Target release1.0
Document status
Document owner


  • Develop consensus around a baseline set of high level functionality required in Fineract-CN ecosystem to elicit interest from a wide community of users, partners and implementors


#ModuleTitleOverviewImportanceFineract CN supportFineract 1.x supportNotes
1Office and staffManage officesSupport for creating, editing and deleting offices and their associated hierarchyMust HaveYes (needs QA)Yes

2Manage staffAbility to manage staff within offices and associate user logins with fine-grained access control to themMust HaveYes (needs QA)Yes

3CustomersCustomer ManagementAbility to create and manage customers along with organization specific structured dataMust HaveYes (needs QA)Yes
4KYCAbility to associate KYC documents with customersMust HaveYes (needs QA)Yes
5LoansTerm LoansAbility to create and service term loans with either

  - No-interest
  - Fixed Interest (Interest not affected by out of turn payments)
  - Interest recalculation (Repayment schedule recalculated as a result of out of turn payments)
  and supporting single or multiple disbursements

Must Have???Yes
6Revolving credit loansAbility to create and service revolving credit, which are conceptually similar to a credit card / overdraft account but has some form of agreed upon repayment schedule associated with it.Should Have???NoSupporting revolving credit early on would help provide a useful business case for organizations using Fineract 1.x to consider investing in Fineract CN
7Documentation and additional dataAbility to capture documents and additional (organization specific) structured data associated with loan accountsShould Have???Yes
8DepositsTransactional accountsA transactional account having support for interest posting, overdrafts and overdraft interest postingMust Have???Yes
9Documentation and additional dataAbility to capture documents and additional (organization specific) structured data associated with loan accountsShould Have

10AccountingCOA and journal entriesAccounting module with support for creating COA and manual journal entriesMust HaveYes (needs QA)Yes
11Integrated accrual accountingIntegrated accrual accounting (supporting GAAP standards) for loans and savingsMust Have???YesFineract 1.x lacks (daily) accrual accounting support for deposit accounts
12IntegrationsACH IntegrationIntegration with a widely used ACH (or ACH with potential to be widely used) like Mojaloop for enabling digital paymentsCould HaveYes (needs QA)Yes There is work in progress on integration with Mojaloop on both Fineract 1.x and CN. A number of implementations of Fineract 1.x and related forks have integrations with country specific ACH
13Customer Access API GatewayView account detailsAbility of authenticated customers to query organization defined (fine-grained control) details of their active and closed loan and savings accounts. Typical details include associated schedules, payment history & breakdown and details of upcoming paymentsShould HaveNoYes

There are some concerns that Fineract 1.x does not have sufficient separation between self-service and back-office API's.

We should plan to illustrate the utility of these API's by supporting a non-trivial application like Mobile wallets.

14TransfersAllow customers to make transfers between their accounts and payments to third parties.Could HaveNoYes (see notes around ACH integration)
15Third Party processorsAllow customers to authorize third parties to act on their behalf. These third parties need to be registered with the customer access gateway along with details of their associated permissions.Could HaveNoNo


Below is a list of questions to be addressed as a result of this requirements document:

Should the customer access gateway allow customer on-boarding / loan origination ?

Vishwas Babu A J : For the first cut, I would suggest that we limit the scope of the customer access gateway to act as a wrapper around commonly used and clearly understood functionality i.e viewing account details and transfers.

Ex : Unlike read functionality, a customer creating a loan application is typically NOT just a wrapper over the create loan API in the back-office. Ideally, all that would happen is the creation of the record in the customer portal itself and the decision to move the same to the CBS would be made only after the completion of an organization defined workflow.

Not Doing