Direct answer: before a UK tour operator, OTA, airline retail desk, hotel group or travel ops team lets an **AI assistant confirm a booking** or **release a supplier payment**, the counterparty must already have been screened against the current **UK Sanctions List (UKSL)** — not the closed OFSI Consolidated List. From **9am UK time on Wednesday 28 January 2026**, FCDO’s UK Sanctions List became the **only** official source for UK sanctions designations. Asset-freeze and related financial prohibitions still mean you must not make funds or economic resources available to a designated person (or an entity owned or controlled by one) without an exception or OFSI licence. AI does not waive that duty.
That is the operator question Kaize is answering here. We are a UK AI product studio for travel and hospitality. This is not a sanctions-screener shopping list. It is a **control-stack** article: what must already be true in list source, match handling, ownership/control and human escalation **before** an agent is allowed to confirm inventory or move money to a supplier. It sits beside — and does not replace — our PCI DSS AI checkout, CMA AI-agent consumer-law, GDPR/ATOL booking-change and AI agent access-control pieces.
Primary evidence is first-party UK government: GOV.UK guidance Moving to a single list for UK sanctions designations, 28 January 2026; The UK Sanctions List; and OFSI’s UK financial sanctions general guidance (updated to reflect the Consolidated List closure). We do not invent client results, fine outcomes, GSC lifts or GEO ranks.
What changed on 28 January 2026 (and why travel AI stacks care)
HM Government moved to a **single list** for UK sanctions designations. The **OFSI Consolidated List of Asset Freeze Targets** closed and is **no longer updated**. Designations are published on the **UK Sanctions List**, maintained by the Foreign, Commonwealth & Development Office. Systems, vendor feeds and runbooks that still point at the old Consolidated List (or its search tool) are screening against a **stale source**.
For AI in travel ops this is concrete, not abstract. If your booking agent, supplier-onboarding bot or payment-release workflow calls a screening API that still keys off **OFSI Group ID** for **new** designations, or caches yesterday’s Consolidated List dump, the model can "confirm" a reservation or "pay the hotel" after a check that official guidance already says is the wrong list. GOV.UK is explicit: use UKSL data; for new designated persons subject to financial sanctions, use **Unique ID** (and Sanction Type) — newly designated DPs from 28 January 2026 are **not** assigned an OFSI Group ID.
- Point screening jobs at UK Sanctions List formats / static URLs — not the closed Consolidated List.
- Update identifiers: Unique ID for new DPs; historic Group IDs remain valid for pre-28 Jan 2026 designations where retained.
- If you use a third-party screener, require written confirmation that their feed is UKSL-primary after the cutover.
What financial sanctions actually prohibit near bookings and supplier pay
OFSI’s general guidance states that UK financial sanctions apply to all persons within the UK and to all UK persons wherever they are. Where the sanction is an **asset freeze**, it is generally prohibited to deal with frozen funds or economic resources of a designated person, or to **make funds or economic resources available**, directly or indirectly, to or for the benefit of a designated person — or a person owned or controlled by one — unless an exception applies or you hold an OFSI licence. Circumvention is also prohibited.
Travel makes those verbs operational: confirming a package, issuing a voucher, settling a DMC invoice, releasing a lodge-card authorisation, or letting an agent "just pay the supplier" are all ways of making funds or economic resources available. An LLM that is allowed to call `confirm_booking` or `release_payment` without a prior clear screen is an enforcement boundary, not a UX convenience.
- Treat guest, booker, payee, beneficial owner and supplier entity as screenable parties — not only the cardholder name.
- Remember ownership and control: more than 50% shares/voting rights, board appointment rights, or control in practice can pull an unlisted entity into scope.
- Name match ≠ target match: aliases, DOB, addresses and Unique ID matter; escalate ambiguous hits to humans.
Gate 1 — Screening source is UKSL, current, and logged
Before go-live, compliance and engineering must prove the AI path cannot confirm or pay unless a UKSL screen has run against the right parties with a logged result.
- Data source = UK Sanctions List (or a vendor feed contractually tied to it), with refresh cadence documented.
- No production dependency on the OFSI Consolidated List search for **current** designations.
- Store Unique ID / historic Group ID, screen timestamp, list version or hash, and parties screened on the booking/payment record.
- Re-screen on material change (new payee, ownership change, high-risk amendment) — not only at first create.
Gate 2 — AI cannot confirm or pay on an unresolved hit
Kaize POV: sanctions screening is a **hard gate**, not a soft suggestion the model may override because the guest is impatient. Tool permissions for confirm/pay must require a **clear** screening outcome. Potential target matches, incomplete identifiers and vendor timeouts must route to a human sanctions/compliance queue — the same discipline we argue for in how travel companies should control AI agents.
- Tool schemas: `confirm_booking` / `release_supplier_payment` refuse to execute without `sanctions_status=clear` (or equivalent) from a trusted service.
- Prompts must not instruct the model to "skip screening" or invent a clear result.
- False-clear pressure testing: inject known list names in UAT and prove the agent blocks.
Gate 3 — Human escalation, licensing and reporting stay outside the model
OFSI guidance distinguishes name matches from target matches and expects firms to freeze, not deal, and — where reporting obligations apply to relevant firms — to report as required. Licensing (where a ground exists) is an OFSI written permission process; it is not something a chat agent can invent mid-conversation. Keep escalation, licence applications and suspected-breach reporting in human-owned workflows with audit trails.
- Playbook for potential target match: stop confirm/pay, freeze relevant funds/resources if held, escalate, document.
- Do not let the assistant draft "we are licensed" claims unless a verified licence reference is attached by compliance.
- Align with your legal view of whether you are a "relevant firm" for mandatory OFSI reporting — AI cannot decide that away.
Gate 4 — Separate this from checkout CHD, consumer-law and border-check articles
Sanctions screening is about **who you may deal with and pay**. It is not PCI cardholder-data scope (PCI article), not CMA fairness of agent behaviour (CMA article), not ETA/EES eligibility before confirm (ETA / EES), and not GDPR/ATOL booking-change process. Operators need all of these gates; collapsing them into one "compliance prompt" is how gaps appear.
What this is not
- Not legal advice and not a claim that Kaize is your OFSI counsel or MLRO.
- Not permission to ignore ATOL, Package Travel, DMCC price display or consumer-law duties.
- Not a guarantee that fuzzy name match alone equals a designated person — or that a clear name match means you are safe without ownership/control checks.
- Not invented rankings, case studies, penalty amounts or "AI reduced sanctions risk by X%" claims.
Operator checklist (before production)
- Confirm UKSL is the screening source; Consolidated List retired for current designations.
- Map every AI path that can confirm inventory or move supplier funds.
- Enforce clear-status gate in tools; human queue for hits and timeouts.
- Log Unique ID / list version / parties / timestamp on booking and payment objects.
- Review ownership/control procedure for suppliers and corporate bookers.
- Kill-switch: disable AI confirm/pay without disabling read-only itinerary help.
FAQ
Can we keep using the OFSI Consolidated List search for "speed"?
No for **current** designations. GOV.UK states the Consolidated List closed on 28 January 2026 and is no longer updated; the UK Sanctions List is the only source for all UK sanctions designations. The old search remains historical only.
Is screening the guest enough if the hotel invoice is paid to a DMC?
Usually not. Funds made available to a payee that is designated — or owned/controlled by a designated person — can still breach prohibitions. Screen the payment counterparty and beneficial ownership where your risk process requires it, not only the passenger string the chatbot collected.
Does a clear screen let the AI ignore SCA or consumer-law duties?
No. Sanctions clear is necessary for dealing/paying; it does not replace Strong Customer Authentication near card checkout, ATOL disclosure, total-price display or CMA expectations for agent behaviour. Stack the gates; do not substitute them.
Kaize next step
If you are designing AI for booking confirmation, supplier settlement or agentic ops, start with the sanctions boundary: UKSL as source, hard clear-gate before confirm/pay, human escalation for hits. See services, thinking and contact. Related reading: control AI agents, PCI near checkout, CMA consumer law for AI agents.