What a bordereau is, and why delegated authority still runs on one
- Written by
- Riska Underwriting TeamInsurance operations & underwriting
- Published
- Length
- 4 min read
How a bordereau works under a binding authority
It is the morning after October closes. The bordereau for your property program is due to the carrier inside the number of days the binder schedule names, and the file does not exist yet.
Under delegated authority the MGA binds on the carrier's paper, and the carrier sees the business afterwards. The bordereau is how. In the Lloyd's Market Association's multi-year binder wording, LMA3113M (October 2015), the coverholder sends the risks written details "and any adjustments thereto" within a maximum number of days from the end of each reporting interval. Paid premium and claims follow the same pattern, and the schedule fills in the interval: monthly or quarterly.
What goes in the file is standardised at Lloyd's. The Coverholder Reporting Standards (version 5.2, published August 2019; the Lloyd's page was last updated 10 August 2026) set a core data set for risk, premium and claims across all classes and territories, with premium and claims templates to report against. Managing agents can ask for more on top of it.
In the US the floor is set by statute. The NAIC's Managing General Agents Act (model law 225, October 2002) requires the MGA contract to have the MGA render accounts detailing all transactions, and remit all funds due, on not less than a monthly basis.
The month-end bordereau cycle
Five steps, repeated for every carrier and every reporting interval.
- 1
Period closes
the month ends and the binder's clock starts
- 2
Export
the period's policies pulled into a spreadsheet
- 3
Reformat
columns remapped to this carrier's agreed layout
- 4
Rows rejected
lines that miss the standard are stopped
- 5
Resubmit
corrected no later than the next bordereau
and back to Period closes
Who does what, and who carries which risk
The MGA quotes, binds, issues the policy and collects the premium. Under the NAIC model act it holds that money for the insurer in a fiduciary capacity, and owes it onward at least monthly.
The carrier carries the risk. The model act has it review the MGA's underwriting and claims operations on site at least twice a year. Between visits, the carrier knows its own exposure through the bordereau, and only as fresh as the last one.
So the lag lands on both sides. The carrier is holding a book it can see a period late. The MGA owes a file that someone has to build, check and defend, every period, for every carrier.
Three ways a carrier sees an MGA's book
What changes when the bordereau stops being a file someone builds.
| Arrangement | How fresh the carrier's view is | Who reconciles | What the carrier can ask | How an agent gets at it |
|---|---|---|---|---|
| Emailed spreadsheet | As of the last close, delivered within the binder's window | The carrier, mapping each MGA's layout onto its own | What the columns already hold. Anything else is an email | Reads the file, once someone attaches it |
| Standard reporting template | The same window, plus a round of validation | Both sides. Rows that miss the standard are stopped and corrected by the next bordereau | The core data set, plus any fields the carrier added | Reads the validated submission, a period after the fact |
| A live shared view | Open months at any time. The closed month's file is cut at close | Nobody re-keys. The file and the book are the same records | Any question SQL can ask of the live book, joins and totals included, between closes too | Connects over MCP or the API with its own credential, which sees only business on that carrier's paper |
What makes bordereaux hard in practice
A program with two carriers on it produces two bordereaux of the same policies. Neither one is the hard part of the job on its own. Three things are.
Every carrier wants its own layout. The LMA wording has the coverholder report "in a manner or format agreed by" the underwriters, and the Lloyd's standards let managing agents add fields to the core set. Each new carrier on a program is another layout to maintain by hand.
Endorsements change premium after it was reported. A March endorsement moves the premium on a policy the carrier saw in January. The wording asks for adjustments as well as new risks, and Lloyd's Market Bulletin Y5311 (27 October 2020) set out that submissions missing the standard would be stopped at validation, with corrections due no later than the next bordereau.
Reported is not paid. Y5311 names three separate bordereaux: Risk Written, Premium Paid and Claims. Matching the cash that actually arrived against the premium already reported is a job of its own, and it comes round every period.
Live, not exported: a bordereau built from live records
In Riska a bordereau template is a saved view of posted premium lines. Its column labels become the carrier's headers, so a second carrier's layout is a second view of the same lines rather than a second spreadsheet. Closing the month starts a written run for each carrier that has a template, and a run refuses a month that is still open, because its lines can still change. Every run keeps its file, its row count and its totals: premium by charge type, commission retained and net due to the carrier. A download returns the bytes that were sent.
An endorsement posts the difference as a new line in the open month. The month the carrier already has stays as sent, and the change reaches the next bordereau as a line of its own. Each carrier's remittance terms say whether it is paid on written or collected premium, how often, and how many days after the period.
Between closes, nobody waits for the file. The template runs against the live book, and portfolio charts read the same posted lines. The carrier can query that book in SQL, joining policies, premium lines and endorsements across the program. Its credential sees only business written on its paper, under the binder it granted, never another carrier's, and every query it runs is logged under its own name. Its own tools and agents connect over MCP or the API under that same credential. The bordereau stops being a file someone builds and becomes a query the carrier runs. Skip the export and go straight to the source.
The written premium bordereau is what ships today. Paid premium and claims bordereaux do not yet: a paid bordereau needs every payment matched to the line it settles, and that matching is still to come.
Questions we get asked
- What is a bordereau in insurance?
- A bordereau is the periodic schedule a delegated underwriter, such as an MGA or a Lloyd's coverholder, sends the carrier that bears the risk. It lists the policies bound, the premium written or paid, or the claims paid and outstanding for one reporting period.
- How often do MGAs submit bordereaux?
- The binding authority agreement sets it. Lloyd's standard LMA wording offers monthly or quarterly intervals with a maximum number of days after each one, and the NAIC Managing General Agents Act has US MGAs render accounts and remit funds to the insurer at least monthly.
- What is the difference between a risk and a premium bordereau?
- A risk bordereau lists the policies bound and their details, which the carrier needs for its tax, regulatory and financial reporting. A premium bordereau lists the money: premium written or paid, commission retained and what is owed to the carrier.
- Can a carrier get real-time data from an MGA?
- Yes, if the agreement allows it and both sides work from the same records. Lloyd's LMA3113M wording already lets paid premium be made available in an alternative manner agreed in advance. In Riska the carrier queries the MGA's live book in SQL and connects its own tools or agents over MCP or the API, instead of waiting for the month-end export. Its credential sees only business written on that carrier's paper, under the binder it granted, never another carrier's, and every query it runs is logged under its own name.
- Does a live view replace the bordereau file?
- No. A closed period still needs a file of record that both sides can point at later. In Riska each run stores its file and totals, and a download returns exactly what was sent, while the same view keeps answering questions about the open month.
Keep reading
Why the agentic era will break insurance systems
Insurance systems were built for a person who opens one account and finishes it before the next one starts. More product lines, and a broker's agent sending the same risk to more carriers, mean more submissions and more operations than that person can decide on. Anthropic hit the same wall with git: about 2,500 merges a day in May 2026, more than 30,000 by September, and the tool built for a smaller day was the bottleneck. The platform that cannot score, refer and answer while the submission is still open loses the account.
Context compounds: why an underwriting agent is only as good as the file
An agent acts on whatever context it finds. In underwriting, the most valuable context never reaches the policy system: why a risk was declined, which broker's schedules are always wrong, what was quoted last year and why it was lost. Put that on the record, tied to the rules each decision ran under, and every submission makes the next one cheaper to underwrite.
Agents are breaking your policy system
For thirty years insurance software has come in two shapes. Neither was built for an agent that reads every submission, acts on whatever is in the file, and needs authority over a narrow slice of the book. Insurance already has the answer in delegated authority: written limits and referral rules, enforced by the system instead of by a reviewer's attention, so the agent works inside the lines and a person sees only what falls outside them.
See it on your own submissions.
Bring a real ACORD form and a real appetite guide. We will run them through Riska on the call.