Challenge · 01
The regulator forbade modifying legacy systems that had no audit hooks.
Resolution
One-way, read-only CDC taps on every source — the source database never sees a transaction from the lineage layer.
← All case files
Case / 2025.02 · Public Sector
Cold Trail
Federated claims lineage across a legacy stack
End-to-end traceability for a benefits agency whose claims lived across four legacy systems — without modifying any of them.
/Gov-AsiaPac/ · Shipped
4M+ claims traceable end to end · audit cycle compressed from 6 weeks to 4 days.
/ 01 · Stakes
What was on the line.
A public-sector agency couldn’t trace a benefits claim through its stack. The data lived across four legacy systems that had each been “the source of truth” over 20 years: a z/OS mainframe at intake, an Oracle eligibility engine, a Java EE adjudication service and a .NET payout ledger from a stalled 2016 modernisation.
Audit cycles took 6 weeks of analyst archaeology per quarter. New data-residency rules raised the stakes: every observation about a claim had to be provably captured, attributed and stored inside the jurisdiction.
/ 02 · Approach
How we built it, in five moves.
- 01
Read-only CDC taps on each legacy system
Source modification was off the table. Debezium reads the Oracle, Java EE and .NET sides; a custom z/OS journal reader taps the mainframe without writing back.
- 02
Normalizer into a shared event vocabulary
Four systems’ status codes and claim IDs reduce to one vocabulary. Disagreements are preserved, not flattened — conflicts surface for the auditor to resolve.
- 03
Hash-chained ledger of every observation
Append-only Postgres, each row signed and chained. The 4M+ claim backfill ran with idempotency keys so it was restartable and replay-identical.
- 04
Daily notary anchor
Once a day the ledger publishes its head hash to an external timestamp authority, making any tampering provable even if the whole database is rewritten.
- 05
Trace UI plus regulator export
Caseworkers see a claim’s full trail across four systems in one view; auditors export the regulator’s prescribed format directly. Six weeks of archaeology becomes a query.
/ 03 · Challenges
What got in the way, and how we resolved it.
Challenge · 02
A data-residency mandate: nothing could leave the jurisdiction, including supporting infrastructure.
Resolution
The entire pipeline runs on in-jurisdiction Kubernetes with no external SaaS; per-tenant isolation between ministries.
Challenge · 03
Tampering had to be detectable, not just discouraged — a malicious admin was in scope.
Resolution
A hash chain per claim plus the daily external notary anchor: any altered row breaks the chain at the next read.
/ 04 · Outcomes
What changed, in numbers.
- 4M+
- Claims indexed
- 4d
- Audit cycle (was 6 weeks)
- 0
- Compliance findings, year 1
- 2
- Ministries live
- End-to-end traceability for 4M+ claims, queryable in seconds
- Audit cycle compressed from 6 weeks of analyst archaeology to 4 days
- Zero compliance findings in the subsequent audit year
- Two ministries live as separate tenants on a shared platform
/ 05 · Evidence
Live across two ministries in the Asia-Pacific region. Notary anchor audited quarterly by the client’s GRC team. Reference available on request under NDA.
- Debezium CDC
- Custom z/OS journal reader
- PostgreSQL hash-chained ledger
- In-jurisdiction Kubernetes
- External timestamp authority
