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