Should a CBDC be legal tender?
In general, a United States CBDC should be designated as legal tender, thereby matching the current physical US currency. Such a characterization is necessary for a Digital Dollar to exist alongside and eventually replace physical notes and coins, particularly in relatively small “retail” transactions like the acquisition of food, energy, and/or personal services. With the wide adoption of a Digital Dollar, the reduction in costs associated with producing, transferring, securing, and destroying physical currency notes and coins would be quite considerable.
The arguments against designating a US Digital Dollar as a legal tender are more operational in nature. Consider, for instance, the various types of fraud that might be attempted with Digital Dollars. Currently, the largest US note in general circulation is one hundred dollars. It is thus difficult to gather sufficient physical notes to exchange for substantial physical assets like an automobile or a housing unit. How would similar “speed bumps” be implemented with a United States CBDC where the transaction size might be unbound?
Currently, financial institutions are key points of control in implementing Anti-Money Laundering (“AML”) / Combating the Financing of Terrorism (“CMT”) policies and procedures. If a United States CBDC is considered legal tender, presumably it will also be convertible with both physical currency and/or account balances with financial institutions. What entities, potentially with geographic or other constraints, will be permitted to perform these conversions, particularly the physical currency / CBDC type where counterfeit tender might be involved?
The design features of a United States CBDC will necessitate trade-offs along four axes:
As the design evolves, OMG's CBDC WG recommends further consultations that include Use Case analysis and solicitation of scenarios that test the limits of the contemplated CBDC design.
According to the U.S. Code, Title32, Subtitle IV, Chapter 51, Subchapter I Section § 5103, Legal Tend in the U.S. is:
According to the Statutes, yes if the U.S. CBDC is considered a form of the Federal Reserve Note.
The U.S. CBDC could offer another mechanism to the existing non-cash mechanisms such as debit cards, credit cards, electronic transfers, and checks. However, in order to offer real-time settlements, it may need to use a different mechanism than the existing Automated Clearing House (ACH) Network currently in use to electronically move money between banks accounts across the U.S. The current ACH network is run by an organization called Nacha, formerly the National Automated Clearing House Association (NACHA).
There definitely would need to be a bridge between the existing ACH-NACHA payment network and a U.S. CBDC, its associated Consensus Algorithms, and the network of nodes. However, in addition to the bridge between the two, there probably needs to exist a new consolidated frontend ( Application Programming Interface (API)?) that abstracts the type of payment from the participants in the transactions. In other words, the transaction should be agnostic to non-cash mechanisms such as debit cards, credit cards, electronic transfers, checks, and CBDC.
The U.S. CBDC needs to support basic purchases of:
U.S. CBDC should be treated like any other payment form, even though under the hood, it might use a different payment network than the National Automated Clearing House Association (NACHA) network.
The following “Desirements” are from the White Paper as identified by the Object Management Group's CBDC WG report called White Paper Analysis:
Benefits | B0025, B0026, B0029, B0034, B0038, B0040, B0044, B0045, B0046, B0047, B0049 |
---|---|
Policies | P0003, P0018, P0019, P0020, P0021 |
Risks | |
Design | D0004 |
Statement No. | Statement | Comment |
---|---|---|
B0025 | Serve as a new foundation for the payment system | The CBDC could offer another mechanism to the existing non-cash mechanisms such as debit cards, credit cards, electronic transfers, and checks. However, in order to offer real-time settlements, it may need to use a different mechanism than the existing Automated Clearing House Network (ACH) network currently to electronically move money between bank accounts across the U.S. The current ACH network is run by an organization called Nacha, formerly the National Automated Clearing House Association (NACHA). |
B0026 | Provide a bridge between legacy and new payment services | There definitely would need to be a bridge between the existing ACH-NACHA payment network and a U.S. CBDC, its associated Consensus Algorithms, and the network of nodes. However, in addition to the bridge between the two, there probably needs to exist a new consolidated frontend ( Application Programming Interface (API)?) that abstracts the type of payment from the participants in the transactions. In other words, the transaction should be agnostic to non-cash mechanisms such as debit cards, credit cards, electronic transfers, checks, and CBDC. |
B0029 | Support basic purchases of:
|
See the answer to |
B0038 | Allow private-sector innovators to focus on:
|
By defining a new standardized Application Programming Interface (API) as in |
B0044 | Facilitate access to digital payments |
See answers to |
B0046 | Enable rapid and cost-effective delivery of:
|
See answer |
B0047 | Lower transaction costs |
See answer |
B0049 | Promote access to credit |
See answer |
P0003 | Complement current forms of money and methods for providing financial services |
See answer |
P0018 | The Federal Reserve Act does not authorize direct Federal Reserve accounts for individuals | The easiest solution is to allow current intermediaries to process CBDC transactions using an upgraded payment system.
See answer |
P0020 | The private sector would offer accounts or digital wallets to facilitate the management of CBDC holdings and payments |
See answer |
P0021 | The intermediaries would operate in an open market for CBDC services |
See answer |
D0004 | Design should influence how the Federal Reserve might affect monetary policy |
See answer |
B = Benefit Considerations |
||
P = Policy Considerations |
||
R = Risk Considerations |
||
D = Design Considerations |