Sidebar

Welcome to OMG-CBDC WG Wiki Provide Feedback

cbdc:public:cbdc_omg:04_doc:20_comments:dsn:q20:start

Question: 20. How could a CBDC be designed to achieve transferability across multiple payment platforms? Would new technology or technical standards be needed?

Question

Return to Top

  • How could a CBDC be designed to achieve transferability across multiple payment platforms?
  • Would new technology or technical standards be needed?

Answer

Return to Top

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.

Table 1: Theoretical components of a Dual ACH / CBDC System
Note: The API could be in the form of Web Services, Remote Procedure Calls (RPC), Common Object Request Broker Architecture (CORBA), Data Distribution Service (DDS) or other interprocess communication mechanisms defined using ISO/OMG Interface Definition Language (IDL), standardized Web Services Interface Language (WSDL), etc.
Figure 1: Theoretical Very Simplified Dual ACH-CBDC Network Concept.

Examples

Return to Top

The “desirements” specified in White Paper and identified by the OMG's CBDC WG White Paper Analysis as achieving transferability across multiple payment platforms are listed in Table 2.

Table 2: Examples of achieving transferability across multiple payment platforms identified during the White Paper Analysis conducted by the OMG's CBDC WG.
Category Desirements
Benefits B0026, B0045, B0046
Policies and Considerations P0021
Risks
Design D0015
Note: B = Benefit, P = Policy, R = Requirement, D = Design.

Discussion of Examples

Return to Top

Table 3 provides discussion points for each of the “desirements” identified by the OMG's CBDC WG White Paper Analysis which apply to achieving transferability across multiple payment platforms.

Table 3:
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.

Note: The API could be in the form of Web Services, Remote Procedure Calls (RPC), Common Object Request Broker Architecture (CORBA), Data Distribution Service (DDS) or other interprocess communication mechanisms defined using ISO/OMG Interface Definition Language (IDL), standardized Web Services Interface Language (WSDL), etc.
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:
1. wages,
2. tax refunds
3. other federal payments

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
cbdc/public/cbdc_omg/04_doc/20_comments/dsn/q20/start.txt · Last modified: 2022/06/17 19:29 by terrance
Translations of this page: