GRLC FAQs

Begin by exploring the GRLC Overview here. Use the Data Dictionary to familiarize yourself with the message structures. Access implementation guides from the ACORD Standards Library.

The ACORD GRLC schemas, and the wider Standards in general, ensure everyone speaks the same language, eliminating confusion caused by different data formats, field names, codelists, or structures.

Having a standard data schema—whether that be JSON or XML—for sharing contract, accounting, or claims information between a sender and a receiver is important because it ensures consistency, efficiency, and reliability across the parties involved in the (re)insurance data value chain.

The ACORD GRLC Placing Standard is designed to support JSON implementations.

With the release of ACORD GRLC Gen 2.0 for Accounting and Claims, the GRLC Accounting and Claims standards will include JSON and XML schemas. Prior versions of the ACORD GRLC Accounting and Claims standards include XML schemas only.

Access the schemas here, or find out more by contacting grlc@acord.org.

To ensure proper implementation of ACORD GRLC Standards, it is essential to correctly apply the classifications for data items in your systems. Follow these guidelines for each classification:

1. Mandatory (M): These data items must always be included. Your system should enforce validation to ensure these fields are present in every transaction or message.
2. Conditional/Mandatory (CM): These items are required only under specific conditions. Implement logic in your system to validate these fields based on the relevant condition(s). If the condition is met, the data item must be present.
3. Recommended (R): While not strictly required, these data items are advised for inclusion to support best practices and enhance data quality. Your system should encourage users to provide these fields whenever possible.
4. Optional (O): These data items may be included at the implementer’s discretion. No strict validation is required, but your system can accept these fields if they are provided.

As an implementer, ensure that your validation logic aligns with these classifications to maintain compliance with ACORD GRLC Standards and to support efficient, accurate, and transparent data exchange between brokers, insurers, and reinsurers.

To find out more about the ACORD GRLC Accounting Standards, contact grlc@acord.org. ACORD GRLC members can access the GRLC Accounting Standards here.

The ACORD GRLC Standards define a suite of structured digital messages that support end-to-end processing across the insurance lifecycle. These include:

1. Placing Messages
   Global Placing Message (GPM) and ePlacing Toolkit
   Used during the placement negotiation phase, these messages enable two-way communication between brokers and carriers. They support approximately 200 data elements and are aligned with the Unified Placing Standard. Click here for more information.
2. Contract, Risk & Pre-Accounting (CRP)
   Facilitates post-bind processes, including contract finalization, risk details, and pre-accounting flows. These messages typically involve sender/receiver exchanges across five touchpoints and carry around 300 data elements. Click here for more information.
3. Technical Account & Settlement
   Electronic Back Office Transactions (EBOT)
   Supports transactional accounting and settlement for premiums and claims. These messages are based on the TechAccount & Settlement standard and are widely used for back-office automation. Click here for more information.
4. Claim Movement
   Electronic Claims Office Transactions (ECOT)
   Enables digital claims handling and agreement processes. ECOT messages are designed for transactional claims messaging and are part of the broader claims lifecycle. Click here for more information.
5. Response Messages
   GRLC Response Message
   A standard message used across all business types—pre- and post-bind—to indicate the status of a transaction and guide next steps. It is part of the ACORD GRLC Response Resource Toolkit. Click here for more information.

To align a legacy proprietary data model with the ACORD GRLC schema, treat the GRLC schema as your master reference model. Begin by cataloguing all fields in your existing system and mapping each legacy attribute to its GRLC equivalent. Once the mappings are defined, implement transformation logic—using tools like XSLT, ETL pipelines, or middleware—to convert your data into GRLC-compliant XML or JSON formats.

After transformation, validate the output using the GRLC Test Harness to ensure structural and semantic compliance. To maintain long-term compatibility, version control your mapping specifications. This allows you to quickly identify schema changes in future GRLC releases, update your transformations accordingly, and revalidate to ensure continued compliance.

To find out more about the Test Harness, click here.

In an API-first architecture, the ACORD GRLC XML/JSON schemas serve as the foundational data contract for each API endpoint. Begin by designing your OpenAPI specifications around these schemas so that consumers know exactly what data to submit and expect in return.

At runtime, your API gateway or middleware enforces these schemas—validating incoming requests against the GRLC model and formatting responses accordingly. This approach ensures data consistency, accelerates client-side development, and simplifies versioning, allowing your APIs to evolve in sync with new GRLC schema releases.

The ACORD GRLC Standards are governed through a structured, stakeholder-led process that ensures transparency, domain expertise, and alignment across the industry. Change proposals can originate from any member group—including full and restricted license members, industry associations (e.g., Lloyd’s, IUA, LMA, LMG Data Council, LIIBA, Ruschlikon), and vendors or service providers.

Once submitted, proposals are reviewed and triaged by the ACORD Standards Team, who prepare a formal package for the relevant Standards Project Group (SPG) or Advisory Group—such as those focused on Placing, Accounting & Claims, or Technical Design Authority (TDA). These groups assess both the business need and technical impact of the proposal.

Recommendations are then escalated to the GRLC Programme Advisory Committee (PAC), which holds final decision-making authority. Approved changes are incorporated into the GRLC standard and published; rejected proposals may be revised and resubmitted. This governance model ensures a consistent and collaborative approach to evolving the standards.

GRLC standards follow a structured release cycle. Major schema updates are issued no more than once every 12 to 18 months, given their impact on implementation and the need for coordinated adoption across all stakeholders. These major releases typically introduce changes to the XML/JSON schema and require validation against the GRLC Test Harness.

Between major releases, minor updates are published more frequently. These include:

• Non-breaking enhancements that do not alter the schema.
• SPG-approved fixes that fit within the existing schema framework.

All updates—whether major or minor—are communicated through ACORD’s official member channels, including:

• SPG and PAC updates
• Release notes and technical guidance
• Webinars and roadmap sessions
• Publication to ACORD’s online portals and Data Dictionary

This ensures that implementers are informed, supported, and able to align their systems with the latest standards.

GRLC schema versioning follows a clear distinction between minor and major releases:

• Minor versions are backward compatible, meaning they only introduce optional enhancements—such as new optional fields or refinements—that do not disrupt existing implementations. These updates are designed to extend functionality while keeping the cost of change low.
• Major versions, by contrast, are not backward compatible. They may alter the structure or semantics of the schema in ways that require redesigning application interfaces, data mappings, and validation logic. Such releases are planned with great care and only introduced when necessary to meet significant new business or technical requirements.

ACORD maintains a strong policy of preserving compatibility across minor versions and only introduces major changes when absolutely essential.

The benefits of using the ACORD GRLC Accounting Standards are:

1. Efficiency and Automation
   • Reduces manual data entry and reconciliation efforts
   • Speeds up payment and settlement process
2. Accuracy and Reduced Errors
   • Minimizes discrepancies through standard validation
   • Less room for interpretation reduces disputes
3. Faster Reconciliation
   • Clear, structured data supports quick matching of statements and cash flows
   • Easier to identify and resolve mismatches between broker and insurer/reinsurer records
4. Better Transparency
   • Provides clear audit trials
   • Supports regulatory requirements by maintaining consistent records
5. Scalability
   • Brokers and insurers/reinsurers can handle more volume without proportional increases in administrative work
   • Easier to onboard new trading partners when everyone applies the same standard
6. Stronger Broker-Insurer Relationships
   • Reduces friction caused by payment delays or disagreements
   • Enables smoother business transactions and greater trust
   • Provides metrics and MI to enable root cause analysis and inform discussions/decisions

To see real-life examples of ACORD GRLC implementations, click here, or find out more by contacting grlc@acord.org.

EBOT stands for Electronic Back Office Transactions. EBOT applies the ACORD GRLC Accounting Standard (Technical Account and Settlement Message) and imposes a community-agreed implementation of those standards.

Specifically, EBOT refers to a common format and protocol for exchanging financial and accounting data relating to an insurance or reinsurance contract. This includes contract data, financial data (premiums, commissions, claims payments, adjustments, etc.). These standards define what data is exchanged, how the data is structured, any rules applicable to the data, and how data is transmitted between the parties.

EBOT brings together the following ACORD GRLC Accounting assets:

• Reference data, definitions, formats, and codelists: common fields like policy number, premium amount, commission rate, settlement dates, claims references, etc.
• Schemas: conceptual and physical schemas such as JSON and XML
• Validation rules: guidelines that ensure consistency, such as currency formats, mandatory elements, and conditional elements, as well as the conditions that apply
• Transmission rules: technical guidance to support consistent implementations of the standard; provides additional “business” best practice guidance regarding business process rules, recommendations, and other guidance to support implementers in their ACORD journey

To find out more, click here or contact grlc@acord.org.

The sender can provide the tax details and tax amounts. The tax details allow the sender to provide tax type, tax location, tax percentage, and tax amount to be specified, as well as the type of amount against which the tax applies (e.g., gross premium, commission, brokerage, profit commission, or loss costs).

To find out more about the ACORD GRLC Accounting Standards, contact grlc@acord.org. ACORD GRLC members can access the GRLC Accounting Standards here.

An ACORD GRLC Technical Account (TechAccount) serves as an accounting transaction that is shared digitally between trading partners on an insurance or reinsurance contract. It details one specific transaction between two parties for a particular contract and section. By adopting the following principles, the digital TechAccount structure is consistent and understood across all implementations.

1. Each TechAccount has a single sender and receiver. The sender and receiver represent the trading partners (payee and payor). If multiple parties are involved (e.g., multiple insurers on a contract), separate TechAccounts must be sent for each party, even if some processing is outsourced to a shared service provider.
2. A TechAccount is specific to one insurance or reinsurance contract and section or layer. Separate TechAccounts are necessary for each contract and section, even if they share the same parties, currencies, and settlement dates.
3. It includes only one reference currency (original currency) and one target currency (settlement currency). For multi-currency transactions, separate TechAccounts must be issued for each contract and section—even if the sender, receiver, currencies, and settlement dates are the same. For guidance on handling of multi-currency transactions: How does the ACORD Standard handle multi-currency transactions?
4. All amounts are expressed in the reference currency. If the reference and target currencies differ, the amounts remain in the reference currency. Once the receiver accepts the TechAccount, a Settlement message will be issued, detailing the net settlement amount converted to the settlement currency. For more information on the GRLC Settlement message, refer to: What is the ACORD Financial Account?
5. Multiple financial account amount items (e.g., gross premium, tax deductions, brokerage, commissions) and a net settlement amount can be included in a TechAccount.
6. Each TechAccount has only one settlement due date. Separate TechAccounts must be issued for each installment if applicable to the contract.

By enforcing these principles in the TechAccount schema, ACORD is able to maintain clarity, precision, and accuracy across the (re)insurance value chain.

To find out more about the ACORD GRLC Accounting Standards, contact grlc@acord.org. ACORD GRLC members can access the GRLC Accounting Standards here.

The GRLC Technical Account supports the following transaction types:

• premium
• deposit_premium
• adjustment_account_for_all_types_of_adjustments
• reinstatement
• account_statement
• claim_transaction
• cash_loss
• portfolio_transfer
• stop_loss_claim
• no_activity
• fees
• commission
• loss_review_premium
• individual_informational_claim_update
• journal
• claim_discount

To find out more about the ACORD GRLC Accounting Standards, contact grlc@acord.org. ACORD GRLC members can access the GRLC Accounting Standards here.

Brokers and (re)insurers typically account for insurance contracts at the currency level. Even within multi-currency contracts, this approach offers several benefits. It allows for accurate reflection of currency risk, enables more detailed performance analysis, and simplifies the application of IFRS 17 requirements, which are designed to provide a clearer understanding of an insurer's financial performance and position. This practice is supported by the ACORD GRLC Standards, which facilitate the digital distribution of accounting transactions among cedents, brokers, and (re)insurers.

Treating each currency within a multi-currency contract as a separate element makes the accounting process more manageable. However, cedents, brokers, or co-insurance leads may prefer to present a multi-currency transaction to facilitate the receiver's processes. To achieve this, the sender can group TechAccounts using the ACORD GRLC grouping data attributes in the TechAccount. While sending TechAccounts at the currency level might seem more complex, particularly where presenting digital transactions for a multi-currency contract, it offers significant advantages in terms of accuracy, risk management, and the effective application of IFRS 17.

Issuing ACORD GRLC TechAccounts at the insurance contract and section/layer level, even with the same parties involved, enhances transparency and financial reporting. While grouping contracts might make administration easier, it hides the unique characteristics and risks of each contract, potentially leading to inaccurate financial performance and risk evaluation.

Specific reasons include:

1. Transparency and Accuracy: Each insurance contract has unique terms, conditions, and risk factors. Accounting for them individually provides a clearer view of these specifics, giving a better picture of the insurer's obligations and the associated risks.
2. Financial Reporting: IFRS 17, the standard for insurance contracts, emphasizes the importance of reflecting the underlying risk and cash flows. Individual contract accounting better captures the economics of the arrangement, making financial statements more informative and reliable.
3. Regulatory Compliance: Regulatory bodies often require detailed reporting on individual contracts to ensure industry solvency and stability. Individual contract accounting helps insurers meet these requirements.

While aggregation might offer some administrative efficiencies, the benefits of transparency, accuracy, and risk management associated with individual contract accounting typically outweigh the administrative burden, especially in the context of IFRS 17.

The GRLC Technical Account enables reporting commissions by providing the commission percentage. Commission amounts are deducted from the premium amount.

To find out more about the ACORD GRLC Accounting Standards, contact grlc@acord.org. ACORD GRLC members can access the ACORD GRLC Accounting Standards here.

In the London Market messaging, Lead underwriters are required to submit the business acceptance for the Technical Account. In this scenario, the sender flags the Technical Account as “agreement Required” for the receiver.

Whereas the following underwriters follow the decision by the Lead underwriter and are not required to submit the business acceptance for the Technical Account. In this scenario, the sender flags the Technical Account as “No Response Required” by the receiver.

To find out more about the ACORD GRLC Accounting standards, contact grlc@acord.org. ACORD GRLC members can access the GRLC Accounting Standards here.

The sender of the Technical Account may submit a correction due to circumstances like a query from the receiver. Amounts given in the reversal Technical Account Message must have their +/- sign reversed. In case of informational claim amounts, the reversal Technical Account Message should reflect what these amounts were before the incorrect Technical Account Message was sent.

The following are the details of corrections processed in various scenarios:

1. Reversal processed before business acceptance on Original Technical Account
   When the sender submits a reversal for the original Technical Account message, both transactions are closed in their systems, and further business processing is not allowed.
2. Cancellation processed after business acceptance on Original Technical Account
   When the sender submits a reversal for the original Technical Account message, the receiver must send the business acceptance for the reversal Technical Account message. Both transactions are closed in their systems.

To find out more about the ACORD GRLC Accounting standards, contact grlc@acord.org. ACORD GRLC members can access the GRLC Accounting Standards here.

An ACORD GRLC Financial Account (Settlement) is generated once a TechAccount is business accepted and payments are ready to be collected. A Settlement message can include all financial account items (FA) relating to a business accepted technical accounts conforming to the following:

1. Each Settlement has a single target (settlement) currency.
2. Each Settlement message has a single sender and receiver. The sender and receiver represent the trading partners (payee and payor). If multiple parties are involved (e.g., multiple insurers on a contract), separate Settlement messages must be sent for each party, even if some processing is outsourced to a shared service provider.
3. Each Settlement message has only one settlement date for all FA items included in the same settlement batch.
4. The types of Settlement messages include remittance advice, payment request, request to agree on listed items, and settlement advice.

By enforcing these principles in the Settlement message schema, ACORD is able to maintain clarity, precision, and accuracy across the (re)insurance value chain.

To find out more about the ACORD GRLC Accounting Standards, contact grlc@acord.org. ACORD GRLC members can access the GRLC Accounting Standards here.

ECOT stands for Electronic Claims Office Transactions. ECOT applies the ACORD GRLC Claims Standard (Claims Movement message) and imposes a community-agreed implementation of those standards.

Specifically, ECOT refers to a common format and protocol for exchanging claims data relating to an insurance or reinsurance contract. This includes contract data and claims data (loss details, current payments, reserves, etc.). These standards define what data is exchanged, how the data is structured, any rules applicable to the data, and how data is transmitted between the parties.

ECOT brings together the following ACORD GRLC Claims assets:

• Reference data, definitions, formats, and codelists: common fields like policy number, claims references, loss details, reserves, etc.
• Schemas: conceptual and physical schemas such as JSON and XML
• Validation rules: guidelines that ensure consistency, such as currency formats, mandatory elements, and conditional elements, as well as the conditions that apply.
• Transmission rules: technical guidance to support consistent implementations of the standard, and provides additional “business” best practice guidance regarding business process rules, recommendations, and other guidance to support implementers in their ACORD journey.

ECOT can be used in conjunction with EBOT to support claims settlement advice. To find out more, click here or contact grlc@acord.org.

A claim transaction can be shared digitally between trading partners using the ACORD GRLC Claim Movement (ClaimMovement). It details one specific claim transaction between two parties for a particular contract, section, and claim. By adopting the following principles, the digital Claim structure is consistent and understood across all implementations.

1. Each ClaimMovement message has a single sender and receiver. The sender and receiver represent the trading partners. If multiple parties are involved (e.g., multiple insurers on a contract), separate ClaimMovement messages must be sent for each party.
2. A ClaimMovement message is specific to one insurance or reinsurance contract, section, or layer and claim. Separate ClaimMovements are necessary for each contract, section, and claim—even if they share the same parties and currencies.
3. It includes only one reference currency (original currency). For multi-currency transactions, separate ClaimMovement messages must be issued for each contract and section.
4. All amounts are expressed in the reference currency.
5. All non-financial amounts and reserve amounts are expressed as informational.

By enforcing these principles in the ClaimMovement schema, ACORD is able to maintain clarity, precision, and accuracy across the (re)insurance value chain.

To find out more about the ACORD GRLC Accounting Standards, contact grlc@acord.org. ACORD GRLC members can access the GRLC Accounting Standards here.

The following are GRLC 2016.10.2 release updates/ corrections along with their timelines:

• 2016-10.2 Point Release - published on 31/08/2023
• 2016-10.2 Correction Release - published on 29/03/2024
• 2016-10.2 Correction Release - published on 31/05/2024
• 2016-10.2 Correction Release - published on 23/05/2025
• 2016-10.2 Update Release - published on 29/07/2025

GRLC 2016.10.2 release notes are available on the ACORD website, where ACORD GRLC members can also access the GRLC Accounting Standards. To find out more about the ACORD GRLC Accounting Standards, contact grlc@acord.org.

Yes, the Placing Message structure can be used to exchange a message with multiple parties and endpoints.

The party dataset is reusable across the contract message, but its use varies by context.

Header level: roles (broker, insurer, reinsurer) are explicitly defined, so JSON mapping starts with the role (e.g., broker.partyidentities.typeid).

Contract/market level: roles are indicated via a role code within the dataset, using a generic mapping with the role specified at the end (e.g., party.partyidentities.typecode).

To find out more, please go to the ACORD site.

Triggers for a Placing Message exchange (not an exhaustive list) can be:

• Submission of a new contract
• Quotation request or response
• Request for firm order line
• Signed line advice
• Post-placement process

No, each Placing Message must only relate to one contract.

ACORD GRLC Placing JSON Schema covers direct insurance, treaty reinsurance & facultative reinsurance.

The guide provides direction on how to implement the ACORD GRLC JSON Placing Message schema in relation to electronic placement of (re)insurance contracts.

The guide provides direction on how to implement the ACORD GRLC JSON Placing Message schema in relation to Lloyd's Core Data Record (CDR).

No. Instead, receivers issue a new Placing Message updated with their business data or a quotation, etc.

To find out more, please go to the ACORD site.

The receiver of Technical Account or Claim Movement or Settlement messages send the following responses.

1. Application Validation - Acknowledged:
   Upon receiving the ACORD messages (e.g., Technical Account or Claim Movement or Settlement), the receiver validates the message against the ECOT or EBOT rules. If messages passes all rules, then the receiver sends [Application Validation – Acknowledged] response.
2. Application Validation - Rejected:
   Upon receiving the ACORD messages (e.g., Technical Account or Claim Movement or Settlement), the receiver validates the message against the ECOT or EBOT rules. If messages fails one or more rules, then the receiver sends [Application Validation – Rejected] response by specifying the failure reason.
3. Business Validation - Query:
   The receiver of the (e.g., Technical Account or Claim Movement or Settlement) may raise a business query on the transaction. Refer to: How do you raise a query in ACORD GRLC?
4. Business Validation - Accepted:
   The receiver of the (e.g., Technical Account or Claim Movement or Settlement) submits business acceptance after completing the business review.

To find out more about the ACORD GRLC Accounting Standards, contact grlc@acord.org. ACORD GRLC members can access the GRLC Accounting Standards here.

There are cases where the sender wishes to submit a group of messages for processing, such as:

• two or more installment premiums
• two or more adjustment premiums

These messages can be grouped using Group Reference and the count of messages. This allows the receiver to validate the completeness of the group.

If the group is incomplete, then the receiver must reject the entire group.

To find out more about the ACORD GRLC Accounting Standards, contact grlc@acord.org. ACORD GRLC members can access the GRLC Accounting Standards here.

The ACORD GRLC Standards support receivers raising queries in response to a Technical Account or Claim Movement they have received.

On receipt of a Technical Account or Claim Movement, the receiver can issue a query using the Acknowledgment message [Business Level – Query]. Further Acknowledgement messages can then be sent between the Sender and the Receiver until the query is resolved. Once the query is resolved, the receiver must issue an Acknowledgement message [Business Level – Accept]. The business acceptance of the Technical Account or Claim Movement submitted by the receiver closes all outstanding queries raised. Note: resolution of the query may require a reversal of the TechnicalAccount or correction of the ClaimMovement. For more information on reversal and corrections, please refer to the GRLC Accounting Standards.

To find out more about the ACORD GRLC Accounting Standards, contact grlc@acord.org. ACORD GRLC members can access the GRLC Accounting Standards here.

GRLC Validation applies to ALL Placing Messages. Additional business-specific validations (e.g., CRP or ePlacing) are applied as a secondary layer depending on the message type.

The sender of the Technical Account and Claim Movement messages is required to supply documents electronically to support the transaction (e.g. Calculation sheet, Loss Report, etc.). These supporting documents can be sent along with the Technical Account or Claim Movement message using the following methods:

1. Document Repository Interface (DRI)
   There are different methods defined in DRI regarding how repositories can exchange documents:
   

   1a. Notify and download:
   This is the most widely used method and is recommended best practice. The sender provides information about electronic documents that are available to be downloaded either in the original ACORD message (e.g., the TechAccount or ClaimMovement message) or alternatively sent in a separate DRI “notify” message. Based on the details supplied, the receiver can determine which of the documents they want to download.

   1b. Separate TechAccount and DRI messaging streams:
   This method is supported but NOT recommended as best practice. In this method, document information cannot be provided in the Technical Account message or Claim Movement message. The sender can send one or more separate DRI “notify” or DRI “upload” messages.

2. Instream inclusion
   In this method, the sender includes supporting documents in the same transmission as the original ACORD message.

To find out more about the ACORD GRLC Accounting standards, contact grlc@acord.org. ACORD GRLC members can access the GRLC Accounting Standards here.

The GRLC Data Dictionary is an online reference tool that provides detailed definitions and structures for all data elements used in the ACORD Global Reinsurance and Large Commercial (GRLC) Standards. It helps users understand how data fields are defined, structured, and used across different GRLC messages.

The tool is useful for:

• Business analysts
• Developers
• Standards implementers
• Testing teams
• IT architects
• Operations and compliance professionals who work with ACORD GRLC Standards in placing, accounting, settlement, or claims processes.

You can access the GRLC Data Dictionary here. You will need an ACORD membership or license to access full content.

The Data Dictionary includes:

• Message types (e.g., Placing, Claim Movement)
• Business elements
• Technical XML elements and attributes
• Data types and enumerations
• Descriptions and usage guidance
• Relationships between elements

Yes, the search bar allows you to quickly find:

• Specific message types
• Individual business elements
• Field names or codes

You can also browse through categories or by message process.

Yes, the Data Dictionary is kept up to date alongside the official releases of GRLC Standards. Each release reflects any new messages, enhancements, or deprecated fields.

The Data Dictionary is primarily an online reference. To download full schemas, implementation guides, or XML samples, you need to visit the ACORD Standards.

The Data Dictionary helps you:

• Understand required vs. optional fields
• Validate data mappings
• Ensure correct message formatting
• Build test cases and validate XML or API payloads
• Train business and technical teams on GRLC structures

For technical support or membership inquiries, you can contact ACORD Support via standards@acord.org or use the Contact Us section on the ACORD website.