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.
|#||Module||Title||Overview||Importance||Fineract CN support||Notes|
|1||Office and staff||Manage offices||Support for creating, editing and deleting offices and their associated hierarchy||Must Have||Yes|
Minor issues : An error message is shown when creating the head office using the community App. Need to investigate further.
|2||Manage staff||Ability to manage staff within offices and associate user logins with fine-grained access control to them||Must Have||Yes|
|3||Customers||Customer Management||Ability to create and manage customers along with organization specific structured data||Must Have||Yes (needs QA)|
|4||KYC||Ability to associate KYC documents with customers||Must Have||Yes (needs QA)|
|5||Deposits||Basic Transactional accounts||A transactional account having support for deposits and withdrawals||Must Have|
Yes (needs QA)
|6||Account Transfers||Ability to effect transfers from one account to another within the same organization||Must Have||No (?? 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 reversals||To support electronic transfers, a transactional account needs to provide support for authorizing holds, settlements and reversals.||Must Have||No||This should have been a dependency for the Customer Access API Gateway.|
|7||Deposit Fees||Ability 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 Have||Partially 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.
|8||Transfer Fees||A 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 merchants||Should Have||Partially 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
|9||Withdrawal Fee||A 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 Have||Partially supported||Most Mobile wallets avoid fees while loading the wallet with fees typically paid during transactions or on the event of cashing out of the ecosystem|
|10||Taxation support||Typically service taxes are levied on top of any fees charged by an organization (deposit fees, withdrawal fees, transfer fees etc)||Nice to Have||No|
|11||Documentation and additional data||Ability to capture documents and additional (organization specific) structured data associated with deposit accounts||Should Have||Yes|
|12||Accounting||COA||Accounting module with support for creating an organizations COA||Must Have||Yes (needs QA)|
|13||Integrated accounting||Integrated accrual accounting for deposits and withdrawals linked to transactional accounts||Must Have||Yes (needs QA)|
|14||Value dated accounting||Ability 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 Have||No|
|15||Customer Access API Gateway||View account details||Ability 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 etc||Must Have||Yes (needs QA)|
Provided by the Mifos Initiative's work around customer self-service
|16||Transfers||Allow customers to make transfers between their accounts and payments to third parties.||Must Have||Yes (needs QA)|
|17||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.||Should Have||No|
Below is a list of questions to be addressed as a result of this requirements document: