What Fraud Actually Is

Before writing a single line of code, get the vocabulary right. "Fraud detection" is used loosely in industry to mean at least three different jobs. They have different deadlines, different tools, different teams and different metrics. Confusing them leads to bad architectural decisions and worse models.

The three jobs called "fraud detection"

Real-time prevention

Sub-second decisions at the point of a transaction, login, application or claim submission. Uses ML models plus a rules engine to approve, decline, challenge (step-up auth) or send to review. Owned by fraud engineering and data science. This is where the machine learning work lives.

Post-hoc investigation

Human analysts working through queues of flagged events, chargebacks and disputed transactions in the minutes to days after they happen. Case management platforms, external data lookups, analyst judgement. Owned by fraud operations. Feeds confirmed-fraud labels back into Job 1.

Regulator-driven financial crime monitoring

Structural pattern analysis across many accounts and long time windows to satisfy AML, sanctions and PEP obligations. Batch pipelines producing typology alerts and Suspicious Transaction Reports. Owned by compliance and financial crime teams. Regulator-driven (FIC Act in SA).

The three jobs share the word "fraud" but have almost nothing else in common technically.

Job	Deadline	Primary tool and owner
1. Real-time prevention	Milliseconds to seconds	ML model + rules engine. Owned by fraud engineering. Metric: cost-weighted expected value, precision-at-K.
2. Investigation	Minutes to days	Case management platform (Feedzai, Actimize, homegrown). Owned by fraud operations. Metric: cases per analyst-day, chargeback recovery rate.
3. Financial crime	Hours to weeks (batch)	Typology rules + graph analytics. Owned by compliance. Metric: STR filing rate, regulator satisfaction, coverage.

Confusing them is what causes the classic mistakes: someone tries to use an AML-style batch pipeline for card authorisation (too slow, wrong shape), a data scientist builds a real-time model for AML typologies (missing the structural view), a case management tool ships without ranking (wastes analyst time on low-risk noise).

What this course focuses on

The rest of this course is about Job 1: real-time prevention. That is where the ML-heavy work lives and where most of the technical mistakes happen. Job 2 shows up in module 7 when we cover how models feed analyst case queues and how analyst feedback loops back into training. Job 3 gets most of module 6, on graph analytics and anti-money-laundering patterns.

One-line working definition (Job 1)

Real-time fraud prevention is the discipline of predicting, in real time or near real time, whether a specific event (a transaction, a login, an application, a claim) is being executed by someone with intent to deceive for financial gain.

Every phrase in that sentence matters. Break it apart.

Predicting

Fraud detection is a prediction problem, not a lookup. You do not have a list of fraudulent card numbers you can check against. Fraudsters use stolen cards that look identical to legitimate ones until the real owner notices something wrong, which can take hours or days. The prediction has to be made from behaviour, not identity.

In real time or near real time

The decision has a hard deadline. When a card is swiped at a Woolworths till, the payment network expects an authorisation response in under 500 milliseconds. Anything slower and the transaction times out and gets declined by default. This constraint shapes every architectural choice downstream: which features you can compute, which models you can use, how you store data and how you retrain.

Not every fraud decision is real time. AML monitoring runs on batch pipelines that produce reports overnight. Insurance claim fraud is scored days or weeks after submission. Application fraud has minutes to hours. Know the deadline before you design.

A specific event

Fraud detection scores events, not people. The same customer can execute a legitimate transaction at 09:00 and a fraudulent one at 10:00 if their card was cloned in between. A "person" is not a useful unit of scoring: the same person can be a victim at breakfast and a victim again at lunch. The unit is always the event.

Intent to deceive for financial gain

This is the phrase that separates fraud from abuse, error and dispute.

FraudA transaction attempted by someone who is not the legitimate cardholder or account owner, or by the legitimate owner in a way designed to extract value they are not entitled to.

AbuseLegitimate use of a service in ways it was not designed for. Promo-code abuse, referral farming, refund abuse. Overlaps with fraud tooling but is a different problem with different economics.

ErrorWrong amount, wrong account, duplicate submission. No intent to deceive. Handled by customer service, not the fraud team.

DisputeThe customer disagrees that they authorised a transaction or that the goods were as described. May or may not be fraud, depending on whether the customer is telling the truth.

The five common fraud shapes

Every fraud detection problem you will meet in South African financial services fits one of these five shapes. Each has a different feature space, a different model choice and different production constraints.

Card fraud (present and not-present)

A stolen or cloned card being used at a merchant. Card-present is dying due to EMV chip and PIN. Card-not-present (online) is the dominant category, driven by data breaches and social engineering. Millisecond decision budget.

Account takeover (ATO)

A legitimate account being accessed by someone who is not the owner. Often follows a data breach elsewhere (credential stuffing). Detected at login, at password change, or at unusual behaviour after login. Seconds to minutes budget.

SIM-swap and mobile-first fraud

Uniquely severe in SA. The fraudster convinces a mobile carrier to move the victim's number to a new SIM, defeats SMS-based OTP, then drains the account. Detected by pairing telco signals with banking behaviour. Seconds budget.

Application fraud (synthetic and stolen identity)

A new account or loan application submitted with false or stolen identity information. Includes synthetic identities that combine real and fabricated details. Detected at application submission. Minutes to hours budget.

Money laundering (AML)

Structured movement of illicit funds through the banking system to disguise their origin. Detected by pattern analysis across many transactions and accounts. Batch pipelines, hours to days budget. Regulator-driven (FIC Act in SA).

Two shapes that look like fraud but are not

Worth naming so you can push back when a stakeholder asks you to build the wrong thing.

Fraud vs credit risk

Credit risk is "will this customer pay us back". Fraud is "is this even the customer". Very different feature spaces, very different labels, very different models. Do not use a credit model to detect fraud, and do not use a fraud model to score credit. Both mistakes are common in mid-size lenders.

Fraud vs conduct risk

Conduct risk is "is our institution behaving properly toward customers and regulators". Fraud tooling can support conduct monitoring (unusual advisor behaviour, mis-selling patterns) but the two functions live in different parts of the org and have different accountabilities.

What you will build in this course

Everything in this module positions the problem. The rest of the course is applied: by module 8 you will have shipped an end-to-end pipeline that trains a fraud model on real imbalanced transaction data, calibrates it to a cost matrix, explains any given decision to an analyst, and monitors itself for drift. It is a small system, but the shape is the shape.

Key Takeaways

Three jobs share the name "fraud detection". Real-time prevention (ML), post-hoc investigation (analysts), regulator-driven financial crime monitoring (compliance).
This course focuses on Job 1. Jobs 2 and 3 appear in modules 6 and 7.
Job 1 is prediction, not lookup. No blacklist. Score behaviour, not identity.
The unit is the event. A specific transaction, login, application or claim. Never "the person".
Five common event shapes. Card, ATO, SIM-swap, application, AML. Each has a different feature space and model.
Not credit risk, not conduct risk. Push back when a stakeholder confuses these.