This is an old revision of the document!
OMG Responses to Federal Reserve Discussion Paper
The Object Management Group® (OMG®), founded in 1989, is an international not-for-profit software consortium (aka Standards Developing Organization (SDO) or a Voluntary Standards Consensus Body (VSCB)) that sets standards in the many areas including distributed object computing. This means the OMG organization plans, develops, establishes, or coordinates voluntary consensus standards using agreed-upon Policies and Procedures (P&P). The P&P provides a framework for openness and transparency to aid in balancing the interests of the Stakeholders, providing due process for disagreements, and building consensus.
The OMG is not a financial institution, a government institution, or a provider of goods, services, or technology. The main goal of the OMG is to produce standard technical specifications for use by the national and international communities with a proven track record, see the Introduction). Based on our experience in formulating the responses to the questions posed in the White Paper, our members have formulated a set of recommendations to help aid the Federal Reserve to move forward with a U.S. CBDC. The OMG members are very active in 26 vertical markets, including Business, Finance, Government, Healthcare, Manufacturing, Military, Robotics, Space, and Telecoms.
Return to Top of Recommendations
Obviously, when it comes to determining the Stakeholders it might be fair to include every U.S. Resident, or at least those having banking or credit union accounts. Obviously, this would be unwieldy. All these individuals are supposedly represented in government through elected officials in Congress and the President. These elected officials have taken the problem and made various departments or agencies that should be representing these people. Based on a cursory review, it appears that there are at least 33 different Oversight authorities in the U.S., see Table 1.
Potential Oversight Authorities | No. of Stakeholders |
---|---|
U.S. Federal Government Oversight Authorities | 14 |
non-U.S. Federal Government Oversight Authorities | 19 |
Total | 33 |
However, this does not include the roughly 4,200 Commercial Banks insured by the FDIC, see Figure 1 or the largest Banking Association in the U.S., The American Banking Association (ABA), or its competitors, nor the roughly 5,300 Credit Unions.
It does not represent all the retail outlets, service providers, landlords, etc that all have a “stake” in the U.S> Dollar and consequently a U.S. CBDC. For more on the Stakeholders identified in the OMG analysis, please refer to section 05_stakeholder.
Return to Top of Recommendations
The members of the OMG have compiled a list of the Laws and Regulations within the U.S. that applicable to the Financial System covering:
These laws were passed by the Legislative and the Executive Branches of the Government and have been upheld by the Supreme Court. Therefore, this can be considered as part of the will of the people ( see Stakeholders).
U.S. Privacy Consideration | No. of Laws and Regulations |
---|---|
U.S. Federal Laws and Regulations | 10 |
U.S. State Laws and Regulations | 6 |
Total | 16 |
National Security Consideration | No. of Laws and Regulations |
---|---|
Human Trafficking | 14 |
Drug Trafficking | 9 |
Corruption | 10 |
Money Laundering | 11 |
Total | 44 |
A U.S. CBDC would have to adhere to these laws if it going to be considered valid. Not doing so would be considered arbitrary and capricious. In addition, since the CBDC would most likely rely on new technology, each of these laws would need to be evaluated by a legal team to assess how the laws and regulations need to be reinterpreted, amended, or extended to remain current. Further discussions are well beyond the skills of the authors but it is recommended The Federal Reserve take this on as a serious part of the whole CBDC effort.
Return to Top of Recommendations
The Object Management Group (OMG) recommends the Federal Reserve uses a Model-Based Systems Engineering (MBSE) and Unified Architecture Framework (UAF) approach for future CBDC efforts. The CBDC is a complex issue that, once released, could have a life expectancy of many, many years. Only through extensive Systems Analysis, Engineering, Design, and testing will CBDC have the stability it needs to instill confidence of the public.
Some of the potential requirements in the White Paper as summarized by the Object Management Group's White Paper Analysis reflect the need to instill public confidence (See Table 4)
Statement No. | Page No. | Statement |
---|---|---|
B0020 | 13 | Maintain public confidence by not requiring mechanisms, such as deposit insurance |
R0003 | 3 | Risk to the safety and stability of the financial system |
R0004 | 3 | Risk to the efficacy of monetary policy |
R0005 | 7 | New payment services could pose Risks to:
|
R0011 | 11 | Increased Risk to consumer's vulnerability to:
|
Return to Top of Recommendations
For more than forty years, the practice of systems engineering followed a linear path: requirements are documented first, followed by analysis then conceptual design—through the development life cycle. However, regardless of the engineering process employed—waterfall, incremental, iterative, spiral, and even sprint-based—the lack of integration from one phase to another in the cycle results in longer delivery times and increases costs to correct errors introduced at transition points.
Model-Based Systems Engineering (MBSE)2) is an initiative in the systems engineering community that uses model-based descriptions and transformations so that work occurs concurrently. Requirements collection, analysis, and specifications are performed at the same time as conceptual design. MBSE is practiced across many industries around the globe. For example, it was used to develop the world’s largest telescopes, propulsion engines for fighter jets, autonomous driving cars, software solutions to include software-defined radios, and space applications (hardware and software).
MBSE is often contrasted with a more traditional document-based approach to systems engineering, where system information is spread across many document-based artifacts (handwritten text documents, spreadsheets, and drawings). MBSE brings information together into a cohesive, integrated model of the system that:
For more information on MBSE, please see:
The Object Management Group (OMG) also recommends that the Federal Reserve use the Unified Architecture Framework (UAF) for future CBDC efforts. See OMG Unified Architecture Framework (UAF):
UAFP 1.0 supports the capability to:
The intent of UAF is to provide a standard representation for describing enterprise architectures using a Model-Based Systems Engineering (MBSE) approach.
The Object Management Group also recommends that the Federal Reserve use the Unified Architecture Framework (UAF) for future CBDC efforts. See OMG Unified Architecture Framework (UAF), it is summarized here:
UAF Profile (UAFP) 1.0 supports the capability to:
The intent of UAF is to provide a standard representation for describing enterprise architectures using a Model-Based Systems Engineering (MBSE) approach.
Return to Top of Recommendations
The OMG members recommend the Federal Reserve invest Research Development Test & Evaluation (RDT&E) Funding in developing and perfecting any Consensus Algorithms required by the CBDC since they are an essential part of any DIDO implementation such as Blockchain, Distributed Ledger, Directed Acyclical Graphs, etc).
There are a few consequences to not having “the best” Consensus Algorithms for the CBDC:
Currently, in the Cryptocurrency world, most of the Mining Operations have moved from being distributed to being centralized and operated be a few select organizations in highly centralized locations. For example,
If this is true for a U.S. CBDC, then what advantage does the CBDC have over the Real-Time Payments (RTP) developed by the Automated Clearing House (ACH) Network.
Return to Top of Recommendations
The OMG members recommend the Federal Reserve use Research Development Test & Evaluation (RDT&E) Funding in developing and perfecting Artificial Intelligence (AI) for use with and alongside a U.S. CBDC. The AI could help in detecting suspicious security and criminal activities. When combined with Biometrics and Biometric Authentication.
AI could also consider time and geospatial data to make informed decisions about the validity of a proposed transaction.
Return to Top of Recommendations
The OMG members recommend the Federal Reserve use Research Development Test & Evaluation (RDT&E) Funding in developing and perfecting glossaries, taxonomies, and ontologies used to represent the U.S. CBDC, the Intermediaries, and the needs of the Stakeholders. There already exists an OMG Ontology, Financial Industry Business Ontology (FIBO) that probably needs to be extended or updated to handle a U.S. CBDC.
Return to Top of Recommendations
The OMG members recommend the Federal Reserve use Research Development Test & Evaluation (RDT&E) Funding in developing and perfecting Smart Contracts. Currently, the de facto standard for Smart Contracts is the Ethereum language called Solidity. See the Ethereum Solidity Language Specification. However, there are shortcomings in the language which could either be updated or replaced with a more comprehensive language and may not even be procedural in nature. For example, the graphically based Business Process Model And Notation (BPMN). Another possibility would be to develop a standardized, Platform-Independent Model for a Smart Contract Application Programming Interface (API) which could have multiple Platform Specific Models developed from the PIM.
Return to Top of Recommendations
The OMG members recommend the Federal Reserve use Research Development Test & Evaluation (RDT&E) Funding in developing and perfecting how to model data on a blockchain and especially what data to store on a blockchain.
TBD TBD TBD
Most of the data models underlying cryptocurrencies are pretty simple. Generally, it's a balance.
The OMG members recommend There needs to be a comprehensive study of what needs to be stored in addition to the simple balance, especially if the “ledger” is going to try and prevent criminal activity and protect privacy. It also means that there will most likely be a confederation of blockchains and the need to link these together with the blockchains. some examples of concepts not covered in the existing models are association and composition. However, this extra data comes at a cost.
Return to Top of Recommendations
Task | Gas required | Cost (ETH) | Cost (USD) | Ops per ETH | Ops per USD | Ops per Block | Blocks to complete OP |
---|---|---|---|---|---|---|---|
Add or subtract two integers | 3 | 0.000000009 | 0.000002655 | 11111111.11 | 37664.78343 | 1566666.667 | 0.0000006382978230 |
Add two Integers, 1 Million times | 3000000 | 0.09 | 26.550000000 | 11.1111111 | 0.037664783 | 1.566666667 | 0.638297872 |
Task | Gas required | Cost (ETH) | Cost (USD) | Ops per ETH | Ops per USD | Ops per Block | Blocks to complete OP |
---|---|---|---|---|---|---|---|
Save a 256-bit word to Storage | 20000 | 0.0006 | 0.171 | 1666.666667 | 5.649711751 | 243 | 0.004255319 |
Save 1MB to Storage (31250 256-bit words) | 625000000 | 18.75 | 5531.25 | 0.053333333 | 0.000180791 | 0.00752 | 132.9787234 |
Save 1GB to Storage (31250 256-bit words) | 6250000000000 | 18750 | 5531250 | 0.00005333333 | 0.00000018079 | 0.00000752 | 132978.7234 |
Return to Top of Recommendations
Also see the answers to:
Cryptocurrency skirts near the edges of illegal, illicit, or shady interactions and transactions. The Chainalysis Team recently published their 2021 findings5) which highlights some security issues associated with the unregulated or poorly regulated Cryptocurrency realm. The following is an excerpt from the report:
Therefore, security needs to be “baked into” the CBDC from the onset and can not be an afterthought; however, it is hard to balance the tightrope between the need for Privacy and the need for Security. This difficulty in achieving a balance has been captured in Desirement R0014
:
R0014 | Risk of not achieving an appropriate balance between safeguarding the privacy rights of consumers and affording the transparency necessary to deter criminal activity |
---|
It appears that the Digital Cash Model is less vulnerable than the Digital Account Model. The use of Stablecoins could help with maintaining the value of CBDC, but would not add any security.
Regardless of which model ( Digital Accounts, Stablecoins, Digital Cash) is used for the CBDC, the Object Management Group recommends that the Federal Reserve consider Seurity of the system from the earliest phases of the U.S. CBDC. This means having the Non-Functional requirement of Security be well defined and formal.
One way to accomplish this is through the use of a Model-Based Systems Engineering (MBSE) and Unified Architecture Framework (UAF) to model all aspects of the CBDC before it is built. Since the requirements for the security of the system are a moving, ever-changing target, this does not mean that every security issue must be fully understood or specified before work can begin. It means that at every step, the Security question needs to be raised. The CBDC is a complex issue that, once released, could have a life expectancy of many, many years. Only through extensive Systems Analysis, Engineering, and Design will the CBDC have the stability it needs to instill confidence in the public.
During system development, MBSE and UAF models of the system are used along with Use Scenarios and Use Cases to flush out potential problems. This means thinking about all aspects of the State of Data throughout its lifecycle. The OMG DIDO-RA has detailed discussions of the various states of data and how it relates to a distributed system.
Figure 3 graphically represents the different Data States within a system. Most systems are now able to handle Data-in-Motion and Data-at-Rest issues but have traditionally relied on physical security to protect Data-in-Use.
Table 5 provides a quick overview of the various data states. These data states are described in detail in the OMG DIDO-RA.
Data-at-Rest | Data-at-Rest refers to all data in computer storage. It excludes data while it is moving across or within a network, and it excludes data that is temporarily residing in computer memory. |
---|---|
Data-in-Motion | Data-in-Motion , also referred to as Data in Transit or Data in Flight, is a Digital Asset transmitted between locations (i.e., between computers or computer components). Data-In-Motion also describes data within Random Access Memory (RAM). |
Data-in-Use | Data-in-Use covers data being processed (i.e., updated, processed, erased, accessed or read) by a system. Data-In-Use is not passively stored, but is actively moving through parts of a Computing Platform (i.e., Central Processing Unit (CPU), Dynamic Random Access Memory (DRAM),, Data Bus, etc.). Data-In-Use is one of three states of digital data – the other states are Data-at-Rest and Data-in-Motion. |
Statement No. | Page No. | Statement |
---|---|---|
B0004 | 2 | Protect consumer privacy |
B0005 | 2 | Protect against criminal activity |
B0053 | 20 | Provide resiliency to threats to existing payment services—including:
|
R0011 | 11 | Increased Risk to consumer's vulnerability to:
|
D0015 | 20 | Design should include any dedicated infrastructure required to provide a resilience to threats such as operational disruptions and cybersecurity risks |
D0016 | 20 | Design should include offline capabilities to help with operational resilience of the payment system |
D0017 | 20 | Design should include digital payments in areas suffering from large disruption, such as natural disasters |