Join our Newsletter — 33% off our NHI Course
Home FAQ Cyber Security How do security teams spot book-and-switch fraud in…
Cyber Security

How do security teams spot book-and-switch fraud in travel flows?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated September 7, 2026 Domain: Cyber Security

Look for long-dated bookings, itinerary edits, and unusual device or network combinations that appear consistent only when viewed in isolation. Fraud rings use these patterns to avoid red flags and extend the time before chargeback processing. A useful detection model links these behaviours across the full booking journey.

Why Book-and-Switch Fraud Slips Past Point-in-Time Checks

Book-and-switch fraud is hard to catch because the attacker’s behaviour is designed to look normal at each individual step. A booking may appear legitimate, the later itinerary change may look like ordinary customer activity, and the device or network used may not stand out on its own. The risk is not a single bad event but the way multiple low-signal actions combine into a misleadingly clean profile. Security teams that focus only on isolated alerts often miss the coordinated pattern. In practice, many fraud teams discover the pattern only after chargeback disputes have already matured, rather than through intentional end-to-end journey analysis.

For control design, NIST SP 800-53 Rev. 5 helps frame the problem as a detection and correlation issue rather than a single-rule problem; teams need telemetry that can be tied across events, not just screened event by event. See NIST SP 800-53 Rev 5 Security and Privacy Controls.

How the Booking Journey Reveals the Fraud Pattern

Book-and-switch detection works best when security, fraud, and payments data are analysed as one chain. The first booking creates a baseline, but the important signal usually appears later when the same record is edited, reissued, or paired with a device, IP range, or behavioural profile that does not match the original purchase context. The goal is not to treat any one attribute as proof of fraud. The goal is to see whether the sequence is coherent across time, actor, and channel.

Common indicators include:

  • Long-dated travel or delayed fulfilment that increases the window for abuse.
  • Booking edits that shift names, dates, routes, or passenger details after the initial purchase.
  • Repeated use of the same device, payment pattern, or account cluster across otherwise unrelated journeys.
  • Mismatch between the original booking context and the later access pattern used to amend it.

That means the detection model should correlate identity, device, payment, and itinerary events rather than score each event independently. Teams often need a join key or graph view that preserves the relationship between the first booking and later edits, especially when the attacker intentionally keeps each action just below a threshold. Behavioural scoring is more useful when it tracks how the story changes over time, not just whether a single event looks odd.

This guidance becomes weak when the organisation cannot retain or correlate the booking lifecycle data needed to link one transaction to the next.

Where Legitimate Changes End and Fraud Signals Begin

Tighter journey-level monitoring often increases analyst review volume, so organisations need to balance fraud coverage against customer friction and false positives.

Not every itinerary change is suspicious. Travel is a legitimate environment for rescheduling, passenger substitutions, and route adjustments, and teams should be careful not to treat normal service recovery as hostile behaviour. The practical question is whether the sequence is plausible for the customer profile and transaction history. Industry consensus is limited on universal thresholds because route, fare class, loyalty status, and channel mix all affect what “normal” looks like.

The strongest edge-case signal is usually consistency failure across multiple dimensions rather than one extreme anomaly. For example, a late booking edit paired with a new device may be legitimate on its own, but a late edit, a payment context shift, and repeated reuse across different accounts begins to look like a coordinated fraud pattern. In that setting, the issue is less about one suspicious field and more about the attacker trying to keep each field individually defensible. That is why teams should tune models to sequence integrity, not just single-event outliers.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0DE.CM — Security Continuous MonitoringBook-and-switch detection depends on continuous correlation across the booking lifecycle.
DE.AE — Anomalies and EventsThe fraud pattern is a sequence of low-signal anomalies that only matters in context.
Recommendation — Correlate booking, payment, and device telemetry continuously to surface multi-step fraud patterns. Treat linked itinerary edits and context shifts as anomalous sequences, not isolated outliers.
CIS Controls v88 — Audit Log ManagementDetection requires preserved event history across bookings, edits, and access context.
Recommendation — Retain and centralise booking lifecycle logs so investigators can reconstruct the fraud chain.
MITRE ATT&CKT1078 — Valid AccountsFraud rings often rely on legitimate-looking account activity to avoid simple fraud flags.
T1110 — Brute ForceCoordinated booking abuse often includes automated attempts against accounts or payment workflows.
Recommendation — Hunt for abuse of valid customer accounts when edits and purchases remain superficially normal. Monitor for automated booking attempts that create repeated, low-friction transaction trails.

Practitioner Guidance

What to prioritise: Prioritise cross-journey linkage over isolated alerting. If the team cannot connect the original booking, later edits, payment context, and device history, the fraud pattern will often remain invisible until the financial loss has already moved downstream.

What to verify: Verify that the detection logic can compare the booking’s first-seen context against its later modification context. The key test is whether the model preserves a durable relationship between events, not whether it can label one event as unusual.

What practitioners underestimate: Fraud rings often succeed by staying just inside normal operational variation at each step. The defensive mistake is to optimise for obvious anomalies instead of for pattern continuity across the whole travel flow.

Practitioner takeaway: The best signal is usually not a single suspicious booking event but a journey that becomes progressively harder to explain as more context is added.

Deepen Your Knowledge

Sign up to our weekly newsletter — get 33% off our NHI Foundation Level Course

    NHIMG Editorial Note
    Reviewed and updated by the NHIMG editorial team on September 7, 2026.
    NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org