Ledgers Powering Innovation: Highlights from Our Tech Talk

Modern Treasury’s Ledgers help companies across use cases accurately manage money movement. To better understand what makes ledgers work best and how sophisticated companies need to be with ledgering, we hosted a tech talk with Koji Murase, Ledgers Product Manager, and Matt McNierney, Engineering Manager. Below is an edited excerpt—you can access the full Tech Talk here.

Q: Where did the Ledgers product start at Modern Treasury and how is it different from a general ledger?

Koji: We work with great software companies and help them build embedded payments into products. One of the things we noticed was that the best software companies need a financial database because financial data is really critical and requires a specific kind of infrastructure, so we built it. And what’s exciting is how companies are using Ledgers to build innovative products on top of.

Matt: There's some ways in which a ledger like ours is different from general ledgers:

• The first is performance. These financial database ledgers have to be optimized for high throughput. We're talking about thousands of transactions per second which need to be optimized for efficient reads.
• Then there are concurrency controls. At scale, you may have multiple transactions happening at the same time or even microservices writing to this database. So there is a need to ensure that the ledger is consistent, even if transactions are written out of order.
• Another thing that's different is how you architect the ledger. The way you design accounts in a general ledger is different. A general ledger typically thinks about big buckets of money, your accounts payable, accounts receivable. We typically advise companies to make the accounts in a ledger database as granular as possible. So you'll have many more accounts in an application ledger.

Q: So there’s a couple benefits of having an application ledger: speed and accuracy. Is there an optimal time when companies should consider building a central ledger?

Koji: Early on, startups can get away with doing last-minute or delayed reconciliation. But larger enterprises that work closely with big banks know that there's less tolerance for that amount of risk. So, it's important to have a ledger built the right way before a company is at that stage. If you don’t, you may slow product velocity. And we’ve seen lots of stories about how that breaks down.

We talked to a marketplace payouts company, who had an interesting bug where–they’re trying to pay out a balance to customers at the end of each day. And there was an interesting edge case, where, if a transaction came in around cutoff times, the payout would be backdated and wouldn’t be logged correctly.

And it is a great example of how users end up having hawk eyes for this kind of thing. Like, in a general ledger, you’d likely never notice a $100 payout getting missed, but at the user level, in an application ledger, your customers will notice if even $1 is missing from their expected payout. So that marketplace realized there was a bug in their ledger.

Trying to implement fixes after the fact means months of work trying to remedy versus building correctly the first time. That’s really a huge tax on your development team. But there's a lot of opportunity when you have a ledger built the right way and financial products interact seamlessly.

Matt: One other fun example is from a conversation that Koji and I had with a product leader at a fintech company. He was telling us a story about how, at the end of one month, a person on the finance team came to his desk and said, “Hey, there's a couple of millions of dollars missing here.”

And there was a mad scramble to try to figure out what happened to that money. The really interesting thing is that the money wasn't gone. It was just the attribution of that money that was missing. So it looks like there were unaccounted for funds, when in fact, everything was fine, so at the end of the day, it's about attribution and a correct ledger.

One analogy I like to make is double entry accounting to unique indexes in a relational database.

A lot of application developers probably have had the experience that if you're not enforcing something at the database level, you will have inconsistency.

So double entry doesn't solve all your problems. But having that guarantee at the architectural level, can really help out and prevent a bunch of edge cases.

Q: I'm wondering if you could say more about the opportunities with differentiated products you're seeing spun up. What kind of innovation are you seeing around closed-loop payment systems?

Koji: First of all, a closed-loop payment system is a system where money moves between users in your network, so you have full control over the network. A really typical setup, you'll see, is an omnibus, which is, think of that as a pile of cash that you're subletting, meaning your users might have fractional pieces of that pile. But those fractions are recorded just on your own database, and you're tracking all those balances.

One of the most famous examples is Starbucks. Consumers load money onto Starbucks cards for use at Starbucks stores, and so Starbucks has a huge amount of money in deposits.

Think about the cash flow implications of that: that’s billions of dollars from users loading up their wallet. But it’s not just cash flow; users like it—it's fast and delightful.

They don't have to go check with a card network when someone comes in to buy something. So it's a great user experience.

And the last thing is, it gives them a lot of visibility on the payments. They're not again offloading onto an external system to process that payment. They're cutting out all the intermediaries, and they get to see the full life cycle of that payment.

Another example is a customer of ours, ClassPass. You sign up, pay a monthly subscription and, every month, get an allocation of class credits. I can find a gym and spend credits to book a class. They have tens of thousands of studio partners around the world. This is all ClassPass credits that they ledger and then the studio partner gets paid.

But we see so many interesting forms of closed loop payment systems. They can involve rewards points, gift cards, or traditional store balances. And a lot of companies are innovating with new models every day.

One thing I have to say is, I'm not a compliance expert. We work with a lot of experts in the space, but the way you design this closed-loop system has implications—obviously on the user experience, but also on how it's treated in a compliance sense. So it's really important to dive into that as well as you're designing out your closed loop system.

Q: What does a payments product team need to know or build differently to support audited financials?

Matt: There are some basic principles that I would suggest. Use an immutable ledger so you know about all the money movement that's happening. And when your auditors come, you can say, “This is the state now, and on January 1, this was the state.” And you can go back and see the state of every account at any moment in time.

Double-entry can really help here, too. A lot of companies, not just startups, start with a single-entry system and then, later on, hire a recon team that takes all that data and turns it into some kind of double-entry system that then feeds into your ERP. They sometimes suffer from the same “garbage in, garbage out” problem that you see in AI models. It's very difficult to add double-entry data to a single-entry ledger. So, I'd recommend thinking about double-entry from day one, so you don't have to do a really costly migration later.

Visibility is another big one. You want your data and analytics and reporting teams to see and understand the ledger, and be able to interact with tables that you ledger on. You don't want those kinds of stakeholders to mutate or edit the ledger, but it is nice to give them visibility. One thing that our product does well is push the entire data warehouse version of the ledger to you in a read only form. That's one way to give that kind of view to those stakeholders.

Q: Do you have any recommendations and advice for project managers and engineers tasked with building these payment systems?

Matt: Again, it's important for companies that are moving money, regardless of size, to think about using an immutable and double-entry ledger. It makes it architecturally impossible to lose track of money. A lot of the companies we work with are moving into ledgers and seeing benefits in terms of their scale in terms of correctness. And it really enables you to build cool experiences for your customers.

Koji: The fintech market has changed. Obviously, in the last couple of years, companies are less focused on growing for growth's sake and capturing market share and more on retaining and driving value to existing users. We're especially seeing that with our enterprise users who are trying to monetize and retain their customer base. The best way to do that is always embedded finance.

With embedded finance, closed-loop patterns are really powerful. This is a more recent trend. But it's really powerful if you create a network with instant, no-cost payments within your application.

It’s great for users and you can build all sorts of financial products on top of it. Think about what version of this closed-loop model you want to go with and then talk with compliance experts to understand what the implications are.

Next Steps

You can access the full Tech Talk here.

Modern Treasury enables companies to automate payments from end-to-end, including reconciliation, payment orchestration, compliance and ledgering. If you are interested in learning more, reach out to us.