Kinexys by JP Morgan, the bank’s blockchain arm, and the Massachusetts Institute of Technology’s Digital Currency Initiative (MIT DCI) have collaborated on a paper to explore standards for bank tokens on open blockchains. The authors suggest primarily relying on existing Ethereum standards, but propose two new ones they believe are needed for interbank payments. They also suggest areas where regulations might be relaxed for blockchain-based bank payments.
By open blockchains they mean permissionless blockchains and also open permissioned blockchains such as Unified Ledgers and Singapore’s Global Layer One. In the latter case, a key differentiating feature is the blockchain node operators are regulated.
Apart from stablecoins, most live solutions for blockchain-based bank payments or tokenized deposits have mainly been on permissioned networks and for single banks. There are quite a few single bank solutions such as Kinexys Digital Payments (formerly JPM Coin), Citi Token Solutions and Customers Bank which uses Tassat’s technology.
However, for conventional payments, the vast majority are made between different banks.
Interoperability between bank tokens
Hence, part of the paper explores potential standards for bank tokens to enable interoperability for payments between banks. It maps various bank token functions against existing Ethereum token standards. However, this mapping process unveiled a couple of large gaps, particularly around payment orchestration.
One example is anti money laundering (AML) and fraud analysis, which is based on large datasets, so would be processed off chain, and currently would be executed before the payment is initiated.
The payment standard ISO 20022 took years to develop and has 750 pieces of information. The ERC-20 payment standard has three – payment and recipient wallet addresses and the amount. Banks need more variables.
So, when a user wants to make a payment, the wallet would request the format of the payment information needed by the bank (or other entity with authority), and present the appropriate screen to the user for input. Once the user has entered the data, the bank responds to the wallet with the authorization, which is included in the on-chain transfer request. The transfer and authorization would be validated on -chain, for example, to ensure that the payment amount does not exceed the amount authorized.
Stepping back, JP Morgan is keen for these standards to be “designed to be narrow in scope and componentized in a way that allows them to be easily composed with other standards,” the authors wrote. The Linux Foundation Decentralized Trust organized an interoperability workshop with Kinexys, which highlighted the need for standards but “there is a need to move beyond ‘your’ standards versus ‘my’ standards, towards the convergence of ‘our’ standards.”
Other blockchain payment proposals
The second gap in standards relates to suspending accounts, freezing and seizing funds. The ability to freeze is not that unusual in a permissionless blockchain environment, especially for centralized stablecoins. But the ability to seize funds would be problematic in a ‘trustless’ environment. In a regulated environment it’s a requirement. The authors propose that seizures should be done transparently, otherwise it could undermine trust.
Beyond technical standards, the paper also explores regulatory implications for blockchain-based banking, exploring a couple of topics that regulators might consider going forward. For conventional payments messages are simply relayed between banks. Hence, the paying bank is expected to validate both the payer and payee. The authors propose that each bank be responsible for vetting their own clients and their end of the payment for DLT based payments.
Circling back to the point and ‘your’ versus ‘my’ standards, these proposals are a useful step toward enabling interoperable bank tokens on open blockchains, though industry-wide collaboration will be essential for their adoption and evolution.
As part of Ledger Insights’ research, we have also noted some gaps, particularly some blind spots in programmability. It’s relatively easy to think about programmability from the perspective of simple conditional payments.
However, bank tokens and stablecoins will quickly be used for more advanced functionality. Without the ability to envision and consider these use cases, there’s a risk that in just a couple of years an expensive interbank payment system might not be fit for purpose.
In our report on bank stablecoins, tokenized deposits and DLT payments, we provide a simple example of the sort of programmability that will soon be expected but is not currently being considered. And we show how it can break most current designs. It’s always possible to develop workarounds, but these compromise the efficiency potential, making it harder to compete with stablecoins. We suggest an alternative design that prevents this.