Project

A. General Information

1. Title

LACCHain cross-border payments project

2. Status of the project
Pilot
3. Implementation period of the project/service:
From
2021
To
2021
4. Website
--
5. Geographical coverage
Bilateral
Participating countries: Dominican Republic, United States of America
Hub Point: United States of America
6. Participating agencies/entities of the project/service:
a. Development stage
Lead agencies/entities
Citi Bank, Inter-American Development Bank
Other participating agencies/entities
--
b. Operational stage
Lead agencies/entities (op)
Citi Bank, Inter-American Development Bank
Other participating agencies/entities (op)
--
7. Main stakeholders/beneficiaries of the project
Other Government Agencies (OGAs)
8. Business process category of the project
Payment

B. Lessons Learned

9. Summary description of the project/service
Brief Summary

The project used the LACChain Blockchain Network to power payments from the IDB’s headquarters in Washington, D.C., to a recipient in the Dominican Republic.

What is the LACChain global alliance? | by LACChain Alliance | Medium
 

a. Objective(s)

The goal of this PoC was to demonstrate that it is possible to use blockchain technology to accomplish cross-border payments while reducing costs and times as well as increasing traceability of the transactions, intermediaries, and fees.

b. Business need for the project (background)

The IDB sends several thousands of transactions a year from the headquarters (HQ) in Washington DC the Latin American and the Caribbean Region, to fund projects through grants and loans, fund the country offices (COFs), and make payments to local service providers. These transactions usually involve IDB’s Agent Bank, an intermediary Bank that facilitates the currency exchange, and the Beneficiary’s Bank. This leads to high transaction fees, reducible times, and improvable traceability.

c. Business process covered*

Payment

d. Overall architecture and functionalities*

This PoC worked with b-money. Specifically, two stable coins were created, pegged to the US Dollar and to the Dominican Peso, respectively. These tokens were always backed-up by fiat money in bank accounts that is guaranteed by Citi Bank as the Bank Agent and the financial institution providing the liquidity of b-money on the blockchain. This development has been based on an Ethereum Request for Comments (ERCs) that defines a set of rules required to implement tokens for the Ethereum ecosystem: the ERC-2020. The ERC-2020, a set of extensions of the ERC-20, known as the E-Money Token Standard, is “a proposed standard for e-money, bank and central bank money issued tokens, with extended functionalities such as holds, clearance, detailed compliance, funding, and payout”. The E-Money Token is “working with global institutions, such as the International Telecommunications Union (ITU) and the Enterprise Ethereum Alliance (EEA) to become the standard for the use of real financial money on blockchain” and has been recognized in the Technical Report elaborated by the ITU’s DLT Focus Group on August 2019.

e. Relevant document/figure
--
10. Documents and data exchanged via the project
--
11. Data models/databases, proprietary solutions, hybrid approaches

LACChain system

12. Main challenges faced during the project

Privacy and correlations: one of the main challenges when using blockchain networks as the public ledgers for the exchange of digital assets, and particularly tokenized money, is that transactions are immutably recorded and completely exposed to anyone with access to the public network. Blockchain not only does not guarantee privacy by default but presents very relevant challenges to erase potential correlations and personal identifiable information from transactions made in different contexts by the same blockchain account. Therefore, if the identity behind a pseudonymous account is discovered in one context, the entire transaction history of that identity is revealed because of the public character of the blockchain. One potential solution is the use of mixers. Mixers allow to erase the traceability of blockchain transactions in a way that it is not possible to link the sender with the recipient. Blockchain-based identities: today, digital identity is far from ideal. In general, there are not suitable ways to identify individuals electronically with the maximum level of assurance, which is necessary to provide digital services with all the guarantees. Blockchain networks are not exempt from this. With the aim of overcoming this, a set of standards and tools coming up under the scheme Self-Sovereign Identity (SSI), such as the Decentralized Identifiers (DIDs) and the Verifiable Credentials (VCs) from the W3C are intended not only to improve the interoperability, ownership, pseudonymity, portability, recovery, scalability, and security of the digital identification and authentication of individuals, but to also match real identities with blockchain accounts in a trustable, reliable, and essential way to guarantee compliance with KYC and AML processes when dealing with tokenized money -and other digital assets- living in blockchain networks Key management: key management is one of the biggest challenges when dealing with blockchain tokens of any kind. For large institutions it is easier to use key vaults or HSMs to store the private keys and leverage their corporate solutions for the identification of employees, allowing each individual to use their private keys indirectly when generating blockchain transactions from friendly interfaces. For individuals, it is not straightforward. Digital wallets are the personal and private repositories proposed in the SSI model for this purpose, but there is still some work to be done around developing good mechanisms for things such as authorization to access the wallet authorization to use digital tokens, authorization to use the digital identity to access digital services, and recovery of private keys and credentials in case a digital wallet is lost or compromised. Transaction throughput and fees: when dealing with blockchain networks, transaction throughput and fees can become strong limitations. The number of transactions a blockchain network can process per second is and will always be limited, because of the time required to process them and reach consensus, and the block size. Similarly, incentive mechanisms in certain types of networks -in general permissionless- require paying a fee for each transaction. Shardings and second layer solutions for transaction processing such as state channels and rollups are interesting alternatives under development to guarantee scalability. Permissioned public networks with no transaction fees and incentives based in fixed memberships seem suitable to guarantee affordable costs.

13. Lessons learned from the project

All the transactions sent in the timeline of a month from the IDB HQ bank account to the account in Dominican Republic were accomplished successfully. This PoC was a single-banking effort, involving only Citi Bank as an intermediary. Real cross-border situations will generally involve two, including the sender’s Bank and the recipient’s Bank, or more. These two financial institutions will typically have their own smart contracts for the tokenization of money integrated with the core financial systems. Therefore, when the sender sends digital money minted by one financial institution and the recipient aims to cash out with a different financial institution, settlement is required. We understand that multi-purpose networks that enable payments using tokenized money are not suitable for settlements, as settlement networks require specific regulatory frameworks and governance models. Thus, we think that it might be necessary to develop clearing mechanisms that could also leverage blockchain networks that can be interoperable with commercial blockchain. For instance, two financial entities could provide tokenized money for their customers in a commercial blockchain network and settle payments in another specific purpose blockchain network, as shown.

14. Main benefit(s) of the project
--
14A. Elaborations/detailed description on benefits gained
--
15. Technical/financial/capacity building/other assistance
--
16. Future plan for expansion of the project
--
17. Other information or relevant references on the project
--
18. Relevant document regarding the project

C. Relevant Standards

20. Electronic message standard
20A. Electronic message standard supporting the project
--
20B. Type of standard for electronic message applied for the project
--
21. Technical communication standard
21A. Technical communication standard supporting the project
--
21B. Type of technical communication standard applied for the project
--
22. Security-related standards*
22A. Security-related standard supporting the project
--
22B. Type of security-related standard applied for the project
--
23. Other Technical Information
23A. Interface developed for data exchange with an internal system
--
23B. Other technical implementation information
The LACChain Besu Network utilized is a public-permissioned network 2 developed and maintained by the LACChain Alliance. This network builds on the Hyperledger Besu software, which is “an Ethereum client designed to be enterprise-friendly for both public and private permissioned network use cases”. This network incorporates the LACChain tecno-legal framework and is already being used by governments, academic entities, large corporations, and start-ups, among others, that are using it for free for different use cases including academic credentials, exchange of information between custom administrations, notarization of documents, and procurement processes. This network was chosen for being the biggest public-permissioned network in Latin-America and the Caribbean, with no transaction fees, and supported by a technical team that has been assuring its reliability since August 2019, when the network was launched.

The architecture of the PoC was designed and implemented in three layers: front-end, API and back-end, as described below:
- The front-end layer allows user interaction via a web interface that requires user authentication using a key vault. Front-end components include a React.js UI that integrates the Ethereum web3.js collection of libraries enabling interaction with the LACChain network as illustrated in the use cases sequence diagrams.
- The API layer consists of two endpoints, one endpoint exposes the business logic for users, roles and accounts, the other endpoint exposes container-based Citi-API-Proxy that provides transparent access to Citi’s WorldLink API

The back-end layer comprises:

- container-based Java/Spring Boot business logic application Management Service uses a container-based PostgreSQL database to manage users, roles, and account information.
- container-based Go application IDB_Service interacts with the Cross-Border Payments’ smart contracts for operations (Execute transfer, Dollars to exchange, Dollars to pesos, Pesos to recipient).
- container-based Eventeum application listens to the smart contract’s events using geth and JSON-RPC. In the LACChain network topology, writer nodes are the only nodes allowed to broadcast transactions to the network.