ACORD Digital Standards Evolution: A Practical Guide for Agencies

ACORD (Association for Cooperative Operations Research and Development) has published data standards for the insurance industry since 1970. What began as standardized paper forms has evolved through AL3 electronic data interchange, XML schemas, and now JSON APIs. The ACORD digital standards evolution matters for every agency because every system in the insurance value chain -- your AMS, carrier platforms, rating engines, certificate portals, and compliance tools -- depends on ACORD standards to exchange data.

In 2026, the industry is mid-transition from ACORD XML to ACORD JSON. Agencies that understand this shift make technology decisions that serve them for the next decade. Agencies that ignore it find themselves managing workarounds when their tools fall out of step with carrier requirements.

This post traces the full evolution, explains the current state, and identifies what actions agencies should take now.

Key Takeaways

• ACORD standards have gone through four generations: standardized paper forms (1970s-1990s), AL3 electronic data interchange (1995-2005), XML schemas (2005-2020), and JSON APIs (2020-present), with each generation reducing processing time by 60-80% compared to the prior era
• 85% of agency-carrier data exchange still uses ACORD XML or PDF-based ACORD forms as of the ACORD 2025 Technology Report; JSON adoption sits at 12% and grew from 3% in 2024
• The transition from XML to JSON reduces API integration development time by 40-60% and data payload sizes by 30-50%, according to ACORD's 2024 JSON Implementation Guide
• ACORD's 2026 standards roadmap includes expanded JSON schema coverage for specialty lines and claims data, semi-annual rather than annual release cycles, and a new real-time certificate verification specification
• Tools that fall behind ACORD standard updates by two or more versions create carrier compatibility failures within 12-18 months as carriers upgrade their intake systems
• Agencies that belong to ACORD's member program (annual fee: $750-$2,500 depending on membership tier) receive draft standard access 6 months before publication, enabling technology partners to update tools before changes go live

Era 1: Standardized Paper Forms (1970-1995)

ACORD was founded in 1970 by a working group of insurance carriers and independent agents who identified a practical problem: every carrier published its own application form. An agent selling commercial property to a client with five carrier options needed five completely different applications, each with different fields, layouts, and field definitions. There was no consistency in what "liability limit" meant from one form to the next.

ACORD's first mission was to standardize the paper. The ACORD 25 (certificate of insurance), ACORD 125 (commercial insurance application), ACORD 140 (property section), and dozens of other standard form numbers created a common language across the industry. Carriers agreed to accept these standard forms in place of proprietary ones. Agents could train staff on one form set instead of dozens.

By 1985, ACORD had published over 600 standardized form numbers. By 1990, that number exceeded 1,200. Every agency in the country used them, and the forms became so embedded in operations that most people forgot they were optional. The standardization worked.

What the paper standard did not solve was data duplication. An agent completed an ACORD 125 for a commercial account. The carrier received the paper form. A data entry clerk re-keyed every field into the carrier's mainframe system. The same information existed in two places: the agency's paper file and the carrier's computer, with no automated connection between them. Every field transition from paper to digital was a manual step and a potential error.

Era 2: AL3 Electronic Data Interchange (1995-2005)

ACORD's first electronic standard was AL3 (Agency/Company Level 3), a fixed-width flat-file format designed for batch data transfer between agency systems and carrier mainframes. AL3 was not a form replacement; it was a data transport protocol.

AL3's most significant application was carrier download. When a carrier updated a policy (endorsement, renewal, cancellation), that update could transfer to the agency's AMS via an AL3 file rather than requiring a paper document and manual re-entry. By 2000, carrier download via AL3 was the backbone of AMS data management at most independent agencies.

IVANS (Insurance Value Added Network Services) became the clearinghouse for AL3 transactions, routing data files between agency management systems and carrier mainframes through a private network. IVANS still processes AL3 transactions today, connecting legacy carrier systems with AMS platforms that have not moved fully to XML or API-based exchange.

What AL3 accomplished:

AL3 eliminated the most repetitive data re-entry task in agency operations: keying carrier-generated policy data into the AMS. Before AL3, a carrier endorsement arrived on paper. A CSR read the paper and typed every changed field into the AMS. After AL3, the endorsement data arrived in an overnight file and populated the AMS automatically. The IIABA estimates that AL3 carrier download saved the average agency 15-20 hours per week in AMS data entry labor.

Where AL3 failed:

AL3 was designed for 1990s mainframe computing. Fixed-width fields meant that every data element had a predetermined length. If an address was longer than the allocated width, it was truncated. If a new field type needed to be added (a field that did not exist when AL3 was designed), it could only be added by modifying the fixed-width spec, which required all parties to update their systems simultaneously or lose compatibility.

AL3 also handled only P&C lines. Life, health, and specialty lines had no AL3 equivalent. And AL3 was batch-only: data transferred in overnight jobs, not in real time. An agency could not submit an application and receive a quote in the same AL3 session. Those transactions still required phone calls, faxes, or emails.

Era 3: ACORD XML Schemas (2005-2020)

ACORD XML replaced AL3's rigid flat-file format with self-describing, hierarchical data structures. XML (Extensible Markup Language) was already the standard for web services and business data exchange across industries. ACORD's XML schemas defined how insurance-specific data should be structured within that general framework.

What XML changed about data exchange:

XML enabled real-time transactions. An agency could submit an ACORD XML application to a carrier's web service and receive a quote in the same session, without waiting for an overnight batch cycle. This shift from batch to real-time made same-day quoting possible for standard commercial risks with carriers that built XML-based underwriting systems.

XML also supported multiple lines. The ACORD XML framework covers P&C, life, health, reinsurance, claims, and specialty lines. This gave the industry a single standard for all data exchange rather than separate standards by line of business.

The ACORD XML P&C schema alone contains over 5,000 defined elements covering every aspect of commercial and personal insurance applications, policies, endorsements, certificates, and claims. Travelers, Hartford, and several other large national carriers built their carrier APIs on ACORD XML and published their endpoints to agencies and AMS vendors during the 2008-2014 period.

What XML limitations created:

XML's power came with overhead. An ACORD 25 certificate of insurance transmitted as ACORD XML averages 12-15KB. The same data in ACORD JSON averages 4-5KB. For a single transaction, this difference is irrelevant. For an agency processing 500 certificate requests per day through an automated API, XML's verbosity creates real bandwidth and processing overhead.

XML also requires specialized parsing libraries. A developer building an insurance API integration for the first time faces a steeper learning curve with XML than with JSON, because XML parsers are less intuitive than JSON parsers for developers trained on modern web technologies. This higher implementation cost slowed API adoption beyond the largest carriers with dedicated technology teams.

Schema validation in XML is resource-intensive. Processing an XML submission against the full ACORD P&C schema requires significant server computation, which became a performance concern as submission volumes scaled. Carriers optimized their XML implementations over time, but the structural cost remained.

The table below summarizes how each standard generation compared across the dimensions that matter most for agency operations.

Era 4: JSON APIs and the Current Transition (2020-Present)

ACORD published its first JSON schemas in 2022, covering certificates of insurance and basic commercial applications. The 2023 standard release expanded JSON coverage to include binders, endorsements, and personal lines applications. The 2024 release added claims data and the beginning of specialty lines coverage.

JSON (JavaScript Object Notation) is the dominant data format for web APIs across every industry outside insurance. Every modern web framework, from React to Node.js to Python's requests library, handles JSON natively without specialized parsers. Developers new to insurance technology find JSON immediately familiar in a way that XML is not.

Why JSON is replacing XML for new integrations:

ACORD's 2024 JSON Implementation Guide documents that JSON integrations take 40-60% less development time than equivalent XML integrations. This is not because the insurance data is simpler; the data requirements are identical. The difference is that JSON's syntax is less verbose, easier to read, and processed natively by every modern web framework without specialized insurance technology libraries.

JSON payloads are 30-50% smaller than XML for identical data, according to ACORD's benchmarks in the 2024 guide. Smaller payloads reduce bandwidth consumption, speed transmission over mobile networks, and lower server processing overhead. For an agency or carrier processing millions of API calls annually, the efficiency difference is financially meaningful.

InsurTech carriers built on modern cloud platforms default to JSON. Pie Insurance, Next Insurance, Coterie Insurance, and Coalition have all launched with JSON-only or JSON-first APIs. As these carriers grow market share, the volume of insurance data moving via JSON grows alongside them.

Current adoption numbers and what they mean:

The ACORD 2025 Technology Report shows that 12% of agency-carrier data exchange uses ACORD JSON today. That number was 3% in 2024 and is projected to reach 25% by the end of 2026. The jump reflects both InsurTech carrier growth and national carrier JSON API launches: Travelers launched its full commercial lines JSON API in 2025. Hartford announced JSON support for new business applications in Q1 2026.

The remaining 85% of data exchange uses ACORD XML (structured) or PDF-based ACORD forms (unstructured). These two channels will remain dominant through at least 2028. The transition is not a replacement event but a gradual expansion of JSON alongside continuing XML use.

The ACORD 2026 Standards Roadmap

ACORD's published 2026 roadmap includes four significant changes that agencies and their technology partners should prepare for.

Specialty lines JSON expansion. The 2026 standard release extends JSON schema coverage to commercial auto (fleet schedules), inland marine, and professional liability. Agencies writing these lines through API-capable carriers will gain the same structured submission benefits that commercial property and general liability agencies have had since 2024.

Semi-annual release cycles. ACORD is shifting from annual standard releases to semi-annual releases in 2026. This means schema updates will arrive every 6 months instead of once per year. Technology partners (AMS vendors, form tool providers, integration middleware) need faster update cycles to stay current. Agencies should ask their vendors about their planned update frequency and confirm they will match ACORD's semi-annual cadence.

Real-time certificate verification specification. ACORD is finalizing a new standard for real-time certificate verification, enabling third-party verifiers to query carrier systems directly and confirm coverage status without relying on a static PDF certificate. This standard formalizes what companies like myCOI, PINS, and TrustLayer already do through proprietary connections. Once published, it will expand who can access real-time verification data and how it travels.

Claims data standardization. The 2026 roadmap includes the first complete ACORD JSON schema for claims submission and status reporting. Today, claims data exchange is largely proprietary between carriers and their claims systems. ACORD's claims JSON standard would allow agencies to submit loss notices and track claim status through a standard API rather than logging into each carrier's claims portal individually.

How AL3 Still Functions in 2026

AL3 is not dead. Roughly 40% of carriers still route some policy data to agency AMS platforms via AL3 through IVANS, according to IVANS 2025 carrier connectivity data. This is primarily for policy download (carrier sends updated policy data to the AMS after endorsements or renewals), not for submissions.

Agencies that rely on AL3 for carrier download are not at risk in the short term. IVANS continues to support and maintain the AL3 network. But the direction is clear: IVANS has been expanding its XML and API-based carrier connections while maintaining AL3 for legacy integrations. Carriers that have built modern underwriting platforms are launching XML or JSON APIs and eventually retiring their AL3 feeds.

For agencies, the practical implication is: if your AMS receives policy data through AL3 carrier download, confirm with your AMS vendor that they plan to maintain AL3 support for your specific carriers. Ask what their path looks like when individual carriers retire their AL3 feeds. AMS vendors that have invested in IVANS's newer API-based connectivity layer will handle these transitions automatically.

What the XML-to-JSON Transition Means for Agency Operations

Agency operations are not directly affected by the format change from XML to JSON. Your CSRs do not write XML or JSON. They submit forms through a digital form tool or portal. The format question belongs to your technology stack.

But agency technology decisions have downstream effects on operations. Here is what the XML-to-JSON transition means for the decisions you make about tools.

AMS selection and renewal. When evaluating an AMS or renewing your contract, ask specifically: "What is your ACORD standard version support, and do you support both XML and JSON?" AMS platforms that have not yet built JSON support are accumulating technical debt. This debt surfaces when a carrier transitions their API from XML to JSON and your AMS cannot follow without a major update cycle.

Form tool selection. Your digital form tool must keep pace with ACORD schema updates. If the tool uses a static form library that was last updated in 2023, it may be missing fields that became required in the 2024 or 2025 standard releases. Carriers that enforce schema validation will reject forms with outdated field sets. Ask every form tool vendor: "What ACORD version are your schemas currently on, and how often do you update?"

Carrier API integration planning. If you are planning API integrations with specific carriers, check whether those carriers have published or announced a transition timeline from XML to JSON. Building a new XML integration with a carrier that is six months from launching a JSON API creates a short-lived integration. Check the carrier's developer portal for version announcements before committing integration development resources.

Middleware platform selection. Middleware platforms that sit between your AMS and carrier APIs handle the format translation. A good middleware platform supports both XML and JSON and translates automatically based on what each carrier requires. A platform that supports only XML will fail when carriers go JSON-only. This is not a hypothetical future problem; InsurTech carriers are already JSON-only.

ACORD Standards and the Certificate of Insurance

The certificate of insurance is the single most frequently issued ACORD document. The ACORD 25 alone accounts for tens of millions of issuances annually across the U.S. property-casualty market. How certificates are created, delivered, and verified has changed at every stage of ACORD's digital evolution.

Paper era (1970-1995). A CSR printed, completed manually, signed, and mailed the certificate. The certificate holder received it in 3-5 business days. Verification that coverage was current required calling the agency. Certificate holders with compliance requirements often maintained filing cabinets of paper certificates.

AL3 and early XML era (1995-2010). Certificates generated from AMS data via PDF. Email delivery replaced mail for most recipients. Turnaround dropped to same-day or next-day. But the PDF certificate was still a static image. Verification still required calling the agency or trusting the document, which could be outdated.

XML API era (2010-2022). Carriers with XML APIs enabled real-time certificate verification for the first time. A certificate holder with access to a verification portal could query whether coverage was active at the moment of the query, not just at the time the certificate was issued. Companies like myCOI and TrustLayer built businesses on this real-time verification capability.

JSON era (2022-present). ACORD JSON schemas for certificates enable lighter, faster verification queries. The new real-time certificate verification specification in ACORD's 2026 roadmap standardizes how these queries work across carriers and agencies. When this standard publishes, certificate holders will no longer need proprietary connections to individual carriers to verify coverage in real time.

For agencies, this evolution means that the certificate is becoming less of a document and more of a data connection. Clients whose certificate holders require active coverage tracking (municipalities, general contractors, commercial landlords) increasingly expect real-time verification through portals rather than periodic PDF updates.

ACORD's AL3 Replacement: ACORD Connect

ACORD launched ACORD Connect in 2024 as a modern alternative to AL3 for carrier download transactions. Where AL3 used fixed-width flat files routed through IVANS, ACORD Connect uses ACORD XML and JSON over REST APIs with real-time delivery.

ACORD Connect is still in early adoption. As of the ACORD 2025 Technology Report, 18 carriers had launched ACORD Connect integrations, with another 32 in development. For AMS platforms, ACORD Connect connections deliver declaration page updates, endorsement records, and policy status changes in real time rather than overnight.

The practical benefit for agencies is that AMS data becomes more current. An endorsement processed by the carrier at 2:00 PM arrives in the AMS by 2:15 PM. The next client call about that policy finds current information rather than data that is 18 hours behind.

Agencies cannot directly activate ACORD Connect; it is a carrier-to-AMS integration. Ask your AMS vendor which carriers they have activated ACORD Connect with, and whether your highest-volume carriers are on the list.

Preparing for the ACORD 2026 Standard Release

The 2026 standard release lands in Q3 2026. For agencies, preparation means verifying that your technology stack will update without disruption.

Four weeks before the release date: Ask your AMS vendor, form tool provider, and any middleware platforms you use whether they have tested against the draft 2026 schemas. ACORD member organizations receive draft schemas 6 months before publication. Partners who have not yet accessed the draft schemas are likely to fall behind on the release date.

At the release date: Do not assume your tools updated automatically. Log into your form tool and check the schema version displayed in the platform settings or documentation. Submit a test form for each major form type (ACORD 25, 125, 126) to a carrier that enforces schema validation and confirm acceptance.

Two weeks after the release date: Contact your top five carriers by premium volume and ask whether they have moved to 2026 schema validation. Carriers that enforce the new schema immediately will reject submissions from tools still running the 2025 schema.

Quarterly throughout 2026 (and after): As ACORD moves to semi-annual releases in 2026, this schema version check becomes a recurring task every six months rather than once a year. Build it into your agency's technology maintenance calendar.

What Agencies Should Do Right Now

The ACORD digital standards evolution does not require agencies to become technology experts. It does require agencies to ask the right questions of their technology vendors.

Ask your AMS vendor three questions. Which ACORD standard version do you currently support? Do you support both XML and JSON? What is your update timeline for the 2026 standard release?

Ask your digital form tool provider two questions. Which ACORD standard version are your form schemas on? How will you notify me when you update schemas, and what do I need to do on my end?

Inventory your carrier API connections. For any carrier you connect to via API, check their developer portal for version announcements. If they have announced a transition timeline from XML to JSON, share that timeline with your form tool and middleware providers.

Join ACORD's agency membership program. At $750-$2,500 per year depending on tier, ACORD membership gives agencies access to draft standards 6 months before publication, participation in working groups that shape future standards, and early notification of carrier API changes. Agencies that understand the standards roadmap make better technology investments.

The broader trend is clear and has been consistent for 30 years: every standard generation moves toward faster, more structured, more automated data exchange. Paper became electronic batch. Batch became real-time XML. XML is becoming JSON. Each transition creates a window where agencies on the new standard gain competitive advantage through speed and accuracy while agencies on the old standard absorb the friction of outdated compatibility.

The current XML-to-JSON transition is in its early phase. Agencies that prepare their technology stack for JSON today -- not by replacing everything, but by ensuring their tools support both formats and update with ACORD releases -- will be well-positioned when JSON reaches majority adoption in the 2027-2028 timeframe that ACORD's 2025 Technology Report projects.

FAQ

What is the difference between ACORD XML and ACORD JSON?

ACORD XML and ACORD JSON carry the same insurance data but in different formats. XML (Extensible Markup Language) uses tag-based syntax with opening and closing elements: <PolicyNumber>ABC123</PolicyNumber>. JSON (JavaScript Object Notation) uses key-value pairs: "policyNumber": "ABC123". JSON produces smaller files (30-50% smaller than XML for equivalent data) and is easier for modern web developers to implement. XML is more established, with broader carrier adoption and a more complete schema library. Most carrier APIs built before 2022 use XML; most APIs built since 2022 use JSON. The ACORD 2025 Technology Report shows that 85% of current data exchange uses XML (structured) or PDF (unstructured), with JSON at 12% and growing rapidly.

How does the AL3 standard still affect agencies in 2026?

AL3 still routes policy download data from roughly 40% of carriers to agency AMS platforms through IVANS, according to IVANS 2025 carrier connectivity data. Most agencies using AL3 are not aware of it because the data transfer happens automatically in overnight batch jobs. Practically, AL3 means that policy updates (endorsements, renewals, cancellations) that carriers process today appear in the AMS the following morning. XML and API-based alternatives deliver those same updates in real time. Agencies whose highest-volume carriers are transitioning from AL3 to API-based carrier download should confirm with their AMS vendor that the AMS has or will have connections to handle the new format.

What is ACORD Connect and how is it different from IVANS?

ACORD Connect is ACORD's modern replacement for AL3 carrier download, launched in 2024. Where IVANS routes AL3 flat files through a private network, ACORD Connect uses ACORD XML and JSON over REST APIs with real-time delivery. When a carrier processes an endorsement, ACORD Connect sends the update to the agency's AMS immediately rather than the next morning. As of the ACORD 2025 Technology Report, 18 carriers had live ACORD Connect integrations with another 32 in development. IVANS continues to operate alongside ACORD Connect, maintaining AL3 for carriers that have not yet migrated. Agencies cannot activate ACORD Connect directly; AMS vendors and carriers negotiate these connections. Ask your AMS vendor for a list of carriers they have live on ACORD Connect.

How often does ACORD update its standards, and what happens if my tools fall behind?

ACORD has historically released standard updates annually, typically in Q3. Starting in 2026, ACORD is moving to semi-annual releases. Tools that fall behind by one version are usually still compatible with most carriers but may lack fields that became required in the newer version. Tools that fall behind by two versions (12-24 months on the annual schedule, now 6-12 months on the semi-annual schedule) begin generating carrier rejections as carriers upgrade their intake systems to enforce new schema requirements. The practical risk is submissions failing at carriers that have moved to strict schema validation without the agency receiving a useful error message. Ask your form tool vendor explicitly which ACORD version their schemas are currently on and whether they have a plan to match ACORD's semi-annual cadence.

What does the ACORD 2026 standards roadmap include?

The ACORD 2026 roadmap, published in the ACORD 2025 Technology Report, includes four major initiatives. First, expanded JSON schema coverage for specialty lines including commercial auto (fleet schedules), inland marine, and professional liability -- lines where JSON submission was not previously standardized. Second, a shift to semi-annual release cycles instead of annual, requiring faster update cycles from technology vendors. Third, a new real-time certificate verification specification that standardizes how third-party verifiers query carrier and agency systems for live coverage status, replacing proprietary connections with a common API standard. Fourth, the first complete ACORD JSON schema for claims data, enabling standardized loss notice submission and claim status reporting through APIs rather than carrier-specific portals.

How should agencies evaluate technology vendors based on ACORD standards compliance?

Ask four specific questions. First, which ACORD standard version do you currently support, and can you show me the documentation? Second, do you support both ACORD XML and ACORD JSON, and which carriers can I submit to in each format? Third, what is your update process when ACORD releases a new standard, and how long after the release date are your schemas updated? Fourth, how will you notify me of schema updates, and what action, if any, do I need to take on my end? Vendors who cannot answer these questions precisely are likely to fall behind on standard updates. Vendors who can provide version numbers, update timelines, and notification processes are treating standards compliance as a product commitment rather than an afterthought.

---

Written by Javier Sanz, Founder of BrokerageAudit. Last updated April 2026.

Compare ACORD-compliant form tools and AMS platforms for your agency. See the full comparison at BrokerageAudit