Bank transfers as a payment method

Most transfers of money in the economy are made via bank-to-bank transactions. Most payments are currently not. There is substantial innovation happening in bank transfers, especially outside the U.S., and they will be a larger portion of the payment mix in a few years. It’s worth understanding why, and why it hasn’t already happened.

What is a payment, anyway?

Stripped to its fundamentals: a payment is a message, with new information, about a debt, with a certain confidence level associated with it.

This is not how most of the world thinks about payments. You probably think that when you pay for a coffee with a credit card you’re “moving money” to the cafe. But that isn’t what physically happens; generally speaking, nothing moves as a result of the transaction and, most especially, nothing moves while the coffee is still warm. So why is the cafe happy to give you coffee after you’ve flashed your plastic?

You could have made a payment by saying “I’m good for $4; please give me coffee”, and in some cases (such as stores you have a tab with) that suffices. But the reason it works at scale is that the trust problem has been solved by so-called payment rails, which are a constellation of firms that have implemented a protocol to quickly make a series of offsetting promises about debts such that the cafe quickly becomes almost positive it is owed money for the coffee and that that debt will be collected with a very high certainty.

In credit cards, a brief and intentionally simplified version of the actions of the payment rail is: you agree with your bank that you owe them $4, your bank agrees with a credit card network that it owes a particular processor almost $4 (taking a fee), and the credit card processor agrees with the cafe that it owes them a bit less than $4 (taking another fee).

In the settlement phase of the transaction, the credit card processor makes an agreement with its bank that it owes the processor a bit less than $4, which it discharges by having their bank agree that it owes the cafe’s bank a bit less than $4, which the cafe’s bank discharges by agreeing they owe the cafe a bit less than $4. And so your debt for coffee is now two offsetting debts; between you and your credit card issuer, and between the cafe’s bank and the cafe. You will, at some point in the future, probably up with your credit card issuer, and the cafe will probably withdraw money from the bank (perhaps to e.g. buy beans or pay the barista), but from your mutual perspective the transaction for the coffee will be long over by then.

Critically, settlement happens later (painfully later, measured in Internet speeds; a few days by more traditional calendars).

Many people think that this is painfully complicated and would be much simpler if you could just pay money from your bank account to the cafe’s bank account directly. Why don’t we do that, and what would it take such that we could do that?

Core features of payment methods

When we covered payments in Japan, many readers were surprised that a convenience store needed to interoperate with 40 payment methods. Worldwide, there are more than a hundred major ones, and a long tail with literally thousands of entries. These all compete with each other for customers, for businesses willing to accept them, and for individual transactions.

There are something like fifty axes you could categorize payment methods by, but to make it simpler for this essay, lets compress them to five: total cost, customer user experience (UX), certainty, settlement time, and reversibility. These five features are why bank account to bank account payments are not yet routine for most transactions, and improvements to them are why that is going to change over the next few years. (And, indeed, why they’re already seeing explosive growth in some markets).

Cost: As we’ve covered previously, the payments industry makes most of its revenue by taking a small fee from every transaction. The exact size of that fee and how it is priced varies wildly between payment rails. Businesses would broadly prefer to spend less money on payments costs, but that isn’t their only preference.

Customer UX: Different ways to transact look very different from the customer’s perspective, both in terms of the benefits they are offered by a payments scheme (rewards, warranties, protections against fraud, etc) and the actual mechanics of communicating with the business they are paying about their payment method.

The credit card networks made this so easy in real life that we underappreciate how much intellectual effort underpins it: you pass a plastic token to the cafe, the cafe passes it back, and neither of you even had to consider the supply chain which resulted in a custom-made computer processor arriving in your mailbox or the public key cryptography that that chip used to prove to its issuers that it was absolutely positively in someone’s physical possession at the cafe at exactly the time it ran the transaction there.

It turns out that users’ propensity to transact is acutely sensitive to the friction associated with transacting, particularly online. Since no one has figured out how to pass a plastic token through the Internet yet, there must be some data entry step at some point, and payment methods vary in how (and where, and when) this takes place.

Certainty: If payments are a promise about a debt, and some promises are worth more than others, how should a business reason about promises made using a particular payment method? Businesses get a decision about when to provide goods and services; should they provide them immediately after (... or even before?) a payment is made? Should they wait until the payment is more likely to successfully settle?

Settlement time: There is, for many payment methods, a gap between when the payment is made and when the recipient receives funds. For credit cards, in much of the world, this is a few days, but it can be much longer. (In some markets, such as Brazil, the market standard expectation is for credit card transactions to settle in approximately a month.)

Reversibility: Some payment methods allow payments to be reversed after settlement. This is, in the main, a consumer protection measure which payment schemes use to make transacting on them more palatable with consumers. Businesses as a class benefit from that, since they’re in favor of more transactions and larger transactions, but particular businesses suffer a bit when the embedded option is exercised and a transaction is reversed after the product/service has been delivered.

Since businesses have more knowledge of their cost structures and risk than payment networks do, some businesses prefer less reversible payment methods and some prefer transaction-maximizing payment methods.

An example of how subtle this is: precious metals dealers are extremely vulnerable to fraud (because they’re in the business of literally giving people gold, which can be trivially turned back into money at another precious metal dealer). They earn relatively small margins on their transactions. Accordingly, they strongly prefer less-reversible payment methods.

Video game sellers are also extremely vulnerable to fraud, both so-called “friendly” fraud (where the customer wanted the service but didn’t want to pay for it), family fraud (child and parent disagree with respect to desirability of purchasing the video game; bank backs parent; video game seller loses out), and fraud where the buyer is using stolen credentials to obtain something which can be resold (similar to the main risk to precious metal dealers). Unlike precious metals, video games have extremely high margins, and therefore most in the games industry optimize for payment methods with high conversion rates and treat fraud as a cost-of-doing-business.

How bank transfers stack up

The payments industry, and the tech industry more broadly, is sometimes excessively informed by many of its members being physically within the United States, and the “natural” thing for me to do at this point would be to explain ACH payments and why they’re not acceptable for most transactions.

Nah, let’s do it the other way.

The most interesting bank transfers payment method in the world right now is India’s Unified Payments Interface (UPI). It is less than 5 years old, is currently experiencing meteoric month-over-month transaction growth, works almost flawlessly for online transactions, and broadly benefits from being developed in the context of the modern Internet rather than being an overlay network on paper moving around.

UPI offers extremely low cost, instant confirmation, instant settlement, virtually certain, low reversibility risk transactions. That is a truly magical combination, and explains much of the growth. The fact that, in India, it is mostly competing (even for online transactions) with physical cash settlement is another. The dominant way to pay for e-commerce transactions in India has historically been cash-on-delivery, which necessitates a complicated and leaky value chain between delivery staff, delivery networks, payment networks, and the sending business.

The customer UX of UPI is novel, and is to other bank transfers what URLs are to IP addresses. If you don’t live in India, it is highly likely that your bank-to-bank transactions involve giving your counterparty a code representing your bank, a number for your bank account, and some metadata about yourself. UPI instead has the user register a “virtual payment address” (VPA) with their bank.

It might look something like an email address, but doesn’t have to; the important part is that it can be short and memorable rather than a string of digits. The business attempting to charge a VPA communicates details of the transaction to the clearinghouse, which performs a real-time lookup of that VPA to find which bank custodies it. That bank then does a real-time authorization with the user directly, typically via a push notification or SMS message, confirming the details of the transaction.

In an IRL transaction, one could do the same (via keying in your VPA on a terminal) or, more commonly, one could use QR code payments, similar to the booming category in Japan, which execute the handshake for you. And indeed, India’s market leader Paytm is a partner in Japan’s market leader PayPay.

That's what UPI does. Here is what UPI does not do:

Payment authorization is not linked with banking information. Without the user in the loop to authorize the transaction in real time, possession of a VPA is essentially worthless. This is very not true of banking credentials in, most notably, the U.S. Knowing a bank account number in the U.S. is sufficient to try debiting it, and bank account numbers are also passed around promiscuously, such as on checks (in carefully designed block print to make these security tokens even more readable). Credit card numbers have the same problem.

This is a very important design choice. It optimizes for customer security but pessimizes for payment convenience. Most transactions (by count and by transaction amount) are repeated transactions; much of the payments industry exists to make repeated transactions less frictionful for all parties. SaaS is one salient example, but rent and mortgages are typically fixed amounts on a fixed schedule between repeated parties, most e-commerce merchants will hope the user comes back (and want to charge their credentials on file rather than forcing a re-authentication), etc etc. UPI adds substantial friction to repeat transactions compared to how bank transfers are implemented in many countries.

Access to a bank account statement is not needed to confirm payment. A key function of payments rails is allowing someone, for example a store clerk or a cronjob running at an e-commerce retailer, to verify that a transaction was (probably) paid for without needing to be able to access the company’s bank account. For understandable reasons, access to bank accounts is tightly controlled within businesses.

This is historically difficult for bank-to-bank transfers! They assume you have access to the bank account to verify receipt of them! And they mostly don’t have metadata about the transaction on them! So you need a human, with full read access of all recent transfers, to manually reconcile to see that the payment happened! This deserves even more exclamation points than it already received!

Because UPI is designed to be intermediated by computers rather than by humans, transactional information gets captured by the payments company while the transaction is in progress, and that can tell the clerk (or cron job) that the payment succeeded without them needing access to the bank account.

This is a fun engineering challenge in many countries, which are often overlaying bank transfers as a payment method on top of bank transfers as a settlement method.

One method of solving it is issuing “virtual bank accounts”, which are either single-use or limited-use numeric bank accounts (thus the acronym VBAN, for “virtual bank account number”) which are allocated to a predicted transaction shortly before it happens. If that VBAN receives a transfer in the correct amount, you can (hopefully) conclude it was from the right counterparty for the right transaction without needing to investigate it manually. You can then have a system which has access to the VBA (say, one operated by a payments provider) communicate that the transaction was authorized to the clerk (or cron job) without needing the payment provider to have access to the business’ underlying non-virtual bank account.

Bank payments in countries with less modern systems than India

There isn’t a strict hierarchy of good/better/best for bank payments. Different ecosystems have made different tradeoffs and arrived at their current position via very different historically contingent paths.

Japan

In Japan, domestic bank transfers go over the Zengin network. (Zengin is short for Zenkoku Ginkou Shikin Kessai Network, and rather delightfully would literally translate to something like “All The Banks”, which is indeed their domestic footprint.) They’re commonly referred to as furikomi, in the same way that many savvy U.S. consumers would call a bank transfer an ACH transfer (even if it didn’t actually hit the ACH network).

Zengin is a clearinghouse; it operates as an interbank intermediary which both routes information about individual payments and also acts as a counterparty for settlements. A user’s bank credits them with funds instantly if received during business hours; the funds are actually received after business hours, when Zengin totals up funds flows for the day and sends instructions to the Bank of Japan for net settlement between participating financial institutions.

Furikomi are almost instant during business hours, and the plan is to gradually increase that to almost all of the time. (The “More Time System” is, because Japan, helpfully explained by a penguin fairy in an anime short if you’d like more detail.)

Furikomi are not free or near-free, and while there is government pressure to reduce costs to pass to consumers some of the benefit of computerization, they are still a major revenue driver for banking in Japan. The cost of each payment is borne by the sender, difficult to predict in advance unless one extremely enjoys banking procedure trivia, and generally in the range of $1 to $8 irrespective of payment amount.

Funny story: I bought my condo with a furikomi after being disbursed my mortgage’s amount into my bank account, and the bank solemnly informed me that they would, of course, charge an $8 fee on the transaction. It was politely suggested that I should wait in the room with the bank officer for the few minutes where the money was in my account, because while it would seem extremely unlikely that someone would rob a bank by getting a mortgage and then simply leaving with the money, it has happened a non-zero number of times.

Furikomi require the sender to know three numbers about the recipient (bank number, branch number, and account number) and result in the recipient learning two things about the sender (name and phone number, both of which are configurable at transaction time). This extremely limited information makes furikomi positively maddening to reconcile. The best way to do it is to tell the consumer to overwrite their name to include a transaction ID, but many consumers will ignore that instruction or typo their transaction ID, and as a result furikomi are generally received at Internet speeds but interpreted at salaryman speeds, as a team of overworked clerks gets a daily Excel file of bank transactions and laboriously associates them with anticipated invoices, mostly via manual labor.

Because furikomi have a user-borne cost and because they’re too slow to release services in real-time, they are mostly used for B2B payments. (Consumer use of furikomi is generally for large-ticket purchases like e.g. rental payments, cars, professional services, and similar. One would never buy a coffee with them.)

United States

In the U.S., there are multiple clearinghouses for bank transfers. The most common one in payments is the Automated Clearing House (ACH), which hints to its historical origins: ACH was an improvement on manual clearinghouses, which were originally used to process millions upon millions of paper checks in a mostly centralized fashion to avoid the necessity of each bank breaking out each other bank’s checks to courier to them directly.

ACH transfers support both push and pull transactions, but they have an interesting relationship with payment certainty. When you start an ACH transaction, you get functionally no guarantee that the account numbers were accurate and the account has funds sufficient to cover the transaction. You will have more of a guarantee generally later that day that the transaction avoided the most glaring problems, but still no guarantee of funds sufficiency, because ACH is “negative confirmed”; you don’t get a final message representing probable success, you merely observe the lack of a message representing certain failure.

As a result, most businesses relying on ACH payments will not release goods or services prior to the end of the “return window”, which is the time by which an ACH participant is bound by regulation to send a message indicating insufficient funds. This is typically 5 business days. NACHA, the organization which administers ACH, huffily insists that ACH doesn’t actually take 5 days to clear, and that it happens multiple times every banking day, but in practice most recipients (or their banks) will hold transactions for several business days prior to accepting them.

ACH payments are generally free to end users in the U.S., though a few banks will attempt to monetize them. (Looking at you, Bank of America.)

Bank transfers are an extremely small percentage of customer-to-business payments in the U.S. In addition to the speed issue, which might get improved by FedNow when it launches (wags have referred to it as FedLater), bank payments have no consistent way to receive metadata, and despite being no-cost they compete with well-developed credit card ecosystems which credibly offer better-than-free pricing through rewards schemes (to the customer, who generally gets to choose which payment method they use to transact).

Europe

The Single Europe Payment Area (SEPA) offers free, instant transactions between European banks. They’re pull based; a user communicates their banking information to a business, which debits the user’s account, rather than the business communicating their banking information to the user in order to send them money.

Again, this is a choice and it has some consequences. One is that payment credentials in Europe are reusable and, as a consequence, both convenient to keep around to facilitate repeat transactions and persistently dangerous if leaked.

Fraud rates in Europe for SEPA transactions are notably high, at many, many multiples to UPI or furikomi. (And probably higher than ACH pull payments, though that is a closer call.)

It is often underappreciated outside the industry that fraud regimes are a choice which have to balance many social goods. Europe made a political decision to allow instantaneous payments between nations, including to financial institutions in less-developed countries with weak controls. That decision has a cost associated with it, but the European project has many costs associated with it, and Europe has decided as a collective body to allocate them in some fashion based on political processes.

Why isn't the future here yet?

I expect we’ll see bank transfers as a more prominent part of the payment mix in much of the world.

Amazon is often credited with asserting three invariants about customer wishes: they want more selection, at lower prices, delivered faster. In payments, we should expect the arc of history to bend towards instant payments, which are free or better-than-free to customers, which are pervasively available within nations, which interoperate (by government mandate and/or competitive pressure) between individual banks and wallet systems, and which have very, very good online and IRL experiences.

Bank transfers are far from that idealized future state, but getting closer.

In India, and perhaps in similar countries, I expect bank transfers (via UPI) to eat much of the payments market, and future payment methods will often be UX affordances on top of underlying nearly-free bank transfers rather than parallel systems.

In the U.S., I expect bank transfers will struggle to see general adoption as a payment method, even after the release of FedNow, but who knows what will be built on top of them. Cards are very popular and entrenched, and the economic model allows them to outcompete free on price alone. New payment methods will need to find something very interesting to offer to capture the user’s interest, and some participant in the transaction to pay for it; Buy Now Pay Later had the interesting insight that some businesses would happily underwrite their customers’ use of credit if someone else took the payment risk. Perhaps we’ll see similar experiments in applications using bank transfers as the underlying payment rail but with more complicated economics split creatively between the parties.

In Japan, I expect that financial institutions will push to make furikomi better but not better enough to compete with their card issuing businesses unless government decisively forces the issue. Although banks are a policy arm, someone has to pay for them eventually, and with net interest mostly off the table due to Japan’s economic situation for several decades, payments are the most viable option on the table in consumer banking.

One interesting gap in bank transfers almost everywhere: outside of a nation (or for the EU, an economic block), they tend to be almost impossible to use. (International wire transfers exist, but they’re almost physically painful, and none of the improvements discussed above are yet contemplated for them.) International commerce is exploding; Chinese consumers, for example, are increasing their spend ex-China at something like 30% annually. Payment methods which punt on international transactions can’t solve for payments in even the medium term.

My employer Stripe believes that the world will be knit together by what we call the Global Payments and Treasury Network (GPTN), allowing customers and businesses to interoperate between various bank-based networks in countries/regions without themselves needing bank accounts in every region they do business in. We’ll see! There exists lots of work yet to do in building it. (As always, opinions here are my own thoughts.)