Inside the Book of Record
By Dorra Bouchiha
The book of record is the source of truth for what happened to a client's money. Trades, transfers, and deposits flow into it. Balances, positions, statements, and tax slips derive from it.
We've spent the last two years building it out, and the work continues. This post is about the shape it's taking.
The five jobs of a Book of Record
It helps to start with what the book of record has to do:
- Decide — can this client place this order, transfer that money, pay this bill, right now?
- Record — what happened, in what order, with what timestamps?
- Book — what's the official double-entry accounting?
- Track & Calculate — given everything that happened, what does the client hold, what's it worth, what's the return?
- Show — what does the client see in the app, on a statement, in a tax slip?
Different jobs have different constraints. Decide has to be synchronous and right under contention. Record needs a complete and replayable history. For Track & Calculate, the test is whether you can recompute positions from a long history and land on the same number every time. And Show has to be fast enough that the app feels alive. A single system trying to do all five jobs the same way wouldn't be good at any of them.
That insight shaped the architecture and why we built the book of record as multiple systems.
One funnel in: the write path
We built a single validated funnel for every piece of financial intent entering the book of record. We call it the Financial Activity Model.
Whether a client is buying a stock, depositing cash, getting paid a dividend, or paying a bill, the event lands as an activity in the financial activity model first. It gives us two key properties:
- Idempotency. Every event has a stable identifier. The same event submitted twice is a no-op; the same identifier with a different payload is a validation error.
- Lifecycle authority. The financial activity model is the source of truth for the state of an activity — pending, settled, reversed. Domain services decide if something should happen. It records what happened.
The authoritative store: the ledger
Every dollar that moves at Wealthsimple is recorded in our general ledger.
The ledger has one responsibility: accounting. It records what happened in double-entry form, append-only, with reversal symmetry (corrections are compensating entries, never edits). The history is the truth. That property is what makes a tax slip reconcile cleanly back to the underlying records, and what lets auditors and the business itself reason about money with confidence.
Wealthsimple owns its ledger. That's a deliberate choice.
- The books are ours. Activities arrive in real time, and state transitions in the activity lifecycle drive ledger postings. Reconciliation runs against records we own.
- The audit trail is ours. We're regulated by the Canadian Investment Regulatory Organization (CIRO). Clients trust their statements and tax slips to be accurate, and we don't take that lightly.
- The roadmap is ours. The ledger doesn't slow our product velocity and innovation: Norbert Gambit, dual-listed securities, a new asset class, a new way to move money. If we can model it, we can ship it.
The Financial Activity Model exists so the ledger doesn't need to validate, deduplicate, or interpret inputs: by the time an event lands, it's already canonical. Instead of making the ledger smarter, we made the inputs to the ledger smarter. The read path consumes the same canonical event stream, and continuously reconciles against the ledger, in service of a different job: not recording, but showing.
A separate path out: the read path
The write side has one job: record what happened, durably, and without duplication. The read side has another: compute what we show in the app: balances, positions, book value, returns, net deposits. So we built them apart.
Three large boxes:
- The Financial Calculation Platform: a streaming pipeline that consumes the canonical activity stream and continuously materializes everything we'd want to ask about an account.
- The materialized view of the computed metrics, shaped to serve client-facing reads.
- Client surfaces: what the client actually touches. The app, the activity feed, statements and tax slips.
The Financial Activity Model is the single write entry. The ledger holds the canonical record. The read components are how the client experience is derived.
Write-side and read-side splits are a well-understood pattern in software engineering. We hold to it: no growing the write path to answer read-path questions, no folding read-time correctness into write-time decisioning.
Holding the Bar
As Wealthsimple grows, the book of record is built to grow with it. Naive ambition isn't only about taking on hard new things. Sometimes it's refusing the easy local shortcut as the system grows.
When the markets open and tens of thousands of trades, transfers, and deposits land in the same minute, and every one is reflected in the balance the client sees, the book of record is doing its job.
We'll share more as the work continues.
Interested in working at Wealthsimple? Check out the open roles on our team today.