Booking Fraud Detection

Only two request objects are needed: booking carries payment_method, amount, and ip_country, while account carries country and bookings_last_24h; the three risk tables read them in parallel.

Payment instruments are ranked by abuse potential under first hit: a 'prepaid_card' with booking.amount above 2000 scores 40 as a 'High-value prepaid card transaction', prepaid without the amount trigger scores 20, 'gift_card' rows score 30 above 1000 or 15 otherwise, 'cryptocurrency' takes a flat 25, a 'credit_card' only registers 15 above 3000, and the catch-all writes 0 for a 'Standard transaction'.

Weighting prepaid and gift instruments hardest follows card-not-present fraud experience: both are favored cash-out tools because they detach the payment from a verifiable cardholder identity, and cryptocurrency removes chargeback recourse entirely. Credit cards score only at high amounts since issuer-side authentication already covers them; the 2000, 1000, and 3000 cutoffs are risk-team calibration, not any card-scheme mandate.

Velocity and geography combine under first hit: account.bookings_last_24h above 5 together with account.country != booking.ip_country scores the maximum 50 as 'Multiple bookings from different country', the same velocity alone scores 30, more than 3 bookings scores 35 with a mismatch or 20 without, a mismatch by itself scores 25, and the clean row returns 0 for a 'Normal booking pattern'.

Stacking a country mismatch on top of velocity reflects how stolen-credential fraud actually presents: bursts of purchases routed through a foreign IP. More than five bookings in 24 hours would be extreme for a genuine consumer, so these thresholds are sensible business tuning; no regulation prescribes them.

Account maturity feeds the third score: account.age_days under 30 scores 40 as a 'New account with significant transaction', under 90 scores 20 as 'Relatively new account', a further row on the same field scores 15 carrying the 'Previous chargeback history' reason, and the fallback returns 0 for 'Normal account history'.

Young accounts scoring highest is standard fraud logic, since fraudsters register throwaway accounts shortly before attacking, which makes age one of the strongest cheap signals available. The 30 and 90 day breakpoints are conventional review windows in risk operations rather than mandated periods.

Aggregation happens in two folds over the risk object: total_risk_score sums map(values(risk), #.score) across the payment, pattern, and account branches, and risk_factors collects the reason text from every branch whose score is above 0. Keeping the human-readable reasons next to the number is what makes a later manual review actionable.

Classification is a simple band on total_risk_score with first hit: 70 or more maps to "high", 30 or more to "medium", and anything below falls through to "low".

Three bands are the practical minimum for a fraud queue - approve, challenge, review - and the 70/30 cut points are tuned against the upstream scores so a single strong signal lands in "medium" while it takes stacked signals to reach "high". They are operational calibration, not an industry scale.

Action bits come last: flags.requires_verification is set when risk_level lands in ["medium", "high"], and flags.manual_review only when risk_level == "high". Splitting the two keeps friction proportionate, with step-up verification for the middle band and human review reserved for the worst cases.