ORMs are more harm than good. Everybody knows it.

They start fine—that’s one reason everyone adopts them in the first place. No boilerplate. But then there’s some special use case down the line where you yearn for the expressiveness of SQL (rather than the way your ORM forces you to write it), and there’s no way to do it.

Which is why every engineer worth their salt will tell you not to use an ORM. Even when they have one, spread throughout the software.

“Why?”

I used to ask that question too. It first started as a thought I stared at, one that had never struck me before. Software is of our own making, and if it feels like a prison, then we’re the warden.

And it’s not like this is a new problem. There’s a well-known article by Ted Neward called The Vietnam War of Computer Science in which the problems of using ORMs are described, and the fact that it uses the Vietnam War as a metaphor should tell you how long ago this article was written.

Even Steve Wozniak has written on the topic, arriving at the same conclusion: just learn SQL:

I’ve come to the conclusion that, for me, ORMs are more detriment than benefit. In short, they can be used to nicely augment working with SQL in a program, but they should not replace it.

— Steve Wozniak, What ORMs have taught me: just learn SQL

I resonate strongly with that quote. But not with the title.

I don’t think it’s a matter of not knowing SQL. Wozniak may very well think it is, but note that he wrote his software without the Internet, without Google, and, crucially, without Stack Overflow.

He wrote database queries at a time when if you wanted to do it well you needed to learn SQL.

That’s not the case anymore. Not that you would be better off if you knew SQL well (and I’ve already recommended you to pick up a database book in a previous article), but there’s enough out there to write SQL well without having to understand the language as deeply as Wozniak does.

So it’s not a lack of knowledge that people keep using ORMs against their own judgement; people already “just know” SQL.

The problem is something else.

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, I’m going to argue that ORMs are a good thing, as long as you build them yourself. That, and not SQL syntax, is the knowledge you’re missing.

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

• Why your own ORM trumps everything out there

• What an ORM does (it’s simple, but not easy)

• How to start building one (step by step)

Enough intro, let’s dive in.

Read more

A couple of days ago, in one of those meetings that are going nowhere, someone casually coined one of the most wonderful terms I’ve ever heard: the root-root cause.

Not root cause, no. Double-root. The root of the root cause.

It was a moment as memorable to me as it was to all those journalists who were in the room when US Secretary of Defense Donald Rumsfeld first talk about unknown unknowns.

It was corporatespeak in the making.

I’m half joking. The term “root-root cause” is superficially absurd: if there is a root to a root cause, then it wasn’t a root cause to begin with. But on the other hand, I’ve witnessed problems caused by an underlying bug that was caused by something even deeper. Problems whose actual cause wasn’t slopiness, carelessness or a misunderstanding of the mechanicals of the problem, even if they were looked like, and addressed as, such.

Problems that were caused by something more fundamental. A root-root cause.

Bugs in ledgers, like in any other software system, are usually treated as engineering problems. When ledgers fail, they do so because they’re slow or because the calculations are off. And when engineers inspect them, they search for performance bottlenecks, off-by-one errors, or the use of floats to represent money.

That’s one way to look at ledgers’ problems. But it’s incomplete. When you look at ledgers as if they were simply technical problems to solve, you’re overlooking the fact that they’re a critical piece of business technology for fintechs. Which means that there are multiple areas of the company using the ledger in fundamentally different ways.

“Fixing” a bug may involve a tradeoff that benefits one of those areas at the expense of the others. And, in time, the other areas will notice how their way of interacting with the ledger has gotten worse, and will demand it “goes back to how it was behaving before.”

Spice this up with two different engineers looking at this problem at different points in time, and you’re going back and forth between doing and undoing the “fix”, never going anywhere.

Because none of them are really seeing the root-root cause.

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 looking at the 3 products subsumed in a ledger system, their conflicting requirements, and some of the “scalability” or “performance” issues that arise from it. It’s one of those topics that makes it clear that being an engineer takes a special kind of courage, the courage to admit that you don’t know everything, and the courage to tell others that they don’t either.

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

• The 3 root-root causes of all of ledger’s problems

• What you will be forced to do if you ignore this for too long

Enough intro, let’s dive in.

Read more

In his crusade to destroy the Entity, a sentient AI, he’s got to jump into a moving train and rescue one of his teammates. This time, however, as he gets closer and closer to the train on his motorbike, he arrives at the edge of a cliff, and is told to use his parachute, and jump.

So, he jumps.

If you’ve watched the behind the scenes, you know that this scene is actually more scary than it looks. It is arguably one of the best stunts in cinema history: a motorbike jump off a cliff into a base jump. The cliff is real, the motorbike and the parachutes are real and, of course, the stuntman is Tom Cruise himself.

He said he wanted to do it since he was a little kid.

There is something gripping about the Mission Impossible franchise or the Jason Bourne saga that other action movies like Fast & Furious or Mad Max can’t simply replicate.

Yes, there’s impossibly high stakes, cars racing and explosions in all of them. But you can measure the emotional difference of leaving the theater after watching Tom Cruise jump of a cliff, or climb the Burj Khalifa, and after watching Vin Diesel “drive” a sportscar from one of the Etihad Towers to the other.

The difference, of course, is that you can believe the former, but not the latter.

I don’t want to argue that there’s one type of action movies that are “better” than others. Leave that to Rotten Tomatoes. What I want to persuade you is that there is a kind of action movie that’s impossible to replicate by others, no matter how much money, technology or people you put into it, and that this difference is precisely what make these movies unique and immediately recognizable by the broader public, while the others blur into a cloud of sameness (“was this movie before, or after Paul Walker’s accident?”).

Having spent huge amounts of money on a movie, the outcome is vastly different when the work involves some member of the staff saying “Vin, look focused and angry behind the wheel, we’ll do the rest”, or Tom Cruise laying out his plan to the safety guy, getting some push back from him, then getting a new safety guy.

The difference boils down to the creator’s vision.

Weirdly enough, software engineering has been drifting away in a similar cloud of sameness for a long time. Since the 2010s, virtually all software engineers work under the umbrella of Agile and Lean methodologies, and nowadays the only effective difference between the large enterprise and the small startup is that the former has more ceremony, and the latter has less people.

This, however, is ripe for change, now that there’s a machine that can write code for us.

The invention of LLMs and coding agents has, for the first time in history, unlocked the possibility of one-person teams. Just as cloud computing allowed companies to avoid buying servers upfront, LLMs allow them to avoid hiring large engineering teams upfront, keeping headcount small, reducing coordination overhead, and minimizing the need for middle management.

However, much like the first news program on television were just someone repeating on camera what they had just broadcasted on radio, early adopters of LLM have focused on replicate the human scaffolding of enterprise software organizations into their own workflows. These “AI-native” companies “hire” agents and give them tasks to do, and use “loops” as the artificial equivalent of middle manager, whipping and “harnessing” the agent until the task is done.

It is tempting to put distance between you and the code that makes your product. Coding is, after all, mentally demanding, and we know from the work by Kahneman and Tversky that humans are repelled by mentally demanding work.

The promise of a machine that can do the low level thinking for us is too good to pass on.

Still, you must still write most of the code yourself. Not because LLMs don’t deliver; they may very well do. But because the writing of the code is the highest level of thinking you can make.

What you have to do isn’t to let the LLM run amok, and build the tooling around it to prevent bad things from happening. What you have to do is, for the first time in software history, be in total control of a software system no unaided human can build on their own.

Tom Cruise has a saying that deeply resonates with this:

Don’t be careful, be competent.

I’m Alvaro Duran, and this is The Payments Engineer Playbook. This is the only newsletter on Earth tailor made for the engineers who build money software. And in these engineers’ minds, the most important question right now has to do with this brand new machine that promises to take most code-related jobs, and leave the rest unrecognizable.

My gut tells me that this is just marketing. If your company decides to fire you on the grounds that AI can replace you, they’re either wrong, or commanding a ship that will be automated away by somebody else. Which means that, in the end, you were better off leaving the company anyway.

Building software will always be an activity that requires humans, just like ChatGPT has eliminated the stock photograph industry, but not photographers. The reason isn’t that there’s something called “taste” that can’t be replicated by machines (most people have Big Mac levels of taste about many things), but because using LLMs to replicate enterprise software organizations won’t give you enterprise levels of success.

Let me tell you why, and what you should do instead.

From Zero To One

“What is morality?” she asked.

“Judgement to distinguish right and wrong, vision to see the truth, courage to act upon it, dedication to that which is good, integrity to stand by the good at any price. But where does one find it?”

The young boy made a sound that was half-chuckle, half-sneer: “Who is John Galt?”

— Ayn Rand, Atlas Shrugged

Peter Thiel’s book Zero To One: Notes on Startups, or How to Build the Future made a profound influence on me when I read it, about ten years ago.

On a superficial reading, Thiel’s claim simply echoes Christensen’s concept of disruption from The Innovators Dilemma. Thiel’s point, however, is much deeper than that: Zero to One is a book about the practical aspects of building a company meant to disrupt an industry, from the kind of ideas that are “disruption material”, the kind of founder, the kind of funding, the kind of business model, the kind of team.

Thiel’s argument is that only the startups that are weird and absurd to the general public can succeed. That heresy is the point.

This article is the application of such thinking to LLMs: the AI-native companies that will succeed will have their engineers writing the code by hand.

That’s because the real obstacle between a company and the ability to create value has never been speed to market, or productivity. In software, the biggest obstacle is, and always will be, the gap between what the customer needs, and is willing to pay for, and the implementation of a product that satisfies that need.

Speed has always been a catalyst. A company gathers feedback from a potential customer, and the race is to nailing down a product that satisfies it. Because of the dynamics of disruption, enterprise companies won’t even address that need: these are not the customers they’re looking for. That’s what give startups a chance to succeed (and why only heretical companies can eschew competition from incumbents).

So the race isn’t against enterprises, but against other startups. But the thing is that it isn’t really a race on a defined track, but a treasure hunt in the dark. That’s why Medium, with a 5 year head start and millions of dollars in the bank was brought to its knees by Substack: Medium was trying to become another New York Times; Substack wasn’t.

Agile may finally be dead, after all

“The F-18 Natops. Contains everything they want you to know about your aircraft. I’m assuming you know the book inside and out.”

“Damn right!”

“So does your enemy.”

— Top Gun: Maverick

What’s changed is that, now that there’s an LLM out there, and that everyone has it, undifferentiated software won’t cut it anymore.

The software products that will win have a point of view. A vision, coherent from the top down. A single, unified mental model of what the customer needs, and how and why the product address that need.

Let us call that conceptual integrity.

Conceptual integrity, a contribution from Brooks’ Mythical Man Month, makes the product easier to develop and easier to use. This integrity pervades every decision in software, down to the line of code. And you haven’t heard of conceptual integrity because it has been remarkably absent from Agile discourse.

In other words, Agile is all about collaboration. Which sounds like a good thing, but it really isn’t. What you want instead is having as little collaboration as you can get by.

The only reason you need to collaborate is because you can only build so much of the product in a given time, up to some standards, and maintain those standards.

But now that there’s a tool that can help you build and understand the code you write, the threshold of collaboration you need has gone down, sharply. To the point where Agile may be actively harmful to the interests of a company.

Maybe you shouldn’t be token-maxxing, but sense-making-maxxing.

The Real Villain is Convenience

Fidelity to a coherent vision about a software product, all in the head of one person, may now be possible.

What stands in your way is your own unwilligness to get down into the trenches and understand the code, line by line, aided by some new piece of technology that could make that understanding faster. Not to engage in the kind of apathy and disengagement that comes from the fact that someone told you that there’s a thing that can do it for you.

That’s the mission, should you choose to accept it.

I’ve always seen every piece of technology as a Faustian bargain, some smaller and some bigger. We use our GPS to orient ourselves, and have given up on having a sense of our surroundings or engaging with strangers (something that used to give some quirky flavors to our holidays and make for good anecdotes later). We use search engines to ask questions, failing to curate our own sources of information, failing prey to lies and deceit.

Technology is what can, and will, be enshittified.

Another approach to build software

I encourage you to keep writing code with your own hands, to keep reading the docs yourself, and to spend your time focused on the minutia of functions, methods and classes.

You’ll quickly notice, as I have, the following.

First, you’ll reengage with your job in a way that you didn’t noticed you were missing. You weren’t that productive to begin with, because the off times between writing the prompt and looking at the outcome were spent on your phone, on Slack, or drinking coffee. There’s nothing as joyful as being engaged on a single, well defined task of moderate difficulty, making progress, and seeing it to completion. What’s now well known as flow.

Second, you’ll noticed over time that you’re more knowledgeable than your peers in some area of the product in a way that’s richer and more nuanced. Obviously, it is a consequence of the fact that they’re letting AI write the code for them, and you don’t. It could be a remark you hear yourself saying on a meeting, an edge case they’ve overlooked, or a solution to a problem they didn’t consider because of some seemingly disconnected parts of the system. You’ve earned it: it’s your time to shine.

And third, you’ll realize that you’re actually in a better position to prompt the machine for suggestions. You’re behind the wheel, ready to reengage with the LLM for brainstorming, rubber duck debugging, and review, but not delegation.

This, in time, is how software engineers will work. There’s simply no way around it. The rest will burn out from the inhumane task of prompting prompts to prompt prompts all day long.

Is the software engineer industry going to change? No doubt about it. But it isn’t going to look like Fast & Furious, with ever more technology creating ever more unimaginative slop.

It’s going to look more like single humans, on a motorbike, with a parachute on their back.

Ready to jump and see what happens.

This was it for this week in The Payments Engineer Playbook. I’ll see you next week.

The state machine you built is almost certainly incomplete.

I can see the whiteboard in your office, or the Miro board you had prepared, full of details and notes. I can visualize the transitions, the edge cases. But I can also see what went wrong, in a very subtle way.

Let me tell you what I see.

Let’s say we want to implement a service that handles the process of placing an order. This order goes through multiple stages during its lifetime. Initially it is pending, then goes to confirmed and paid. Finally it ends up as either completed or canceled.

— Ürgo Ringo, Implementing entity states as separate classes

State machines are unexpectedly one of the most difficult components of the domain logic in any domain system. They’re meant to represent the lifecycle of a given entity under all possible interactions with users, and they almost always seem to be missing something crucial, and impossibly hard to introduce retrospectively.

Which is why I’ve been very vocal against them in the past.

That said, Ürgo Ringo’s article on implementing state machines, not as enums, but as separate classes, has made a profound influence in how I build software systems.

And that’s because I resonate with the idea that the compiler can help you become aware of gaps in the way you represent an entity’s lifecycle before you go live with the changes.

This, alongside Alexis King’s Parse, Don’t Validate, made me realize that in order to build a more robust approach to how state machines are implemented in the wild (full of switch statements and guard clauses), I had to treat entities as completely different types as they evolve.

If you do this, you’ll quickly realize something: identifiers are optional, in a very weird way.

Let’s say, just like in Ürgo Ringo’s article, that we’re implementing a system to place orders, Amazon style. An order may have creation time, items, nothing out of the ordinary. And it has an order_id.

Is that id optional?

On the one hand, no, not really. Orders must be uniquely identified in the system, and you’d benefit greatly from not having to check if the damned id is null or not every time you check its value, or cache it, or use it in any other way. It wouldn’t make sense to separate orders into different classes to avoid if statements, only to reintroduce them in the silliest way possible.

On the other hand, you may need to pass an order instance in order to create the record in the database, but until you do, there’s no order_id you can assign to that entity.

So you probably bit the bullet and made order_id optional.

That was a mistake.

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 down into the weeds and ask how can I make an entity’s identifier non-optional, without losing the ability to pass that entity to the database?

This time, and by popular demand, I’m going to show you some code. It’s Go, but the takeaways should be seamlessly portable to any language, even Java.

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

• How to use interfaces and DTOs instead of inheritance

• Type assertions as a way to add information to the compiler

• A practical example on how to use interfaces to solve a state-machine-like transition without state machines

Enough intro, let’s dive in.

Read more

Imagine if paper had just been discovered.

A new storage medium, local-first, with unlimited battery life, more schemaless than any database out there. Multi-model: you can store text as well as drawings and pictures. Lossless serialization and O(1) read latency to the nearest page (O(log n) otherwise).

A killer app in every aspect.

We call the systems that keep track of a company’s finances ledgers, paying homage to the notebook that was open in some corner of the office table during the workday1. 16th-century Venetian merchants ran multiple books, each updated independently throughout the day by different clerks (concurrently, and without locks), and reconciled them at the end of the day.

They had already invented CRDT centuries before it was formally defined in 2011.

But now that we have computers, most of this work is done for us, and we’ve lost a few things in the translation.

It’s a bit disheartening. Because the irony of treating paper as a new technology is that we already had it for a long time. And now that we’ve “migrated” everything to the computer, we’ve left behind unique traits about it that are far superior than what computers have to replace it.

Case in point: everything is now archived in folders or stored in containers.

Both are clearly metaphors of what people used to do with paper, but these weren’t the only things we do with paper.

I’m a very analog person, and I have paper spread out all over my desk, and none of it is archived or stored. Many engineers, if they saw that, would be prone to organizing, categorizing, and compiling all this paper.

They can’t see paper for what it is; they only see computerized reality. And that’s how we lost something that 16th-century clerks had: task management across transactions.

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, I’m going to make the case that many ledger systems are missing a piece of the puzzle that would make them ten times more useful. Not surprisingly, I’ve called this missing piece the Folio entity: a piece of data that relates multiple transactions across time, aiding reconciliation efforts, facilitating changes in revenue recognition frameworks, and making ledgers entries way easier to understand beyond their metadata.

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

• The limits of Transactions as the highest abstraction for ledgers

• The case for the Folio entity

• Why Folios aren’t containers of Transactions

• The soundness of older, paper-based architectures for ledgers

Enough intro, let’s dive in.

Read more

The AI futurists are approaching agentic commerce totally backwards.

They believe that the Internet is going to go full dead (as in “99 percent of traffic will be non-human”), and plan for a world in which commerce is done by machines to machines, with no human involvement at all.

And that, if you think about it, is nonsense.

Even if the Internet becomes something you no longer surf, navigate or information-superhighway-drive, there’s something irreducibly human in every purchase that cannot, by design, be automated away: intent.

However impulsive your shopping is, purchasing decisions start with the intent of the human.

That’s why an end-to-end agentic commerce doesn’t make any sense at all.

If AI gets adopted more widely, and we rely less on click and tap and more on vibes and prompts, it’s not the increased traffic or the bad quality code that’s going to be a problem.

It’s that fraud will be indistinguishable from legit.

For that reason, agentic commerce, in order to succeed, will have to rely on the only thing that has to be human.

The intent to buy.

I’m Alvaro Duran, and this is The Payments Engineer Playbook. In this chapter, I want to persuade you that most authentication measures that are now commonplace, such as 3DS, are incompatible with a world in which agentic commerce is the norm.

And I want to present you with an alternative that can work, even when fraudsters use frontier models and you’re stuck with an open source model you downloaded from Hugging Face.

An alternative inspired by 16th century pirates like Francis Drake.

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

• A metaphor from the days of piracy that reinforces a new approach to AI-mediated commerce

• How to use Intent, not Presence, as the core of the authentication process

Enough intro, let’s dive in.

Read more

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.

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 think1, 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.

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.

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 zeros2 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.

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.

Most ledgers approach accounting with foreign currencies wrong.

Every accounting software I know is designed to have, as one of its most fundamental configurations, a currency of reference. The one in which all the ledger’s debits and credits are denominated.

It is a convention so prevalent that we no longer see it. Ledgers may be split into USD subledgers, EUR subledgers, and so on. But that’s because the assumption is that movements across subledgers, across currencies, are rare.

That assumption is becoming less and less correct every day.

I don’t blame you if you don’t agree with me on this. Your day to day is denominated in a single currency. There’s only one currency you think about when you buy groceries, pay your taxes and receive your salary. Only the occasional trip abroad may require thinking of some exchange rate, and even then you use one that’s both fixed and easy to use for mental math.

The US dollar isn’t really worth 0.8 euros, but if you’re buying a souvenir in a flea market, that rate will work just fine.

That, however, is no longer a way in which fintech companies can operate. They aim to be global, and to manage transactions at high volume and high speed. Focusing on a single economic zone with a single currency means missing out on so much of their Total Addressable Market; venture capital would abandon you.

But treating the world as if it were denominated in a single currency is not just an oversimplification, but actively harmful. And yet, most ledgers are designed to do just that, because engineers aren’t used to, or refuse to, think in terms of multiple currencies.

They may say that it’s unnecessarily complex. But the truth is that they just don’t want to do it.

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, I’m going to persuade you not to have “base amount” and “base currency” in your ledger’s entries.

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

• Why multi-currency ledgers are more relevant than ever

• Why GAAP and IFRS don’t really require a currency of reference

• And what the Green Lumber fallacy has to do with any of this

Enough intro, let’s dive in.

Read more

Every ledger that uses source-destination pairs as a primitive ends up creating accounts that have no use other than making everything work.

Source-destination pairs are a Python dataclass, or a Java class, or a Go struct, that contains two mandatory fields that represent Accounts; one for the source of funds, another for the destination.

Engineers are tempted to use S-D pairs because there’s a rigidity in it that can be easily transferred to the type system. “If I can make this work”, they think, “I’ll be able to enforce double-entry safety in the compiler, rather than having to write lots of tests and be paranoid about it”.

Consider Nubank. There’s an interesting talk by Lucas Cavalcanti, now a Distinguished Engineer at Nubank, in which he claimed that double-entry accounting is “the perfect fit for functional programming”, and described how they build their ledger on top of an Entry schema that contains “a positive amount, a debit, and a credit”, and that “modeling it this way, by design, the sum of credits is equal to the sum of debits.”

Which is factually not true.

Why? Because, when I built a ledger for the first time, we used S-D pairs just like Nubank. And we used append-only, immutable records. And our Tech Lead couldn’t stop talking about Haskell and how what we were doing was as close to functional programming as you could get in Ruby.

And yet, we were losing track of a few cents on every transaction.

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 the fallacy of trying to enforce double-entry safety on the type system. I’ve already covered why thinking of accounting in terms of flows is a bad idea, and not using S-D pairs is its natural consequence. Enforcing a beginning and an end of funds is a misrepresentation of what accounting is really about, and ledgers that use S-D pairs as their primitive end up having to do all sort of workarounds to make the tests pass.

You used S-D pairs to get the compiler’s help, and then you make its help pointless.

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

• The imaginary accounts needed to make S-D pairs work

• Which ledgers could work with S-D pairs (not many)

• The financial operations that S-D simply cannot model

Enough intro, let’s dive in.

Read more

You can go too far and design a ledger that’s too rigid.

When you engineer software, there’s a tendency to push the most basic rules of your code as close to the storage layer as possible. The reasoning is that things that must always be true don’t change, and must be the foundation of the rest of the system. Or so the argument goes.

This is a good heuristic. But if that thing you call invariant needs to be modified, or you need to change the database engine as a result of scale, closeness to storage will make the migration more difficult and expensive.

Database invariants either age well, or get rewritten.

It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.

— Not Mark Twain

In ledgers, the most foundational of business rules is double-entry safety. And so, many ledger systems have placed its logic as close to the database as possible.

TigerBeetle takes this argument to its purest expression. Its primitives are not tables. They are Account and Transfer. A transfer “debit a single account and credit a single account.” There is no INSERT INTO transfers that can produce an unbalanced row, because the API does not expose a shape in which an unbalanced posting is a valid input.

Which sounds like a good thing, and it is, unless the world suddenly becomes multi-currency. TigerBeetle is built for speed, but makes multi-currency scenarios unmanageable.

The thing about ledgers is that, although they’re hard to build correctly, there isn’t One Canonical Ledger Design that every ledger must conform to. Every company has nuanced finances, idiosyncratic approaches, tricky and ever changing regulation, and evolving business needs.

TigerBeetle proved that double-entry deserves a primitive. But it didn’t prove that the primitive has to live in the database.

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, I’m going to make the case for placing all the ledger’s logic, even its most foundational, in the application layer, and away from the database. When you do that, you’re one bug away from corrupting the books without the database to help you. But the reality is that ledger bugs can’t be prevented by database schemas unless you make these schemas so rigid that you lose the ability to adapt to the needs of the company.

In other words: database safety is an illusion.

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

• Seeing the tech stack as a business bet

• Persistence ignorance as a mitigation mechanism for scale

• The only valid way to ensure double-entry safety

Enough intro, let’s dive in.

Read more

What do you do when you’re tasked with building a ledger? You sign up for an accounting course online.

That makes all the sense in paper: ledgers are financial systems, governed by accounting rules. Go learn your debits and credits, depreciations and equities, balance sheets and P&L statements, and you’ll be ready to build.

Except that none of that will help you.

The reason is that accounting, as it’s usually taught, is universally aimed at accountants and financial analysts. And that means, to put it very simply, that accounting courses are taught so that you learn how to prepare financial statements. Yes, there’s way more to it, but the central point is either to learn to write them (for accountants that do their clients’ taxes) or to read them (for analysts that track the value of companies).

And that’s not the accounting you need to build a ledger.

Every ledger system out there is built to support one of 5 use cases:

• Wallets

• Marketplaces

• Loyalty programs

• Lending

• Insurance

The thing is, I own a copy of Accounting Information Systems, by Romney, Steinbart, Summers and Wood (16th edition!). It’s the book I bought when I realized that I had to fix a single-entry ledger that was losing track of users’ money

And although it’s the book ChatGPT would recommend you if you want to build financial systems, none of these use cases are covered in that book.

All case studies and lessons in that book are for accounting systems that need to keep their own organization’s finances, not for technology companies offering, or using, financial services for themselves or their users.

Sure, if you’re working at a company selling appliances and consumer electronics, the AIS book is what you need.

But if you move your users’ money around, you’ve bought the wrong book.

I’m Alvaro Duran, and this is The Payments Engineer Playbook. In today’s article, we’re going to cover, one by one, all the actual ledger use cases, and the accounting needed to handle them correctly:

• How they work

• The operations needed

• A quick real-world company that operates under that use case

Enough intro, let’s dive in.

Read more

“The nature of promises, Linda”, Frank Underwood said in the pilot of House of Cards, “is that they remain immune to changing circumstances.”

He was talking about the president-elect’s promise to nominate him as Secretary of State, but we may feel the same outrage and betrayal about “open source” databases: Redis being BSD-licensed until 2025; Elasticsearch being Apache 2.0 until 2021; and MongoDB being AGPL until 2018.

Frank was wrong, of course.

Promises are not immune to changing circumstances. Open source databases have to face the pressure of two, in particular:

• Having a cloud provider like AWS productizing your database and eating your main source of funding (also known as getting Jeff’d)

• Having the VCs you’ve raised funds from pressuring you into capturing the market instead of serving the community built around your database.

Unlike choosing a logging library or a linter, the database is the foundation of financial systems because most money software’s value is derived from its data. Once a database is chosen and deployed in production, it becomes incredibly difficult and expensive to migrate away from.

The problem, however, is made worse by the fact that engineers are often the least reliable judges when it comes to choosing databases.

Under the veil of “best tool for the job”, many engineers argue endlessly about what the best database is based on a combination of past experience, CV-driven development, and marketing. Confronted with a database choice, they go for the familiar, the shiny, or the coolest new thing.

And that’s how you get SQLite rewritten in Rust.

Engineers are often dismissive of marketing done to others, but are helpless to the marketing done to them: open source databases most likely to appear in the Stack Overflow Developer Survey are VC-funded1.

The problem with the effectiveness of marketing is that the databases most likely to hurt you down the line are often the ones “most admired” and “most popular”. If engineers weren’t so susceptible, database choice would be more niche and less “general purpose”, and cloud providers wouldn’t be so prone to “Jeff” them. We probably wouldn’t have VC-funded databases to begin with.

But we would know which promises to trust.

I’m Alvaro Duran, and this is The Payments Engineer Playbook. There is a lot of content out there on how to choose a database for money software. Most of it, however, is marketing. The Playbook is the only newsletter on Earth tailor-made for engineers of money software, which teaches you how to design money software, not to pass interviews, but to handle real users and real money.

Every week, more than 2,000 subscribers from companies like Stripe, Coinbase and Modern Treasury get a deep dive on how to build software that moves money around.

This week, we’re going to investigate one of the most crucial questions that every CTO must face before building money software: which database should I use? And since I can’t make that choice for you, because I don’t have your full context, today’s article is less about the database engine to pick, and more about which promises to believe.

Those that are immune to changing circumstances.

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

• What is Open Source Enclosure

• The 3 categories you can choose a money database from

• And why durably governed open source is rare (hint: that’s actually the point)

Enough intro, let’s dive in.

Read more

Uber has rewritten its ledger systems five times in the last ten years. And at least one of those rewrites, if not all, could have been avoided.

That’s because the root of each generation of money software at Uber was driven from bad incentives. Each started with a brand new proposal, approved as the definitive solution; in time, a fatal flaw was surfaced; and finally, a new proposal came along to replace it.

Every rewrite was someone’s promotion project.

At least one of them could’ve been avoided: the one where Uber moved to DynamoDB. In 2017, Uber launched their new payment platform on it, and the critical factor that everyone involved seemed to miss was that DynamoDB is a consumption-priced database.

You pay for every read, and every write.

With each trip generating multiple ledger entries, and Uber as a whole processing 15 million trips per day, it didn’t matter that DynamoDB was great because of high throughput at global scale. The proverbial bean counter should’ve stopped this madness from happening.

Within 2 years, the cost became prohibitely expensive:

At Uber’s scale, DynamoDB became expensive. Hence, we started keeping only 12 weeks of data (i.e., hot data) in DynamoDB and started using Uber’s blobstore, TerraBlob, for older data (i.e., cold data). TerraBlob is similar to AWS S3. For a long-term solution, we wanted to use LSG.

— Migrating a Trillion Entries of Uber’s Ledger Data from DynamoDB to LedgerStore

A redesign that gets replaced 2 years later is a catastrophe.

And yet, history remembers Uber’s ledger on top of DynamoDB as a masterpiece. As late as 2024, ByteByteGo has an article praising it.

And that’s what concerns me. Uber’s design was a failure, but nobody seems to remember it that way.

That ends today.

I’m Alvaro Duran, and this is The Payments Engineer Playbook, the only newsletter on Earth tailor-made for engineers of money software. Every week, more than 2,000 subscribers from companies like Stripe, Coinbase and Modern Treasury get a dive deep on how to build software that moves money around. Not to pass interviews, but to do their job exceptionally well.

When money is on the line, 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 insights from it.

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

• Why DynamoDB works for payments but breaks when you use it as a ledger

• The napkin math that would have saved Uber millions of dollars

• And one shocking conclusion from all of this

Enough intro, let’s dive in.

The Consistency Trap

But first: is DynamoDB a bad choice for financial software?

Not necessarily. I’ve already covered DynamoDB as a potential data store for payment systems, and it has many features that are worth it: zero-downtime migrations, low latency for a global audience, and built-in replication and failover.

If you’re accepting payments at scale around the globe, DynamoDB is a great choice.

It is because DynamoDB, while not enforcing full linearizability across partitions, can guarantee consistency within a Region. DynamoDB gives you strong consistency on a per-partition basis, but not across partitions — and for a global-scale payments system, that’s a trade-off worth making.

PostgreSQL can; DynamoDB cannot.

This is quite a property when it comes to payments, because they are independent from each other. You can interleave the authentication of one with the capture of another. There’s no need to maintain full linearizability across your data; causal consistency is enough. DynamoDB trades off the linearizability that you don’t actually need for all those nice features I mentioned earlier, which means that for large enterprises that serve customers all over the world in high volume and frequency, DynamoDB is better than PostgreSQL.

But a ledger isn’t a payments system.

A ledger cannot simply say “hey, this account and that account can be dealt with independently”. The scope of a ledger system is The World; a data store that can’t enforce full linearizability isn’t going to cut it, no matter how good at throughput and latency it is.

In other words: DynamoDB works well in payments because payments can give up global consistency for better availability. But ledgers can’t give up global consistency, even if that means they get worse availability.

The Napkin Math (Because Someone Has To Do It At Some Point)

DynamoDB capacity pricing is based on two main models: Provisioned and On-demand. You can buy reads and writes in bulk, buy reads and writes when you need them, or both.

And then, there’s the storage and add-on features. For most, throughput is the real deal, and storage is just the cream on top of the invoice. But for data-heavy applications, such as ledgers, storage can become the dominant cost. That’s why reserving capacity is important, but it demands from you some predictive abilities, or at least making an educated guess about how much you’re going to need in advance, because you’re going to get a discount of more than 50 percent if you do it right.

If you use DynamoDB at scale, you need to do some napkin math.

In 2017, Uber was doing around 11 million trips a day. Assuming 10 entries per trip and 5 WCUs per entry1, that’s 550 million writes per day, and at $1.25 per million writes, that’s $687 per day.

$687 per day doesn’t sound like a lot. But that’s $250K a year, just in writes.

With 3x annual growth, the math is unsustainable: by year 3, we’re talking $2.25 million a year. I don’t have visibility into reads, indexes and global tables, but at Uber’s scale, the read side likely costs as much as the write side.

Which means that Uber was burning 5 million dollars in a freaking ledger.

Based on Uber’s data, by 2020 they had accumulated 1.2 petabytes of data. That, at $0.25 per gigabyte is 300K per month. And assuming the same 3x annual growth from 2017 to 2020 with a final size of 1.2 petabytes, that’s a cumulative cost of $3.5 million.

No wonder they switched to storing only the last 12 weeks of data in Dynamo, and stored the rest on premises.

Add the writes to the storage, and you’re looking at an 8 million dollar bill for a ledger that didn’t need to exist on DynamoDB in the first place.

Somebody Should Have Been Fired For This

What do you do with an 8 million dollar bill? You turn it into a case study.

Since 2020, Uber has migrated away from DynamoDB into their own internal ledger, called LSG (Ledger Store...Gateway?2), built on top of their own internal distributed database called DocStore:

Docstore is a general-purpose multi-model database that provides a strict serializability consistency model on a partition level and can scale horizontally to serve high volume workloads. Features such as Transaction, Materialized View, Associations, and Change Data Capture combined with modeling flexibility and rich query support, significantly improve developer productivity, and reduce the time to market for new applications at Uber.

— Evolving Schemaless into a Distributed SQL Database

Why not use an open-source alternative? Because Uber builds in-house. That’s what Uber does.

You could argue that DocStore provided the features they needed in a way no other alternative could. But you would be wrong!

Our homegrown Docstore was a perfect match for our database requirements, except for Change Data Capture (CDC) a.k.a., streaming functionality. [...] We decided to build a streaming framework for Docstore (project name “Flux”) and used that for LedgerStore’s Manifest generation.

— How Uber Migrated Financial Data from DynamoDB to Docstore

So let me get this straight: DynamoDB was a bad choice because it was expensive, which is something you could have figured out in advance. You then decided to move everything to an internal data store that had been built for something else3, that was available when you decided to build on top of DynamoDB. And that internal data store wasn’t good on its own, so you had to build a streaming framework to complete the migration.

And nobody got fired for this?

But nobody was optimizing for cost. They were optimizing for their next promotion. Each rewrite was a new proposal, a new design doc, a new system to put on a resume. The incentive was never to pick the boring, correct choice — it was to pick the complex, impressive one.

This isn’t Metaverse-levels of disaster, but relative to Uber’s scale, gets pretty close.

Catastrophes Disguised as Case Studies

What bothers me the most is this: by 2019, it was painfully obvious that Uber had made a terrible decision when they built LedgerStore on top of DynamoDB.

And yet, when AWS invited Uber to present at re:Invent 2019, they said yes.

I’ve written about Uber’s testing practices before, and praised them for it — the article hit the front of Hacker News.

But let’s call a spade a spade: when you actively disguise an atrocious decision as a case study for a database technology, you’re no less fraudulent than one of those hedge fund managers talking their book on TV.

It is the technological equivalent of an arsonist writing a fire safety manual.

On a second level, there’s the publications that regurgitated this case study without looking at the full picture: ByteByteGo has an article on LedgerStore praising “The cost savings from this migration” with yearly savings “exceeding $6 million due to reduced spend on DynamoDB”.

I can’t possibly comment on this.

When you’re tasked with building a system of any kind, not just ledgers, the technology is never enough. If you’re building a system that makes the economics of your company impossible, you’re better off not building it.

Focusing solely on the technical requirements, and not seeing the costs, is a disservice to the business that employs you.

Uber didn’t make a ledger mistake. It set the wrong incentives.

And it paid millions of dollars for it.

This was The Payments Engineer Playbook. I’ll see you next week.

Financial transactions aren’t database transactions.

Sure, they are the inspiration for database transactions. Turing Award-winner Jim Gray defined the standard measure of database transaction processing in terms of debits and credits. They also follow a layman’s intuition that, when money leaves an account, it immediately arrives at another.

But that’s not what usually happens.

When you make a transfer from your bank account, those funds almost always take some time to arrive. It may be a few seconds, or a business day, or a whole month (if your bank is settling payments made to you in Brazil1).

What happens during that time is treasury. Whoever is holding the funds in transit can use them as a (very) short-term collateral. It can deposit them and earn some interest, it can use them to improve their cash-flow, it can do as they please, as long as the funds arrive where they’re supposed to, when they’re supposed to.

That’s not how database transactions work at all.

Nevertheless, modeling ledger transactions as atomic units can work fine. You wrap debits and credits, make sure they’re double-entry safe, and work under the assumption that all those entries are all pending, or all posted. And if something goes wrong, you archive those entries, knowing that you don’t have to do anything else. It’s clean, safe, and predictable.

You may very well do that; Stripe doesn’t.

Stripe processes billions of events per day through a system they call Ledger. And in Ledger, they don’t assume that both sides of a money movement arrive together. After all, they don’t have to come from the same service, or in the same order. Each event is its own thing, with its own timestamp, source system, and moment of arrival; the only thing they share is an identifier.

That’s one limitation we already saw in stock markets: the risk of quickness versus completeness.

This risk is central to stock market systems. In order to scale, multiple matching engines are running in parallel, processing massive amounts of buy and sell orders with low latency. As soon as two orders are crossed (a buy order matches a sell order for a given price), there’s an execution, and that information gets disseminated quickly and fairly.

But what if something bad happens? What if regulators step in and ask “what happened here first”?

Like, two buy orders for the same price get sent at the same time by two traders, but one gets crossed and the other doesn’t, or does at a higher price.

How can you be sure that you were fair to both orders? Which one is “technically first”?

That, weirdly enough, is an ambiguous question. Because you haven’t clarified which notion of time is being used to sort the orders.

It’s not that transactions in a ledger can’t be atomic; they can. It’s that you don’t need them to.

And the real question is: what are you missing out when you force transactions to be atomic?

I’m Alvaro Duran, and this is The Payments Engineer Playbook, the only newsletter on Earth tailor-made for engineers of money software. Every week, more than 2,000 subscribers from companies like Stripe, Coinbase and Modern Treasury get a dive deep on how to build software that moves money around. Not to pass interviews, but to do their job exceptionally well.

When money is on the line, 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 insights from it.

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

• Why computer science trained us to think of transactions as atomic, and why that assumption breaks down in distributed ledgers

• How Stripe’s Ledger posts individual entries instead of atomic transactions, and gets away with it

• The trade-offs between atomic and non-atomic models, and when to pick which

Enough intro, let’s dive in.

Read more

There’s a playbook for building successful companies that contradicts everything Paul Graham ever wrote.

Most business advice, what circulates on X, on Hacker News, and on Youtube, is modeled on PG’s essays. “A startup is a company designed to grow fast” (Startup = Growth); “the main value of whatever you launch with is as a pretext for engaging users”; “put a big piece of paper on your wall and every day plot the number of users” (Startups in 13 Sentences).

But the reality is that there are companies out there designed to grow slow, to launch late, and to deliberately restrict sales, that not only survive, but thrive.

The tech industry business model feels played out. Silicon Valley is both a place and a comedy show. It has grown so much that we now have a term for the point when these platforms have gone too far: enshittification.

Here is how platforms die: first, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die. I call this enshittification, and it is a seemingly inevitable consequence arising from the combination of the ease of changing how a platform allocates value, combined with the nature of a “two-sided market”, where a platform sits between buyers and sellers, hold each hostage to the other, raking off an ever-larger share of the value that passes between them.

— Cory Doctorow, The ‘Enshittification’ of TikTok

But as far as I can tell, nobody has articulated an alternative way of building online businesses. There’s a collective aloofness in the industry about this: “sure, enshittification is bad,” they seem to say, “but it’s the only way to build a startup.”

PG’s advice is battle tested: if you ignore his essays, you’re probably going to fail. But I argue that you can do something else: not to ignore PG, but to deliberately disobey him.

Let us call that approach The Luxury Playbook.

I’m Alvaro Duran, and you know I like playbooks. This article of The Payments Engineer Playbook, however, isn’t about the technology that moves money around. Today is April Cools: a celebration of what doesn’t fit the mold, so instead, I’m discussing business strategy.

But not your usual MBA pablum.

Since most startup founders learn how to build businesses from tech adjacent media, they usually treat PG’s advice as gospel. Thus, alternative approaches are poorly understood and underutilized in tech, and for exactly that reason, can be a secret weapon for those who wield them.

This is tricky advice, though. Most investors won’t understand it either, so funding will be more difficult. This article therefore has two main goals:

• To make you understand The Luxury Playbook and apply it to your company.

• To be a reference for investors who want to fund companies using this approach.

Enough intro, let’s dive in.

Make Something People Want, and then what?

It is impossible to build a successful business if you don’t make something people want.

That’s why both luxury brands and startups are, initially, very much alike. They both reject building for “everyone”, because that’s the same as building for no one. And both are designed to amplify the intensity of their founders.

Startups call it “founder mode”. But luxury founders go as far as naming their companies after them: Ferrari, Hermès, Yves Saint Laurent, Beats by Dr. Dre.

So the startup and the luxury brand agree on the starting conditions: make something real, stay close to it, and find Product Market Fit.

What separates them is what happens next.

The startup, once PMF is achieved, treats it as a milestone. From then on, it’s all about growth, speed, and distribution. The luxury brand, however, treats PMF as a horizon. Startups leave product market fit behind; luxury brands never fully reach it.

Luxury As The Anti-Playbook

You probably don’t dream of buying a Birkin bag.

But Samantha from Sex and the City can’t simply pay $4,0001 to get it. It’s not that she can’t afford it; it’s that she has to wait 5 years.

Luxury seems to operate in a completely different universe: rising prices famously spur demand (economists call these Veblen goods), websites do not show the price of the items, and physical shops are empty most of the time, usually because there’s a bouncer at the door.

Paul Graham’s advice is widespread because it makes sense. People understand in their bones that the right product must win, that being close to the users is a good thing, and that charts going up and to the right are indications of valuable companies.

On the other hand, Ferrari cars are uncomfortable, way too expensive, and you have to wait a few years to get one.

And yet, every kid wants a red car for Christmas, and every man wants a red Ferrari when they turn 40.

Different concepts of value

Luxury brands aren’t built to maximize growth. But that doesn’t mean they don’t make sense. Growth, for startups, vindicates the product. It’s evidence that a lot of people value what they’re selling.

Luxury brands, however, maximize the desirability of the product. It is very much the way consultants sell their services, and it’s not a coincidence. Luxury products have delayed gratification built in, which justifies the price in the mind of the buyer.

Startups make something PEOPLE want; luxury brands make something people WANT.

Move fast, or never break things

A Cartier Tank watch you buy today is largely unchanged to the one introduced in 1918.

Startups iterate and move fast. Their founders understand that every iteration is both a product to sell and a quest for market data; continuous change refines it, adapts to the changing environment, and sharpens the model of its ideal customer.

Luxury sees frequent change as instability, and the product as a promise. The Rolex you’ve waited years to buy isn’t just for yourself; in time, your kid will grow up, and you’ll give it to them, as if to pass the baton.

Startups move fast; luxury brands make timeless things.

Feedback as contamination

Startups iterate quickly, because the point is to gather feedback.

Their founders have gaps in their knowledge. These gaps are hard to spot, because your brain papers over them with assumptions. It is best to find paying customers, and figure out as much as you can from them, invade their privacy if required, so that the product feels tailor made to the ideal customer.

Luxury brands could not care less about that.

Obsessive attention to users is anathema in luxury. The creative genius is the source of all product decisions, and customers have little to say about that. A luxury brand dominates their customers the way a parent dominates their kids: “this is what is best for them, even if they don’t like it at first.”

Startups build bottom-up; luxury brands build top-down

The value of friction

Stripe’s entire thesis was to accept payments “in 7 lines of code”.

Nascent companies often position themselves against a big, but well-known competitor. Inertia and status quo are their biggest barriers to growth, and friction is the conversion killer. Startups, therefore, iterate on the way users interact with their product and remove friction every step of the way.

You can’t have startups without User Experience.

Luxury, on the other hand, embraces friction. A dream is the negation of the obstacle to attain the desire, but the obstacle must be there, and it must hurt. It is precisely the fact that not many people can have what you’re buying that makes it valuable. It says something about why you’re not just like anybody else.

Startups search for a moat in their business; luxury brands build a moat in their products.

What this means for online businesses

The luxury logic can’t be confined just to handbags, watches and sports cars.

One of the reasons I’ve been obsessed with luxury recently is because I have a thesis of my own: that luxury can be applied to online businesses, and digital products.

Since in digital markets the marginal cost of selling a product is near zero, everything naturally drifts towards commoditization. Things are free to sell, so we might as well give you cat videos for free, and aggressively pay for it with ads.

But this can’t be the only way to build successful businesses online. I have a visceral reaction to pointless ads. So, I’ve been mulling over this idea of online businesses that eschew commoditization.

And that brought me to luxury.

Luxury is taste, and there isn’t anything as tasteless as advertising. Therefore, online luxury brands, if they exist, build on the ideas I’ve described:

• Maximize the desirability of the product, not the user count

• Move slowly, and expand their offering only when it adds to the overall experience

• Manufacture scarcity, even when the Internet has removed it

And you know what? I believe they exist, even if they don’t call themselves luxury. In fact, I believe that the first luxury digital product that has ever existed was the Bloomberg Terminal.

The Terminal is an informational product, accessed online, that signals that your financial company means business, and that it’s profitable enough to afford the price tag: $30,000 per user per year.

Why so expensive? Well, why not? Wall Street pays a premium for high-quality business information, delivered instantly, and that’s become even more true over time.

The Terminal is complex, intentionally dense, not optimized for casual users. And yet, sales from the Terminal account for more than 85 percent of the company’s revenue. The product itself is largely unchanged since its inception in 1982. Sure, “if it ain’t broke, don’t fix it.” But that sounds a lot like a Cartier watch.

Bloomberg made financial data feel like a professional credential. A founder following Paul Graham’s advice would have never invented the Bloomberg Terminal.

Superhuman is a more recent and interesting case. It launched with a wait-list, onboarding gatekeeping, and a high price for an email client.

That scarcity worked as a growth mechanism in the early days; everyone wanted in, precisely because not everyone could get in.

And yes, eventually Superhuman abandoned scarcity in order to keep growing. But that doesn’t invalidate the luxury approach. Superhuman simply abandoned it.

What does a digital product that remains faithful to The Luxury Playbook look like?

Beyond Y Combinator

Graham’s advice is not wrong. Making something people want is a valid way of building startups.

But I’m just tired of it. I’m tired of the same kind of CEO, selling their product onstage, sporting a black turtleneck in my memory, even when they actually dressed in something else.

I’m tired of a business model that puts the online user at odds with the company in order to build a business moat. Of treating users as the product, then customers as the product, then even the shareholders as the product.

The Startup Playbook feels played out at this point.

It’s time for companies to test if The Luxury Playbook makes sense for them. It’s not that the odds are in their favor anyway. So they might as well try something different.

In a big company, you can do what all the other big companies are doing. But a startup can't do what all the other startups do. I don't think a lot of people realize this, even in startups.

— Paul Graham, Beating the Averages

The choice between the two playbooks is a choice about the kind of value you want to create in the world. The Luxury Playbook is the natural consequence of people taking taste more seriously.

Go make your taste a differentiator.

This is it for this week in The Payments Engineer Playbook. I’ll see you next week.

PS: You’ve come this far, I have some secret to share with you.

I’ve written this article with a not-so-secret question in mind: how can I turn my newsletter into a luxury brand?

And after writing it, I’m convinced that newsletters are the perfect playground for building luxury brands online. This, as I said, is somewhat uncharted territory, and that’s why the most well-known publications out there are funded with ads, not with paid subscribers.

In this new model, newsletter articles are more like bottles in a wine cellar. That’s why they’re paywalled: because subscribers are the newsletter’s patrons.

I’m deliberately turning The Payments Engineer Playbook into something much more exclusive and much more valuable for a smaller set of highly interested individuals. The Playbook is the only newsletter on Earth tailor-made for engineers who build money software, and I want to speak to those who want to do their job exceptionally well.

For that reason, I’m putting together a Flagship Membership.

It’s going to be expensive, and it’s going to demand work from you. But it’s going to be worth your money and your time.

If you’re interested, please write down your name and your email in this form, and I’ll be in touch.

I’ll see you around.

Data warehouses are poor implementations of ledgers.

You may think that, since all a ledger does sometimes is store money data, you can do away with all the complexity that ledgers require (namely, append-only tables) and use a data warehouse to store all your company’s financial data.

This is a mistake. The purpose of a ledger isn’t simply to store financial data.

A ledger that only stores data is doomed to fail because, in finance, the history is as important as the end state. When auditors and financial analysts look at a company’s finance, they want to make sure that the numbers don’t simply look good, but also tell a good story.

A bad history with a good look has a name: fraud.

The purpose of a ledger isn’t to store money data, but to store its history. We call that integrity: the ability to see what the ledger looked like, and query its accounts’ balances, now and at any point in the past.

Actually, accountants often get this backwards: it is integrity that leads to double-entry, not the other way around.

Ledgers, first, have integrity, and then they enforce double-entry.

This is The Payments Engineer Playbook, the only newsletter on Earth tailor-made for engineers of money software. Every week, more than 2,000 subscribers from companies like Stripe, Coinbase and Modern Treasury get a dive deep on how to build software that moves money around. Not to pass interviews, but to do their job exceptionally well.

When money is on the line, 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 insights from it.

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

• Why immutability is a tool to verify integrity

• Why double entry is its natural consequence

• How to achieve consistent historic reads even when you apply compensating entries

Enough intro, let’s dive in.

Read more

You don’t know what a ledger is for.

You think you do, but you don’t. You’re aware that ledgers “keep accountants happy” and that “keep track of money across the business.” But your company has been doing just fine without one, so it’s not entirely clear why all of a sudden it would need one.

If you don’t know what a ledger is for, then having one is pointless.

Not knowing what a ledger is for has disastrous consequences, whether you’re a manager or an executive. Managers who don’t know what ledgers are for can’t get their projects approved; executives who don’t know what ledgers are for build ineffective ones.

Vague awareness of what a ledger is for isn’t enough. Only when you know precisely how a ledger fits within the context of your business, the project gets approved, the engineers understand the goal, and the resulting system is very effective, unlocking new avenues of growth and better financial planning and analysis.

But you don’t know what a ledger is for.

Let’s change that.

This is The Payments Engineer Playbook, the only newsletter on Earth tailor-made for engineers of money software. Every week, more than 2,000 subscribers from companies like Stripe, Coinbase and Modern Treasury get a dive deep on how to build software that moves money around. Not to pass interviews, but to do their job exceptionally well.

When money is on the line, 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 insights from it.

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

• Why ledgers suddenly go from pointless to top priority at many startups

• The Accounting-Engineering tension at the core of every ledger

• Why all ledgers have to fulfill at least one of 4 use cases

• How to know if your company needs one

Enough intro, let’s dive in.

Money is a Skill

Money requires judgement, accuracy, and ownership.

Knowing how much you have in the bank is good, but not enough. The skill of money means acquiring the capacity to understand how money was used in the past, what insights to gather from that usage now, and how to make the most of what you have in the future.

In other words: the skill of money is about cash flow, budgeting and ROI. And these subskills are built incrementally.

In the beginning, startups don’t require ledgers at all, because the only metric that matters is “the runway”. Just as airplanes need a runway of a minimum length to take off, startups must have enough cash to reach Product-Market Fit. The only money skill that matters at this stage is “how much time can I buy with the expenses I have right now?”.

The 70 percent of startups that don’t get to achieve PMF don’t get to build a ledger either.

The startups that live to tell the tale face a more sophisticated money problem: how to make the most with what they have. Past survival, every post-PMF startup’s CEO has to allocate their money in such a way that the company achieves explosive growth. Sales are no longer founder led, employees cannot simply “do things that don’t scale”, and engineers have to titrate up the software used to satisfy customers’ needs.

Given the opportunities opened by product-market fit, the money skill that matters is “how much money do I allocate on each opportunity to achieve the most growth?”.

This is the part where, all of a sudden, knowing where the money goes, and what for, becomes necessary. And, depending on the complexity of the money flows, whether having everything on a spreadsheet will cut it, or whether a fully-fledged system is required.

What ends up happening is often a mix of the two: money inflows are tracked in a PSP dashboard, and the codebase preserves some data regarding transactions on their database, with some basic reporting built on top. This is good: the last thing you want is to waste everybody’s time getting strict with your finances at the expense of the startup’s actual goals.

However, there’s a point when startups can no longer ignore their finances anymore, because profit starts to become as important as revenue. Past a threshold, and every startup has it, ROI suddenly creeps into every conversation with investors.

Growth isn’t the only thing that matters. And, by then, if you don’t have a ledger in place, you’ll be falling behind.

The Accounting - Engineer Tension

At scale, there’s a tension between correctness and edge cases.

When a company starts handling a large volume of transactions, across multiple accounts, currencies, or business units, tracking balances manually with a spreadsheet becomes inefficient, error prone and opaque. At that point, a ledger system provides a structured, auditable way to record everything money-wise, ensuring accuracy, clarity and compliance.

Some companies never reach this stage though. That’s why most of us don’t need a ledger to manage our finances: there’s X amount in the bank, we know the outstanding credit card debt, and your precise portfolio balance doesn’t really matter in your daily life. In simpler businesses with few accounts and minimal volume, building a ledger is unwarranted.

If a spreadsheet is enough, use a spreadsheet. Ledger adoption is a matter of timing and scale.

Spreadsheets work because they’re simple, and simplicity is a great tool for correctness. Having your finances right in front of you is the best way to spot errors and missteps. It is not the lack of features what makes a spreadsheet inferior to a ledger system. Rather, it is the complexity and the scale of the business that makes a simple, but human dependent tool, unwieldy.

This is the tension between the Accounting and Engineering systems within the ledger: accounting is focused on correctness and precision; engineering is focused on scale and throughput. A ledger system provides (and demands) both. If manual work at low scale is sufficient, choose the spreadsheet.

This tension is also the biggest reason why ledgers don’t get adopted until late: its necessity is felt by accountants, not engineers.

When to ditch the spreadsheet and build a ledger

Here’s a good framework for deciding whether to build a ledger for your company:

1. Transaction Volume: Your company is approaching 1,000 transactions per month

2. Audit Readiness: Your company takes around 40 hours of man-work to close the book for the quarter.

3. Error rates: Your company consistently has at least 1 percent discrepancy rate (as in “1 in 100 transactions aren’t correct down to the cent).

4. Reconciliation Effort: Your company’s finance team spends 20 percent of their day in reconciliation.

5. Forecasted Growth: Your company’s transaction volume is projected to grow more than 50 percent in the next year.

These indicators are different manifestations of the same need, and often reinforce each other. They’re symptoms of scale, and signal that your company will soon need a more rigorous approach to its finances.

A ledger isn’t an accounting tool

Ledgers aren’t compliance checkboxes.

A ledger is a system that builds the skill of money in your company. In the beginning, it may look like a ledger answers the question “where did money go?”.

But the trick is that, when built correctly, a ledger ends up answering “where should money go next?”.

Startups that treat money as a skill build ledgers slightly before they need them. Their executives are aware of the usefulness of spreadsheets, but can look into the future and see the necessity for budgeting and ROI conversations.

In other words: they see beyond revenue growth, and the inevitable refocus to profit.

This is it for this week in The Payments Engineer Playbook. I’ll see you next week.

I’m not a visual learner.

When I onboard into a new team, and I go through all the available documentation, the hardest part for me is understanding the system diagrams. These invariably consist of many boxes representing entities, or even individual services, linked to each other by interactions (HTTP or SSE requests, Kafka queues, you name it) represented by arrows. They always leave me more confused than before.

I’m not a visual learner. But the thing is: neither are you.

The biggest clue I have as to why is the fact that nobody seems to be bothered when I ask further clarifications about the diagram. Elaboration is expected. Despite the thoroughness of the engineer who spent all that time putting those diagrams together, it is never enough: a meeting to make those diagrams resonate is assumed to be needed.

Diagrams never seem to be enough. At best, they make meetings shorter. At worst, they waste everybody’s time.

The Cognitive Style of the Miro board

Arrows and boxes aren’t completely useless, though.

They’re very effective for conveying flow, which is why they get used all the time by people already onboarded. Diagrams are good reminders for how components interact, aiding in high level system design. You’re able to see all at once.

But the more sophisticated, multivariate, and formal your task is, the more damaging the arrows and boxes become.

That description fits accounting like a glove: although cash is intuitive and simple, it is only a fraction of what a ledger has to keep track of. Accounting is the process of tracking ownership, not money, over time. And ownership isn’t concrete enough to be stored in boxes, and moved with arrows.

Arrows and boxes serve engineers when they map code flows. No argument there. But their visual emphasis is misleading when it comes to accounting.

This week, we’re looking at the limitations of arrows and boxes to explain accounting to engineers. I should know: a significant part of my job consists of clarifying accounting to engineers, from the very junior to the CTO. And, being an engineer myself, I initially used arrows and boxes to try to convey how to represent common use cases in accounting terms.

No longer. When you step into accounting, arrows and boxes are glorified squiggles.

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 do your job exceptionally well. 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 insights from it.

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

• The shift from “moving money” to “transferring ownership”

• Why using arrows to represent balance changes is confusing

• The “arrow from the outside” misconception

• And a better alternative to diagrams to explain accounting

Enough intro, let’s dive in.

Read more

Ledgers are a “get your shit together” tool.

The goal isn’t to record account balances, or where money comes and goes. A ledger’s purpose is to make the company trustworthy. All the strictness and the weird complexity isn’t to make life harder for engineers, or to prevent software bugs, but to keep accountants and auditors happy.

If a ledger can’t be trusted, neither can the company.

In order to interact with your ledger, all the other services have to make sure that they’re sending the right data in the right way. Sure, you can create a translation layer between the other services and the ledger, but that defeats its purpose: a service that initiates, validates, or completes money movements must be, implicitly, as strict as the ledger.

And the way that strictness is enforced is with a ledger that tolerates no bullshit through its interfaces.

All the strictness and complexity isn’t there to slow you down. It’s to create consistency, traceability, and proof.

• Proof that every money movement is intentional

• Proof that nothing can quietly disappear

• Proof that what the company says in aggregate matches the collection of what every transaction whispers individually

A ledger is discipline encoded in software.

This week, we’re looking at the most fundamental building block of ledgers: immutability. In most engineers’ mind, it translates to “append-only”. And sure, append-only databases are immutable because you can’t UPDATE or DELETE rows on them.

But that’s only the beginning of what immutability means for a ledger.

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

• A practical definition of immutability for ledgers (and why you can have it with mutable databases)

• The difference between Journaling and Posting ledger entries, and why it matters

• Why git is a nice metaphor for what a ledger’s immutability is about

• And for the database nerds, read skews, and why are relevant

Enough intro, let’s dive in.

Read more

The biggest obstacle to multi-currency ledgers is a misunderstanding of what the balance rules really are.

Currencies can’t be balanced; you’re comparing apples to oranges. In theory you can balance them using comprehensive exchange rate lists, so that currencies can be comparable. In practice, this never works: it’s like trying to join database tables by timestamps. ASOF joins might work, but time series data is never aligned perfectly. Slight delays between cause and effect can make the reconciliation process unwieldy.

What we need is to reinterpret the balancing process when multiple currencies are in play.

I’ve hinted at this idea in Ledgers of Catan, but the reality is that virtually every company that deals with more than one currency compiles a list of exchange rates (or gets one from an external provider) and uses that as a “best effort” to reconcile numbers, accepting that a compensation will be needed at the end of the period.

They’re doing ASOF joins with their money.

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 do your job exceptionally well. 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 insights from it.

In this article, I’m going to use a multi-currency wallet company as a practical example of how to balance multiple currencies without the strictness of the rule that “every transaction must be balanced” that every accountant uses in practice. This is dangerous territory: nobody does it.

But you’ll see that it can be done, and that it makes sense.

Read more