1 of 47

Payments Building Block

Vijay Mauree

Payments WG

govstack.gitbook.io/bb-payments/

2 of 47

Overview

  1. Introduction
  2. Key functionalities
  3. Cross Cutting Requirements
  4. Interfaces APIs
  5. Next Steps

2

3 of 47

Introduction�

1

4 of 47

Purpose�

  1. Implements the common payments transactions use cases for government services (e.g G2P, P2G and B2G).
  2. Enables digital payments for government services to be initiated, validated, executed / processed, reconciled and audited.
  3. Cater for disbursements to be made through a variety of non cash payment channels such as mobile money, vouchers and bank accounts taking into account low resource conditions of developing and low income countries

4

5 of 47

Benefits�

  1. Reduces administrative costs for government
      • By digitising payments, governments automate their payment systems, which reduces the cost of collecting, processing and tracking payments
  2. Digitisation of payments facilitate reporting, reconciliation and settlement. This improves data processing and reduces errors and time spent on manual processes
  3. Enhances efficiency of government revenue collection and reduces loss in revenue
  4. Allows government to reconcile payments electronically
  5. Users benefit from a convenient and fast payment method allowing remote payment of government services especially during the pandemic

5

6 of 47

Intended Scope

6

7 of 47

Future Scope�

  1. Current scope does NOT cater for
      • G2B payments
      • G2G payment
      • Multicurrency payments
      • International remittance payments
    1. These payment use cases can be added in a next phase.

7

8 of 47

Out of Scope

  1. Identity Systems: Separate from payment building blocks, playing a crucial role in Know Your Customer (KYC) and Customer Due Diligence (CDD) processes.
  2. Settlement Mechanisms: Allow flow of money between participants. Two types - Pre-funding (where transactions are allowed if the sending Digital Financial Service Provider (DFSP) has pre-deposited sufficient liquidity) and Clearing-based (where Financial Service Providers (FSPs) allow transactions prior to receiving funds).
  3. Dispute Resolution Mechanisms: Aid in achieving consensus on transaction status and financial liabilities during disputes. Two main types - Consensus (where parties must agree on transaction status) and Arbitration (where one party has authority over transaction status).
  4. Governance: Defines the rule-set guiding participant decisions within the payment systems.
  5. Voucher Management Ecosystem Development: Falls outside the technical specification of the Payment Building Block. This includes but is not limited to registration of merchants/agents for voucher redemption.
  6. Merchant Registrations: Involves capturing and storing merchant payment details and the applications used for voucher redemption.

8

9 of 47

G2P Payments

9

Government to Person (G2P) payments

Employee Payments (e.g salary, pension)

Social Transfers

Unconditional

Conditional

10 of 47

G2P Payments Distribution

10

G2P Delivery

Account

Bank

Cards

Mobile Money

CBDCs

Non account

Cash

Vouchers

Paper

Digital

Payments are digital.

G2P system is connected

to the national payment system.

Items in blue could added

In a second phase

Payments can be either in digital

or non-digital mode

Cash payments are not in scope

11 of 47

G2P Payments Design

11

Infrastructure Dependencies

Interoperability and

Shared Infrastructure

Enablers to support different

access points and accounts

Caters for recipients needs

Source: Next Generation G2P Payments – World Bank

12 of 47

G2P Payments Design

12

Impact of shared infrastructure

Beneficiary needs only their ID

# of documents decreased

Time to apply decreased (from days to minutes)

Time for payment delivery much faster

Source: Next Generation G2P Payments – World Bank

13 of 47

P2G Payments

13

Person to Government (P2G) payments

Utility

Transport

Health

Taxes

Education

Public Services

  • passports
  • marriage certificates
  • birth certificates
  • Bill payments
  • Water
  • Electricity
  • Gas
  • Vehicle reg.
  • Road tax
  • Traffic violations
  • Driving licence
  • School fees
  • University fees
  • Accommodation
  • Exam fees

Non-exhaustive

  • Inpatient
  • Outpatient

14 of 47

P2G Payments Supported

  • Bill Payments
    • Bill aggregators
    • Without bill aggregators
  • Payments for government services (e.g. birth certificate)

14

15 of 47

Country Payment Infrastructure Scenarios

15

Scenario

Suggested approach

Scenario 1 - Regional Switch (or a switch of switches) connects financial service providers including banks and non-banks in different countries in a region. 

Government should leverage the regional payments switch (scheme) to enable all use-cases.  This may also imply important developments of a standardized Customer Due Diligence (CDD).

Scenario 2- A national payment switch connecting financial service providers such as banks and non-banks including mobile money providers is in place and actively working

Government should leverage the existing switch to enable payments use-cases to reach both banks and non banks inc. mobile money providers

Scenario 3 - A national payment switch is in place in the country or is in the process to be deployed but non-banks, including mobile providers are not connected to it

Government should leverage third-party aggregators to enable payment use-cases to reach mobile money providers

Scenario 4 - A payment switch is not place or in the process of being deployed

Government should leverage third-party aggregators or bilateral arrangements to enable payment uses-cases to reach mobile money providers

16 of 47

Country Payment Infrastructure Scenarios

16

Scenario

Suggested approach

Scenario 5 - Government makes G2P payments using Central Bank Digital Currency (CBDC) 

The Central Bank distributes the funds for the CBDC accounts via regulated entities (e.g. Payment Service Providers)

Scenario 6 - Citizens have CBDC accounts directly with the Central Bank or other accounts with other payment service providers

The Central Bank sets up limited accounts for each person, providing a base level of access and functionality.  Such accounts may be denominated in country currency (fiat) or CBDCs.

17 of 47

Interoperability

  1. Payments system interoperability is critical for a digital payments architecture.
  2. There may be one, government-owned and operated payment switch in a country managed as public utility or there may be multiple switches owned and operated by the private sector.
  3. In some cases the payment switch in one country could be acting as regional switch for neighboring countries facilitating settlements of cross border transactions.
  4. Interoperable infrastructure for bulk payments, agent transactions and payments which translates to higher number of access points and use cases for the beneficiary;
  5. Interoperability will also impact the distribution network and electronic acceptance network, allowing beneficiaries to use their account to withdraw funds independent of provider.

17

18 of 47

Key Digital Functionalities�

2

19 of 47

Key Digital Functionalities

  1. Payment Orchestration: Ensures end-to-end workflow across subsystems and asynchronous processing for diverse payment types and use cases.
  2. Voucher Management: Handles full lifecycle of vouchers, from provisioning to reporting.
  3. Account Lookup Services (Account Mapper): Identifies payee's Financial Service Providers (FSP) for secure payment routing.
  4. Payment Request Initiation: Allows both internal and external systems (e.g., other GovStack Building Blocks) to initiate payment requests.
  5. Payment Gateway: Facilitates interoperability among various Financial Service Providers (FSPs).
  6. Payment Portal: Enables users to manage complete cycle of sending and receiving payments.
  7. Event Management: Supports events that trigger specific actions based on payment outcomes.
  8. Reconciliation: Ensures financial account accuracy and consistency.

19

20 of 47

Key Digital Functionalities – BB Components

20

21 of 47

Logical Architecture

21

Source: Payments BB Architecture Implementation

22 of 47

Key Digital Functionalities: Account Mapper / Directory

  1. Maps Functional ID of beneficiaries to their payment modality and financial address.
  2. Maintain payment information for beneficiaries of G2P Social Benefit programmes in one location and can be easily updated.
  3. Supports multiple payment channels:
    1. Bank
    2. Mobile money
    3. Vouchers
    4. Payment alias
  4. Information is stored in tokenised format.

22

23 of 47

Functional Requirements�

3

24 of 47

Account Mapper / Directory

24

Beneficiary registration to the payments BB

Source: G2P Bulk Disbursement Report

25 of 47

G2P Bulk Disbursement

25

Source: G2P Bulk Disbursement Report

26 of 47

G2P payments flow – Option 1

26

Ministry and Department

Beneficiary

Payment Service Provider (PSP)

Treasury Single Account (TSA)

Treasury - FMIS

Payroll System

Pension System

Social Protection Payment System

FMIS

Central Bank

TSA

Bank 1

Bank 2

MMP1

Retail – Welfare

Payment Scroll

Retail – Payroll

Scroll

Retail – Pension

Scroll

Lumpsum Payment request

Retail Payment Info

Payment Gateway

Bulk payment

FMIS – Financial Management Information System

MMP – Mobile Money Provider

Access Point

ATM

Bank Branch

Post Office

Agent

Post

27 of 47

G2P payments flow – Option 2

27

Ministry and Department

Beneficiary

Payment Service Provider (PSP)

Treasury Single Account (TSA)

Treasury - FMIS

Payroll System

Pension System

Social Protection Payment System

Payment Portal

FMIS

Central Bank

TSA

Bank 1

Bank 2

MMP1

Retail – Welfare

Payment Scroll

Retail – Payroll

Scroll

Retail – Pension

Scroll

Retail payment Scrolls

Lumpsum Payment request

Retail Payment Info

Lumpsum Payment request

Payment Gateway

Bulk payment

FMIS – Financial Management Information System

MMP – Mobile Money Provider

Access Point

ATM

Bank Branch

Post Office

Agent

Post

Retail Payment Info Is accessed from the Payment Portal by PSP

28 of 47

External dependencies

  1. The merchant registry will be managed by another building block.
    • Merchant registry has details of registered merchants from whom vouchers can be redeemed (schools, hospitals, grocery stores)
  2. Beneficiary payment information and payment scrolls are created and validated by another block (including checks for fraudulent transactions).

29 of 47

Workflows�

4

30 of 47

G2P Bulk Payments

30

31 of 47

P2G Payments – Mobile Money / Bank

31

32 of 47

Cross Cutting Requirements�

5

33 of 47

Security BB

  • Transaction logging
  • Encrypted syslog server
  • Secured audit trail logging
  • Digital Certificates
  • Fraud detection
  • Secure audit logging
  • Privacy
  • Data encryption at rest and in transit requirements
  • End to end encryption and key management 
  • Protection against viruses
  • Virus, Ransomware, Malware, Spam, Phishing Protection Requirements

34 of 47

Additional requirements

Requirement

Relevant building block

Type (Must/Should/May)

Hardware Security Module or equivalent for secure data storage of sensitive data and transaction logs and to comply with data protection requirements.

Security

Must

Separation of concerns design 

Architecture

Should

Zero trust model applied to all components (always verify)

Security

May

Reporting

Requesting building block

Must

Compliance with applicable regulations and laws

All

Must

Merchant and beneficiary registration

Registry

Must

Account lookup and directory services MUST be available to resolve accounts

Must

High availability (Load balancing, infrastructure redundancy, backups)

Security

Should

Time synchronization across building blocks.

Security

Must

35 of 47

Service APIs�

6

36 of 47

Payments BB APIs

  1. Voucher disbursements
  2. Bulk payments – OpenG2P APIs
  3. P2G payments

37 of 47

Voucher APIs

VoucherPreActivation

  • Requests a single voucher from the voucher server that can be used for a future redemption process

VoucherActivation

  • This second function call is intended to ensure that the voucher is only activated when it is disbursed

VoucherRedemption

  • Used by the merchant interface for voucher redemption.

VoucherStatus

  • Used by other blocks to check the status of a voucher (redeemed, active)

VoucherCancellation API

  • Used to cancel an issued voucher.

38 of 47

G2P Payments (Outgoing government payments)

Onboarding to the account mapper

    • Register_Beneficiary

Triggered when uploading beneficiaries details into the Payments BB's ID Mapper.

    • Update_BeneficiaryDetails()

Used to when the updating beneficiaries into the Payments BB's ID Mapper.

Bulk disbursement

    • PrePayment_Validation()

Called by Source BB, retrieves eligible Functional IDs from the account mapper for credit transfers.

    • BulkPayment()

It will be called by the Source BB to handover a batch of credit instructions to be processed.

39 of 47

P2G payments (Incoming government payments)

Request to pay

  • Used by government entities through their online platform to request a payment.
    • The payments BB sends the request to the FSP for payer to approve the transaction.
  • The post request to the payments BB includes a reference ID, amount and payers account/mobile money number.

40 of 47

Infrastructure �Considerations�

7

41 of 47

Infrastructure Considerations

  1. Use of Foundational Digital ID to authenticate beneficiaries and users of the service
  2. Verification of eligibility of beneficiary for the service would be done in another block.
  3. Each G2P program need not maintain the payment and account information.
  4. Account directory/mapper maps recipients’ ID to their transaction account, allowing the government to address payments to a specific individual.
  5. The Account mapper should comply with the data handling and data protection legislations in force.
  6. Interoperability among FSPs, (different mobile money providers and banks) is important. This can be in place through a national payment switch, enabled by third-party aggregators or done on a bilateral basis

41

42 of 47

  1. National payment system is needed to support a G2P payments system
  2. A centralized treasury system, usually called integrated financial management information system (IFMIS), is used to process government payments against the budgetary allocations.
  3. The IFMIS supports
      • the treasury single account (TSA) that aggregates all incoming government receipts and disburses all government payments and
      • budget management to ensure budget compliance, tracking, and reporting.
    1. The TSA is either a single bank account or set of linked accounts through which the government transacts all its receipts and payments.

42

Infrastructure Considerations

43 of 47

Infrastructure Considerations

  1. Payment switches may not be accessible to all payment services providers including non-banks. Different scenarios are provided in the document to address the different payment system scenarios in different countries;
  2. For social protection G2P payments, social registries are an important building block in a recipient-centric digital G2P architecture.
  3. Social registries are information systems that support outreach, intake, registration, and determination of potential eligibility for one or more social programs. As such, they are the gateway to the inclusion of populations of interest into social programs. Multiple programs can leverage the same social registry (also called an integrated social registry) to identify potential beneficiaries, creating economies of scale and therefore government savings

43

44 of 47

Infrastructure Considerations

  1. To support G2P payments at scale, a good connectivity infrastructure with the following characteristics to ensure convenient access to and usage of payments for recipients is needed:
        • A stable connection to the mobile network is available to rural areas as well as urban.
        • Broadband connectivity is available and supports mobile Internet connection in rural areas as well as urban.
        • Access to the national electrical grid is nearly ubiquitous, and where it is not available, there are affordable and accessible off-grid options for recipients to charge phones and other devices.
        • Mobile phones of sufficient quality are affordable and accessible, with no perceivable gender gap in mobile phone ownership. While basic mobile phones are sufficient for most G2P payments at this time, smartphone ownership and Internet data plans are becoming increasingly affordable.

44

45 of 47

FAQ�

8

46 of 47

FAQ – Payments

  1. What is the current state of the country's digital infrastructure and broadband connectivity? (e.g., internet penetration, mobile coverage, broadband penetration, handset types in use, women access to mobile phones)
  2. Is there a national payments system in place that can be leveraged for Government payments?
  3. Is there interoperability between banks and non-banks financial service providers?
  4. Is there a centralized treasury system used to process government payments against the budgetary allocations?
  5. Is there a treasury single account (TSA) that aggregates all incoming government receipts and disburses all government payments?
  6. Is there appropriate legislation in place for data protection, privacy and handling of sensitive data of citizens such as payment account information and financial services transactions for government services?
  7. Is there a social registry database available that can be used to verify eligibility for social benefit programmes?
  8. Is there a foundational digital ID system in place that can be used to verify the identity of users?

46

47 of 47

FAQ– Payments

  1. Describe existing payment system infrastructure including how banks and non banks are interoperable (if at all), how G2P and P2G payments are currently being implemented and any national plans for digital payments and digital public infrastructure.
  2. Is there an account mapper infrastructure in place in the country as recommended by Payments BB for G2P payments?
  3. What policies and standards has government adopted for digital payments for G2P and P2G?
  4. What are the priority use cases for G2P and P2G?

47