| |
|---|
| Soban Najam clarified that while the API specs hadn't yet been ported to Swagger, this would be the next step once the interfaces were finalized. @Soban Najam walked through the G2P bulk disbursement process, from the receipt of a request by the Payments Hub to the disbursement completion. The system involves a "payment building block" that manages instructions from source building blocks and passes these instructions to relevant financial institutions. The financial institutions are the entities where funds may need to be routed to for processing. The "sponsor institution" or "TSA" is where the allocation of funds happens; it could be a central bank or a commercial entity. A Get Authorization API is in the works, which would allow the entity allocating funds to give authorizations via APIs, although this process may have to work manually in some jurisdictions. The payment building block also works with an "account mapper", an entity that holds details of beneficiaries and their financial addresses. Payments are divided into "sub-batches" based on modality or bank identification codes, assuming they are available. A third party, known as a "pair bank" is used to route instructions to the receiving bank (payee bank), as the system doesn't have the mandate to go directly to the payee bank. The "pair bank" can also do similar batching if required, although ideally, there would be a single approach. Transaction statuses are updated asynchronously to account for possible delays in processing at the "pair bank"
@PSRAMKUMAR pointed out that any application satisfying the API criteria should be able to interface with it, not just the registration building block.
|
Implementation of the APIs facilitating payment flows and the optional validation steps involved.
| @Soban Najam explained the context of two parts in a payment process: the pre-validation step and the bulk payment instructions. The pre-validation step, while optional, is recommended as it aids in managing liquidity and could be crucial in a liquidity-strapped environment. For each payment instruction, there are four necessary components - a functional ID, an amount, a narration (optional), and a GUID for individual instruction identification. When the payments building block is invoked, they undergo a de-bulking process, examining the functional ID for each beneficiary. If a beneficiary's functional ID is not found, it's recorded as a failed instruction and the payer bank is invoked, which leads to bulk validation. Vijay Vujjini suggests that a preemptive fail-fast mechanism might be feasible if the mapping lookup has the ability to resolve with the pay bank. He also added that different countries may have various capabilities due to their level of financial maturity. However, Soban Najam highlights a few issues with this approach, primarily that it assumes they have access to all pay banks directly, which is not necessarily the case. It was agreed that having the option to validate either with the payer or payee bank would be ideal, but it depends on several factors, including the capabilities of the bank and administrative and business considerations. They also discuss the scenario where prepayment validation is bypassed, and errors are only known when a bank refuses a transaction. The discussion focusing on certain technical aspects of payment processing and information storage. @Soban Najam explains that they do not store pay bank information. Validation is done via the pay bank or directly with paybacks, but the status of these transactions is not stored; instead, it is passed back to the source building block @PSRAMKUMAR queried the technical possibility of the Payment Building Block identifying the payee bank before sending a bulk validate account request. @Soban Najam explains this process using the Account Mapper and the Financial Address table, where the beneficiary's financial address and an FSP identifier are stored at the time of registration, thereby identifying the payee bank. The information about the payer bank is not stored in the Account Mapper. It is part of the configuration in the payment building block and is located in the Payment Hub. This information is derived pre-configuration, and not in real time through APIs. The process flow of the payment system, from the validation stage to the authorization process. This involves the payment building block interacting with the payer bank, which could potentially be a manual step in places where sufficient infrastructure doesn't exist.
Vijay Vujjini brings up the point of the payment building block's potential interactions with other systems, especially from a macro view. He also proposes the flexibility of the API to accommodate different scenarios and the traceability for accounting purposes. @Soban Najam challenged related to uniquely identifying institutions in the private sector and the issue of no such unique database existing. He highlights that these problems relate more to fund allocation and authorization flows, rather than API limitations
Vijay Vujjini suggests two key features for the bulk instruction request: scheduling time (immediate vs. delayed payments) and a purpose/scheme code for system integration. Vijay Vujjini also brings up the topic of the APIs being asynchronous, which Najam clarifies by stating that immediate acknowledgments are given upon request but actual logic is defined across different endpoints, and the actual business response comes later
|
Scheduling | Soban Najam explains the base assumption that the payment building block does not schedule payments; instead, it processes transactions immediately when the bulk payment interface is invoked. @PSRAMKUMAR agrees with this and adds that if scheduling is needed, a scheduler building block would handle it. The payment building block, on the other hand, simply processes payments at the earliest possible time upon receiving instructions. @Soban Najam introduces a bulk payment API, explaining it in detail including its components like registering institution, batch ID, and credit instructions. Then he talks about the authorization process for the transactions.
|
Security | Vijay Vujjini further asks about the security measures in place, specifically digital signature and encryption. Najam talks about the presence of digital signatures and the use of tokenization for data at rest. @Soban Najam also suggests that HTTPS, TLS, and other security considerations are in place for data in flight. However, the specifics of the configuration for the signatures are not detailed in the conversation but can be provided later. Vijay Vujjini suggests that instead of relying only on transport layer security (TLS), considering encryption at the data payload level would add an additional layer of security and flexibility. Najam questions the feasibility of this, citing potential additional costs and the need for a shared Public Key Infrastructure (PKI) among participants. Vujjini responds by suggesting that the specification should at least allow for such a setup, even if it's not immediately implemented.
|
Design and operation of a payment infrastructure | The importance of addressing system specifications based on the needs and requirements of individual countries was highlighted. @Soban Najam discussed the concept of a status push interface in the payment infrastructure, which is invoked by the payer bank and provides detailed information about payment instructions. This system does not only handle failed instructions but provides an overview of all transactions, stating whether they are posted, pending, or unpostable. The participants suggested having both push and pull mechanisms to ensure the system works efficiently, even during asynchronous exchanges where message losses might occur due to internal implementation issues. The conversation touched upon the need for pagination, especially when dealing with large files or millions of batch instructions. @Soban Najam stated that they had considered this, assuming a limit to batch size and the creation of multiple batches in cases of abnormally large numbers. A need to clearly state prerequisites was also highlighted to help users understand the system better. The importance of having a reason code for failure in immediate acknowledgement. It was suggested that policies should be fortified and immediate acknowledgement should flag if the message size is larger than the acceptable level. The concept of using push notifications in the payment building block was brought up. In this system, an API would be invoked by the payer bank to push the updated status of all instructions. A suggestion to include an API for the source to check the status with the payment building block, in scenarios where a payroll system might send a set of instructions every month end and would need to know the status of these instructions from the payment building block.
|
AOB | @Soban Najam acknowledges that a certain feedback mechanism isn't currently included in the specifications, but agrees to consider it. Vijay(G2P) mentions that they've made progress in terms of alignment and convergence in solutioning and unbundling from a building block perspective. He also mentioned about an update related to G2P and social protection standardization activity. They're looking to converge different standards, with an emphasis on non-functional architectural principles in API design.
@Mauree, Venkatesen appreciated Vijay's input and suggested @Soban Najam reviews the documents in more detail, and perhaps arrange a follow-up meeting. Vijay reaffirms that their aim is to start converging the specifications, believing that adoption will dictate the success of the solution. They also plan to establish a sandbox for G2P Connect, but this could be integrated with other entities if there is a convergence. |