Lloyd’s Blueprint Two: What Market Data Standards Mean for a Managing Agent’s Systems

In March 2026 Lloyd’s announced it was retiring the Blueprint Two name and the original vision behind it. If your managing agency read that as a reprieve on the data work, you read it wrong.

Blueprint Two was the London market’s grand digital transformation programme, conceived in 2020 and delivered through Velonetic, the market’s central processing bureau owned jointly by DXC, Lloyd’s and the IUA. It slipped repeatedly. Phase-one cut-over moved from 2024 into 2025; the full re-platforming onto cloud infrastructure is now not expected before 2028. After a review, Lloyd’s concluded the programme had not yielded the benefits originally envisaged and folded the ambition into an incremental, market-led modernisation run through Velonetic, with the existing bureau infrastructure sustained for years yet. The brand is being sunset. The direction is not.

This matters for one reason. The part of Blueprint Two that survived the reset intact is the part that was always the real work for a managing agent’s systems: structured, standards-conformant data. Everything else — the platform names, the phasing, the go-live dates — is the market’s problem to sequence. The data your systems produce is yours.

Free · 4 minutes

When two of your systems disagree, do you know which one to believe?

Fourteen questions on ownership, lineage, and quality — the difference between a number on a dashboard and a number you could defend. Banded finding on screen, full sheet by email.

What actually survived the reset

Strip the programme back to its load-bearing components and three of them are data, not platform. The Core Data Record — the defined set of data that must accompany a risk and a claim through the market’s processing rails. The move to ACORD global standards as the shared vocabulary for that data. And the structured reporting regime for delegated authority: bordereaux submitted through the Delegated Data Manager against defined coverholder and claims reporting standards, rather than as free-form spreadsheets.

None of those three depend on the re-platforming timeline. Lloyd’s has been explicit that data standards remain central to whatever modernisation now looks like, and that ACORD stays at the heart of it. The accounting-and-settlement and claims services being built to consume this data can slip to 2028 and beyond without changing the underlying demand: what flows into them has to be structured, complete and conformant on the way in. A later platform does not forgive earlier data.

What “structured and conformant” actually means for your systems

The comfortable reading of “data standards” is that it is a mapping exercise — take what you already hold, relabel the fields, send it on. It is not, and treating it as one is where managing agents lose time. A defined record built on a shared standard imposes three obligations your legacy systems may not currently meet.

Completeness at source. The record specifies fields that must be populated for a submission to be valid. If your underwriting or binding systems never captured a value — because a human filled it in on a slip later, or because it lived in an email — you cannot map your way to it. You have to capture it upstream, at the point the business is written, which is a workflow change, not a data change.

Conformance, not just format. Sending well-formed data in the right schema is necessary but not sufficient. Values have to conform to the standard’s code lists, reference data and validation rules — the same discipline anyone who has lived through a payments-messaging migration will recognise. The lesson from the ISO 20022 cut-over in payments is that the migration is where firms spend the effort, but the value only arrives once the richer, structured data is actually used downstream rather than treated as a compliance tax. Insurance is running the same play a few years behind.

Machine-to-machine exchange. The direction of travel is submission through gateways and APIs against a published contract, not documents attached to a workflow. That makes conformance measurable and enforceable at the boundary. This is the same principle now showing up across regulated data flows generally — the standards your platform is measured against increasingly sit at the interface, where either your output validates or it is rejected, with no human on the other side to interpret good intentions.

The failure mode: PDFs and spreadsheets that do not clear

Here is the concrete risk, and it is not abstract. A managing agent whose data production still ends in a bordereau spreadsheet emailed to a broker, or a PDF endorsement, is producing artefacts the new rails are designed not to accept. For a transitional period the market tolerates both, because it has to. That tolerance is the trap. It lets a firm defer the work while the deadline that matters — the point at which non-conformant submissions stop processing cleanly — moves closer without a fixed date attached to it.

When that boundary tightens, the failure is quiet and operational rather than a single dramatic cut-off. Submissions get rejected or queried, settlement is delayed, claims data has to be reworked by hand, and the agents who prepared find they can transact while the agents who waited find they cannot. Because the timeline is genuinely uncertain, the rational response is not to wait for certainty. It is to make your data production conformant now and stop caring what the platform is called this quarter.

What to build, and who owns it

The work sits in your data production layer, not your reporting layer, and that distinction decides whether you do it once or repeatedly. Bolting a translation step onto the end of a legacy process gets you through the next submission and leaves you re-doing it every time the standard revises. Capturing the required data as structured, validated values at the point of underwriting and binding — with reference data and code lists managed as a governed asset — gets you a source you can serve to the market, to your own analytics, and to the AI use cases everyone is now asking about. Well-structured, well-governed data is the substrate those depend on; it is the same reason AI-ready data management leans so heavily on disciplined structure. You are not building for Blueprint Two. You are building a clean data source that happens to satisfy it.

Ownership is the other half. If this lands solely with a data team told to “produce the bordereaux”, it will be a mapping exercise and it will fail at the completeness test above, because the missing fields are captured — or not — in underwriting workflow the data team does not control. The people who write the business have to be part of the change.

Who this is for

  • Managing agents whose submissions to the market still originate as spreadsheets and documents rather than structured data.
  • CTOs and COOs who read the 2026 Blueprint Two announcement as a reason to slow down.
  • Delegated-authority teams reliant on coverholder and claims bordereaux that will have to clear the Delegated Data Manager.
  • Boards that want to know whether their firm can transact cleanly when tolerance for non-conformant data runs out.

The programme has changed its name and lost its original deadline. The requirement that your systems produce structured, standards-conformant data survived all of it. A firm that mistakes the branding turbulence for a reprieve is deferring the one part of the work the reset left standing.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.

Most technology problems are not technology problems. They are control problems.

The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.