Payments and the blockchain

More than a decade after the introduction of Bitcoin, blockchain payments are still a relative niche, despite innovations like stablecoins that use the underlying technology while continuing with fiat money.

My previous blog explored the impact of blockchain on financial services. This blog explores how blockchain technology could impact payments, assuming that the currency remains fiat money.

The blockchain functionality cited in this blog will reference Ethereum, with the understanding that banks would use a permissioned fork, instead of public Ethereum.

Any new technology must solve a problem. Hence, this blog is organized around 3 major sources of friction in the existing payments system:

Friction source 1: Disjointed flows

A payment involves three flows:

i. Flow of real-world products and services

ii. Flow of information relating to the payment (how much, when, to whom)

iii. Flow of money

The above three are disjointed in most payments.

The three flows of a cheque payment for a used car sale on Facebook Marketplace is illustrated below:

The consequence of disjointed flows include:

Foregone commerce:

At the micro level, a consumer may simply not buy online from small merchants. At the macro level, this leads to oligopolistic industries. In the above example, the seller would not hand over keys till payment is credited and the buyer would not hand over the cheque till he has the car. They may choose to skip the transaction.

Transaction costs:

In our example, the buyer and seller may opt to transact with a used car dealer, thus incurring higher transaction costs. Another example is the large security deposits that tenants post with landlords. The delivery of service (shelter) is not systemically linked to payment, exposing the landlord to credit risk.

Legacy solutions

The legacy solutions to this problem follow two models:

Operational intermediation

In 2004, the Chinese e-commerce giant Alibaba launched an escrow service Alipay , to promote trust in their peer-to-peer marketplace Taobao. Alipay held money in escrow till goods were delivered.

Somewhat strangely, the Alipay model is used in capital markets. When we buy shares, the counterparty can take the cash without transferring the shares to our brokerage account (and vice versa). To eliminate this risk, securities and cash are parked with central entities (e.g., DTCC, Euroclear), who ensure delivery versus payment settlements.

Risk intermediation

Unlike an operational intermediary who performs a transactional service, in this model, the intermediary absorbs financial risk arising from disjointed flows. Example, when returning goods, we run the risk of not getting a refund. Intermediaries that represent the merchant (legacy players like JP Morgan, Fiserv and fintechs like Block, Stripe) absorb this chargeback risk.

Digital innovation

Digital innovation in this area has been limited. Card issuing platforms that integrate the payment with the real world via digitally enforced rules, are an example. A corporate card swipe at a cannabis dispensary is likely to get declined. Modern businesses require far more sophisticated rules. For instance, a gig worker for a food delivery company should use the business credit card only to pay at the pickup restaurants. Fintechs like Marqeta provide sophisticated rule enforcement platforms for payment cards.

The Blockchain solution to the Disjointed Flows problem

Ethereum can be conceived as consisting of 3 components that can work in tandem to integrate the flows of product, information and money:

i. Token:

A token is a digital representation of value. For instance, a token could represent ownership of a company (equivalent to stocks) or ownership of a painting (NFTs). A bank permissioned payments system will need, at the very least, a token that represents fiat currency.

ii. Blockchain address:

The blockchain address is the account which holds the token (analogous to a bank account). Each address is associated with a unique private key, the equivalent of a password.

iii. Smart Contracts

Smart Contracts are a somewhat grandiose term for software code hosted on the blockchain.

As an illustrative example, the above elements can be deployed into an e-commerce chargeback as follows:

a. At the time of purchase, the customer pays into an ephemeral customer-merchant joint account (blockchain address) via fiat currency tokens.

b. A smart contract codes the following rules:

· If delivery is not recorded by the shipper (say FedEx) within 5 days of the order, the money reverts to the customer

· The merchant cannot withdraw from this account for a specified number of days after FedEx records delivery- the maximum permissible return period, say 7 days

· After 7 days from order delivery, if FedEx has not scanned the return label that accompanied the merchandise, the money is transferred to the merchant without recourse

The chargeback part of the above workflow is illustrated below:

In the above example, the delivery side of the transaction occurred in the physical world and the payment side occurred on-chain. Hence, an Oracle (in this case, FedEx) was needed to input off-chain information into the smart contract.

Friction source 2: walled gardens

The flow of money follows the flow of information. In 2022 when Russia was yanked from the flow of information via SWIFT, it became harder to move money. The second major source of payment friction arises because these information flows occur among parties, whose systems are walled gardens.

There are two types of information flows in a payment:

Friction in payment authorization

The payer seeks authorization from the source account sponsor (either a checking account issuer or a credit card/BNPL lender).

Most consumer payments are initiated from a physical or online point-of-sale that is outside the walled garden of the paying bank. Historically, this problem was solved by:

i. network operators like Visa and Mastercard that connect the merchant to the paying bank

ii. the paying bank expanding its walled garden to the merchant, creating a closed loop system (example, private label credit cards)

The above is sub-optimal in developing countries because:

a. merchants cannot afford to bear the cost of card interchange fees

b. vast populations have bank accounts but not credit cards

The advent of the cloud has seen API based digital innovation, enabling consumers to transact without cards. Two forms of open banking have emerged:

Bank specific APIs

Each bank offers APIs via which third parties connect to them. Since it is cumbersome for merchants to connect to each bank individually, technology aggregators (e.g., Plaid) usually come in between the merchants and the banks:

Network APIs

Parties connect to one network via APIs, e.g., the Unified Payments Interface (UPI) in India.

Friction in settlement communication

After a payment is authorized at point-of-sale, paying banks communicate payment details to beneficiary banks via a separate process. Since each bank is a walled garden, payment rails administered by intermediaries are needed to connect them:

Reliance on antiquated payment rails imposes working capital costs. For instance, merchants get paid 2–3 days after a credit card transaction occurs. It is not economically efficient for banks to settle every credit card swipe between themselves individually. Hence, banks batch transactions, which causes delays.

Two innovations have emerged to solve for this:

Real Time Payments

RTP is simply a payment rail where banks exchange information for low-value payments between each other much faster, creating a middle path between expensive wires (RTGS) and delayed ACH:

Closed loop systems via digital wallets

Digital wallets create closed loop systems by bringing consumers and merchants within the umbrella of an omnibus bank account controlled by the wallet provider. In a wallet-to-wallet transfer, the wallet company simply updates the share of the bank balance in the omnibus account attributed to different customers.

The Blockchain Solution to the Walled Garden problem

Blockchain addresses, unlike bank accounts, do not exist in walled gardens. Payment rails are not required because:

i. each node (computer) of the blockchain records the address and associated transaction history independently

ii. the nodes communicate with each other via the internet using a communication protocol coded in the blockchain software

In a bank permissioned blockchain, each participating bank can maintain a node but there is probably no need to duplicate data across each node.

Below is a visualization of a blockchain payment:

Step 1:

The payment initiator authenticates herself with the private key of her blockchain address at the point of sale, to initiate the payment.

Step 2:

The transaction is broadcast from the point of sale via API to the blockchain.

Step 3:

The private key of the payment initiator is verified and value is transferred from the consumer’s address to the merchant’s address. A smart contract applies rules (e.g., proof of delivery) as needed.

In the above model, the payment authorization and settlement occur near simultaneously, eliminating latency.

While the blockchain solves the walled garden problem for domestic payments, in cross-border payments, regulatory hurdles are significant. Further, Governments are not likely to support the creation of a SWIFT like monopolistic cross-border system for geopolitical reasons.

Friction source 3: identity awareness

The third source of friction is the difficulty of verifying identity. Two proxies are commonly relied upon:

i. Physical possession of a payment instrument like a credit card, but with growth in e-commerce, this became less relevant.

ii. Knowledge of privileged information like credit card details, passwords, PINs etc.

Unfortunately, the above could easily be stolen. Worse, making a payment involved sharing account details with strangers. For instance, a counterfeit card could be created by extracting the information in the magnetic stripe.

3 models of payment security innovations have emerged:

Model 1

The payer shares account information with the merchant but the technology makes it hard to misuse the information, e.g., chip cards.

Model 2

The payer does not share account information. Instead,

a. the beneficiary (merchant) shares her bank account with the payer in a disguised form (QR code or a phone number) and

b. the payer approves the payment from an app on her own smartphone using PIN/password

Model 3

Model 3 dispenses with the proxies of possession and knowledge, and directly verifies the who. It is best used in conjunction with Model 2. The payer can use facial recognition or fingerprints to approve from her smartphone app.

The Blockchain Solution to Identity Awareness

Blockchain networks use cryptography to authenticate the account owner. An in-store transaction is illustrated below:

The following are unique to the blockchain:

i. it is not the private key that is validated but the digital signature generated (Step 3) from the private key

ii. blockchain software uses arcane mathematics (Step 5) to validate that the digital signature was generated from the correct private key without knowing the private key.

iii. just as we can sign a cheque offline, the payment app can generate the digital signature (Step 3) in an offline mode.

The above 3 observations, when taken together, means that even the account issuing bank’s systems need not record the private key!

However, there are practical challenges:

i. private keys can be stolen or lost, in which case the assets held by the blockchain address cannot be accessed

ii. private keys are long & non intuitive. Hence, to prevent manual keying on each payment, most people would store them on their online wallet apps, exposing them to cyber risk.

Hence for practical purposes banks could

o keep custody of the private key or

o eschew cryptography altogether

Regardless, private keys can be used across the 3 models of security innovations discussed above. For instance, a chip credit card can point to a private key protected lender’s address instead of a lender’s bank account. Similarly, private keys can be protected behind a biometric wall.

Summing up

A bird’s eye view of the payment solutions landscape (see below) leads to the inference that the disjointed flows problem is the least well-served today:

Instead of creating a parallel blockchain payments system, an optimal solution will combine Smart Contracts with best-in-class payment solutions that already exist.

The effectiveness of Smart Contracts in integrating the real world with payments can be visualized in the continuum below:

Configuration A

This is the current state.

Configuration B

The delivery side occurs in the real world which is disconnected from the blockchain but third parties (Oracles) input the off-chain information required in smart contracts. This could be a shipping company recording delivery or a title company confirming real estate title has been transferred.

Configuration C

The delivery side is directly connected to the chain via connected devices’ data. An example would be a car key that gets activated on payment.

Configuration D

An example of the extreme right (Configuration D) is professional crypto trading. The delivery side (purchase of a crypto token) as well as the payment side (via stablecoin) occurs on-chain.

Solving the disjointed flows problem is a powerful tool in low trust situations as buyers and sellers can maximize the what, instead of worrying about who they are transacting with. Blockchain payments should be viewed as a commerce enabler rather than an efficiency play.