Announcing Multi-Currency Support for Ledgers

Introduction

Maintaining a ledger often involves only a single currency. But when dealing with cryptocurrencies, exchange rates, international transfers, or even just customer preferences, there comes a need to record multiple movements of separate currencies.

We can accomplish this today with our current implementation of single currency ledgers. You can create a transaction within a USD ledger and a second transaction within a BTC ledger while ensuring the books are kept even.

This implementation, although functional, has two large gaps we want to resolve:

1. Atomicity (a guaranteed success or failure of a transaction) is not assured across ledgers;
2. Associating transactions requires exporting and joining the transactions with logic the client needs to build (e.g., either identical external-id or metadata)

Atomic guarantees are foundational to a ledger. Without atomicity, ledgers risk creating inconsistent balances and requiring intervention from engineers and finance to troubleshoot. A huge headache.

While part of this could be mitigated by associating transactions across ledgers with our push-to-warehouse solution, the number of customers we serve who operate internationally has grown exponentially. With this growth, the need for full atomicity in cross-currency transactions became clear.

Today, we are happy to announce multi-currency support for Ledgers. A single transaction can now have entries and update accounts across currencies. We believe this will dramatically simplify the process of scaling infrastructure internationally for fintechs, marketplaces, vertical SaaS, and other tech companies that move money.

How Multi-Currency Works

The currency property has now moved from being defined on the ledger level, to the ledger account level. Ledgers can now hold accounts with multiple currencies, and a single ledger transaction can span many currencies. Custom currencies are supported in ledger accounts the same way as they were in ledger objects.

How does this look on an implementation level? Let’s walk through a simple example.

Let’s assume you’ve built a wallet solution, and you want to support sending transfers between wallets from Uri in the US (in USD) to Casey in Canada (in CAD). You probably at minimum, have the following set of accounts:

1. Uri (USD) + Casey (CAD) Accounts (Credit Normal)
2. Foreign Exchange (FX) Fees (Debit Normal)

Before multi-currency, you’d have to model these transactions in two different ledgers. Now, we can model this as a single transaction. Let’s say Uri sends $12 CAD to Casey’s wallet:

Notice that you need a cash account for every currency involved in the transaction; FX Fees are only processed in USD. Just as you would balance every debit and credit entry, so must every debit and credit be balanced per currency. This transaction has a single transaction ID and therefore single state (pending/posted/archived) and metadata. In this case, there’s a processing fee of $1 USD.

Settlement (in particular of FX processing fees) could be split into multiple transactions:

Each of the rows in the tables indicates a single atomic API call with a single transaction guaranteed within it. The currency of an account is now tracked with a new currency field. Exporting each of these transactions now has all the associated metadata across currencies, allowing for simpler cross-currency accounting.

Multi-currency in Practice

Multi-currency support will be particularly helpful to companies that deal with multiple fiat or cryptocurrencies or with data that behaves like currency (points, rewards, etc.). In addition to making cross-current transactions atomic, this makes it simpler to cross-check, and audit balances, query accounts by currency, and display balances flexibly.

If your product or platform deals with multiple currencies, Modern Treasury Ledgers can act as a high-performing double-entry database for your financial data. Reach out here if you have questions.