Every corporate BES (Bireysel Emeklilik Sistemi) pipeline I've inherited in the last decade carries the same silent assumption: the employer tax ID on a group contract is a stable, permanent key. Systems join against it, dashboards group by it, EGM (Emeklilik Gözetim Merkezi) reconciliation files reference it, and vesting calculations trust it as an identity anchor.
It isn't. And when an employer disappears from the commercial register — through liquidation, merger, bankruptcy closure, or Revenue Administration deregistration — the participant accounts underneath that employer don't vanish with it. They stay. And they stay wrong.
What actually happens when the employer dissolves
A corporate BES contract has three legal actors: the pension company (emeklilik şirketi), the sponsoring employer, and the participant. When the employer is dissolved:
- The group contract is legally terminated, but individual participant accounts survive under an "individualized" status.
- The participant's vesting clock freezes at the date of employer termination — but not always cleanly, because the last contribution date and the legal dissolution date rarely match.
- The employer tax ID (VKN) may be released by the Revenue Administration and, after a retention period, reassigned to an unrelated entity.
- EGM daily transmission files continue to reference the old VKN as the historical sponsor, even though no such entity exists in TÜRMOB, MERSİS, or GİB active registries.
The account is now what I call an orphaned policy. It has a legal owner (the participant), a legal custodian (the pension company), and a historical sponsor that references a dead entity — or worse, a live entity that has nothing to do with the original contract.
Where the pipeline breaks
Most corporate pension reporting stacks were built by teams who treated the employer dimension as a slowly changing dimension type 1 or 2. Neither works here.
Type 1 pipelines overwrite employer attributes. When the VKN gets recycled and reassigned to a bakery in Konya, the participant's historical statement now shows them as an employee of that bakery. I have seen this happen. The customer service call that follows is not pleasant.
Type 2 pipelines keep history but assume the natural key remains unique across time. VKN recycling breaks this. You end up with two valid employer rows sharing the same business key across non-overlapping periods, and every join against the fact table has to be date-scoped — which nobody remembers to do until an auditor asks why the aggregated AUM by employer doesn't tie to the EGM report.
Reference data pipelines pulling from GİB or MERSİS silently drop the dissolved employer on the next refresh. The dimension row disappears. Fact rows now point to a missing foreign key. Most teams paper over this with a LEFT JOIN and a COALESCE to 'Unknown Employer', which is how millions of TRY in AUM end up bucketed under a null sponsor in the monthly board pack.
The vesting calculation trap
BES employer contributions vest on a schedule tied to the participant's tenure in the system, but the sponsoring employer's contributions have their own vesting rules under the group contract. When the employer dissolves:
- Contributions already made are subject to the vesting schedule as of dissolution date.
- Unvested employer contributions are returned to the (now non-existent) employer, which in practice means they sit in a suspense account for years.
- The participant sees a statement balance that includes funds they don't legally own yet — and may never own, because the entity that would need to release them is gone.
I worked on a reconciliation in 2019 where a participant tried to retire and access their fund. The employer had been liquidated in 2014. The unvested portion — around 42,000 TRY — was sitting in a suspense ledger that nobody had touched since the dissolution. There was no process to release it, because the process assumed the employer would exist to confirm the release.
What the EGM identity chain actually requires
EGM's daily transmission protocol expects every participant record to carry a sponsor VKN when the account originated as a corporate contract. There is no null-safe path in the schema. If you transmit without a VKN, the record is rejected. If you transmit with the historical VKN, and that VKN has been reassigned, EGM's cross-reference checks may flag the record as inconsistent — because the current registered entity behind that VKN has no BES contract on file.
The workaround most pension companies use is to maintain a private mapping table: "this VKN was the sponsor as of date X, and the entity is now dissolved." This table is almost never governed. It lives in an Excel file on someone's laptop, or in a stored procedure comment. When that person leaves, the institutional memory of which orphaned accounts belong to which dead employers goes with them.
What actually needs to change
If you own a corporate BES data model, treat the employer dimension as a first-class temporal entity with three separate concepts:
- Legal existence period — when the employer was registered with GİB and MERSİS.
- Sponsorship period — when the employer held an active group BES contract.
- VKN validity period — when that specific tax ID was assigned to that specific legal entity (which is not the same as legal existence, because of recycling).
Every participant fact row should reference the employer via a surrogate key that resolves to the correct (entity, VKN period) combination. Never join on VKN alone. Never assume the current row in the employer dimension is the correct one for a historical contribution.
And build the dissolution workflow before you need it. When an employer dissolves, someone — legal, ops, or compliance — needs to trigger a controlled state transition on every participant account tied to that sponsor: freeze vesting, snapshot the sponsor attributes, mark the account as individualized, and lock the VKN reference against future reassignment.
Most pension companies discover this workflow doesn't exist the day a participant calls to ask why their retirement statement lists a bakery as their former employer. By then, the fix is a manual reconciliation project measured in months, not a pipeline change.
The uncomfortable part
This isn't a technical debt problem. It's a modeling problem that was baked in when the first corporate BES data warehouse was designed in the mid-2000s, when the assumption that a sponsoring employer would outlive the participant seemed reasonable. It wasn't. Turkish corporate lifespans are shorter than pension horizons, and the reference data systems that anchor employer identity were never designed for the retention periods that pension products require.
If your BES reporting stack cannot answer the question "which participants are currently sponsored by an entity that no longer legally exists," you have orphaned policies. You just haven't counted them yet.