Hi Abhishek, Thanks for the proposal. The overall approach and the breakdown into slices look good to me, and keeping loan repayments out of the first version makes sense.
On your questions: 1. Using Fineract's standing instructions is the right call so Core stays the system of record and we don't maintain a separate scheduler in the BFF. Just make sure the new calls go through the thin adapter pattern we are moving to for Fineract clients. 2. Let's keep allowPartialTransfer off for consumer transfers. Partial execution is confusing for savings-to-savings transfers, and exposing a per-instruction toggle would also require changes on the Core side. 3. Let's leave future-dated one-off transfers out of scope for now and stick to weekly and monthly recurring transfers first. One important thing to keep in mind: please make sure all of this can be implemented inside fineract-consumer-facing using the existing Core APIs. If anything requires new PRs in core Fineract, it will have to go through PMC review and will slow this down quite a bit. Since your standing instruction fixes are already merged in Core, we should only need to update the pinned Fineract image and spec in consumer-facing if needed. Also, while working on the create/cancel flow, please check how we should handle active standing instructions if a user later deletes that beneficiary or lowers its transfer limit. P.S. Please also ensure that you can accommodate new requirements and that the scope can be changed. I would also ask the community for suggestions. Regards, Aman On Thu, Nov 05, 2026 08:50 PM, Abhishek Chaudhary < [email protected]> wrote: > 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 >
