Every BES operations team I have worked with has the same story. A participant dies. The widow arrives with a court decision, an inheritance certificate, and the expectation that the pension savings her husband accumulated over eighteen years will be paid without a fight. Then the pipeline stalls, and the reason is almost always the same: someone, somewhere, at some point, marked the account as being managed by a legal representative — a power of attorney, a guardian, a court-appointed trustee — and that flag is still sitting on the record, silently, with no history behind it and no expiration in front of it.
This is not a form design problem. It is a data modeling problem that the industry has been avoiding for a decade because fixing it means admitting that legal authority is not an attribute of a participant. It is an event with a lifespan.
What Actually Sits on the Account Today
Open almost any BES participant table in production and you will find something like this attached to the account:
legal_rep_flag(boolean)legal_rep_tckn(identity number of the representative)legal_rep_type(POA, guardian, trustee)legal_rep_start_date(sometimes)legal_rep_end_date(rarely populated, often NULL by convention meaning "still valid")
When a new authority document arrives, the operations user opens the record and overwrites the fields. The old representative is gone. The document reference, if it existed, is replaced. The reason the authority was granted — dementia diagnosis, prolonged travel abroad, court-appointed guardianship of a minor beneficiary — is nowhere in the schema. The event that terminated the previous authority is not recorded either. There is one row. It reflects whatever the last data entry clerk typed.
Meanwhile, downstream systems read that row as truth. The withdrawal engine checks legal_rep_flag. The transfer-out API to another pension company checks legal_rep_flag. The death claim workflow checks legal_rep_flag. None of them ask when it was set, by which document, under which legal basis, or whether the underlying court order has since been revoked.
Where This Breaks in Practice
Four scenarios recur, and I have seen every one of them cost weeks of manual reconciliation.
Scenario one: the expired POA that no one told the pension company about. A notarized power of attorney in Turkey typically carries either a fixed term or is tied to a specific purpose. When it expires, the notary does not call the pension provider. The flag stays on. Two years later the participant transfers to a competitor, the representative signs, and the transfer clears. When the participant discovers this, the reversal touches SGK reporting, tax withholding on any interim partial withdrawal, and the state contribution calculation. All of it has to be unwound because nobody versioned the authority record.
Scenario two: the guardian whose ward turned eighteen. A minor beneficiary's account is managed by a parent under statutory guardianship. On the eighteenth birthday, that authority ends by law. No document is filed. No system event fires. The flag stays on. When the now-adult participant tries to make their first independent decision on the account, the workflow routes the confirmation SMS to the parent's phone number, because that is what the representative record still says.
Scenario three: the death claim where the deceased was also someone else's representative. The participant who died was the court-appointed guardian for a disabled sibling's BES account. His death terminates that authority. But the sibling's account still shows him as the active representative for months, because there is no cross-reference between the death event on one account and the authority record on another.
Scenario four: the revoked POA that lives forever in a cached view. Operations updates the flag. The core system reflects it. The reporting warehouse, refreshed nightly, picks it up the next day. The withdrawal front-end, which reads from a materialized view refreshed weekly, does not. A withdrawal request signed by a revoked representative clears on a Wednesday because the authority check hit stale data.
Why "Better Forms" Will Not Fix This
Every vendor pitch I have seen for the last five years proposes the same solution: a richer intake form, a document management module, a workflow that forces the user to attach a scan. None of it addresses the underlying model. You can attach a hundred PDFs to a record whose authority state is still stored as a single overwritable field. The moment the next event arrives and the clerk edits the row, history is gone and every downstream consumer reads the new state as if it had always been true.
The problem is not intake. The problem is that legal authority is being modeled as a property when it is actually a sequence of events.
The Event-Sourced Alternative
Treat authority as its own table, append-only, with its own temporal axis. Every record represents one legal event:
authority_id(immutable)participant_idrepresentative_identityauthority_type(POA, statutory guardianship, court-appointed trustee, inheritance transition)legal_basis_document_ref(notary reference, court decision number, death certificate serial)granted_at(when the legal instrument took effect, not when the clerk entered it)expires_at(explicit, or NULL only when the authority type is legally indefinite)terminated_at(populated by a later event, not by overwriting)termination_event_id(foreign key to the event that ended this authority)recorded_at(system time, separate from legal time)
Authority state at any moment becomes a query, not a lookup. "Who could sign for this participant on 14 March 2022?" is answerable. "Was this transfer authorized under a valid instrument at the time it was executed?" is answerable. "Show me every account where the representative is a person who has since died" is answerable, and it is the query that catches scenario three before the family has to.
Critically, the schema separates legal time from system time. A court decision dated 3 January that reaches operations on 20 February must record granted_at = 3 January and recorded_at = 20 February. Auditors need both. Bitemporal modeling is not academic here — it is the difference between defending a payment decision in court and losing.
What This Costs to Implement
Honestly, less than the annual cost of the manual reconciliation these failures already generate. The migration path most teams can absorb:
- Freeze the existing flag as the current-state cache, but stop treating it as source of truth.
- Build the authority event table alongside it, backfilled from whatever document evidence exists, with a
backfilled = truemarker where the historical record is incomplete. - Rewrite every downstream authority check to query the event table with an explicit "as of" timestamp — usually the timestamp of the operation being authorized, not the current time.
- Add expiration monitoring as a scheduled job that emits events when authorities lapse, so downstream caches get invalidated instead of drifting silently.
The hardest part is not technical. It is convincing operations leadership that the authority field they have been overwriting for a decade was never adequate, and that the reason it seemed to work is that failures were absorbed as customer complaints during death claims — the moments least likely to escalate into regulatory action because the complainants were grieving.
The Uncomfortable Part
Participants and their families encounter this system at three moments: opening the account, transferring it, and closing it — the last usually because someone died. Two of those three moments are exactly when the authority model fails most visibly. The industry has tolerated this because the failures are distributed, quiet, and land on people who are not in a position to file a formal complaint with the regulator.
That is not a technical excuse. It is the reason the fix is overdue.