Fraud detection_

Travel fraud has its own patterns: card testing on low-value deposits, account-takeover on familiar brands, friendly fraud post-trip. A detection layer that does not know about booking context — deposit versus balance, agency versus consumer, departure date — will either miss real fraud or block legitimate customers.

A generic fraud engine does not know that a £30 booking on a popular OTA is being card-tested, or that a high-value balance paid two days before departure is normal travel behaviour. Without travel context, the engine over-blocks or under-blocks — and either failure shows up as direct financial cost. The teams that get this right give the engine the booking context to work with.

The travel businesses with mature fraud-detection programs read outcomes back into the engine continuously: which blocks were right, which were wrong, which approvals turned into chargebacks. The businesses that set rules once and never revisit them quietly drift out of step with the threat model as fraud patterns evolve.

felloh surfaces fraud signals alongside booking context so the next decision is informed by the whole picture, not just the payment in isolation.

The Transactions and Risk Analysis views in the dashboard surface fraud signals — BIN risk, AVS mismatches, repeated authentication failures, behavioural anomalies — against the booking. Where a pattern emerges (card testing during a flash sale, repeated friendly fraud after a destination, account takeover on a particular brand), the booking-level evidence makes the response specific rather than blanket.

For fraud teams operating across multiple brands and acquirers, the detection layer learns from booking-level outcomes — captured, settled, refunded, disputed — rather than from logs. False-positive rates drop, false-negative rates drop, and the team spends time on the genuinely suspicious cases instead of triaging noise.