Implementation

This research brief outlines a range of factors and options to demonstrate what is possible with the technology and the solution, with varying degrees of input and integration with partners. OARS is a standalone web-based solution, but its effectiveness and usage need to be considered either alongside or integrated into partners’ existing financial system and technical infrastructure. Successful system design and development hinge on a deep understanding of stakeholder needs, capabilities, and desired outcomes, as well as thorough planning and architecture.

As noted in the customization and considerations section above, to derive the most value from OARS, key areas of consideration need to be assessed at the outset of planning. Decisions about objectives, partners, solution architecture, financial systems integration, and timelines are intertwined with implications for scope, costs, and feasibility. Building digital services that meet objectives makes it possible to more effectively deliver policy and public programs.

The U.S. Digital Services Playbook outlines how to approach the planning phase for digital product sprints and software development for the public sector. For readers interested in a deeper understanding of the technical and architecture considerations of the solution, please review the QuickStart Guide available in the OARS repository on New America’s GitHub.

The first step for partners considering an OARS deployment is to make an initial assessment to inform a managed research and discovery phase that produces a deployment or product road map plan that includes costs; timelines; technical implementation and testing; capacity building; and a clear delineation of roles, responsibilities, ownership, and accountability. Total costs and scope will be affected by these decisions. Areas of consideration include:

Partners

• Who are the partners involved in the asset return?
• What is the context of the return, and how do the partners work together? Are there factors for consideration that could affect the implementation?
• Who assumes responsibility for managing the implementation of OARS inclusive of technology considerations, costs, and timelines?

Participants

• Who are the participants in the system?
• What does each participant need to do?
• Who are the actors that will actively create system transactions?
• Who are the observers that will provide additional oversight to system transactions?
• Who governs the solution?
• Is there a need for a neutral OARS administrator?
• Are there observers? For example, is there a potential for including civil society partners into the solution for additional transparency?

Processes

• What are the key workflows OARS will cover? This includes read and write permissions. For example, in the case of the prototype, each participant in OARS was either an actor or an observer. In each of those two categories, there were various permissions.
• What does each participant need to see before authorizing system transactions?

Hosting Details

• Where will the solution be hosted?
• How long will it be hosted?
• Who hosts the solution?
• Are there data residency requirements?
• Are there compliance factors such as General Data Protection Regulation (GDPR) or the equivalent?
• Are there additional privacy and data ownership considerations? (There should be little personally identifiable information in the system, but an assessment on this front is good practice.)

Architecture Options

• The OARS prototype was built on a mock network. To deploy a full solution, a network to run the pilot must be selected. Network options could include Corda Network or a segregated or private network. Each has trade-offs in terms of cost, security, and technical capacity.
• A notary in Corda is a network service that provides unique consensus by attesting that, for a given system transaction, it has not already signed other transactions that consume any of the proposed transactions’ input states (i.e., preventing “double spends”). There are two types of notaries in Corda: validating and nonvalidating. The final choice of the notary depends on the solution requirements. There are privacy considerations that should be agreed between the governments engaged in an asset repatriation before selecting a notary option. For the purpose of the prototype demonstration, R3 used a nonvalidating notary, which preserves transaction privacy for security purposes. In this case, the name of the OARS user who approved or declined the request for the use of funds is not fully visible.
• For deployment options in the prototype, R3 assumed nine nodes for the participants. For the purposes of the proof of concept deployment, each node was hosted on one Azure Virtual Machine. In the POC deployment, R3 used East U.S. as the only hosting region. Implementers will have the flexibility to use more country-specific and more resilient deployment strategies, for example, deploying to a region closer to the target country, replicating data in another zone, and the like.

The OARS prototype features the immutability and auditability benefits of distributed ledger technologies. As innovation in DLT is more widely adopted, it may be possible to incorporate more advanced features in OARS.

Future iterations and uses of OARS could include the following enhancements and additional features beyond what was demonstrated with the POC:

• Requiring coauthorization by multiple approved agencies, countries, or departments to complete transactions.
• Monitoring multiple returns to the same country simultaneously or adding multiple returning countries with oversight needs.
• Instituting smart workflows (for example, to block financial transactions if agreed-upon conditions aren’t met, or to release funds if they are), automated notifications or transactions, or tokenized assets.
• Automatically recording automated notifications and transactions.
• Tracking the transfer or return of goods, art, equipment, and other nonmonetary assets.
• Tracking disbursal to the end recipient beyond government entities, for example, tracking disbursal from a Ministry of Education to the contracted builders of a new school.
• Adding language translation.

There are many factors that could influence a timeline to customize and deploy the OARS solution. Roughly six to 12 months are needed for solution deployment once all partners, including tech vendors, as applicable, have been identified. A timeline with five distinct phases could reflect this road map:

• Research and Design (~4 to 12 weeks)
  • Define Use Case: Determine the specific problem or goal that the solution is meant to address. Align objectives and stakeholders.
  • Specify Product Requirements: Identify and document the requirements for the product, considering factors such as functionality, compatibility, constraints, user interface, and overall design, all in close consultation with stakeholders and potential end users.
• Build (~12 weeks)
  • Itemize Initial Development: Break down the product requirements into smaller tasks and initiate the development phase. This may include creating a prototype or mock-up.
  • Build the Solution according to Requirements: Develop the software or solution as defined in the requirements, adhering to best coding practices and aligning with a predefined architecture.
  • Maintain Iteration and Refinement: Regularly review progress with stakeholders, making necessary adjustments to ensure alignment with the project goals.
• Test and Deploy (~6 weeks)
  • Enforce Quality Assurance: Implement testing protocols to ensure that the solution meets performance, security, and design specifications, as well as all other contractual obligations.
  • Arrange Deployment: Prepare for deploying the solution in a live environment, including finalizing hosting, managing configurations, and setting up any necessary integrations.
• Onboard and Prepare for Launch (~12 weeks)
  • Onboard Participants: Enroll users and other necessary participants, providing them with access and permissions as required.
  • Designate Administrators: Identify and train designated administrators or superusers who will have higher-level access or responsibilities.
  • Train and Support: Provide necessary training and support materials to ensure that all participants understand how to use the solution effectively.
  • Undergo Final Pre-launch Checks: Conduct a final review to ensure everything is in place for a successful launch, including data migration if necessary, and do any troubleshooting.
• Go Live
  • Launch: Officially release the solution to the intended audience, switching from any old system or process to the new one.
  • Provide Post-launch Support and Monitoring: Maintain ongoing support and monitoring to ensure that the solution is working as intended, offering prompt assistance as needed and collecting feedback for potential future enhancements.
  • Implement Evaluation and Continuous Improvement: Regularly review the solution’s performance against its objectives and make improvements to keep it aligned with evolving needs and expectations.

The OARS prototype was developed to function primarily as a payment tracing tool that provides real-time visibility to permissioned stakeholders and helps institutionalize the rule of law. Other possible implementations of a DLT solution can bring transparency and accountability to asset repatriation or public asset management. DLT can be applicable and useful when there is a need to create and manage immutable records, or make the misappropriation of funds easier to identify.

As currently designed, OARS or a system inspired by the OARS prototype could assist with the monitoring of allocated funds or foreign development assistance. A system like OARS could be particularly helpful in many potential use cases, such as tracking resources or assets in the context of conflicts, natural disasters, pandemics, and other humanitarian crises.

OARS could be repurposed to track asset movement among government departments or between regional and national government networks. Given adequate political will and compatible integration with banking systems, OARS can not only trace asset movement but could eventually be harnessed to transfer tokenized assets, providing complete real-time transparency and accountability in the movement of funds.

For example, imagine being able to program a digital dollar to determine the conditions under which it can be transferred, blocked, or spent. This future state would need entities on both sides of a return, such as banks or a mutually-accepted third party, that could initiate a transaction using digital dollars or could receive and convert digital dollars into fiat currency.

While it might sound far off in the future, governments around the world, including the U.S. government, are actively exploring digital cross-border payments. The Corda platform underlying OARS is being used to represent digital assets in global projects, including central bank digital currency (CBDC) and real-time cross-border payments. Currently, 130 countries, representing 98 percent of global GDP, are in various stages of exploring the feasibility of implementing a CBDC.

Innovation advancements and a clearer regulatory framework surrounding CBDCs and related digital assets that include privacy preservation, consumer protections, and anti-money laundering standards may enable these technologies to serve as tools for secure and open exchange of assets and information. They also have the potential to lower transaction costs.

Although corruption cannot be eliminated overnight, trust can be strengthened. Leveraging digital tools to support improvements in public accountability and budget processes can substantially enhance the legitimacy of government and public institutions. OARS and similar digital public infrastructure solutions committed to harnessing innovation in the public interest could reinforce democratic values by providing opportunities for increased transparency and accountability.