Where fraud sits, and why it matters
Fraud is one of four functions looking at the same customer data with different objectives, and where it reports determines what it optimises for.
Under finance or payments, it optimises for loss reduction and chargeback ratio. Fast to justify, and it will tighten indefinitely because loss is the only number it owns.
Under risk or compliance, it optimises for control and evidence. Better routing into financial crime, and it can become slow and conservative in a way that costs revenue nobody attributes to it.
Under operations or commercial, it optimises for customer experience and conversion. Better at the friction side, and structurally reluctant to restrict valuable customers, which is exactly where the largest cases are.
None of these is right and the choice is less important than the correction applied to it. A fraud function reporting into finance needs a customer-experience measure it is accountable for. One reporting into compliance needs a conversion measure. One reporting into commercial needs an independent escalation route that does not pass through the person whose revenue a restriction affects.
The structural minimum, wherever it sits: the decision to restrict a high-value customer must not require the approval of the person whose target it damages.
The four-function problem
Fraud, financial crime, responsible gambling and payments all read the same signals and have different obligations. Deposit velocity, failed deposits, reverse withdrawals, multiple instruments and unusual withdrawal patterns appear in all four playbooks.
Three arrangements exist and they are not equally good.
Separate teams, separate systems, no routing. A common default, and it produces systematic under-referral in every direction. Each team resolves ambiguous cases within its own frame because that is the only frame it can see.
Separate teams, shared triage. A first-line step with visibility of all four domains routes the case, and specialists handle it. This works, and it is the arrangement this course recommends.
Single combined team. Efficient at small scale and it degrades: financial crime and responsible gambling carry obligations with personal and regulatory exposure that a generalist queue handles badly.
Whatever the arrangement, three things need to be explicit. A case can belong to more than one domain simultaneously and the handling must not collapse it to one. Legal limits on disclosure bind the whole chain. In Britain, tipping off is an offence for people working in the regulated sector, which in gambling means operating a casino under a casino operating licence, and prejudicing a money laundering investigation is an offence for anyone who knows or suspects one is under way or about to begin. The Gambling Commission's view is that reasonable, tactful enquiries, including those driven by social responsibility concerns, should not prejudice an investigation unless they are made in a way that discloses it. A responsible gambling interaction with a customer under financial crime suspicion therefore needs a protocol. And the responsible gambling route must never be subordinated to commercial recovery: a self-excluded customer who multi-accounted is a compliance failure first and a terms breach second, because in Britain licensees must take all reasonable steps to prevent a self-excluded individual from gambling (social responsibility code 3.5.3 for remote operators).
Building the signal layer before the rules
The common sequencing error is buying a decision engine before having signals worth deciding on.
The order that works: identity resolution first, then device and network signals, then the behavioural layer, then rules, then models.
Identity resolution comes first because every other control is computed per account, and if one person holds several accounts each control sees a fragment. This is a data engineering problem entirely within the operator's own estate, it improves fraud, financial crime, responsible gambling and marketing suppression simultaneously, and it is unresolved at more operators than anyone would like to admit.
An operator with excellent identity resolution and simple rules will outperform one with a sophisticated model on fragmented data, and it will do so at a fraction of the cost.
Vendors, and what to ask them
Many operators buy rather than build, and buying decisions are often made on demonstrations rather than on the questions that matter.
What was the model trained on, and what bias does that import? If the answer is unclear, the vendor either does not know or does not want to say.
Can decisions be explained to a customer and to a regulator? Unexplainable decisions in a regulated context are a liability whatever their accuracy. Where a significant decision is made solely by automated means, the UK GDPR requires safeguards that give the customer information about the decision and let them make representations, obtain human intervention and contest it.
What is the measured precision on a book like ours? Aggregate accuracy across all clients is not an answer.
Does the data leave our control, and where does it go? A data protection question before it is a fraud one.
Can we tune it ourselves, or is every threshold change a support ticket? This determines whether the system adapts at your speed or the vendor's.
What happens at contract end? Models, rules and case history built inside a vendor platform may not be exportable unless the contract provides for it, which turns a tooling decision into a long-term dependency.
Consortium data deserves its own assessment. Shared industry data on known fraud is genuinely valuable, particularly for organised activity spanning operators. It also raises real data protection questions about the lawful basis for sharing, the accuracy of shared markers, and the customer's ability to challenge an entry made by someone else. The ICO's data sharing code puts the recipient on the hook: an organisation receiving shared data must satisfy itself about its integrity, is responsible for its lawful use and must respond to complaints about it. An operator relying on a consortium marker to restrict a customer should be able to say where the marker came from and how the customer could contest it.
Staffing and the human layer
Sizing follows from alert volume and the review depth intended. Deciding the depth first and staffing to it is the honest sequence; the common alternative is staffing to budget and then quietly reducing depth until the queue clears, which produces exactly the superficial closures that are worse than no system.
Skills are investigative rather than procedural. The core competence is testing a hypothesis, and it is trainable.
Shift coverage matters because fraud is not confined to business hours, and payout review queues that only move during the day produce withdrawal delays, which customers notice immediately and complain about.
Attrition is a real operational risk. Fraud analysts accumulate pattern knowledge that is not written down, and losing an experienced reviewer removes detection capability that no document captures. Documenting typologies as they are found is the mitigation, and it is often the thing that gets deferred.
Reporting that supports a decision
Most fraud reporting describes activity. Useful reporting shows the two-sided trade.
On the loss side: realised loss by type, prevented loss with the estimation method stated, chargeback ratio against scheme thresholds with friendly fraud broken out, and recovery achieved.
On the cost side: false positive rate and reversal rate, declined legitimate deposits and their estimated value, complaint volume arising from fraud actions, and customers lost following a restriction.
On the system side: precision by alert source, alert volume against review capacity, closure quality from independent sampling, and below-the-line testing results.
On the routing side: referrals made to financial crime and to responsible gambling, because a fraud function that never refers is resolving everything within its own frame.
A board seeing only the loss side will ask for tighter controls every quarter and will get them. A board seeing both sides can make the trade deliberately, which is the entire purpose of producing the second half.
The exercise worth doing once a year
Take the three bluntest controls in the stack, the ones applied uniformly rather than by segment. For each, compute the fraud prevented and estimate the legitimate customers stopped and their value.
The estimate is achievable: sample the declines, manually review a subset to establish what proportion were legitimate, apply the average customer value, and extrapolate. It is not precise and it does not need to be. The question is whether the number is larger or smaller than the prevented loss, and that is usually clear well inside the error bars.
The exercise is designed to find a control costing more than it saves, and where it does, segmentation is the usual remedy: applying the control to the segments where the risk sits can deliver comparable protection at a fraction of the cost to legitimate customers.
The reason this is worth restating at the end of the course is that it is the finding the reporting is structured to hide. Prevented fraud is counted, attributed and celebrated. Declined customers are a number nobody owns. A function that closes that gap is doing something many of its peers do not, and it is doing it with data it already holds.