Target release1.0
Document status
Document owner


We define a digital wallet as a payment instrument that is typically loaded with money transferred from a bank account or a credit card. The funds available in the wallet is then used for transactions like bill payments and transferring funds to other wallets within the platform

  • Define and track the completion of features that are critical for supporting a basic wallet on Fineract-CN. 


#ModuleTitleOverviewImportanceFineract CN supportNotes
1Office and staffManage officesSupport for creating, editing and deleting offices and their associated hierarchyMust HaveYes 

Minor issues : An error message is shown when creating the head office using the community App. Need to investigate further.

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

3CustomersCustomer ManagementAbility to create and manage customers along with organization specific structured dataMust HaveYes (needs QA)
4KYCAbility to associate KYC documents with customersMust HaveYes (needs QA)
5DepositsBasic Transactional accountsA transactional account having support for deposits and withdrawalsMust Have

Yes (needs QA)

6Account TransfersAbility to effect transfers from one account to another within the same organizationMust HaveNo  (?? needs verification)While transfers can be made by using the withdrawal and deposits API's in an atomic fashion, without details of from / to accounts, reversals become problematic

Holds, settlements and reversalsTo support electronic transfers, a transactional account needs to provide support for authorizing holds, settlements and reversals.Must HaveNoThis should have been a dependency for the Customer Access API Gateway.
7Deposit FeesAbility to link different percentage charges based on the input source for loading funds. Examples include a flat fee for loading the wallet from bank accounts or a percentage fees for loading the wallet from credit cards.Must HavePartially supported

Ability to link fees to both the payment channel (card networks, banks , agents etc would have different associated fees) and the deposit event is missing. However, since most new wallets tend to absorb loading charges during the market formation phase, this might not be an immediate concern.

8Transfer FeesA percentage of the transaction is typically charged as a merchant discount rate for payments made to merchants . This % fee typically has various slabs based on the amount of transactions processed by a merchant , additionally various merchantsShould HavePartially supported

The ability to have multiple slabs based on transaction amounts, link fees to a particular merchant etc are absent. Multiple workarounds are available:

a) Transfer fees being linked to the deposit event at the merchant account. Each merchant account can then have separate deposit fees linked to them.

b) Fees being calculated outside of the system and applied to each merchant wallet at the end of a month

9Withdrawal FeeA percentage or fixed fee is typically levied when a customer cashes out of the platform. This can either be through bank transfers or physical withdrawals through agent networks.Should HavePartially supportedMost Mobile wallets avoid fees while loading the wallet with fees typically paid during transactions or on the event of cashing out of the ecosystem 
10Taxation supportTypically service taxes are levied on top of any fees charged by an organization (deposit fees, withdrawal fees, transfer fees etc)Nice to HaveNo
11Documentation and additional dataAbility to capture documents and additional (organization specific) structured data associated with deposit accountsShould HaveYes
12AccountingCOA Accounting module with support for creating an organizations COAMust HaveYes (needs QA)
13Integrated accountingIntegrated accrual accounting for deposits and withdrawals linked to transactional accountsMust HaveYes (needs QA)
14Value dated accountingAbility to have a separate entry date (date on which the transaction was entered into the system) , transaction date (date on which the transaction was made in the real world) and value date (date on which accounting books were affected)Should HaveNo
15Customer Access API GatewayView account detailsAbility of authenticated customers to query organization defined (fine-grained control) details of their wallet accounts. Typical details include history of all transactions with a running balance and additional relevant details for transfers etcMust HaveYes (needs QA)

Provided by the Mifos Initiative's work around customer self-service

16TransfersAllow customers to make transfers between their accounts and payments to third parties.Must HaveYes (needs QA)
17Third 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.Should HaveNo


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


Not Doing

  • No labels