Introduction
Although the hype around bitcoin has largely abated, the underlying technology behind it, distributed financial technology, is taking center stage. Against that backdrop this article discusses the application of distributed financial technology to funds transfers, as a new payment rail. Traditional payment service providers, such as banks, can use this technology as a decentralized payment mechanism to potentially make settlement quicker, less expensive, and safer. Distributed financial technology can be adapted to payment systems without necessarily involving the issuance of a digital currency, instead using fiat currencies (such as U.S. dollars, euros, or yen) to settle cross-border transactions. However, it is only with robust payment rules, such as state-law rules adopting the Uniform Commercial Code (UCC), that such payments using distributed financial technology can effect a discharge of the underlying obligation to pay.
This article explains how distributed financial technology can be used to effect a funds transfer in fiat currency and gives an example of what such an application looks like. It discusses how UCC Article 4A can be interpreted to cover the typical payment of an interbank payment order using distributed financial technology – namely, by means other than a debit or credit to the account of a bank. In particular, we examine the application of UCC Article 4A to the completion of the funds transfer and the discharge of the underlying debt paid.
Distributed Financial Technology as a Payments Rail
The Bitcoin block chain represents but one specific application of distributed financial technology – as a decentralized ledger. The block chain is a decentralized and shared public database that verifies and permanently records transactions. It was first born out of a need to create and track bitcoin balances in the absence of trust between the parties involved and without the need for intermediaries. Specifically, all parties involved in a bitcoin transaction must agree to a trustworthy record of ownership. Enter the distributed ledger known as the block chain: every bitcoin transaction is chained to each previous transaction with the goal of preventing anyone from fraudulently duplicating or tampering with the ownership of a bitcoin. The distributed ledger is designed to allow validated information to be put in and never deleted. Everyone can inspect that ledger, but no single user controls it.
The Bitcoin block chain accomplishes this through cryptography. A payor initiates a bitcoin payment to the payee by submitting the transaction to its local node, which checks, among other things, that the payor has the bitcoins it now wants to spend, and confirms that the transaction is likely to succeed. If the proposed transaction is confirmed, the local node broadcasts the transaction to other nodes and the transaction quickly propagates through the entire distributed network. Bitcoin miners are constantly seeking transactions that are broadcast through the network. Every 10 minutes on average, a miner solves a mathematical problem involving a set of recently broadcast transactions; doing so bundles the transactions together into a block. The mathematical problem is hard to solve, but it is easy for the network to confirm that the answer is correct once found. Each time a miner solves the mathematical problem that produces a new block, the block is “hashed” together with the previous block. In other words, miners take the information in the block and apply a mathematical formula to it (a cryptographic hash function), which transforms the information into a hexadecimal string of characters. This hash function is one way: one can produce a hash from a collection of data in a block, but going from the hash back to the data is impossible. Each block’s hash is produced using the hash of the block before it, creating a “chain” of blocks that stretches back to the first Bitcoin block (the genesis block), containing the first transaction in the Bitcoin network. This construction is designed to make the Bitcoin block chain tamperproof: if one tries to fake a transaction by changing a block that had already been stored in the block chain, that block’s hash would be different and ought to be apparent to all as having been tampered with.
At its heart, distributed financial technology represents a mechanism for establishing trust among parties that does not require a single central authority. The Bitcoin block chain is but one manifestation of that technology, and other cryptography-based verification processes exist – for example, distributed financial technology need not rely on mining (or its consumption of large amounts of energy) to validate transactions.
One application for distributed financial technology is payments, which rely on trusted, central third parties to clear and settle payments. Trust is imperative for cross-border payments in particular, which call for multiple parties in different jurisdictions to take a series of coordinated actions. Distributed financial technology would allow a payment system to establish trust and operate in an entirely decentralized way, without intermediaries such as common correspondent banks.
Suppose that Alpha Corp wishes to make a payment of $5,000 to Beta Corp for products that it purchased and opts to make that payment by wire transfer. In a typical funds transfer, Alpha Corp (the originator) instructs its bank (Alpha Bank) to pay, or cause another bank to pay Beta Corp (the beneficiary) by crediting an account of Beta Corp on the books of its bank. Thus, Alpha Corp and Beta Corp would be only two of the many parties to that payment. Where they do not share the same bank (which, as a practical matter, would more often be the case), the transaction would also involve Alpha Bank and Beta Corp’s bank (Beta Bank) and, if neither bank maintains an account with the other, even more intermediaries (adding even more parties). All these parties must take a series of coordinated steps in order for the payment to Beta Corp to be made: each bank in the chain must pay the bank downstream and receive payment from the bank upstream. These payments must offset each other such that at the end of the series of transactions, what remains is the increased balance in the account of Beta Corp with its bank and the decreased balance in the account of Alpha Corp with its bank.
This coordination requires trust, which payment systems have achieved through trusted third-party banks, such as a common correspondent bank. In the example above, Alpha Bank and Beta Bank would rely on a third party with which they both maintain accounts to settle with each other. This reliance on a common correspondent bank, let’s call it Sigma Bank, requires trust that Sigma Bank will, among other things, properly authenticate the transaction and perform appropriate checks (e.g., sufficient funds), credit Beta Bank’s account and debit Alpha Bank’s account at the right time and in the correct amount, and do this in a secure manner. More generally, Alpha Bank and Beta Bank trust Sigma Bank to maintain a ledger that represents the definitive record of their balance of funds and that Sigma Bank will maintain this record in a reliable, accurate, and honest way. Of course, global interbank communication services, like those provided by SWIFT (the Society for Worldwide Interbank Financial Telecommunication), also allow banks to authenticate and maintain a record of the amount of the payment orders they send and receive. Nevertheless, at the heart of this well-established arrangement is a central ledger, with settlement taking place on the books of Sigma Bank.
Distributed financial technology could revolutionize this traditional funds transfer framework, replacing the need for the trusted third-party bank (Sigma Bank) positioned between Alpha Bank and Beta Bank. The technology developed by Ripple is one such example of how a funds transfer could run on distributed financial technology rails. In this new model, using the example above of a $5,000 payment from Alpha Corp to Beta Corp, Alpha Bank and Beta Bank would use distributed financial technology to replace the trusted, central third party (Sigma Bank) and settle with each other, through any entity that has accounts on the books of both Alpha Bank and of Beta Bank (a connector). In contrast to the common correspondent model (where Alpha Bank and Beta Bank each have accounts with Sigma Bank), here it is the connector that has accounts with Alpha Bank and with Beta Bank. This connector can be an institutional customer of Alpha Bank and Beta Bank, like a hedge fund or broker dealer, willing to act in this capacity and authorized by Alpha Bank and Beta Bank to do so. Banks may choose to use a different connector for each transaction.
Similar to the example above this funds transfer would involve Alpha Bank debiting Alpha Corp’s account on its books and Beta Bank ultimately crediting Beta Corp’s account on its books. As between Alpha Bank and Beta Bank – instead of settling with each other through Sigma Bank, they will use distributed financial technology to coordinate certain account entries involving the connector’s accounts on each of their own respective books. Specifically, Alpha Bank would increase the balance it owes to the connector and, at the same time, Beta Bank would decrease the balance it owes to the connector. Alpha Bank and Beta Bank would use distributed financial technology to communicate, coordinate, validate, and record their credit and debit to the connector’s accounts.
Critical to this funds transfer framework is certainty and clarity as to rights and liabilities, including when certain rights arise and certain liabilities are extinguished. It is important that the parties involved in the transaction fully understand the consequences of using the distributed financial technology framework as a payment mechanism to effect a discharge of monetary obligations. For example, Alpha Corp needs to know when it has discharged its obligation to pay and no longer has to worry about its debt to Beta Corp. Beta Corp is likely relying on the payment from Alpha Corp to satisfy its own monetary obligations; if, for some reason, its reliance is misplaced and the payment is later reversed or there are doubts to its finality, Beta Corp may unexpectedly find itself short of liquidity.
Article 4A of the UCC is a comprehensive set of rules that defines the rights and obligations in connection with funds transfers. It was drafted specifically to facilitate high-value commercial payments and has been adopted by all 50 states. The next section examines the application of Article 4A to payment transactions where distributed financial technology is used.
Application of Article 4A
The threshold question is whether payments running on distributed financial technology rails are within the scope of Article 4A. The primary focus of Article 4A is the “funds transfer,” the transfer of bank credit from the payor to the payee. Specifically, Section 4A-104 defines “funds transfer” as the series of transactions, beginning with the originator’s payment order (that is, the payor’s instruction to its bank to pay or cause another bank to pay a fixed amount of money to the payee), made for the purpose of making payment to the beneficiary of the order. The examples above – where Alpha Corp transmits an instruction to its bank, Alpha Bank, to pay or cause another bank to pay Beta Corp – fall within the definition of “funds transfer.” This is so even where Alpha Bank and Beta Bank choose to use distributed financial technology to settle with each other. That transfer is still a series of transactions, beginning with Alpha Corp’s payment order (Alpha Corp’s instructions to Alpha Bank to pay or cause another bank, like Beta Bank, to pay a fixed amount of money to Beta Corp), made for the purpose of making payment to Beta Corp, the beneficiary of the order. Alpha Bank and Beta Bank’s choice to use distributed financial technology to communicate and settle with each other does not remove the transfer from the ambit of Article 4A.
Returning to the original scenario, Alpha Corp wishes to make a payment of $5,000 to Beta Corp – when has that payment been made? Under Article 4A (Section 4A-406(b)), the underlying obligation of Alpha Corp to Beta Corp is discharged when a payment order for the benefit of Beta Corp is “accepted” by Beta Bank. Section 4A-209(b) specifies four ways a beneficiary bank like Beta Bank may accept a payment order, the soonest of which would discharge Alpha Corp of its obligation to pay Beta Corp. How might Beta Bank accept a payment order where distributed financial technology is used? There are two potential ways.
One way for Beta Bank to accept Alpha Bank’s payment order is by receiving payment of its amount under Section 4A-209(b)(2) by means of “final settlement” through “a funds-transfer system,” as specified in Section 4A-403(a)(1). Arguably, a settlement framework running on distributed financial technology rails can be considered a “funds-transfer system” under Article 4A. Section 4A-105(a)(5) defines “funds-transfer system” to include a “communication system of a clearing house or other association of banks through which a payment order by a bank may be transmitted to the bank to which the order is addressed.” According to Official Comment 3 to Section 4A-105, the term “funds-transfer system” includes CHIPS, which provides for transmission of the payment order as well as settlement of the obligation of the sender to pay the order, and organizations like SWIFT, which provide only transmission services. In the example above, Alpha Bank and Beta Bank use a certain agreed-upon distributed ledger technology framework as a means to communicate the payment order with each other, as well as to coordinate and settle with each other through a connector. If they and other participant banks that use the same settlement framework together promulgate and agree to rules governing their payment orders transmitted over that framework which supplement (or, in some cases, override) Article 4A, one could take the similar position that those rules are a “funds-transfer system rule” under Section 4A-501(b).
Another way for Beta Bank, as beneficiary’s bank, to accept the payment order is by passive acceptance. Under Section 4A-209(b)(3), if Beta Bank does not give timely notice of rejection of the payment order, then it is deemed to accept the payment order if either (a) the amount of the order is “fully covered by a withdrawable credit balance in an authorized account” of Alpha Bank, or (b) Beta Bank has “otherwise received full payment from” Alpha Bank. In the example above, Alpha Bank and Beta Bank use distributed financial technology to coordinate two account entries: (1) Alpha Bank increases the balance it owes to the connector, and (2) Beta Bank decreases the amount it owes to the connector. Accordingly, the order amount is covered by a withdrawable credit balance, albeit in an authorized account of the connector, not that of Alpha Bank. Arguably however, Beta Bank has “otherwise received full payment from” Alpha Bank through these simultaneous entries coordinated by the distributed ledger: Beta Bank’s obligation to pay the connector is decreased by the amount of the payment order and, as a practical matter, offset by an increase in Alpha Bank’s obligation to pay the connector.
Could one argue that the connector is implicitly an agent of Alpha Bank, such that the order amount would be “fully covered by a withdrawable credit balance in an authorized account” of the connector and therefore its principal Alpha Bank – thereby falling more squarely within Section 4A-209(b)(3)’s passive acceptance? The concept of implicit agency is not alien to Article 4A. Under Section 4A-206(a), if a payment addressed to Beta Bank (the receiving bank) is “transmitted to a funds-transfer system or other third-party communication system for transmittal” to Beta Bank, “the system is deemed to be an agent” of Alpha Bank (the sender). In fact, if there is a discrepancy between the terms of the payment order that Alpha Bank transmitted to the system and the terms transmitted by the system to Beta Bank, the terms transmitted by the system trump under Section 4A-206(a). However, deeming an agency relationship between the connector and Alpha Bank as described above based on Section 4A-206(a) is rather tenuous. By its own terms, Section 4A-206(a) limits its implicit agency relationship to being only “for the purpose of transmitting the payment order to the bank.” Deeming the connector to be an agent of Alpha Bank for account structure and settlement purposes as described above goes beyond these boundaries. Additionally, it is unclear that the connector would fall within the definition of “funds-transfer system“ discussed above – particularly given that banks may choose to use a different connector for each transaction.
In the final analysis, interpreting Article 4A’s definition of “funds-transfer system” to cover settlement frameworks running on distributed financial technology rails so as to allow for acceptance under Section 4A-209(b)(2) is practically sensible for two reasons. If it were otherwise, Beta Bank could accept a payment order where distributed financial technology is used only by passive acceptance under Section 4A-209(b)(3). Such acceptance occurs at “the opening of the next funds-transfer business day of the bank following the payment date of the order.” That is, some amount of time must pass until Article 4A deems Beta Bank to have accepted Alpha Bank’s payment order. Official Comment 7 to Section 4A-209 explains that the delay in this deemed acceptance is designed to accommodate a situation where: “it may not be possible for the bank to determine until the end of the day on the payment date whether there are sufficient good funds in the sender’s account. There may be various transactions during the day involving funds going into and out of the account. Some of these transactions may occur late in the day or after the close of the banking day.” This rationale does not apply to a transfer running on distributed financial technology rails, where there is no reason to delay acceptance beyond the time the two coordinated account entries are made (Alpha Bank increases the balance it owes to the connector and Beta Bank decreases the amount it owes to the connector). Such a delay instead undermines the technology’s enhancements in speed and efficiency.
Additionally, if settlement frameworks running on distributed financial technology rails fall within Article 4A’s definition of “funds-transfer system,” participant banks in that framework (like Alpha Bank and Beta Bank) can together promulgate and agree to “funds-transfer system rules” under Section 4A-501(b), as noted above. Such a funds transfer rule may include a choice of applicable law provision, and under Section 4A-507(c) that choice may bind not only participating banks but also other remote participants in the funds transfer (such as the originator/payor and beneficiary/payee) provided they have notice. Official Comment 4 to Section 4A-507 notes that subsection (c) may be the most important provision in regard to creating uniformity of law in funds transfers. In particular, “[t]he ability of a funds transfer system to make a choice of law by rule is a convenient way of dispensing with individual agreements and to cover cases in which agreements are not feasible.” The benefits to having a consistent, unitary law governing all transfers made on traditional funds transfer system apply just as well in the context of distributed financial technology.
Conclusion
Although Article 4A can be read to apply to a transfer over distributed financial technology rails, some uncertainty remains as to how its fundamental concepts map onto such a framework. In the absence of new legislation, freedom of contract can accommodate this technological revolution – but not to the extent third-party rights are significant and standardization or other rules are required.
Moreover, the potential impact of distributed financial technology to payments extends far beyond the simplistic scenario described above. A settlement framework running on distributed financial technology rails can be similarly structured to make cross-border payments in different fiat currencies, with an embedded foreign exchange component. For example, Alpha Bank would increase the balance it owes to the connector in one currency (e.g., U.S. dollar) and Beta Bank would decrease the balance it owes to the connector in a different currency (e.g., euro), with such account entries based on an exchange rate previously agreed to between Alpha Bank and the connector. Cryptocurrency, such as XRP, could also be used as an intermediary asset to bridge any currency pair. Critical to realizing the potential of this decentralized funds transfer framework is certainty and clarity as to the rights and liabilities, including when certain rights arise and certain liabilities are extinguished.