Case Study: Building a Scalable Ledger: Key Lessons from Our Team

In 2024, Liberis undertook a project to deploy a new strategic platform for financial ledgers. Ultimately, we settled on Formance as the technology provider for this ledger. Over the year, we identified a pilot product to evaluate the new ledger platform and ultimately deployed it to our customers. This case study is the result of interviewing the people responsible for the work, and the stakeholders for the work.

The project was successful at reducing the maintenance burden of our ledger stack and increasing the reliability of the ledger. Key to this was explicitly planning alignment and collaboration between our Finance/Treasury team, and the engineering team responsible for the implementation. This close collaboration helped the engineering team to identify additional opportunities and reduced the need for rework and maintenance.

Liberis is the world’s leading embedded finance company; we allow providers of vertical software, payments companies, and marketplaces to offer financial products to small businesses on the platforms that they are already using.

Liberis’ flagship products centre around new ways to deploy capital to small businesses in a flexible, fast, and transparent way. We integrate deeply with payment systems and deploy our own in-house machine learning models to drive a best-in-market customer experience and a sustainable, responsible financial product.

As a scale-up, we are exceptionally discerning about where we spend our technology teams’ time. We always aim to launch products early and gain fast feedback. However, we are also a provider of financial services, so certain systems can’t be exposed to the same fast iteration cycle of development, and instead must be made resilient from the beginning. Our Ledgers are a perfect example of this type of system, they need to work accurately, reliably, and consistently from day one.

Our existing ledger platform has grown with us over time. The functionality is spread across several in-house and third-party components. While, of course, we trust it to keep accurate records of our accounts - it isn’t the easiest system to keep consistent, relying on manual reconciliation activities in our treasury team. It also generates a fair amount of maintenance work for our engineering teams, something we are always keen to make more efficient.

At the start of 2024, we made our plans to massively expand our geographical footprint by launching in 6 new countries, and also deploy 3 new product pilots in key markets. We knew that our ledger system would need to change to accommodate this growth, so we explored ways to get it ready for our year of expansion.

We identified our Flexi Advance product as a good place to begin deploying our new ledger programme. Variants of the product had existed in pilot phases for some time, but we were getting ready to roll it out on a huge scale as the backend system for eBay’s Flexible Cash Advance programme.

The product has some unique constructs: Small businesses get access to a pre-approved “pot” of available financing that they can choose to deploy as and when it suits them, in small or large chunks. It’s optimised for small businesses who know they often need finance, but who don’t need it right now. It also is compatible with our split funding rails, so small businesses are paying via a small percentage of the transactions they are making on the platform rather than on a fixed schedule.

As such, it introduces several interesting financial concepts to model:

• Customers can have an outstanding balance, or no active balance at all, while they have an active product.
• Customers have an amount of finance available to them in their “pot”, which will move up and down as they request funds and make payments.
• Outstanding balances are comprised of a mixture of fees and advanced capital.

These elements made the product interesting to us as a place to explore upgrading our ledger infrastructure.

“There's so many ways you can get a Ledger wrong. And it's so fundamental to the business, that having that challenge solved for you already is a no brainer”

-Kirsty Luke, Head of Financial Systems Engineering @ Liberis

As our flagship products are not traditional constructs, such as an APR-based loan, this often rules out using off-the-shelf ledgering and pricing platforms for our work. We need the ability to express our financial constructs and transactions in our ledger.

Despite this, we knew that there are base components of a ledgering system that we do not need to replicate in-house. Double-entry credits and debits, rolling balances, etc. work the same everywhere. Replicating this in-house adds risk, and also means we are spending a relatively smaller proportion of our time on the pieces of our financial systems that are truly unique: such as our comprehensive network of Split payments integrations across card acquiring and e-commerce payment systems.

Fortunately, the tradeoff is not so binary. Configurable ledgers have existed for some time, we were pleased to find a new generation of these products that worked perfectly for a scale-up like Liberis. We made the decision to reach out to a number of suppliers of ledger platforms and evaluate if any of them met our cross-functional and feature requirements.

We broke down the types of platforms we were exploring into a few categories:

• Core banking platforms
• Complete SaaS ledger products
• Lightweight, modular ledger platforms

We evaluated a number of Core Banking platforms initially, with Thought Machine taking our interest as a leading contender. While we were impressed by the quality and breadth of these products, especially Thought Machine, we ultimately decided that we would look for a simpler platform for our use case. This category of product lets you do a huge amount and can be used as core banking infrastructure for entire banks. However, Liberis doesn’t need to build a bank, instead, we need to accurately model our existing banking and payments relationships. We ultimately decided that these platforms were too complex for our current business needs.

We also evaluated some complete SaaS ledger products. These products promise to solve the entire problem for you from day one. However, as our financial products are not identical to traditional financing products, it would mean we would need to build in some of that complexity directly into our application layer and maintain a translation system between ledger concepts and software concepts. We would much rather model our transactions and accounts directly onto the ledger layer so that we can ensure accuracy without overcomplicating our software development lifecycle in all teams.

We were most excited about more lightweight, modular platforms. Formance stood out to us as the best in the category. Key facets of this decision were:

• The level of support offered during the ledger design phase. While we were confident that we could design it ourselves, it was reassuring to have support from a team who can pre-warn design choices that are costly to rectify.
• The Open Source offering. Our ledger must be resilient to supplier failure, it is one of our biggest assets. The traditional answer to this problem is software escrow, but we don’t believe this is a sufficient safeguard against supplier failure. Especially in a world of SaaS suppliers, it is dubious to rely on your ability to build and run software in your own single-tenant computing environment. At best, such a scenario is likely to lead to a huge amount of replatforming and addressing compatibility issues. We much prefer vendors such as Formance who offer an open-source model, as this shows us that they are built from the ground up to be maintainable by third parties.

At Liberis, our way of working is extreme collaboration. We much prefer to be solving problems together than endlessly specifying requirements. We knew that for this project to be a success, we needed very tight collaboration with our treasury/finance team, and do that we all needed to be speaking the same language. As far as possible, we wanted to make sure that as engineers we were adapting our view of the world to match how our treasury team see it. We didn’t want to be translating back and forth in our heads between financial concepts, e.g. credits, and computer science concepts, e.g. mutations.

To accomplish this, Nadia Emamboccus (Group Financial Controller @ Liberis) trained all of our software engineers in the business unit that would be responsible for the ledger in the basics of double-entry accounting. The training focused on the domain language used by accountants to describe their work and the processes and methodologies they follow to ensure the integrity of our accounts.

“Whenever I raise anything through Slack, [the engineering team] always knows exactly what I’m asking. That’s probably because I’ve spent so much time with them, and they’ve spent so much time with us. We’re almost extensions of each other at this stage”

-Rosie Baker, Head of Treasury @ Liberis

To ensure we had a truly joined-up model of the world, we co-designed the ledger with our treasury team. This is very different to collecting the requirements from a stakeholder, we wanted to ensure that there was a true shared model usable by both the engineers and the treasury team to describe the system, avoiding the problems of translation.

This proved useful, our colleagues in the finance team instinctively see many more things in terms of accounts and transactions than us technologists do, helping us to spot opportunities to model our ledger in a way that solves additional business problems directly, rather than having to solve them separately in the application layer. For example, the notion of one customer account being splittable into multiple sub-accounts to differentiate revenue comes as natural to somebody trained in finance but is non-intuitive if you have not had exposure to that idea.

We had hoped that a domain-specific language (DSL) would help to more closely align our vocabulary with the vocabulary of our finance team. Formance supports such a DSL: Numscript.

DSL’s have a mixed history of success and are often overused. One of the traditional promises is that they allow subject matter experts, not engineers, to directly express what they are talking about.

In this case, it turned out that this did not materialise as a benefit. Numscript proved to be a little too procedural to be something we could use to fluently communicate with the Finance team.

However, it did bring another big benefit: Using a DSL instead of a configuration-heavy system meant that we could apply the classic tools of a software engineer’s trade to ensure consistency and safe change management. Ledger products that can change their behaviour via the modification of configuration in a UI run the risk of breaking integrations with in-house systems if they change separately to the Software Development Lifecycle.

Much like the argument for Infrastructure as Code, replacing this config with code changes under source control lets us control our application layer and our foundations through the same mechanisms. This makes changes simpler, and therefore safer.

The engineering team made use of testing environments for the ledger to gain confidence about transactions in a lower environment before rolling changes out to production. This sounds obvious and is a widespread practice in technology, but in this case, it was made much easier because the ledger itself is expressed as code. Systems that are highly driven by configuration are prone to environment drift without strict governance, aligning the release cycle to our existing pipelines and environments gives us strong confidence in the reliability of our test environment.

Opportunities taken

“The way we integrated the ledger into our funding system, essentially lets us onboard new products much more easily because we built predefined pipelines for all of our supported payment routes.”

-Mark Valdez, Senior Software Engineer

A standout aspect of the success of the approach was the relative amount of time we spent on the integrations that are unique to Liberis and directly drive our ability to service more small businesses - deep integrations into the payments stack of our partners. Being able to safely shift effort into this activity drives the top of our conversion funnel.

Integrity

A key indicator for success for any ledger programme is “nothing went wrong”. To date, we have not experienced any reconciliation errors with our new stack. However, payments are a complex space, and there is a long tail of unusual scenarios when you work across 13 different payment rails.

As such, we are letting the pilot run a little longer to expose it to more of these scenarios before rolling it out to our highest-usage products.

Manual reconciliation

The work required to reconcile what happens in the banking layer with the ledger is substantially reduced. This is primarily because we were able to shift the team's effort to automation of the payments stack rather than working on core ledger concepts directly.

Collaboration

As a fintech, the relationship between our finance and tech teams is a key asset. Beyond the ledger work itself, we’ve seized the opportunity to bring these teams even closer together and have a deep understanding of each other's work. As we expand our product offering in 2025, we’re confident that this will prove to be a fintech superpower.