Thanks, Aman and James. Aman*:* Agreed on all three points. I'll stay within the existing Core APIs and follow the thin adapter pattern. For beneficiaries, I'd reject deletion or any attempt to lower a beneficiary's limit below the amount of an active instruction until those instructions have been cancelled.
James*:* Understood. The feature would be controlled by a configuration property, disabled by default, so it can be turned off entirely if needed. Regarding timing, I'd like to move forward with this now. Separately, thank you for sharing your thoughts on how you'd like to see the community move forward with GSoC 2027 since it helps me a lot in planning for the next upcoming months. Thanks, Abhishek On Thu, 5 Nov 2026 at 22:46, James Dailey via dev <[email protected]> wrote: > hi Abishek > > I agree with Aman mostly, AND I would point out that the broader community > has also been building additional BFF concepts and embedding logic for > standing instructions and multi-sig flow, complex permissions, etc etc in > those outside services (some of them other open source projects). > Without a broader vision for the edge of Fineract and the beginning of > those other services, I think this *risks* bringing Fineract code into > conflict with outside components that are in production in various places. > I would therefore add, that it needs to be set at configuration time > whether such functionality is enabled in Fineract. It has to be able to be > "turned off" at the API level (permissions level?) or excluded from the > build. > > The reason I created the four projects for GSOC last year was to establish > work areas that clearly were NOT going to be conflict with ongoing dev or > even touch on things that could conflict. > > - Backoffice_UI > - Loan_Origination > - Business_Intelligence > - BFF_with_front_end > > I assume you want to make this a project now or is this a project for GSOC > 2027? > > My general take is that in 2027, we may only have more than 2 or 3 GSOC > students, based on available mentors. > > My personal focus in 2027 is to advance one or more of the areas above and > hopefully pay down the code debt identified by the senior devs in multiple > posts and presentations. > I will repeat: I don't want to see more and more functionality in core > Fineract, I want less. I want more tests, more stability, more > maintainable code. I want a better developer experience. > > James > > On Thu, Nov 5, 2026 at 8:01 AM Aman Mittal <[email protected]> > wrote: > >> 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 >>> >>
