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

Return to Design Considerations	<b> <a href="mailto:cbdc-feedback@omg.org?Subject=OMG's CBDC WG Response: Question: 20. How could a CBDC be designed to achieve transferability across multiple payment platforms? Would new technology or technical standards be needed? ">Provide Feedback</a></b>

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 provides the system components of a very simplified, theoretic ACH / CBDC network. Figure 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.

Theoretical components of a Dual ACH / CBDC System Development of a U.S. CBDC is probably based on Stablecoin Model.Use of an energy-efficient Consensus AlgorithmDevelopment of a bridge between the existing Automated Clearing House (ACH) Network and the new U.S. CBDC NetworkDevelopment of a new standardized Application Programming Interface (API) to connect the outside world to the newly enhanced combined ACH Network and CBDC Network for the existing intermediaries to use for transfersNote: 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.

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 .

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 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.

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 refunds3. 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 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