An Approach To Ledgers That Makes Multi-Currency Not Just Possible, But Easy
Or "How To Embed Everything Into Finance"
Without Ray Dalio, we wouldn’t have McNuggets.
Back in the 80s, McDonalds wanted to add chicken nuggets to their menu. But there was a problem: the price of the chicken was influenced by corn and soy, which are traded in financial markets.
McDonald’s wanted to protect itself from all that. It wouldn’t make any sense to buy nuggets at one price today, and a completely different one tomorrow. They wanted to hedge but there was no viable chicken futures market out there.
So, they turned to Ray Dalio.
Before founding Bridgewater from his apartment in 1975, Dalio had worked as a commodities trader on Wall Street for a few years. He happened to have a chicken producer client willing to sell chicken to McDonald’s at fixed prices, provided that Dalio found a way to hedge the producer’s exposure to corn and soy.
That was Dalio’s expertise. He combined the two commodities into a synthetic future, and the McNugget was born.
There’s a key takeaway from this. Any business sells products that can be broken down into components. Some of them have a relatively stable value, like buildings, or have a value that changes predictably, like office furniture.
In both cases, traditional accounting has all sorts of tricks to take into account changes in value. For buildings, we call it surplus value; for office furniture, we call it depreciation.
But there’s a special kind of component whose value fluctuates rapidly, and unpredictably. Foreign currency is the most visible example.
Thanks to technology, though, we can do what Dalio did with the chicken nuggets in the 80s. And in this article, I’m going to tell you how.
I’m Alvaro Duran, and this is The Payments Engineer Playbook. You’ve already come across tons of tutorials that show you how to pass software design interviews that use payment systems. Frankly, a lot of it is junk. But there’s not much that teaches you how to build this critical software for real users and real money.
And because I’ve built and maintained payment systems for almost ten years, I’ve been able to see a lot of amazing, but behind-the-scenes conversations about what works and what doesn't for money software.
In my opinion, these conversations should be shared. And that is what this newsletter, The Payments Engineer Playbook, is all about.
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 extract tactics from it.
I believe this is the only place in the entire Internet where you can get that.
Double-entry accounting has existed for thousands of years. And yet, it’s experiencing rapid change these days.
First, even small companies now sell globally these days. We’ve come a long way from that proverbial pizza ordered online in 1994. Nowadays, much like mail is email, commerce is ecommerce:
Online merchants make the most of the attention they get on social media with extremely quick campaigns. Special offers, on a limited time window, often for a limited amount of stock. And that put a lot of pressure on Shopify’s infrastructure almost from the get go.
Especially on Black Friday.
Global commerce, remote employers, foreign suppliers. Multicurrency, real-time payments happen a lot these days. Dropshipping may be morally questionable, but it’s operationally feasible.
Second, companies like Robinhood, Revolut and Coinbase now offer the chance to invest small amounts in financial markets. They’ve brought foreign investments to the mainstream. They’ve normalized risky trades.
And third, the dollar is no longer the ultimate reserve currency. Our world is becoming more fragmented, not only politically, but also economically. Some suppliers will only accept a particular form of currency.
It’s not that some companies are trying to do embedded finance. It’s finance which is being embedded into everything.
Supporting multiple currencies in your company’s ledger has become a necessity.
And that’s bad. Because double-entry accounting is meant to use a single currency to represent value.
Double-entry accounting trades-off the simplicity of bartering for a self-check mechanism. But currency exchange is bartering (it’s an exchange, after all). Entries in different currencies cannot be balanced. Apples cannot be compared to oranges.
Traditionally, this wasn’t a problem. Cross-border payments happened so rarely, humans could reconcile them manually. And accounting rules provisioned rules like Weighted Average, FIFO or LIFO, to account for those Accounts that stored inventory with fluctuating value.
But now, cross-border payments happen even at the smallest scales. And they happen frequently. We’re entering uncharted territory, where traditional double-entry accounting has to be adapted to a world where assets’ and liabilities’ values must be reconciled, in the face of volatility, in real time.
That’s intimidating. And exciting.
Not a Balance Sheet, But a Balance Folder
Say you have a stock trading platform like the one I used to work for, and user Alice wants to purchase bitcoins from us. This is one way to represent this operation in a double-entry system:
Alice BTC gets 1 bitcoin from Platform BTC.
Alice USD gives $58664 to Platform USD.
Platform USD gets $58664 from Alice USD.
Platform BTC gives 1 bitcoin to Alice BTC.
Does this make sense so far? (Go to my recent article on ledgers if it doesn’t).
Here’s the issue: Even though we’ve balanced BTC accounts and USD accounts, we can’t say that the overall ledger is balanced. In fact, I’ve just checked again, and the price of Bitcoin has moved to $58510!
That’s what I meant by real-time. One blink of an eye, and we have to recognize a loss? And we have to do this every millisecond?
How can a system like that, not just be always balanced, but also accommodate further throughput coming from actual movements of money?
Thankfully, there’s a solution here. And it’s been under everyone’s noses all this time.
Having multiple currencies coexisting in the same ledger requires us to abandon a two dimensional description of money. We need to treat the ledger as if it were multiple layers of it, each in its corresponding currency.
Not a sheet, but a folder.
This makes a lot more sense than what it now looks like. But first, I need to talk to you about vectors to make some sense.
Money Movement As Vectors
Last week, when I published Engineers Do Not Get To Make Startup Mistakes When They Build Ledgers, I got a comment from Matheus Portela, the author of Double-Entry Bookkeeping as a Directed Graph.
That made me very happy, because I had already studied his article in detail. But his approach didn’t fully click with me, and I decided not to include it.
Matheus’s likes to think about ledgers as if they were directed graphs:
Think about this: An account is a node in the graph, a credit entry is an outgoing edge with an amount of money leaving this node whereas a debit is an incoming edge with money flowing to another node. A transaction, then, groups and enforces a condition on a set of edges: the outgoing edges must have the same sum of money as the incoming edges.
— Matheus Portela, Double-Entry Bookkeeping as a Directed Graph
Martin Kleppman (author of what I consider the most important book in payments engineering) follows a similar approach in his blog.
This approach is fine for some. But I’ve realized that treating ledgers as graphs doesn’t go far enough.
Ledgers may be graphs, but movements of money are vectors.
Vectors, like the ones we all got to know and love in high school. Movements of money are vectors because they have magnitude, sense and direction.
Now, the magic trick. Each of the movement-of-money-as-vector has revealed itself through history one at a time:
Single-entry accounting records magnitudes: The first phase of accounting recorded the most obvious of the money movement’s properties: the amounts.
Double-entry accounting records magnitudes and senses: The next phase noticed that money movement has source and destination, not just a value.
Multi-currency double-entry accounting records magnitudes, senses and directions: Finally, treating the ledger as multiple layers of single currency sheets means that where the money is moving is also an important property that must be captured in the system.
Treating movements of money as vectors unlocks a clever trick. Vectors can be decomposed into a parallel and perpendicular component, right? Then, balancing a multi-currency transaction becomes balancing two single-currency subledgers independently, and then recognizing the gains and losses derived from fluctuations in the exchange rate only when an exchange happens.
No more having to update fluctuations in the ledger in real time: if you’re not converting currency, then the ledger doesn’t change as a result of that volatility.
Again, some numbers will make this more clear. Say that Alice now wants to buy shares in TSLA (in dollars) and shares in BP (in British pounds) at an effective rate of 1.5 dollars per British pound. This is one way to represent this operation in a double-entry system:
Buy 1 TSLA ($100)
Buy pounds, sell dollars (GBP 100 in exchange for $150)
Buy BP (GBP 100)
Later, Alice will undo her position in both TSLA and BP, and convert all the gains into dollars. This will get represented this way:
Sell BP
Sell pounds, buy dollars
Sell 1 TSLA
Let’s say that BP goes up 10%, TSLA goes up 20%, and the exchange rate is now 1.25 dollars per British pound.
This, by the way, is the example that Omi Chowdhury, CTO of Fragments, uses in his talk Building a kickass multi-currency ledger.
Being able to consider each currency independently helps us do the numbers separately.
On the dollar side:
Buying and selling TSLA: 120 - 100 = $20
That’s it. And in the British pound side:
Buying and selling BP: 110 - 100 = GBP 10
Buying and selling GBP: 110 * 1.25 - 100 * 1.5 = $(-12.5)
All told, Alice made $7.5. The unrealized gains from BP were offset, and then some more, by the devaluation of the British pound.
The benefit of treating different currencies separately is that it help us understand the problem more clearly. But most importantly, in many countries, gains and losses in currencies and stock markets are taxed differently than revenues and costs from normal operations.
There’s an element that I’m making implicit here, and that is a database (internal or external) that provides the effective exchange rates at which each conversion happened.
There’s something oddly satisfying about looking at payments from the point of view of software engineering.
Accounting is several thousand years old, and yet we’re still discovering new ways to build upon the basics to serve modern use cases.
It is also a testament of how useful it is to choose boring technology most of the time.
And that is my biggest takeaway from this article. It’s not simply to implement double-entry accounting because it’s battle tested. It’s choosing technology that’s been around to coevolve with the problems that tracking down money brings with it. History implies reliability. But understanding the underlying principles, the key decisions, is what helps us see beyond.
It prevents technology from becoming outdated.
As I said, it’s oddly satisfying. To find new in what’s old. It leaves you with a sense of respect for those who developed the technology in the first place.
This has been The Payments Engineer Playbook. I’ll see you next week.
PS: I’ve got a gift for you.
I included lots of publicly available references on last week’s article. Some of you have come to me asking for more of this, and for all of my articles.
“Hey Alvaro, is there a chance that you have your references for all your articles listed somewhere?”
I get it. Some of you want to dig a little bit deeper in a particular topic, and all you’re looking for is some guidance, a Reference List.
Turns out I don’t have such a list. But I can build one. And I’m going to make it available online.
All I’m asking for you is to refer a friend.
How does that work? Well, you’ve made it this far into the article, so I’m going to assume that you liked it. You might like it enough to think that some colleague at work should read it too.
Refering a friend is a way to reward those who help this newsletter grow by word of mouth. If you successfully refer a friend, I’ll share the link to the References List as soon as it is available.
As you can see, I’m letting you know of this program at the very end of the article. I don’t want people gaming the referral program, and I don’t want people to get emails they don’t want to get.
So I trust that you do what’s right.
If you think that someone at your company could benefit from subscribing to The Payments Engineer Playbook, you can share this article link. But I will have no way to tell it was you who refer them!
Instead, you can share this article using this button below:
If your colleague happens to subscribe, then I’ll make sure you get the Reference List as soon as it is available.
And if someone you respect shared this article with you, do me a favor and subscribe. Every week I feel I’m getting better at this. That means that my best articles on how to build payment systems are probably yet to be written.
You can only find out if you subscribe to The Payments Engineer Playbook. I’ll see you around.
Great stuff. We'll build our own references, don't fret.