Use case
Your platform has the transactions. Their customers need balances.
Definition
A customer subledger is the state layer beneath a financial product that maintains a live balance and transaction history for each end customer. Payment platforms, wallets, custody providers, and embedded finance infrastructure hold the transactions and the aggregate position for their direct customer, while that customer serves end customers who each need to see an individual balance and their own activity. Lucius consumes the transactions the platform already produces, attributes each in-scope transaction to the relevant end customer, and maintains that balance and history per asset, with pending and settled activity held separately. Money movement, custody, and execution stay with the platform. The platform's own product remains customer-facing, and the capability can be enabled only for the programs that need an end customer layer.
Map your end customer layer
Show us your existing transaction and customer objects. We'll map the end customer layer and show how it sits behind your product.
The problem
- Your platform knows every transaction and the aggregate position. Your customer needs to show their own customers an individual balance and history, and that object does not exist anywhere yet.
- Funds sit in one omnibus wallet, pooled account, or custodian position. The on-chain and bank activity is real; who owns which portion of it is not recorded.
- Each customer either builds and operates its own state layer before they can launch, or ships a workaround that gets more fragile as end customers, assets, and volume multiply.
- The same requirement arrives with every new program, so the same engineering work is repeated and implementations slow down.
How Lucius solves it
- Lucius consumes the transactions your product already produces and attributes each in-scope transaction to the relevant end customer.
- Every end customer gets a continuously maintained balance and complete history, held per asset, so a unit balance and what it is currently worth are both available.
- Deposits, withdrawals, trades, transfers, and fees taken in kind land as events. Pending and confirmed activity are held distinctly, so the history matches what the end user is actually looking at.
- History is append-only. A correction appears as a new entry rather than rewriting a line an end customer has already seen, and any balance can be replayed from its transactions when someone disputes it.
- Your product stays customer-facing. Lucius runs behind it, enabled only for the programs that need it.
Workflow
- 1
Connect your existing transactions
Lucius consumes the activity your product already creates. There is no second transaction system for your customer to operate.
- 2
Add the end customer layer
Each end customer is mapped beneath the relevant customer or program using your existing identifiers and object model.
- 3
Attribute activity as it happens
Every in-scope transaction is associated with the end customer it belongs to, including deposits, withdrawals, trades, transfers, and fees.
- 4
Maintain balance and history
Lucius keeps a live balance and full transaction history per end customer and per asset, with pending and settled activity tracked separately.
- 5
Serve it through your product
Your platform requests end customer state and presents it in the experience your customer already integrates with.
Example data flow
| From | To | What happens |
|---|---|---|
| Transaction | End customer | Existing activity is attributed to the end customer it belongs to. |
| Attributed activity | End customer balance | The balance updates as activity occurs, held per asset. |
| Pending deposit | Settled balance | Unconfirmed activity is visible as pending and moves to settled without rewriting history. |
| Omnibus position | Sum of end customer balances | The pooled wallet, account, or custodian position reconciles against the claims recorded beneath it. |
| Lucius state | Your product | Your platform returns balance and transaction history through the existing customer experience. |
Frequently asked questions
What is a customer subledger?
A customer subledger maintains the balance and transaction history for each end customer within a larger financial platform. A payment, wallet, or custody platform holds the transactions and the aggregate position for its direct customer, while that customer serves hundreds or thousands of end customers of its own. The subledger is the layer that records which portion of the platform's activity belongs to whom, so each end customer can be shown an individual balance and history. The platform remains the source of every transaction and all money movement. The subledger does not move money; it attributes activity that has already happened and keeps the resulting state current, so the balance an end customer sees is maintained continuously rather than calculated on request from raw transaction exports.
Why wouldn't our customers just build this themselves?
They can, and some will. The trade-off is that every customer then has to design, build, test, and continuously operate its own state layer before it can launch anything, and keep that layer correct as end customers, assets, and volume grow. Balance correctness under concurrency, replay after a disputed number, pending versus settled activity, and history that stays stable are all easy to underestimate and expensive to retrofit. Building the capability once at the platform level means it is available to the next customer and the next program without being rebuilt each time, which shortens implementations and removes a dependency that sits directly on the critical path to launch.
Does Lucius replace our existing wallet, custody, or transaction system?
No. Your existing infrastructure remains the source of the underlying transactions and all money movement. Lucius consumes that activity and maintains the additional end customer state on top of it. Nothing about custody, settlement, or execution changes, and there is no second transaction system for your customer to operate. The preferred implementation maps Lucius onto the customer, transaction, and account objects you already expose rather than introducing a parallel model that your customer would have to learn.
Does our customer have to integrate with Lucius?
No. Lucius can operate as an invisible layer behind your existing product. Your customer continues to integrate with you, and receives end customer balances and transaction history through the experience you already provide.
How does this work with an omnibus wallet or pooled account?
That is the common case rather than the exception. One wallet, account, or custodian position holds the assets, while many end customers hold claims against it. The movements are real and visible, but nothing in the pooled position records who owns which portion of it. Lucius records those claims from your existing transaction activity and maintains a balance per end customer, so the sum of end customer balances can be reconciled against the pooled position at any point rather than reconstructed from exports when someone asks.
Can end customer balances be held in crypto and stablecoins?
Yes. Balances are maintained per asset, so a single end customer can hold several at once. The unit balance is what the end customer sees in the product; its value in a reporting currency is derived at a given price and time, so the two are never forced into one number. Stablecoin balances generally sit at par, while volatile assets move continuously, and holding units as the maintained state keeps both correct. Deposits that require confirmation are held as pending and move to settled without rewriting the history an end customer has already seen.
Do all of our programs need to use it?
No. Customer subledgering can be enabled only for the programs that require an end customer layer. Existing programs continue unchanged.
Do we have to use Lucius for accounting?
No. This capability is about end customer balances and transaction history, not your books. If a program later needs an accounting view of the same activity, it derives from state that is already being maintained — but that is an option, not a prerequisite.
Map your end customer layer
Show us your existing transaction and customer objects. We'll map the end customer layer and show how it sits behind your product.
Map your objectsOr explore the stateful ledger — Lucius's financial system of record.