Every pension company in Turkey runs the same disclosure machinery: annual participant statements, fee change notifications, fund performance reports, allocation confirmations, tax certificates. The regulation is clear on what must be sent and when. What the regulation does not spell out — and what almost no firm has built for — is the ability to reconstruct, three years later, exactly what a specific participant saw on a specific date, tied to the specific legal or operational event that triggered the communication.
This is the gap that turns into a problem the moment a participant files a complaint with SEDDK or opens a case at the arbitration commission.
The typical BES disclosure stack, and where it breaks
In most firms I've worked with or reviewed, the disclosure layer looks something like this:
- A policy administration system holds the participant's current state (fund allocations, accumulated units, fee schedule).
- A batch job runs nightly, monthly, or annually to generate PDFs, emails, or SMS payloads.
- A communication gateway (an in-house dispatcher or a third-party like İleti Merkezi, RelateLabs, or a bank SMS provider) sends the message.
- A log table records: participant ID, channel, timestamp, delivery status.
That is the entire audit trail at most companies. Notice what is missing:
- The content of what was sent is often not stored — only the fact that something was sent.
- The input data snapshot that produced the content is overwritten every night by the next batch.
- The regulatory or contractual trigger (a fee amendment approved on a specific board date, a fund merger, a legal notification requirement under a specific SEDDK circular) is nowhere linked to the dispatch record.
- The template version in use at that moment is not pinned.
So when a participant says "three years ago you told me my TEFAS-linked fund had a 1.75% management fee and now I'm seeing you deducted 1.95%," the firm cannot reproduce the original document. It can only reproduce what today's data and today's template would generate for that historical date — which is not the same thing, and any auditor knows it.
The three reconstructions you actually need
A disclosure layer that can survive a dispute has to answer three questions independently:
- What did we send? The exact rendered artifact — PDF, HTML email body, SMS text — byte-for-byte as delivered.
- What data did we base it on? The snapshot of the participant's fund positions, fee schedule, contribution history, and any calculated values at the moment of generation.
- Why did we send it? The triggering event — annual cycle, fee amendment, fund closure, participant-initiated allocation change, regulatory circular — with a reference to the governing rule or approval.
Most firms can partially answer question 1 if they stored the PDF. Very few can answer question 2 without a forensic database restore. Almost none can answer question 3 in structured form.
Why the pipeline was never designed for this
Data engineering teams in insurance and pension companies inherit ETL pipelines optimized for one job: get the current state right for tomorrow's operations. Historical accuracy is treated as a reporting problem, not a communication problem. The disclosure batch reads from the same warehouse tables that get updated the next day, and the communication team assumes the warehouse is the source of truth forever.
It isn't. A fund NAV correction posted two weeks later silently changes what yesterday's statement would look like if regenerated. A fee schedule migration overwrites the old rates. A participant merge (which happens after a TC kimlik correction or a duplicate cleanup) can destroy the linkage between the old ID and the old communications.
I have seen cases where a firm defending itself in an arbitration proceeding had to physically restore a database backup from two years prior, spin it up on a parallel server, and manually regenerate a statement to prove what was communicated. That process took three weeks and cost more than the disputed amount. It is not a scalable defense strategy.
What a defensible disclosure layer looks like
The fix is architectural, not procedural. Sending more emails to a compliance folder does not solve it. The pattern that works:
- Immutable dispatch records. Every communication generates a record that includes the rendered artifact (or a content hash pointing to object storage), the input data snapshot as JSON or Parquet, the template version identifier, and the trigger event reference. Written once, never updated.
- Event-sourced triggers. Fee changes, fund actions, and regulatory circulars are modeled as first-class events with their own approval trail and effective dates. Every dispatch links to the event that caused it.
- Snapshot storage separated from operational storage. The disclosure snapshot lives in an append-only store — object storage with versioning, or a dedicated audit database — not in the warehouse that gets rebuilt.
- Reproducibility as a test, not a hope. A monthly job that picks random historical dispatches and re-renders them from stored snapshots to confirm byte-equivalence. If the test fails, you know before the regulator asks.
The uncomfortable business case
CFOs do not fund audit infrastructure until it hurts. The honest way to frame this internally is not "we should improve our compliance posture" but rather: what is the cost of one week of legal team time, plus one database restore engineering effort, plus one reputational incident, versus the cost of adding a snapshot layer to the disclosure pipeline?
In every firm I've helped with this calculation, the snapshot layer costs less than two disputed cases. Turkish pension participants are getting more sophisticated about their statements, and social media amplifies individual complaints into regulatory attention faster than the old paper-mail cycle ever allowed. The dispute volume is going up, not down.
Where to start if you're behind
Do not try to backfill history you don't have. Draw the line at today and commit that from this quarter forward, every dispatch is provable. Then:
- Inventory every communication type your BES operations send. Most firms discover they have between 20 and 40 distinct templates, half of them undocumented.
- For each one, identify the trigger, the data inputs, and the current storage of the rendered output.
- Add snapshot capture at the point of generation, not after dispatch. Capturing after dispatch means you're already reading potentially-mutated data.
- Version your templates in git with the same discipline as application code, and pin the template hash into the dispatch record.
The disclosure layer is not a marketing channel. It is a regulated evidentiary system that happens to use email and SMS. Firms that keep treating it as the former will keep discovering, one dispute at a time, that they built a machine for sending and forgot to build the machine for proving.