Fintech
Payments / regulated finance
A growing North American fintech with a regulator on the doorstep needed its payments ledger to survive an audit it could not fail. SDEN engineered the migration in seven months, with no customer-visible downtime and a posture that passed the audit on the first attempt.
- Client
- PLACEHOLDER: anonymized Series B fintech challenger
- Sector
- Payments / regulated finance
- Duration
- PLACEHOLDER: approximately seven months end-to-end
The premise
Most fintech reconciliation failures are not exotic. They are the compound effect of a payments ledger that started as a few tables in the operational database, was extended every time a new partner integration shipped, and was never re-architected before the volume made the shortcuts expensive. By the time the regulator asks for an auditable transaction trail, the work to produce one has become a multi-quarter rebuild, and the rebuild has to happen while the product keeps running.
This is the engagement class SDEN is built for. The case below is a composite of a real client engagement, presented with PLACEHOLDER markers on every identifying detail and quantified figure until the client signs off on a published version. The engineering shape is real; the numbers will be replaced with audited figures before final publication.
An operational ledger pretending to be a payments ledger
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. PLACEHOLDER: confirm the team transition timeline with the client before publishing externally.
Append-only ledger, dual-write migration, no downtime
SDEN's posture on financial ledgers is explicit: append-only by construction, double-entry by accounting principle, isolated from the operational database, 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.
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.
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.
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.
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.
Passed the audit on the first attempt
The audit passed on the first attempt. PLACEHOLDER: confirm the audit body and the regulatory framework before publishing externally. The engagement was scoped to a North American financial supervisory authority's expectations equivalent to SEC / FINRA / OSFI.
Operationally, the reconciliation cycle the team had been running manually every month became an automated daily process. 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.
0 PLACEHOLDER
customer-visible downtime during cutover
Pass PLACEHOLDER
regulator audit, first attempt
1 → 4 PLACEHOLDER
engineers with full ledger context
Continue
More from SDEN: fintech
Got a project worth building?
Tell us about your project. We work with a limited number of clients at a time, and we'll get back to you within 24 working hours with a first engineer's read, no commitment.