Out-of-Scope Assumptions (Payments)

  • Payment scheme creation is outside of the scope of the current Payments Building Block.

  • 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 Building Block, with key implications for KYC(Know Your Customer)/CDD(Customer Due Diligence) in the banking system.

  • Consent of people eligible as beneficiaries of G2P programs for their personal details (i.e. National ID and payments details) to be stored in the tokenized form in the centralized 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. It should be handled by the consent management building block at the time of beneficiary registration for the G2P program.

  • For social benefits G2P payments, social registries are an essential Building Block that 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 Building Block.

  • 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 Building Block.

  • 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 Digital Financial Service Provider (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 allow FSPs to reach a consensus on a transaction’s status and financial liabilities in the case of a dispute. There are two main 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 defines sets of rules on how participants make decisions.

  • Development of the voucher management ecosystem that is outside the technical specification of the Payments Building Block, including but not restricted to recruitment and registration of merchants/agents for the redemption of vouchers, etc.