Why Every ACORD Digitization Attempt Has Failed

The commercial insurance industry has been trying to digitize ACORD-based workflows for more than two decades. The effort has produced useful tools and almost no structural change. Here is why.

The persistence of the ACORD form

The Association for Cooperative Operations Research and Development (ACORD) was founded in 1970 to standardize insurance forms across carriers. The organization's forms (ACORD 25 for certificates of liability, ACORD 125 for commercial applications, ACORD 140 for property, and hundreds of others) became the de facto common language of commercial insurance paperwork.

The ACORD form was a genuine innovation in its time. Before ACORD, every carrier used proprietary formats, and brokers had to translate between them for every submission. ACORD let brokers fill out one form and send it to multiple carriers. It reduced friction meaningfully.

The problem is that ACORD was designed as a paper-form standard. Its fundamental data structure is a printed form with fields that humans fill out and other humans read. When the industry moved to PDF, ACORD moved with it, but the underlying structure stayed the same: a form-shaped document whose primary purpose was to be printed, signed, and filed.

Commercial insurance is still running on this foundation today. A broker preparing a submission in 2026 is still, in most cases, filling out an ACORD 125 or 140, either as a PDF or through a software tool that generates a PDF. The submission is still being sent by email. The receiving carrier is still, in many cases, manually transcribing the PDF into their underwriting system.

This should seem strange. It is not normal, in most industries, for the core data exchange format to be a form designed for paper. The explanation is a series of failed digitization attempts, each of which tried to fix the problem in a way that did not work.

Attempt 1: Fillable PDFs

The first serious digitization attempt was to make ACORD forms fillable PDFs. Instead of printing, handwriting, and scanning, brokers could type directly into fields that would render in the final document.

Why it helped. Faster data entry, legible output, reduced manual errors.

Why it did not solve the structural problem. The fillable PDF is still a PDF. The receiving carrier still has to extract the data to use it. The fillable fields made input easier but did nothing about the underlying format being document-shaped rather than data-shaped. A fillable PDF is a slightly better version of a piece of paper. It is not a structured data exchange.

Attempt 2: XML and ACORD Standards

The more ambitious attempt was ACORD's own XML standard. ACORD developed detailed XML schemas (ACORD XML, or more formally, the ACORD Life Standards and the Property and Casualty Standards) that were meant to allow structured data exchange between carriers, brokers, and service providers.

In principle, this was the right approach. A broker's system could produce an ACORD XML document, a carrier's system could consume it, and the PDF form could be generated as a by-product rather than being the primary artifact.

Why it failed in practice.

The adoption problem. ACORD XML required every participant in the exchange to implement the schema. Carriers had to build ingest systems. Brokers had to build output systems. Agency management systems had to support the format. For a decade, no one wanted to invest in implementation until everyone else had, and everyone was waiting for everyone else.

The versioning problem. The ACORD schemas are complex, extensively versioned, and evolve over time. Building to the standard was a meaningful engineering investment, and keeping up with version changes was an ongoing maintenance burden. Many implementations shipped and then stagnated.

The variation problem. Even with the standard, carriers frequently needed to capture information that did not fit cleanly into the ACORD schema, so they added custom extensions. These extensions were, by definition, non-standard, so the data exchange format drifted back toward bilateral rather than multilateral.

The net effect was that ACORD XML became a standard that a lot of systems nominally support and that very few submissions actually use end-to-end. The form-shaped PDF kept being the default, and the XML became a parallel infrastructure that never achieved the network effects it was designed for.

Attempt 3: Agency management system integrations

A third approach was to make agency management systems (Applied Epic, Vertafore's AMS360, HawkSoft, and others) the source of truth, with integrations pushing structured data directly to carriers.

In principle, this was also reasonable. If every broker's AMS could connect to every carrier's underwriting system, the ACORD form could fade into the background as a printed artifact, while the actual data moved through structured APIs.

Why it has not succeeded.

The N-by-M problem. There are dozens of agency management systems and hundreds of carriers. Every integration is a bilateral engineering project. Some of these integrations exist, usually between the largest AMS vendors and the largest carriers, but the coverage is sparse. A broker using a mid-tier AMS and submitting to a mid-tier carrier is still almost certainly sending a PDF.

The data quality problem. Even when integrations exist, the data in a broker's AMS is often not clean enough to submit directly without review. AMS systems store data in whatever shape the broker's workflow produces, not in the shape a carrier's underwriting system expects. The integrations often require manual cleanup on both sides, which undermines the efficiency argument.

The business model problem. AMS vendors have built their products around an assumption that the AMS is the center of the broker's workflow. Carriers have built their products around an assumption that the carrier's underwriting system is the center of the carrier's workflow. Neither side has a strong incentive to build integrations that make the other side's system more central.

The result is a patchwork of bilateral integrations, none of which add up to a coherent industry infrastructure.

Attempt 4: Broker portals and carrier portals

A fourth approach was portal-based data entry. Brokers would log into carrier portals and enter submission data directly, bypassing the PDF entirely. Some carriers built portals specifically for this purpose. Others built API-based versions of the same workflow.

Why it has not scaled.

The multi-carrier problem. A broker working with fifteen carriers would need to log into fifteen portals, each with different interfaces, different field requirements, and different data export capabilities. The data that was clean in one carrier's portal had to be re-entered in the next. This is worse than the PDF workflow, not better, because the PDF at least can be sent once to multiple carriers.

The portal-as-silo problem. Data entered into a carrier portal lives in that carrier's systems. If the relationship with the carrier ends, or the broker needs the data for a different purpose, the data is not easily portable out. The broker effectively has to maintain its own record in parallel anyway.

Portals remain useful for certain workflows (particularly direct small commercial sales) but have not displaced the PDF as the primary industry exchange format.

What the failures have in common

The pattern across four attempts is consistent. Each attempt treated the problem as a format problem: the PDF is bad, let us replace it with something better. Each of the replacements (fillable PDF, XML, AMS integration, portal) was better than the PDF in some narrow sense, but none of them solved the underlying structural issue.

The structural issue is that commercial insurance data does not want to live in any single vendor's system. It needs to move across brokers, carriers, MGAs, reinsurers, regulators, and insureds. A format standard is valuable only if it is genuinely neutral (not owned by or favoring any single party), and an integration architecture is valuable only if it does not require every pair of participants to build a dedicated link.

ACORD XML was close to the right shape on the neutrality dimension but failed on adoption because the implementation cost was high and the network effects did not materialize. Bilateral integrations are the opposite: they work for the specific pairs that build them, but they cannot scale to the industry.

This failed-digitization pattern is exactly what Polysea was built to address. Rather than creating another format standard or another bilateral integration, we are building the neutral infrastructure layer underneath all of them, where structured data can live and move between parties without any single vendor owning the pipes.

What would be different

A successful digitization of commercial insurance data exchange would have several properties that the previous attempts lacked.

Data-shaped, not form-shaped. The primary artifact is structured data, not a document that happens to contain data. The PDF, if it exists at all, is a rendering of the data for human consumption, not the canonical record.

Neutral infrastructure, not vendor-owned. The data lives in a shared layer that no single participant owns or can monopolize. Brokers, carriers, and insureds all have appropriate access without having to route through a proprietary system.

Incremental, not all-or-nothing. Participants can adopt the shared layer without replacing their existing systems. A carrier can connect its underwriting system to the shared layer while keeping its policy administration platform. A broker can connect its AMS to the shared layer while keeping the workflows that work.

Authorization-aware. The shared layer knows who is allowed to read, write, and modify which data. This is the gap that no prior attempt has addressed at all, and it is the gap that makes the shared layer trustworthy across parties with competing interests.

These properties describe infrastructure, not an application. The failed attempts have largely been applications, even when they were dressed up as standards.

Why this attempt can succeed

Two conditions are different now than they were during the earlier digitization waves.

The first is technical. Modern cloud infrastructure, API standards, and cryptographic verification tools have made neutral shared data layers buildable in ways that they were not in 2005 or 2010. The engineering problem is tractable.

The second is forcing pressure. AI-driven workflows cannot function on PDF-shaped data at scale. The industry is under increasing pressure to move data faster, with better provenance, and with clearer accountability. Earlier digitization attempts failed partly because the existing PDF workflow was, while inefficient, adequate for the volumes and speeds the industry operated at. That is no longer true.

When the existing workflow is merely inefficient, incumbents tolerate it. When it is actively preventing new capabilities from being deployed, incumbents look for alternatives. The shift from inefficiency to active blockage is happening now.

Conclusion

The PDF-based ACORD workflow has persisted not because the industry has not tried to replace it, but because every prior replacement attempt solved the wrong problem. The problem is not that the PDF is a bad format. The problem is that commercial insurance needs shared, neutral, authorization-aware data infrastructure, and every attempt so far has been an application built by a single vendor with an interest in being at the center of the resulting workflow.

The next attempt will either succeed by being infrastructure-shaped, or it will join the list of failed digitizations. The difference between those two outcomes is not technical. It is architectural.

Polysea is building neutral infrastructure for the commercial insurance ecosystem, including shared exposure data management, authorization chain tooling, and automated loss run extraction. If the problems described in this article are relevant to your work, we would like to hear from you at hello@polysea.ai.