BRAM and Transaction Laundering: What Merchant Monitoring Covers

Transaction laundering detection is not a niche compliance concern. Industry research estimates that transaction laundering through online merchant accounts exceeds $200 billion annually in processed volume, according to research cited by the payments risk community. Most of it never triggers an alert.

‍

That gap is structural. The merchants running these schemes are not unsophisticated. They register clean businesses, submit complete documentation, present coherent websites, and process payments in patterns that look entirely normal at the surface level. By the time a risk team notices something unusual, months of undisclosed activity have already settled through the account.

‍

This brief explains how transaction laundering works, why it is specifically addressed under Mastercard's Business Risk Assessment and Mitigation (BRAM) program, and why the monitoring tools most acquirers rely on are not built to find it.

‍

‍

‍

What Transaction Laundering Actually Is

‍

Transaction laundering occurs when a legitimate merchant account is used to process payments for a business that was never disclosed to the acquirer.

‍

The registered merchant, which passed onboarding, becomes a conduit for one or more undisclosed storefronts, selling goods or services that would not have been approved, or would have required enhanced due diligence, had they been submitted at application.

‍

The key distinction from "normal" merchant fraud is intent and structure. A fraudulent merchant application involves deception at the point of onboarding. Transaction laundering involves a merchant who may have onboarded cleanly, then activated or exposed their true business model after approval, or added undisclosed verticals to an existing account.

‍

Three mechanics are common in practice:

‍

• Shell merchant with multiple web properties. The registered URL represents a benign business (apparel, supplements, general retail). Separate websites, often with distinct domain registrations and branding, funnel customers to the same payment processing infrastructure. The descriptor on the cardholder's statement points back to the registered merchant.

‍

• Multiple merchant identification numbers (MIDs) operated by connected principals. Undisclosed related entities, sharing beneficial owners or key management personnel (KMPs), operate separate merchant accounts. Volume is distributed across accounts to suppress individual chargeback ratios and avoid category-specific monitoring thresholds.

‍

• Post-onboarding content pivot. A merchant registers as a low-risk category, establishes a clean transaction history, then migrates toward higher-risk or prohibited goods and services. The website content changes. The registered URL may still resolve to the original compliant landing page, while the actual commerce operates elsewhere.

‍

In all three cases, the acquirer is processing payments for a business it never reviewed.

‍

‍

‍

‍

What BRAM Requires on This Specific Issue

‍

Mastercard's BRAM program requires acquiring banks to maintain ongoing oversight of their merchant portfolios, with explicit obligations that extend well beyond chargeback thresholds.

‍

The relevant requirements for transaction laundering specifically include:

‍

• Web presence analysis beyond the registered URL. Acquirers must examine what a merchant is actually operating online, not only the URL submitted at onboarding. BRAM requires that the acquirer investigate evidence of undisclosed web activity associated with the merchant entity, its principals, and its payment infrastructure.

‍

• Undisclosed business activity detection. When a merchant is found to be processing transactions for goods or services not disclosed in the merchant agreement, this constitutes a BRAM violation. The acquirer's monitoring program must be capable of identifying this, which includes reviewing content, product listings, pricing structures, and business model consistency over time.

‍

• Merchant connection mapping. BRAM requires that acquirers assess the broader merchant ecosystem, including identifying related storefronts or domains operated by the same entity or principals. A merchant that appears to be a standalone operation may control several payment-facing websites that are all routing to the same processing account.

‍

• Continuous monitoring, not point-in-time review. BRAM obligations do not end at onboarding approval. Acquirers are expected to maintain ongoing surveillance for changes in merchant behavior, website content, business model, and transaction patterns that could indicate undisclosed activity has been introduced.

‍

Failure to maintain adequate monitoring exposes acquirers to BRAM enforcement fines and, in cases involving prohibited merchant categories, to Mastercard program termination.

‍

‍

‍

Why Transaction Laundering Is Harder to Detect Than Other Merchant Fraud

‍

Most acquirer monitoring programs are built to catch explicit signals: prohibited keywords in website content, MCC codes associated with high-risk verticals, chargeback ratios above defined thresholds, or adverse media hits on merchant names. These tools work for the fraud they were designed to catch. Transaction laundering is specifically engineered to avoid them.

‍

Several factors make it structurally resistant to conventional detection:

‍

Laundering merchants deliberately avoid flagged terminology. A merchant processing payments for an unregistered pharmaceutical operation will not describe their products using terms that trigger a compliance keyword list. Content is written to appear generic, health-adjacent, or retail-oriented. Category signals are suppressed by design.

‍

The registered URL remains compliant. Many monitoring programs check only the URL submitted at onboarding. Laundering merchants maintain the registered site as a clean front. The actual commerce, and any content that would raise flags, lives on separate domains that are never surfaced to the acquirer unless the monitoring scope extends beyond the registered URL.

‍

Content cloaking defeats surface-level scans. Technically sophisticated operators use cloaking techniques that serve different content depending on who is requesting the page. Monitoring tools relying on direct HTML retrieval may receive a compliant version of the site. Actual customers, particularly those arriving via specific referral paths or geographies, see different content.

‍

Multilingual and cross-jurisdictional gaps. Monitoring tools trained predominantly on English-language content frequently miss undisclosed activity conducted in other languages. A merchant operating an unregistered sales channel in a non-English market may generate no alerts in a system that cannot interpret the content it is scanning.

‍

Transaction patterns look normal in isolation. Because the undisclosed business runs alongside or through the registered merchant, the aggregate transaction data often resembles a functioning retail operation. Average ticket sizes may be consistent. Dispute rates may be within tolerance.

‍

The signal is in the relationship between the transaction data and the merchant's actual business model, not in the transaction data alone.

‍

‍

‍

‍

The Signals Risk Teams Should Actually Be Looking For

‍

Effective transaction laundering detection depends on building a more complete picture of what the merchant actually is, not just what it submitted on its application.

‍

The most operationally useful signals we examine include:

‍

Web presence signals:

‍

• Multiple domain registrations sharing the same registrant contact, IP infrastructure, or SSL certificate chain

‍

• Domains registered shortly before or after merchant onboarding, pointing to the same payment processing setup

‍

• Disparities between the registered URL's product content and the transaction descriptor shown on cardholder statements

‍

• Evidence of multiple distinct checkout flows or payment pages operating under different branding

‍

Business model signals:

‍

• Product or service categories on active websites that do not match the MCC approved at onboarding

‍

• Pricing structures, terms of service language, or refund policies inconsistent with the stated business type

‍

• Fulfillment or delivery model discrepancies (for example, a registered B2B services merchant with active consumer checkout flows)

‍

Connection mapping signals:

‍

• Shared principals, beneficial owners, or key contacts across multiple merchant accounts

‍

• Common corporate registration addresses, phone numbers, or email domains across distinct merchant entities

‍

• Related storefronts discoverable through web graph analysis, even when not surfaced through direct search

‍

Behavioral signals in transaction analysis:

‍

• Volume distribution across related MIDs that suppresses individual chargeback metrics

‍

• Sudden increases in transaction volume without corresponding changes in disclosed business activity

‍

• Descriptor variation across transactions that cannot be explained by the registered business model

‍

No individual signal is definitive. Transaction laundering detection is contextual: the accumulation of signals, evaluated against a merchant's stated business model and ongoing web behavior, is what generates actionable intelligence.

‍

‍

‍

‍

Why Keyword-Based Monitoring Cannot Solve This

‍

The core problem with rule-based and keyword-matching monitoring systems is that they are reactive by design. They identify what has already been categorized as a risk indicator and look for its presence. Transaction laundering, by definition, involves merchants who have learned to avoid those categories.

‍

Consider how this plays out operationally. A monitoring system flags content containing terms associated with prohibited pharmaceuticals. A laundering merchant operating in that space simply does not use those terms. The product is described generically. The site passes the scan. The undisclosed business continues processing.

‍

The same structural limitation applies to MCC monitoring. If a merchant's registered MCC is apparel, and the actual undisclosed business is in a restricted vertical, the transaction data reflects apparel volumes. The MCC alert does not fire because the MCC on the account has not changed.

‍

This is not a calibration problem. It is not something that can be fixed by adding more keywords to a watchlist or lowering a threshold. Rule-based systems can only detect patterns they were built to recognize.

‍

They cannot identify that a merchant's actual business model is different from its disclosed one, because that determination requires understanding what the merchant is doing, not matching text strings against a list.

‍

The Financial Crimes Enforcement Network (FinCEN) has explicitly noted that payment processors can be exploited to mask illegal or suspicious transactions, and that the complexity of payment processing arrangements can obscure the nature of underlying business activity.

‍

The monitoring implication is that compliance programs must be designed to look through the processing layer at the actual merchant operation.

‍

‍

‍

How AI-Driven Monitoring Addresses the Detection Gap

‍

The difference between contextual, AI-driven merchant fraud detection and keyword matching is not speed. It is the nature of the analysis.

‍

An AI-based monitoring system approaches merchant risk the way an experienced underwriter does: by building a coherent picture of what the business actually is, then evaluating whether that picture is consistent with what the merchant disclosed. Several capabilities make a material difference in transaction laundering detection specifically:

‍

Business model classification, not keyword scanning. Rather than searching for prohibited terms, contextual analysis determines what type of business a merchant is operating based on product descriptions, pricing structures, fulfillment models, and commercial language.

‍

A merchant whose active website describes a business model inconsistent with its registered MCC is flagged regardless of whether it contains any explicitly prohibited content.

‍

Full web graph analysis. Monitoring that extends beyond the registered URL, systematically mapping related domains, shared infrastructure, and connected storefronts, surfaces the undisclosed business activity that surface-level checks cannot see.

‍

Content cloaking detection. Systems that retrieve and analyze content across multiple request vectors, rather than a single direct HTTP call, reduce the effectiveness of cloaking techniques as a concealment method.

‍

Continuous post-onboarding monitoring. FATF has identified merchant account laundering as a growing money laundering and terrorist financing typology, noting that criminals exploit the post-onboarding window when monitoring intensity typically drops. Continuous monitoring that runs independently of the onboarding cycle catches pivots that a periodic review schedule would miss.

‍

Cross-merchant connection mapping. Systematic identification of shared principals, corporate registrations, and web infrastructure across the merchant portfolio makes MID-splitting strategies visible. What looks like five independent merchants may be a single operation distributing volume to stay below individual thresholds.

‍

The result is a monitoring posture that aligns with what BRAM actually requires: not a checkbox that confirms the registered URL looks clean, but a continuous, evidence-based assessment of what the merchant is doing.

‍

‍

‍

About Ballerine

Ballerine is an AI-powered merchant risk intelligence platform built for acquirers, payment service providers (PSPs), and payment facilitators (PayFacs) that need to meet BRAM and VIRP compliance requirements, detect transaction laundering, and monitor merchant portfolios at scale.

‍

For transaction laundering detection specifically, Ballerine's capabilities include:

‍

• Contextual AI analysis that classifies merchant business models based on actual web behavior rather than keyword lists, identifying undisclosed verticals regardless of how they are described

‍

• Web presence analysis beyond the registered URL, systematically mapping related domains, connected storefronts, and undisclosed web properties associated with a merchant entity or its principals

‍

• Content cloaking detection, analyzing merchant sites across multiple retrieval methods to surface content that standard monitoring passes over

‍

• Continuous merchant monitoring that runs throughout the merchant lifecycle, not only at onboarding, catching post-approval pivots before they generate chargebacks or BRAM violations

‍

• Cross-merchant connection mapping, identifying shared principals, infrastructure, and corporate registrations across the portfolio to surface MID-splitting and related-entity schemes

‍

Ballerine also supports direct BRAM compliance workflows, including web presence audits, undisclosed business activity reviews, and MCC consistency analysis, with outputs structured for compliance documentation and escalation.

‍

Risk teams can run 5 free merchant reports to evaluate the detection quality on their own portfolio before committing. Or schedule a demonstration to see how AI-powered merchant monitoring catches what rule-based tools miss.

‍