Bordereaux Reporting

Skip key takeaways

Updated September 24, 2026

• Lloyd's mandates the data set, DDM is an elective LIMOSS service Lloyd's mandates that every syndicate requests and collects data consistent with the Coverholder Reporting Standards, while LIMOSS lists the Delegated Data Manager as an elective service for managing agents, so the pipeline targets the standard and treats every delivery channel as an adapter.
• Three reporting families, one risk and premium standard Risk and premium share one standard with separate templates and claims is a second standard, and a coverholder without claims authority may not be expected to provide a claims report at all.
• Contract identity is the first validation, not the last The UMR is assigned to the agreement by the market and references the London broker, a section reference is required on any multi-section binder and the year of account follows the agreement rather than the policy issue date, so every row is checked against the contract record before anything else.
• Cadence and cut-off are contract terms, the standard fixes how the period is dated No source states a submission day or a working-day deadline, the reporting period end date must state at least the month and the year, a precision for that field rather than a length for the period, and the monthly rule in the user guide is stated for coverholder appointment agreements with Lloyd's Brussels.
• Exceptions go back to the record, re-submissions get a version A validation finding is routed to the party that owns the source record with the CR code and the rule, a corrected file identifies the period it replaces and the pipeline records approval as a named, timestamped version that a later correction never edits in place.

Copy takeaways

A bordereau is the periodic report through which a coverholder, or a delegated claims administrator for claims, tells the managing agent that delegated the authority what has been written, what premium has been paid and which claims have been notified. In the Lloyd's market that report has a defined shape: a core field set, three reporting families and a submission route the managing agent chooses. Bordereaux reporting is therefore a data pipeline problem before it is a compliance problem: extraction, mapping to a published standard, validation, exception handling and re-submission, a contract-driven cadence, delivery and an audit trail.

In short: A Lloyd's coverholder, also called an MGA, reports risk, premium and claims data to the managing agent that delegated the authority. Lloyd's mandates that every syndicate collects data consistent with the Coverholder Reporting Standards, whose version linked as current from the Lloyd's Reporting Standards page is 5.2, dated 20 August 2019 and announced by Market Bulletin Y5261. That mandate binds the data set; the Delegated Data Manager is listed as an elective LIMOSS service and the cadence and cut-off are terms of the agreement. A working pipeline validates contract identity, currency, dates, class and section codes and claim status before submission and routes every failure to the party that owns the source record.

What a bordereau is and who produces it

Delegated authority is the arrangement behind the coverholder bordereau, and the scope here is Lloyd's delegated-authority reporting under the Coverholder Reporting Standards, not reinsurance or treaty bordereaux and not non-Lloyd's program business. The Lloyd's coverholders page defines the producer: "A Lloyd’s Coverholder, also referred to as a Managing General Agent (MGA), is a company that has been authorised by a Lloyd’s Managing Agent to enter into insurance contracts on behalf of a Lloyd’s syndicate." Its authority comes from a binding authority agreement, which defines the underwriting and administrative functions the coverholder may perform, so a bordereau is the record of what was done under that agreement and the standard identifies every report by its agreement first.

On the other side stands the managing agent, which the Lloyd's Definitions Byelaw defines as an underwriting agent with permission to manage a syndicate and to carry on underwriting and other functions for a member. Brokers are in the chain from the start, since on the same coverholders page "Prospective Coverholders must be sponsored by both a Lloyd’s Broker and a Managing Agent." and the managing agent initiates the application on ATLAS. The consumers of the file follow from the mandate, not from sponsorship: the managing agent, acting for the syndicate, requests and collects the data, while the London broker is referenced inside the agreement identifier and the risk/premium standard reserves a block of detail for it to add.

Risk, premium and claims bordereaux

Lloyd's treats risk and premium as one standard with separate templates and claims as a second standard. The premium figures a coverholder reports back into that risk template are themselves the output of a rating engine, and building one correctly is covered in our insurance rating engine guide. Its Reporting Standards page states the purpose in one sentence: "Establish a standardised core data set for all coverholder and delegated claims administrators to report risk, premium and claims data." It also names the agreements the reporting attaches to: "Binding authority agreements, coverholder appointment agreements and delegated claims administrator agreements where risk, premium, regulatory, tax and/or claims information is required to be reported to Lloyd’s syndicates."

Working definitions of the two transactional families come from the market's operating procedures. The Lloyd's premium bordereaux standard operating procedure defines its subject as "A bordereau containing details of the Premiums that have been paid." and ties itself to Coverholder Reporting Standards Version 5.2 by name.

Per the claims counterpart, a claims bordereau is "A bordereau which contains details of the Claims that have been notified." It is a record of claims data, not a claims process: notification intake, triage and straight-through settlement belong to the claims system and to our guide to insurance claims automation software; the bordereau reports what that system holds at period end.

No Lloyd's source in this set defines the risk bordereau in a quotable sentence. In the user guide it is the risk half of the risk/premium standard: the policies written under the agreement in the period, each with its reference, dates, class, risk code, section number, insured, location of risk and sums insured.

Not every coverholder produces all three. The user guide is explicit: "The standards apply to all coverholders and to TPAs/DCAs with claims authority. Where a coverholder does not have authority to manage claims they may not be expected to provide a claims report."

The Coverholder Reporting Standards by version

The cover of the Lloyd's user guide reads "Coverholder Reporting Standards User Guide Version 5.2 20 August 2019" and it is the version the Lloyd's Reporting Standards page links as current, next to templates whose file names carry V52. Its scope is every class and territory: "The standards state the core set of regulatory, tax, premiums and claims information coverholders and TPAs/DCAs are required to report into the Lloyd’s market for all classes of business in all territories."

What changed in that version is narrow. Market Bulletin Y5261, which announced it, says: "Changes in this version are limited to those which are mandatory for tax or regulatory purposes. All changes should be implemented by September 2020." One of the listed changes, a section reference for any multi-section binder, becomes a validation rule below.

The Lloyd's mandate sits on the syndicates; the coverholder's own obligation flows through its agreement. Per the Reporting Standards page, "It is mandated that all Lloyd’s syndicates request and collect information consistent with the requirements set out in the user guide." and "Core reporting requirements apply to all binding authority agreements and coverholder appointment agreements incepting since July 2017." Beyond the core set, managing agents can require additional data for regulatory obligations, risk profile, customer type, geography and distribution model. Third parties are expected to provide it where reasonably requested. An MGA's pipeline therefore has a fixed floor and a per-agreement ceiling.

The core field set is the mapping target. The risk/premium standard identifies each report by coverholder name and PIN, unique market reference, agreement number, reporting period dates, section number, class of business, risk code, type of insurance, London broker reference, year of account and certificate reference, then carries the premium groups from period of cover and gross written premium in the original currency through commissions, brokerage and net premium to underwriters to sum insured, deductibles and limit of indemnity, with the insured, the locations, the transaction dates and the taxes around them. On the claims side the standard adds the TPA or DCA, the claimant, the claim reference, the location and cause of loss, claim status with referrals, denials and key dates, then indemnity and fees. Every field carries a CR code and a per-report mandatory status.

Extraction from policy and claims systems

An extract is a query over the policy administration and claims systems for one agreement and one reporting period, and two rules from the standard shape it. First, the period. In the user guide the reporting period end date is "The end date of the reporting period being submitted. As a minimum the month and the year must be provided." so the extract carries an explicit period key rather than inferring one from a file name. Second, the year of account: "All policies written under such agreements should be allocated to the year of account to which the agreement has been allocated, not the year in which the policy was issued." A system that stamps the issue year onto each record reports the wrong year for every policy issued in a calendar year after the one the agreement is allocated to.

Three design decisions follow.

1. Extract transactions rather than balances, because the standard reports transaction types and dates, cancellations, endorsements, reinstatements and installments, which a snapshot of current policy state cannot reproduce.
2. Extract in the original currency and carry the settlement currency separately, because the guide asks for both: "If the currency in which monies are being settled is different to the original currency, then the rate of exchange must be stated (CR0067); together with the net amount being paid to London expressed in the settlement currency (that is the currency in which it is being paid). (CR0068)."
3. Extract claims as of the period end with the status and key dates the claims standard names.

Mapping the extract to the standard

Mapping is a configuration artifact rather than code: each source column maps to one CR-coded field, with a transformation where the source encodes the value differently, versioned with the agreement it serves. The LIMOSS Delegated Data Manager page describes it: "Consolidation is achieved using a questionnaire that filters data submissions into a single, standardised dataset that avoids duplication. Data processing rules can be created to make some datasets mandatory while others can be configured as required." For an in-house bordereaux reporting pipeline the lesson is a questionnaire completed once per channel and reused every period, so the per-period work is validation rather than re-mapping.

In the premium operating procedure the transformation role is "Translate bordereaux formats to DDM standard data fields using a simple, pre-defined and once-only questionnaire." and its file-level advice is a specification for the extract's output format: "Ensure there are no merged cells. Heading order must remain static." It also warns against duplicate headings and heading changes and recommends XLSX. The procedure's warning implies the saved mapping depends on the headings, so a column renamed between periods is a mapping failure the pipeline has to detect. Where the pipeline generates the file, those rules are met by construction, the strongest argument for generating the bordereau from the extract rather than maintaining a spreadsheet.

A pipeline is not always worth building: a coverholder with a single agreement, one managing agent and low volume can complete the questionnaire once and maintain the template by hand, and the pipeline earns its place when agreements, managing agents or volumes multiply.

Validation rules, field group by field group

Two of the four columns below are sourced and two are not. Field group and validation rule come from the standard, the bulletin, the operating procedures and the LIMOSS platform page; where the standard only names a group, the cell says so. Common failure is editorial, since no source measures how often anything fails and the standard publishes no rejection log; each entry describes a row that misses the rule beside it. Who fixes it is editorial too, allocating the fix to the party that owns the source record under the operating procedures' role model.

Field group	Validation rule (sourced)	Common failure (editorial)	Who fixes it (editorial)
Contract identity: UMR, agreement number, section number, year of account, coverholder name and PIN	The UMR is assigned to the agreement by the Lloyd's market and includes a reference to the London broker. The section number is the section of the agreement that authorizes the class of business, and any multi-section binder needs a section reference. Policies take the year of account of the agreement, not the policy issue year	A UMR keyed by hand that does not match the contract record. A section left blank on a multi-section binder. A year of account taken from the policy issue date	The coverholder's bordereau producer, against the contract record held by the contract administrator role
Reporting period	The end date states at least the month and the year. For coverholder appointment agreements with Lloyd's Brussels the guide states monthly risk and claims data, with premium at the existing intervals	A period inferred from the file name. A re-submission carrying the original period with no marker that it replaces the earlier file	The submitter: the coverholder, or the broker where the broker submits
Risk classification: class of business, risk code, type of insurance	Lloyd's classifies business using risk codes, and the class must be one the agreement's section authorizes	A risk code missing on a class added at renewal. A class that does not belong to the stated section	Underwriting administration at the coverholder, checked by the managing agent
Insured and location: name, sector, tax code, location of the insured and of the risk	Field group named in the standard. The bulletin makes the trade or industry of the insured mandatory for commercial risks	A location of risk given as a country where the sub-division is expected. A commercial risk with no industry sector	The coverholder, from its policy administration record
Policy dates: inception and expiry, period of cover, policy issuance date	Field group named in the standard. No date-ordering rule is stated in a quotable form, so any ordering check is the pipeline's own	An expiry before inception. An endorsement dated before the risk it endorses	Policy administration, at extraction
Premium and money: gross written premium, original currency, commissions, brokerage, net premium to underwriters	Field group named in the standard. Where the settlement currency differs from the original, the rate of exchange and the net amount in the settlement currency must be stated	Net premium to underwriters out of step with the gross premium, commission and brokerage components the standard names, a consistency check of the platform's own. A settlement currency that differs from the original with no rate of exchange	The coverholder's finance team, or the London broker for the detail the standard reserves to it
Taxes, levies and fees	Regulatory and tax data are part of the core set. Per the guide, missing or incorrect tax information leads to the policy being rejected and to delayed premium and tax payments	A tax jurisdiction with no tax type or amount. A tax amount in the wrong currency	Whoever prepares the tax fields at the coverholder, with whatever tax guidance the managing agent issues
Claims: claim reference, TPA or DCA, claimant, location and cause of loss, claim status and key dates, indemnity and fees	Claim status, referrals, denials and key dates form one group and indemnity and fees another. Litigation status takes the values O, N or U. No table of permitted status transitions is published, so a transition check is the pipeline's own rule	A closed claim reappearing as open with no reopen date. A paid-to-date figure lower than last period with no recovery recorded	The TPA, DCA or coverholder claims team that owns the claim record
File and mapping: workbook structure, headers, transformation questionnaire	The platform transforms received formats to the standard through a once-only questionnaire. XLSX is recommended, with no merged cells, a static heading order and no duplicate headings	A header renamed between periods so the saved mapping no longer applies. A second sheet with a different layout in the same channel	The submitter fixes the file, then the transformation role owner re-saves the questionnaire
Approval and access	Final approval of a processed bordereau happens before the data is made available to all contract participants	An approved bordereau corrected afterwards without a new version, so consumers hold two states of the same period	Whoever holds the approval role, which the operating procedures leave the managing agent, brokers and coverholders to allocate

Take a policy under a two-section binder, priced in a currency other than its settlement currency. It carries its UMR, agreement number, section number and year of account. Contract identity is checked first: the UMR and agreement number match the contract record and the named section authorizes the policy's class of business. Currency comes next: original currency, settlement currency, rate of exchange and net amount in the settlement currency are all present. Only then does the row pass into the file, which is submitted against its period, transformed through the saved questionnaire and approved.

Claim status deserves a note. In the user guide litigation status is defined as "Extent to which case has proceeded through the legal system" with the values O, N and U; no matrix of permitted claim status transitions is published. A pipeline that refuses a closed claim reopening without a reopen date is applying its own rule, documented as the platform's, agreed with the managing agent and never described as a Lloyd's requirement.

Exception handling and re-submission

A validation failure is an exception with an owner, not a rejected file. The user guide itself says business is rejected at the processing stage where a required transaction date is not specified. In the design we build, a file rejected downstream is corrected and re-submitted as a whole, while a row held upstream is corrected once.

So the pipeline validates before submission and grades each finding. A blocking finding stops the row: a UMR that does not match the contract record, a missing period, a settlement currency with no rate of exchange. A warning lets the row through with a flag, such as a commission percentage that rounds differently from the amount. One file-level check of the platform's own, required by no source, reconciles the premium bordereau totals to the amounts actually settled for the period before release. Each finding goes to the party in the last column of the table with the source record identifier, the CR code and the rule text, and stays open until the source record is corrected and the row re-extracted; a hand patch to the bordereau with the source left wrong reproduces the exception next period.

Re-submission is a versioning problem. A corrected file for a period already submitted identifies the period it replaces and carries a version. Because the operating procedures put the period selection at the start of the submission step and approval after processing, we treat a corrected bordereau as a new submission for the same period that goes through approval again. No source in this set says how a coverholder marks a replacement file, so in the design we build the marker is agreed with the managing agent and the pipeline refuses to submit a period twice without one.

Cadence, cut-off and the reporting period

Cadence is a term of the agreement: the managing agent that collects the data sets the intervals, and outside one context the standard states no interval of its own. That context is the user guide paragraph on coverholder appointment agreements with Lloyd's Brussels, where its only cadence sentence sits and is read: "Risk and claims data must be provided on a monthly basis to support financial and actuarial processing and oversight. Premium data can be submitted as per current submission intervals."

What the standard fixes for every agreement is how the period is identified: the reporting period end date must state at least the month and the year, a minimum precision for that field rather than a length for the period.

Cut-off is the second contract term. No source states a day of the month, a working-day count or a deadline after period end, so the pipeline treats it as a parameter of the agreement record and extracts against a frozen view of the period: a transaction posted after the cut-off but dated inside it appears in the next file as a late entry. A coverholder reporting to several managing agents runs the scheduler per agreement, each with its own period, cut-off and mapping.

Delivery channels, approval and the audit trail

Lloyd's mandates the data set; the Delegated Data Manager is listed as an elective LIMOSS service. Three routes appear in the sources: direct submission to the managing agent, which the LIMOSS problem statement implies when it says insurers receive bordereaux in many formats, the Delegated Data Manager where the managing agent has elected it and, inside that platform, either API ingestion or manual upload.

The LIMOSS page opens with the platform's status: "The DDM Elective service is available to Managing Agents who wish to use DDM." and states what happens to an incoming file: "It will transform the various bordereaux formats received to the agreed Coverholder Reporting Standards." Email or SFTP delivery to a managing agent is an integration option rather than a market fact, since no source in this set describes it.

In the premium operating procedure the platform is "A platform/central repository designed to provide entities, such as brokers, insurers and coverholders, with a platform to send and receive information." formerly named DA SATS. Its five roles map onto pipeline stages whoever performs them:

1. contract administration, which creates and manages the contracts in the platform
2. submission of the file against a period
3. transformation, the translation of the received format to the standard fields through the saved questionnaire
4. assignment of records to sections by rule
5. approval, the final sign-off before the processed data is released to every contract participant

Approval anchors the audit trail. In the procedure's words that role is "Final approval of processed bordereaux before providing access to all data for Contract Participants." In the design we build, the platform records who approved the released data set and when, and treats a correction after approval as a new version rather than an edit.

The rest of the trail is the pipeline's own: the raw extract, the mapping version applied, every validation finding with its resolution, the file as submitted, the result returned and the approval event. No source in this set states a retention period for any of it, so in the design we build retention is a parameter of the agreement record rather than a fixed number.

Lloyd's own systems and tools page for delegated authority describes itself as "An overview of key systems used to manage coverholder information and contracts of delegation, including ATLAS, DCOM, Lineage and Crystal+." and does not list the Delegated Data Manager, consistent with an elective LIMOSS service rather than a Lloyd's mandate. Build the pipeline to the standard and treat every delivery channel, the platform included, as an adapter. Resilience of that adapter layer and the third-party register behind it are the subject of our guide to DORA compliance software architecture.

How Pharos Production helps

Bordereaux reporting is a data product with a published target schema, which suits an engineering team better than a spreadsheet. The Nexora insurance platform case shows the shape of that work for an MGA.

If you are building or replacing that layer, our insurance software development team can map your policy and claims data model to the standard's field set, design the validation and exception flow around the parties that own each record and integrate the delivery channels your managing agents have chosen.

Sources: the Lloyd's Reporting Standards, Coverholders and Systems and Tools pages; Market Bulletin Y5261 of 20 August 2019 and the Coverholder Reporting Standards User Guide Version 5.2 of the same date; the Lloyd's Definitions Byelaw; the DDM Premium and Claims Bordereaux Standard Operating Procedures, Version 1.1; and the LIMOSS Delegated Data Manager page. Read on 16 September 2026. Engineering guidance, not legal advice.

FAQ

Last updated: September 24, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 7

• ★ Featured question. What is a bordereau in insurance?

  Copy link Copies a direct link to this answer to your clipboard.

  A bordereau is the periodic report a coverholder or delegated claims administrator sends to the managing agent that delegated authority to it. In the Lloyd's market it comes in three families.

  The risk bordereau lists the policies written under the agreement in the period with their identifiers, dates, classification and sums insured. The premium bordereau contains details of the premiums that have been paid, with commissions, brokerage and the net amount due to underwriters. The claims bordereau contains details of the claims that have been notified, with status, key dates, indemnity and fees. Lloyd's treats risk and premium as one standard with separate templates and claims as a second standard.

• Who produces a bordereau and who receives it?

  Copy link Copies a direct link to this answer to your clipboard.

  The producer is the coverholder, also called a managing general agent, or a delegated claims administrator for the claims report. The receiver is the managing agent that delegated the authority on behalf of its syndicate, which Lloyd's mandates to request and collect data consistent with the standard; the London broker is referenced in the agreement identifier and the risk/premium standard reserves a block of detail for it to add.

  Where the managing agent has elected the Delegated Data Manager, the file goes there and is transformed to the standard first.

• Which version of the Lloyd's Coverholder Reporting Standards applies?

  Copy link Copies a direct link to this answer to your clipboard.

  Version 5.2 is the version the Lloyd's Reporting Standards page links as current, through Market Bulletin Y5261, the user guide and templates whose file names carry V52, with changes limited to those mandatory for tax or regulatory purposes. Lloyd's mandates that all syndicates request and collect information consistent with the user guide, and the core requirements apply to all binding authority and coverholder appointment agreements incepting since July 2017.

  A pipeline holds the version it maps to as a configuration fact and re-checks the Lloyd's page for a newer one.

• How often is a bordereau submitted and what is the cut-off?

  Copy link Copies a direct link to this answer to your clipboard.

  Cadence and cut-off are contract terms set by the managing agent that collects the data. The user guide's only cadence sentence, monthly risk and claims data with premium at existing intervals, is stated for coverholder appointment agreements with Lloyd's Brussels and read in that context.

  For every agreement the standard requires that the reporting period end date states at least the month and the year, a precision for that field rather than a length for the period; no source states a day of the month or a working-day deadline.

• What does bordereaux validation check?

  Copy link Copies a direct link to this answer to your clipboard.

  Contract identity first: the unique market reference and agreement number against the contract record, the section number on a multi-section binder and the year of account of the agreement rather than the policy issue year. Then the reporting period, the class of business and risk code against the section that authorizes them, the policy dates, the internal consistency of the premium components the standard names as a check of the platform's own, the rate of exchange wherever the settlement currency differs from the original, the tax fields and, on the claims side, the status, key dates and litigation status values.

  Findings go back to the party that owns the source record rather than being patched in the file.

• Is the Delegated Data Manager mandatory?

  Copy link Copies a direct link to this answer to your clipboard.

  Lloyd's mandates the data set; the Delegated Data Manager is listed as an elective LIMOSS service, available to managing agents who wish to use it, and the Lloyd's systems and tools inventory for delegated authority does not list it. The user guide itself carries a mandate for the platform's predecessor, DA SATS, requiring managing agents to ensure risk and premium data on coverholder appointment agreements with Lloyd's Brussels is provided to it, and the current position for that book is not stated on the pages read.

  What Lloyd's mandates everywhere is that syndicates request and collect data consistent with the Coverholder Reporting Standards, so the standard binds the data set and the managing agent chooses the channel. A coverholder reporting to several managing agents should expect to support more than one route, which is why the standard, not any platform, is the right target for the pipeline.

• Does the standard define claim status transitions?

  Copy link Copies a direct link to this answer to your clipboard.

  No. The claims standard names claim status, referrals, denials and key dates as a field group and defines litigation status with three values, but publishes no table of permitted transitions. A pipeline that refuses a closed claim reappearing as open without a reopen date is applying its own rule, which is documented as the platform's and agreed with the managing agent.

  Claims workflow itself, from notification through triage to settlement, belongs to the claims system rather than to the bordereau.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.