Virtual Bank Accounts Are Virtually Inexhaustible

Why are we using unstructured text when a strict alphanumeric ID can do the job better?

There’s something paradoxical about reconciliation.

On the one hand, it looks simple: here’s a receipt, or a confirmation of payment, and here’s a bank transfer with the same amount, go figure if they’re related. If you had all inside a massive database, a simple JOIN statement would be all you need to make this relation apparent.

On the other hand, reconciliation is a perennial problem, and big companies have given up on having an automated solution that doesn’t involve humans at some point.

I just don’t get it.

For the last several hundred years, [B2B payments] have followed a very well-understood dance. A deal is struck. The exact amount of compensation is decided upon and memorialized by the sender in an invoice. The purchaser receives the invoice, reads it, then wraps money around a metaphorical brick and throws it through a metaphorical window. Someone on the other side of the window then applies forensic science to the question of what caused this particular brick to arrive.

— Patrick McKenzie, Reconciliation: A game designed to frustrate the player

Well, I kind of get it: reconciliation is one of those things that’s invisible when things go well, but panic-inducing when things go wrong. That’s why there seems to be no way around humans getting involved in it: machines have no skin in the game.

But that’s suboptimal. In order for reconciliation to work 100%, we need the JOIN key that makes the two “tables” (receipts and bank transfers) work.

What we had so far is that free-text, sender-controlled piece of data most banks call “Concept”. Especially in B2B, where bank transfers as a payment method are the norm (though it’s becoming more frequent in B2C as well), there’s a disconnect between the invoice, which gets created automatically at the Point of Sale, and the transfer, which gets created manually by the payer when they receive the invoice.

The Concept, then, becomes the only piece of data that the purchaser can control, under the advice of the seller, to make the reconciliation process easier, or at least possible.

That said, notice that humans don’t need to get involved. They aren’t for card payments, and they definitely aren’t involved anymore in stock exchanges. The only reason humans are still involved in B2B reconciliation is because it has always been that way.

From Stock Markets To Ledgers, Part I: Fairness

That, and a lack of creativity when it comes to the other pieces of data involved in a transfer.

I’m Alvaro Duran, and this is The Payments Engineer Playbook. You’re already subscribed to free newsletters that “teach” you how to get a job as a software engineer.

But you don’t want to get a job; you already have one. What you want is to learn how to be great at your job. Especially as a payments engineer, where stakes are sky-high, and the margin for error is razor-thin.

In The Payments Engineer Playbook, we investigate the technology that transfers money. All to help you become a smarter, more skillful, and more successful payments engineer. And we do that by cutting off one sliver of it and extracting tactics from it.

In today’s article, we’re going to look at creative ways to make reconciliation easier without human involvement. We’ll start with the hackiest of all, all the way to using bank accounts in a more flexible way, and what it would take for this solution to become widespread, eliminating the need to keep discussing reconciliation.

Here’s what you can expect in today’s article:

• How to use the transfer amount as a reconciliation tool

• Seeing bank accounts beyond a depositor’s vaults of cash

• Why virtual bank accounts cannot be exhausted, no matter how much you try

• Moving from BAN as address to BAN as intent

Enough intro, let’s dive in.

Sneaky Discounts As Reconciliation Tool

Bank transfers have in practice 5 pieces of metadata:

• The receiving account number

• The receiving account name

• The sender’s name

• The amount

• The concept/reason/description

Given that the first two are about you, and therefore a bit pointless, and that names aren’t as straightforward as you may think¹, the only pieces of data you can use to coordinate with the buyer are the amount and the concept.

You’ve probably been in situations where you were expected to input some invoice ID in the concept line item, and know by now that people seem able to fill in everything except the actual invoice ID, turning reconciliation into a nightmare for the Accounts Payable team.

So let’s try the amount instead.

One hacky way that’s really a thing is to sneak a line item into the invoice for a specific discount for the customer, one in the order of cents. The purpose of this discount is that the final two digits of your invoice are unique among the invoices you expect to send that month (if you’re Net 30).

These 2 digits are the JOIN key you need to match invoices and transfers. Problem is, this breaks down at scale.

Something else you can do, though, is to change your approach to bank accounts, so that they become less about you, and more about the invoice.

Bank Accounts As Intent

Because of the tiny scale on which B2B transfers used to happen, bank accounts are considered a form of primary key of the accountholder’s deposit box. If banks still were a metallic vault full of gold coins, you’d still expect your small container to be labeled with the IBAN of your bank account, the string of numbers and sometimes letters of up to 34 characters in length you’re familiar with.

It almost looks heretical for somebody to have 2 accounts in a bank, unless there were some special use case for it, such as the business’s account or the one for investments.

But banks no longer have vaults in the basement, and you don’t have a deposit box.

Banks move money by sharing files, and that's OK

Instead, I want to persuade you that, if your bank were more conducive to it, you could have thousands, even millions of IBANs available, so that every time you issued an invoice to a customer, you could add a unique bank account number to it, so that each individual account had a history of a single transfer, making the reconciliation process so stupidly straightforward, even a machine could do it.

I call that the Bank Account As Intent approach.

The reason this is possible is because banks can issue a massive number of “virtual” bank accounts (VBAs) that serve as proxy for a single, “physical” account.

You’ve probably heard of Virtual Credit Cards: they are an extension of the ISO 8583 credit card protocol, but for identifiers that don’t have an actual plastic card associated with it, can live on your phone, and can pay via NFC.

The Ultimate Guide to Payment Tokens

In fact, many companies, including travel agencies, have been using VCCs for a long time in order to become merchants of record rather than merely recommender systems. By issuing a single-use VCC for each payment, travel agencies are able to uniquely match the payment made to the airline with the one received from the customer.

These VCC programs, though, only work with a modicum of scale. VBAs, instead, can be used at any scale.

Can’t A Bank Run Out of Bank Accounts?

How much traffic would a bank need in order to run out of bank accounts?

More than a lot. IBANs, as currently implemented, can hold in the order of 1 nonillion bank accounts, or 1 followed by 30 zeros² per country. In some countries, given that they allow for letters as well as numbers, that number is even higher.

For comparison, the Earth weighs around 6 septillion kilograms, or 1 followed by 24 zeros. If you could divide the planet into 1 kg rocks, you’d need one million Earths to have as many rocks as bank accounts. Again, per country.

Bank accounts, without any modification or upgrade, are virtually inexhaustible.

So the question isn’t whether we’re going to run out of bank accounts eventually. We’re not, even if we only recycle them every couple of decades.

The actual question is: why are we so greedy with our bank accounts?

How To Live In a World With Unlimited Bank Accounts

If bank accounts cannot be exhausted, I want to have one bank account per purchase.

Rather than sharing the same bank account on every invoice I issue to a customer, I want to never reuse bank accounts, and attach each invoice its own virtual bank account.

Of course, your bank may object to it. Banks, especially traditional banks, aren’t used to this approach to bank accounts, and you may incur fees in order to create new virtual bank accounts.

No problem. There are already a bunch of new banks already geared towards the indiscriminate use of virtual bank accounts (Increase, Modulr, and others) that provide the ability to buy VBAs in bulk, at a discount.

It is only a matter of time that this practice will be prevalent: how hard could it be for a bank to issue one more bank account?

And if it’s hard, why is that?

But even if your bank has no objections, the regulator may have something to say about this. This is where we the engineers step in: each invoice, and the metadata involved in creating it, can be stored alongside the bank account details, so that auditors can review the process and approve or reject each individual transaction.

But now that we can use the bank account as the link between the invoice and the transfer, we’ve just found our JOIN key. One that’s unique and standardized.

After all, VBAs are indistinguishable from physical bank accounts. The customer would have no idea it’s happening. And, since they don’t need to be recycled, they can use it and reuse it for recurring payments.

From the point of view of the customer, life is still the same. But from the point of view of the seller, life is so much easier.

The only thing blocking the adoption of VBAs

The only thing blocking the adoption of Virtual Bank Accounts more widely is the banks’ unwillingness to do it.

Payments is still a very path-dependent industry. They still use mental models close to checks and vaults in the basement to describe it. And are missing out on entirely new ways to approach B2B payments so that reconciliation becomes a problem solved once and for all.

Why Payments Are Path-Dependent

Reconciliation, therefore, isn’t a matching problem. It’s an addressing problem. For the longest time, we were missing a JOIN statement that made the whole process straightforward.

We now have it.

That’s it in The Payments Engineer Playbook. I’ll see you next week.

1. Spanish names, to give you an example I’m familiar with, are notably long, something that confuses the hell out of foreigners. Most Spaniards (if not all), have at least two surnames, and each can be a compound surname. Note that the city of Los Angeles, when it was claimed by Juan Rodriguez Cabrillo (see, two surnames) in 1542, was named El Pueblo de Nuestra Señora la Reina de los Ángeles del Río Porciúncula. Imagine putting that in a baseball cap.

2. Not all numbers are valid under the IBAN protocol, which is why the number isn’t exactly that, but it’s close enough for the purpose of showing how staggering the number is.