Transaction laundering, also known as factoring, merchant laundering, or unauthorized aggregation is the practice of routing payments for one business through the merchant account of a different, approved business. The unapproved operator hides behind the approved merchant's identity; the payment volume looks legitimate to the acquirer, the issuer, and the schemes; and the prohibited activity that generated the volume goes unflagged because the front-end merchant appears to be a normal, low-risk business.
For acquirers, PSPs, and payment facilitators, transaction laundering is the single highest-consequence form of merchant fraud. The financial exposure is direct; chargebacks, scheme fines, AML and BRAM/VIRP violations, and in extreme cases license-level consequences. The operational exposure is wider laundering operations damage the integrity of the entire portfolio, contaminate the chargeback profile, and pull internal resources into reactive investigations that the program should never have needed to run.
This guide explains what transaction laundering is, why standard fraud detection structurally fails to catch it, what working transaction laundering detection actually requires, and how to detect transaction laundering with the depth modern acquiring portfolios need — including dark web monitoring merchants integration where the laundering signals demand it.
Why transaction laundering is the hardest fraud to catch
Most categories of payment fraud have signatures that can be pattern-matched. Card-present fraud has known velocity profiles. Card-not-present fraud has identifiable IP, device, and behavioral signals. Account takeover has detectable session anomalies. The detection systems built for these categories are mature, well-calibrated, and broadly effective.
Transaction laundering does not produce that kind of signature, by design. The whole point of the operation is that the front-end merchant looks normal. Onboarding produces a clean approval. KYM produces a coherent business profile. Transaction velocity, individual transaction values, and chargeback rates can all sit within the merchant's expected range — because the laundering volume is being shaped to fit that range. A static rules engine evaluating each transaction against the merchant's expected profile sees nothing wrong, because nothing wrong is happening at the transaction level. The problem is at the merchant identity level, and the merchant identity is exactly what the laundering operation has constructed to look right.
Detection therefore has to operate on different inputs. The signals that expose laundering are structural — relationships between technical artifacts (IPs, DNS records, metadata), behavioral patterns (volume profile versus declared business, traffic patterns versus processing volume), and active validation (what actually happens when a test transaction runs through the merchant's checkout). Each input is individually weak; the combinations are conclusive. Transaction laundering detection is a correlation problem, not a matching problem, and detection systems built for matching produce systematically poor results.
This is also why the schemes have moved aggressively to require certified detection capability. Mastercard's MMSP certification specifically validates transaction laundering detection as a core capability area, because the schemes themselves recognize that ad-hoc detection produces inadequate coverage at scale.
What Transaction Laundering actually is
Transaction laundering takes several forms in practice, and the detection program has to cover all of them.
The most common form is the front merchant: an approved merchant account is used to process payments for an unapproved business, often run by the same operator or a related party. The front merchant has a legitimate website, a coherent business model, and a passable transaction profile. The unapproved business sells prohibited goods, operates in a high-risk category, or runs in a jurisdiction the acquirer cannot support. Payments from the unapproved business get routed through the front merchant's checkout, often via a redirect chain or an embedded payment form that hides the actual point of sale.
The second form is the proxy merchant: an inactive or shell merchant account that exists primarily to process payments for other operators. The original business may have wound down, but the merchant account remains active and is now used as a conduit. From the acquirer's perspective, the account looks like a long-tenured, established merchant; in practice, the volume going through it has no relationship to the registered business at all.
The third form is unauthorized aggregation: a merchant approved as a single-business operator processes payments on behalf of multiple sub-merchants, effectively operating as an unregistered payment facilitator. The aggregated sub-merchants are typically in categories the original merchant was not approved for, often including categories the acquirer would not have approved at all.
The fourth form is cloned or impersonating storefronts: bad actors create new merchant accounts using cloned versions of legitimate businesses' branding and websites, processing payments under the cloned identity until the chargeback profile becomes severe enough to require shutdown.
Each form requires different detection emphasis. A working illegal merchant activity detection program covers all four.
What Transaction Laundering Detection covers
Effective transaction laundering detection is a layered correlation discipline. Each layer addresses a category of evasion.
Deep entity linking and network mapping
The foundation is mapping the relationships between merchant identities, technical artifacts, and behavioral patterns to expose the underlying networks that legitimate-looking front merchants are part of. The entity linking combines IP records, DNS configurations, hosting metadata, payment endpoint patterns, beneficial ownership, and operational signals to surface the merchants that share enough structural signal to be related even when none of them have declared the relationship.
Visualizing the network is part of the operational value. Investigators looking at a list of merchants see scattered records; investigators looking at the network graph see clusters that immediately reveal the structure. The graph is what makes the detection actionable.
Working programs achieve up to 4x higher detection accuracy with deep entity linking compared to manual checks or legacy tools, because the correlation runs at scales human analysts cannot match.
IP, DNS, and metadata correlation
The technical layer of the entity linking. Merchants that share IP ranges, DNS configurations, hosting providers, SSL certificate registrations, or operational metadata are not always related, but they are often enough to warrant investigation. The signals get stronger when multiple technical artifacts cluster across multiple merchant identities — at the point where five merchants share an IP block, a registrar, and a similar payment routing pattern, the cluster is unambiguous regardless of what the individual merchant records say.
This is also the layer that catches infrastructure reuse. Laundering operations frequently reuse infrastructure across iterations — when one front merchant gets shut down, the next one launches with overlapping technical signatures. Continuous correlation catches the pattern early in the new operation rather than after the chargebacks start.
Active validation through test transactions
Static signals can be ambiguous. Active validation removes the ambiguity by performing the action — running a controlled test transaction through the merchant's checkout — and recording what actually happens. The test reveals proxy behavior, hidden payment redirections, illicit redirect-to-pay flows, and any divergence between the merchant's declared payment endpoint and the actual processor handling the volume.
For laundering operations specifically, the test transaction is often the conclusive evidence. A merchant whose checkout routes payments to a processor different from the one declared on file, or whose checkout form is hosted on a domain unrelated to the registered merchant, is producing evidence that survives review.
Cloned storefront and shell company filtering
The final layer is identifying merchants whose storefront content is cloned from legitimate businesses, or whose corporate registration is a shell with no operational history. Cloned content matching, registration anomaly detection (newly formed entities with no commercial track record claiming high projected volume), and operational presence validation all feed into the same scoring layer.
This layer matters most at onboarding. Filtering out cloned storefronts and inactive shells early prevents them from entering the portfolio in the first place — which is materially cheaper than detecting them after they have started processing.
Transaction laundering vs. card fraud
A common conflation: that strong card fraud detection should also catch transaction laundering. It does not, and the gap is important to articulate.
Card fraud detection is about the cardholder side. The signals are about the card, the cardholder, the issuing relationship, and the transaction context. The detection is mature and broadly effective at the issuer-side problem.
Transaction laundering is about the merchant side. The signals are about the merchant entity, the merchant network, and the relationship between declared business and actual activity. The detection requires entity linking, behavioral correlation, and active validation — none of which are core capabilities of card-side fraud platforms.
Acquirers using card fraud platforms for transaction laundering detection routinely find themselves with a strong card-fraud profile and a weak laundering profile, because the platform was built for the wrong problem. Specialized merchant fraud detection tooling is what closes that gap.
How transaction laundering detection works in practice
A working transaction laundering detection program runs as a continuous correlation operation with active validation as a targeted layer.
Continuous correlation runs across the active portfolio, evaluating entity links, technical artifacts, and behavioral patterns to surface the merchants whose structural profile suggests laundering risk. The output is a prioritized list of merchants that warrant investigation, ordered by the strength of the correlation evidence.
Active validation runs against the prioritized list. Test transactions execute through the targeted merchants' checkouts, capturing endpoint URLs, redirect chains, screenshots, and metadata. The validation either confirms the suspicion (the actual routing is materially different from the declared setup) or removes it (the routing matches, the suspicion was a false positive).
Investigation works on the validated cases. Investigators see the network graph, the technical evidence, the behavioral patterns, and the active validation result in a single case file, with the audit trail captured automatically. Remediation — typically merchant termination or restriction — happens on the basis of the case file, not on circumstantial signals.
Reporting closes the loop. Continuous BRAM and VIRP exposure tracking, scheme audit response readiness, and portfolio-level laundering metrics all flow from the detection program's output. The schemes' own expectations for detection are met by the same evidence the internal program is using.
Laundering signals: what the data is telling you
The most useful laundering signals are correlations rather than individual flags.
A merchant whose declared business is kitchenware, whose website traffic profile matches a kitchenware merchant, but whose transaction volume profile (ticket size distribution, time-of-day patterns, geographic distribution) matches a gambling operation is producing a high-conviction signal. The transaction profile alone might be ambiguous; the comparison against the website and declared business is conclusive.
A network of five merchants sharing IP ranges, registrar history, and payment routing patterns, none of whom have declared a relationship, is a network signal. The individual merchants might pass review; the cluster does not. This is the pattern that deep entity linking is built to catch.
A merchant whose test transaction reveals a checkout routing through a processor unrelated to the declared setup, with the payment form hosted on a domain that registers to a different operator, is producing direct evidence. This is the kind of finding that survives review and supports immediate action.
The combinations are where detection works. A program that flags individual signals one at a time produces noise; a program that scores combinations produces the kind of intelligence the schemes' own programs respond to.
What to look for in a transaction laundering detection platform
When evaluating transaction laundering detection platforms, the questions that matter are about correlation depth, validation capability, and integration. Does the platform run deep entity linking across IPs, DNS, metadata, and behavioral patterns, or does it rely on transactional signals alone? Does it include active validation through test transactions, or only static analysis? Does it produce network graphs and case files, or only individual alerts?
Detection accuracy benchmarks matter. Working systems demonstrate a measurable improvement over manual checks and legacy tools — typically 3–4x higher accuracy in like-for-like portfolio testing. A platform that cannot demonstrate this kind of improvement is not solving the correlation problem.
Audit handling is the next filter. Laundering findings frequently lead to merchant termination and scheme reporting, which means the evidence has to be defensible. Timestamped screenshots, redirection chains, metadata logs, and exportable case files are required, not optional.
Certification is the final filter. A platform certified as a Mastercard MMSP for laundering detection meets the schemes' own bar; an uncertified platform requires the acquirer to demonstrate alignment to the schemes themselves.
How Onlayer automates transaction laundering detection
Onlayer's Transaction Laundering Detection is powered by Onlayer's proprietary C.A.R.V.E.™ AI — built specifically to map the complex correlation patterns that expose laundering networks. The system correlates IPs, DNS records, metadata, and online presence traces to map behavioral and technical patterns visually, achieving up to 4x higher detection accuracy compared to manual checks or legacy tools.
For active validation, the service detects proxy behavior, hidden payment redirections, and illicit redirect-to-pay flows automatically — including through automated test transactions that validate actual payment endpoints and merchant legitimacy at the checkout layer. Cloned storefronts and inactive shell companies are filtered early in the approval process, preventing the laundering risk from entering the portfolio in the first place.
For audit and scheme compliance, the service reduces scheme exposure to laundering-related BRAM/VIRP violations by up to 70% — and produces definitive evidence files (screenshots, redirection chains, metadata logs) that support both internal remediation and immediate scheme audit response. The defense is delivered as part of an officially Mastercard-certified MMSP, which carries weight in scheme audit response that an uncertified platform does not.
Operationally, the service integrates seamlessly with Merchant Monitoring Service, Transaction Monitoring Service, Merchant Onboarding Service, and BRAM/VIRP Checks — so laundering detection runs as a connected layer in the same workflow that produces onboarding decisions, transaction monitoring alerts, and continuous compliance oversight. Online Presence Detection and Customized Test Transaction round out the active validation layer, ensuring that hidden domains and gray-label routing get caught before they reach scheme attention.
