This is an old revision of the document!
By using a system designed roughly as outlined in section 4.7 Dual Payment Networks, much of the current infrastructure would remain in place and to achieve transferability across multiple payment platforms would be very little different than the current system.
Table 1 provides the system components of a very simplified, theoretic ACH / CBDC network. Figure 1 graphically shows a theoretical, very simplified, dual ACH-CBDC Network Concept. A newly developed Application Programming Interface (API) and a specialized bridge going between the existing ACH Network and the new U.S. CBDC network would allow the existing platforms to work fairly seamlessly.
The existing Intermediaries would have time to adopt and adapt to the new API and use a “stubbed out” bridge as a first step toward the support of the U.S. CBDC in the future. The API and “stubbed out” bridge would connect to the existing ACH Network. As the CBDC network comes online, the existing Intermediaries would be able to join. This would allow a phased roadmap for the transition. New Intermediaries would start using the new API and the new U.S. CBDC network when it becomes available.
The “desirements” specified in White Paper and identified by the OMG's White Paper Analysis as achieving transferability across multiple payment platforms are listed in Table 2.
Category | Desirements |
---|---|
Benefits | B0026, B0045, B0046 |
Policies and Considerations | P0021 |
Risks | |
Design | D0015 |
B
= Benefit, P
= Policy, R
= Requirement, D
= Design.Table 3 provides discussion points for each of the “desirements” identified by the OMG's White Paper Analysis which apply to achieving transferability across multiple payment platforms.
Desirement No. | Desirement Text | Comment |
---|---|---|
B0026 | Provide a bridge between legacy and new payment services | The Dual ACH Network and U.S. CBDC Networks presented provides a bridge between the two networks. In order to be used effectively, the use of a standardized Application Programmer Interface (API) is also recommended.
|
B0045 | Enable rapid and cost-effective payment of taxes | The Internal Revenue Service (IRS) would be required to support the ACH/CBDC API and Bridge to make this happen. It is beyond the control of the Federal Reserve. |
B0046 | Enable rapid and cost-effective delivery of:
| This would require the employers, the U.S. Benefits agencies, and the Internal Revenue Service (IRS) to support the ACH/CBDC API and Bridge to make this happen. |
P0021 | The intermediaries would operate in an open market for CBDC services | Currently, the Intermediaries operate in an open market that is confined by the Laws and Regulations of the U.S. and Foreign governments when applicable. The proposed Dual ACH/CBDC networks would allow the existing Intermediaries to participate in the CBDC services as long as they are compliant with the standardized Application Programmer Interface (API) and Bridge. The proposed Dual ACH/CBDC networks would also allow new Intermediaries to only offer CBDC services. |
P0023 | CBDC would need to be readily transferable between customers of different intermediaries | As long as the Intermediaries use the standardized Application Programmer Interface (API) and Bridge, all transfers between Intermediaries is possible. |
D0015 | Design should include any dedicated infrastructure required to provide resilience to threats such as operational disruptions and cybersecurity risks | The Dual ACH/CBDC Networks would require the new infrastructure for the Application Programmer Interface (API), the bridges, and the building out of a Distributed Network of Nodes to handle the CBDC transactions and Consensus. The network of nodes might have any number of node types. Figure ##REF:typesOfNodes## describes the taxonomy of DIDO Node Types. See OMG DID-RA Node Taxonomy for a discussion on the different kinds of nodes. |
B = Benefit Considerations |
||
P = Policy Considerations |
||
R = Risk Considerations |
||
D = Design Considerations |