Announcing Ledger v2

We are thrilled to announce the release of Formance Ledger v2, a major milestone and core product update building off its previous version and millions of real-world transactions operated.

Formance Ledger provides a programmable, real-time system-of-record that enables you to support your core ledger operations and operate complex, diverse flows of funds.

The Ledger also holds a special place as a foundational component, as it is at the heart of interactions with the other services of the Formance Platform.

We believe in enabling our users to keep ownership and control over their critical financial infrastructure components, which means this brand new version is available under a permissive MIT license, as since the beginning of our journey.

And as any component of the Formance Platform, Ledger is designed to be consumed either directly with our managed cloud service, or deployed on your own infrastructure, with the support of our Kubernetes operator. Raw artifacts (binaries, docker images) are also published for specific deployment contexts.

New in this version

Introducing bi-temporality

The main highlight of Ledger v2 is the introduction of bi-temporality, elevating time to a first-class primitive in its data model.

Ledgering systems happen to find themselves at the crossroads of different financial data sources, tasked with the creation of a cohesive and unified end state. Coalescing multiple truths to a single version of the truth is hard, especially when time gets involved. Allowing your ledger data to exist in multiple timelines with bi-temporality is a powerful addition in your toolkit as a ledger designer.

In practical terms, bi-temporality in the ledger means that each transaction is now associated with two distinct timestamps, namely:

Request time

The time at which the transaction is submitted to the ledger, typically reflecting the machine clock time.

Transaction time

The actual time at which we consider the transaction to logically have occurred. Systems in the wild tend to use the terminology effective date or booking date to name this concept.

With these two timestamps attached to each transaction, Ledger v2 can now allow users to determine the state of the ledger at any given point in time, being the past or the future. This enables quite a few exciting and practical things. We can now easily:

Time travel

Querying the ledger at a specific point in time. An invaluable capability for analyzing past states, conducting historical financial analysis, or simply understanding how the ledger has evolved without reverse-engineering its own data.

Mitigate erroneous entries

Correcting ledger errors becomes way easier with the ability to commit backdated or postdated transactions, ensuring rectification of discrepancies without while keeping a clean transaction history.

Audit at fixed time

Enhance your auditing processes by reviewing the ledger at a specific point in time. Auditors can verify the state of accounts and transactions at a fixed date, enabling end-of-day and other time-oriented reporting and statements.

Import historical data

Import data from external systems, bringing the transactions with their former in-situ timestamps. This feature ensures that your ledger remains consistent with the system you are migrating off from, and is also helpful when integrating data from various external sources.

Read more about bi-temporality here.

Improved querying and filtering options

The Ledger v2 API comes with new filtering options for transactions and accounts. Clients can now apply filters using JSON objects to control query results precisely, replacing the former query string variables.

Filters can match specific criteria, use wildcards, and combine multiple conditions with logical operators such as $and and $or. These improvements make extracting meaningful data from the ledger easier based on various fields such as metadata, timestamps, and account balances as complex queries can now be expressed.

Example queries include,

• Querying the aggregated balance of a set of accounts based on their metadata
• Retrieving transactions within a specific date range
• Filtering accounts with balances greater than a specified amount

Read more about the new querying syntax here.

Enhanced Storage Isolation Controls

This version improves the ledger data management and storage capabilities, by introducing a new bucket primitive, which provides a construct to explicitly define how your ledgers should be isolated from one another at the storage layer.

The co-location of multiple ledgers within a single storage unit (i.e. bucket) now becomes possible, which each bucket translating as a separate database schema.

The creation of multiple buckets facilitates data isolation and ensuring that datasets have no possibility of interfering with one another—and serves as a foundation for horizontal sharding at the ledger level.

With this architecture, platforms and financial Institutions can scale their storage needs dynamically without compromising on performance or security. These enhancements are particularly beneficial to enterprise deployments handling large volumes of data, requiring stringent data separation for compliance requirements.

Getting Started with Formance Ledger v2

You can now deploy today a new ledger in its latest version to take advantage of its new features. Our comprehensive API documentation provides detailed reference on using bi-temporality and the enhancements mentioned in this release note.

Join the Community

Formance wouldn’t exist without its open-source community: join our group of financial applications engineers to share your experiences, ask questions, and collaborate on best practices. Visit our Slack and GitHub repository to get involved.