Every BES operations team I've worked with has the same blind spot. The dashboards track contribution flows, new sales, fund performance, surrender rates. The alerting is built around movement. When a participant stops paying, the account falls off the operational radar within a quarter, and the assumption is that a dormant record is a stable record.
It isn't. A BES account that stops receiving contributions is not frozen — it continues to accrue state contribution entitlements on prior balances, participates in fund NAV changes daily, generates EGM reporting rows monthly, and remains subject to regulatory parameter changes that occur regardless of participant activity. The data pipeline, however, is almost always designed around contribution events as the trigger for validation logic. No contribution, no trigger, no reconciliation. The record sits there compounding drift until someone asks for it back.
Why Inactive Accounts Are Structurally Different
Active accounts self-heal. Every contribution cycle forces a series of downstream computations: state contribution accrual is checked, vesting schedules advance, fund allocations rebalance if configured, and the record touches enough tables to expose inconsistencies. If a reference table is out of date or a fund code has been retired, the contribution posting will fail loudly and someone will fix it.
Inactive accounts get none of that. Consider what actually keeps changing on a BES record that hasn't received a lira in five years:
- State contribution vesting continues advancing based on total time in the system, not contribution recency. A participant who contributed for three years and stopped is still moving through the 3/6/10-year vesting brackets.
- Fund unit valuations update daily. The account balance in lira terms changes every single business day.
- Fund lineup changes. Funds get merged, closed, or renamed. If the participant's allocation points to a fund that no longer exists under that code, nobody finds out until someone tries to transact.
- Regulatory parameters shift. Withholding rules, state contribution ceilings, and payout formulas have been revised multiple times. Each change is meant to apply forward, but the interpretation of "forward" against a dormant account is rarely tested.
- KYC and address data goes stale. The participant may have moved, changed phone numbers, or died. No contribution means no bounce-back on communication attempts if nobody is sending communications.
The Moment of Truth Is Always a Withdrawal or Transfer
The drift is invisible until it isn't. In my experience, the trigger is almost always one of three events:
- The participant requests a partial or full withdrawal after ten years.
- The participant initiates a transfer to another pension company.
- A beneficiary shows up with a death certificate.
At that moment, the system has to produce a legally defensible number: total balance, state contribution entitlement, applicable withholding, net payout. And it has to do this against a record whose reference data has been silently rotting.
I've seen cases where the fund code on an inactive account pointed to a fund that had been merged into another six years earlier. The migration script had handled active accounts and accounts with recent activity, but the cutoff logic excluded records with no contribution in the last 24 months. The unit balances were technically correct — units had been converted at the merger ratio — but the fund name and risk profile shown on the withdrawal form referenced a fund that no longer existed. The customer noticed. EGM noticed shortly after.
What Makes This Hard to Fix After the Fact
Retroactive reconciliation of an inactive book is expensive because you cannot just run today's validation logic against yesterday's data. You need to reconstruct the state of the reference tables at every point where a rule changed, apply the correct rule to the account as of that date, and forward-roll to today. For a book with hundreds of thousands of inactive participants, each carrying five to fifteen years of history, this is not a weekend job.
The things that make it particularly painful:
- Reference data is rarely versioned properly. Fund tables, parameter tables, and rule tables often carry only the current state. Historical values live in change logs, backup files, or nowhere at all.
- State contribution logic has changed enough times that applying the correct version requires knowing exactly which cohort a participant belongs to and which regulatory window each portion of their balance was earned in.
- The population is not homogeneous. An inactive book contains participants who stopped in 2015, 2018, 2021, and last month. Each cohort has a different reference-data trail.
- You cannot batch-communicate with the population to confirm anything, because their contact data is exactly the thing that has decayed most.
What Actually Works
The teams that handle this well do a few specific things:
Run inactive-account validation on the same schedule as active-account validation. If you reconcile active balances nightly, reconcile inactive balances nightly. The compute cost is real but bounded. The alternative is discovering a systemic error across 40,000 accounts on the day one of them requests a withdrawal.
Version every reference table with effective-dated rows. Fund codes, state contribution parameters, withholding rates, vesting rules. Every lookup in the payout calculation path should be a point-in-time lookup, not a current-state lookup. This is boring infrastructure work that pays for itself the first time EGM asks how a specific number was computed.
Treat inactive-account drift as a first-class risk metric. Track the percentage of inactive accounts whose reference data still resolves cleanly against current tables. Track how many carry fund codes that have been retired, addresses that have bounced, or state contribution accruals that don't match the recomputed value. These numbers should be on the same dashboard as new sales.
Simulate the withdrawal path periodically for a sample of inactive accounts. Not a full payout — just run the calculation and compare against what the account statement would say if generated today. Discrepancies here are the earliest warning that something has drifted.
The Reporting Angle
EGM reporting is the other place inactive accounts quietly cause trouble. The monthly and quarterly reports include inactive participants in aggregate figures — total assets under management, total state contribution accrued, participant counts by tenure bracket. If the underlying record state is wrong, the report is wrong, and the error compounds month over month because nobody is validating the inactive portion of the aggregate.
I've seen reconciliation exercises where the reported state contribution accrual for an inactive cohort differed from the recomputed value by several percent. Not because anyone made a bad decision, but because the accrual logic had been updated three times over a decade and the inactive population had never been reprocessed under the latest logic. Every monthly report going back years was slightly wrong in the same direction.
The Uncomfortable Conclusion
BES data quality is not a function of how well you handle contributions. It's a function of how well you handle the absence of contributions. Any pension operation can look clean when measured against the accounts that are actively transacting. The real test is whether the accounts that have been silent for eight years can produce a legally correct number the moment they wake up.
Most systems can't. And the cost of finding that out at the withdrawal counter, in front of a participant with a lawyer, is considerably higher than the cost of finding out on a Tuesday night batch run.