After ten years of building, reviewing, and occasionally rebuilding BES (Bireysel Emeklilik Sistemi) data pipelines for pension companies and their insurance-group parents, I have stopped believing in the myth of the single correct output. Two pipelines, fed the same raw contribution files, the same fund NAVs, the same state contribution (devlet katkısı) records, can produce participant balances that differ by kuruş — sometimes by more — and both can pass an EGM audit. Neither is wrong. They just resolved different regulatory ambiguities in different ways.
That is the part nobody in the vendor deck warns you about.
The regulation is not the specification
BES-related regulation — the Bireysel Emeklilik Tasarruf ve Yatırım Sistemi Kanunu, the associated yönetmelikler, and EGM's periodic communiqués — tells you what must happen. It rarely tells you exactly when, in which order, or against which reference value. A working pipeline has to answer questions the text leaves open:
- When a contribution arrives on a non-business day, does it earn units at T+0 NAV, T+1 NAV, or the next fund valuation date? The regulation says "the applicable fund price." Fine. Which one is applicable is a design decision.
- If a participant's payroll deduction and their voluntary top-up arrive in the same batch file, is state contribution calculated on the combined amount or per-source? Both readings survive scrutiny.
- When a fund change (fon dağılım değişikliği) request lands at 15:59:30 and the cutoff is 16:00, does the request apply to today's NAV or tomorrow's? Your pipeline picked one. Did anyone write down why?
- When a participant exits mid-month, is state contribution accrual pro-rated by calendar days, business days, or contribution-weighted days?
Each of these has a defensible answer. Each has at least one other defensible answer. And if two pension companies picked differently in 2015 and never revisited it, their participant balances on identical hypothetical data will diverge, permanently.
Where the divergence actually comes from
In the reviews I have done, the numerical differences almost never come from bugs. Bugs get caught. The differences come from three sources, all interpretive:
Rounding boundaries. The regulation says balances are calculated to a certain precision. It does not always say at which step you round. Round at unit purchase, round at daily valuation, round at reporting — three different balances, all lawful. A pipeline that rounds units to 6 decimals at purchase and one that carries 10 decimals until reporting will disagree by the third month, and the gap widens.
Effective date semantics. "İşlem tarihi" versus "valör tarihi" versus "muhasebe tarihi" are not synonyms, but they get treated as such in requirements documents. When contribution posting, fund allocation, and state contribution accrual each pick a different one of these three dates as their anchor, you get a pipeline that is internally consistent and externally different from a peer's.
Order of operations on the same day. If a participant contributes, changes fund allocation, and receives state contribution posting all on the same value date, the sequence matters. Contribution → allocation → devlet katkısı gives a different unit count than devlet katkısı → contribution → allocation. Regulation is silent on the ordering. Your pipeline is not silent — it just doesn't tell anyone what it decided.
Why this is worse than a bug
A bug is discoverable. It produces something obviously wrong: a negative balance, a state contribution that exceeds the legal cap, a fund unit count that doesn't match the custodian. Reconciliation catches it. Someone opens a JIRA ticket. It gets fixed.
An interpretive choice produces something perfectly reasonable. Reconciliation passes because your custodian feed and your pipeline agree — they were built by the same team, using the same assumptions. EGM's periodic reporting passes because the aggregate numbers are internally coherent. Everything looks fine until:
- A participant transfers to another pension company (aktarım), and the receiving company's pipeline recalculates the entitlement using its own interpretation. The numbers don't match. Now someone has to explain the delta, and "we round differently" is not a satisfying answer to a customer who lost 47 TL.
- EGM issues a clarifying communiqué that names one interpretation as the correct one. If you picked the other one, you now have historical balances to restate — sometimes going back years.
- An internal auditor from the insurance-group parent asks why your BES balances reconcile to the custodian but not to a naive recalculation from raw contribution files. You cannot answer without the design memo that was never written.
The documentation gap is the actual risk
In every BES pipeline review I have done, the code is fine. The SQL is fine. The batch orchestration is fine. What is missing, consistently, is a document that says: "At this step, the regulation permits interpretations A, B, and C. We chose B. Here is why. Here is the person who approved it. Here is the date."
Without that document, three things happen over a decade:
- The original architects leave. The interpretation is now embedded only in code, and only implicitly.
- A new requirement — say, a change to devlet katkısı rates — gets implemented by someone who has to reverse-engineer the original interpretation from behavior. They guess wrong half the time.
- When EGM asks why balance X is what it is, the answer is "that is what the system produced," which is not an answer.
What to actually do
If you own or oversee a BES pipeline, the useful exercise is not another code review. It is an interpretation audit. Sit down with the people who wrote the pipeline (if they are still around) and the current business owners, and for each of the following, force a written answer:
- Which date field drives contribution recognition, and against which NAV?
- What is the exact order of operations when multiple events land on the same value date?
- Where does rounding occur, at what precision, and using which rounding mode?
- How is state contribution accrual calculated on partial periods?
- What happens to a fund change request at the cutoff boundary — inclusive or exclusive?
- When the custodian's unit count and the pipeline's unit count disagree by less than a threshold, which one wins?
For each answer, cite the regulatory text you are relying on, note the alternative interpretations you rejected, and record who signed off. This document is not for EGM. It is for the version of your team that will exist five years from now, when someone asks why participant 1057382's balance is what it is.
The pipeline that survives a decade of regulatory drift is not the one with the cleanest code. It is the one whose interpretive choices are legible enough to defend, and specific enough to change when the regulation finally catches up.