Key Decision Log (Payments)
- Steve Conrad
Date | Decision |
|---|---|
| “Discovery service” also known as the “Account lookup service” in the payments BB components. |
| Direct bilateral connections between the state owned bank and the Financial services provider vs all connections going through a switch. |
| The Debit and credit entries for the treasury single account are out of scope of this document |
| The user interface for payments management will be managed through the payments portal. |
| Payments, reconciliations and settlements out of scope of the building block. |
| Sequence flow diagrams to the FSP were removed - |
24/Nov/2021 | G2P payments using Mobile Money - individual Disbursement Flow were removed |
01/02/2022 | All security requirements removed from the specification of the payments BB, security requirements are described in the security BB. |
01/02/2022 | A requirement to have a hardware security module was removed, data security is handled in the security BB |
07/02/2022 | Account mapper and the account lookup service to be discussed in detail in phase 2 along with considerations for use of federated IDs with considerations for user privacy. |
Comments and corresponding replies from the payments BB are shown in the tale below
No. Comments/Feedback Suggested Action/Reason
1 Payments BB has core requirements called out. However, the Voucher mgmt system can be made more generalised. One powerful feature that facilitates generic characteristics in the VMS in the specification is the use of voucher groups. These groups can restrict the use of vouchers to certain functions, geographies and merchants. One extension we could do is to add a custom field to the Voucher Management System API so that the calling Building Block could submit data regarding how the voucher is to be used and by whom. However, as per the use cases the voucher initiation and redemption are triggered by other Building Blocks so this data is actually collected by the calling Building Block. In terms of the final delivery of the voucher this in control of the calling Building block
2 Payments from other BB perspective (and from citizen perspective) is to integrate to the payment service to avail a govt service Unclear comment - payments is handling all government related payments and disbursements.
3 It may be a good idea to separate Payment BB into two logical parts - a) as payment integrator b) as core building block to support payments at country scale. The payments building block is focusing on enabling the digitization of the different types of payment modes for government services.
4 Generally, we have a paying side (Payer) and a receiving side (Payee)? Why diversification (P2G, B2G, etc.)? The payment processes are different for each of the payment types B2G and G2B, P2G etc.
5 Section 3.What if the user of the service wants or for some reason paid physically / in the traditional way and not electronically? In a G2P, the beneficiary “user” can be paid with a physical voucher if they don’t want to receive electronic payments. A voucher can be cashed out.
6 Section 3.What exactly does that mean? Is it validation against the budget of the organization? In public administration it is better to use terms like a budget or allotment or something like that (see IMF GFSM, for example). The term "operating cost" might be confusing Yes, it means validated against the budget before payment is made. correction in section 3 to allotment instead of budget.
7 Generally we have a paying side and a receiving side? Why diversifikation (P2G, B2G, etc)? The payment processes are different for each of the payment types B2G and G2B, P2G etc.
8 Should include also G2G as governmental institutions are paying taxes as well These will probably be considered in the next phase of the payments BB G2G are out of scope in this version
9 3.1 Introduction to financial inclusion, banks and mobile money accounts: Does it have to be in spec? I suggest specification contains only normative information
10 Should include G2G as well G2G will be addressed in the second phase
11 Our sense is that this BB is focussed on developing countries - more developed countries will have Direct banking arrangements e,g, taxation authorities, social welfare systems. It is likely we will adopt a very light approach for more incidental digital financial transactions To clarify more on the above please note we are not focusing on only emerging economies. We are have considered different levels of maturity from developing and developed countries i.e from paper vouchers to central bank
12 what does this mean for PBB.. it may not be advisable to share the gender information for payment info based on minimalism principle. The payments building block should ideally be blind to this. PBB - payments building block, this was corrected.
13 which information and how would the payments BB know the requirements of different services which use this shared payments BB? this requirement can be made more specific maybe?
14 | Section 5.2 what does this entail? interaction with the payee to verify account details? could there be privacy or security concerns?What does this entail? interaction with the payee to verify account details? could there be privacy or security concerns? | There is no interaction with the payee involved in this, the Account Lookup Services (ALS) in the payments BB will be called to verify the payment information provided by the payee before the payment is made. |
15 | Section 5.4: any requirements on accounting or reporting of vouchers for different processes listed (provisioning, issuance etc.) .. reconciliation of funds based on redemption? What about the authentication of the beneficiary at the time of activation/redemption ? | These are all good and valid questions.
|
16 | 7.1.2 Payment orchestration in the second wave of BB-s there is a Workflow BB. Probably this part can be delegated to the Workflow BB | The payments BB orchestrator handles the microservices interactions within the BB as there are several components for bulk processing, voucher management, Account lookup service. This is an internal orchestration of workflow in the payments BB. it might embed an appropriate workflow component to realise this orchestration |
17 | Voucher management: I did not see support for redemption in the Registration BB. There is only a voucher issuing process. How exactly redemption will work? who will withdraw actual funds from the Treasury account and when? | where the authentication of the beneficiary is required, the merchant authenticates the beneficiary through the registration bb. |
18 | Account lookup directory service What is the interface for the users or payment providers to update this mapper e.g. update their account number /bank name/FSP/or even personal identification number ? Who all can access this ? | The user cannot update the mapper directly. When the user makes changes to their account, (e.g. switches from one FSP to another FSP), it is the FSP who will update the mapper. |
19 | In case of payment of taxes P2G and B2G there is a need to reconcile individual ID/company ID and tax type or even document (in case of Customs clearing). How such reconciliation is supported? | Out of scope of the BB |
20 | if this would be a request to collect a tax due then I do not see a data field for automatic reconciliation of this payment with outstanding liability in the tax administration accounting system. | Tax administration and accounting are out of the current scope for the payments BB. |
21 | what kind reference ID it is? issued by whom? | This payment transaction ID issued by the registry |
22 | in case tax and customs duties payment, I guess, there are no Registration BB but some other BB or how? | This will be considered in future scope |