Two insurers can each have perfectly accurate, well-maintained policy databases and still fail to exchange a single piece of usable data between them.

This isn’t a contradiction. Rather, it happens because “accurate” and “compatible” are different things, and the insurance industry has spent decades building the first without much regard for the second.

Every policy administration system, whether built in-house decades ago or licensed from a modern vendor, stores information according to its own internal logic. One system’s “premium” field might include fees that another system tracks separately. One carrier’s definition of “coverage limit” might not map cleanly onto how a partner insurer, a reinsurer, or a lending partner structures the same concept.

None of this is a data quality failure in the traditional sense (the numbers can be entirely correct); it’s a translation failure, and translation failures are harder to spot because nothing throws an obvious error.

This is the problem ACORD, the insurance industry’s standards body, has been trying to solve for a long time.

ACORD provides shared data models and message formats so that a “Policy” or a “Claim” means the same structured thing whether it originates from a legacy mainframe system or a cloud-based platform built last year. Where it’s actually adopted, the results are measurable.

When reinsurer SCOR used ACORD-aligned AI tooling to digitize broker claim data, they saw a 60 percent reduction in manual effort and an 80 percent improvement in data quality, along with faster turnaround on claim payments.

The catch is the phrase “where it’s actually adopted.” ACORD has existed since the 1970s, long enough to become genuinely foundational in parts of the industry, and still nowhere close to universal.

Adoption is uneven across lines of business, uneven across company sizes, and uneven across the age of the underlying systems doing the storing. A carrier running a core policy admin system built decades ago (systems that, in plenty of cases, are still running COBOL underneath a newer interface) doesn’t get ACORD compliance automatically just because a standard exists.

Retrofitting an old system to speak a shared language is its own project, with its own budget line, competing against every other priority an IT department has.

Even carriers running modern platforms aren’t automatically interoperable with each other. Vendors build proprietary extensions, customize implementations to fit specific product lines, and interpret ambiguous parts of a standard slightly differently (this is not unique to insurance, but it lands harder here because so much of the data being exchanged has legal and financial consequences attached to it). Two systems can both claim ACORD compliance and still require a mapping layer between them before data actually moves cleanly.

What this produces, in practice, is an industry where the connective tissue between systems is often built by hand, one integration at a time, rather than assumed as a baseline capability.

A carrier connecting to a new lending partner, a new reinsurer, or a new insurtech vendor frequently has to build or commission a custom integration just to get the two systems speaking the same structured language, even when both sides nominally follow the same standard.

That work is slow, it’s expensive, and it has to be redone (at least partially) every time either side changes its own internal systems.

Lloyd’s of London’s Blueprint Two initiative is one recent, large-scale attempt to address this at a market level, aiming to give brokers, insurers, and syndicates a single common data platform built around ACORD standards rather than each party maintaining its own translation layer.

Whether an effort at that scale succeeds market-wide is still an open question, and the difficulty of past modernization attempts in the same market is reason enough not to assume the outcome.

The deeper issue sitting underneath all of this isn’t really about API technology, which has gotten quite good at moving data quickly once everyone agrees on what the data means.

It’s about the fact that “agreeing on what the data means” turns out to be a slower, more political, more institutionally stubborn problem than building the pipes to move it through.