Motor
A2A Motor Insurance Agent Standard
Version: 0.2 (Draft for Comment)
Status: Working Draft. Supersedes v0.1.
Steward: Marrow (onmarrow.com), on behalf of the Agent-to-Agent (A2A) working group
Line of business: UK private motor
Published: June 2026
This is a draft request for comment. It defines how an autonomous AI agent should request, compare, and transact a UK private motor insurance quote against a regulated carrier, in a way that is safe, auditable, and carrier-agnostic. It is published openly so that carriers, agent platforms, and regulators can converge on a single shape rather than a hundred bespoke integrations. Comments to standards@onmarrow.com.
Foundational dependency. This standard relies on the A2A Core Patterns Standard for all shared behavioural rules (grounding and no fabrication, assume-infer-confirm, the advice-versus-information boundary, disclose-and-acknowledge, fair presentation, honest absence and uncertainty, data protection, vulnerability and Consumer Duty, handover machinery, and audit) and the canonical roles, and on the A2A Consent, Authority and Scopes Standard for authentication and transaction authority. Only the rules distinctive to motor are stated in full below.
What changed in v0.2, and why
v0.1 was drafted from the canonical-schema spine and general knowledge of UK motor proposal forms. v0.2 is validated against the authoritative UK sources that actually govern motor data capture and underwriting. The validation changed the centre of gravity of the standard.
The headline change: the agent should look up, not ask. Most of the facts v0.1 told the agent to collect from the customer are available from authoritative databases keyed off two identifiers, the vehicle registration and the driving licence number. A standard that has the agent interrogate the customer for licence-held-years, entitlement, penalty points, vehicle specification and value is both worse UX and worse data quality than one that retrieves those facts and asks the customer only to confirm them. v0.2 makes database enrichment the primary path and customer questions the fallback. This is also the clearest possible demonstration of why an agentic rail is better than a web form: the form asks twenty questions, the agent asks for two identifiers and confirms the rest.
Material fields v0.1 missed, now added, each with a documented basis:
- Driving licence number as the key enrichment identifier (drives MyLicence/IIADD lookup), and National Insurance number where required for identity.
- Previous insurance refused, cancelled, voided, or accepted on special terms. A material underwriting and non-disclosure question with a permanent record; its omission in v0.1 was the most serious gap.
- Homeowner status and UK residency duration, both standard rating factors.
- All household members who may drive the vehicle (fronting and undisclosed-driver risk).
- Vehicle security (alarm, immobiliser, tracker), daytime parking distinct from overnight garaging, keeper and purchase dates, and import status.
- The distinction between claim-free years as a main driver and years of no-claims discount, which v0.1 conflated.
- Convictions captured by DVLA offence code, points, date, and alcohol or accident involvement, rather than as free text.
- Anti-fraud and verification database hooks (CUE, MIAFTR, MID) that the standard must anticipate even though they run rail-side.
What stayed the same: the design principles, the agent behavioural rules, the handover triggers, and the audit model from v0.1 all hold and are unchanged in substance.
Sources and provenance
This draft is validated against the following. Where a field or rule below cites a basis, it refers to this list.
- Polaris UK is the digital trading standards body for UK general insurance. Its Polaris Online Database (POD) publishes the EDI, XML, and JSON message definitions and the industry code lists for personal and commercial lines. The XML and JSON standards support both quotation and placement. The canonical motor schema in this standard should align to Polaris code lists field-for-field; see the confidence note below on what that requires.
- MyLicence (IIADD) is the Insurance Industry Access to Driver Data database, reached via the MIB Hub's secure link to DVLA licence data. Given a 16-character driving licence number, it returns licence type, entitlement, endorsement codes, penalty points, disqualifications, and licence duration. It is the authoritative source for the driver-history fields.
- CUE (Claims and Underwriting Exchange), managed by Insurance Database Services Limited under the MIB, holds UK claims records and is checked at quote to verify claims history.
- MIAFTR (Motor Insurance Anti-Fraud and Theft Register), MIB-managed, records written-off and stolen vehicles; checked against the registration.
- MID (Motor Insurance Database), MIB-managed, is the record of insured vehicles.
- DVLA vehicle data resolves specification, and DVLA offence codes are the canonical representation of motoring convictions.
- Defaqto maintains the UK's largest product-feature database and scores motor policies against 30 to 100 features and benefits. The canonical cover-feature taxonomy in the quote response should map to Defaqto's feature set. Marrow has Defaqto wired into the rail, which makes this both achievable and a defensibility point.
- UK aggregator and insurer question sets (Confused.com, Compare the Market, Aviva, Admiral, NFU Mutual and others) corroborate the customer-facing field list and the social/commuting/business class-of-use conventions.
Confidence statement
What is locked: the structure of the standard, the identifier-led enrichment model, and the existence and role of every database and code-list source above are confirmed against public documentation and corroborated across multiple insurers and aggregators.
What is not yet locked: the exact canonical code lists (occupation codes, vehicle modification codes, conviction code subsets, cover-feature enumerations) require licensed access to the Polaris POD and the Defaqto data dictionary to reproduce field-for-field. v0.2 aligns to these sources conceptually and names them; v0.3 should be produced after Marrow takes POD access, at which point the standard can credibly claim conformance to the UK motor data standard rather than alignment with it. Acquiring POD and Defaqto access is therefore both the next validation step and, in itself, a credibility and moat asset worth citing to carriers.
1. Why this standard exists
An AI agent can already talk about insurance. It cannot reliably buy it. The reason is not model capability. It is that there is no agreed, machine-readable contract for what an agent must establish, what a carrier must return, and what neither side is permitted to do. Without that contract, every agent-to-carrier connection is hand-built, every carrier behaves differently, and the agent is one hallucinated premium away from a regulatory breach.
This standard fixes the contract for one line of business: the canonical quote request, the enrichment that populates it, the canonical response, and the behavioural rules that keep the agent inside UK regulatory expectations (FCA Consumer Duty, the advice-versus-information boundary, fair presentation). A carrier that exposes motor through this shape, and an agent that consumes it, interoperate without bespoke work, and a regulator can read one document to understand how the transaction is governed.
2. Design principles
The shared design principles (carrier-agnostic by construction; look up, do not ask; no fabrication; assume-infer-confirm; disclose-and-acknowledge; observable compliance) are defined in the A2A Core Patterns Standard and apply in full. Motor is the exemplar of look up, do not ask: the registration and the licence number key almost the entire risk picture, so the agent retrieves and confirms rather than interrogating.
Live demo
The same protocol, walked through interactively. The left panel is the agent's conversation; the right is the canonical motor_quote_request building up, every value tagged with its provenance — enriched, attested, derived, or asked. The Bind & pay action stays locked until all six conditions of the bind precondition invariant (defined in the New Business Standards) are met. Step through it:
3. Roles and terms
Roles and terms (Customer, Agent, Surface, Rail, Carrier, Material fact) are defined in the A2A Core Patterns Standard. No motor-specific roles are added.
4. Canonical motor quote request
The agent assembles a motor_quote_request. Fields are marked enrichable (the rail can populate from an authoritative source; the customer still confirms), required (must be present or confirmed before a quote call), or conditional.
4.1 Identifiers (enrichment keys)
| Field | Type | Notes |
|---|---|---|
vehicle_registration | enrichable key | Resolves the entire vehicle block via DVLA and vehicle data, and keys MIAFTR. Prefer this over asking the customer to describe the vehicle. |
driving_licence_number | enrichable key | 16-character DLN. Keys MyLicence/IIADD, which returns entitlement, endorsements, penalty points, disqualifications, and licence duration. Captured per driver. Basis: MyLicence. |
national_insurance_number | conditional | Where a carrier requires it for identity or NCD verification. PII; tokenised by the rail. |
4.2 Proposer and drivers
An array of one or more drivers; the proposer is flagged. Per driver:
| Field | Required | Basis / notes |
|---|---|---|
date_of_birth | required | Rating and eligibility. |
relationship_to_proposer | required | |
occupation and employment_status | required | Polaris occupation code list. Full-time, part-time, self-employed, plus occupation and employer where relevant. |
licence_type | enrichable | From MyLicence; confirmed by customer. |
licence_held_years / test_pass_date | enrichable | From MyLicence. Replaces asking the customer. |
entitlement | enrichable | From MyLicence. |
convictions | enrichable | From MyLicence where available; each as DVLA offence code, date, points, and alcohol or accident involvement. Default empty, confirmed not assumed. Basis: MyLicence, DVLA offence codes. |
medical_conditions_dvla_notifiable | required | Boolean attestation, not detail. |
homeowner_status | required | Standard rating factor. |
uk_residency_since | required | Standard rating factor. |
claims_history | enrichable | Per driver, five-year. From CUE, confirmed by customer; each claim with date, type, fault status, cost band. Basis: CUE. |
access_to_other_vehicles | optional | Rating factor. |
4.3 Household
| Field | Required | Notes |
|---|---|---|
household_members_who_may_drive | required | All resident members who may drive, listed or explicitly excluded. Addresses fronting and undisclosed-driver risk. |
4.4 Vehicle (enriched from vehicle_registration)
| Field | Required | Basis / notes |
|---|---|---|
make / model / variant / year / fuel / engine | enrichable | DVLA and vehicle data. |
abi_code / insurance_group | enrichable | Rating keys; from vehicle data. |
value | enrichable | Confirmed by customer. |
modifications | required | Explicit attestation; material non-disclosure risk. Default null, never silently assumed absent. |
security | required | Alarm, immobiliser, tracker. Rating factor. |
ownership and registered_keeper | required | Owner, registered keeper, or neither. |
keeper_since / purchase_date | optional | |
import_status | conditional | Imported or grey import affects rating and eligibility. |
overnight_location | required | Garage, driveway, street, car park. Defaults to proposer postcode garaging, confirmed. |
daytime_location | optional | Where different from overnight. |
write_off_theft_flag | enrichable | From MIAFTR; surfaced if the vehicle has a recorded write-off or theft marker. Basis: MIAFTR. |
4.5 Usage
| Field | Required | Notes |
|---|---|---|
class_of_use | required | Social and domestic only; plus commuting; plus business. Aggregator-standard conventions. |
annual_mileage | required | |
commute_destination | conditional | Required when class includes commuting. |
4.6 Cover
| Field | Required | Notes |
|---|---|---|
cover_type | required | Comprehensive, third party fire and theft, third party only. |
voluntary_excess | required | |
ncd_years | required | No-claims discount; subject to proof at bind. |
claim_free_years_as_main_driver | required | Distinct from NCD years; do not conflate. |
cover_start_date | required | |
payment_frequency | required | Annual or monthly; monthly implies a credit agreement with its own disclosure. |
telematics_opt_in | optional | Whether a telematics or black-box product is acceptable. |
addons | optional | Canonical list: breakdown, legal expenses, courtesy car, protected NCD. |
4.7 Declarations (history and anti-fraud)
| Field | Required | Basis / notes |
|---|---|---|
previous_insurance_refused_cancelled_voided | required | Ever refused, cancelled, voided, or accepted on special terms. Material, permanent record, high non-disclosure risk. The most significant addition in v0.2. |
named_driver_exclusions | optional | Any household member explicitly excluded. |
5. Enrichment and verification hooks
The rail performs these between request assembly and the carrier call. Results are returned to the agent for customer confirmation, never used silently in a way the customer has not seen. Verification hooks (CUE, MIAFTR, MID) may also run as carrier-side checks at or after quote.
| Hook | Source | Populates / checks | Basis |
|---|---|---|---|
vehicle_lookup | DVLA + vehicle data | Specification, ABI code, insurance group, value from registration. | DVLA |
licence_lookup | MyLicence / IIADD via MIB Hub | Licence type, entitlement, endorsements, points, disqualifications, licence duration, test pass date. | MyLicence |
claims_check | CUE (IDSL / MIB) | Verifies and pre-fills claims history. | CUE |
vehicle_theft_writeoff_check | MIAFTR (MIB) | Write-off or theft markers on the vehicle. | MIAFTR |
insured_status_check | MID (MIB) | Existing insured status. | MID |
postcode_risk | Postcode metadata | Flood zone, crime band, area rating context. | Aggregator convention |
address_verify | Address lookup | Garaging address normalisation. | - |
A carrier may override any enrichment source with its own preferred vendor; the canonical field names do not change.
6. Canonical motor quote response
The carrier (via the rail) returns a motor_quote_response containing zero or more quote objects. Zero quotes is a valid, first-class response meaning no appetite, and the agent must represent it honestly.
Each quote object:
| Field | Notes |
|---|---|
carrier_quote_reference | Required for bind. |
annual_premium / monthly_premium | As returned. The agent must not recompute or independently annualise. Where monthly, the credit agreement and APR are disclosed. |
cover_type | Echo of the rated cover. |
compulsory_excess / voluntary_excess | |
cover_features | Structured against the Defaqto feature taxonomy, so cover can be compared like-for-like across carriers rather than on price alone. Basis: Defaqto. |
key_exclusions | Structured list; surfaced under disclose-and-acknowledge. |
priced_addons | Each add-on priced separately; never bundled silently. |
ipid_url | Insurance Product Information Document. |
validity_expires_at | Quote expiry; an expired quote must not be presented as live. |
appetite_status | quoted, declined, or referred. A referral routes to human handover. |
7. Agent behavioural rules (compliance semantics)
The general behavioural rules (no fabrication, information-not-advice, material-fact confirmation, disclose-and-acknowledge, PII minimisation, fair presentation across carriers, honest absence) are defined in Core Patterns Section 2 and apply in full. Motor-specific emphasis:
- Material facts attested before bind: modifications, convictions, claims, class of use, garaging, household drivers, and the previous-insurance-refused-cancelled-voided declaration.
- Identifier tokenisation: the driving licence number and National Insurance number are tokenised by the rail before they reach model context or logs.
- Monthly-payment disclosure: where premium is paid monthly, the credit agreement and APR are disclosed under disclose-and-acknowledge.
8. Handover triggers
The shared handover machinery and common triggers are defined in Core Patterns Section 2.9. Motor-specific triggers, additional to those: a MIAFTR or CUE flag requiring underwriter review; an unresolved conflict between an enriched value (for example MyLicence) and a customer attestation; or a complex claims, conviction, or previous-refusal profile the canonical schema cannot represent.
9. Audit requirements
Audit requirements are defined in Core Patterns Section 2.10 and apply in full. Motor-specific evidentiary emphasis: the enrichment and verification calls (DVLA, MyLicence, CUE, MIAFTR, MID) and their results, and each material field marked as enriched or attested.
10. Versioning and conformance
This standard is versioned (v0.2) and relies on the A2A Core Patterns Standard and the A2A Consent, Authority and Scopes Standard; conformance requires conformance to those at a declared version. A conformant agent implements Sections 4 through 9 in full. A conformant carrier maps its motor product to the canonical request and response and supplies the IPID and appetite semantics. Partial implementations declare which sections they omit. v0.3 follows Polaris POD and Defaqto data access and will move the standard from alignment with the UK motor data standard to conformance with it.
11. Open questions for comment
- Locking the canonical occupation, modification, conviction, and cover-feature code lists against Polaris POD and Defaqto.
- Whether
ncd_yearsproof should be pre-bind or post-bind in the canonical flow. - The minimum claims and convictions lookback the standard should mandate versus leave to carrier appetite.
- How advised sales should be represented when an agent operates under a permission to advise.
- Multi-carrier ordering disclosure: the minimum the standard should require an agent to tell the customer.
Published as an open standard. Marrow stewards the drafting but does not assert proprietary control over the interface; the compliance, enrichment, and audit implementations behind it are separate. Carriers, agent platforms, and regulators are invited to adopt, critique, and co-author future versions.