Rebuilding a payments ledger for a Series A fintech

The problem

A Series A fintech processing $4M/week through a B2B payments API was running reconciliation as a 14-hour nightly batch. When it failed, the on-call engineer spent the next morning rebuilding state from CSV exports. By the time we engaged, three of the four engineers had been paged every weekend for a month.

The original ledger was a series of denormalized tables written from the request path. Money moved in and out through stored procedures that knew about merchants, fees, and FX — but no single source of truth for “what happened to this dollar.” Every reconciliation was archaeology.

The work

We replaced the request-path writes with an append-only event log: every state change in the system became a row in a single ledger_events table, keyed by a ULID and grouped into transfers. Double-entry accounting was enforced at the schema level — every transfer had matching debit and credit rows in the same transaction.

The reconciler moved from a batch job to a streaming consumer on Kafka. Each event was projected into the merchant’s view within 200ms, and the daily close was the trivial roll-up of yesterday’s events. We migrated six months of history by replaying the original logs through the new schema in parallel with the legacy system, comparing deltas nightly until they matched.

The outcome

Reconciliation time dropped from 14 hours to 11 minutes. The on-call rotation went from three pages per weekend to one every six weeks — and the one page turned out to be a misconfigured Slack alert. The ledger query layer handles 42ms p99 against 60M rows, and the merchant dashboard reads directly from the projected view with no cache.

Two engineers who’d been talking about leaving to escape the on-call burden both stayed. That’s the metric we don’t put on the slide.