Hi Vishwas, Hi Aman, Thank you both for the feedback.
The LOS staff-facing frontend is already implemented as part of the current GSoC, with the existing authentication and authorization using Fineract users, roles, and permissions. This was the initial direction, and the current flow already demonstrates the approval workflow. Since this is a POC, I’m happy to proceed with the Back Office Micro Frontend approach proposed by Aman for the staff-facing approval interface, while keeping the approval workflow and state machine entirely within the LOS backend. This also aligns with Vishwas’s feedback on keeping LOS as a standalone, decoupled service while having the staff-facing approval experience within the protected Back Office environment. I’m happy to explore the proposed authentication and short-lived JWT flow as part of this work and proceed accordingly. Regards, Sujan On Tue, 11 Aug, 2026, 11:42 Aman Mittal, <[email protected]> wrote: > Hi Sujan, > > Thanks for the clarification. I agree with keeping the LOS as a > standalone, decoupled service where the origination workflow and approval > state machine remain owned by the LOS. > > For the staff-facing approval interface, I think integrating the LOS > approval UI into Fineract Back Office through its Micro Frontend support > could be a good approach. This would allow us to keep the staff interface > within the protected Back Office environment without moving the approval > logic itself into Fineract. > > From the Back Office UI perspective, I would propose the following > authentication and integration model. > > The Back Office is primarily designed to interact with the Apache Fineract > Core/LMS and uses the authentication mechanism provided by Fineract. LOS > can maintain its own API security using short-lived JWTs. > > A possible flow would be: > > 1. The staff user logs into Fineract through the Back Office UI using > their Fineract credentials. > 2. Fineract authenticates the user and provides the authentication > context/token used by the Back Office. > 3. When the user accesses the LOS Micro Frontend, the UI requests a > short-lived LOS JWT. > 4. LOS verifies the Fineract authentication context against the > relevant Fineract instance. > 5. LOS verifies that the Fineract user has the required > role/permission for the requested LOS functionality. > 6. If the authorization succeeds, LOS issues a short-lived JWT to the > Back Office/LOS Micro Frontend. > 7. The LOS Micro Frontend uses this JWT when invoking LOS APIs. > 8. Once the JWT expires, the UI obtains a new token through the same > flow rather than maintaining a long-lived LOS credential. > > Conceptually, I see the architecture as: > > CLIENT / UI SIDE > ┌─────────────────────────────────────────────────────────────┐ > │ Fineract Back Office │ > │ │ > │ ┌──────────────────────┐ ┌───────────────────────────┐ │ > │ │ Core Back Office UI │ │ LOS Micro Frontend │ │ > │ │ │ │ │ │ > │ │ Customers │ │ Applications │ │ > │ │ Loans │ │ Approval Queue │ │ > │ │ Accounts │ │ Credit Review │ │ > │ │ etc. │ │ Approval Actions │ │ > │ └──────────┬───────────┘ └─────────────┬─────────────┘ │ > └─────────────┼──────────────────────────────┼───────────────┘ > │ │ > │ Fineract authentication │ Short-lived LOS JWT > │ │ > ▼ ▼ > > SERVER SIDE > > ┌──────────────────────────┐ ┌──────────────────────────┐ > │ Apache Fineract │ │ LOS │ > │ Core + LMS │◄─────►│ │ > │ │ │ Origination │ > │ Users / Roles │ │ Applications │ > │ Permissions │ │ Workflow │ > │ Loans / Servicing │ │ Approval State Machine │ > │ Disbursement │ │ LOS Authorization │ > └──────────────────────────┘ └──────────────────────────┘ > │ │ > │ │ > └─────────── integration ─────┘ > > The important separation here would be: > > - *Fineract Core/LMS* remains responsible for staff identity, existing > roles/permissions, loan servicing, and disbursement. > - *Back Office* remains the protected staff-facing application. > - *LOS* remains responsible for the complete origination lifecycle, > including workflow and approval state. > - *LOS Micro Frontend* provides the approval interface inside Back > Office but does not own the authorization or business logic. > - *LOS APIs* remain responsible for validating the JWT and enforcing > authorization for every approval operation. > > I would also recommend that LOS should not blindly trust authorization > information coming from the UI. The authorization decision should always be > enforced server-side by LOS. The Back Office/Micro Frontend should only act > as a client of the LOS APIs. > > This approach could provide a good balance between the two concerns: > keeping LOS completely decoupled from Fineract while still reusing the > existing Fineract authentication/RBAC model and the protected deployment > model of Back Office. > > It also leaves room for the LOS to have other clients in the future, > without making Fineract Back Office a mandatory dependency of the LOS > itself. > > Regards, > Aman > > On Tue, Aug 11, 2026 at 11:41 AM Vishwas Babu <[email protected]> > wrote: > >> Hi Sujan, >> >> Keeping the origination workflow and approval state machine in the LOS >> backend is the right call. I would question why the Fineract LMS Back >> Office needs to be involved in origination at all. >> >> Approvals are not necessarily simple yes or no decisions. They can >> involve modifying offers, terms, and conditions, requesting additional >> information or documents, or sending an application back to an earlier >> stage. All of this belongs to the origination domain. If the LMS Back >> Office hosts the approval interface, we reintroduce the coupling we just >> removed. >> >> On the security concern, I think this can be handled through deployment. >> The LOS staff portal can be deployed separately and isolated from the >> public applicant portal, while both use the same LOS backend and its roles >> and permissions. This gives origination staff a single protected >> environment without splitting the origination experience across two systems. >> >> This keeps the LOS independent and allows it to evolve without being >> constrained by Fineract LMS Back Office. Once the LOS is more fully built >> out, we can always revisit providing a unified staff experience across the >> LOS and Fineract Back Office. >> >> Regards, >> Vishwas >> >> On Mon, 10 Aug 2026 at 22:36, sujan kumar <[email protected]> >> wrote: >> >>> Hi Vishwas, >>> >>> Thank you for the feedback. >>> >>> The LOS is being kept as a standalone, decoupled service, with the >>> origination workflow and approval state machine owned by the LOS backend. >>> >>> For the approval interface, I’m considering using the Fineract Back >>> Office UI for internal staff, while keeping the approval logic in LOS. This >>> would allow us to leverage the existing RBAC and keep staff approval access >>> within the Protected environment, rather than exposing it through the >>> public-facing LOS. >>> >>> The Back Office would invoke dedicated LOS APIs for approval actions, >>> while LOS remains responsible for the origination lifecycle and its >>> integrations with Fineract. >>> >>> I’d appreciate your thoughts on whether you see any architectural >>> concerns with this approach. >>> >>> Regards, >>> Sujan >>> >>> On Tue, 11 Aug, 2026, 10:01 Vishwas Babu, <[email protected]> >>> wrote: >>> >>>> Hi Sujan, >>>> >>>> Congrats on building this out. An LOS is much needed in the Fineract >>>> ecosystem, and done well, it could become more widely adopted than >>>> Fineract’s loan servicing capabilities themselves. >>>> >>>> On your two questions: >>>> >>>> *Security model: *I would recommend a hard boundary between the LOS >>>> and Fineract LMS. The LOS should own applicant authentication and have a >>>> dedicated Fineract service account to interact with Fineract LMS as a third >>>> party. >>>> >>>> *Where approvals should live*: I would keep the complete origination >>>> workflow, including any approvals, within the LOS with its own roles and >>>> permissions. Approvals are part of the origination domain, and moving them >>>> into Fineract LMS Back Office would unnecessarily couple the two systems. >>>> >>>> The above answers are grounded in the assumption that the *LOS should >>>> be a standalone project that integrates well with Fineract, rather than an >>>> extension of Fineract*. An approved application should be capable of >>>> being booked into Fineract or any other Loan Management System. This gives >>>> both projects clear responsibilities: the LOS owns the application and >>>> origination lifecycle, while the LMS owns the loan after booking. It also >>>> gives the LOS the potential to reach a significantly larger audience. >>>> >>>> This separation matters because a production LOS will eventually need >>>> configurable workflows, a rules and decisioning engine, bureau and >>>> verification integrations, scoring, pricing and offer generation, and >>>> comprehensive auditability. Versioning should be a first-class design >>>> concern: for any historical application, an institution should be able to >>>> determine which workflow, rules, scorecard, and pricing configurations >>>> produced the decision, and ideally replay historical applications against >>>> newer models or rules to analyse the potential impact of changes. >>>> >>>> Coupling with Fineract LMS also creates the temptation to reuse >>>> existing infrastructure where it may not be the right fit. *Data >>>> Tables are a good example :* Their direct mapping to database tables >>>> in PostgreSQL makes them useful for simple extensions, but awkward as the >>>> foundation for a domain that needs schema evolution, versioned >>>> configuration, richer validation, rules, and reproducible historical state. >>>> Doing so risks boxing the LOS in with design choices we made in the LMS >>>> more than a decade ago, when we did not know any better. >>>> >>>> Building a platform that can be easily extended is what would turn this >>>> LOS from a proof of concept into something lenders would be interested in >>>> building on and contributing back to, rather than vibe-coding a point >>>> solution for their requirements. >>>> >>>> Regards, >>>> Vishwas >>>> >>>> On Sat, 8 Aug 2026 at 04:48, sujan kumar <[email protected]> >>>> wrote: >>>> >>>>> Hello Fineract Community, >>>>> >>>>> I'd like to seek community feedback on the security model for the Loan >>>>> Origination System (LOS). >>>>> Current Architecture >>>>> >>>>> The current LOS prototype is implemented as a standalone service that >>>>> integrates with Apache Fineract. It currently provides: >>>>> >>>>> - A public-facing applicant portal for creating and submitting >>>>> loan applications. >>>>> - A staff portal supporting configurable multi-stage approvals >>>>> (Loan Officer → Credit Committee → Branch Manager). >>>>> - Authentication using Fineract users and roles. >>>>> - Loan disbursement through Fineract after the approval workflow >>>>> completes. >>>>> >>>>> Security Considerations >>>>> >>>>> One of the areas I am currently evaluating is the security model for a >>>>> production deployment. >>>>> >>>>> The applicant-facing LOS is intended to be publicly accessible, while >>>>> Apache Fineract Back Office is typically deployed within a trusted >>>>> internal >>>>> environment. This raises questions about how responsibilities should be >>>>> divided between the two systems, particularly for approval workflows that >>>>> ultimately lead to financial actions. >>>>> >>>>> Some possible approaches include: >>>>> >>>>> - Keeping both customer submission and staff approvals within LOS, >>>>> secured with appropriate authentication and authorization. >>>>> - Keeping customer-facing functionality in LOS while moving >>>>> approval stages into the Fineract Back Office. >>>>> - Leveraging the existing Back Office role and permission model >>>>> for internal approval workflows. >>>>> >>>>> The current implementation should be considered a proof of concept, >>>>> and we intend to clearly document that it is not yet a production-ready >>>>> security architecture. >>>>> Questions >>>>> >>>>> I would appreciate community feedback on the following: >>>>> >>>>> 1. What security model would be recommended for a public-facing >>>>> Loan Origination System integrated with Apache Fineract? >>>>> 2. Should multi-stage approvals remain within LOS, or should they >>>>> be handled by the Fineract Back Office? >>>>> >>>>> Thank you. >>>>> >>>>> Sujan >>>>> >>>>>
