QFS - CROSS BORDER PAYMENT METHODS BY THE QFS NESARA GESARA : PROJECT STELLA

PROJECT STELLA

 See Project Stella: 

Synchronised cross-border payments, joint research project of the European Central Bank and the Bank of Japan, June 2019.

Project Stella was born as a joint research undertaking by the European Central Bank (ECB) and the Bank of Japan (BOJ). Launched in December 2016, the project aimed to contribute to the ongoing debate with experimental work and conceptual studies exploring DLT’s opportunities and challenges for financial market infrastructures. 

In 2018, the two central banks built on the insights gained from the earlier stages of the project to explore innovative solutions for cross-border payments, i.e., payments between currency areas.45 Stella Phase 3, thus, studied whether cross-border payments could be improved, especially in terms of safety, by using new technologies. 

In particular, it studied a Ledger-Agnostic Protocol that synchronizes payments across different types of Ledgers and assessed the safety and efficiency implications of a variety of payment methods that could be used in the Cross-Ledger Payment. 

These models show distinctive characteristics, which can be summarized as follows: i) whether individual payments are settled on-ledger or recorded off-ledger, ii) whether funds are locked or escrowed, iii) whether payments are enforced when the predefined condition for the payment is fulfilled, and (iv) whether specific ledger functionalities are required to conduct transfers, such as the functionalities to enforce conditional transfers and process signed claims.

Description of the models. The different payment methods are the following:

• Trustline: This model involves an arrangement between the payer and the payee outside the ledger where the payer promises to make a payment if the payee fulfils a predefined condition. At the same time, the total of payments which has not been settled must not exceed the predetermined maximum amount that the payer can pay without Settlement on the Ledger.

On-ledger holds/escrow: This model uses the HTLC technology (referred to earlier), which allows for conditional transfers that are recorded on the Ledger and Enforced by the Ledger if the Payee fulfils a predefined condition. 

• Third party escrow: This model is conceptually similar to the on-ledger escrow but relies on a third party which is trusted by the Payer and the Payee rather than on the Ledger to enforce the Conditional transfers. 

• Simple payment channel: This model involves an arrangement between the Payer and Payee using Escrowed Funds in a Shared Temporary account on the Ledger. Both parties promise to Exchange signed claims Off-ledger, which represents their entitlement to a specific portion of Escrowed funds, if the payee fulfils a predefined condition. Only the final net position of multiple bilateral payments is actually settled on the ledger. 

• Conditional payment channel: This model uses HTLC and is similar to the simple payment channel in the sense that both Parties exchange signed claims Off-ledger, but in addition has an Enforcement Mechanism by the ledger for the transfers based on whether the Payee Fulfils a predefined condition. 

Example of a funds transfer. Here only a general illustration is reported of how the Interledger Protocol—a ledger-agnostic protocol—allows the sender to make payments across different types of ledgers, 

The building blocks of the Protocol are Participants, Ledgers and Payment Methods, whereby Participants are entities that have accounts on one or more Ledgers and Participate in the Cross-Ledger Payment, Ledgers indicate any System used to Track Transfers of value between, and Balances on, Accounts, and Payment methods (as above) are Bilateral Agreements between Participants on specific Methods to make Payments and Settle Obligations on the Ledger.

 The choice of payment method depends on participants’ preferences and Ledger Functionalities. Participants can assume three roles within the Interledger Protocol: 

Sender, Receiver, or Connector. 

Connectors are entities with accounts on two or more Ledgers, which act as liquidity providers that relay payments across ledgers and play a critical role for the successful execution of Cross-Ledger Payments. A liquidity provider enables a Cross-Ledger payment by Exchanging an Incoming payment from its account on one Ledger for an outgoing payment to its account on another Ledger. 

When Connectors relay a payment across ledgers denominated in different currencies, they conduct Currency Conversion. Where a single Connector cannot link the Payment between the Sender and the Receiver, or cannot do so in an efficient way, multiple Connectors can be composed into a payment chain (Chart 11).

All individual payments along the payment chain depend on the fulfilment of the following condition by the Payee (Receiver or Connector(s)): Presentation of the preimage for a Cryptographic hash value before a predetermined time (timeout). 

The hash value is used to define the payment condition (in the context of a smart contract), while the corresponding hash preimage marks the fulfilment of that condition. 

Before a Cross-Ledger Payment is initiated, the preimage and its Cryptographic Hash value are produced by the Receiver. The Hash value must then be shared with the Sender together with other terms of the Payment, which may include Payment amount, Payment Currency, Payment Timeout and Receiver information, using external means of communication (e.g., email). 

After the initial Bilateral Sender-Receiver communication, each individual Payment of the Cross-ledger payment chain goes through two main phases: 

• First, the Payer (the Sender or Connector(s)) prepares the Payment to the Payee (the Receiver or Connector(s)) according to the specific Payment method used. 

• Second, there are three possible scenarios. If the Hash preimage is presented by the Payee (the Receiver or the Connector(s)) before the timeout and is verified as correct, the condition for the payment is fulfilled and the payment to the Payee is executed (fulfilment scenario). 

Alternatively, if the timeout expires without the correct preimage being presented, the Payment is aborted (timeout scenario), or if the Payee does not accept the Payment, the payment could be aborted even before the expiration of the timeout (reject scenario). 

Payment processes based on the protocol require Information Exchanges between Participants as well as with other relevant entities. These include the initial information exchanged between the Sender and the Receiver which does not vary along the Payment Chain and does not depend on the Ledger and the Payment method used, as well as other information which varies among each Payment in the Payment chain (e.g., fees and timeouts for individual payment conditions).

Considerations. 

The Stella report concluded that, from a technical perspective, the safety of today’s cross-border payments could potentially be improved by using payment methods that synchronize payments and lock funds along the payment chain, noting in addition that further reflections would be needed on legal and compliance issues and the maturity of the technology. Specifically, in relation to safety, the on-ledger escrows, third- party escrows, and conditional payment channels (all of which have enforcement mechanisms) can ensure that each transacting party who completely satisfies its responsibilities in the transaction process is not exposed to the risk of incurring a loss on the principal amount being transferred. On the other hand, with regard to liquidity efficiency, THE TRUST LINE method appears to be superior to the others since it is the only POST FUNDED PAYMENT METHOD.

Interestingly, the study identified the so called “Free Option Problem,” a risk aspect that could materialize even when all of the preconditions used in the Assessment are met. This is the exchange rate risk that participants are exposed to when relaying a Cross-ledger, Cross-currency payment. 

In the preparation of such a payment, participants enter into a commitment to deliver a fixed amount denominated in one currency in exchange for a fixed amount denominated in another currency.

 This could potentially be exploited by malicious actors, without the safety of payments being undermined.

An example would be one where the Sender and the Receiver collude after initiating a transaction and thereby effectively locking the Connector’s liquidity. In this instance, the Receiver has the option to either execute the payment (fulfil), or alternatively abort the payment by rejecting it within the timeout or by letting the timeout expire. Thus, the colluding parties can take advantage of the Connector’s binding commitment depending on the movement of the exchange rate. That is, they only execute the payment if the exchange rate moves in a favorable direction for them, otherwise the payment is aborted.

This “Free Option Problem” currently remains open and is being actively discussed within the Interledger Community. However, it should also be noted that it does not pose direct risk to the safety of the Payments. Moreover, this may not be a significant issue if the participants value reputational risk above the potential gains from exploiting the Connector’s binding commitment.