The Reconciliation FilesLife & PensionsAS/400 · DB2
FILE 01

The Ghost in the Stored Procedure

Case Summary
Legacy core
AS/400 + DB2, 30+ years in production
Procedures parsed & mapped
~400
Change history reconstructed
3 weeks
Auditor walkthrough
6 yrs of history, 2 sittings
Migration scope
Legacy data + opening balances only
Legacy data availability
Guaranteed under SLA

The Number That Didn't Tie Out

I found it on a Tuesday, three weeks before our Swiss Solvency Test submission. A reconciliation that should have tied out to the rappen didn't. Eleven basis points off, on a life annuity book carrying just over a billion francs in reserves.

Eleven basis points sounds small — until you multiply it across every quarter for six years, and realise you can no longer tell your auditors, your board, or FINMA which of those six years of numbers was ever actually correct.

That's the moment a migration programme stops being an IT project and becomes a personal one. My signature goes on the technical provisions. Not the vendor's. Not the integrator's. Mine.

Data Isn't the Problem. The Logic Is.

Here's what nobody tells you about a forty-year-old policy administration system running on AS/400 and DB2: the data was never just data. Every net present value on our in-force annuity ledger was the output of a stored procedure — logic written by people who had left the industry before some of my analysts were born.

We traced our eleven basis points to a single routine our own documentation still called Stored_Procedure_01: an NPV calculation on a 360/365 day-count basis. The routine actually running in production hadn't been that one for four years. Somewhere along the way, a successor — cosmetically similar, functionally different — had taken its place, on an actual/365 basis.

On its own, that's a rounding footnote. What kept me up at night was the arithmetic that followed: if one procedure had drifted silently, how many of the other roughly four hundred had done the same, at some unknown point, in some unknown way? Every reserve figure, every fulfilment cash flow, every number carrying my name was built on logic I could no longer prove was stable.

$ diff --history annuity_npv_calc
>>> resolving procedure lineage…
>>> last documented version — FY19 spec
Stored_Procedure_01
NPV · 360/365 day-count convention · documented
>>> running in production — FY23 extract
Stored_Procedure_01a
NPV · actual/365 day-count convention
⚠ no change ticket · no log entry · no sign-off
>>> delta: 4 years running, unreconciled

What We Tried First

We did what most teams do. We brought two retired AS/400 programmers out of consulting retirement, at a rate that made our CFO wince, and had them read RPG and embedded SQL procedure by procedure against our last complete documentation. Six weeks in, they had cleared forty-one of roughly four hundred procedures. At that pace, we would have finished sometime after our next SST cycle. Possibly the one after that.

Meanwhile, the actual migration — the one meant to get us off this platform for good — sat on hold. Nobody was going to sign off on moving to a new core system while the source of truth underneath the old one was still, strictly speaking, unknown.

Bringing In an AI Managed Service

What changed things was bringing in an AI Managed Service to sit across the AS/400 and DB2 estate — not to extract it once and walk away, but to treat it as a living system of record. Every stored procedure, every table, every batch job was parsed, versioned, and diffed against every prior version we still had, back as far as our archives went.

Within three weeks, we had a reconstructed change history for the procedures behind our entire annuity book — including the exact point Stored_Procedure_01a quietly replaced Stored_Procedure_01, and which reporting periods had been calculated under each.

A Regulatory Picture I Could Finally Defend

That reconstruction was the first thing that let me sleep. For any historical date I named, it showed precisely which version of which procedure had produced which number — and could reproduce it. Not an estimate. A defensible, repeatable answer to "how was this calculated, and is it still calculated the same way today."

We walked our external auditors through six years of restated confidence in two sittings, instead of the six months we had budgeted. FINMA received a submission where every technical provision traced back to specific, documented calculation logic — current and historical, on demand.

Data I Could Finally Ask Questions Of

The second benefit surprised me, because I hadn't asked for it. Once the calculation logic was untangled, the underlying policyholder data — decades of it, sitting in flat files and green-screen extracts — was restructured into something a modern analytics layer could actually query in plain language.

Our product and distribution teams, who had spent years working from spreadsheets built off quarterly data dumps, could finally ask real questions and trust the answers: which annuity cohorts were lapsing early, which client segments were genuinely profitable once the correct NPV logic replaced the approximate one everyone had been planning against. Two segments we had priced as marginal for years turned out to be comfortably profitable. One larger segment we had assumed was healthy wasn't.

You don't get findings like that from a migration project. You get them from finally being able to trust — and interrogate — thirty years of your own data.

Why We Could Finally Go Greenfield

Here is the part that actually unblocked the migration. Once the AI Managed Service stood behind the legacy estate — reconciling it, explaining it, keeping the regulatory picture correct on an ongoing basis, under an SLA guaranteeing that legacy data would stay available and correctly interpretable for as long as we needed it — my architecture team stopped trying to migrate forty years of accumulated logic. We didn't need to.

We migrated exactly two things: the legacy data itself, and the opening balances the new platform needed to go live. Every workaround, every undocumented patch, every "temporary" fix someone made permanent in 2003, stayed exactly where it was — reconciled, explained, and out of scope.

That freed my team to design the target architecture we actually wanted, instead of a faithful, over-engineered replica of forty years of technical debt. No shadow logic to reverse-engineer. No stored procedures to reimplement "as-is" when nobody could prove what "as-is" ever meant. Just a clean core, opening balances that tied out on day one, and a legacy environment sitting quietly in the background — answerable under SLA, if anyone ever needed to ask it another question.

It was never really a migration problem. It was a "do we actually know what our own numbers mean" problem. I signed that migration off in the end — the full platform, not a patch. My name is on it. But it's the only signature in six years I've put on a number I could actually defend, line by line, back to the day the logic changed. Once that was solved, the rest was just engineering.

~400Stored procedures parsed & mapped
3 wksChange history reconstructed
6 yrsAuditor walkthrough — 2 sittings
0Restatements filed