SEDDK publishes a draft amendment. Within 48 hours, someone in the CFO's office wants an impact estimate: how many participants affected, how many contracts recalculated, how many downstream reports change, how long the implementation takes, and — the one everyone lies about — whether the current pipeline can absorb it or needs to be rebuilt.
Every pension firm produces a number. Almost none of those numbers survive contact with the actual change request three months later. I have watched this cycle repeat across GEV, HAYMER, and state contribution flows for years. The pattern does not change.
The Estimate Is Built From Memory, Not From the Pipeline
When a rule change lands, the analyst assigned to the impact assessment does not read the pipeline. They cannot. The pipeline is 40+ stored procedures, a handful of SSIS packages, three Python jobs someone wrote in 2019, and a reconciliation layer that only two people understand — one of whom left last year.
So the analyst does what is humanly reasonable: they ask the team. "If SEDDK changes the state contribution eligibility window from 10 years to 7 years, what breaks?" The team answers based on what they remember touching in the last 18 months. That answer is always incomplete because:
- The eligibility check is duplicated in at least three places (the daily calculation job, the monthly reporting extract, and the annual entitlement recalculation).
- One of those places uses a hardcoded threshold that was never parameterized.
- The downstream HAYMER submission has its own validation that will silently reject records the new rule accepts.
- A report used by the actuarial team joins on a derived flag that assumes the old window.
None of this is in a document. It lives in the pipeline. And nobody reads the pipeline before writing the estimate.
Why This Keeps Happening
Three structural reasons, none of them fixable by hiring more analysts:
1. Pipelines were built incrementally around regulation, not around a domain model. Each SEDDK circular for the last 15 years added a branch, a flag, a special case. There is no single "eligibility rule" — there are seventeen implementations of overlapping eligibility rules, each written for a specific circular. When a new circular arrives, you cannot scope its impact without tracing all seventeen.
2. Data lineage tools do not capture business logic. You can generate a lineage diagram that shows a column flows from table A to table B to report C. That tells you nothing about whether the calculation logic in the middle assumes the old rule. Column-level lineage is necessary and radically insufficient.
3. The people who could scope accurately are the same people delivering the current sprint. The senior engineer who actually knows the HAYMER pipeline is not available for a two-week discovery exercise every time a draft circular appears. So the estimate gets delegated to whoever is free, which means whoever knows least.
What the Wrong Estimate Actually Costs
The cost is not the estimate itself. The cost is the commitments made on top of it.
- Legal signs off on a customer communication timeline based on the estimate.
- IT budgets a two-sprint effort that turns into six.
- The board is told the change is "low impact" when in fact it touches the state contribution reconciliation, which means every affected participant needs a corrected entitlement letter.
- Operations discovers three weeks before the compliance deadline that the batch window cannot accommodate the new recalculation load.
I have seen a "minor parameter change" turn into a four-month project because the estimate did not surface that the parameter was consumed by a legacy actuarial job that runs against a snapshot table refreshed only quarterly.
What Actually Helps
Not documentation. Documentation rots faster than the pipeline changes. What helps is narrower and more boring:
-
A rule inventory that is executable, not descriptive. Every business rule — eligibility windows, contribution caps, vesting thresholds — should exist as a named function or view that the pipeline calls. If the rule is defined in one place and referenced everywhere, impact assessment becomes a grep. If it is inlined in 17 stored procedures, no assessment will ever be accurate.
-
Regression fixtures tied to regulatory scenarios. For every historical circular, keep a fixture: input data, expected output. When a new circular arrives, you can at minimum run the fixtures against a proposed change and see what moves. This does not give you the estimate, but it tells you what you did not think of.
-
A standing "pipeline archaeology" budget. Two engineer-days per month, allocated to reading and mapping a section of the pipeline nobody currently owns. Over a year this produces a real map. Without it, the map is always the one in the head of the person who last touched the code.
-
Treating the impact estimate as a deliverable with acceptance criteria. Not "here is a number," but "here are the pipeline components inspected, here are the ones deferred, here is the confidence interval." This forces the estimator to admit what they did not look at.
The Honest Version of the Estimate
The estimate every pension firm should be sending back to SEDDK or EGM during consultation periods is: "We do not know, because our pipelines encode 15 years of your prior rules and we cannot fully trace them in the consultation window you have given us." Nobody sends that. Everyone sends a number. And then, three months later, everyone is surprised by the same thing.
The pipelines are not going to document themselves. Until the rule inventory is executable and the archaeology is funded, the impact estimate will remain what it currently is: an educated guess dressed up as a plan.