Building and Scaling a Ledger: Our Interview with Tom Taubkin

At Modern Treasury, we often see companies struggling with the complexities of handling their ledgering system and everything—like tracking and surfacing data, storing user balances, payout decisions, and authorization workflows—that comes with it. We know that a well-built ledger will act as a single source of truth for any company that moves money, but we also know that well-built ledgers aren’t always easy to come by.

Tom Taubkin, CEO and founder of Boosted Technologies and long-time friend of Modern Treasury, was kind enough to sit down with us earlier this month to talk about all things ledgers. Prior to Boosted, Tom was the co-founder of Float, a corporate charge card startup, and an engineer at Coinbase. Throughout his career, Tom has built and scaled numerous ledger databases for different companies.

Read on below to see what Tom had to say about where ledgers fall in the broader architecture of a fintech application, the major challenges in building a financial ledger and how to address them, and advice on how to scale internal ledger databases.

A Q&A With Tom Taubkin

Q: When building a fintech company, or even any product that moves money, ledgering is just one component of the overall infrastructure, but it’s also something that can sometimes be overlooked. What’s been your experience with building back ends and building infrastructure, how important is that ledgering component, really?

A: I think the way I look at it is like what CRM is to sales a ledger is to a fintech company. So what is a CRM? It’s a centralized source of truth for information that you can rely on. You can plug and hook all these different systems into a CRM to get a real time, current view of your information and that’s exactly what a ledgering component does. It can integrate in all these systems and it can help you find mistakes and reconcile the locations of your money.

I think there are a few reasons why a lot of companies don’t originally start using a ledger. One is because they use a vendor, that they can call and just get a balance out of. And so they’ll just rely on that vendor to provide that information. But once a company starts adding more vendors, now they have to track all of those across and it can create a huge problem.

Another thing is that double-entry accounting is 5,000 years old. Something found product market fit 5,000 years ago, everyone uses it and it's still being used as the default today, so you should probably consider using it to move money.

Q: And did you ever fall into the trap of building a single-entry system?

A: We did and I know a lot of other people who did. And it works, at first. But then you start running into issues around, when something goes wrong like a balance for example, and you start trying to figure out why you realize that that issue would have been literally prevented had you had a system which naturally has safeguards in it. There’s a reason why the double-entry system exists. It has a system of checks and balances that force you to, before the accidents happen, think through where the error cases can be and how the system should be properly structured in order to avoid them.

Q: That leads me right into my next question. When you first got into building and scaling ledgers, what were some of the unexpected, non-obvious challenges you encountered?

A: My first exposure to this kind of ledgering system was when I was working at Coinbase. There they had a single, monolithic kind of code repo with a transactions table in it that kept track of everything. And it was just built by the engineers to meet the market needs, but eventually, as we tried to build new services and new features on top of it it just became a super hairy mess to be able to integrate through it. So I think that that was a really difficult point.

I also think the second someone asks you, “Hey how much funds have been transferred into the system? Can I get some data access?” You start realizing that maybe you didn’t think about certain requirements for your system beforehand. And then, of course, you wish that you had.

Q: So, on that note, is it more about doing proper requirement gathering in the design phase and making sure that you have your finance and business teams in the loop or is it more the nature of the problem that you can’t really know what will be needed from a ledger down the line?

A: I think it’s actually a combination of both. There are almost two separate systems inside one ledger. You want to talk to the accounting team and the management team to figure out what information they need from the system and how they will use it. And then, in addition, you want to think through exactly how the systems will be able to use balances and such with the engineering team. You basically gather the requirements for the operational system and then gather requirements for the accounting and back office system of the company, too.

On the back end it's things like what reports accounting teams need in order to close the books at the end of the month. Or, say you’re a mortgage business, you want to be able to say we had x million dollars of transactions a month. What we initially started doing was actually working with our accountants and saying: “Here is how we’re thinking of modeling our flow of funds. Does this make sense?”

But accountants also don’t totally understand the operational needs of the system, so there are going to be points at which you might have to be able to add accounts to the ledger that, from an accounting perspective, wouldn’t matter. Maybe you need a certain balance to be able to display for a user. You need to build out the set of all the different balances that you need to display to the user and then you build out as best you can, a chart of accounts and the flow of funds, then work with your accountant through it.

I think you can have a fair bit of a trial and error mentality, but you also want to try and make your system as simple as possible. If you try to adhere to every single accounting principle, you’re going to end up overcomplicating the system.

I don’t think that process catches everything, but it will catch a lot of things and give you a way to build so that the system is modular and able to easily extend it in the future.

Q: I’m curious if there is anything you would say works surprisingly well when building a ledgering system?

A: I think one thing that works surprisingly well is thinking through the holistic system in the beginning and documenting it. One process we always go through is to basically get a list of all the transactions and get a list of all the different chart of accounts and then actually combine that with the user flows.

I define a transaction as anything that affects an account balance on a ledger or any composable set of business logic that changes the way that balances are defined in a ledger, which might not be the traditional way of thinking about a transaction. Traditionally, you would not think that account opening is a transaction, but it can be because it can initiate a credit limit or funds allocation or set off events that change something in the system.

So all transactions need to have a set of defined ledger entries that they’re associated with. Then, we essentially create a chart of accounts that shows the set of accounts that are linked to the system.

Then we also define a set of user requirements, or queries, that need to exist for the system. For example, for a card product, we need to be able to display the user’s credit limit in real time. Then we think about what accounts we need to get information from in order to balance this. Or, when you swipe a card, you need to be able to know at the point of sale whether or not there is enough money in the account for that transaction and it needs to be super performant. Things like that drive our decision making.

I think performing that exercise and thoroughly planning how the whole system will work from the beginning Is incredibly useful.

Having a ledger is useful, but I think the systemic way that it forces you to think about the flow of funds and how the system operates together is almost as useful as the ledger itself.

Q: You touched on performance briefly and I wonder if you have any best practices for making sure that these systems remain performant at scale?

A: I think it becomes a question of build versus buy, at a certain point. If your company has a really strong devops and scaling muscle that can be applied to it, then you can kind of say, “Okay, we can grow, we can do something in house.” But if you’re writing hundreds and thousands of records, you need a really complex system. And I do think, for performance at scale you will start to get issues that are associated with scale.

Or you can use a solution like Modern Treasury, which offers, I think, the scaling portion really, really well.

Q: One thing we’ve seen at Modern Treasury is a “fix it when it breaks” mentality, I don’t know if you’ve seen that as well. What is the thing that you think people get wrong most often about building a ledger?

A: Definitely the “fix it when it breaks” mentality, that is present in a lot of startup thinking everywhere. But there’s a caveat here which is, at what scale does a system actually need to be super reliable? If you’re moving hundreds of thousands of dollars, it should be a reliable system. There are certain domains where “move fast and break things” is not applicable. Like reporting user balances, that is probably a place where you should slow down and actually architect it properly and make sure that it’s never wrong. You can be fast on the front end, but you should never be wrong and missing client funds. That’s one piece.

The other pieces that I’ve noticed are weird requirements. Things that, for one reason or another, a founder has decided is an important requirement for their ledgering component. An interesting example is a blockchain ledger. People will say, “Oh, that’s a ledger and I need a ledger, too.” And then they want a ledger based on the same heuristics as a blockchain ledger, which is really not what you need. If you’re building a teen debit card application, you don’t need a blockchain in the back end to power that piece of infrastructure, you just need a database. Blockchains are great and useful and you can build decentralized systems with that. But if that’s not what you’re trying to build, then I think that becomes problematic. I’ve had a surprising amount of conversations where people are trying to convince me that putting a blockchain in the back end of a mortgage origination app makes sense.

Some other things I’ve seen are requiring your accounting system to be completely synced with all ledger entries all the time and trying to make Quickbooks your source or truth versus relying on your engineering team. I think that, because there is very little written on ledgering, people will Google things that say the word ledger and just try to apply those concepts without much thought for the principles.

Q: We talked a lot about what could go wrong and things to avoid. A question that comes to mind is, what are the ways in which someone who is building a ledgering system today can stress test that?

A: There are a couple of tools that you can use. One is, you can have invariance on balances, like a balance can never be negative or a balance can never be over a certain amount. If this place expects something positive and it becomes negative, you instantly know that the system is broken and there is something there.

The other advantage of writing ledger entires in the format of code is that you can unit test your logic. You can actually write comprehensive unit tests chaining transactions together and see if you can get these weird states. I’ve seen companies do generative testing, where they'll test out all the different possible iterations and be able to find weird edge cases.

Another place to stress test is to run a reconciliation job, which is a something that monitors balances and then verifies them against real world systems to find discrepancies.

And then the third part, which is not one hundred percent an answer to your question, is to find a way to remediate issues really quickly. If an issue arises you need to make sure you’ve implemented plans for addressing it quickly. That way, even if mistakes happen they aren’t a really big deal.

Q: Do you have any final words of advice for people who are building or developing their first ledger?

A: I would just say, think about it, don't ignore it. Don't put it off into the future, because if you spend a little bit of time thinking about it now it can save you a ton of pain in the future.

To learn more about Ledgers, check out these additional resources:

• What is a Ledger?
• What is a Ledger Database?
• Designing the Ledgers API with Optimistic Locking
• Enforcing Immutability in your Double-Entry Ledger
• Three Questions to Consider When Setting Up Ledgers

If you're looking to keep balances in your platform or move money in your product, Modern Treasury’s Ledgers simplifies building a double-entry system from scratch. Get in touch with us here to find out more.