A broker rekeys a client's address into the quoting tool on Monday. By Wednesday, the same client's file in policy admin still shows the old one, because nobody updated it there too. Neither system is wrong on its own. Between them, there are now two versions of the same fact, and nothing in either system knows the other one exists.
Multiply that by every client, every renewal, and every system a desk touches in a week, and the picture stops looking like an inconvenience. It starts looking like the reason submissions get queried, renewals slip, and nobody can say exactly why.
The Same Client Details, Entered Three Times, Priced Once
A typical submission does not originate in one place. It starts in a quoting tool, gets rebuilt in policy administration once bound, and gets rebuilt again in finance for billing and commission. Each system holds its own copy of the same client and risk information, because the systems were never built to share a single record between them.
At BIBA 2026, the industry's own trade conference, one finding surfaced repeatedly across broker conversations, according to a review of the event. Stripped of the AI headlines, the most common technology complaint brokers raised was an older and more mundane problem, that their own systems simply do not talk to each other. Brokers described re-keying the same client data across quoting tools, policy administration platforms, and finance systems, and named it ahead of anything AI-related as their biggest day-to-day frustration.
That is not one client entered once. It is one client entered three times, with no system aware that the other two copies exist, and the time lost to it is not spent on a difficult risk. It is spent reconciling versions of a client that should only ever have needed entering once.
Duplicate Data Doesn't Stay a Back-Office Problem
The cost does not end with the person doing the rekeying. A submission built from data pulled at different times, from different systems, is more likely to carry a mismatch an underwriter has to query before they can move forward. The broker who thought the submission was ready gets it bounced back, and the clock on that placement keeps running while the discrepancy gets traced back to whichever system was last updated.
This is why duplicate data feels like a speed problem from the desk but is actually a trust problem between systems. No single platform is lying. Each one is simply correct about a version of the client that has already been superseded somewhere else.
The underwriter querying a submission is not being difficult. They have just noticed that two systems disagree, and someone has to decide which one is right.
This same fragmentation shows up further downstream too. In a 2025 survey of financial services firms conducted for SAP Fioneer's FSI Forum, over half of respondents, 55 percent, named data quality and integration as the major barrier standing in the way of scaling AI and automation, ahead of budget, skills, or regulation. Automation cannot resolve a discrepancy it was never told existed. It simply repeats whichever version of the data it was pointed at, at whatever speed it runs.
Why Adding a New Tool Multiplies the Problem Instead of Solving It
The instinct, once duplicate data becomes visible, is to add something on top to catch it. A validation step here, a reconciliation report there. Each addition genuinely catches some errors. Each one also becomes a fourth place holding its own version of the same client, which is one more place that can quietly drift out of step with the rest.
This is the part that is easy to miss. Duplicate data is not a fixed cost that adding tools slowly pays down. It compounds, because every new system added without a shared source of truth is another copy to keep in sync, not one fewer discrepancy to manage.
Agiliux was built around a single client and risk record that every workflow, quoting, policy administration, and finance, reads from directly, rather than a separate system per function that each holds its own copy and hopes the others stay aligned.
Key Takeaways
| Five things to retain from this article |
|---|
| 01 Duplicate data is created structurally, by quoting, policy admin, and finance systems each holding a separate copy of the same client, not by staff carelessness |
| 02 UK brokers at BIBA 2026 repeatedly named re-keying the same client data across quoting, policy admin, and finance systems as their top technology complaint, ahead of AI-related concerns (Genasys, BIBA 2026 review) |
| 03 55 percent of financial services firms name data quality and integration, not budget or skills, as the main barrier to scaling AI and automation (SAP Fioneer FSI Forum, 2025) |
| 04 A submission built from mismatched copies of the same client is more likely to trigger underwriter queries, which stalls the placement rather than the risk assessment itself |
| 05 Adding a validation or reconciliation tool without a single source of truth adds another copy to keep in sync, it does not remove the underlying duplication |
Frequently asked questions
Duplicate data is usually created structurally rather than by human error. Quoting, policy administration, and finance systems each hold their own copy of the same client and risk information, and without a shared source of truth, updates made in one system do not automatically reach the others.
Broker evidence suggests it is a measurable cost, not an inconvenience. At BIBA 2026, brokers named re-keying the same client data across quoting, policy admin, and finance systems as their single biggest technology complaint, ahead of anything AI-related, and separate survey data shows data quality and integration are now the leading barrier to scaling automation in the wider financial services sector.
Not on its own. A validation or reconciliation tool can catch some mismatches, but if it holds its own copy of the client data to do so, it becomes another version to keep synchronised rather than a reduction in the number of copies in circulation.
A submission assembled from mismatched copies of the same client is more likely to contain a discrepancy an underwriter has to query before proceeding, which slows the placement even though the underlying risk information may be entirely sound.
Glossary
| Key terms used in this article |
|---|
| Duplicate data The same client, risk, or policy detail held separately across two or more systems, with no agreed record treated as the correct one |
| Re-keying Manually entering the same information a second or third time into a different system because it does not transfer automatically |
| Single source of truth One system or record designated as authoritative, so every other system reads from it rather than holding its own separate copy |
| Data reconciliation The manual process of comparing records across systems to find and resolve mismatches after the fact |
| System of record The specific platform or database recognised as holding the accurate, current version of a piece of data |
| Bordereau A periodic report detailing policies written or claims incurred, typically compiled by hand from multiple source systems |
Conclusion
None of this is solved by asking staff to double check their data entry more carefully. A broker rekeying the same client detail for the third time in a week is not making a mistake. They are doing exactly what the system design asks of them, and the discrepancies that follow are the predictable output of that design, not a training gap.
The brokers who feel this least in the next few renewal cycles will not be the ones who added the most validation steps on top of their existing systems. They will be the ones who stopped treating each system's copy of a client as good enough and moved to one record that every workflow reads from instead.
Is your data structurally single-sourced, or held together by whoever remembers to update the second and third copy?
Agiliux was built around a single client and risk record read by every workflow, because closing the gap that creates duplicate data has to happen in the architecture, not in a reconciliation step bolted on afterwards.
Want to see what removing duplicate data actually looks like for your book of business?
Sources cited
- Qualitative finding (not a statistic): Genasys, "BIBA 2026: 10 Valuable Insights from the Conference," reporting broker conversations at the British Insurance Brokers' Association conference, Manchester, 13-14 May 2026. https://www.genasystech.com/biba-2026-review/
- Statistic: SAP Fioneer, "The True Cost of Poor Data Quality in Banking and Insurance" (FSI Forum 2025 AI Implementation Survey of financial services respondents), published 23 December 2025. https://www.sapfioneer.com/blog/poor-data-quality-in-banking-and-insurance/
Agiliux
The Agiliux Editorial Team comprises professionals with expertise across insurance, enterprise technology, legacy modernisation, AI, and digital transformation. Drawing on decades of combined experience, the team publishes research, industry analysis, and practical insights for commercial insurance brokers, reinsurance brokers and insurers. Their areas of focus include insurance operations, workflow automation, AI adoption, data management, and the evolving technology landscape shaping the future of insurance.