Scope and Summary

Relevant read for Functional consultants, developers, architects, or fintech product managers.

The scope and details in this space is relevant for:

• Ability to deploy services anywhere in the cloud or premise , raw or using a tooling service.

• Deployed configuration for testing, staging and production deployment.

• Ability of authenticated services to query tenant defined (fine-grained control) details of their active and closed loan(accounts). Typical details include associated schedules, payment history & breakdown and details of upcoming payments.

• Ability to add and reduce tenants when required for testing with boot scripts in place.

• Deploying fineract community-app with desired API for teams to access (limited to only few)

• Service to service interaction using oauth2 with predefined clients

• Connecting Fineract Audit logs with ELK

• Potential assessment study between Fineract 1.x and CN

• Potential pitfalls we might encounter in functionality and deliverable

• Define the scope for API middleware

Things to keep in mind:

Versioning Notes: 1.x vs CN(CN is deprecated now)

While Fineract 1.x is the choice for test deployment. Fineract 1.x lacks performance and stability since the nature of monolithic architecture. Also, the idea of changing or adding a new feature is definitely easy for 1.x but over the period of time, managing the change and its dependency over other features becomes cumbersome.

Create a Service Layer

There is a clear view to create a service layer- a middle ware between Fineract API platform and any and all external services including but not limited to CRM DB, notification mechanisms etc. Our view is that the scope of service layer is to enhance security, expose only the services which are specific to business requirements.

Open Banking Principles

Embedding WSO2 style PoC case study in technical architecturing of the Financial Institutions's tech infrastructure

Performance and Scalability Test

Create a strong 'Performance and Scalability Test' to evaluate the availabilty of Fineract platform subject to your DevOps and prior to Production runtime phase.

Historical Database Migration

Drop the old cat dead by ruling out Reports in excel or csv as an input/output to and from Fineract say for internal and external services integration.

A financial Institution is a running business with a wide variety of reporting formats on the same set of data pointers.

It may be lethal and time consuming to bring Fineract Data reports in sync with historical data records for both the purpose of import and export.

API interfacing level approach should be followed.

See section DB Migration and Fineract Connector Design Principles.

(Note: This point does not apply for a routine and recurring management reports section such as Loan portfolio, Savings portfolio securitization activities etc.)

This approach also completely phases out batch oriented processes thus bringing systems to a real time API interfacing modes.