Payment BB: B2G ,G2B and G2G Use-cases
In 2024/2025 the Payments working group has expanded its use case focus to look at Business to Government (B2G) payments and Government to Business (G2B) payments. At some point this may be extended to Government to Government (G2G) payments but at the moment that work is paused beyond the definition below due to complexities of cross-border payments.
The use cases described here are compatible with either single or multi-currency modes of operation for the payments building block.
This work should be considered draft and work in progress until formally adopted by the Payments Building Block Working Group.
Government to Business (G2B)
Overview:
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.
Example Workflows:
1. Example of a Government to Business Loan
In this example the Government has a scheme where they provide loans to small businesses on preferential terms to encourage small business development. This example could also apply to small business loans needed for disaster recovery (The UK offered such loans during Covid19).
https://miro.com/app/board/uXjVKysC8uo=/?share_link_id=804094628658
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
Workflow covers:
Registration of a Loan Scheme
Loan Setup and Payment
Loan Repayment flows
Workflow excludes:
Audit
Most unhappy path flows
Detail of Loan system internal flows
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)
Business to Government (B2G)
Overview:
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.
Example Workflow:
1. Example of a Business paying for Government services- Refuse Collection
In this example the local Government provides a refuse collection service to local businesses this consists of both regular collections and the ability to request additional collections. These services are chargeable by the local Government to the local businesses.
If we look at the existing Person to Government (P2G) payment usecase we see that within this the flows are agnostic of if the Payer is an individual or a business and the ID of the Payer is not within the flows or APIs resolving the concerns that arise in G2B payments that need changes to cater for business scenarios.
Final Versions of Key Documents | P2G v16Oct23
Hence we can conclude the following flows would be used:
For the regular bills these would follow the Bill Generation and Bill Inquiry workflows with Bills being sent from the Billing Entity to the Payer who would pay with the reference supplied enabling the Payment BB to reconcile the payments to the Billing table.
For the one off charges this would follow a one-time Request to Pay workflow from the Billing entity to the Payer.
The use of a billing aggregator could also be supported for G2B payments without any adjustments foreseen.
Government to Government (G2G)
Overview:
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:
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
These are represented by these axis of contention
Further consideration of G2G will occur after B2G and G2B due to these complexities in particular Cross-Border.
Requirements and Considerations for other BBs
During the exploration of these use cases have identified some elements that need consideration by other BBs
Requirement and Considerations to Identity Building Block
Currently the functional ID provided by the Identity Building Block to the Payments Building Block is based on the foundational ID of the Individual, there is no considerations for an equivalent foundational ID for a company.
For both G2B and B2G transactions a functional business identity will be needed which can be mapped to the appropriate financial details for the company and stored in the Payments BB ID Account Mapper (see current specification for function of this module). This functional business ID would be key to workflows between the registration BB or source BB and the Payments BB
Similar to how a Individuals functional ID is provided unique for the combination of a Program and Individuals Foundational ID it is assumed that a Business Functional ID that will be provided by the ID BB will be unique for the combination of a Program and a Business Foundational ID.
To this extent it means a Business Functional ID is unique to a program and a Business Foundational ID may be mapped to multiple Business Functional IDs based on the number of programs they participate in.
The source of the Foundational ID for a Business is the accountability of the ID BB but a suitable form may be the government company registration number.
Although the Payments BB does not require any mapping between authorised representatives of a company’s individual ID and the company ID. This may be a valid requirement from the Registration or Source BB in most workflows. Whether this function should exist then within the ID BB or a Registry BB is probably appropriate for discussion between those BBs.
Requirements and Considerations to Registration Building Block
Currently Payments considers the Registration Building Block the source building block in the case of G2P payments. Managing the eligibility and registration of individuals to an eligible payments program. Similarly for G2B we consider the Registration Building Block to be the source building block in the case of G2B payment ensuring eligibility and registration of businesses to an eligible payments program.
For the example of G2B loans, the Registration Building Block would be a system such as the Government Loan System.
For the example of B2G payments, the Registration Building Block may be a Government Bill and Invoicing function.
Where details need to be updated e.g. payment details pertaining to a company. The process by which such information is gathered and the authentication or validation of the users rights to update such information are outside of the Payment BB responsibilities. The Payments BB will execute any update instruction from a valid Registration or Source BB for a program (this remains the same for G2B and B2G as currently exists for G2P and P2G). We do however suggest though that there may be an additional consideration that the Registration or Source BB will have to take in the case of an update that was not considered for G2P and P2G and that is whether an individual has the right to update the details, this may require some form of registry of valid individuals and permitted changes for a business.
Requirements and Considerations to Messaging Building Block
Consistent with G2P and P2G use cases. For G2B and B2G currently the workflows do not require any messaging between the Payments BB and a recipient outside the Government. But indications are given in the workflow where such messages may be required from the Registration or Source BB.
The payments BB does not currently hold any information on messaging preferences, or messaging addresses, these are assumed to be within the Registration or Source BB and not needed by the Payments BB. This approach is extended to G2B and B2G
Requirements and Considerations to Registries Building Block
Although the Payments BB does not require any mapping between authorised representatives of a company’s individual ID and the company ID. This may be a valid requirement from the Registration or Source BB in most workflows. Whether this function should exist then within the ID BB or a Registry BB is probably appropriate for discussion between those BBs.