Set your thresholds too low and your team spends all day clearing harmless alerts. Set them too high and the ugly stuff slides straight through. That’s the game.
Founders usually learn this the hard way. They launch with a generic monitoring tool, turn on every rule, and suddenly the dashboard looks like a fire alarm panel in a burning building. Hundreds of alerts. Maybe thousands. Almost none of them useful.
And then people start doing the worst possible thing – closing alerts fast just to keep up.
That’s how bad habits get baked in early.
Thresholds are not just numbers
A lot of teams treat threshold setting like a spreadsheet exercise. Pick an amount. Pick a frequency. Maybe copy what another licensed firm is doing. Done. Nope.
A monitoring threshold is really a business decision wrapped in compliance language. It should reflect your product, customer base, payment rails, geographies, and the type of financial crime risk you actually face. A B2B payments platform handling regular six-figure treasury flows should not monitor the same way as a retail crypto app with first-time users depositing from personal cards. Obvious, right? Yet people still use the same blunt settings.
If you’re still building your framework, this is exactly where proper Outsourced AML Officer & Compliance as a Service support can save you a pile of wasted effort. Not because the policies look nicer. Because someone needs to tie the rules to the real activity on the platform.
Honestly, most founders leave this too late.
Start with behavior, not regulation
Regulators expect monitoring. Sure. But they usually don’t hand you a magic list of perfect thresholds that fit your business. You have to justify your settings based on risk. That’s the part that matters.
So start by asking a much better question: what does normal activity look like here?
Break it down:
- Typical deposit and withdrawal size
- Average number of transactions per day or week
- Usual funding methods – card, bank transfer, wallet, stablecoin
- Expected customer profiles – retail, VIP, merchants, affiliates, institutional
- Geographic exposure
- How quickly funds usually move back out
This sounds basic, but it’s where decent threshold design starts. If your average user deposits EUR 150 twice a month, a rule that flags every account crossing EUR 1,000 in total monthly volume may be reasonable. If your normal user is an OTC client moving EUR 80,000 chunks, that same rule is useless noise.
Same with gambling. A sportsbook with sharp bettors, arbitrage patterns, and frequent wallet recycling will generate very different transactional behaviour from a casual casino brand. If you ignore that, your false positive rate goes through the roof.
The biggest mistake: one threshold for everyone
I’ve seen this kill monitoring programmes again and again. One universal rule set. One amount. One frequency cap. One set of scenarios for every customer type.
It feels tidy. It isn’t.
You need segmentation. At minimum.
That usually means creating different monitoring logic for different buckets of customers, such as:
- Retail low-risk customers
- Higher-risk geographies
- PEPs and sanctions-adjacent exposures
- High-volume business accounts
- VIP or high-net-worth customers
- Crypto-native users funding from self-hosted wallets or multiple exchanges
The goal isn’t to make things fancy. The goal is to stop your system treating clearly different customers like clones. If a licensed EMI, a casual player, and a high-frequency crypto trader all trigger the same velocity rule at the same point, your setup probably isn’t mature enough.
This is where customer risk scoring matters. If you haven’t built that piece properly, your monitoring engine is half blind. There’s a solid breakdown of that in Customer risk scoring: building a model that regulators and banks actually accept. Worth reading because thresholds work far better when they’re layered onto actual risk tiers, not guesswork.
Use layered rules, not just amount-based triggers
A raw amount threshold is the simplest rule in the world. It’s also rarely enough on its own.
Good monitoring usually mixes several dimensions together. Amount. Frequency. Counterparty type. Geography. Time between deposit and withdrawal. Product usage. Source of funds changes. Device or IP weirdness. Stuff like that.
Say you’re running a crypto platform. A single EUR 2,000 deposit might be completely ordinary. But a new customer who makes five deposits in 24 hours, converts to privacy-focused assets, and withdraws to a fresh external wallet? Different story. Same money, very different pattern.
Or in gambling. One player depositing heavily before a major sporting event may be normal for that segment. A player who deposits, barely plays, then requests withdrawal through a different channel. That’s where you lean in.
Patterns matter more than headline values. Always.
What to do if you’re drowning in alerts already
First, don’t panic and don’t just raise every threshold across the board. That’s the lazy fix and it creates new holes.
Do this instead:
- Pull 30 to 60 days of alerts and classify them by rule type
- Measure which rules create the most volume
- Identify which of those high-volume rules almost never produce real escalations
- Check whether the issue is threshold level, poor segmentation, or bad data feeding the rule
- Tune one rule at a time and re-test
That last point matters. One rule at a time. If you change ten settings in the same week, you won’t know what fixed what.
Also, check your data quality before blaming the thresholds. I’ve seen duplicate transaction feeds, broken merchant category mapping, and wallet labels imported wrong. Ugly little technical issues. They create alot of fake noise and the compliance team gets blamed for it.
If your setup is spread across PSPs, EMIs, card acquirers, crypto processors, and manual CSV uploads, clean architecture matters just as much as rule logic. That’s usually why teams also need stronger Payment Strategy & Banking Access planning – because fragmented payment flows lead to fragmented monitoring.
Calibrate with real cases, not theory
This bit gets missed all the time.
Thresholds should be tested against known examples. Internal cases, historic SAR-related activity, fraud incidents, chargeback abuse, mule patterns, bonus abuse in gambling, wallet peel chains in crypto. Whatever you’ve got. If you don’t have much internal history yet, use typologies from your sector and build sample scenarios around them.
Then ask:
Would our current rules catch this?
Would they catch it early enough?
How many harmless customers would get swept up by the same rule?
That’s the balancing act. Detection versus drag.
If you’re dealing with crypto activity in Europe, you should also think ahead. MiCA authorisation and VASP-style controls push firms toward more defensible monitoring logic, better governance, and cleaner documentation around alert handling. This article on CASP authorisation under MiCA: the full application timeline and what stalls it is useful because poor compliance buildout often slows the whole process, not just monitoring.
Document why the threshold exists
This sounds boring. It is boring. Still has to be done.
For each meaningful rule, keep a short rationale. Not a 12-page memo. Just enough to show:
- what the rule is trying to detect
- which customer segment it applies to
- why the threshold was set at that level
- what data inputs it relies on
- when it gets reviewed
If a bank, auditor, investor due diligence team, or regulator asks why your payout velocity threshold is set where it is, “the vendor suggested it” is a terrible answer. Big mistake.
You want to be able to say the threshold was based on observed activity, customer segmentation, and periodic tuning results. Short. Sensible. Defensible.
Review it before the business changes, not after
Thresholds drift out of date fast. New market. New payment method. New customer segment. New product. Suddenly your old settings make no sense and nobody notices until the alert queue blows up or, worse, an incident slips through.
Review thresholds whenever you:
– launch in a new country
– add fiat rails or a new acquirer
– onboard a different customer type
– introduce higher transaction limits
– move from retail into B2B or institutional flows
And yes, review them on a schedule too. Check current requirements in the jurisdictions where you’re licensed or registered, because supervisory expectations do change. Slowly sometimes, suddenly other times.
The practical standard you’re aiming for
You do not need a perfect monitoring system on day one. Nobody has that. What you need is a setup that’s proportionate, explainable, and actually usable by the humans clearing the alerts.
If analysts are rubber-stamping 95% of alerts in under a minute, your thresholds are probably off. If genuinely risky behaviour can move through your platform without triggering anything until days later, same problem from the other side.
The sweet spot is boring, honestly. Alerts that are manageable. Rules that match customer reality. Reviews that happen before things break. And documentation that won’t make you cringe six months later.
That’s the job.