Delegated authority runs on data that arrives ugly. Every coverholder ships their own spreadsheet, in their own format, on their own schedule, and every file is a cell or a header away from the last. The work today turns skilled analysts into copy-paste operators and pushes useful underwriting insight weeks behind the position it describes.

Case Study, not Delivered Project.

How we'd approach this kind of problem. See delivered projects →

Weeks, not days Typical lag between a bordereaux arriving and a clean, reconciled position the underwriter can act on

You probably have this problem if…

  • The same person spends most of every cycle untangling spreadsheets before any underwriting or claims work can start.
  • Different coverholders send files with different column names, different date formats, and different sheet structures.
  • The same UMR appears as "BCH001-0047" in one file and "BCH0010047" in another, and VLOOKUP quietly fails.
  • Orphan claims and arithmetic errors only surface when something downstream breaks.
  • When oversight asks how an exception was spotted, the trail lives in someone's head or in a Slack message.

Any two of those is a strong signal. All of them and you are paying skilled people to do what should be a one-off engineering problem.

How the pattern works

Imagine a careful analyst who has seen every coverholder template you receive. They know that "GWP", "Gross Prem", and "Premium Written" all mean the same field, and they know your house rules for net, gross, and brokerage. When a new bordereaux lands they parse it, line it up against your system of record, mark every row that fails a check, and leave a written note for each decision. That is the system.

Five things have to work for it to be useful.

Mixed inbound Parse + normalise Structured records Reconcile Audit log
From inconsistent inbound files to a reconciled position with every decision written down.

1. It accepts whatever the coverholder sends

Files arrive as xlsx, CSV, or PDF, often several per period, with merged title rows, premium and claims split across workbooks, and the occasional schedule embedded in a scanned page. Excel and CSV are read directly. PDFs run through a document AI parser. Mistral OCR, Reducto, and Azure Document Intelligence are all defensible choices. The system never asks the coverholder to change their format. Asking is what stalls every previous attempt.

2. It learns each coverholder's schema once, then reuses it

GWP A Gross Prem B Premium Written C MktRef A UMR B From A Inception B Standard schema gross_premium umr inception_date A, B, C are three coverholders. Each row is the column name that coverholder uses for the field.
Every coverholder spells the same fields differently. The pattern learns each mapping once and reuses it on every subsequent file.

The hard part of bordereaux is not the data, it is the variability. A Lloyd's V5.2 schema exists and DDM now mandates it for new arrangements, but established coverholders rarely match. A language model is handed the header row and a handful of sample values, and maps each column to your standard schema. "MktRef" becomes umr. "From" and "Inception" both become inception_date. The mapping is saved against the coverholder and reused on every future file. If the template drifts the system flags it and remaps. That single choice keeps the running cost low and makes adding a new coverholder a small task.

3. It enforces deterministic rules on every row

Once the columns are mapped the work is arithmetic and rule enforcement. Required fields present. UMRs in the expected pattern. Inception before expiry. Net plus brokerage equal to gross within tolerance. Paid plus reserve equal to incurred. Currency codes valid. Transaction types from the allowed list. Each row gets pass, warning, or exception with a plain-English note. Running this in code rather than through a model means the same input always produces the same output, which is the bar oversight expects.

4. It reconciles against the system of record

Structured rows are matched against the carrier or broker's policy and claims systems. Exact UMR matches first. Where the key is malformed (extra hyphen, missing prefix, leading zero) fuzzy matching surfaces likely pairs for human review rather than silently linking or silently failing. Claims with no matching policy are tagged as orphans. Period-over-period diffs highlight new, removed, and materially changed policies.

5. It writes everything down

Every decision lands in an append-only audit log. Which file arrived when. Which mapping version applied. Every rule that fired, on which row, with which value. Every fuzzy match accepted or rejected, every human override. When a managing agent or Lloyd's oversight asks how an exception was identified, the trail is one query away and reads the same in two years as it does today.

Why this is safe for regulated work

Bordereaux are delegated authority data, and Lloyd's, the FCA, and managing agents all have a defensible interest in how it is handled. Four properties matter.

Can run entirely on your network. For carriers and brokers handling sensitive coverholder data, the whole pipeline deploys on-premise with an open-weight mapping model. Parsing, reconciliation, and storage all sit inside your perimeter. The pattern sits beside the Lloyd's Delegated Data Manager rather than replacing it, consuming what DDM publishes and pulling the long tail that does not yet flow through it.

Deterministic where it matters. The language model touches only the schema-mapping step, and only once per coverholder template. Every rule, every reconciliation check, every total runs in deterministic code, so the same input produces the same output, every time.

Version-aware. Mappings, rule packs, and reference data are versioned. Every record carries the version of the logic that produced it. When a rule changes you can replay history under the old, the new, or both, which matters the next time Lloyd's pushes a V5.2 update and you need to show what would have moved.

Audit trail by default. Every parse, mapping, flagged exception, and human decision is logged with timestamp and actor. The log is append-only and exportable. When oversight asks for evidence, you have it before the meeting starts.

The default stack

Excel and CSV parsing openpyxl and pandas in a Python service
PDF and scanned tables Mistral OCR or Reducto for cloud, open-weight Docling on-premise
Schema mapping Claude Haiku with structured JSON output, called once per coverholder template
Rules and reconciliation Pure Python, Pydantic models, deterministic checks
Fuzzy key matching RapidFuzz with thresholds tuned to your data
Storage and audit log Neon Postgres, append-only audit table, daily snapshots
Operator interface Web app with exception queue, mapping review, and one-click export

Two choices that matter most.

A small model for mapping, not a large one. The schema-mapping step is bounded and structured. Claude Haiku or an open-weight equivalent handle it accurately at a fraction of the cost of a flagship model.

Deterministic code for everything else. Rules, totals, reconciliation, and fuzzy matching are not LLM problems. Putting a model in that loop trades predictability for nothing, and the audit trail is only worth something if the same input produces the same output.

When this isn't the right fit

The pattern is powerful, but it is the wrong tool for some problems.

Your coverholders are already clean. If every arrangement submits to the current Lloyd's V5.2 schema through DDM and your downstream tooling already consumes that feed, the heavy lifting is done. The reconciliation and audit log still earn their place, but the value here is variability.

Volume is genuinely low. Below roughly two or three coverholders and a few hundred policies a month, an experienced analyst with a well-built spreadsheet template is faster and cheaper than a build. The break-even is the moment you start hiring a second person for the job.

The dispute is about interpretation. If what consumes time is judgement (which reading of a policy wording should apply, whether a loss is in or out of scope) the bottleneck is not document AI. The right intervention is a structured workflow for the human decision.

Your system of record cannot be queried. Reconciliation assumes you can read policies and claims out of your underwriting and claims platforms by API or replica. If the data is locked inside a closed system, that needs solving first.

What to expect

Implementation time 6–12 weeks for a typical first build, covering 3 to 5 coverholders and reconciliation against one system of record.
Deployment options Cloud-hosted by default. Can run entirely on your network with open-weight parsing and mapping models when delegated data oversight requires it.
Infrastructure cost Roughly £150–500 per month for cloud deployments at typical Lloyd's coverholder volumes, including parsing, storage, and rule execution. On-premise shifts the cost to hardware and ops.
Cycle time Days of manual work per cycle becomes minutes of compute plus a focused exception queue. The reconciled position is available within hours of submission rather than weeks.
Time recovered In a typical delegated authority team, a meaningful share of program administration cost is spent on manual reconciliation, chase emails, and rework. A well-deployed pattern recovers most of that and collapses the data lag from weeks to the same business day.
Secondary benefits Earlier visibility on emerging exposures, fewer orphan claims, a defensible audit trail for delegated authority oversight, and a marginal cost of new coverholders that approaches zero.

If this pattern fits your team

A Pare Audit is the way to find out whether it does, and what a delivery would look like in your situation. We spend a focused few days with you, look at the real bordereaux you receive, your system of record, and your oversight requirements, then come back with a written recommendation, a scoped build, and a costed plan.