1 of 20

Payments Building Block Scenarios beyond G2P and P2G

2 of 20

Overview

  1. Synopsis
  2. Scenario Definition
  3. Example Scenarios
  4. API to Use-case Mapping
  5. Conclusions

2

3 of 20

The first versions of the Payment Building Block specifications considered G2P (Government to Person) and P2G (Person to Government) scenarios/use-cases. However, there are a wider set of use-cases that should be considered 

  • Government to Business (G2B)
  • Business to Government (B2G)
  • Government to Government (G2G)

There are also use-cases beyond those that a Government would not participate in, and these are not considered for this reason

  • Business to Business (B2B)
  • Business to Consumer (B2C)
  • Consumer to Business (C2B)

3

Synopsis�

4 of 20

2

Scenario Definition

  • Government to Business (G2B)
  • Business to Government (B2G)
  • Government to Government (G2G)

5 of 20

Government to Business (G2B)

The broad definition of this scenario is payments made to a business from a Government, these are assumed to be single currency. These can be narrowed down to a set of high-level areas:

Loans – Where the Government makes a payment to a business with an expectation of repayment in whole or in parts with or without interest.

Allowances- Where the Government makes a conditional payment to a business. E.g. Agriculture allowance.

Unconditional Payments- Where the Government makes an unconditional payment to a business. E.g. disaster relief.

Rebates and Repayments – Where the Government makes a payment based on payments previously having been received, e.g. tax refunds.

Payments for Services - Where the Government pays a business for a service or work done.

Financial Aid to NGOs - Where the Government pays an NGO financial aid

Subsidies - This could be considered similar to Allowances but may bring in a dimension of being ringfenced in what it can be spent on or which merchants it can be spent with. This may bring in an element of Vouchers for consideration.

6 of 20

Business to Government (B2G)

The broad definition of this scenario is payments made from a business to a Government. These can be narrowed down to a set of high-level areas:

Loan Repayments – Where the Business makes a repayment to a Government either in whole or in parts with or without interest.

Taxation – Where the Business makes a payment to the Government to cover a taxation obligation either one off or regular.

Services - Where the Business makes a payment to the Government for a service either one off or regular such as refuse collection.

Fines - Where the Business makes a payment to the Government to cover a fine

Customs Duties - Where a Business needs to pay customs duties (this scenario really opens up consideration of cross border and forex)

It may be important to consider cross-border/multi-currency payments depending on if the business is in the same country/region as the government.

7 of 20

Government to Government (G2G)

The broad definition of this scenario is payments made from a Government to a Government. These can be narrowed down to a set of high-level areas:

Department to Department – Payments between Government departments.

Authority to Authority – This could be national to local Government or between country Governments

Within these you have a number of potential complexities to consider:

Currency/Multi-currency

Invoice/Event Driven

Cross- Border

Conditionality

Cross Border payments – where a payment may cross a network/regulatory boundary regardless of currency

Multi-currency payments – where the payments cross currencies and some conversion needs to occur

Conditional/Non-Conditional payments – are payments requiring a condition check or not

Disbursement vs Invoiced payments – are payments in response to an invoice (including RTP)

Budgets/Allocations - Do we need to distinguish between them?

Revocability - Currently we consider all transactions irrevocable does this still apply

8 of 20

3

Example Scenarios

  • Government to Business (G2B)
  • Business to Government (B2G)
  • Government to Government (G2G)

9 of 20

Government to Business (G2B)

To be focused on specific examples

Insert Flow Diagram

Volunteers with real use-cases wanted

Notes from call 25/6 add in:

Need to be end to end flows e.g. all building blocks -->PBB 🡪 Wallet

Must have an end user.

10 of 20

Government to Business (G2B)

Mifos Submission: Example of a loan workflow.

Assumptions:

  • That the loan scheme is not part of the Pay BB (could be an independent system or BB that is yet to be defined)
  • KYC - “Know your Customer” is inclusive of KYB “Know your Business”
  • This is giving an example loan scheme but is not inclusive of all steps within that as we are not defining the loan-scheme in this BB
  • This example covers a normal Business type loan, it is not intended for guarantee loans where the Government is not the loan provider
  • All interactions with the Payment BB will go via the IMBB as per GovStack specification even where not shown for clarity in the workflow
  • Messaging or Schedular BB’s could be used when defined for notifications and loan schedules

Covers:

  • Registration of a Loan Scheme
  • Loan Setup and Payment
  • Loan Repayment flows

Excludes:

  • Audit
  • Most unhappy path flows
  • Detail of Loan system internal flows

Disclaimer - This represents a contribution of Mifos until adopted by the Payments Building Block

11 of 20

Government to Business (G2B)

Mifos Submission: Example of a Loan Workflow:

Key Callouts:

  • There may need to be 2 ID’s verified, that of the Business and that of the Individual acting on behalf of the business (TO BE EXPLORED).
  • IDBB currently only considered individual ID therefore this has an impact on the current IDBB specification
  • Currently in the workflow existing Pay-BB API definitions can be used (needs to continue to be assessed with any changes)

Disclaimer - This represents a contribution of Mifos until adopted by the Payments Building Block

12 of 20

Business to Government (B2G)

To be focused on specific examples

Insert Flow Diagram

Volunteers with real use-cases wanted

13 of 20

Government to Government (G2G)

To be focused on specific examples

Insert Flow Diagram

Volunteers with real use-cases wanted

14 of 20

4

API to use-case mapping

  • Government to Business (G2B)
  • Business to Government (B2G)
  • Government to Government (G2G)

15 of 20

Government to Business (G2B)

Explore if they need any different API calls. Assumption is that in most cases the Business could be defined as a beneficiary and that use-case complexities would more hit other BB’s such as Identity and Registration.

Loan functionality is probably a specific use-case as it’s a hybrid of G2B and B2G, may require some specification around loan interfaces if we want to consider in scope.

16 of 20

Business to Government (B2G)

Explore if they need any different API calls. Assumption is that in most cases the Business could be defined as a beneficiary and that use-case complexities would more hit other BB’s such as Identity and Registration.

Loan functionality is probably a specific use-case as it’s a hybrid of G2B and B2G, may require some specification around loan interfaces if we want to consider in scope.

Consider if always event driven e.g. can it fit the current P2G Invoice or RTP models.

Is there any complexity for a government to consider around calculating taxation that’s relevant for the BB gut says that’s for the taxation system.

17 of 20

Government to Government (G2G)

Highly complex and probably needs clear definition due to the impact of cross-border and multi-currency. This will segway nicely to alignment with Oscars workstream and links should be called out.

At some level we would need to consider if the BB is the right place. E.g. most of these transactions probably just fit in a class of one off or variable transactions that would normally be handled by the Governments Bank/Payment System. What benefit is there for them in using the Payments BB for orchestration.

18 of 20

5

Conclusions

  • Conclusions
  • Design Considerations

19 of 20

Conclusions

To

Be

Updated

To be updated once we have completed all mappings

20 of 20

Design considerations

Next steps for any identified gaps

To be updated once we have completed all mappings