01 – Context
What ACORD does well and where it was designed for
ACORD has served the insurance industry since 1970, and its contribution to reducing bespoke integration overhead between carriers, brokers, and agents in the direct insurance market is genuine. Its data standards, form definitions, and message formats create enough common ground that two ACORD-compliant systems can exchange transaction data without building a custom integration from scratch.
That common ground is valuable for direct commercial insurance: a policy bind, a certificate of insurance, a basic claims notification. The transactions are relatively standardised. The data fields are predictable. The relationships between parties are bilateral.
Reinsurance is a different operating environment. A single facultative placement can involve more than ten reinsurers, each potentially using different internal data systems. A treaty programme with proportional, excess of loss, and aggregate layers creates a hierarchy of coverage relationships that does not map onto the bilateral transaction model ACORD was built around. A retrocession chain adds further parties, each requiring data from the step before them in the chain.
ACORD’s field structures were designed to describe a transaction. Reinsurance requires describing a relationship between transactions, across multiple parties and periods, with calculations that depend on data accumulated over the life of the contract.
02 – The Gaps
The four structural gaps in ACORD for reinsurance
Gap 01 — Bordereau data management
Insufficient granularity for treaty-level reporting
The bordereau is the primary operational data document in reinsurance. ACORD does not provide sufficiently granular specifications for the variety of bordereau types, treaty structures, and reporting frequencies in active use. Even between two ACORD-compliant systems, the broker typically receives bordereaux that require manual field mapping before they can be processed. The ACORD North American P&C data standards coalition, formed in May 2026, identifies this gap explicitly in its mandate.
Gap 02 — Treaty hierarchy and contract semantics
No structured representation of coverage relationships
ACORD can record that a treaty exists and capture its basic parameters. It cannot represent a treaty hierarchy as a structured object. It cannot express that a reinstatement provision depends on the limit consumed by a prior loss, or that a sliding scale commission calculation requires cumulative loss data across multiple periods. These are not edge cases. They are the defining characteristics of most active reinsurance treaties.
Gap 03 — Multi-party claims notification
Field interpretation varies across reinsurer systems
In a subscription placement, a claims notification must reach all parties and be processed consistently by each. ACORD defines a standard for claims messages, but the interpretation of fields covering loss definition, aggregation basis, and applicable exclusions varies enough between parties that inconsistent processing is common. The downstream effect is claims disputes that extend settlement timelines, not because the facts are in dispute but because the same data has been read differently by different systems.
Gap 04 — Real-time versus batch
Batch-oriented design conflicts with modern integration requirements
ACORD’s historical architecture is batch-oriented: data accumulates and is exchanged in periodic file transfers, with validation running after the transfer. Modern reinsurance operations require real-time data availability: bordereaux validated at ingestion against treaty terms, claims notifications processed on receipt, regulatory data updated continuously. This is not a flaw in the standard. It is a consequence of designing a standard for a world where file transfer was the primary exchange mechanism.
03 – The Compliance Paradox
Why ACORD compliance does not mean interoperability
A system can use ACORD-approved field names and message formats and still require substantial manual intervention in every complex workflow. ACORD compliance is a format standard, not a content standard. Two systems can both comply with ACORD while using the same field to mean different things.
In direct insurance, where transactions are more uniform, this ambiguity is manageable. In reinsurance, where contract terms are bespoke and the calculation of commissions, recoveries, and reserves depends on precise field interpretation, the same ambiguity creates material errors.
The result is that brokers operating entirely within ACORD-compliant environments still maintain dedicated operations teams whose primary function is translating between systems that theoretically speak the same language but practically require human interpretation at every handoff.
Where the gap between ACORD capability and modern reinsurance need is most pronounced
| Data requirement | ACORD capability | Modern reinsurance need | Gap impact |
|---|---|---|---|
| Treaty structure hierarchy | Basic entity definitions and header fields | Granular semantic representation of layers, reinstatements, and retrocession | Cannot model relationships automatically; requires manual interpretation |
| Bordereau scheduling | General premium and loss reporting fields | Detailed mapping across diverse treaty types, frequencies, and cedant formats | High manual mapping effort, elevated error rates, delayed financial close |
| Multi-party claims notification | Standardised claims message format | Consistent field interpretation across all parties in a multi-reinsurer placement | Disputes from inconsistent processing of shared data |
| Real-time data validation | Batch-oriented, post-transmission validation | API-driven validation at the point of entry against live treaty parameters | Delayed error detection; correction cycles after carrier rejection |
| Contract term semantics | High-level contract data fields | Machine-readable capture of nuanced reinsurance-specific terms | Ambiguity requiring human interpretation at each calculation step |
| API integration flexibility | XML-based file transfer with custom mapping | Native API design for real-time exchange across diverse counterparty systems | Integration bottlenecks when connecting new trading partners |
04 — What’s Required
What genuine reinsurance data standardisation requires
The solution to ACORD’s limitations in reinsurance is not a better file format. It is a different architectural approach to how data is captured, represented, and processed.
01 — Architecture
Semantic data models for treaty structures
Rather than storing a reinsurance contract as a collection of flat fields, a semantic model captures it as a structured object: the retention limit as a parameter of the surplus layer, the reinstatement provision as a rule linked to the limit consumed, the sliding scale commission as a formula that requires real-time loss data. A system built on a semantic data model processes these relationships automatically. A system built on ACORD fields cannot.
02 — Integration
API-first real-time data exchange
When a platform is designed from the outset to exchange data through real-time APIs, bordereaux can be validated against treaty terms at the point of receipt rather than after a batch cycle. Claims notifications can be processed immediately. Regulatory data can be produced from live records. Real-time validation replaces the correction cycle with pre-submission exception review.
03 — Automation
Automated bordereau field mapping
Field mapping for non-standard cedant formats should run automatically rather than requiring a manual exercise for each new cedant relationship. When a cedant changes their format, the system re-maps at ingestion. The data and document automation capabilities in Agiliux are built on this principle: bordereau data enters once, is validated against the treaty parameters held in the same system of record, and flows through to settlement preparation without re-entry.
04 — Compliance
Immutable audit trail as workflow output
Compliance documentation should be generated as a by-product of normal workflow operations, not as a separate reconstruction exercise. Every bordereau received, every validation rule applied, every discrepancy flagged and resolved should produce an immutable record automatically. This is both an operational efficiency and a regulatory requirement under IFRS 17 and Solvency II.
05 – Regulatory Dimension
IFRS 17 and Solvency II: the regulatory dimension
The data standardisation problem is not only an operational efficiency issue. It has a direct regulatory dimension that is increasing in urgency.
IFRS 17 requires that assumptions used to measure reinsurance contracts are consistent with those used for the underlying direct contracts. The American Academy of Actuaries has identified specific challenges in fitting reinsurance structures into IFRS 17’s measurement models, particularly for contracts with non-linear loss participation and for reinsurance held that does not have a direct one-to-one correspondence with the underlying direct business.
For brokers, the practical implication is data lineage. IFRS 17 compliance requires tracing how reinsurance data flows from the original treaty terms through bordereau submissions, into financial statements, and into capital calculations. Systems that produce this data through manual reconciliation cannot reliably demonstrate that lineage to auditors or regulators.
Solvency II requirement
Solvency II requires reinsurance exposure data to be reported with sufficient granularity to support the Solvency Capital Requirement calculation. The data that feeds this depends on accurate, continuous bordereau reporting rather than periodic reconciliation. Neither IFRS 17 nor Solvency II can be met adequately by ACORD-compliant systems that still require manual intervention at every complex processing step.
06 – Path Forward
The path forward: augmenting ACORD, not replacing it
The answer to ACORD’s limitations in reinsurance is augmentation, not abandonment. ACORD remains the most widely adopted standard for counterparty connectivity, and moving away from it entirely would create more interoperability problems than it would solve.
The productive approach is to use ACORD as the interface standard for external data exchange while maintaining richer internal data models that can represent the full complexity of reinsurance structures. This is the architectural approach the ACORD North American P&C coalition is working toward at the industry level: developing more granular extensions for specific workflow categories, including delegated authority and treaty management, rather than replacing the existing standard.
The modern system of record approach that Agiliux is built on reflects this distinction. Treaty data is held as structured semantic objects, not as ACORD field collections. Bordereau submissions are mapped and validated against those objects at ingestion. The ACORD-compliant output, where required for counterparty exchange, is generated from the richer internal representation rather than stored as the primary data structure.
For brokers who manage the full lifecycle from placement to bordereau reconciliation, the connection between data standardisation and operational efficiency is direct. The broader discussion of how bordereaux reconciliation affects reinsurance margins covers the operational cost dimension in detail.
Key Takeaways
| Five things to retain from this article |
|---|
| 01 ACORD leaves four structural gaps in reinsurance: bordereau data management, treaty hierarchy representation, multi-party claims notification, and real-time versus batch processing. Each gap requires manual intervention that scales with the size of the book. |
| 02 ACORD compliance does not guarantee interoperability. Two compliant systems can still require significant manual intervention because ACORD defines format, not content interpretation. The same field can mean different things in different systems. |
| 03 ACORD’s own coalition formation in May 2026 confirms the industry has identified the current standard as insufficient for complex delegated authority and treaty workflows. The standard is being extended, not defended. |
| 04 IFRS 17 and Solvency II create a data lineage requirement that manual reconciliation processes cannot satisfy. Regulatory-grade data must be traceable, continuous, and produced through automated pipelines rather than periodic manual reconciliation. |
| 05 The right response is augmentation, not replacement. Use ACORD as the external connectivity standard. Maintain semantic data models internally. Generate ACORD-compliant output from the richer internal representation rather than storing ACORD fields as the primary data structure. |
Frequently asked questions
ACORD standards are industry-standard data formats designed to facilitate electronic data exchange across the insurance value chain. Reinsurance brokers use them because ACORD adoption by carriers and reinsurers is widespread, reducing the technical overhead of connecting to new trading partners. The limitation is that ACORD was primarily designed around direct insurance transactions and does not adequately represent the multi-layer, multi-party complexity of most treaty and facultative reinsurance placements.
ACORD’s field structures were designed for direct insurance transactions, which are simpler in structure than reinsurance. Treaty hierarchies, retrocession chains, aggregate covers, reinstatement provisions, and sliding scale commissions all involve relationships and calculations that ACORD’s generic fields cannot represent with the precision required for automated processing. Even when all parties are ACORD-compliant, significant manual intervention is still required to translate ACORD messages into each party’s internal data structures.
Bordereaux are the periodic data reports through which cedants account to reinsurers for premiums written and claims incurred. The problem is that each cedant uses different formats, field names, and submission schedules, and ACORD does not provide sufficiently granular specifications to standardise this reporting across the variety of treaty types in use. The broker receives bordereaux that are all nominally ACORD-compliant but differ enough in structure that manual mapping is still required before processing.
IFRS 17 requires insurers and reinsurers to measure contracts using consistent assumptions and to report on reinsurance held and underlying contracts consistently. For brokers, this creates specific data lineage challenges: the measurement basis for reinsurance contracts must align with underlying direct contracts, requiring traceable data across multiple systems and treaty periods. The American Academy of Actuaries has noted specific challenges in fitting reinsurance structures into IFRS 17’s measurement models.
No. ACORD remains valuable for basic transaction types and for establishing common ground in counterparty data exchange. The appropriate response is augmentation: using ACORD as the external connectivity standard while maintaining richer semantic data models internally. ACORD itself formed a North American P&C data standards coalition in May 2026 to address the gap between compliance and practical interoperability, confirming the standard needs extension rather than replacement.
API-first integration means a reinsurance platform is designed from the ground up to exchange data in real time through application programming interfaces. This allows bordereaux data to be validated at the point of receipt against treaty terms, claims notifications to be processed immediately, and regulatory reports to be generated from live data rather than reconciled retrospectively. The contrast is with ACORD’s historically batch-oriented design, where data is exchanged in periodic file transfers and validated after the fact.
Semantic data modelling means designing data structures that capture not just the values of data fields but their meaning and relationships. In reinsurance, this includes representing treaty hierarchies as structured objects so the system understands that a surplus layer is related to a retention limit and that a reinstatement provision depends on the limit consumed by a prior loss. Platforms with semantic data models can process these relationships automatically, reducing manual intervention at each calculation step.
IFRS 17 and Solvency II both require accurate, traceable, and consistently produced data for financial reporting. When reinsurance data is produced through manual reconciliation, the traceability required by both frameworks is difficult to demonstrate. Errors in bordereau submissions and batch reconciliation cycles create gaps in the data lineage that regulators expect to be fully auditable.
Glossary
| Key terms used in this article |
|---|
| ACORD Standards Industry-standard data formats for electronic insurance data exchange, defining common field structures, message formats, and data dictionaries. Provide a useful baseline for counterparty connectivity in direct insurance but leave structural gaps in reinsurance workflows that require more granular specifications. |
| Semantic Data Model A data architecture that captures not just the values of data fields but their meaning and relationships. In reinsurance, this means treaty hierarchies are stored as structured objects with defined relationships between layers, provisions, and calculations, rather than as flat ACORD fields requiring human interpretation. |
| Retrocession The transfer of risk by a reinsurer to another reinsurer, creating a chain that can span multiple parties. Each leg requires its own data exchange and reconciliation, making data lineage tracking particularly complex when systems rely on ACORD file transfers. |
| IFRS 17 The International Financial Reporting Standard for insurance contracts, requiring consistent measurement assumptions for reinsurance held and underlying contracts, and continuous traceable data for financial reporting. Manual reconciliation processes cannot reliably satisfy IFRS 17 data lineage requirements. |
| API-First Integration A platform design approach where real-time data exchange through application programming interfaces is the primary mechanism, rather than batch file transfers. Enables real-time validation of bordereau data at ingestion, immediate claims processing, and continuous regulatory reporting. |
| Contract Certainty The state where all terms and conditions of a reinsurance contract are agreed, documented, and understood by all parties before the risk incepts. Poor data standardisation delays contract certainty timelines by requiring extended manual reconciliation of inconsistent data across multiple parties. |
| Data Lineage The documented history of where data originated, how it was transformed, and where it has flowed through a system. Required for IFRS 17 and Solvency II regulatory audit. Manual reconciliation processes create gaps in data lineage that automated systems with immutable audit trails eliminate. |
Conclusion
ACORD’s limitations in reinsurance are not a criticism of the standard. They are a consequence of applying a format designed for bilateral direct insurance transactions to multi-party placements, layered coverage structures, and regulatory requirements that demand continuous traceability.
The brokers feeling this most acutely are those who have grown their delegated authority books past the point where manual reconciliation is sustainable, or whose IFRS 17 obligations require data lineage that batch processing cannot produce. The solution is a different relationship between the standard and the platform: ACORD as the connectivity interface, semantic data models as the internal representation, API-first integration as the processing mechanism.
ACORD’s own coalition formation in May 2026 signals that the gap is widely enough recognised for the standards body itself to address it. Brokers do not need to wait for that process. The platforms capable of operating at this level exist, and the return from adopting them shows up at the first cedant relationship where bordereau reconciliation becomes an automated validation rather than a manual cycle.
See How Agiliux Handles Reinsurance Data
Agiliux is built on a semantic data model that holds treaty structures as objects rather than flat fields. Bordereau data is validated at ingestion against live treaty parameters, not after carrier rejection. If your current reconciliation cycle is the constraint on your next stage of growth, the conversation starts with a 30-minute workflow mapping call.
Sources cited in this article
- ACORD / The Insurer, ACORD Forms North American Coalition to Unify P&C Data Standards, May 2026. theinsurer.com
- American Academy of Actuaries, IFRS 17 Challenges for Reinsurance: Fitting a Square Peg in a Round Hole, 2023. actuary.org
- Lloyd’s of London, Delegated Data Manager, Lloyd’s Market Resources. lloyds.com
- European Insurance and Occupational Pensions Authority, Solvency II Technical Specifications. eiopa.europa.eu