Every few months in a Turkish insurer's operations room, someone asks a question that sounds simple and isn't: "What is the customer's actual withdrawable balance?"
If that customer has taken a policy loan against their BES accumulation or a life savings product, the answer requires stitching together at least three systems that were never designed to agree with each other in real time. And the pipeline you built to feed the regulatory reports, the CRM dashboards, and the actuarial models almost certainly does not stitch them. It just picks whichever number was written last and calls it truth.
This is the policy loan data problem, and it is one of the most persistent silent-failure patterns I have seen in insurance data architecture.
Why the loan is structurally invisible
A policy loan against a BES or life savings balance is not a loan in the retail-banking sense. It is a collateralized draw against the policyholder's own accumulated units, priced against the fund NAV at draw time, accruing interest on a schedule that is often decoupled from both the fund's daily valuation and the general ledger's month-end close.
That creates three ledgers that all describe the same economic position from different angles:
- The pension/savings ledger tracks units, NAV, contributions, and fund allocation. It usually does not know a loan exists. The units are still there.
- The loan ledger tracks principal, accrued interest, and repayments. It usually does not know which units are collateralizing what.
- The GL sees a receivable and an offsetting liability movement, aggregated, often without the policy-level granularity to reverse-engineer anything.
Each system is internally consistent. The problem is that the collateral position — the encumbrance on specific units at a specific NAV — is not a first-class entity in any of them. It exists implicitly, as a difference that has to be computed on demand.
And because it has to be computed on demand, most reporting pipelines don't compute it. They report the pension balance. They report the loan balance. They present both on the same customer screen. Nobody notices the arithmetic doesn't close until someone tries to actually move money.
The reconciliation that only happens under duress
The moment of truth is almost always a withdrawal, a transfer to another provider (BES aktarım), a surrender, or a death claim. That is when operations has to answer: how much is actually payable?
At that point, someone opens a ticket, someone pulls three extracts, someone runs a spreadsheet, and someone — usually a senior operations person who has been there long enough to remember the last time this happened — resolves the discrepancy manually. If the customer is patient, this takes days. If the customer is a lawyer, this takes weeks and a written explanation.
What is happening in that spreadsheet is a reconciliation that the data model should have been producing continuously. The pipeline treated the loan as a state you check when asked, rather than a sequence of events that changes the meaning of every downstream balance from the moment of origination onward.
This is the shadow ledger. It exists. It is materially correct. It just lives in the heads of operations staff and gets serialized to Excel on demand.
Why bolting on a new report doesn't fix it
The intuitive response — and I have watched this response fail multiple times — is to commission a "loan exposure report" that joins the loan system to the pension system and shows the net position.
This fails for a specific reason: the join is temporal, and the systems don't share a temporal axis.
- The pension ledger is valued daily at fund NAV close.
- The loan ledger accrues interest on its own calendar, often with a different day-count convention.
- Repayments may be posted with backdated effective dates when they come through payroll deduction cycles.
- Origination itself may have a value date that lags the request date by two or three business days while units are notionally "pledged."
A point-in-time join of these tables produces a number that is defensible for exactly one instant and wrong shortly thereafter. You can't audit it because next week it reconciles to a different truth. You can't reproduce a historical figure because none of the underlying tables were designed to answer "what did this look like on March 14?"
The rearchitecture: loan lifecycle as first-class events
The fix is not a report. It is an event model where the loan's lifecycle is decomposed into explicit state transitions, each with its own effective date, posting date, and versionable payload:
- Origination event — captures pledged units, NAV at pledge, principal disbursed, accrual schedule, effective date, and the specific fund allocation the encumbrance applies to.
- Accrual event — emitted on the loan's own schedule, referencing the origination event and producing an interest posting with its own effective date.
- Revaluation event — emitted whenever the underlying NAV changes materially enough to change the collateral coverage ratio. This is the event that reporting pipelines almost never produce, and it is the one that makes withdrawable-balance queries answerable.
- Repayment event — with source (payroll, direct debit, lump sum), effective date, and allocation between principal and accrued interest.
- Settlement event — terminal, whether via full repayment, offset against surrender, or claim.
Each of these events lands in an append-only store keyed by policy and ordered by effective date. Balances at any point in time — pension, loan, withdrawable, encumbered — become deterministic functions of the event stream up to that timestamp.
The practical consequences:
- The withdrawable-balance question becomes a query, not a ticket.
- BES transfer requests can be priced before the customer is on the phone rather than during the phone call.
- Actuarial and risk teams can reconstruct exposure at any historical date, which matters when the regulator asks about a specific reporting period.
- Reconciliation stops being an event and becomes a continuous property.
What this costs, and what pretending costs more
The honest counterargument is that this is more infrastructure to build and operate than a nightly extract-and-join. That is true. It is also true that the extract-and-join has a hidden cost that only surfaces in complaint ratios, ombudsman filings, delayed transfers, and the specific reputational damage of a customer being told two different withdrawable balances by two different channels in the same week.
I have seen this exact scenario end with a mid-six-figure remediation project and a regulator asking pointed questions about internal controls. The event model would have cost less than the remediation, and it would have produced audit trails the regulator actually wanted to see.
The policy loan is not a rare edge case in Turkish BES and life portfolios. It is a routine product feature that has been architecturally treated as an exception for as long as I have been working in this space. Treating it as a first-class citizen of the data model is overdue, and the pipelines that have already made the shift are the ones whose operations teams stopped opening spreadsheets on withdrawal day.