Insights Travel Compliance 9 min read

Block AI From Completing UK Package Sales Until PTR Insolvency Cover Is Named

Before an AI assistant or agent binds a traveller to a UK package travel contract, Part 5 of the Package Travel Regulations 2018 requires effective insolvency security — and the Schedule standard information forms require the protector to be named with contact details. Missing those fields is a hard stop, not a footnote.

Direct answer: before a UK tour operator, OTA, hotel group or travel agent lets an **AI assistant or agent complete a package sale, take payment for a package, or tell a traveller they are booked**, the booking path must already know — and show — **which insolvency protector covers that organiser for that sale**, with the entity’s **name and contact details**, under The Package Travel and Linked Travel Arrangements Regulations 2018 (regulation 19 Part 5 security; regulation 5 and Schedule 2 pre-contract information). An agent that bundles flight + hotel, confirms the PNR, and leaves “insolvency protection” as a generic footer is not clever automation. It is a point-of-sale failure against a criminal offence for organisers who fail to provide the security.

That is the operator question Kaize is answering here. We are a UK AI product studio for travel and hospitality. This is not legal advice and not a substitute for reading the live Regulations, BEIS/DBT business guidance, or CAA ATOL advice where flights are in scope. It is a **control-stack** article: what must already be true on the booking record before an AI is allowed to **bind a UK package travel contract**. It sits beside — and does not replace — our PTR 2026 booking-journey redesign (that page is about the April 2027 package definition, LTA removal and supplier refund clocks), our ATOL AST-14 booking-assistant disclosure (ATOL certificate and choice disclosures for flight-inclusive products), and our ATOL AST-13 ad controls (what must be true before AI publishes ATOL ads). This article is narrower: **Part 5 insolvency cover must be live and named** before confirmation.

What regulation 19 actually requires of the organiser

Regulation 19(1) is blunt. The organiser of a package who is established in the United Kingdom **must provide effective security** to cover, in the event of the organiser’s insolvency, the reasonably foreseeable costs of (a) **refunding** payments for travel services not performed as a consequence of the insolvency, and (b) where carriage of passengers is included and performance is affected, **repatriating** the traveller and, if necessary, financing accommodation prior to repatriation. Regulation 19(5) requires that one of the listed arrangements — bonding under regulations 20 or 21, insurance under regulation 22, or monies in trust under regulations 23 and 24 — is in force, subject to the ATOL carve-out in regulation 19(6) for packages that must be ATOL-licensed or are already covered by ATOL arrangements.

Regulation 19(9) makes failure to comply with paragraphs (1) to (5) an **offence**. That is not a soft “best practice” for an AI product team to park in a backlog. For an AI booking path it means three product facts:

  • Every AI-owned sales channel that can complete a UK **package** booking — chat, voice, agent tool, package builder, NDC wrapper that creates an organiser package — is a path that can create organiser liability. If the path can bind the traveller, the path must know whether Part 5 security (or ATOL cover where 19(6) applies) is in force for that sale.
  • “Insolvency protection exists somewhere in the company” is not enough. The Schedule standard forms require the traveller to be told **which entity** provides the protection and how to contact it.
  • An LLM paraphrase in the transcript (“you’re covered if we go bust”) is not security under regulation 19 and is not the Schedule wording. The booking system of record must hold the protector identity and the confirmation artefacts.

What the Schedule forms force onto the AI checkout

Regulation 5 requires the relevant person to provide Schedule 1 information where applicable **before** a package travel contract is concluded, plus the standard information forms. Schedule 2 (where hyperlinks are possible) is explicit in Part 1: the combination is a package; the company is responsible for proper performance of the package as a whole; and **as required by law** the company has protection in place to refund payments and, where transport is included, ensure repatriation if it becomes insolvent. Part 2’s key-rights list ends with the same hard requirement in concrete fields: if the organiser or retailer becomes insolvent, payments will be refunded and repatriation secured where transport is included; **XY has taken out insolvency protection with YZ** (the entity in charge — for example a guarantee fund or insurer); travellers may contact that entity or the competent authority with **name, geographical address, email and telephone number** if services are denied because of insolvency.

BEIS/DBT’s Package Travel Regulations 2018 guidance for businesses restates the same pre-sale duty: key information and the standard information forms must be provided in a clear, comprehensible and prominent manner before selling the package. ATOL remains the mechanism for flight-inclusive packages that fall under the CAA ATOL Regulations; non-flight packages still need one of the Part 5 arrangements. An AI that “summarises consumer rights” without injecting the live **YZ protector** fields has not complied with the form — it has performed a chat.

The five gates before AI may complete the package sale

Gate 1 — Package classification is on the booking record before confirmation

If the sale is not a package, Part 5 does not apply in the same way. If it is a package, everything below applies. The AI must not invent classification in prose. Persist whether this booking is a package, which components form it, and who the organiser is — the same systems discipline we argue for on the PTR 2026 journey page. Gate 1 fails if the agent can confirm while classification is still “TBD”.

Gate 2 — Effective security is selected and in force for this organiser

Map the sale to ATOL (where regulation 19(6) applies) or to bonding / insurance / trust under regulations 20–24. The booking file needs the mechanism type and evidence that the arrangement is **in force** for the period covering payments taken now. Gate 2 fails if cover expired last quarter, if the AI is selling under a white-label brand whose organiser entity is not the one on the bond, or if the only “evidence” is a PDF in a compliance drive the checkout cannot read.

Gate 3 — Protector entity YZ is a first-class field, not marketing copy

Schedule 2 requires the named insolvency entity and contact details. Store protector name, geographical address, email and telephone on the product or organiser profile the AI reads at confirmation time. Gate 3 fails if the agent invents a phone number, omits the entity because the prompt was too long, or shows yesterday’s insurer after a mid-year novation.

Gate 4 — Standard information is shown before the traveller is bound

Regulation 5 timing is **before** the contract is concluded. For an AI path that means: Schedule information and the standard form content (or compliant hyperlink pattern where Schedule 2 allows) must be delivered in the same session **before** payment capture and before “you’re booked” language. Gate 4 fails if the rights dump arrives only in a post-purchase email the traveller never opened, or if a voice agent completes the sale and promises to “send the paperwork later.”

Gate 5 — Confirmation artefacts match the reservation row

The confirmation the traveller can keep must name the same organiser and the same insolvency protector as the booking system of record. Divergence between chat summary, PDF and reservation row is the failure mode we already flag when travel AI changes a booking under UK GDPR and ATOL. Gate 5 fails if the AI confirms one protector and finance later invoices under another.

What this is not (duplicate fence)

A practical control stack for AI package agents

Evidence anchors (read these, do not invent outcomes)

What Kaize will and will not automate

Kaize builds AI product for travel and hospitality operators. We will help design **classification, cover-status, named-protector, pre-contract timing and confirmation-match** controls so an assistant cannot complete a UK package sale while insolvency fields are missing or invented. We will not claim a chat model “is PTR compliant,” invent traveller refund outcomes, underwrite insolvency cover, or replace ATOL licensing advice. The organiser and their systems of record stay accountable; the AI stays behind the gate.

If you are wiring an AI agent into UK package sales and want a control review against Part 5 / Schedule-named insolvency evidence — not a brand rewrite — discuss a project with Kaize.

Related Kaize journal