Highlights

2.1 General Description

This section gives an overview of the architecture for the cross-border platform we propose. It lays out the minimal requirements that allow deployment of the tools we presented in section 1. We specify the architecture of the platform in terms of participation, access, and assets that would be available. We then explain how the platform works for cross-border payments and the related financial infrastructure.

Settlement risk is an important friction in legacy cross-border payments. X-C addresses this friction by providing a form of central bank digital monies as settlement assets available to all participants. X-C also leverages new technologies and mechanism design to minimize risks of reneging on previous trade agreements. The proposed architecture for X-C is based on using digital monies issued by central banks to shorten transaction chains, allowing more direct transactions, and reducing counterparty and settlement risk. The platform provides programmable and final settlement in participant countries’ currencies.²⁶

More generally, the features of X-C’s design propose an improved financial infrastructure that enhances contract possibilities. This approach does not rely on networks of bilateral claims as corresponding banking does. Rather, it aims at increasing competition in cross-border payments. It allows smaller intermediaries to provide services directly in an environment where risks are better managed, as there are more opportunities for them to enter hedging and risk-sharing contracts. At the same time, X-C also addresses concerns that central banks may have in terms of non-resident unsupervised financial institutions holding their fiat money.

X-C’s architecture and design have the following key specifications. First, the platform is a common financial infrastructure for exchange and for entering financial contracts, where agents from participating countries would be able to transact. Second, the platform allows for greater competition to cross-border payment intermediation by opening access to bank and non-bank financial entities. Third, the platform includes a settlement asset for each currency that can be freely transacted inside the platform but still addresses limits to fiat money that central banks may want to impose on non-resident entities. Fourth, X-C has technological features that include a single ledger where participants’ accounts and contracts are recorded, the ability to program smart contracts, and to encrypt accounts, contracts, and information that flows in the platform. In the next subsections, we present X-C’s design in detail.

2.2 X-C’s Architecture

A multilateral platform for exchange and contracting is a financial market infrastructure set up for transactions between platform participants that maybe in different jurisdictions (“cross-border transactions”).²⁷ As such, it must have common rules, governance, standards, and technology that reduces risks and costs of exchange. While platforms can in principle provide “front-end” services to final users, here we describe the setup of a platform focused on “back-end” services and where financial intermediaries are responsible to provide services to their clients.

X-C has a “centralized” model with multiple currencies. Participants from different jurisdictions that are part of the platform would have accounts in the multilateral platform.²⁸ As such, X-C does not require modifying domestic systems. In principle, all participating jurisdictions’ currencies would be available on the platform. As greater participation of intermediaries helps increase competition, the design envisages access by banks and non-bank financial institutions, including payment service providers (PSPs). Still, under these common principles, each jurisdiction would decide the entities it would give access to X-C.

The platform’s design includes a final settlement asset for each participating country issued by its central bank. We call these assets “Certificates of Escrow” (CE). These CEs are issued one-to-one against central bank reserves. As a result, CEs are safe and homogenous and do not carry intermediaries’ risk. There are no interoperability issues, as CEs are native to the platform and are only issued and exchanged in it. This shortens chains, reduces balance sheet interconnections, and makes transactions faster, cheaper, and safer than bilateral private claims. The speed, cost, and safety features of CEs also facilitate subsequent contracts based on the same CEs, as is discussed in section 4. CEs can be committed under contracts and, so committed, it is escrowed until released by a specified contingency.

Settlement is done by transferring value on the platform’s ledger by moving CEs between agents’ accounts. When there is exchange of different CEs, agents with funds in their accounts can enter smart contracts to eliminate risks in the transaction.²⁹ An example of this are hash-time locked contracts, explained further below.³⁰

All participants from all countries who participate in the platform would be able to hold both domestic and foreign CEs in each of their platform accounts. This is intended to allow for more competition in market making for each currency pair.³¹ For multi-currency cross-border payments to be feasible, it is necessary that at least one agent must be able to “intermediate". In principle, this can be done by final users (e.g., when tourists pay in cash), by banks (that have multi-currency nostro and vostro accounts or accounts at CLS), or by Central Banks (that hold international reserves).

A distinctive feature is that CEs are always convertible at par for entities that are regulated by the central bank and are allowed to hold reserves.³² But CEs are not convertible to reserves for non-regulated entities (typically, non-residents that have access to the platform).³³ The reason is that the use of central bank money to settle cross-border transactions is limited. Other than paper currency, central banks have not given non-regulated entities access to their balance sheets. Thus, typically central banks’ reserves cannot be held by non-residents, and these cannot be used to pay or be paid across borders.³⁴

The parity of each CE with domestic fiat would be pinned down by the competition among regulated entities that have access to central bank reserves and by the commitment of each central bank to always redeem CEs at par. Any difference in market value between reserves and CEs of a given fiat money would be subject to riskless arbitrage by these domestic entities. This also has foreign exchange (FX) implications. For non-residents, the expectation that they will find a counterpart that accepts domestic CEs at the same rate as the value of fiat outside the platform will underpin the equality between the value of FX currency pair and the corresponding CEs value pairs.³⁵ Thus, having deep markets to exchange CEs is key for an efficient platform and ensure that all can find counterparts and to avoid concentration.³⁶ We discuss the challenges and potential solutions of thin FX markets in section 4.

Settlement risk is eliminated by immediate guaranteed settlement at a point in time or guaranteed contracted settlement at future designated dates and states.³⁷ The platform does this by providing PvP and DvP. In effect, messaging and settlement, or messaging and committed contracts, are linked, no longer separated in time. Thus, cross-border transactions using X-C are final and irrevocable.³⁸

Figure 2.1 illustrates how participants’ accounts are funded using reserves. In this example, in Step 1 a PSP from country A (PSPA) funds its account with CEs from its country (CEA) using reserves, and a commercial bank from country B (BankB) does the respective operation to fund CEB. Both central banks reflect the respective changes in their liabilities. In step 2, PSPA and BankB exchange their CEs at an agreed FX rate. In principle, this transaction could be done relying on an outside fixing rate (an “oracle”), by a bilateral agreement as typical in over-the-counter (OTC) trades, or in a centralized trading environment such as dealers’ market or multi-currency auctions. In section 4 we discuss this in more depth and highlight the benefits of centralized exchanges to reduce fragmentation, foster market depth, and increase competition.

CE issuance and cross-border

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: This figure illustrates the issuance of CEs in country a and b against reserves. The dotted boxes denote assets and liabilities that are recorded in the platform’s ledger. In country a, step 1 shows a PSP exchanging reserves for CE, and in country B a commercial bank exchanging reserves for CEs. In step 2, country a’s PSP exchanges CE_A for CE_B with country b’s commercial bank. In general, both intermediaries (PSP_A and Bank_B) can hold CE_A and CE_B. In this example, however, only PSP_A can hold Reserve_A and only Bank_B can hold Reserves_B.

• Download Figure
• Download figure as PowerPoint slide

View Full Size

CE issuance and cross-border

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: This figure illustrates the issuance of CEs in country a and b against reserves. The dotted boxes denote assets and liabilities that are recorded in the platform’s ledger. In country a, step 1 shows a PSP exchanging reserves for CE, and in country B a commercial bank exchanging reserves for CEs. In step 2, country a’s PSP exchanges CE_A for CE_B with country b’s commercial bank. In general, both intermediaries (PSP_A and Bank_B) can hold CE_A and CE_B. In this example, however, only PSP_A can hold Reserve_A and only Bank_B can hold Reserves_B.

• Download Figure
• Download figure as PowerPoint slide

CE issuance and cross-border

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: This figure illustrates the issuance of CEs in country a and b against reserves. The dotted boxes denote assets and liabilities that are recorded in the platform’s ledger. In country a, step 1 shows a PSP exchanging reserves for CE, and in country B a commercial bank exchanging reserves for CEs. In step 2, country a’s PSP exchanges CE_A for CE_B with country b’s commercial bank. In general, both intermediaries (PSP_A and Bank_B) can hold CE_A and CE_B. In this example, however, only PSP_A can hold Reserve_A and only Bank_B can hold Reserves_B.

• Download Figure
• Download figure as PowerPoint slide

Figure 2.2 shows how a resident of country A (“Alice”) could make a payment to a resident of country B (“Bob”) to cancel a debt she may have with him that is denominated in B’s currency. In step 1, Alice sends an order to her PSP to pay Bob and thus, the bank reduces Alice’s deposits by the equivalent in B’s currency. For instance, this could be done using a “best execution” protocol or an FX reference rate provided by the platform.³⁹ In step 2, PSPA sends CEB for the specified amount. BankB receives it and, in step 3 it increases Bob’s deposits for that amount. In step 4, Bob confirms receiving the deposit and cancels the IOUB. For comparison, Figure 2.3 shows how a similar transaction would be done using correspondent banking and messaging.

Cross-border payment using X-C.

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: The figure below shows how intermediaries can use the X-C platform to send encrypted transactions on behalf of their clients. Central banks are depicted as they are participants in X-C and needed for initial funding (see figure 2.1 for that) but they are not needed for this specific transaction (see figure 2.2). Balance sheets would adjust so that a resident of country A (“Alice”) can use X-C to cancel a debt she may have with a resident of country B (“Bob”). Transactions are shown sequentially for clarity. First, Alice sends an order to her PSP to use funds in their deposit account to make a transfer to Bob. These are converted to currency B by her PSP at a rate FXA,B. Using X-C, the PSP then sends CEB to Bob’s bank. BankB credits deposits to Bob, and Bob cancels Alice’s IOUB.

• Download Figure
• Download figure as PowerPoint slide

View Full Size

Cross-border payment using X-C.

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: The figure below shows how intermediaries can use the X-C platform to send encrypted transactions on behalf of their clients. Central banks are depicted as they are participants in X-C and needed for initial funding (see figure 2.1 for that) but they are not needed for this specific transaction (see figure 2.2). Balance sheets would adjust so that a resident of country A (“Alice”) can use X-C to cancel a debt she may have with a resident of country B (“Bob”). Transactions are shown sequentially for clarity. First, Alice sends an order to her PSP to use funds in their deposit account to make a transfer to Bob. These are converted to currency B by her PSP at a rate FXA,B. Using X-C, the PSP then sends CEB to Bob’s bank. BankB credits deposits to Bob, and Bob cancels Alice’s IOUB.

• Download Figure
• Download figure as PowerPoint slide

Cross-border payment using X-C.

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: The figure below shows how intermediaries can use the X-C platform to send encrypted transactions on behalf of their clients. Central banks are depicted as they are participants in X-C and needed for initial funding (see figure 2.1 for that) but they are not needed for this specific transaction (see figure 2.2). Balance sheets would adjust so that a resident of country A (“Alice”) can use X-C to cancel a debt she may have with a resident of country B (“Bob”). Transactions are shown sequentially for clarity. First, Alice sends an order to her PSP to use funds in their deposit account to make a transfer to Bob. These are converted to currency B by her PSP at a rate FXA,B. Using X-C, the PSP then sends CEB to Bob’s bank. BankB credits deposits to Bob, and Bob cancels Alice’s IOUB.

• Download Figure
• Download figure as PowerPoint slide

Cross-border payments using correspondent banking

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: The figure illustrates how a cross-border payment is done using correspondent banking. Each bank must adjust bilateral assets and liabilities while sending payment instructions using Swift messages. Balance sheets show how they use vostro and nostro accounts to create bilateral exposures and move value across borders. For simplicity, in this example, bank A is assumed to make the FX conversion to currency B using its balance sheet.

• Download Figure
• Download figure as PowerPoint slide

View Full Size

Cross-border payments using correspondent banking

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: The figure illustrates how a cross-border payment is done using correspondent banking. Each bank must adjust bilateral assets and liabilities while sending payment instructions using Swift messages. Balance sheets show how they use vostro and nostro accounts to create bilateral exposures and move value across borders. For simplicity, in this example, bank A is assumed to make the FX conversion to currency B using its balance sheet.

• Download Figure
• Download figure as PowerPoint slide

Cross-border payments using correspondent banking

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: The figure illustrates how a cross-border payment is done using correspondent banking. Each bank must adjust bilateral assets and liabilities while sending payment instructions using Swift messages. Balance sheets show how they use vostro and nostro accounts to create bilateral exposures and move value across borders. For simplicity, in this example, bank A is assumed to make the FX conversion to currency B using its balance sheet.

• Download Figure
• Download figure as PowerPoint slide

X-C is a dedicated infrastructure for cross-border transactions that would complement existing domestic payment systems and would not require harmonization of existing infrastructures (other than the connection to the platform). As described above, central banks would provide the on-off ramp for domestic currency funding and redemption of funds. Participants would retrieve information and send instructions to the platform (including contracts) using APIs.⁴⁰ The only important feature would be the 24x7 availability of a wholesale RTGS and access to central bank reserves to CE conversion as this acts as the bridge between traditional rails and the platform.⁴¹

The modularity of X-C would also have the benefit that central banks could develop new solutions (including CBDCs) for domestic use without being constrained by potential interoperability requirements. Having CEs as a dedicated digital liability for cross-border transactions would allow central banks to pursue the design of their CBDCs to achieve their domestic policy goals, rather than having to coordinate it.⁴² Box 2.1 compares CEs to other types of money.

^{Box 2.1.}

How do CEs compare with other payment instruments?

CEs allow more agents access to central bank reserves. It opens access to non-bank financial institutions, NBFIs, and payment-system providers, PSPs, and to non-residents. While non-residents may have access to paper currency, in practice this is not useful for high value cross-border transactions or wholesale payments in general

Compared with commercial bank deposits and stablecoins, each country’s CE provides settlement finality and, as it is a central bank liability, the same as are paper currency, reserves, and CBDC, it is homogeneous and has no counterparty risk. CEs share an important dimension with stablecoins as both are programmable (see section 1.2). A key comparison is with CBDCs. While access to those may vary depending on the country and could potentially be used by non-residents (and thus be useful for cross-border payments), CBDCs may be designed for specific country circumstances and are not expected to be coordinated internationally to be on the same ledger. Thus, while CBDCs may be indeed programmable for their users, cross-border transfers are sometimes an afterthought. With CEs we directly address the need for a multi-currency platform.⁴³

^{Table 2.1.}

Alternative types of monies as payment instruments

^{Table 2.1.}

Alternative types of monies as payment instruments

View Table

^{Table 2.1.}

Alternative types of monies as payment instruments

Platforms must have common rules, governance, and standards, and a technology to reduce risks and costs of exchange (see CPMI-IMF-WB 20222). All these can be holistically called part of the “infrastructure” as it implies the provision of public goods that all participants benefit from. This common infrastructure can also contribute to increasing transparency in cross-border payments: procedures are clearly specified, must be followed, and are enforceable.⁴⁴

The operation of the platform can benefit from the automation that its technological features enable. The different “actions” in the platform can be executed by computer code (smart contracts) and would not have to rely on a supranational entity to perform them. Put differently, the solutions we propose in the following sections are done by code that can read and act on the platform and can protect and manage data to ensure trust while allowing new business models to form. Financial transactions like simple cross-border payments, FX conversion, or more complex hedging or risk sharing agreements (e.g., see section 4.3) are written and enforced as “smart contracts” (computer code). This is achieved thanks to such code stored and executed in the platform’s ledger.

Transactions and changes in accounts’ holding can be validated by a central authority (“single node”) or by more than one (“multiple nodes”). This decision will vary depending on the agreed governance, the trust participants may have on a central authority, and the required need of resilience in the ledger.⁴⁵ Thus, the choice of the underlying technologies and whether validation should be done with DLT or centralized databases should be weighed against differences in terms of cyber-security, resiliency, and governance.

For example, a centralized ledger architecture can entail efficiency gains, but it also concentrates risks (if this ledger were to be attacked or corrupted). Distributed computing can also make the physical infrastructure more resilient.⁴⁶ A centralized ledger, however, can also concentrates the control mechanisms and tools to detect misbehavior. Concentrating transaction and operations provide the data for algorithms implementing automatic detection of suspicious activities to function (for instance the “siphoning” of funds, either from abnormally few numbers of accounts, or to abnormally few numbers of accounts). All these issues must be considered together with governance models. A cost-benefit analysis on technology choices is beyond the scope of this paper and is left for further work.

New multilateral platforms such as X-C could be operated under different structures and with different roles for the public and private sector (CPMI-IMF-WB 2022). Fair participation requirements, pricing, open access and governance arrangements which uphold the policy objectives of competition and interoperability should be priorities.⁴⁷ As challenges may arise from large stakeholders, ensuring broad representation in decision making would be important.⁴⁸ The existence of different commercial interests, and divergent views on the cost-benefit analysis, may require public intervention from an early stage to allow the development of a platform to progress. Costs associated to establishing and sustaining a multilateral platform should also be considered and its fees, prices, and business model should also include cost-recovery considerations.

Risk management must be incorporated in design from early stages. Risks arise from financial integrity, operational and cybersecurity risks, but also financial stability, sustainability of the ecosystem needed around the platforms, and implementation risks (for instance, in failing at developing sufficient overall adoption or adoption in targeted participants).⁴⁹ We go back to financial integrity issues and data management in section 3. We discuss financial stability risks in section 4.

To the extent possible, design should consider how to minimize the needs to harmonize legislation relative to data, digital ID, commercial and financial transactions, insolvency, and central banking and payments. For instance, if inconsistency between national insolvency regimes is not addressed, the finality and irrevocability of payments may not be achieved. Moreover, the governance of the platform and the design of contractual agreements between the participating countries might require legal reform.⁵⁰ Also, smart contracts still suffer in many jurisdictions from legal uncertainties (and therefore from legal risks) especially in terms of the application of commercial and financial law.⁵¹

The specific design of such arrangements could be tailored to the scope that a platform may have. For instance, a platform in a region may have a different governance design relative to another one in a different region. Sufficient compatibility across potential X-C regional platforms, however, would be desirable to allow for interoperability among them.⁵²

2.3 X-C as a Dynamic Ledger for Contracting

There are three key technological features in X-C. These play different roles in the different use cases. These are (1) a common and unique ledger with participants’ accounts, (2) programmability, and (3) encryption techniques.⁵³ We outline different ways in which these components can be recombined or unbundled depending on the use case, and how several of these combinations can satisfy our technological requirements.

X-C’s first key technological feature is the unique state of the common ledger. This ensures that all participants interact with the same dataset on who has or owns what. Put differently, participants’ accounts must be always mutually consistent. In computer science terms, X-C needs to ensure a unique state of shared information. When a transaction or contract is signed or executed, this must cause a state change in the database and an update in the information that agents may retrieve from it.

With the introduction of a unique state of shared information, settlement risks are mitigated. Once a trade contract or transfer is operated on this ledger, then the agreement and ownership are definitely recorded, not only validated by direct parties but also verifiable by all in the encrypted ledgers. This allows for “trustless” exchanges or transactions, but also allows participants to pledge assets that they do not have yet but have committed to buy (for instance through rehypothecation of smart contracts—more on this later).⁵⁴

Our proposal generalizes schemes being developed for domestic⁵⁵ or cross-border uses⁵⁶ by creating the appropriate escrow accounts on a multilateral contracting platform, instead of staying within platforms centered around one private balance sheet or a limited function or use case. X-C’s objective is to provide different complementary functions under the same umbrella, as this would result in greater efficiency, interoperability, and competition.

X-C’s second key technological feature is its programmability. Put simply, this means that smart contracts can be written to read and potentially modify the data recorded in the platform’s ledger. A smart contract is then a reusable snippet of code (a program) that is published into the shared unique ledger of the platform. The smart contract code can be executed via a transaction request to its address, and developers can write executable applications into the shared unique ledger by publishing smart contracts.⁵⁷,⁵⁸ Because the ledger is common to all participants and a unique state would be ensured, commitment of assets in one of these programs have to be non-conflicting with commitment of the same assets in another one of these programs.⁵⁹

X-C’s third key technological feature is the use of cryptography. Encryption is the process of encoding information to protect messages’ content and authenticity, controlled revelation to maintain market depth, while securing senders and receivers’ identities and privacy, providing additional guarantees on authenticity, commitments, and enforcement of contracts can help solve frictions that constrain financial contracts.

Encryption uses a key pair that consists of a public key, which can encrypt messages, and a private key in that space which is used for decryption of messages. The public key can be seen and used by anyone wishing to send something in an encrypted fashion to the holder(s) of the private key, which is the only one who can read the content of this encrypted message. Properties of the encrypted space make it virtually impossible to decipher an encrypted message without the private key that was used as part of generating it. Symmetrically, for an outgoing message, the private key can be used to generate a digital signature which can be verified by those knowing the sender’s public key. Moreover, they can also verify the origin of the message and that the message has not been modified since it was signed. Likewise, the sender cannot repudiate the message after signing. For more details on this and other aspects of encryption see Townsend, Zhang, and Zhao (2022).

Encryption can solve communication and commitment problems. It further allows for a larger set of outcomes by making information flows a decision variable in the design of the contracts.⁶⁰ With modern privacy-preserving cryptography, a designer can also rely on an intermediate state of information, that can now be not only either fully public or alternatively fully private, but rather in-between these extremes. For example, pieces of information can be inputs to aggregation and computation, while remaining fully private for all the participants. That is, code and mathematical operations can be performed on a group of encrypted messages, and the result can still be revealed, without revealing the initial inputs.⁶¹ Just as the ability to choose different production technologies may expand the “possibilities frontier,” expanding the information flow technologies will typically result in an outcome closer to one without information frictions.

We use these three technological features to offer new designs tailored to the economic and policy problem of cross-border exchange. The rules for market exchange, contracts, and mechanisms can thus encode ex ante contingent actions or states and automate execution of these actions, so that one party cannot renege on a contract they had agreed on. The common and unique state of the ledger ensures that all agents retrieve the same information from the platform and trust that what others observe is consistent with this information. The smart contracts execute contractual arrangements that maximize participants’ outcomes without the need for a trusted third party to implement or verify the contractual arrangement.⁶² And encryption allows participants to share private information with the smart contracts without revealing it to other parties.

A first application of these tools is the use of smart contracts to address limited commitment in exchanges. Limited commitment is an important obstacle in legacy cross-border payments and gives rise to trade failures. Trade and settlement take place at distinct times. Thus, a holder of an asset may renege at the time of settlement on a previous trade agreement, to pass the asset back to the issuer, or to a third party as per a multilateral trade agreement. This can be a function of a change in circumstances between the time of trade and the time of targeted settlement.

Bilateral agreements may reflect the best intentions of both parties at the time of trade, but with limited commitment, the seller of the asset, or the purchaser as provider of liquidity, may not relinquish the relevant object at time of settlement, or at least, not at the agreed upon price. This hold-up problem is aggravated by the evolution of private unobserved underlying states which makes a party want to choose the most advantageous time of settlement or renege entirely. In short, there is counterparty risk when trade and settlement are separated. With that risk, trade is limited or may even collapse so no transactions are carried out.

A solution to the commitment problem is a system in which trades are carried out with code and ensures PvP and/or DvP. Under bilateral or multilateral smart contracts there can be no reneging, even if circumstances change. This means that if the delivery of an asset is promised, this asset will be taken automatically by the smart contract. This eliminates settlement uncertainty from counterparty risk. As Lee et al. (2022a, 2022b) show this is closely linked to the idea of “instant settlement.”⁶³ Implementing this with escrow accounts (with either the assets locked in, or a commitment to deliver the assets from another rehypothecated smart contract), or with atomic swaps type PvP, can address the limited commitment and trade fails problem.

Atomic swaps use a smart contract to commit agents to an agreed simultaneous exchange of a smart contract, like a committed “handshake.” Figure 2.4 illustrates how atomic swaps work with a simple example. Two agents (Alice and Bob) agree to exchange their domestic CEs (A and B, respectively) for future use on the platform. They enter a standard contract to exchange at a given FX rate.⁶⁴ Alice and Bob lock their respective CE funds in escrow accounts that are managed by the smart contract. The contract executes the exchange and unlocks the escrow only when both participants provide their temporary key (s) and “shake hands".⁶⁵ This protocol avoids reneging on the exchange, even if done sequentially: Bob observes that Alice entered her temporary key to get the CEs she wanted (and that were in escrow), and then can copy and enter it to get the CEs he wanted (and that were in escrow). In practice, the figure below should be made symmetric so that Bob also has a temporary key and is also able to initiate the sequence, ensuring that no agents can block it once committed. There can be a short time window to enter these temporary keys, and were the contract not to receive the keys, original funds would be returned to agents.

Hash Time Lock and Commitment, guaranteed instantaneous trade and settlement

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Source: Adapted from Narula (2018).Note: the smart contract contains the condition “unlock Bob’s escrow to Alice if she sends an s to the contract such that it produces H(s) = x”. Now that Alice sent her s to unlock Bob’s escrow account, Bob can just copy this s and also send it to the smart contract, which has the similar condition “unlock Alice’s escrow account to Bob if he can send an s that produces H(s)=x”.

• Download Figure
• Download figure as PowerPoint slide

View Full Size

Hash Time Lock and Commitment, guaranteed instantaneous trade and settlement

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Source: Adapted from Narula (2018).Note: the smart contract contains the condition “unlock Bob’s escrow to Alice if she sends an s to the contract such that it produces H(s) = x”. Now that Alice sent her s to unlock Bob’s escrow account, Bob can just copy this s and also send it to the smart contract, which has the similar condition “unlock Alice’s escrow account to Bob if he can send an s that produces H(s)=x”.

• Download Figure
• Download figure as PowerPoint slide

Hash Time Lock and Commitment, guaranteed instantaneous trade and settlement

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Source: Adapted from Narula (2018).Note: the smart contract contains the condition “unlock Bob’s escrow to Alice if she sends an s to the contract such that it produces H(s) = x”. Now that Alice sent her s to unlock Bob’s escrow account, Bob can just copy this s and also send it to the smart contract, which has the similar condition “unlock Alice’s escrow account to Bob if he can send an s that produces H(s)=x”.

• Download Figure
• Download figure as PowerPoint slide

These ideas can be expanded to dynamic future and conditional versions of atomic swaps. For example, these can require the seller to have contractual evidence that she will be in possession of the asset at the specified time. Buyers can then use the platform’s ability to check that a contract has an underlying asset, thus allowing for rehypothecation of the contract (of the asset to be delivered). In borrowing and lending agreements, the contracts can also have a conditional provision which include the option of default and collateral forfeit. But full collateralization is not needed in all contracts, as penalties can be incorporated into the design.⁶⁶ Thus, as a general principle, not all trades on the digital contracting platform need to be fully collateralized with seizable assets that are escrowed. The platform’s ability to check that a contract has an underlying asset allows for rehypothecation and interlinking contracts, thus saving collateral and conserving liquidity.

A second example of how the technological features can be exploited is the design of insurance agreements. Figure 2.5 illustrates how smart contracts and cryptography can be used in a bilateral risk sharing contract. Here, Alice and Bob agree on a smart contract where they commit to exchange goods at a given price, and in a guaranteed, PvP fashion. The maximum possible premium is put in escrow, in advance of the shocks. Both agents experience shocks to their balance sheets (for example, due to other trades or to market revaluations), but these are private. Under the contract, they are given an incentive to announce these shocks honestly, that is, to send messages which are truthful. But the messages, encrypted, go into the code and are not revealed to others. The code then generates transfers, which can be positive or negative, on the two parties’ balance sheets. In this insurance example, the risk across balance shocks is pooled, and one party is paying a premium and the other receiving an indemnity. See Townsend and Zhang (2020) for a specific example.

Smart contracts, cryptography, and mechanism design.

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: this figure portrays the balance of each of the two agents, A and B, which is subject to shocks. These shocks are announced as encrypted messages, going into the smart contract code. That pre-programmed code solves the optimal design problem, so that as a function of encrypted messages a transfer among the two parties is executed, giving a new state for the balance sheets.

• Download Figure
• Download figure as PowerPoint slide

View Full Size

Smart contracts, cryptography, and mechanism design.

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: this figure portrays the balance of each of the two agents, A and B, which is subject to shocks. These shocks are announced as encrypted messages, going into the smart contract code. That pre-programmed code solves the optimal design problem, so that as a function of encrypted messages a transfer among the two parties is executed, giving a new state for the balance sheets.

• Download Figure
• Download figure as PowerPoint slide

Smart contracts, cryptography, and mechanism design.

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: this figure portrays the balance of each of the two agents, A and B, which is subject to shocks. These shocks are announced as encrypted messages, going into the smart contract code. That pre-programmed code solves the optimal design problem, so that as a function of encrypted messages a transfer among the two parties is executed, giving a new state for the balance sheets.

• Download Figure
• Download figure as PowerPoint slide

A third example is the implementation of auctions. In an auction, multiple parties bid over an object. The incentives for participants to bid honestly their valuation of the object are part of the design of the auction.⁶⁷ Observing the different bids and allocating the object to the winner would require a trusted auctioneer that should act non-strategically. The role of the auctioneer can be assigned to a smart contract that observes encrypted bids, ranks them, and determines the correct outcome of the auction (that is, who the “winner” is and what price she must pay). Buyers can audit the code and be assured it works properly and accomplishes the objective of the auction. Thus, the smart contract replaces the third party and creates trust in the mechanism. See Townsend and Zhang (2020) for a specific example. In section 4 we discuss how this can be applied to FX price determination in a multi-currency environment as X-C’s.

2.5. Contracts’ Governance: “Supervised Open Contracting”

A fundamental aspect of X-C is how smart contracts could be deployed, for which use cases, and by whom.

The explosion of innovation triggered by the Internet and its open and layered architecture provides guidance. A key for this were Internet’s common protocols, especially open ones—as emphasized by the Digital Currency Initiative at MIT in their design of a CBDC prototype. More broadly, engineers from the IT industry often refer to the Open Systems Interconnection model (OSI model) to abstract in different layers the communications happening in a computing system. Within an OSI layer, communications are organized via “protocols,” which are agreed ways for all participants to interact. These are executed by components of an OSI layer speaking a common language (for the Internet, browsers are the components executing the common language of HTTP).

For the Internet, for instance, these shared standards allowed users to post messages and host them, create content, and post them at a website address that directs other users to the hosted content. From an OSI point of view, at the base level of Internet protocols lies Ethernet, which is how two computers can be connected to each other. On top of that lies TCP/IP, which specifies how to route messages in a network. Then the World Wide Web, and other layers come next. At each layer different successful companies provided unforeseen improvements to the overall architecture by developing their new layer, stacked on top of existing protocols. And even while they do so, these companies do not “own” the protocols on which they were based, nor do they control them. Each layer has a different stewarding body that oversees its deployment and potential changes over time.

The openness and upgradability of this architecture is a desirable model that X-C aims to reproduce (in an economically safe and regulatory compliant fashion), as “future proofing” the infrastructure and contract structure would ensure that the investment to adopt it would pay off over a longer period of time. Figure 2.6 illustrates this analogy between OSI and digital payment technology stacks.

X-C as a protocol stack

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

• Download Figure
• Download figure as PowerPoint slide

View Full Size

X-C as a protocol stack

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

• Download Figure
• Download figure as PowerPoint slide

X-C as a protocol stack

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

• Download Figure
• Download figure as PowerPoint slide

There are trade-offs between how open versus standardized protocols can be. For instance, open-source smart contracts are easy to standardize, but open standards like ISO20022 for payment information require more coordination and governance. Hence a layered architecture and open protocols can take a long time to develop, which is an argument to take into account existing successes in open protocols while designing a new system, so that the resulting platform builds on these existing protocols instead of replacing them.

In X-C (potentially pre-selected) participants could propose a smart contract to be deployed, and if it is validated by the platform operator or its oversight/governance bodies, then it can be integrated within the platform and used by any participant. X-C would start with “templates” that could be adopted. For example, smart contract templates for exchange via centralized multi-currency auctions, forward and risk sharing contracts could be proposed in follow-up papers and prototypes. The open access ensures competition and pricing on the platform, again, provided security and regulatory audits of the proposed contract to be deployed on the platform pass specified criteria.

With a library of smart contracts that can be deployed if approved, and with open contracting for participants of the platform, the objective is to foster competition, in which we can let users come up with contracts and code tailored to their needs and their existing relationships.

Highlights

• X-C can deal with data, retain privacy, and comply with domestic and international regulations. X-C leverages cryptography to enable regulators and compliance officers to conduct checks, monitor and audit in a privacy-preserving fashion. Financial integrity checks and capital flow management measures (CFMs) encompass two sets of rules and regulations that can make cross-border payments slower, riskier, and more expensive.

• In the case of financial integrity, a major challenge is the required harmonization of KYC frameworks which requires multilateral coordination to ensure that the information generated in each country is trusted by others. CFMs are unilateral rules imposed by each country on resident or non-resident agents, so there is no need for inter-jurisdictional agreements.

• Strong privacy can be retained while preventing untraceable transactions by leveraging “credential providers” and control agencies together with cryptographic proofs and checks. This allows decoupling controls and user authorization from transaction submission and execution.

• “Credential providers” issue anonymous credentials, which ensure that only authorized persons can use the system while simultaneously protecting their identities. These credentials can be associated with actions that are outside the system (“off-ledger”) such as identity or with actions inside the system (“on-ledger”) such as limits to certain transactions amounts.

• The functionalities of X-C allow it to manage efficiently and in a privacy preserving way the information generated at the local level, to identify and vet individuals or firms that X-C ’s participants may want to serve. For example, a transaction order can read a list of sanctioned individuals and attach a cryptographic proof that the individuals participating in a transaction were vetted and are compliant with, for example, AML-CFT rules.

• When CFMs are applied to holdings within the platform’s common ledger, the programmability can greatly simplify transactions involving CFMs. In this case, all the information needed for compliance is in the platform’s ledger, so smart contracts can read it and apply the CFM. When CFMs involve information generated outside the platform this requires a “bridge” so smart contracts can read that information. In contrast, CFMs that are applied by administrative decisions would be unlikely to allow for more efficiency.

This section explains how X-C can deal with data, retain privacy, and comply with regulations. X-C leverages cryptography to enable regulators and compliance officers to conduct checks, monitor and audit in a privacy-preserving fashion.⁶⁸ Financial integrity checks and capital flow management encompass two sets of rules and regulations that can make cross-border payments slower, riskier, and more expensive.

Information generated outside the platform will be needed to comply with both financial integrity and CFMs (for example, information on customers IDs, and a sanctioned individuals list, or on financial positions on ledgers not connected to X-C). In the case of financial integrity, a major challenge is the required harmonization of KYC frameworks. This will need to include multilateral coordination to ensure that the information generated in each country is trusted by others and that the adequate safeguards are put in place to ensure the quality and reliability of the information.⁶⁹ CFMs are unilateral rules imposed by each country on resident or non-resident agents, so there is no need for inter-jurisdictional agreements. In both cases, this section illustrates how X-C can help to reduce the costs and risks by automatizing compliance with these rules while preserving privacy.

The role of data (and the type of data collected or generated by X-C) is wider than what is discussed in this section. Data is not limited to user privacy, as aggregated anonymized data, non-user specific data, or trends may represent significant value for both private sector’s participants and would play an important role in adoption of X-C (see Rizaldy and Sun (2022)). Aggregated data can also play an important role for policy makers—specially to monitor financial stability (see section 4.3 for a discussion). Unpacking the type of non-private data available on the platform could also highlight the possibility of new functionalities, such as descriptive analytics (getting the pulse on what is happening live), diagnostic analytics (identifying emerging issues and their root cause), or even predictive analytics, possibly leveraging artificial intelligence. These issues are beyond the scope of the paper but deserve careful investigation in future work.

3.1. Privacy in Digital Payment Systems: Separation of Roles and Dedicated Cryptographic Schemes

Current designs of CBDC that aim to promote strong privacy while preventing large-scale flows of untraceable money do so by decoupling controls and user authorization from transaction submission and execution, leveraging existing controls agencies and using cryptographic proofs and checks.⁷⁰

In general, separating controls from transactions allows for a very high degree of privacy. The intermediaries involved could be made to not see the identities of the sender and the recipient of a transaction flow, nor the amount involved. However, the relevant parties would receive cryptographic proof that the users and their transactions are compliant with rules. Transactions without a valid proof could be automatically rejected.

The approach usually followed to operationalize this is to design systems that integrate two cryptographic components. First, “credential providers” issue anonymous credentials, which ensure that only authorized persons can use the system while simultaneously protecting their identities. These credentials can be associated with actions that are outside the system (“off-ledger”) or with actions inside the system (“on-ledger”). Off-ledger validation requires credential providers to attest that something is indeed true. For example, whether the sender or the recipient of a payment is who she says she is. On-ledger validation can be done directly by the system, for example, checking that a certain transaction amount is not above a specified limit.⁷¹,⁷²

By applying this, details of transactions sent to X-C can be hidden in cryptographic commitments, and transactions themselves are authorized using digital signatures. This is illustrated in Figure 3.1, from one of MIT Digital Currency Initiative’s work proposals. In the example, all details of the transaction are encrypted: its amount, sender and recipient’s identities, and any metadata. All these would be encrypted on the platform so that no one can see its real value.⁷³ But the transaction would still carry a proof that a certain condition is true, without revealing anything else about the underlying information backing this proof. These proofs are called “zero-knowledge.”⁷⁴ This can, for instance, attest that the sender and recipients are cleared off criminal lists, and that the funds being transferred do not exceed limits imposed by CFMs in their respective jurisdictions, even while the exact transfer amount and/or identities are kept secret.⁷⁵

Delegating verification using zero-knowledge proofs

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: This figure inspired from MIT DCI’s design illustrates the two points above: first in step1 a “compliance provider” checks that a non-encrypted transaction is indeed the one associated with the encrypted version provided, and that this transaction respects compliance rule XYZ. The compliance provider then issues a certificate that validates that this encrypted transaction is compliant with rule XYZ (the certificate is attached to the encrypted transaction, by for instance referring to its hash on the certificate—so that it is only valid for this encrypted transaction). Then at step 2 Alice can just submit this encrypted transaction (therefore protecting her private information, such as sender ID, recipient ID, transaction amount and other data), along with the certificate that this encrypted transaction is compliant, for the platform to process it, without gaining any private information. Different technologies could be used for the computation on top of encrypted transaction on the platform (such as zero knowledge described above), and the permissioned nature of our platform make these privacy preserving technologies much easier to implement than on public blockchains.

• Download Figure
• Download figure as PowerPoint slide

View Full Size

Delegating verification using zero-knowledge proofs

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: This figure inspired from MIT DCI’s design illustrates the two points above: first in step1 a “compliance provider” checks that a non-encrypted transaction is indeed the one associated with the encrypted version provided, and that this transaction respects compliance rule XYZ. The compliance provider then issues a certificate that validates that this encrypted transaction is compliant with rule XYZ (the certificate is attached to the encrypted transaction, by for instance referring to its hash on the certificate—so that it is only valid for this encrypted transaction). Then at step 2 Alice can just submit this encrypted transaction (therefore protecting her private information, such as sender ID, recipient ID, transaction amount and other data), along with the certificate that this encrypted transaction is compliant, for the platform to process it, without gaining any private information. Different technologies could be used for the computation on top of encrypted transaction on the platform (such as zero knowledge described above), and the permissioned nature of our platform make these privacy preserving technologies much easier to implement than on public blockchains.

• Download Figure
• Download figure as PowerPoint slide

Delegating verification using zero-knowledge proofs

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: This figure inspired from MIT DCI’s design illustrates the two points above: first in step1 a “compliance provider” checks that a non-encrypted transaction is indeed the one associated with the encrypted version provided, and that this transaction respects compliance rule XYZ. The compliance provider then issues a certificate that validates that this encrypted transaction is compliant with rule XYZ (the certificate is attached to the encrypted transaction, by for instance referring to its hash on the certificate—so that it is only valid for this encrypted transaction). Then at step 2 Alice can just submit this encrypted transaction (therefore protecting her private information, such as sender ID, recipient ID, transaction amount and other data), along with the certificate that this encrypted transaction is compliant, for the platform to process it, without gaining any private information. Different technologies could be used for the computation on top of encrypted transaction on the platform (such as zero knowledge described above), and the permissioned nature of our platform make these privacy preserving technologies much easier to implement than on public blockchains.

• Download Figure
• Download figure as PowerPoint slide

The separation of different parts of X-C into a set of trust-minimized components guarantees that the compromise of a single component does not impact the overall privacy of users. Data sovereignty can also be protected this way. Identity and information about users do not leave the country, but the transaction carries cryptographic proof that the transaction is being carried by identified individuals that are allowed to do so or that the transaction is compliant with limits. Thus, participants can be reassured that relevant rules (on who can make transactions and on transactions’ characteristics) are being enforced

How privacy protection works can be illustrated by comparing CEs with other forms of central bank money. For example, country A’s central bank issuing CEs may be able to directly monitor their supervised entities’ X-C accounts (and their CE holdings). From that perspective, CEs would be akin to central bank reserves but on X-C’s ledger. But when a CE issued by this central bank is held by a non-resident PSP, it could become more like cash: the central bank would know that it has been issued, but it may not be able to know who is holding it.⁷⁶ Of course, and different from cash, transactions using those CEs would need to comply with rules and carry cryptographic proof of that compliance.

Finally, data being stored and processed in different entities and kept confidential does not preclude privacy-preserving computations to be performed on top of these. As discussed in section 2 smart contracts with the right permission could still interact with encrypted data. This capability is explored in more detail in next sections.

3.2: Sharing Identities and Information Across Jurisdictions

The costs of preserving financial integrity represent an important friction in cross-border payments. At the domestic level, financial institutions must incur costs to comply with KYC/AML-CFT, but they preserve the data they gather by creating client relationships that generate market power. Initiatives like Open Banking aim to make some of this client’s information “sharable". At the international level, there is no common governance for these vetting procedures and monitoring: not only is it expensive to gather this data on customers but it can also be risky to trust financial institutions from other jurisdictions as there can be uncertainty on the soundness of their procedures. Lack of common digital ID standards only creates more hurdles.⁷⁷,⁷⁸,⁷⁹

The functionalities of X-C allow it to manage efficiently and in a privacy preserving way the information generated at the local level, to identify and vet individuals or firms that X-C ’s participants may want to serve. For example, this information management feature can read a list of sanctioned individuals and attach a cryptographic proof that the individuals participating in a transaction were vetted and are compliant with, for example, AML-CFT rules.

Of course, this functionality “on-ledger” needs to rely on the trust-worthiness of the information created outside the platform (“off-ledger”). The provision of identification and vetting services would require additional governance to ensure that platform’s participants can trust the information behind the proofs that transactions will carry.

The importance of providing a reliable framework for international identification is reflected in the multiple workstreams of the G20 agenda to enhance cross-border payments.⁸⁰ One possibility that creates a flexible governance framework is presented in Amplus (2020).⁸¹ Their governance module relies on local providers (e.g., financial institutions, mobile operators) to identify and onboard customers. These would be overseen by a local authority, while the local arrangements (providers and local authorities) would be overseen by a supranational entity.⁸²

The governance of the off-ledger identification framework could be part of X-C governance or could be a separate scheme, although complementarities and rules’ alignment can potentially be easier if this were to fall under the same arrangement.

An example of complementarities between X-C’s features with a common KYC framework would be the creation of business models specialized in KYC onboarding that can be ’monetized’ when used for cross-border transactions. Once a KYC provider has on-boarded a customer and added her to the KYC list, transactions on X-C could carry the (encrypted) information of the provider that validated the identity of a final user. That could help create accountability, but it also could generate incentives to provide these validation services, as fees on that service could be paid with each transaction in which proof of that validation is attached. The implementation in the platform would have (1) KYC checks that do not leave national borders, (2) an instruction that adds a fee to the transaction and that it is sent to the initial KYC provider. Of course, this is only an example of how to leverage X-C to create markets and incentives. Other designs could certainly be feasible too. In all cases, the platform will require close coordination and cooperation to ensure the ongoing due diligence on the business relationships and the scrutiny of transactions thorough the course of the relationship (including KYC, their business, risk profile, and source of funds).⁸³

Extending Amplus’ Identification Scheme with Encrypted Certificates

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: This figure extends Amplus (2020) to include anonymous (encrypted) credentials and preserving data sovereignty.

• Download Figure
• Download figure as PowerPoint slide

View Full Size

Extending Amplus’ Identification Scheme with Encrypted Certificates

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: This figure extends Amplus (2020) to include anonymous (encrypted) credentials and preserving data sovereignty.

• Download Figure
• Download figure as PowerPoint slide

Extending Amplus’ Identification Scheme with Encrypted Certificates

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: This figure extends Amplus (2020) to include anonymous (encrypted) credentials and preserving data sovereignty.

• Download Figure
• Download figure as PowerPoint slide

3.3. Capital Flow Management Measures

The use of CFMs is common among countries and especially for EMDEs. This can be an important barrier that could hinder the development of multilateral platforms as improvements on cross-border payments.⁸⁴,⁸⁵

Depending on the different CFMs designs, the platform’s capabilities will be easier or harder to leverage.

• CFMs on the platform’s common ledger: when CFMs are applied to holdings within the platforms’ common ledger, the programmability can greatly simplify transactions involving CFMs. In this case, all the information needed for compliance is recorded on the ledger, so smart contracts can read it and apply the CFM. For example, when non-residents ought to pay a tax or hold CEs for a period of time.

• CFMs off the platform’s common ledger: when CFMs are applied to holdings that include balances outside the platform (“off-chain”), it is possible that solutions will need to be devised to comply with these CFMs and still have smart contracts in the platform. In this case, there will be a need to bridge this gap and bring information from an outside source (e.g., a commercial bank reporting system) to the platform, so smart contracts can read it and potentially apply CFMs to holdings within the platform. For instance, when CFMs are designed over an entity’s total holding of domestic or foreign assets, the value held in the platform (“on-chain”) will be reconciled with balance sheets held in traditional systems. This can create hurdles to the type of propositions that can be created in the platform. The hurdles can be overcome, for example, Inthanon-LionRock allows for Thailand to enforce their limit on non-residents deposit holdings.

• Administrative decisions: when CFMs are applied by “ad-hoc” administrative decisions, automatizing transactions is much harder. Since these permits are not administered and decided automatically, human intervention may impair the platform’s capabilities. For example, when an official needs to manually issue a permit for a transaction to be authorized, it will be more difficult to reap gains from programmability and automation.

Highlights

• FX spreads play a large role in the fees for cross-border payments and are usually a result of wholesale market underdevelopment. A better trading infrastructure, better risk management, and a more predictable policy environment can contribute to lower FX trading risks and better-functioning for FX markets.

• Currently, FX trade is mostly done through a set of oligopolistic intermediaries who carry different currency inventories. This requires large balance sheets, resulting in imperfect competition and in price distortions. When markets are decentralized or shallower, market power and distortions are usually larger.

• The centralization of information and exchange of FX trading can contribute to improving markets by increasing transparency and by creating incentives to increase competition. It allows for visibility on prices and quantities that are being actively traded. It also allows elimination of settlement risk from transactions.

• X-C is distinguished from other proposals by organizing FX exchange in a multi-currency environment that utilizes market design theory. Intermediaries act as broker dealers and compete to attract trade from clients. Also, multi-currency auctions are introduced as a robust solution that generates competitive outcomes and can be implemented entirely through smart contracts where no third-party auctioneer is needed.

• X-C is also distinguished by enabling participants to hedge FX risks via forward or contingent contracts, allowing on-platform FX derivative contracts and markets for those. Agents can also enter contracts that mutualize idiosyncratic risks though contingent on aggregate shocks. Smart contracts take as inputs the messages of all the agents with private shocks and implements a cross agent allocation

• X-C’s dynamic ledger can help control and manage financial stability risks from these derivative contracts without requiring full escrow or collateral. The dynamic ledger goes beyond preventing double spending of funds and avoids the double commitment of the rights to future funds that have been contracted with others. As smart contracts are part of the ledger, these can be made to be consistent with each other.

• When there is risk that cannot be diversified, the dynamic ledger can still allow for privacy preserving monitoring of exposures

4.1 Currency Exchange-Market Illiquidity and Hedging Contracts

For EMDEs, FX margins play a large role in the fees for cross-border payments (Feyen et al. 2021). This is usually a result of wholesale market underdevelopment: transactions in shallow and illiquid domestic wholesale FX markets are more expensive, and that pricing spills over to retail FX markets.⁸⁶ Where FX markets do not function well, inter-dealer FX market trades are irregular, insignificant, and shallow, and so de facto complementary markets FX hedging instruments do not exist. As a result, FX exchange can be costly for more illiquid currency pairs, and, in certain circumstances, it can reinforce existing players’ market power in cross-border payments.

A key for well-functioning for FX markets is to reduce FX trading risks. This can be done by providing a better trading infrastructure, better risk management, and a more predictable policy environment. This can result in lower costs and risks of market making, so that this activity can be profitable at smaller spreads.⁸⁷ The centralization of currency trading can contribute to this, as it increases market transparency for participants. Trading rules and mechanisms within centralized structures are also important as these create incentives for a more competitive environment.

The next subsections present solutions for (1) organizing FX exchange in a multi-currency environment that utilizes market design theory, and for (2) designing hedging contracts to manage risks that utilize contract theory. These solutions distinguish X-C from existing proposals that use new forms of digital money for cross-border payments; these typically take market structure as given and do not discuss how programmability can be applied to improve contracts and markets functioning.⁸⁸

4.2 Market Design: A Centralized Multi-Currency Market

In existing cross-border transactions, FX trade is mostly done through a set of oligopolistic intermediaries who carry different currencies inventories. Creating and carrying such inventories requires large balance sheets, resulting in imperfect competition and in price distortions. Where markets are shallower, market power and distortions are usually larger.

These outcomes stem from pairwise trading, which contributes to the inefficiency of legacy systems. Pairwise trading means that one currency trades against another (as if in a bilateral market or a series of bilateral markets) to complete the end transaction. This market structure is sometimes taken as a given in proposals to enhance cross-border payments.⁸⁹ Economic theory, in contrast, provides guidance for market organization. For example, theory can guide recommendations on how agents should meet and what should be the rules of engagement in those interactions in order to create desirable outcomes: more competition and higher efficiency can be obtained with a multi-currency centralized marketplace. This can help create market depth for illiquid currency pairs, mitigate market power, and facilitate cross-border transactions.

The organization of exchange markets

Market structures that rely on decentralized environments (such as in OTC trading) are less likely to generate competitive and liquid markets.⁹⁰ There are three basic conceptual issues which are clarified by market design considerations.

The first issue is the absence of double coincidence of wants that can prevent trade when exchanges of different commodities occur in separated environments (that is, trade is done in bilateral segregated exchanges). If trade in currencies is restricted to be pairwise, then with an absence of double coincidence of wants, the result can be low volumes being exchanged. This is a well-known basic problem of monetary theory, and it applies to currency trade. Figure 4.1 provides an example, drawn from Wicksell (2013). In this static setup, an agent from country A wants to give up currency A to get ahold of the currency of country B, an agent from country B wants to give up currency B but to obtain the currency of country C, and an agent from country C wants currency A. In the absence of a centralized exchange, trades would have to take place pairwise, that is, one exchange market with trades for currencies A, B, one exchange market for B, C, and one for C, A. For the underlying example environment with three traders, there is no mutually beneficial bilateral exchange, and the outcome is autarky. On the other hand, if all three participants meet in a centralized platform, trade is possible. Agents need only respect their own budget constraint, that the value of currency surrendered as a sale be enough to sustain the value of currency acquired as a purchase.

Pairwise trade

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: this figure illustrates a simple case where each of the agents want a specific currency. Absent a centralized exchange or a dealer, there may not be transactions.

• Download Figure
• Download figure as PowerPoint slide

View Full Size

Pairwise trade

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: this figure illustrates a simple case where each of the agents want a specific currency. Absent a centralized exchange or a dealer, there may not be transactions.

• Download Figure
• Download figure as PowerPoint slide

Pairwise trade

Citation: IMF Working Papers 2022, 217; 10.5089/9798400224188.001.A001

Note: this figure illustrates a simple case where each of the agents want a specific currency. Absent a centralized exchange or a dealer, there may not be transactions.

• Download Figure
• Download figure as PowerPoint slide

The second issue is that coordination in the use of one currency as a unit of account and “vehicle” does not solve the problem of segregated exchange. That is, even with the use of one specific currency as part of each bilateral trade, multiple equilibria and market power still arise in segregated markets.⁹¹ For example, if traders believe there will be no active market in one of the currency markets, then no one will trade there. This type of self-fulfilling prophecy can be a source of market illiquidity and shallowness. When these arise, two things happen. If there are few participants to buy, the price can move against them when they place orders.⁹² But also, it is more likely that some agents will have market power as it becomes easier for large players to be strategic and extract rents. More generally, fears of lack of liquidity and uncompetitive environments can discourage participation and leave thin markets.

The third issue is that lack of information centralization prevents segregated exchanges from achieving competitive outcomes. Agents may not have visibility of which prices are being traded by others, so they may not be able to properly value their positions. Moreover, agents with larger balance sheets will engage in more trades and thus will be able to profit from a better understanding of market conditions. Agents also may not have visibility of the volumes being traded. This can lead to coordination problems, inefficient outcomes, and financial instability.⁹³

Possible solutions to these issues create yet other problems. A first possible solution is that all participants are endowed in ample amounts of a common currency, so that each can buy before selling, if need be, given the target efficient sequence of trades. But achieving a first best solution would require very large and costly liquidity buffers.⁹⁴ A second solution is a common large trader with sufficient inventory of all currencies, so that this intermediary would be able to sell to whomever arrives without stock outs. This also requires that inventory be large and creates excessive market power. A third solution is to have currency trade run on pre-allocated credit. This creates exposure to credit risk.⁹⁵

Centralizing information and exchange can limit these problems. From an aggregate standpoint, it allows for visibility on prices and quantities that are being actively traded. It also allows elimination of settlement risk from transactions, as traders’ financial position can be checked. But even more so, recording the trades serves as a reference for future exchange.⁹⁶ This is particularly important for contracts, as discussed in Section 4.3.

4.3 Hedging Risks: Forward and Risk Sharing Contracts and Markets

Efficient FX forward and risk management is fundamental for achieving low FX transaction costs. However, in jurisdictions with shallow financial markets, availability of forward and risk management products can be limited. For instance, banks may not offer regular derivative transactions to clients, The general perception is that the market demand is too scarce to make it attractive for banks to engage regularly in the derivative market, while the regulatory uncertainty, or perception thereof, acts as a further restraint to any form of market engagement in hedging.

The features of X-C enable participants to hedge FX risks via forward or contingent contracts by allowing on-platform FX derivative contracts and markets for those. This contributes to a more competitive market structure for cross-border transactions, as it allows for smaller intermediaries to compete on a more equal footing. Smaller balance sheet size becomes less determinant of participants ability to manage risks.

There is a strong complementarity between the development of derivative and spot markets: agents need both an active, liquid, and well-functioning spot FX market, and to be able to price intertemporal trades in their own currency.¹¹⁶ While this varies depending on the country, the discussion below proposes the option of an “on-platform” intertemporal market for domestic currency CE as well as a derivative market for exchanging CEs denominated in different currencies (FX).

In the rest of this section, we first discuss frictions in a simple intertemporal environment and how to address them with forward contracts implemented on X-C. Second, a richer use case for contingent risk-sharing contracts and their implementation.