The Uncontrollability of Payment Systems
How The Cloud Made It So Easy To Build Payment Applications That Are Beyond Our Control
Welcome to Money In Transit, the newsletter bridging the gap between payments strategy and execution. I’m Alvaro Duran.
It is unfair of me to say it, but I’m very happy with how this week’s post has turned out to be. Initially, I wanted to shine a light on the implications of cloud technology in payments, but in the end, it ties up very nicely with one of my favourite posts in this saga, Must There Be a Payments Platform?.
Today, I’m looking into the buy vs build question from a different angle: what has made so easy for startups to give up their responsibility to their customers’ money? The answer, surprising to me when I started writing this post, is technological.
Consider sharing this post with a founder whose startup is facing problems integrating with a payment gateway.
I believe that one of the biggest misconceptions about how engineers work is that, very often, the reason applications fail is beyond any engineer’s control.
Take Plaid, for instance. This is how Ben Thompson from Stratechery describes what the hell is Plaid doing behind the scenes:
Many banks in the U.S. do not have APIs (Application Programming Interfaces) that offer a programmatic means of accessing a particular account; those that do are not consistent with each other in either implementation or in features. Plaid gets around this by effectively acting as a deputy for consumers: the latter give Plaid their username and password for their bank account, and Plaid utilizes that to basically log in to a bank’s website on the user’s behalf.
Most people read this and think “wow, what a shady thing to do”. After all, bank login information should be part of anyone’s deepest darkest secrets, but apparently 1 in 4 people in the US have shared that information with Plaid.
Engineers read this and think “Satan’s hand is all over this”. The industry term for “effectively acting as a deputy for consumers” is scraping, and it consists of opening a web browser in the background, clicking around, filling in forms and downloading data with a machine, pretending to be a human.
Scraping is the reason you have to complete stupid CAPTCHAS from time to time.
What’s remarkable about scraping is that there is an alternate Universe in which communication between two machines online happens via scraping each other’s websites, rather than using APIs.
But we don’t live in a world like that. That kind of way of working is untestable: if the other party makes a change, however minimal, the risk that the communication gets completely broken is very high, as any scraper will tell you. The line between “everything is fine” and “the comms are down” is very thin.
APIs are not like that. With APIs, communications are testable. Not that you couldn’t check that things are fine when you scrap a website. APIs, unlike scraping websites, rely on consistent interfaces. That means that both parties have some form of an agreement of what is expected from each other (what is the format of the request, and what will be the response in each case) that allow engineers to write tests for them.
And tests are great because, when there are a million things to make sure of, you want machines to check them for you. Scraping websites doesn’t allow you to do that. APIs do.
And so, machines communicate online mostly via APIs. Which, at least in theory, makes things easier for engineers, right?
Yes, but there’s a but. When you overuse APIs, you are tempted to think that as long as each individual component works fine, everything will be fine.
And nothing could be further from the truth than that.
Every Payments Company Is a Distributed Systems Company
It all probably started when Amazon decided to make teams communicate internally via APIs:
So one day Jeff Bezos issued a mandate. He's doing that all the time, of course, and people scramble like ants being pounded with a rubber mallet whenever it happens. But on one occasion -- back around 2002 I think, plus or minus a year -- he issued a mandate that was so out there, so huge and eye-bulgingly ponderous, that it made all of his other mandates look like unsolicited peer bonuses.
His Big Mandate went something along these lines:
All teams will henceforth expose their data and functionality through service interfaces.
Teams must communicate with each other through these interfaces.
There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
Anyone who doesn't do this will be fired.
Thank you; have a nice day!
APIs are a nice way to communicate for two companies. But they can be a very nice way to communicate for teams within a company! If you piece your software systems by team, then you can delineate which systems need more resources, which ones can ship new features faster, etc. As we have seen, this is great if you want your applications to be PCI compliant, because you can isolate the critical parts of your payment applications, and use tokens everywhere else.
Soon enough, engineers have started to break down applications into smaller and smaller parts that communicate as if they belonged to different companies altogether. We call them microservices.
Microservices have blurred the line between what you build and what you buy. This has been great for SaaS, because now it makes a whole lot more sense to integrate with applications run by specialists, rather than having to build everything in-house.
It is at this moment in time when Angela Strange, partner at a16z, predicted that every company will be a fintech company. Not coincidentally, she mirrored what had happened for Amazon, and saw a future in which monolithic banks could be broken down too:
What if, similar to what Amazon did to compute and storage, companies focused on each layer of [banking service stack] and provided that step as a service?
She talked about it as if it were a good thing. And it mostly is! However, it is one of those situations where, in order to make things easier for consumers, engineers have taken an enormous amount of complexity and hardship.
Short term, it allows you to Move Fast. Long-term, engineers have to juggle with so much complexity, it becomes very easy to Break Things.
Have you ever seen one of those PowerPoint slides with thousands of tiny logos? We live in a world where every startup can build payment applications, but in order to do so, they have to partner with an external provider, or even multiple.
Angela Strange had one of those slides.
Turning the Tables
However, something extraordinary is happening now.
The tables are slowly turning. First, the first generation of neobanks, like Monzo and Revolut, have started to replace the integrations they have with external providers with in-house alternatives. In startups where there was a strong engineering culture from the beginning, the strategic move nowadays is to regain control of what they offer to the end customers.
And second, the Banking as a Service startups that were the future? Most of them are failing.
This, for non-engs, sounds like regulators are pressuring them. Alex Johnson from Fintech Takes discussed this on a post a few weeks ago, and his thesis was that it’s all because, for the partner banks, it is very difficult to crack down on fraud on behalf of these providers:
Hopefully, this essay has demonstrated just how precarious BaaS, as a business, has become. One of the folks I spoke with while researching this piece described it as an anti-network effect business, meaning that the value of your service actually goes down as more programs use it (because each new program adds compliance risk for the BaaS provider and the other programs already relying on it).
— Can Anyone Win BaaS?
His main thesis is that BaaS is dead because of regulation. But looking past that, there’s a hint that perhaps outsourcing the programmatic interaction to external providers wasn’t a good move for financial companies. And they’re slowly realizing that.
The demise of BaaS is happening at the same time as Monzo and Revolut are moving their operations internally.
I don’t think it’s a coincidence.
Untestable Payment Systems
Every time a startup decides to integrate with an external provider, they are making a small admission of defeat. Microservices have made integrating with external companies so easy, CEOs out there think that in doing so, they have one less problem to solve.
But haven’t these CEOs considered that their companies’ data now lives in another company’s database?
Accessing that data is like accessing a microservice, only worse:
You don’t have control over those systems (when they go down, what caused it, who is responsible for them)
Their testing environments are built with the sole purpose of making the integration with real life systems easier, with few incentives to help at maintenance.
Payment applications shouldn’t become distributed systems. We simply went along and agreed that it was better than the alternative.
It isn’t.