11 min read
—
Every slip that clears in the London Market generates a keying task, and usually several. The broker keys it to build the Market Reform Contract. The lead syndicate keys it to quote. Each following market keys it again. The coverholder keys the bound risk into a bordereau. Nobody in that chain is adding information. They are all retyping the same forty-odd fields from the same document.
This is the part of London Market operations that automation has taken longest to reach, and the reason is specific rather than cultural.
An insurance slip is not a form. It is a narrative document with a schedule attached, written to a market convention rather than a fixed template, carrying bespoke clauses, endorsements and a subscription block that grows as the risk is placed. Optical character recognition reads the words and loses the structure. Template extraction works until the next broker uses a different layout, which is immediately.
The market has moved on this faster than most observers expected. The Lloyd's Market Association's April 2026 survey, covering firms representing more than 60% of Lloyd's stamp capacity, found AI adoption had more than doubled in twelve months, with 93% of respondents holding or building formal AI governance frameworks. A year earlier around half the market reported limited or no implementation at all.
This guide covers what an insurance slip actually contains, why it defeats conventional extraction, how a configured workflow reads one, and what the Common Data Record and Blueprint Two require of the output.
In this article:
The four sections of an MRC slip, and what a machine has to understand in each.
Why slips are harder to read than ACORD forms.
A five-step extraction workflow, from ingestion to CDR field mapping.
What Blueprint Two and the CDR change about where the data has to end up.
How the use case differs for syndicates, coverholders and brokers.
What is an insurance slip, and what does AI need to read it
The slip is the placement document. In its standardised form it is the Market Reform Contract, and it is the binding commercial record of a risk: who is insured, against what, for how much, on what terms, and which markets have signed which lines.
Four sections, each presenting a different extraction problem.
Risk details. Insured name, class of business, period of insurance, territorial scope, sum insured and limits. The most structured part of the document and the easiest to read, though insured names arrive with inconsistent legal suffixes and group structures that matter for aggregation.
The schedule. Locations, assets, values, sublimits and deductibles. Often the longest part, frequently an appendix, and sometimes a separate spreadsheet referenced by the slip rather than contained in it. This is where multi-page tables with continuation rows defeat naive parsing.
Terms and conditions. Coverage clauses, warranties, exclusions, and the market wordings referenced by code rather than reproduced. A machine reading this section has to distinguish an incorporated standard clause from a bespoke amendment to it, which is a semantic problem rather than a layout one.
The subscription block. Lead underwriter, following markets, written and signed lines. It changes as the risk is placed, which means the same slip yields different data depending on when it was read.
Binding authority slips are a different shape
A coverholder slip carries the delegated authority reference, aggregate limits, class and territory scope, and the reporting obligations that follow. The practical difference is downstream: an open market slip describes one risk, whereas a binding authority describes the envelope inside which hundreds of risks will be written, each of which then has to appear in a bordereau.
That distinction matters for automation because the two produce different work. Extracting an open market slip populates a quote. Extracting a binding authority sets the parameters against which every subsequent bordereau line is validated. Our guide to insurance bordereaux covers the reporting end of that chain.
Why manual slip processing stopped scaling
Three pressures, and they compound.
The first is volume against headcount. Lloyd's reported gross written premium of £57.9bn for 2025, up 4.2% on the prior year. Submission counts have grown faster than underwriting operations teams, and the marginal submission still costs the same twenty to forty minutes of keying it always did.
The second is duplication. A subscription market means the same slip is read and keyed by the broker, the lead, every follower, and eventually the policy administration system. Five participants on a risk is five keying exercises against one document, and each introduces its own transcription errors that surface later as discrepancies nobody can trace.
The third is regulatory, and it is the one that changes the deadline. Blueprint Two requires structured data rather than documents as the source of truth for placements, and the Common Data Record specifies which fields have to be captured and machine-readable. Manual keying does not reliably meet field completeness requirements at volume, because the failure mode of a tired human is a blank field rather than an error message.
Intake as a defined sequence rather than an inbox. Note where the human review step sits: after extraction, before anything reaches the underwriting system.
Why slips are harder than ACORD forms
This is worth stating plainly, because vendors who quote extraction accuracy from ACORD benchmarks are answering an easier question.
An ACORD form is a form. Fields have designated positions and prescribed labels, and a tool configured once works repeatedly. An MRC slip has a market convention rather than a specification. Two brokers producing a slip for the same risk will order sections differently, use different headings, place the schedule inline or in an appendix, and reference wordings by code or reproduce them in full.
Add endorsements. A slip that has been endorsed three times carries amendments that override earlier terms, and reading the document without applying them produces a coverage summary that is confidently wrong.
How AI reads and extracts insurance slip data
Five steps. The sequence is fixed in advance rather than decided per document, which is what makes the output comparable across a book.
1. Ingestion. The slip arrives as an email attachment, a download from the placing platform, or a scan. It goes in as received, including the appendix spreadsheet if the schedule sits in one.
2. Classification. The workflow identifies what it is holding: open market lead slip, follow slip, binding authority, or cover note. Each routes to its own extraction schema, because the fields that matter differ.
3. Section-level extraction. Risk details, schedule, terms and conditions, and subscription are located and read separately. A limit in the risk details section and a sublimit in the schedule are different claims about different things, and a workflow that flattens the document loses that distinction.
4. CDR field mapping. Extracted values are normalised and mapped to the Common Data Record schema. Mandatory fields the slip does not contain are flagged as exceptions rather than left silently empty, which is the difference between a compliance gap you know about and one you find later.
5. Quality check and routing. Each field carries a confidence score. High-confidence values flow through to the policy administration system or the bordereau template. Low-confidence values route to an underwriting assistant with the source passage attached.
Two of these steps do more work than the other three.
Why classification comes before extraction
Running one schema across every document type is the most common design error in this workflow, and it produces a specific failure: a binding authority read as an open market slip returns an aggregate limit in a field meant for a single risk limit. The number is real, the field is wrong, and nothing downstream flags it because the value is plausible.
Classifying first costs a step and prevents an entire category of silent error.
Why every field needs a source reference
Visual grounding is usually sold as an accuracy feature. In the London Market it is closer to an audit requirement.
If structured data is the source of truth under Blueprint Two, then the provenance of that data has to be demonstrable. An extracted sum insured that links back to the clause it came from can be defended to a broker, an auditor or a regulator. The same figure sitting in a database with no reference is an assertion, and reconciling it later means going back to the document anyway.
This also changes the economics of review. When checking a field costs a click, underwriting assistants check the flagged ones properly. When it costs five minutes of searching a forty-page slip, they check the two that look odd and accept the rest.
Coverage clauses and premium detail read out of the document and held as fields. The document stays where it is; what changes is that the data no longer only exists inside it.
What Blueprint Two and the CDR require
The regulatory backdrop is what turns this from an efficiency project into a deadline, so it is worth being precise about what each piece does.
Blueprint Two is the market's digital transformation programme, and its central premise is that structured data rather than documents becomes the record of a placement. That is a reversal of how the market has always worked, where the slip was the truth and any data extracted from it was a convenience copy.
The Common Data Record is the agreed schema that makes the first thing possible. It specifies which fields must be captured for every risk: insured details, class, risk location, coverage terms, limits and subscription. Extraction that does not map to CDR fields produces data the market cannot use, however accurate it is.
Placing Platform Limited is where slips are transacted electronically, and it is the practical destination for CDR-compliant data. Extraction at ingestion, before the slip reaches an underwriter, removes the re-entry step entirely.
The competitive consequence is straightforward. A syndicate that has CDR data at the point a submission arrives can triage, price and respond while a competitor is still keying. That advantage is available now and it closes as adoption spreads.
Use cases by market actor
The same extraction capability serves three different jobs depending on where you sit.
Managing agents and syndicates
Inbound submission triage. Extract the slip on arrival, score it against the appetite model, and present the underwriter with a populated risk summary rather than a PDF. Declines happen faster, which matters more than it sounds when broker relationships depend on turnaround.
The LMA's 2026 findings suggest this is where deployment has concentrated: firms are applying AI to operational efficiency rather than to frontline underwriting or claims decisions. That is the right sequencing. More than 60% of respondents said human oversight of AI outputs is mandatory in their frameworks, which is the same boundary a well-designed extraction workflow enforces by leaving judgment fields empty. The LMA has since published an AI Adoption Toolkit to support governance-led implementation, which is a useful reference when the risk function asks how a deployment will be controlled. Our guide to insurance submission triage covers the wider workflow.
Coverholders
Bordereaux population, which is the heaviest recurring burden under delegated authority. Every risk written under a binding authority has to appear in a bordereau with consistent fields, and the source is a bound slip that the coverholder already holds.
Extracting at the point of binding rather than at month end changes the reporting cycle from a retrospective assembly exercise to a continuous one. It also removes the reconciliation queries that follow when a bordereau line disagrees with the underlying slip.
Brokers
Slip preparation and CDR validation before submission. A broker who can confirm CDR field completeness before a slip reaches the market avoids the clearance queries that add days to placement, and cleaner slips reaching underwriters is a competitive position rather than a courtesy.
Automating slip processing with V7 Go
This is the workflow V7 Go's insurance slip processing automation was built for, and the design follows from the problems above rather than from a generic extraction template.
The schema is defined per document type, so a binding authority and an open market slip are read against different field sets. Every extracted value carries a link to its location in the source, which is what makes the output defensible under CDR. Confidence scoring routes uncertain fields to a named reviewer rather than pushing them through. Where a check is arithmetic rather than interpretation, such as confirming that scheduled values sum to the declared total insured value or that signed lines reach 100%, it runs as code and returns the same answer every time.
Output goes where the data is needed: the policy administration system, a bordereau template, the placing platform, or a downstream data store. The extraction step is not the deliverable. What the team does with structured slip data is.
One thing worth stating plainly, because the market has heard a lot of claims this year. None of this underwrites anything. It reads a document, tells you what it found and where it found it, and flags what it could not read. Pricing the risk, assessing the broker's presentation, and deciding whether to lead remain exactly where they were. Related reading: our guide to AI in insurance underwriting and the AI for insurance overview.
What to ask a vendor
Four questions, and the answers separate tools built for the London Market from tools built for forms.
Run an endorsed slip. Not a clean one. A slip that has been endorsed twice, where a later amendment overrides an earlier term. A tool that reads the document linearly will return the superseded term with full confidence.
Run a schedule that spans pages. Multi-page schedules with continuation rows are where table structure breaks. Ask to see the extracted output as a table, not as a summary of the table.
Ask what happens to a mandatory CDR field the slip does not contain. The correct answer is a flagged exception. Any answer involving inference should end the evaluation.
Ask whether the field schema is yours. Syndicates carry their own conventions and their own additional fields beyond CDR minimums. A fixed schema designed by a vendor will be missing the two fields your process depends on.
Start where the duplication is worst
The natural pilot is not the most complex class. It is the one with the most repetition.
For a syndicate that usually means a single line of business with high submission volume and a stable slip format, where a month of inbound submissions gives enough documents to test properly. For a coverholder it means one binding authority with a heavy bordereau obligation, because the reporting burden is monthly and the value shows up in the first cycle rather than the fourth.
Run the extraction alongside the existing manual process for that month rather than instead of it. Comparing the two outputs on the same documents answers the accuracy question with your slips, from your brokers, in your classes. It is the only benchmark that transfers.
And keep the review gate. The market's own governance frameworks assume it, the CDR audit trail depends on it, and the failure mode of an unreviewed pipeline is not a visible error but a plausible wrong number that reaches a bordereau and is discovered three quarters later by someone reconciling aggregate exposure.
The slip has been the market's working document for three hundred years and it is not going anywhere. What is changing is whether the data inside it has to be retyped by every party that touches it.
If you want to see extraction run against your own slips rather than a sample pack, V7's solutions engineers configure the field set and the CDR mapping with you before any commitment. Book a working session and bring a slip with a difficult schedule and at least one endorsement.
What is an insurance slip in the London Market?
An insurance slip is the placement document used at Lloyd's and across the London Market, and in its standardised form it is called the Market Reform Contract or MRC. It is the binding commercial record of a placed risk. The document has four main parts. Risk details cover the insured, class of business, period of insurance, territorial scope and limits. The schedule covers locations, assets, values, sublimits and deductibles, and is often the longest section. Terms and conditions cover coverage clauses, warranties and exclusions, including market wordings referenced by code rather than reproduced in full. The subscription block records the lead underwriter, the following markets and the lines each has signed. Binding authority slips differ in that they define the envelope within which a coverholder writes many individual risks.
+
What is the Common Data Record and why does it matter?
The Common Data Record, usually shortened to CDR, is the London Market's agreed data standard specifying which fields must be captured in structured, machine-readable form for every placed risk. It covers insured details, class of business, risk location, coverage terms, limits and the subscription. Its significance comes from Blueprint Two, the market's digital transformation programme, whose central premise is that structured data rather than the document itself becomes the record of a placement. That reverses long-standing practice, where the slip was the source of truth and extracted data was a convenience copy. For anyone automating extraction, the practical consequence is that accuracy alone is insufficient. Output has to map to CDR fields, and missing mandatory fields need flagging as exceptions rather than being left silently empty.
+
How does AI extract data from an MRC slip?
Through a defined sequence rather than a single pass. The slip is ingested as received, including any appendix schedule. It is then classified by document type, because a binding authority, an open market lead slip and a follow slip require different extraction schemas, and running one schema across all of them produces plausible values in the wrong fields. Next the workflow locates each MRC section separately and extracts within it, so that a limit in the risk details and a sublimit in the schedule remain distinct. Extracted values are normalised and mapped to the CDR schema. Finally each field is confidence-scored, with high-confidence values flowing through to the policy administration system or bordereau, and uncertain values routed to a reviewer with the source passage attached.
+
Why are insurance slips harder to automate than ACORD forms?
An ACORD form is a form. Fields sit in designated positions with prescribed labels, so a tool configured once will work repeatedly. An MRC slip follows a market convention rather than a specification. Two brokers producing a slip for the same risk will order sections differently, use different headings, place the schedule inline or as an appendix, and either reference market wordings by code or reproduce them in full. Schedules frequently span multiple pages with continuation rows, which breaks table structure in most parsing approaches. Endorsements compound the problem: a slip endorsed several times carries amendments that override earlier terms, and a tool reading the document linearly will return a superseded term with full confidence. This is why vendors quoting extraction accuracy from ACORD benchmarks are answering an easier question.
+
What is Blueprint Two and how does it affect data extraction?
Accuracy varies with document quality and structure, and any single headline figure should be treated sceptically, particularly one drawn from ACORD form benchmarks. Clean slips with tabular schedules extract close to completely. Slips with narrative schedules, heavy endorsement history or referenced wordings require more reviewer correction. The more useful evaluation question is not the accuracy rate but the failure behaviour. A workflow that returns a source reference on every field, confidence-scores each value, and flags missing mandatory CDR fields as exceptions is auditable regardless of its accuracy rate. One that fills every field confidently and cites nothing is not, however accurate it happens to be on a clean test set. Human review of flagged fields remains mandatory under most market governance frameworks.
+
How accurate is AI at extracting insurance slip data?
Go is more accurate and robust than calling a model provider directly. By breaking down complex tasks into reasoning steps with Index Knowledge, Go enables LLMs to query your data more accurately than an out of the box API call. Combining this with conditional logic, which can route high sensitivity data to a human review, Go builds robustness into your AI powered workflows.
+
Casimir is a seasoned tech journalist and content creator specializing in AI implementation and new technologies. His expertise lies in LLM orchestration, chatbots, generative AI applications, and computer vision.
