====== 4.7 Dual Payment Networks ====== |< 100% >| | [[cbdc:public:cbdc_omg:04_doc:15_common:start| Return to Common Elements]] | Provide Feedback | ===== Overview ===== [[cbdc:public:cbdc_omg:04_doc:15_common:70_dualnets:start| Return to Top]] : **Note:** Also see: * [[cbdc:public:cbdc_omg:04_doc:15_common:45_privacy:start]] * [[cbdc:public:cbdc_omg:04_doc:15_common:48_natsec:start]] * [[cbdc:public:cbdc_omg:04_doc:15_common:50_international:start]] * Answer to [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q04:start]] The simplest way to add a U.S. CBDC would be to build a parallel payment transaction network to the existing [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:ach | Automated Clearing House (ACH) Network]]. The existing payment network would continue to function //"as-is"//, while the new real-time U.S. CBDC Network would handle payment transactions using the U.S. CBDC (probably a Stablecoin). : **Note:** The ACH has embarked on its own support for real-time transactions with [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rtp | Real-Time Payments (RTP) Network]]. This should not be confused with the Stablecoin or other Crypto solutions. Both networks would rely on the existing intermediary financial institutions to continue to do what they already do in terms of [[cbdc:public:cbdc_omg:04_doc:15_common:45_privacy:start| Privacy]], [[cbdc:public:cbdc_omg:04_doc:15_common:48_natsec:start| National Security]], and [[cbdc:public:cbdc_omg:04_doc:15_common:50_international:start | International Security]] BUT with the addition of the ability to use a real-time U.S. CBDC transfer mechanism instead of only the existing [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:ach | Automated Clearing House (ACH) Network]]. This allows the existing mechanisms that are part of the existing intermediaries structure to remain in place for Privacy and Security. This of course assumes the existing mechanism on Privacy and Security is acceptable. However, it would also be possible for new financial intermediaries to startup but they would only be allowed to use the U.S. CBDC payment network. These new financial intermediaries would **NOT** be released from following the existing Laws and Regulations of the traditional financial intermediaries. In other words, they would have to ensure the End User's privacy (both ends of the Payment Transactions. They would also have conform to all the [[cbdc:public:cbdc_omg:04_doc:15_common:48_natsec:start| National Security Laws and Regulations]]. If either End User in the Payment Transaction is not in the U.S., they would have to abide by all the [[cbdc:public:cbdc_omg:04_doc:15_common:50_international:start| International Laws and Regulations]]. This would mean these new Intermediaries would be subject to oversight and auditing. The new U.S. CBDC network handles the real-time transaction requirements of the U.S. CBDC. This requires the: * Development of a U.S. CBDC is probably based on Stablecoin Model. * Use of an energy-efficient [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.k_consensus:start | Consensus Algorithm]] * Development of a **bridge** between the existing [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:ach | Automated Clearing House (ACH) Network]] and the new U.S. CBDC Network * Development of a new standardized [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:api | 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 transfers : **Note:** The [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:api | API ]] could be in the form of [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:w:web_service| Web Services]], [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:rpc | Remote Procedure Calls (RPC)]], [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:corba | Common Object Request Broker Architecture (CORBA)]], [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dds | Data Distribution Service (DDS)]] or other interprocess communication mechanisms defined using [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:idl&s[]=idl | ISO/OMG Interface Definition Language (IDL)]], [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:w:wsdl | standardized Web Services Interface Language (WSDL)]], etc.
Theoretical components of a Dual ACH / CBDC System
==== The Dual ACH/CBDC Payment Networks ==== [[cbdc:public:cbdc_omg:04_doc:15_common:70_dualnets:start| Return to Top]] Figure {{ref>simpleCbdcFlow}} provides a very simplistic overview of how a Dual ACH/CBDC network might work. The intention is to build onto the existing financial system already in place but to allow an option to use a U.S. CBDC probably built as a Stablecoin. The Existing Intermediaries would still fulfill their existing roles while providing an option to use a CBDC network to transfer the money. The existing validation and verification for the number of transactions, the quantity of money transferred, and all of the checks for criminal activity and assurance for privacy would stay in place.
{{ cbdc:04_doc:15_common:70_dualnets:screen_shot_2022-04-20_at_2.53.28_pm.png?700 |}} Theoretical Very Simplified Dual ACH-CBDC Network Concept.
^ Scenario ^ Step Number ^ Description ^ ^ Current Process ^ 1 | The First End User (Person, Corporation, Institution, a Computer process, etc.) goes into an Existing Intermediary and wants to transfer money to a Second End User. | ^ ^ 2 | The First Existing Intermediary uses the newly U.S. CBDC [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:api | Application Programming Interface (API)]] to start the transaction. The First Existing Intermediary asks if the money is to be transferred immediately requiring U.S. CBDC or if it will just be done using U.S. Dollars. | ^ ^ 3 | The First End User responds that they will be using U.S. Dollars. | ^ ^ 4 | A transaction is created that meets the requirements of the ACH is formulated. | ^ ^ 5 | The ACH Transaction is placed onto the existing ACH Network and routed to the appropriate Second Existing Intermediary. | ^ ^ 6 | The Second Existing Intermediary receives the transaction and waits for the transaction to settle (usually within 24 hours). | ^ ^ 7 | The Second Existing Intermediary places the money designated in the transfer transaction to the Second End User's bank account (i.e., debit, credit, checking, savings, Credit Card account, etc.) | ^ ^ 8 | The Second End User possesses the money. | ^ Scenario ^ Step Number ^ Description ^ ^ U.S. CBDC Process ^ 1 | The First End User (Person, Corporation, Institution, a Computer process, etc.) goes into an Existing Intermediary and wants to transfer money to a Second End User. | ^ ^ 2 | The First Existing Intermediary uses the newly U.S. CBDC [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:api | Application Programming Interface (API)]] to start the transaction. The First Existing Intermediary asks if the money is to be transferred immediately requiring U.S. CBDC or if it will just be done using U.S. Dollars. | ^ ^ 3 | The First End User responds that they will be using U.S. CBDC. | ^ ^ 4 | The First Existing Intermediary verifies that the First End User has the correct amount of U.S. CBDC to complete the transaction. If Not, the First End User can convert some existing U.S. Dollars to U.S. CBDC to complete the transaction. | ^ ^ 5 | A transaction is created that meets the requirements of the U.S. CBDC is formulated. | ^ ^ 6 | The U.S. CBDC Transaction is placed onto the new U.S. CBDC Network and routed to the appropriate Second Existing Intermediary. | ^ ^ 7 | The Second Existing Intermediary receives the U.S. CBDC transaction after the transaction is been validated and verified by the U.S. CBDC Consensus Algorithm. | ^ ^ 8 | The Second End User possesses the money. |
Various steps in using a simplistic theoretical dual ACH/CBDC network.
==== Only the CBDC Payment Network ==== [[cbdc:public:cbdc_omg:04_doc:15_common:70_dualnets:start| Return to Top]] Allowing new or existing Payment Networks to only use the new U.S. CBDC Payment Network is possible. See Figure {{ref>newOnlyPaymentNet}}. This allows for new and creative ways of having payment transactions. In this scenario, the new Intermediary would use the same new [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:api | Application Programming Interface (API)]] as in the Dual situation, but in this scenario, all the transactions would need to be in U.S. CBDC. This means that any U.S. Dollars would have to be exchanged for U.S. CBDC before the transactions can take place. However, the New Intermediaries might allow accounts to contain U.S. CBDC. In this case, there would be no conversion required. The same situation occurs on the other end of the payment transaction. The recipient could level all or some of the transactions as U.S. Dollars or U.S. CBDC. : **NOTE:** These new financial intermediaries would **NOT** be released from following the existing Laws and Regulations of the traditional financial intermediaries. In other words, they would have to ensure the End User's privacy (both ends of the Payment Transactions. They would also have conform to all the [[cbdc:public:cbdc_omg:04_doc:15_common:48_natsec:start| National Security Laws and Regulations]]. If either End User in the Payment Transaction is not in the U.S., they would have to abide by all the [[cbdc:public:cbdc_omg:04_doc:15_common:50_international:start| International Laws and Regulations]]. This would mean these new Intermediaries would be subject to oversight and auditing.
{{ cbdc:04_doc:15_common:70_dualnets:screen_shot_2022-04-20_at_10.32.48_am.png?700 |}} Theoretical Very Simplified single CBDC Network Concept.
===== Examples ===== [[cbdc:public:cbdc_omg:04_doc:15_common:70_dualnets:start| Return to Top]] The "desirements" specified in [[https://www.federalreserve.gov/publications/files/money-and-payments-20220120.pdf | White Paper]] and identified by the [[cbdc:public:cbdc_omg:04_doc:12_summary:start | OMG's CBDC WG White Paper Analysis]] as **Privacy Issues** are listed in Table {{ref>privacyReq}}. |< 100% 20% ->| ^ Category ^ Desirements ^ ^ Benefits | B0003, B0004, B0005, B0007, B0008, B0009, B0011, B0012, B0013, B0022, B0024, B0026, B0027, B0037, B0038, B0045, B0046, B0047, B0051 | ^ Policies and Considerations | P0021, P0023, P0025, P0026, P0028 | ^ Risks | R0007, R0010, R0014, R0018, R0019, R0020 | ^ Design | D0012, D0013, D0014, D0015 |
Examples of **Privacy Desirements** identified during the White Paper Analysis conducted by the OMG's CBDC WG
: **Note:** **''B''** = Benefit, **''P''** = Policy, **''R''** = Requirement, **''D''** = Design. ===== Discussion of Examples ===== [[cbdc:public:cbdc_omg:04_doc:15_common:70_dualnets:start| Return to Top]] Table {{ref>privacyReqDiscussion}} provides discussion points for each of the "desirements" identified by the [[cbdc:public:cbdc_omg:04_doc:12_summary:start | OMG's CBDC WG White Paper Analysis]]. |< 100% 5% 45% 50%->| ^ Desirement No. ^ Desirement Text ^ Comment ^ ^ B0003 ^ Complement, rather than replace, current forms of money and methods for providing financial services | The proposed Dual ACH/CBDC networks would do exactly that. The existing Intermediaries would be allowed to expand their services to include U.S. CBDC by basically making it as a consumer choice. | ^ B0004 ^ Protect consumer privacy| The proposed Dual ACH/CBDC networks would still place the burden on protecting the privacy of the End-User on the existing and new intermediaries. The intermediaries would be subject to reviews and audits. | ^ B0005 ^ Protect against criminal activity| The proposed Dual ACH/CBDC networks would still place the burden on protecting the national security on the existing and new intermediaries. The intermediaries would be subject to reviews and audits. | ^ B0007 ^ Provide households and businesses a convenient and electronic form of central bank money with: : 1. safety : 2. liquidity | In all accounts, U.S. money could be kept as U.S. Dollars or as U.S. CBDC. Since the U.S. CBDC would probably be backed by a U.S. Dollar Stablecoin, there should be no advantage or disadvantage to either. The main difference is the End User's choice to use the real-time CBDC or the existing ACH Network. Note: There may be a cost associated with converting between the two currencies. | ^ B0008 ^ Provide entrepreneurs a platform on which to create new financial products and services | Entrepreneurs would be able to create new Intermediaries that only used the U.S. CBDC Payment Network. This might not require bricks and mortar establishments and might work completely in a virtual environment. | ^ B0009 ^ Provide faster and cheaper payments (including cross-border payments) | If the U.S. CBDC network is selected by the End User, the transactions will most likely be faster, but not necessarily cheaper. There is a cost associated with using the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.k_consensus:start | Consensus facilities]] of the U.S. CBDC as well as the possibility of costs associated with converting U.S. Dollars to U.S. CBDC. | ^ B0011 ^ Make payments: : 1. faster : 2. cheaper : 3. more convenient : 4. more accessible | Using the Dual Network, the End User can decide how fast they want the payments to be made. The cost of using a U.S. CBDC is still unknown. There is a cost associated with using the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.k_consensus:start | Consensus facilities]] of the U.S. CBDC as well as the possibility of costs associated with converting U.S. Dollars to U.S. CBDC. Also see **''B0008''**.It is up to the free market and the entrepreneurs to make it more convenient and more accessible. | ^ B0012 ^ Provide payment services to households and businesses around the clock, every day of the year| Currently, most existing Intermediaries offer online banking addressing this already. However, some transactions may require a "person-in-the-middle" to complete. The U.S. CBDC would still require these "person-in-the-middle" for some kinds of transactions. | ^ B0013 ^ Provide immediate access to transferred funds| If an End User chooses to use the U.S. CBDC network, the funds will be available as fast as the U.S. CBDC infrastructure permits. Usually within minutes. See [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.k_consensus:start | Consensus Algorithms]] for more information. | ^ B0022 ^ Provide a CBDC that is: : 1. [[cbdc:public:cbdc_omg:8_append:20_glossary:privacy-protected| Privacy-Protected ]] : 2. [[cbdc:public:cbdc_omg:8_append:20_glossary:intermediated| Intermediated]] : 3. [[cbdc:public:cbdc_omg:8_append:20_glossary:transferable| Widely Transferable]] : 4. [[cbdc:public:cbdc_omg:8_append:20_glossary:identity-verified| Identity-Verified]] | Using the Dual Network Model for payment transfers should fulfill all these desirements. : **NOTE:** These new financial intermediaries would **NOT** be released from following the existing Laws and Regulations of the traditional financial intermediaries. In other words, they would have to ensure the End User's privacy (both ends of the Payment Transactions. They would also have conform to all the [[cbdc:public:cbdc_omg:04_doc:15_common:48_natsec:start| National Security Laws and Regulations]]. If either End User in the Payment Transaction is not in the U.S., they would have to abide by all the [[cbdc:public:cbdc_omg:04_doc:15_common:50_international:start| International Laws and Regulations]]. This would mean these new Intermediaries would be subject to oversight and auditing. | ^ B0024 ^ Provide transactions finalized and completed in real-time | If the U.S. CBDC Payment network is selected by the End User, the transactions will happen as fast as the U.S. CBDC Infrastructure permits. See [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.k_consensus:start | Consensus Algorithms]] for more information. | ^ 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 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:api | Application Programmer Interface (API)]] is also recommended. : **Note:** The [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:api | API ]] could be in the form of Web Services, Remote Procedure Calls (RPC), [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:corba | Common Object Request Broker Architecture (CORBA)]], [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:dds | Data Distribution Service (DDS)]] or other interprocess communication mechanisms defined using [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:omg:idl&s[]=idl | ISO/OMG Interface Definition Language (IDL)]], [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:w:wsdl | standardized Web Services Interface Language (WSDL)]], etc. | ^ B0027 ^ Maintain the centrality of safe and trusted central bank money | The Dual ACH Network and U.S. CBDC Networks maintain the U.S. Dollar as the legal tender for both payment networks. The ACH Network continues to use the U.S. Dollar as it currently does. The U.S. CBDC would use a U.S. Dollar backed Stablecoin. | ^ B0037 ^ Support private-sector innovation | See **''B0009''** above. | ^ B0038 ^ Allow private-sector innovators to focus on: : 1. new access services : 2. distribution methods : 3. related service offerings | See **''B0009''** above. | ^ 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. | ^ B0047 ^ Lower transaction costs | At this point in time, it can only be conjectured that the transaction costs would be less. Often it is assumed that the [[cbdc:public:cbdc_omg:04_doc:15_common:45_privacy:start| Privacy]] and [[cbdc:public:cbdc_omg:04_doc:15_common:48_natsec:start| Security]] laws and regulations can be skipped when using a U.S. CBDC. This will most likely not happen. If the U.S. CBDC uses a Stablecoin, the cost is highly dependent on the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:platform | Platform]] chosen. See: [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.k_consensus:start | Consensus Algorithms]] | ^ B0051 ^ Generate data about users’ financial transactions similar to the current Commercial Bank(( Commercial banks include banks licensed either by federal or state banking agencies, credit unions, and thrifts from the **White Paper**. )) and [[cbdc:public:cbdc_omg:8_append:20_glossary:nonbank_money]] | The Dual ACH/CBDC network model would require all Intermediaries to collect the same kind of data on all transactions providing one degree of freedom between the End Users and the Government. | ^ 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 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:api | 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 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:api | Application Programmer Interface (API)]] and Bridge, all transfers between Intermediaries is possible. | ^ P0025 ^ CBDC intermediary would need to verify the identity of a person accessing CBDC | See **''B0022''** above. | ^ P0026 ^ CBDC transactions would need to be final and completed in real-time | See **''B0007''** and **''B0024''** above. | ^ P0028 ^ Require significant international coordination to address issues such as: : 1. common standards : 2. infrastructure, : 3. the types of intermediaries able to access any new infrastructure, : 4. legal frameworks : 5. preventing illicit transactions : 6. the cost and timing of implementation | See **''B0026''**, **''P0021''**, and **''B0045''** above. | ^ R0007 ^ Risk CBDC is difficult to use without service providers | At a minimum, the existing Intermediaries would be able to use most of their existing infrastructure to use the U.S. CBDC. In the Workflow for creating a payment transaction: : 1. Need to ask if it is going to use a CBDC transfer. : a. If yes, they need to make sure the End Users account has the correct about of CBDC Stablecoins : i. If not, they need to convert U.S. Dollars to U.S. CBDC Stablecoins : ii. formulate a standardized U.S. CBDC transaction and all the required data : b. If not, do ACH Network business as usual | ^ R0010 ^ CBDC has a Risk of significant energy footprint similar to Cryptocurrencies | This is highly dependent on the DIDO Platform selected for the U.S. CBDC and the [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.k_consensus:start | Consensus Algorithm]] selected. | ^ R0011 ^ Increased Risk to consumer's vulnerability to: : 1. loss : 2. theft : 3. fraud | In the Dual ACH/CBDC network the risk should remain the same as it is under just the ACH Network. | ^ R0014 ^ Risk of not achieving an appropriate balance between safeguarding the privacy rights of consumers and affording the transparency necessary to deter criminal activity | Assuming that the current balance is acceptable, using the Dual Network Model for payment transfers would keep in place all existing Privacy and Security Laws and Regulations. The new Intermediaries would have to follow the same rules as the existing Intermediaries. : **NOTE:** These new financial intermediaries would **NOT** be released from following the existing Laws and Regulations of the traditional financial intermediaries. In other words, they would have to ensure the End User's privacy (both ends of the Payment Transactions. They would also have conform to all the [[cbdc:public:cbdc_omg:04_doc:15_common:48_natsec:start| National Security Laws and Regulations]]. If either End User in the Payment Transaction is not in the U.S., they would have to abide by all the [[cbdc:public:cbdc_omg:04_doc:15_common:50_international:start| International Laws and Regulations]]. This would mean these new Intermediaries would be subject to oversight and auditing. | ^ R0018 ^ Risk a CBDC could fundamentally change the structure of the U.S. financial system, altering the private sector and central bank: : 1. roles : 2. responsibilities | The Dual ACH/CBDC Network models should extend the current structure of the U.S. financial system and provide more potential Intermediaries. The more Intermediaries, the more robust the system should become. | ^ R0019 ^ Risk of reducing the aggregate amount of deposits in the banking system, which could in turn increase bank funding expenses, and reduce credit availability or raise credit costs for households and businesses.| In the Dual ACH/CBDC Network model, U.S. Dollars in accounts or U.S. CBDC would still be treated as transfers. See the answer to [[cbdc:public:cbdc_omg:04_doc:20_comments:brp:q13:start]]. | ^ R0020 ^ Risk that interest-bearing CBDC could result in a shift away from other low-risk assets, such as shares in money market mutual funds, Treasury bills, and other short-term instruments. | Using the Dual ACH/CBDC Transaction Network, the U.S. CBDC should be treated exactly the same way as U.S. Dollars. The Intermediary accounts would have to segment the accounts into those that contain U.S. Dollars and those that contain U.S. CBDC if the End User wants to avail themselves of the new U.S. CBDC network. | ^ D0012 ^ Design should address privacy concerns by leveraging existing tools already in use by intermediaries | See **''B0004''**, **''B0024''**, **''B0047''**, and **''R0014''** above. | ^ D0013 ^ Design should facilitate compliance with a robust set of rules already intended to combat : 1. money laundering : 2. the financing of terrorism : 3. customer due diligence : 4. record-keeping : 5. reporting requirements | See **''B0005''** and **''R0011''** above. | ^ D0014 ^ Design should involve private-sector partners with established programs to help ensure compliance with existing rules | The proposed Dual ACH/CBDC networks would do exactly that. The existing Intermediaries would be allowed to expand their services to include U.S. CBDC by basically making it a consumer choice. The proposed Dual ACH/CBDC networks would still place the burden on protecting the privacy of the End-User on the existing and new intermediaries. The intermediaries would be subject to reviews and audits. The proposed Dual ACH/CBDC networks would still place the burden on protecting the national security on the existing and new intermediaries. The intermediaries would be subject to reviews and audits. | ^ 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 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:a:api | Application Programmer Interface (API)]], the bridges, and the building out of a Distributed Network of Nodes to handle the CBDC transactions and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.k_consensus:start | Consensus]]. The network of nodes might have any number of node types. Figure {{ref>typesOfNodes}} describes the taxonomy of DIDO Node Types. See [[ https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.2_views:3_taxonomic:3_node_tax:start | OMG DID-RA Node Taxonomy]] for a discussion on the different kinds of nodes. | | **''B''** = [[cbdc:public:cbdc_omg:04_doc:12_summary:start#benefit_considerations| Benefit Considerations ]] ||| | **''P''** = [[cbdc:public:cbdc_omg:04_doc:12_summary:start#policy_considerations| Policy Considerations]] ||| | **''R''** = [[cbdc:public:cbdc_omg:04_doc:12_summary:start#risk_considerations| Risk Considerations ]] ||| | **''D''** = [[cbdc:public:cbdc_omg:04_doc:12_summary:start#design_considerations | Design Considerations]] |||
Privacy references of desirements in the **White Paper**
{{ cbdc:04_doc:15_common:70_dualnets:node_taxonomy.png?500 |}} DIDO Node Taxonomy: Node Types
/**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- /* To add a discussion page to this page, comment out the line that says ~~DISCUSSION:off~~ */ ~~DISCUSSION:on|Outstanding Issues~~ ~~DISCUSSION:off~~