/
2025-01-16 Payments BB WG Meeting notes

2025-01-16 Payments BB WG Meeting notes

Owned by Kibuuka, Arnold, created
Jan 30, 2025
3 min read

 Date

Jan 16, 2025

 Participants

  • @Kibuuka, Arnold

  • @Mauree, Venkatesen

  • @PSRAMKUMAR

  • @David Higgins

  • @Oscar Correia

 Goals

  • The primary purpose of the meeting was to discuss and finalize the multi-currency feature for the payment system.

 Discussion topics

Item

Presenter

Notes

Item

Presenter

Notes

Update on Workflows for multicurrency

@David Higgins

  • David is working on the draft. Once David finishes, it can be incorporated into the document. This will be a multi-step process because it needs to be sent to Arnold and then put on the GitBook. David shared his screen to show the progress. Link to document shared by David

Multicurrency


@Oscar Correia

The multicurrency functionality is intended for in-country transactions only and does not include cross-border transactions.

Two models were considered:

1) Independent Currency Model: Each transaction is processed in a single currency, without conversion.

2) Base Currency Model: All transactions are converted to a base currency.

Challenges: Multicurrency transactions introduce challenges related to exchange rates, regulatory compliance, accounting, infrastructure, risk management, user experience, institutional support, operational costs, scalability, data management, reporting, and security.

Decision: The independent currency model was chosen due to its simplicity.

The independent currency model assumes that the government will designate a single currency for all payments.

UI

@David Higgins

  • The existing specification does not include specific requirements for the admin UI.

    David presented two Options:

    • Maintain consistency and avoid adding UI requirements for multicurrency.

    • Develop a comprehensive set of UI requirements.

  • The preferred approach is to avoid adding new UI requirements and keep the UI customizable.

ID Mapper

@David Higgins @PSRAMKUMAR @Mauree, Venkatesen

  • It was established that the registration building block plays a crucial role in managing the interaction between the ID Building Block and the Payments Building Block. It uses the ID Mapper API to link foundational IDs to functional IDs and passes the necessary information to the Payments Building Block for payment processing.  

  • The discussion clarified that there is no duplication between the ID Mapper and the Account Mapper, as they serve distinct purposes and operate within different building blocks.  

  • The existence and importance of an API for populating the ID Mapper was confirmed, and the need for the registration building block to use this API during the beneficiary onboarding process was emphasized.

 Action items

@David Higgins Send the updated workflows to Arnold
@Kibuuka, Arnold Update the Gitbook with the new workflows once received from David
@PSRAMKUMAR Bring the questions related to the registration building block to the Technical Committee:
Should a program ID be associated with a single currency or allow for multiple currencies? This has implications for how functional IDs are generated and managed, especially in the context of G2P programs where beneficiaries may need to be paid in different currencies.
How does the multicurrency aspect affect the creation and management of functional IDs, particularly in scenarios where a beneficiary might have multiple functional IDs associated with different currencies within the same program?
What are the specific requirements and functionalities of the ID Mapper API that the Registration Building Block needs to utilize? This includes understanding how to pass the relevant information (program ID, foundational ID, currency) to the API to ensure accurate mapping of functional IDs
How can the Registration Building Block effectively coordinate with the ID Building Block and the Payments Building Block to ensure a seamless flow of information and functionality in a multicurrency environment?
Update the use case document to clarify that cross-border transactions are not in scope

 Decisions

  1. Use the independent currency model for multicurrency transactions
  2. Do not add UI requirements for multicurrency
  3. Have the registration building block invoke the API for populating the ID mappe