What an iGaming Course Taught Me About Anti-Fraud Systems

I took the Anti-Fraud and Payments Handling course from the iGaming Academy expecting a list of rules for blocking bad transactions. What it actually taught me was that anti-fraud is mostly a series of judgment calls, and almost none of them have a clean right answer.

Fraud prevention is a trade-off, not a filter

The instinct is to think of fraud detection as a filter: bad transactions on one side, good ones on the other. Real systems don't work like that, because the rules that catch the most fraud also catch real customers, and every legitimate customer you block is revenue you lost plus a person who probably won't come back.

So the question is never "does this rule catch fraud." It's "what does this rule cost when it's wrong, and how often will it be wrong." A rule that catches 90% of fraud but rejects 5% of genuine customers can easily be worse for a business than a rule that catches 60% and rejects almost nobody.

Not every decline means the same thing

This was the single most useful distinction in the course. A declined transaction can mean insufficient funds, a network timeout, a card reported stolen, or a bank blocking a transaction it found suspicious. Those are completely different signals that happen to arrive through the same channel.

Insufficient funds is a temporary condition, so trying again later or through a different route is reasonable. A card reported stolen is a permanent, definitive answer, and retrying it somewhere else is trying to push a fraudulent transaction through an acquirer that hasn't caught it yet. Treating those two responses identically is how a payment system ends up either losing legitimate sales or laundering fraud.

Patterns matter more than individual transactions

A single transaction usually doesn't tell you much on its own. A €50 payment is unremarkable. The same card producing repeated declined attempts in a short window is a completely different story, because that's what card testing looks like: someone with a stolen card list checking which ones are still live before spending them.

That shifted how I think about the data a payment system needs to store. Rules that only see the current transaction can't detect a pattern, so the history has to be there and it has to be queryable at decision time, not just archived for reporting later.

Evidence is part of the product

The part I hadn't thought about at all before the course: when an acquirer or a regulator asks why a transaction was approved or declined, "the system decided" is not an answer. You need the record of what was checked, what the result was, and what rule fired.

That reframed persistence for me. In most projects the database is where state lives. In payments it's also the audit trail, and deleting a payment record isn't cleanup, it's destroying evidence.

Card data has rules of its own

Storing full card numbers isn't a decision to make lightly, it's a compliance obligation with real requirements attached. The practical version for a project like mine is straightforward: keep the BIN and the last four digits, which is enough to identify a card across transactions and show a customer which card they used, and never store the rest.

What I actually took from it

The course changed what I think a fraud system is. It's not a wall you put in front of payments. It's a set of decisions about acceptable risk, made with incomplete information, where being too aggressive costs real money and being too permissive costs more. Building PayMaestro afterwards was mostly an exercise in turning those judgment calls into code that could actually be inspected and explained later.