Fintech:
Payments / regulated finance

The client's existing ledger had been bolted onto the operational PostgreSQL instance from day one. Settlements, refunds, partner payouts, and customer balances all wrote to the same tables that served the application, with no append-only invariant and no separate audit trail. The regulator's audit identified four concrete failures: state transitions were not consistently recorded with the actor that initiated them, balance calculations depended on a join that could silently lose rows under load, retention periods were inconsistent across tables, and the recovery posture from a corrupted snapshot was untested.

Worse, the team that had built the ledger had since left. The institutional knowledge of why each shortcut existed had gone with them.

SDEN's posture on financial ledgers is explicit: append-only by construction, double-entry by accounting principle, isolated from the operational database, reconciliation automated as a daily pipeline rather than a monthly manual close, and engineered for the audit before the audit is scheduled. The migration ran in four phases, each with a controlled commit point the client could veto.

1. Phase 1: Scope and threat model

   Two weeks. We mapped every state transition the existing ledger produced, identified the seven that the regulator would treat as audit-critical, and wrote the threat model around them. Output: a typed event taxonomy, a target schema, and a risk register the client's CFO signed.

2. Phase 2: Append-only ledger build

   Eight weeks. New ledger in a separate PostgreSQL cluster with strict append-only invariants enforced at the database and the application layer, double-entry posting, immutable audit log streamed to an isolated destination, and per-tenant encryption keys for high-value accounts.

3. Phase 3: Dual-write migration

   Ten weeks. Every write to the existing ledger was shadowed to the new one, with continuous reconciliation. Discrepancies were investigated and fixed at the source, not patched. The dual-write window stayed open long enough to absorb the full reconciliation cycle the client runs monthly with its banking partners.

4. Phase 4: Cutover and audit dry-run

   Six weeks. Read paths migrated to the new ledger behind feature flags. Write cutover happened on a Saturday with the operations team in a dedicated war room. The audit dry-run ran the regulator's expected queries against the new ledger and produced the exact evidence pack the audit team asked for the following month.

The audit passed on the first attempt. The engagement was scoped to a North American financial supervisory authority's expectations, equivalent to the SEC / FINRA / OSFI bar.

Operationally, the reconciliation cycle the team had been working by hand every month became an automated daily pipeline that flags its own discrepancies. The bus factor on ledger knowledge dropped from one engineer to four. The codebase is in the client's repositories with documentation written for the next engineer who joins the team, not for the project manager who scoped the engagement.

Illustrative scenario. The figures model the engineering shape of real SDEN work, not a specific client's measured results.