A merchant clears KYC in March.
By June, forty percent of its payouts land in an account shared with two other merchants on your platform.
Nobody flagged it. The check happened once. Onboarding was three months ago.
This is the blind spot. The review happens at the front door. The fraud happens at the payout.
Onboarding answers one question: is this a legitimate business, today, on the day it applies.
Registration. Director identity. Bank account ownership. All of it a snapshot.
Fraud rings know the snapshot expires. A shell entity clears onboarding clean. It waits. Trust builds, payout limits relax - and only then does it start behaving like a mule funnel. By the time volume looks strange, the money has already moved. What you are looking at is not a suspicious application anymore. It is settled cash sitting in a shared beneficiary account nobody connected at review time.
This is not a KYC failure. KYC did its job. It is a monitoring design failure. A snapshot cannot catch a pattern that only exists as a trend, across merchants, over time.
Rule-based settlement checks ask one question per payout: is this amount typical for this merchant, is the beneficiary account the one on file. Both checks pass, every time. For a coordinated ring, that is the entire trick. Each payout is internally consistent. The fraud never shows up inside any single merchant's history.
Three patterns repeat across PSP and PayFac platforms: multiple sub-merchants routing payouts to one shared beneficiary account; sub-merchants who share a device fingerprint despite claiming no relationship to each other; payout timing that clusters across accounts that should have zero operational overlap.
None of these are visible from inside one ledger. All three are visible the moment payout data gets mapped as a network instead of a table. That is the actual argument for graph-native detection over rule-based settlement checks: rules ask if this payout looks normal for this merchant. A graph asks whether this merchant's beneficiary account, device signature, or ownership trail connects to anything already flagged on the platform. The second question is the one that catches the ring.
Coordination is the mechanism the fraud depends on. Coordination is exactly what a graph exposes. RBI's Master Direction on Regulation of Payment Aggregators (September 2025, the current consolidated framework) requires ongoing merchant due diligence and continuous transaction monitoring - not a one-time onboarding gate. That requirement only means something operationally if the monitoring can see across merchants, not just anomalies within one.
Money that leaves through a fraudulent payout is usually gone within days. That is the fast cost.
The slow cost shows up later. An examiner asks how the payout decision was made. You need a case trail that connects the flagged payout to the network it belonged to. A single alert with no connective evidence looks, to an examiner, exactly like a programme that never checked for coordination at all.
This is where most stacks fail quietly. Fraud flags the payout. AML flags the beneficiary account - separately, on a different timeline, in a different system. Neither team sees the network the other is standing inside.
Verafye connects payout, onboarding, and beneficiary signals into one explainable case instead of two alerts that never meet each other. When a sub-merchant's payouts start routing to a beneficiary account that appears elsewhere in the portfolio, Verafye surfaces that connection immediately - not after a manual analyst trace weeks into the pattern.
The graph-native intelligence layer maps each new payout against the existing network: which beneficiary accounts are shared, which device fingerprints overlap, which ownership chains connect merchants that filed separately and claimed no relationship. What a rules engine sees as individually normal payouts, Verafye maps as a network with a recognisable topology - and the structure of that topology tells you whether you are looking at commercial activity or a mule funnel.
The investigation case that results is already assembled: the payout trail, the network connections, the shared attributes, and the audit documentation an examiner needs to see a programme that was actually monitoring - not just clearing alerts in isolation. For payment aggregators managing growing merchant books across diverse business categories, that assembled case is the difference between a programme that can satisfy ongoing monitoring obligations and one that passes onboarding reviews while missing the pattern that forms three months later.
Most PSPs can tell you if a payout matched the merchant's history. The question a mule network is counting on you never asking is whether that merchant's beneficiary account has ever touched anything else on the platform. To see where those connections currently exist undetected in your payout data, the Verafye Risk Shadowing Review provides a scoped assessment with no commitment required.
Not "do our settlement checks pass." They always do, for a coordinated ring designed to make them pass.
The question: can your monitoring tell you whether a merchant that clears every per-payout check today is routing funds through a beneficiary account that has already appeared somewhere else on your platform?
If answering that requires a manual trace, the architecture is checking each payout. It is not watching the network. And the network is where the fraud is.
What is sub-merchant fraud and why does it usually pass onboarding checks?
Sub-merchant fraud happens when a merchant looks legitimate at KYC but starts behaving like a mule conduit weeks or months later. Onboarding checks a snapshot: business registration, director identity, bank account ownership. It cannot catch a pattern that only forms across time and across multiple merchants.
Why do rule-based settlement checks miss coordinated sub-merchant rings?
A rule evaluates each payout against its own merchant profile. Both checks - amount typical, beneficiary account on file - pass every time for a ring, because each individual payout stays internally consistent. The coordination between merchants, shared beneficiary accounts, shared device fingerprints, never shows up inside any single merchant's transaction history.
What does RBI expect from payment aggregators on ongoing merchant monitoring?
RBI's Master Direction on Regulation of Payment Aggregators requires continuous transaction monitoring and merchant due diligence - not a one-time check at onboarding. Aggregators treating KYC as a single gate are working from an outdated read of what the framework requires. RBI's September 2025 Master Direction - the most recent consolidated framework - makes this expectation explicit.
How does graph-based monitoring catch what rules engines miss?
A graph asks whether a merchant's beneficiary account, device signature, or ownership trail connects to anything already flagged elsewhere on the platform. Rules cannot ask this. Coordination is the mechanism a fraud ring depends on - and coordination is exactly what a relationship-based view exposes.
If we suspect sub-merchant fraud is already active, what should we look at first?
Start with beneficiary account overlap across merchants onboarded in the same window, then check for shared device or IP signals at registration. Most PSPs can pull this data. What they usually lack is a way to connect it into one case instead of separate alerts in separate systems - which is the specific gap that Verafye's investigation intelligence closes.
Sudeendra
Co-Founder & COO, Verafye
Verafye is a graph-native network risk intelligence platform built for lean fraud, AML, and risk teams at payment aggregators, PSPs, MSBs, and regulated fintech platforms.
See where your monitoring stack has blind spots
The Risk Shadowing Review maps your current coverage against relationship-level gaps.
