2 Description
The Payments Building Block enables digital financial payments to be tracked, evaluated, initiated, validated, processed, logged, compared and verified against budget. This ICT Building Blocks also provides interoperability with connections to the various external applications that need payment services in order to trigger transitions in their own WorkFlow. Payment services generally interface through gateways to regulated financial entities such as banks, credit facilities and insurance companies. To help users easily complete payment transactions and learn if their transaction succeeded or failed, it converts heterogeneous interface protocols, formats and user interfaces to a standard set of common interfaces and formats. It can also help in tracking costs of commodity and equipment purchases to optimize budgets.
The Payments Building Block consists of components that enable multiple use cases in a generic manner. The use cases, including Government to Person(G2P), Person to Government (P2G), Government to business (G2B) and Business to Government (B2G), The existing commercial Payments schemes are heterogenous across regions and countries, the Payments BB assumes that some components are optional when considering implementation. The payments BB covers components that can be used to deliver the key functionalities and the connections to existing systems in the market, but does not contemplate building a new payments scheme
Financial inclusion strategies have largely been based on growing access to regulated accounts. This was traditionally understood to be bank accounts, in recent years mobile money (MoMo) accounts have greatly increased transactional account access. These MoMo accounts are often, but not always, treated as secondary to the banking system and lack interoperability.
That said, today, with over 1.2 billion global accounts, transacting an average of over $2 billion per day, mobile money has grown to become the leading payment platform in a growing number of emerging markets. Today, there are more mobile money accounts in Sub-Saharan Africa than bank accounts. Indeed, during the pandemic, demand for mobile money services increased among businesses, governments and new services that previously relied on cash or other payment channels.
There are currently active discussions in many markets which need integration of mobile money into existing national infrastructure. While the integration of mobile money into existing schemes and infrastructure has the potential to create value for all stakeholders in the ecosystem, many legacy payments systems may not be suitable for mobile money integration in their current state. As an example, many existing interbank switches do not support mobile money as a core feature because of legacy technical architecture. What is often missing is the essential capability of the switch to handle high-volume, low-value flows with the mobile number (Mobile Station Integrated Services Digital Network) as identifier for routing and address resolution hence the need for integration.
Recent industry developments offer solutions designed to solve many of the issues around the switching of mobile money.
Mobile money providers, regulators, infrastructure providers, and other financial system players should seek to engage on any potential interoperability initiatives from an early stage to ensure optimal payments system design for all parties. Should existing infrastructure be used, a thorough assessment should be conducted, with input from all parties, to ensure appropriate governance, commercial, and technical standards are incorporated.
Mandating interoperability within a short time frame, removes opportunities for a thoughtful and holistic analysis of commercial sustainability. Requiring immediate interoperability can also delay or hamper the uptake of interoperable transactions, and mobile money services altogether. This is a particular risk in contexts where regulators or governments impose immediate connections to a centralized hub. Mobile money providers should be encouraged to connect when their service is ready. However alternative modalities of payment such as cash-vouchers can also be considered in scenarios of low-resource regions that lack modern infrastructure and volume of mobile phone users.
Also, in countries where mobile money providers are not connected to a payment switch, aggregators can enable the flow of funds between multiple financial service providers including banks and non-banks. While aggregators may not be as efficient and scalable as switches, they can help solve interoperability issues in the short and medium term.
Generally the Building Block is supportive of multiple types of payment use cases where the Government is one of the parties:
- Government to people (G2P)
- Payment where the payer is a government and the payee is an individual e.g. Social benefits disbursement, government salary payments, Conditional and Unconditional Social Cash Transfers).
- People to Government (P2G).
- Payment where the payer is an individual and the payee is a government (e.g. payment of taxes, payment Registration for Postpartum and Infant Care, payment of school fees, driving license, utility payments).
- Government to Business (G2B)
- G2B payments include tax refunds, goods and services purchases and subsidies. Contracts payments, benefits, loans
- Business to Government (B2G)
- B2G payments include paying taxes and fees.
- Government to Government (G2G)
- Payments between two government entities (ie between Ministries/Departments and public sector institutions).
Government to Business payments (G2B) and Government to Government (G2G) are not covered in this specification and will be covered in the second phase..
Capabilities | Payment Infrastructure Scenario | DIAL User journey | Use Cases | Destination Channel |
G2P | Scenario 1-4 & 6 | Payment - Unconditional Social Cash Transfer (non-electronic/cash payments) | a). Beneficiary payment, Incentive payment to mother. b) Government Salary payment c) Unconditional cash transfer | Voucher payment, Mobile Money, direct bank transfer |
P2G | Scenario 1-4 & 6 | Postpartum care | Payment - registration of birth (Postpartum and Infant Care) | Mobile Money. |
Modality | Infrastructure Components | Comments |
|---|---|---|
Mobile Money |
| Mobile money is a destination account to distribute funds to end users (in the case of G2P) or an initiation account to enable users to initiate a payment for government services (P2G) which is facilitated by private commercial entities,typically Mobile Network Operators. There are three ways that facilitate interoperability between a mobile money provider and a financial service institution (which could be the initiator of a payment - G2P or the receive - P2G): Through a Switch, through a third-party aggregator or through a bilateral integration. We expect one or multiple of these components to be in place to facilitate the use cases discussed in this document but these will remain out of the payment building block. |
Vouchers | Voucher Management System, Merchant Ecosystem, Merchant Registry | The Merchant Ecosystem and the Merchant Registry are both outside the scope of the Payments Building Block. The development of the Merchant Ecosystem will be driven by the relevant government institution. The Merchant Registry will be managed by another building block. |
- Payment scheme creation is outside of the scope.
- Government to Business and Government to Government Payments are out of scope for the first phase and will be considered in the second phase.
- Identity systems are separate and outside the payments BB, with key implications for KYC/CDD in the banking system.
- Consent of people eligible as beneficiaries of G2P programmes for their personal details (ie National ID and payments details) to be stored in tokenised form in the centralised mapper (where the government has to implement the mapper).
- Delegation of authority - Consent of the recipient for payment of G2P to be made to a third party (next of kin) is outside the scope of the payments building block and should be handled by consent management building block at the time of beneficiary registration for the G2P program.
- For social benefits G2P payments, social registries are an important building block which will implement the registration, and determination of potential eligibility of citizens for one or more social programs. As such, they are a separate building block and are outside the payments BB.
- An Integrated Financial Management Information System ( IFMIS ) and a Treasury Single Account (TSA) are essential components in improving the safety and efficiency of government payment programs. The TSA, in particular, ensures effective aggregate control over government cash balances and facilitates the reconciliation between banking and account data. It is assumed that these components exist at the level of the government as they are outside the scope of the payments BB.
- Settlement systems are outside of the scope, Settlement allows the flow of money between participants and can be done on a Pre-funding basis which allows incoming transactions if the sending DFSP has already deposited sufficient liquidity with them. Alternatively settlement can be on a Clearing-base where FSPs allow incoming transactions before receiving the funds.
- Pricing. This generally revolves around processing fees (for each transaction a fixed fee is paid to the entity processing the transaction) and interchange (where one participant agrees to pay the other).
- Dispute resolution mechanisms which allow FSPs to reach consensus on a transaction’s status and financial liabilities in the case of a dispute. There are two main types of dispute resolution mechanisms: the consensus option where parties must agree on a transaction’s status; and the arbitration option where one party has authority over a transaction’s status.
- Governance defining sets of rules on how participants make decisions.
- Development of the voucher management ecosystem that is outside the technical specification of the Payment Building Block, including but not restricted to recruitment and registration of merchants / agents for the redemption of vouchers, etc.
Last modified 9mo ago