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