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 >> >
