Hi all, I'd like to add scheduled and recurring transfers to fineract-consumer-facing (https://github.com/apache/fineract-consumer-facing). transfers.adoc records the gap: transfers "use the server's current date; there is no scheduling, no future-dated transfer, and no recurring transfer". I've fixed standing-instruction issues in core ( https://issues.apache.org/jira/browse/FINERACT-2914, https://issues.apache.org/jira/browse/FINERACT-2400), so I'd like to build on those.
Proposal: use Fineract's standing instructions (/v1/standinginstructions) rather than a scheduler in the BFF. Fineract stays the system of record and its Execute Standing Instruction job runs them. A customer could: - create a weekly or monthly transfer, with a start and optional end date, from an own savings account to another own savings account or a registered savings beneficiary; - list their instructions with run history, including failed runs; - cancel an instruction. Loan repayments stay out of the first version, since a fixed recurring amount can exceed what's owed. Rules, reusing the current transfer flow: - create and cancel go through the same initiate/confirm OTP step-up, with an Idempotency-Key on confirm; - the same destination checks as one-off transfers, with the amount within the beneficiary's transferLimit; - reads authorize SAVINGS_VIEW on every source account, as transfer history does. Slices: the Fineract adapter, then list and run history (read-only), then create and cancel, then the Angular screens with Cucumber and Playwright tests. Questions: 1. Standing instructions, or a BFF-side scheduler? 2. Should customers be able to set allowPartialTransfer, or should it always stay off? 3. Is a future-dated one-off transfer, as a single-run instruction, in scope? Thanks, Abhishek
