Every BES pipeline I've inherited or audited over the last decade has the same architectural flaw hiding somewhere in it: premium holidays are modeled as nothing. No row. No contribution event. A gap between the last successful collection and the next one. On a Kibana dashboard it looks clean. In the reconciliation report at month-end, it's the reason your fund unit balance doesn't tie to EGM.
This is the single most misunderstood state in the entire contribution lifecycle, and it's the one nobody writes about.
What a Premium Holiday Actually Is
Under BES regulation, a katılımcı who suspends contributions — whether voluntarily, through employer-side payroll pause, or because a direct debit failed for N consecutive cycles — does not exit the contract. The policy stays legally active. Which means:
- Fund units remain allocated and continue to be exposed to market movement
- Devlet katkısı entitlement clock keeps ticking toward vesting thresholds (3, 6, 10 years)
- Sistemde kalış süresi accrues toward retirement eligibility (emeklilik hakkı)
- Fon işletim gider kesintisi continues to be deducted from the participant's balance
- EGM daily reporting still requires the policy to appear in the active portfolio snapshot
- The employer-sponsored variant (İşveren Grup BES) has its own vesting schedule that keeps running
A premium holiday is not the absence of a contribution. It's the presence of a contract in a specific sub-state. Those are architecturally different things.
Why Pipelines Get This Wrong
Most contribution pipelines are built around an event-sourced model where the primary fact is the collection event: a debit hit the account, funds were allocated, units were purchased at that day's pay. When there's no event, there's no row. The pipeline reasons about the participant by looking at the most recent event and inferring state.
This works fine for happy-path collections. It falls apart the moment you ask questions like:
- How many participants are currently on premium holiday as of yesterday's close?
- What is the total AUM exposure of suspended-but-active policies?
- Which suspended policies just crossed a devlet katkısı vesting threshold this week?
- For the EGM daily file, which policies must be reported as active with zero contribution this cycle?
If your only source of truth is the collection event stream, none of these questions have a clean answer. You end up with downstream teams writing increasingly baroque LEFT JOINs against the policy master to reconstruct a state that should have been a first-class fact in the pipeline.
The Reconciliation Failures Nobody Talks About
Here are the failure modes I've personally debugged, more than once:
Fund unit drift. Suspended policies still have units. Those units are revalued daily. If the pipeline treats a suspended policy as "inactive" and drops it from the daily valuation job, the fund NAV reconciliation against the portföy yönetim şirketi will be off by exactly the sum of suspended balances. This gets caught eventually — usually by the fund side, not yours — and the fix is always retroactive.
Devlet katkısı miscalculation. A participant on premium holiday for eight months, then contributing again, crosses a vesting threshold based on total sistemde kalış süresi, not contributing months. If your pipeline computes eligibility from the sum of contribution events, you will under-report entitlement. The Hazine reconciliation will flag it. Fixing it requires backfilling months of state.
EGM daily file gaps. EGM expects every active policy in the daily snapshot. A pipeline that emits only policies with recent activity will silently drop suspended ones. You won't notice until EGM sends the mismatch report, and by then you have a compliance conversation, not a data conversation.
Kesinti backlog. Fon işletim gider kesintisi continues on suspended balances. If the deduction job keys off recent contributions rather than active policy state, suspended participants stop getting charged. When someone eventually notices, you owe a mass retroactive adjustment across thousands of policies, and every one of those adjustments has to be explained to the participant.
The Correct Architecture
The fix is not complicated conceptually. It's just rarely implemented because premium holiday feels like an edge case until it isn't.
Model the participant's contribution state as a first-class, continuously-valued dimension — not as something you derive from event presence. Concretely:
- Emit a daily (or at minimum, on-change) state record for every active policy, regardless of whether a contribution event occurred
- The state record carries the sub-status:
contributing,premium_holiday_voluntary,premium_holiday_failed_debit,employer_suspended, etc. - Fund exposure, vesting clocks, and reporting obligations key off the state record, not off the contribution event stream
- The contribution event stream remains what it is: a log of things that actually happened financially
This is essentially the difference between an event log and a slowly-changing dimension. Both need to exist. Pipelines that only maintain the first will keep discovering the same class of bug forever.
Why This Stays Undiscussed
Premium holiday failures don't show up as loud outages. They show up as month-end reconciliation deltas that someone patches manually, or as a Hazine query six months later, or as a fund NAV variance that gets absorbed into a rounding tolerance until it doesn't. Each individual failure is small and explainable. The pattern only becomes visible if you've owned the pipeline long enough to see the same shape of ticket three or four times.
Which is why I'll say it plainly: if you're building or auditing a BES contribution pipeline and you cannot answer, in one query, which policies are on premium holiday right now and what is their aggregate fund exposure, your pipeline has this bug. It just hasn't cost you enough yet for anyone to prioritize the fix.