0. Decision metadata
Decision Title:
Extensibility of contextual requirements
Date:
Jun 25, 2025
Decision ID:
PAYMENT-WGDR-2025-06-1
Status:
OPEN
Decision Statement:
The Working Group decides
Responsible Owner(s):
Supporting References:
- 7.3.4 New Requirements Classification
- 7.3.5 Extensibility and Replaceability Rules
Voting Outcome (if applicable):
Voting and discussion was recorded on both supporting reference documents.
Notes (optional):
Use this field for clarifications, dissenting comments, or conditional aspects of the decision.
1. Context and problem statement
When evaluating the Payments version for Multicurrency payments, a separate document detailing the reasoning behind Multicurrency payments lived outside of the BB-Payments BB. This, along with requirements belonging to Multicurrency feature proposed as OPTIONAL requirements, due to the fact of their application being contextual to the implementation, and the elimination of “OPTIONAL” as a requirement category prompted us to evaluate if the Payments BB should be decomposed into extensions for specific use cases.
2. Decision Drivers
Vijay Mauree: Presently, multicurrency functionality is inbuilt in the system and is needed if the country wants to support different currencies for payments. It is a feature which is considered as an optional requirement within the payments building block and it requires only one additional field currency to be included and this is already in the APIs.
PS Ramkumar: The specs covers a lot of information for different scenarios (G2P,P2G,etc) and modalities(voucher/mobile wallet/central switch /etc.), which may need some common requiements but also different type of infra, functionality, protocols, policy support based on the scenario and the modality under considertation. Likewise single currency, multi-currency in-country and multi-currency cross border are different scenarios that are not relevant to all countries. When we are trying to familiarize a country with the payments BB our current spec seems overwhelming for a country. We need to think how to help a country can quickly zero down on the things that relate to its own realities, out of all the stuff in our specs. Hence I had made a suggestion to arch team as well as BB teams why not keep the common requirements in a main spec document, and put scenario specific / modality specific requirements, components, policies, workflows, assumptions, etc, as extensions to the main document. That way they are together in a loosely coupled set but can evolve independently as related policies, process, provisioning and practices change
3. Considered options
Option 1: Monolithic BB-Payments and requirements reclassification
Keeps the Building Block as-is. Reclassify multicurrency from 'OPTIONAL' to 'RECOMMENDED' within the existing payments building block. This revised status would be uniformly applied to all payment scenarios, including G2B, B2G, P2G, and G2P
Option 2: De-composable BB-Payments and multiple extensions
Maintains a core BB-Payments Building Block and writes small extensions for the following cases:
Currency: Single(done), multiple within country (doing) and cross-country (to be done for regional solutions)
Modalities: We also addressed different modalities (mobile/card/internet banking/centralized switch/ etc), each having their own mechanisms, protocols,infrastructure requirement, etc.
Transaction Type: We also have different protocols and mechanisms for G2P, P2G, G2B,B2G,G2G.