Mission/ Vision:  

At Apache Fineract, our mission is to build, maintain and enhance a cloud-ready core banking system for robust, scalable, and secure operations of financial institutions.  

We believe in financial services for everyone, including and especially for the unbanked and underbanked. 

We primarily build the backend system, the headless application.   

Priorities 

1. Make it easier and more maintainable for outside "users" (implementers) to extend the system rather than fork the code 
   1. We value both the ability to "build on top of" in an external system way and "build capabilities within" 
   2. For the "Build on Top Of", we need more attention to API documentation and recommended approaches 
   3. For the "build capabilities within" we introduced in Release 1.8 the Custom_Module concept which needs additional documentation and also improvements in the direction of Liquibase migrations (for out of bounds modules) 
2. Enhance and improve Quality and Security
   1. We observe that security is also a function of well-executed approaches
   2. We will continue to improve on Pull Request reviews and work to ensure good contributions that meet the necessary standards
   3. For security, we will fix certain design areas (to be discussed on Security List)  
   4. We will consider and use a Fineract Improvement Proposal (FIP) concept for process 
3. Build for stability, maintainability, and scalability. 
   1. we are especially noting that the Loan Module needs refactoring to improve maintainability 
   2. refactoring will also be aimed at improving stability (and make it easier to find the bugs) and as a side effect will improve performance 
   3. the lack of consistent refactoring is also a problem and we prioritize a wider implementation of the same coding patterns across all modules to ensure stability of the project as well as maintainability
4. Make the project more approachable 
   1. This starts with the right sort of documentation 
   2. We assume that people come with either a "developer need" (need to understand how to deploy, how to do dev on top of, how to understand a specific pattern ) or a "business need" (what are the capabilities) 
   3. We have a number of documentation efforts including the ASCII doc (not well linked to) and the Swagger API documentation (too manual for now)  and we need a high level effort here 

HIGH LEVEL ROADMAP 

High Level Proposed areas of development (all are possible, only some are going to be acted upon) 

The above roadmap shows the high level areas of development.  Q4 work is retrospective.  

Group A: underlying libraries and infra related 

• Spring Batch and Close of Business (COB) 
• Upgrade to Spring Boot 3.0 [ SpringBoot now at major release 3.0 (JDK release process -like ), we are close to end of life on version 2.7 (likely on unsupported version by Q2 2023) 
• Event framework (limited to specific modules for now ) 
• Tenant improvements (parameterization) and security 
• Need liquid base change script improvements for not-known liquibase change sets based on new custom modules ( in their own namespaces) , some kind of "orchestration" concept that outside groups have to... maybe better documentation 

Group B: Module refactoring  

• Process: Fineract Improvement Proposal (FIP) under discussion on list 
• Process: Developer documentation via ASCII docs so that patterns of "how to help use improve and add" are more clear 
• Process: Creating high quality standards for new commits so that we avoid new code debt especially in this area (i.e. stop digging the hole) 
• Making progress on the Loan Module , cleaning it up, paying down "code debt", making it more maintainable and enhance performance by streamlining the code 
• Isolate "Self Service APIs"  to prevent inadvertent use 
• Payment Accounts (scalable, avoid optimistic locking, throughput, refactor of balance calc ), essentially limited "current account" functionality, strip out interest and other features of savings component and create as a new concept).  aka "wallet accounts" 
• Related to payment accounts, CAMPT.052 for ISO compatible batch concept, refactoring "note field" i.e. a JSON representation of the transaction set 

Group C: Documentation of the project

• Using automated tools (ASCII doc) that exist in the git next to the code (DONE)  
• Deprecate much of the wiki pages - highlight the ASCII docs 
• Create flow of wiki that suites the two audiences (business vs developer) 
• Need wiki pages for Capabilities documentation (as a kind of updated "user doc")  
• Need API documentation auto generated 

Group D: Areas of work we anticipate seeing as contributions 

• Fixes for POSTGRES implementations (existing queries in code base and uncovered by tests) - coming as a fix 
• Generic revolving line of credit (as a plug in or in a new way that enhances extensibility of the architecture)  , maybe a new microservice?  

Group E:  Ideas and specific items we might be looking at further 

• DSLQuery or JOOQ for enhancing security 
• Command processing service - implementing retry mechanism in case of optimistic locking problems (multiple transactions on the same account/ improved implementation) 
  • Message Queues and response mechanisms 
• Refactor and Remove all security framework and place instead with outside OpenPolicy notes / at idea stage **See notes Roadmap conversation 2023 

Group F: Stuff we think is needed but isn't practically on the Roadmap (no one doing the work) 

• Reporting module
• Completing features across the board (events applied to outside of loan module) 
• Extension points for the Customer model, i.e. support external KYC providers and external third party systems 
• Data export capabilities to external data lakes (might be mostly documentation) 
• Security model enhancement by proposing a deployment architecture behind appropriate firewalls and API gateways (documentation) 
• Better extension points for Full Treasury management system (APIs and new funds movement configuration)  
• Better documentation and perhaps a micro service that performs upgrade from version A to version Z 
• Merchant account feature?:  Down payment on a "Purchase Event" , introducing the idea of a merchant account where full "good funds received" payment is made into account by source of funds being "purchaser" plus "financing source" 

Tickets 

Link to Epics and Key Jira Tickets that express the high level stuff 

COMING 

Anti-Roadmap 

1. Anti-roadmap seeks to avoid feature-creep that muddy the application 
2. Anti-roadmap in an open source project also provides the "missing" components that vendors can then develop as a deeper solution.  

Things we will not prioritize 

• UI:  The UI is already hosted by Mifos as open source, we will not prioritize a UI on fineract / Fineract remains a headless application , i.e. API driven 
• Reports:   other than Elastic Reports on Fineract that can be leveraged , or the Mifos reports also open source 
• Payment gateway/connector: The PaymentHUB at Mifos already connects to Fineract and is an open source solution, this includes ATM connectors, UPI connector, checks, etc.  
• Complex Customer onboarding workflows 
• Full KYC/AML/CFT solution 
• Full Treasury features 
• Teller management features 
• Branch cash management and treasury features 
• Loan Origination complexity 
• Document management 

Not considered and therefore no action→  items highlighted on JIRA as potentially useful for consideration in Roadmap 2022.