Direct answer: before a UK airline, ferry, international rail operator, tour operator selling flight-inclusive packages, OTA or booking agent lets an **AI assistant or agent confirm, ticket, rebook or board** a passenger on a journey **to or from the UK**, you must already know whether **Advance Passenger Information (API)** / travel-document information has been (or will be) submitted in the **form and manner** the Home Office requires, whether your stack can **send and receive** Border Force communications about that submission, and what happens when **Authority to Carry (ATC)** is **refused**. Submitting the required passenger and crew information is treated as a **request for authority to carry**. If authority is refused, the carrier **must not carry** that person. An AI that "confirms" the booking while ATC is refused — or while API was never sent on a compatible two-way system — is not a product feature. It is an ops and liability failure.
That is the operator question Kaize is answering here. We are a UK AI product studio for travel and hospitality. This is not a Border Force implementation manual and not legal advice. It is a **control-stack** article for product and ops leaders: what must already be true before an agent is allowed to **confirm travel** on UK routes where API and ATC apply. It sits beside — and does not replace — our UK ETA checks before inbound confirmation, EES / Schengen outbound checks, UK Sanctions List screening before confirm/pay and AI agent access-control pieces.
Primary evidence is first-party Home Office / GOV.UK: The Immigration (Form and Manner of Passenger and Service Information) Direction 2026 (in operation from **7 January 2026**; accessible text published **23 February 2026**); the Authority to Carry Scheme 2023 (in force **3 April 2023**, page updated **27 July 2026** with passenger-facing refusal wording); and Home Office guidance on providing information about scheduled aviation flights (API / TDI to Border Force; online APIS route). The Direction points at the **Immigration and Police (Passenger, Crew and Service Information) Order 2024** (S.I. 2024/1227) for what information is specified. We do not invent client outcomes, penalty cases, GSC lifts or GEO ranks.
API is not the same as ETA or EES — and AI must not conflate them
**ETA** is a passenger permission to travel to the UK. **EES** is the EU Entry/Exit System for Schengen border processing. **API / ATC** is the **carrier-side** stack: submit passenger (and crew) information in the required electronic form, treat that as a request for authority to carry, receive Home Office messages, and **not board** anyone for whom authority is refused. An AI that only checks "does this person have an ETA?" and then confirms the booking has answered a different question. ETA can still be cancelled or refused in ways that are not obvious to a carrier until API / ATC messaging runs — the Authority to Carry Scheme itself notes that it will not always be apparent to a carrier when an ETA has been refused or cancelled.
For product owners the practical rule is: **eligibility UX** (ETA/visa/passport) and **carrier border messaging** (API + ATC) are separate gates. Both may be required. Neither is optional just because a generative assistant drafted a confirmation email.
- Do not let the agent treat "passenger typed passport details" as "API submitted to Border Force".
- Do not let the agent treat "ETA looks valid in a third-party check" as "authority to carry granted".
- Do not let the agent invent a boarding or ticket-confirm event while ATC refusal messaging is open or unresolved.
What the 2026 Direction actually changes for operators
The Immigration (Form and Manner of Passenger and Service Information) Direction 2026 sets **how** carriers must provide passenger and service information required under the 2024 Order. For aircraft, Schedules 1 and 2 information must be provided as specified in the **UK Generic Carrier Interface Control Document** (UK_ICD_D0081, **Version 14.2 or later**). Rail and maritime (non-cruise) point at the rail/maritime API ICD (**RM_API_ICD**, Version **1.7 or later**); cruise has its own National Maritime Single Window guide. PNR (Schedule 3) for aircraft must use **PNRGOV EDIFACT** version **11.1 or later** over **IBM MQ**; rail/maritime PNR has its own ICD floor.
Critically for AI product design, paragraph 5 requires information in an electronic form **compatible with Home Office technology** and by means of a system that enables the carrier to **send and receive communications** relating to the information submitted. That two-way requirement is exactly what ATC process language also assumes: carriers required to send information electronically compatible with the Government’s Border System should seek authority to carry using such a system, and must be able to receive grant/refusal notifications.
- Version-pin your carrier interface docs (ICD floors are explicit — "or later" is not "whatever the vendor shipped in 2022").
- Treat technical failure fallbacks as governed paths (prior agreement of an immigration officer / Home Office liaison) — not as an AI improvisation channel.
- If your AI sits above a GDS, NDC retailer, consolidator or host airline PSS, map **who** is the carrier for API/ATC and **who** owns the confirm event in your product.
Gate 1 — Is this journey in scope for API / ATC?
Before an agent can confirm, classify the journey and the actor.
- Carrier class: aircraft, ship, international rail service operating to/from the UK where passenger/crew information has been required under the relevant Immigration Act / 2006 Act powers (or voluntarily submitted, which the Scheme still treats as a request for authority to carry).
- Passenger/crew in scope: the Scheme applies to passengers and crew travelling or expected to travel to or from the UK on a covered carrier class (with the voluntary-submission nuance).
- Your product role: operating carrier, agent, OTA, tour operator, or AI vendor writing into someone else's PSS — each needs a written RACI for who submits API and who must honour ATC refusal.
Gate 2 — Can we submit complete API and receive ATC messages?
Authority to Carry Scheme process language is blunt: providing the required passenger, crew and service information **constitutes a request** for authority to carry; **failure to provide the information at all** is a breach. Carriers will be informed if they do **not** have authority to carry any person — and those persons **should not be carried**. Civil penalties under the ATC penalty regime can reach **up to £50,000 per breach** (per person not sought / carried after refusal), separate from carriers’ liability for inadequately documented passengers.
- Block AI confirm/ticket/board tools until the booking has the data fields your API path needs (identity, travel document, flight/voyage/service identifiers as required).
- Require a machine-readable ATC outcome channel (grant assumed only under your documented carrier SOP — e.g. no refusal received by a defined cut-off — never "model thinks it is fine").
- On ATC refusal: hard-stop boarding and confirmation; surface the Home Office-provided form of words and Passenger Advice Line contacts to the passenger; do not let the agent rewrite or soften the refusal message.
Gate 3 — What AI may draft vs what it must never decide
Kaize POV (labelled): generative models are useful for **drafting** passenger explanations, ops checklists and exception queues. They are the wrong component to **decide** that a UK journey is confirmed when API/ATC state is incomplete. Wire tools so the model can propose "collect missing passport MRZ", "queue for carrier API retry", or "open human ops case after ATC refusal" — and cannot call `confirm_booking`, `issue_ticket` or `mark_boarded` while API submission or ATC response state is red.
- Allow: draft passenger messaging after a verified ATC refusal using the mandated wording supplied to the carrier.
- Allow: summarise which API fields are missing for a human agent.
- Deny: inventing an ATC grant; ignoring a refusal; confirming packages that include a UK air sector when the operating carrier has not completed API/ATC.
Gate 4 — Package / OTA / AI-vendor seams
Most AI booking assistants do not own the aircraft. Flight-inclusive packages, merchant-of-record OTAs and multi-carrier itineraries create seams where the customer-facing "confirmed" event drifts ahead of the operating carrier's API/ATC timeline. Before you ship an agent that confirms UK travel, write the seam contract: which system of record owns passenger biographic/document data; which party submits API; how ATC refusals propagate back into your CRM and customer channel within minutes, not "next batch job".
If you cannot name that contract, the agent should stop at **"prepared for human confirmation"** — the same control pattern we argue for rebooking, sanctions screening and border eligibility elsewhere in the journal.
Gate 5 — Evidence, monitoring and incident drill
Keep documentary evidence that (1) ICD versions in production meet the Direction floors, (2) two-way messaging was available for the flight/voyage, (3) ATC refusals were actioned (no board / no confirm), and (4) passenger communications used the provided form of words. Run a tabletop: API outage mid-book, late ATC refusal after customer-facing "confirmed", and cancelled ETA that only surfaces via ATC. Measure mean time from refusal message to booking-state change in your PSS/CRM — not chatbot sentiment.
FAQ
**Does this replace ETA checks?** No. ETA (and visa) eligibility remains a passenger-documentation / carriers’ liability question. API/ATC is the carrier messaging and authority-to-carry stack. Run both where they apply.
**Does submitting API always mean we may board?** Submitting required information is a **request** for authority to carry. You must still honour refusals and have a system capable of receiving them. Do not treat "we uploaded a spreadsheet" as "authority granted" unless your documented carrier SOP and Home Office channel say so.
**Can disclosure that "AI confirmed this" cure a bad ATC path?** No. Labelling an AI confirmation does not create authority to carry or cure a missing API submission.
What Kaize will (and will not) build here
Kaize builds AI product controls around how travel actually works — including hard stops when border and carrier messaging state is incomplete. We will help you map confirm/ticket/board tools to API/ATC state machines and human escalation. We will not claim a turnkey Home Office certification, invent ATC outcomes, or ship an agent that confirms UK travel while refusal messaging is unresolved. If that is the control conversation you need, start from what we build, how we think, or contact.