What Lloyd's Blueprint Two Means for Small Coverholders (Without the Enterprise Jargon)

Blueprint Two has been discussed enough at Lloyd's conferences that most managing agents, syndicates, and brokers know roughly what it is. If you're a 25-person MGA with a binder or two, though, the version of the conversation you've been part of is probably the version aimed at seven-figure consultancy engagements. That's not the version you need.

This piece is Blueprint Two for the practical coverholder — a 10-to-50-person operation that has to comply, does not have millions to spend on transformation, and needs a plain-English roadmap of what specifically changes in daily operations. It focuses on the two components most relevant to coverholders: the Core Data Record and the transition of data flows to the digital gateway.

What Blueprint Two actually is (in one paragraph)

Blueprint Two is Lloyd's multi-year programme to modernise the digital infrastructure of the market. In practical terms, that means standardising how business is placed, claims are handled, premium and claims are settled, and evidence is exchanged between coverholders, managing agents, brokers, and the market's central services. The bit that touches you as a coverholder is primarily around the data you submit and how it flows into the market's central systems.

The Core Data Record — what it is, and what it isn't

The Core Data Record (CDR) is a defined dataset of the fields that must accompany every risk placed into the market. It replaces the older, informal practice of sending “whatever the managing agent asks for” with a standardised structure.

For a coverholder, the CDR means:

• A defined set of fields that must be captured on every bound risk
• Field-level requirements — mandatory, optional, conditional
• Standardised codes and formats — currencies as ISO 4217, dates as ISO 8601, risk codes from the specified classification
• Structured data submission, not free-text summaries

What the CDR is not: a whole new bordereau format. Coverholders will continue producing bordereaux, but the CDR ensures the underlying data behind each bordereau line is complete and consistent.

What's on the CDR that isn't on many current systems

For coverholders whose PAS was configured before the CDR standard existed, these are the fields that most commonly need to be added or restructured:

• Standardised risk classification codes (many older systems hold this as free text)
• Structured beneficial ownership information for the insured
• Broker chain information — who the placing broker is, plus any wholesale intermediaries
• Precise policy inception and effective dates in ISO format
• Territory of coverage in a standardised representation
• Explicit line-of-business classification per binder

Most of this data already exists somewhere in your operation. The CDR requirement is that it be captured on the policy record, in the correct format, at binding. Retrofitting it afterwards is possible but painful. See how upstream data structure prevents downstream bordereaux problems.

The digital gateway transition — what changes in submission

Alongside the CDR, Blueprint Two moves data flows from a variety of channels (email attachments, secure file transfer, portal uploads) toward a more consistent digital gateway. For coverholders, this means:

• Bordereaux submission through defined APIs or structured channels rather than email attachments
• Real-time or near-real-time validation of submissions rather than batch validation weeks after the fact
• Structured feedback on submission errors — machine-readable, so your system can act on them
• Confirmation of receipt and acceptance as structured messages, not email replies

The operational shift is significant. Coverholders who currently email a spreadsheet to a specific contact at the managing agent will need to be able to submit through the market's systems, receive structured acknowledgment, and handle structured error responses.

What small coverholders actually have to do

Stripped of consultancy language, the practical roadmap for a 10-to-50-person MGA is straightforward:

1. Audit your current policy record. List every field on the CDR. For each, confirm whether your PAS captures it, whether it's in the correct format, and whether it's enforced at binding.
2. Fix the gaps at the source. Anywhere the CDR field is missing or wrong, fix it on the policy record itself. Not in the bordereau generation step, not in the submission step. The correct structure has to live in the source of truth.
3. Confirm your bordereau generation produces CDR-compliant output. The generation logic reads from the structured policy record and produces a bordereau where every field maps to a specified CDR element.
4. Get your submission workflow ready for structured channels. If you're currently submitting by email, you'll need a submission workflow that can go through the digital gateway. This is usually an integration project, not a system replacement.
5. Handle structured feedback. When the market's systems reject a submission with a specific error code, your operations team needs a workflow that ingests the code, resolves it, and resubmits. This is where most manual coverholder ops break down.

What it doesn't require

Blueprint Two does not require:

• Rip-and-replace of your PAS
• A multi-year transformation programme
• Enterprise-scale consultancy engagement
• Dedicated in-house Blueprint Two team

What it does require is that your operational stack — PAS + bordereau generation + submission workflow — either produces CDR-compliant output natively or can be adapted to. For coverholders on modern platforms, this is a configuration task. For coverholders on older monolithic platforms with rigid schemas, it's a harder conversation.

The layered upgrade path

For small coverholders whose PAS can't easily accommodate the CDR structural requirements, the least disruptive path is a layered upgrade: keep the existing PAS as the record of transactions, and add a modern operational layer that captures the missing CDR fields, enforces the correct format at binding, and produces the compliant bordereau output.

The layered approach is measured in weeks rather than the years of a full PAS replacement. The trade-off is that it requires the underlying PAS to expose its data. For most coverholder-scale systems, this works. See the MGA solution page and our take on MGAs replacing legacy platforms without full replacement.

What good preparation looks like at 12 months out

• Every CDR field captured on the policy record, in the correct format, enforced at binding
• Bordereau generation produces CDR-compliant output as its default
• Submission workflow can go through structured channels, not just email
• Structured feedback loops handle rejection codes and resubmit automatically where appropriate
• Full audit trail on the CDR fields — including changes and endorsements — so you can prove compliance

For coverholders 6 months out, this list becomes the last-mile checklist. For coverholders 18 months out, it's the roadmap.

Bottom line

Blueprint Two's coverholder-facing requirements are less scary than the consultancy-framed version suggests. The CDR is a data structure. The digital gateway is a submission channel. Both are achievable with disciplined operational work rather than transformation programmes. What they don't forgive is a coverholder still running critical operations through email attachments and Excel spreadsheets — that operating model runs out of runway.

See the broader UK compliance overview for the operational baseline, and what auditors look for in a coverholder systems review for how Blueprint Two readiness intersects with existing audit expectations.