THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Goals
- 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
Requirements
| # | Module | Title | Overview | Importance | Fineract CN support | Fineract 1.x support | Notes |
|---|---|---|---|---|---|---|---|
| 1 | Office and staff | Manage offices | Support for creating, editing and deleting offices and their associated hierarchy | Must Have | Yes (needs QA) | Yes | |
| 2 | Manage staff | Ability to manage staff within offices and associate user logins with fine-grained access control to them | Must Have | Yes (needs QA) | Yes | ||
| 3 | Customers | Customer Management | Ability to create and manage customers along with organization specific structured data | Must Have | Yes (needs QA) | Yes | |
| 4 | KYC | Ability to associate KYC documents with customers | Must Have | Yes (needs QA) | Yes | ||
| 5 | Loans | Term Loans | Ability to create and service term loans with either - No-interest | Must Have | ??? | Yes | |
| 6 | Revolving credit loans | Ability 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 | ??? | No | Supporting revolving credit early on would help provide a useful business case for organizations using Fineract 1.x to consider investing in Fineract CN | |
| 7 | Documentation and additional data | Ability to capture documents and additional (organization specific) structured data associated with loan accounts | Should Have | ??? | Yes | ||
| 8 | Deposits | Transactional accounts | A transactional account having support for interest posting, overdrafts and overdraft interest posting | Must Have | ??? | Yes | |
| 9 | Documentation and additional data | Ability to capture documents and additional (organization specific) structured data associated with loan accounts | Should Have | ||||
| 10 | Accounting | COA and journal entries | Accounting module with support for creating COA and manual journal entries | Must Have | Yes (needs QA) | Yes | |
| 11 | Integrated accrual accounting | Integrated accrual accounting (supporting GAAP standards) for loans and savings | Must Have | ??? | Yes | Fineract 1.x lacks (daily) accrual accounting support for deposit accounts | |
| 12 | Integrations | ACH Integration | Integration with a widely used ACH (or ACH with potential to be widely used) like Mojaloop for enabling digital payments | Could Have | Yes (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 |
| 13 | Customer Access API Gateway | View account details | Ability 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 payments | Should Have | No | Yes | 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. |
| 14 | Transfers | Allow customers to make transfers between their accounts and payments to third parties. | Could Have | No | Yes (see notes around ACH integration) | ||
| 15 | Third Party processors | Allow 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 Have | No | No |
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Comments | Outcome |
|---|---|---|
| Should the customer access gateway allow customer on-boarding / loan origination ? | Vishwas 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. |