Related Questions
Alert volume is up. The team is working harder. And somehow, a merchant that was never flagged just triggered a card scheme fine.
This is a familiar scenario for risk teams managing large portfolios. A team of analysts processes hundreds of merchant monitoring alerts each week. After investigation, the majority clear as false positives: legitimate businesses flagged for using certain words in their product descriptions, for operating in a sensitive MCC (Merchant Category Code), or for appearing on a broad blocklist. The real investigation time goes to noise.
Then the audit arrives. There it is: a merchant that processed a material volume of transactions outside its declared business model, accumulated chargebacks in a product category it was never approved for, and ran payment flows that should have triggered a review months earlier. The tools said nothing.
This is not a staffing problem. It is a structural one, and it starts with how most merchant monitoring systems are built.
Most merchant monitoring infrastructure still operates on the same core logic it used a decade ago:
These tools are effective at catching straightforward cases. A merchant with "CBD" in its product title will flag. A business registered under a restricted MCC will alert. A processor showing sudden transaction volume spikes will surface. These are visible signals, and rule-based systems are reasonably calibrated to detect them.
The problem is that most bad merchants do not look like the obvious cases. Two examples appear repeatedly in practice:
The wellness retailer. A merchant registered as a "wellness and lifestyle" brand. Its onboarding documents are clean. Its MCC is unremarkable. Its website headline reads like a hundred legitimate health brands.
But the product listings, when read by a system that understands content rather than just scanning for trigger words, describe products with claims that cross into regulated pharmaceutical territory. No keyword rule catches it. No blocklist matches. It processes for months.
The consulting business. A merchant that describes itself as a "business consulting service." Its business registration is valid. Its stated MCC generates no flags. But its actual transaction flows, reviewed against its web presence, show payment patterns consistent with a gambling facilitation operation.
The website, examined in context, tells a different story than the form submission at onboarding. Again: no alert. Rule-based systems catch the merchants who make obvious mistakes. They are largely blind to merchants who understand the rules well enough to avoid tripping them.
The noise problem compounds into something more operationally consequential than wasted analyst time.
Research in transaction monitoring compliance consistently identifies false positive rates in rule-based alert systems as a significant operational burden. As Laurence Hamilton, CCO at Consilient, noted in April 2025: rule-based transaction monitoring systems run with "consistent 95% false positive rates."
We observe a comparable pattern in merchant monitoring: systems calibrated for broad sensitivity generate alert volumes that exceed any team's capacity for thorough investigation.
Alert fatigue is the documented result. When analysts clear the large majority of alerts as benign before lunch, the cognitive threshold for what constitutes a real signal degrades. Investigations become faster and shallower. The team stops expecting to find anything meaningful.
Regulators including the Financial Action Task Force (FATF) and the UK Financial Conduct Authority (FCA) have specifically flagged alert fatigue as a compliance risk, noting that firms are expected to maintain systems that minimise unnecessary alerts while ensuring genuine risks are investigated.
The consequences are compounding:
The false positive problem is not a calibration issue that more rules will fix. Adding more rules typically adds more noise. The underlying issue is that rule matching produces binary outputs, triggered or not triggered, without the contextual understanding needed to distinguish a legitimate wellness brand from an unlicensed supplement operation.
The gap between what rule-based tools flag and what actually represents risk comes down to context. Understanding whether a merchant poses real risk requires reading the full picture:
No keyword match does this. No MCC filter does this. Blocklists capture merchants who were caught before, not merchants executing novel patterns.
The OCC Merchant Processing Comptroller's Handbook addresses acquirer obligations for ongoing evaluation of merchant activity throughout the merchant lifecycle, not only at onboarding. The regulatory expectation is continuous, risk-based assessment. For most portfolios, the operational reality is periodic review supported by tools that flag surface-level signals and miss contextual ones.
Visa's Acquirer Monitoring Program (VAMP), effective June 1, 2025, consolidates fraud, dispute, and enumeration monitoring into a single portfolio-level program. Acquirers are now evaluated against a unified VAMP ratio covering fraud (TC40) and disputes (TC15) relative to settled transactions.
The Excessive Merchant threshold tightens further in April 2026. Merchants that slip through monitoring gaps do not just create operational headaches. They move an acquirer's portfolio ratio in the wrong direction.
Periodic merchant reviews create a structural blind spot. A merchant that passes a quarterly review can, within the next 90 days:
All of that can happen without triggering a single alert under a periodic, rule-based review.
We see this pattern consistently. The merchants that appear in post-incident reviews are rarely the ones that looked problematic at onboarding. They are the ones that changed after onboarding, in a window between review cycles when no active monitoring was running.
Continuous monitoring closes this gap, but only if the monitoring itself can detect behavioral change rather than just threshold breaches. A merchant whose transaction volume stays flat but whose product catalog shifts from legal supplements to unregulated compounds will not trigger a volume anomaly. It will only surface if something is actively reading and classifying its content over time.
The monitoring approach that addresses these gaps operates differently from rule-based systems at a fundamental level. Instead of asking "does this merchant match a known-bad pattern," it asks "does what this merchant is actually doing match what it told us it does."
That question requires:
We have found that risk teams applying contextual analysis consistently identify a different distribution of problems than rule-based alert review surfaces. High-volume false positives diminish. Subtle behavioral shifts become visible: merchants quietly expanding into regulated categories, merchants whose transaction flows no longer match their declared model.
The result is fewer alerts, better signal accuracy, and coverage of the changes that matter.
Ballerine builds merchant monitoring infrastructure for acquirers who need to move beyond rule-based systems without adding headcount or slowing portfolio reviews.
The monitoring layer uses AI agents to analyze each merchant's actual web presence on a continuous basis. Key capabilities:
Rather than matching keywords against a trigger list, the system reads and interprets merchant content to evaluate whether what the merchant is doing aligns with what it is approved to do. When the system generates an alert, it reflects a meaningful contextual signal, not a keyword match.
For acquirers managing large portfolios, merchant onboarding feeds directly into the continuous monitoring layer. The contextual understanding established during underwriting is maintained and updated throughout the merchant lifecycle, rather than discarded after approval.
The system also supports transaction analysis that flags inconsistencies between transaction patterns and declared business models. This is where many of the cases that survive onboarding reviews ultimately surface.
If your risk team is clearing the large majority of its alerts as false positives and still finding problems in audits, the issue is not the team. It is what the tools are looking at.
.png)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.png)
