[Written By External Partner]
Can a model tell the difference between a player who won a large hand five minutes ago and a stolen card being tested for the first time? Both produce an unusual deposit from an account with little history. Both look wrong to a rule written last year. Only one of them should be declined, and getting that judgment right at scale is the entire discipline.
The Fraud Types Worth Modelling
Card-not-present fraud is organised work. Europol’s assessment of organised crime online describes non-cash payment fraud as highly organised and highly specialised, adapting continuously to industry countermeasures. Gaming ranks high on the target list because deposits are frequent, balances are liquid, and withdrawals can be requested within minutes.
Within that, casino fraud is several problems that share a cashier. Card testing uses small deposits to validate stolen card numbers before they are spent elsewhere. Account takeover targets funded accounts with weak authentication. Bonus abuse runs multiple accounts through the same promotion. Deposit-and-withdraw laundering moves clean-looking money through minimal play.
Each has a different signature. Card testing shows as many small attempts across many cards from few devices. Takeover shows as a change in behaviour on an established account. Bonus abuse shows as coordination between accounts that should have no relationship. A single model tuned for all four detects none of them well.
The Limits of Static Rules
Rule engines fail in a predictable way. A rule declining deposits above a threshold from new accounts works until the fraud operation tests the threshold and settles a dollar below it. Rules are visible through their effects, and anyone running volume against a cashier can map them within days.
Rules also age badly against legitimate behaviour. A limit written when the average deposit was $40 will decline a growing share of honest players as that average rises, and nobody notices because declined players do not complain, they leave.
Model Placement in the Deposit Flow
Scoring has to happen before authorization, which means the model belongs inside the payment path rather than in a nightly batch. In practice most casino payment solutions call a scoring service between the cashier request and the acquirer, with a budget measured in tens of milliseconds.
That budget shapes the design. Features that require a database join across months of history have to be precomputed and cached, so the model reads a prepared profile at decision time and updates it after.
Placement also determines what the model can see. A scoring service called by the cashier knows the deposit, the account, and the device. A service called by the acquirer knows the authorization response and the issuer’s own risk signals. Operators who put scoring in one place and never share the other side’s data end up with a model that is confidently wrong about the transactions the bank already understood.
Predictive Signals in Gaming Data
The useful features are mostly behavioural. Deposit velocity per account and per device. Time between registration and first deposit. Ratio of deposits to wagers, which separates players from people using the account as a money box. Device and network consistency across sessions. Card BIN country against account country and login location.
Gaming has an advantage over general retail here, because the relationship is continuous. A retailer sees a customer four times a year. An operator sees the same player daily, which means a model has an established baseline to compare against and behavioural change becomes the strongest signal available.
The Class Imbalance Problem
Fraud is rare, and rarity breaks naive training. Fraudulent transactions are a tiny fraction of the total, so a model that labels everything legitimate scores well on accuracy and catches nothing. Research on credit card fraud detection is largely a literature about this problem, with ensemble methods built specifically to handle the disproportionate representation of fraudulent and legitimate transactions.
The general treatment is well documented. Work on class imbalance learning covers resampling the training data, weighting errors by cost, and using anomaly-detection methods that model normal behaviour and flag departures from it. Operators should ask which of these a vendor uses and how the model is evaluated, because accuracy is the wrong measure and a vendor quoting it has answered a different question.
The Cost of a False Positive
Precision matters more in gaming than in most sectors, because the customer relationship is ongoing and a wrongly declined deposit is a customer service event during a session the player expected to enjoy. The expensive part is the lost account, which is worth many times the value of the declined deposit.
That argues for a graduated response instead of a binary decline. Low scores pass. Middle scores trigger a step-up check or a temporary limit. High scores decline and queue for review.
The cost of that middle band has fallen sharply. Where a step-up once meant a one-time code by text message and a measurable drop-off, passkeys let a player confirm with the same gesture used to unlock their phone, and the credential is bound to the site so it resists phishing and replay. A model that can escalate cheaply can afford to be less certain before it acts, which is a design improvement disguised as an authentication upgrade. Operators that jump straight from pass to decline lose more revenue to false positives than they save in prevented fraud, and they rarely measure the first number.
Regulatory Constraints on Automated Decisions
Automated decision-making about people is now regulated in its own right. The European framework for high-risk systems places requirements on providers and deployers before a system reaches the market and throughout its use, with transparency toward affected people among them.
For an operator this means keeping records of why a decision was made and being able to explain a decline to a player who asks. Human review has to cover the cases that carry consequences for the person on the other side. A model that cannot produce a reason code is a compliance problem waiting for its first complaint.
Human Review in the Fraud Queue
Every mature setup ends in the same place. A queue, a reviewer, and a case that the model scored at 0.71, with the contributing features listed beside it. A new device. A card issued in a country the player has never logged in from. A deposit pattern matching four other accounts opened that week. The model found the case, ordered the queue, and explained itself well enough for a human to act on it in under a minute. That is the job. A scoring service without a reviewer behind it produces a queue nobody works, and a queue nobody works is a decision taken by default at whatever threshold the vendor shipped.
