Every insurance company I have worked with in Turkey has the same argument in a meeting room somewhere. The group team says the individual pipeline is producing wrong HAYMER records. The individual pipeline team says the group team is sending bad data. A director escalates. A working group is formed. Six months later, the same argument happens again with different people.
The reason this loop is permanent is that both teams are correct, and neither is responsible. Group life policy data is not a data quality problem. It is a schema impedance problem between two event models that were never designed to share a surface.
Two Truth Surfaces, One Regulatory Reality
A group life policy in the Turkish market is administered as a single contract between the insurer and the employer (poliçe sahibi). Premium is collected once, from the employer. Renewals happen once, at the master policy level. Endorsements (zeyilname) are executed at the contract level. From the group team's perspective, the atomic unit is the employer contract.
HAYMER and EGM do not care about the employer contract. They care about the insured individual. Each covered employee is a person with a TCKN, a coverage start date, a coverage amount, and a coverage end date. Every one of these needs to be reported as if it were an individual life event.
So you have:
- Group operational system: one row per employer contract, with an embedded list of insured lives that changes monthly
- Regulatory reporting layer: one row per insured life per coverage state change
The individual policy pipeline was designed for the second model. It expects each policy to have its own lifecycle: issued, endorsed, cancelled, renewed. Group life sends it something that looks like a policy but behaves like a membership list.
Where the Reconciliation Actually Breaks
The failures are predictable once you see the impedance clearly.
Mid-month joiners and leavers. An employee joins the company on the 14th. The group operational system records this as an endorsement to the employer contract effective that date. The individual pipeline receives this as a new insured life. But if the employer's monthly declaration file arrives on the 5th of the following month, the coverage start in the group system, the coverage start reported to HAYMER, and the premium accrual date can all be different values for the same person. Reconciliation queries that assume start_date is a single truth field will always find deltas.
Coverage amount changes without endorsement. Many group contracts define coverage as a multiple of salary. When payroll updates a salary, the coverage amount changes. The employer contract does not get a formal endorsement, but the individual coverage record must. Individual pipelines built around endorsement events simply do not see this change until someone runs a monthly recalculation, and by then the EGM snapshot has already been taken.
Retroactive membership corrections. Employers submit corrected member lists. An employee they reported last month was actually not covered. From the group contract perspective, this is a premium adjustment. From the individual life perspective, this is a coverage that never existed and must be unwound in HAYMER. If your pipeline treats the corrected list as the new truth and overwrites, you have lost the audit trail. If you treat it as a new event, you have double-counted the reversal.
The TCKN that appears twice. Same person, two employers, both with group life at your company. In the group model these are two independent contract relationships. In the individual model, EGM sees one person with two overlapping coverages, which is legal but requires each to be reported cleanly with distinct policy references. Group pipelines that key on employer + employee often collapse or duplicate these depending on which team wrote the join.
Why Neither Team Fixes It
The group team's KPIs are premium collection, employer retention, and claim ratios at the master contract level. They have no operational reason to model individual coverage as first-class events. Their system is optimized for the contract lifecycle they actually manage.
The individual pipeline team's KPIs are regulatory reporting accuracy, EGM/HAYMER submission success rates, and reconciliation with the general ledger. They have no ability to fix upstream data models they do not own.
So the group team ships employer-shaped data. The individual pipeline flattens it into life-shaped events using assumptions that were never contractually agreed. Every edge case becomes a ticket. The ticket gets bounced. The reconciliation report ships with a footnote.
The Structural Fix
The problem is not going to be solved by cleaning data or writing better validation rules on either side. It requires an explicit intermediate layer whose entire job is to be the join between the two event models.
What that layer needs to do:
- Materialize individual coverage as a first-class event stream, generated from group contract state changes, with its own event types: coverage_started, coverage_amount_changed, coverage_ended, coverage_retroactively_voided
- Preserve bitemporal fields on every event: effective date (when the coverage actually started in the real world) and recorded date (when we learned about it). Every HAYMER discrepancy I have ever seen traces back to one of these two dates being treated as the other.
- Own the reconciliation between employer premium and individual coverage-days, rather than letting each side compute it independently
- Emit a canonical individual-shaped feed that the regulatory pipeline consumes without needing to know the group model exists
This is not an ETL job. It is a domain model. The team that owns it needs to understand both the employer contract lifecycle and the regulatory individual event model well enough to defend the translation rules when auditors ask.
What This Looks Like in Practice
When I have seen this work, the intermediate layer is owned by a small team sitting between actuarial operations and data engineering, not inside either. They own the definition of what a coverage event is. They publish the rules: how a mid-month joiner becomes a coverage_started event with what effective date; how a salary-driven coverage change becomes a coverage_amount_changed event even without a zeyilname; how a retroactive removal produces both a voiding event and a premium adjustment.
The group team stops receiving HAYMER complaints. The individual pipeline team stops receiving data quality escalations. The reconciliation report stops having footnotes. The argument in the meeting room stops happening.
Until someone builds that layer, the group life reconciliation surface will keep producing the same errors, and the same two teams will keep blaming each other for a problem that neither of them created and neither of them can fix alone.