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