Most engineers who have not worked inside a pension company assume the hardest operation in BES is the daily NAV calculation, or maybe the state contribution reconciliation. They are wrong. The hardest operation is accepting a participant who is leaving a competitor and arriving with years of accumulated balance, contribution history, vesting periods, and tax positions you did not create and cannot verify in real time.
When a transfer-in file lands in your pipeline, you are not ingesting a record. You are ingesting a claim. The previous company is asserting: this person paid X lira across Y months, earned Z lira in state contribution, has been in the system since this date, and has this much vested. EGM will eventually confirm or contradict those numbers — but eventually is not when your pipeline has to make a decision.
The Window Where You Are Operating Blind
Between the moment the transfer file arrives and the moment EGM reconciliation completes, your system has to make several irreversible decisions:
- Which contract type to map the incoming participant to
- How to age the contributions for state contribution eligibility
- Whether the entry date is the original BES entry date or the transfer date (these are not the same, and the answer changes vesting math)
- How to treat partial-year state contributions that the previous company already claimed
- What the cost basis is for the units you are about to issue against the incoming cash
None of these are negotiable. The participant expects to log in the next morning and see a balance. Operations expects the contract to be active. Compliance expects every kuruş to be accounted for. And you are making all of this happen against a payload whose author had completely different schema assumptions than you do.
What the Incoming File Silently Assumes
This is where the failures actually live. The transfer file format is standardized on paper. In practice, every company encodes its own operational history into the fields.
A few examples I have personally watched break production:
- State contribution year buckets: One company stores contributions in calendar-year buckets aligned to payment date. Another aligns to accrual date. When you sum them into your own bucketing, you get a participant who appears to have over-claimed the annual state contribution cap, and your validation rejects a legitimate transfer.
- Vesting clock semantics: The incoming "years in system" field can mean continuous BES membership, or it can mean the sum of active periods excluding suspensions. If your downstream vesting engine assumes the former, a participant with a six-month gap suddenly becomes fully vested on day one of arrival.
- Fund history granularity: Some companies send aggregate balances per fund. Others send the entire unit purchase history. Your cost basis calculation for future withdrawals depends on which you got, and the file does not always tell you.
- Suspended contract periods: A contract that was frozen due to non-payment in the previous company can arrive flagged as active. Your system happily starts charging management fees on a contract the participant believes is dormant.
- Identity drift: TCKN matches but the name field has a married name, or a transliteration variant from years of KPS updates the other company never picked up. Your name-match validator throws a soft warning that nobody reads until KYC audit.
None of these are bugs in the transfer file. They are bugs in the assumption that two pension companies, both fully compliant with EGM specifications, encode the same legal reality the same way.
The EGM Reconciliation Is Not Your Safety Net
The instinct is to say: relax, EGM will reconcile, and any discrepancy will surface. This is true but useless. EGM reconciliation tells you that the numbers do not match. It does not tell you which side is right, and it does not freeze the participant's experience while you figure it out.
By the time EGM flags a state contribution mismatch, you have already issued units, already charged fees, already shown the participant a balance, and possibly already processed a partial withdrawal request. Unwinding any of that requires manual operations work, a written explanation to the participant, and in some cases a correction filing that creates its own downstream reconciliation problem.
The correct mental model is that EGM is the eventual source of truth and your pipeline has to be defensive enough to survive the gap.
What Actually Works
After owning this ingestion surface across multiple production cycles, the patterns that hold up are not glamorous:
- Treat every incoming field as a claim, not a fact. Store the raw incoming value alongside your interpreted value, forever. When EGM disagrees three weeks later, you need to know what you were told versus what you computed.
- Refuse to collapse history on ingest. If the previous company sent monthly granularity, do not aggregate to yearly just because your schema prefers it. You will need the granularity for the first compliance question that arrives.
- Quarantine, do not reject. A file that fails validation should not bounce back to the sender. It should land in a held state where operations can adjudicate it without the participant noticing a 48-hour gap.
- Make the entry date ambiguity explicit. Every contract should carry both the original BES entry date and the contract-with-you start date as separate, queryable fields. Vesting, state contribution eligibility, and product migration rules each pick a different one of these, and the choice should be visible in code, not buried in a stored procedure.
- Reconcile against EGM before celebrating. The transfer is not complete when the file is processed. It is complete when EGM has confirmed the numbers and your internal state matches. Until then, the contract is in a provisional state with restricted operations.
The Underlying Lesson
The transfer-in problem is the clearest example I know of why pension data work is not a CRUD problem. You are not maintaining records. You are maintaining a legal position about a person's retirement, assembled from claims made by parties with different operational histories, against a regulator who will eventually adjudicate the truth.
The pipelines that survive are the ones whose authors understood, from the first line of ingestion code, that they were writing a system of disputed claims rather than a system of facts. The ones that break are the ones written by engineers who saw a CSV and assumed the columns meant what the documentation said they meant.
They almost never do.