Machine Learning Fraud Model

A machine learning fraud model is a statistical model that learns from historical examples of genuine and fraudulent activity and uses what it has learned to estimate how likely a new event is to be fraud. The event may be a card payment, a bank transfer, an account sign-up, a login or a loan application. The model's output is normally a number, a risk score, that other systems use to approve, challenge, review or block the event.

Such models are used by card issuers, acquirers, payment processors, banks, marketplaces and specialist vendors as a core part of fraud detection. They complement, and have partly replaced, hand-written rules. A rule states a condition a person thought of in advance; a model finds combinations of signals in the data that no analyst would write down, and can be retrained as fraud patterns change.

Most fraud models use supervised learning. The developer assembles a large set of past events, each labelled as fraud or not fraud. For card payments the labels come mainly from fraud reports and each chargeback filed by issuers, supplemented by manual review outcomes and confirmed customer complaints. The model is trained to separate the two classes and tested on data it has not seen, ideally from a later period than the training data, since the purpose is to predict the future.

Fraud is rare, often well under one percent of transactions, so the classes are heavily unbalanced and accuracy alone is a misleading measure: a model that approves everything is more than 99 percent accurate. Developers look instead at how much fraud is caught at a given rate of false alarms. Labels are also late and incomplete. A chargeback may arrive weeks after the payment, transactions that were declined never reveal whether they were genuine, and some fraud is never reported.

Gradient-boosted decision trees are the most common technique for transaction data, with neural networks used where volumes are very large or where sequences of events matter. Unsupervised methods, which look for unusual behaviour without labels, and graph analysis, which links accounts sharing devices, addresses or bank details, are added to find a fraud ring that individual transactions do not reveal.

The inputs to a model are called features. Their quality usually matters more than the choice of algorithm.

• Transaction details. Amount, currency, merchant type, time of day, and whether the card was present.
• History and velocity. How many times the card, account, email or device has been seen in the last minute, hour and month, and how the current amount compares with past behaviour. These are the learned counterpart of a velocity check.
• Device and network. Device fingerprinting results, IP reputation, and mismatches between location, billing address and card country.
• Identity signals. Age of the account, age of the email address, and consistency of name, phone and address.
• Behaviour. Typing rhythm, navigation path and the time taken to fill in forms.

Networks and large processors have an advantage here because they see the same card or device across many merchants.

For payments the model must answer inside the authorization window, so real-time fraud scoring typically has tens of milliseconds to gather features and compute a result. The score then feeds fraud decisioning: below one threshold the event is approved, above another it is declined, and in between it may be sent to manual review or to step-up authentication.

Where to set the thresholds is a business decision. A lower threshold stops more fraud but turns away more good customers; the false negative rate and the false positive rate move in opposite directions. Lost sales and annoyed customers from false declines often cost a merchant more than the fraud itself.

Models rarely work alone. A rules engine sits alongside to enforce policy, block known bad actors and react within minutes to a new attack that the model has not yet learned. A typical setup uses each fraud rule as a guardrail and the model for the fine ranking of risk.

Fraud is adversarial. Criminals probe a system, see what is declined and change their methods, so a model's performance decays, a problem known as drift. Models need monitoring and regular retraining, and a model trained only on its own past approvals can develop blind spots. Some fraud types give little signal at the level of a single event: in account takeover and in scams where the real customer is tricked into paying, the credentials and device may all be genuine. Synthetic identity fraud and friendly fraud are hard to label at all.

Explanation and fairness are further concerns. A complex model may not offer a simple reason for a decision, yet staff reviewing cases need one, and so may the customer. In lending, United States law requires a creditor to give specific reasons for an adverse action, and European data protection law restricts decisions based solely on automated processing. Features can act as proxies for protected characteristics, and banking supervisors expect firms to validate, document and govern models under their model risk management guidance. Many firms therefore keep simpler, more interpretable models for regulated decisions and reserve the most complex ones for payment screening.