Digital Impact and Governance Initiative at New America

DIGI is a program of New America dedicated to advancing public innovation to empower a people-centric digital future that strengthens communities and improves lives. We support catalyzing next-generation systems and solutions that power the emerging field of digital public infrastructure through cross-sector collaboration with government partners, the technology sector, and civil society. Interoperable, open, and replicable digital solutions are the basis for more inclusive, transparent, and secure societies and do not need to come at the cost of privacy or human rights.

R3

R3 is a leading provider of enterprise distributed ledger technology (DLT) and services that enable the secure exchange of value in regulated industries where trust is critical. Distributed solutions developed on the platform Corda harness the “Power of 3”—R3’s distributed trust technology, connected networks, and regulated markets expertise—to drive transformation in digital finance. As one of the first private, permissioned distributed ledger application platforms, Corda empowers regulated institutions to realize the full potential of direct digital collaboration to solve complex multiparty workflows. R3 maintains one of the largest DLT ecosystems in the world connecting over 400 institutions, including global systems integrators, cloud providers, technology firms, software vendors, corporations, regulators, and financial services firms from the public and private sectors.

The Open Asset Repatriation System (OARS) is an open-source, web-based tool that can be used to create a permanent record of the movement and allocation of repatriated assets from one country to another by leveraging distributed ledger technology (DLT). OARS is currently developed to a proof of concept (POC) stage.

This research brief is intended as a public resource to demonstrate how OARS is designed to harness the power of DLT to strengthen trust and transparency in international asset return processes and to encourage public engagement in the development of digital public goods that strengthen accountability measures.

The research and work associated with the development of the OARS prototype help to advance the mission of New America’s Digital Impact and Governance Initiative (DIGI) to improve the provision of public systems and services by catalyzing next-generation systems and digital solutions through cross-sector collaboration with government partners, the technology sector, and civil society. Interoperable, open, and replicable digital solutions are tools to be leveraged for more inclusive, transparent, and secure societies and do not need to come at the cost of privacy or human rights. The emerging field of digital public infrastructure is grounded in the effectiveness and efficiency of modular, interoperable digital solutions, powered by open-source, open-data architecture that integrates with other solutions.

As currently designed, OARS is not intended to be used to move funds. Rather, it has the potential to create permanent records of the movement of repatriated funds.

While technology alone can’t monitor what actions may take place offline or off-ledger, the goal of OARS is to empower partners in an asset return scenario to accurately track and record how funds are allocated and with what oversight. A return process managed through OARS respects the autonomy of the origin country by complementing existing oversight structures. Additionally, OARS has the potential to empower community involvement in public administration by giving civil society organizations and others a transparency tool to help monitor whether money is being spent as determined by agreements overseeing the provision of an asset return. These measures have the potential to bolster trust and accountability in public institutions.

OARS was developed through a collaboration between DIGI, the technical provider R3, and the State Department’s Bureau of International Narcotics and Law Enforcement Affairs.

Asset recovery is recognized as “a fundamental principle” of the United Nations Convention against Corruption (UNCAC), the only legally binding universal anti-corruption instrument. UNCAC has been signed and ratified by over 160 countries and is widely perceived as a major step in furthering cooperation among countries to join forces to fight corruption and assist each other in recovering looted assets.

In the United States, the Department of Justice’s Kleptocracy Asset Recovery Initiative under the Money Laundering and Asset Recovery Section (MLARS) has repatriated or assisted in the return of $2 billion in proceeds from foreign official corruption since 2010.

Under current international law and norms, there is no defined or standardized process for how seized assets are returned from one country to another. As a result, returning countries often bear the cost of litigation and multijurisdictional investigations to ensure that repatriated assets are not lost to corruption or misuse. Countries are increasingly working together to return recovered assets to their country of origin in line with domestic laws and international obligations.

The concept driving the design of OARS is creating a trusted, permanent, and auditable record of the movement of returned funds, transferred through existing channels such as bank accounts, between and within countries. OARS is a digital tool designed to help facilitate the asset repatriation processes by tracking decisions and actions on a secure, decentralized, consensus-based digital ledger. It does this in two ways:

1. Managing and recording the workflow of authorized participants in an asset return; and
2. Facilitating real-time auditing capabilities by logging when a transfer of funds has been initiated or completed or a withdrawal has been requested, and whether the requests were approved, rejected, or flagged.

A cryptographically secured and consensus-based ledger helps ensure that on-ledger records are immutable and that all system transactions are inherently visible and auditable in real time. The term “transactions,” in this case, refers to actions that represent a change in the ledger status such as in a record or information. For example, an approval or rejection in OARS of a requested use of funds would represent a system transaction. It is essential to remember that OARS is not facilitating fund movement but is creating a permanent and auditable record of system transactions.

Each transaction is assigned a unique ID, or hash, in OARS. OARS acts as a notary to verify the transaction. Each hashed on-ledger transaction contains a list of information pertaining to that transaction, including amount, account, purpose, time stamp, and participants involved. All of this information is available to specific OARS users on a real-time, need-to-know basis.

The proof of concept of OARS is powered by Corda, an open and permissioned distributed application platform developed by R3. Corda is a method of codifying process flows that ensure compliance and accurate records.

OARS provides transparency into funds drawn from a defined pool of returned assets. After the funds have been withdrawn, the amount of accountability and enforceability will vary depending on what information is shared with the system. Transparency is the key feature of this approach as all participants in the network can see when the withdrawals occur. Accountability is relatively low in this context as there is no ability to prevent or delay funds from being withdrawn in order to conduct enhanced due diligence on transactions. However, additional accountability measures could be included in future iterations of OARS.

Key Features of OARS

• Requires mutual consent to complete the creation of a record or transaction, increasing accountability measures. For example, this mutual consent could be from individuals in different government agencies or offices.
• Offers transparency to preapproved observers by incorporating “observer—read only” access that determines when information is visible, what information is visible, and for whom. This feature is designed to be inclusive of cross-sector oversight, including civil society organizations.
• Shares minimal data to verify transactions, allowing for data transparency while maximizing data security.
• Provides mobile accessibility through a web-based platform to facilitate use and minimize broadband issues.
• Uses open-source technology to support accessible replication and scale.
• Integrates with existing systems, including potentially with in-country banking infrastructure, to add more seamless layers of transparency and accountability if desired.

OARS could help recipient and repatriating countries operationalize asset return procedures and record the movement and allocation of returned assets pursuant to agreements. Countries repatriating the assets stolen by corrupt individuals or organizations from other governments may agree with the recipient or origin country to use the recovered assets to benefit the people harmed by acts of corruption and abuse of office or contribute in some other meaningful way to social and economic development within the recipient country.

For example, in 2020, the U.S. repatriated over $311 million to the people of Nigeria under an agreement that allocated the returned funds to support three critical infrastructure projects: the Second Niger Bridge, the Lagos-Ibadan Expressway, and the Abuja-Kano Road. These allocations represent the repurposing of money laundered during and after the military regime of General Sani Abacha. Such allocations help new governments send a strong message of commitment to the public good. There are also recent examples of the U.S. repatriating recovered assets to Malaysia and Peru.

Addressing four areas of consideration—partners, financial infrastructure, technical infrastructure, and costs and timeline—will help partners determine whether OARS is a viable solution for a specific asset repatriation process and the extent of the information that can be recorded for a given asset return.

Partners

• Viable Partners: Partner countries, agencies, or institutions must have an appropriate level of technical capacity, financial infrastructure, and broadband access to accommodate OARS implementation. OARS requires political will by all partners to effectively utilize the system. Participating governments should be committed to transparency and accountability measures and willing to actively engage in the system deployment to help ensure effective use and oversight.
• Partner Roles and Responsibilities: Determine which partner oversees the implementation and management of OARS inclusive of technology considerations, costs and timelines. Assess if that same partner or an alternative serves as administrator of the system. Assess if there is a need for a neutral party to serve as an implementation manager or system manager, this could include a government, multilateral organization, auditor, contracted technical provider, consultant, or civil society organization.
• Terms of Use: The more data points partners agree to record on-ledger, the greater the transaction auditing capacity and transparency.

Financial Infrastructure

• Fund Management: Determine where funds are held—central bank, private bank, subaccount, or other agreed-upon location—will inform what information is possible to access and record on-ledger through OARS.
• Automation: Assess if there is an option to have off-ledger movement (to or from a limited number of predetermined bank accounts) be automatically recorded on-ledger (as opposed to manually input). Assess the feasibility of having the system trigger permissions to release funds off-ledger.
• Local Banking: Assess if there is an option to connect OARS to local banking systems.

Technical Infrastructure

• Connectivity: Limited reliable access to broadband and internet may slow or limit the capabilities of recording transactions in OARS.
• Technical Capacity: Participating countries or other partners will need either in-house expertise or a technical provider to manage front-end services for governments to access the OARS platform, train developers to support and maintain the application, and deploy and support the application in a local jurisdiction.

Costs and Timeline

• Implementation Costs: Unless partners have the technical expertise to customize and manage the solution, a technical provider is needed to implement, deploy, host, and support OARS.
• Associated Costs: Exchange rates, interest rates, and operational fees including hosting and administration should be taken into account.
• Timeline: Once partners are identified to participate in an asset return using OARS, it will take an estimated four to six months to develop the proof of concept version. However, if there is a need to upgrade the features beyond current capabilities, iterations of OARS as described above may require more integration with financial infrastructure and could add to project timelines.

A demonstration of the OARS prototype is viewable here. The video covers a hypothetical use case with a fictitious government created to demonstrate the functionality of OARS and potential future features.

The OARS demonstration reflects the following scenario:

• The U.S. government is returning $5 million to the fictitious government of Catan.
• Catan is a country that is committed to strengthening open-government and transparency measures.
• The $5 million sum will be paid in full through a one time payment from the U.S. Treasury to the government of Catan.
• Both the U.S. and Catan governments are leveraging OARS to gain visibility into all disbursals of these funds.
• The agreement between the two governments provides that the returned funds will be used to improve the education system in Catan.
• No funds move through the OARS system. The system tracks the oversight and authorization of the movement of the funds off-ledger.

For this use case, all participants in OARS are designated as either an actor, an observer, or an administrator.

• Actors can take action and have visibility in the system (otherwise known as both read and write access). The actors in this scenario are the U.S. Treasury, Catan Treasury, U.S. Department of Justice, Catan Ministry of Justice, and Catan Ministry of Education.
• Observers have visibility (or read-only access) into the system. The observers in this scenario—the U.S. Department of State, Catan Ministry of Foreign Affairs, and civil society organizations in both countries—have visibility into disbursals tracked by the system.
• A system administrator is needed for certain operational purposes, such as onboarding new entities and providing technical support. In this demonstration, New America, an independent civil society organization, fills the system administrator role. In practice, any entity agreed upon by participating parties, such as an international civil society or multilateral organization, could serve as the system administrator.

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.

• OARS GitHub Repository
• Demonstration Video

• Consensus: A state of agreement on shared facts or data on-ledger.
• Distributed ledger technology (DLT): Consensus of replicated, shared, and synchronized digital data that use independent computers (referred to as nodes) to record, share, and synchronize transactions in their respective electronic ledgers (instead of keeping data centralized as in a traditional ledger).¹
• Digital public infrastructure: Digital solutions and systems that enable society-wide functions and access to modern necessities like data exchange and sharing, digital forms of ID and identity verification, financial transactions, and information systems—similar to how physical infrastructure facilitates access to electricity, water, and transportation.
• Flows: The interactions that must occur between parties to achieve consensus to satisfy some business requirement.
• Hash, or hashed: Data being added to a distributed ledger is “hashed,” which means a cryptographic hash function is applied to the data and computes an individualized digital fingerprint for the data. Because the hash would be different if any of the underlying data were changed, it provides security from anyone attempting to tamper with it.²
• Notaries: A notary in Corda is a network service that provides uniqueness consensus by attesting that, for a given transaction, it has not already authorized 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.
• On-ledger/off-ledger: On-ledger refers to recorded transactions or actions. For example, if a record is “hashed” to the system, it is on-ledger. Off-ledger refers to activities or actions (including transactions or records issued) outside of a DLT system.
• Open-data architecture: Software design method that is based on specifications that are publicly available, which lowers the barrier for modification and data exchange between applications.
• Open-source software: Software developed and maintained via open collaboration and made available, typically at no cost, for anyone to use, examine, alter, and redistribute however they like. Software for public benefit should be open source by default.³
• Proof of concept (POC): Prototype or sample implementation that’s used to demonstrate the feasibility or potential value of a proposed solution or concept.⁴
• Transactions: Actions that represent a change in the ledger status. These actions can record changes in several formats, including financial, informational, and system transactions.