Pull up any BES participant's screen and look at the balance. That single number — the one the participant actually cares about — was assembled from at least four independent systems in the last few minutes. The policy administration system knows the contribution history. The fund accounting system knows the unit prices. The custodian's feed knows the actual holdings. The state contribution engine knows what EGM has approved and settled. Finance has its own general ledger view. Actuarial has its own reserve calculation.
Each of them will tell you, with complete confidence, what the balance is. And on any given day, at least two of them will disagree.
The interesting question is not why they disagree. They disagree because they were built at different times, by different vendors, with different rounding conventions, different cut-off times, and different definitions of what counts as "settled." That is normal. The interesting question is: when they disagree, who decides which one is right?
In most pension companies I have worked with, the honest answer is: nobody. Or more precisely, whoever escalates loudest that week.
The Four Claimants
Let me be concrete about which systems claim ownership of which slice:
- Policy administration (PAS): owns the contribution ledger. Knows every katkı payı that came in, when, from which employer, and against which participant. Treats itself as the source of truth for "what was paid."
- Fund accounting: owns unit prices and unit counts. Treats itself as the source of truth for "what the participant holds."
- State contribution engine (devlet katkısı): owns the EGM reconciliation. Knows what was claimed, what was approved, what was rejected, and what is pending the three-year vesting cliff. Treats itself as the source of truth for the state's portion.
- Finance / GL: owns the accounting entries. Treats itself as the source of truth for what the company owes the participant.
Ask any of them for a balance as of yesterday close, and they will give you a number. Sum the components differently, apply the FX or valuation cut-off at a slightly different time, and the numbers will differ by a few kuruş per participant. Multiply by two million participants and the aggregate variance is not a rounding error anymore — it is a reconciliation project.
Why the Logic Is Not the Problem
The standard reaction, especially from newer engineering leadership, is to assume the reconciliation logic is wrong. So a team is assembled, the logic is rewritten, edge cases are documented, unit tests are added. Six months later the same variances appear, sometimes in different accounts.
The logic is not the problem. I have seen reconciliation code that was mathematically correct and still produced disagreements every month-end, because the systems it was reconciling had each moved on independently. Fund accounting closed at 17:30. PAS closed at 18:00 but accepted late contributions until 23:59 with T-value date. The state contribution feed arrived the next morning with adjustments to the previous three days. Finance posted at T+1 after manual review.
Each of these behaviours is defensible in isolation. Together they guarantee that no snapshot taken at any single moment will fully agree with any other snapshot. The reconciliation engine is being asked to produce a static answer from four systems that are never simultaneously stationary.
The Missing Role: Legal Source of Record
What is missing is not a better pipeline. It is a designation. Somewhere in the architecture, one system needs to be declared the legal source of record for the final participant balance, and every other system needs to be architecturally demoted to a contributor.
This sounds obvious. It is not what most pension companies actually do. What they do is:
- The PAS vendor claims to be the source of record, because it holds the contract.
- The fund accounting vendor claims to be the source of record, because it holds the valuation.
- Finance claims to be the source of record, because the GL is what the auditor signs.
- The BI team builds a warehouse that pretends to be the source of record, because that is what the CEO's dashboard reads from.
Four systems, four claims, no arbitration. When a participant calls the çağrı merkezi disputing their balance, the agent is looking at the warehouse. When EGM asks a question, the answer comes from the state contribution engine. When the auditor asks, finance answers. Three different answers, all defensible, none authoritative.
What Designation Actually Requires
Declaring a source of record is not a diagram exercise. It has concrete architectural consequences that most organisations are unwilling to accept:
- Every other system must reconcile to it, not the other way around. If PAS is the source of record for contributions, then fund accounting's contribution figures must be forced to match PAS at end of day, even if that means posting an adjusting entry. Not the reverse.
- The source of record must publish a versioned, timestamped, immutable snapshot. Not a live query. A snapshot with a version number that finance, actuarial, and EGM reporting all consume from. When they disagree with each other, the snapshot wins.
- Late-arriving data must be handled as versioned corrections, not silent overwrites. If a contribution posts on T+2 with a T value date, the T snapshot does not change. A T+2 correction is issued explicitly, with an audit trail.
- Downstream systems lose the right to "correct" the number locally. This is the hardest political battle. Finance teams in particular are used to adjusting figures during month-end close. If they can silently adjust, there is no source of record.
Why This Rarely Happens
Because designating a source of record means telling three vendors, two internal directorates, and at least one regulator-facing team that their number is no longer authoritative. Nobody wants to be the one who says that. So the reconciliation team keeps chasing variances that are structurally impossible to eliminate, month after month, and the finding shows up in every internal audit report under a slightly different heading.
The fix is not technical. The pipeline can be rebuilt in Spark, Snowflake, or on a napkin — the variances will persist until someone with enough authority signs a document that says: this system, this table, this column, is the balance. Everything else is a view.
Until that document exists, the reconciliation team is not solving a data problem. They are absorbing the cost of an unmade decision.