Transaction laundering is when an unapproved business runs its payments through the account of an approved one. A merchant boarded to sell yoga mats routes card volume for an unlicensed pharmacy through its own descriptor. The acquirer sees clean settlement against a known MID; the real seller never went through underwriting. Detection means finding the second business hiding inside the first.
This is a harder problem than card fraud because the cardholder usually got what they paid for. Someone buying counterfeit sneakers or off-label medication rarely files a dispute. The chargeback rate, the number acquirers watch by reflex, stays flat. You are looking for a business that does not want to be seen, operating behind a descriptor that was legitimately issued, inside a portfolio where the loudest alarm is silent by design.
What the settlement ledger gives away
The undisclosed merchant has to move money, and moving money leaves a shape. A florist that boarded at 40 euros average ticket with weekday-daytime volume starts settling 180-euro tickets at 2am, weighted toward a handful of countries the onboarding file never mentioned. The mismatch between the boarded profile and the settled behaviour is the first thing worth modelling.
Concretely, we build features off settled transactions and compare them against the merchant’s declared profile at onboarding:
- Ticket-size distribution versus the declared average and the MCC peer group, not just the mean but the shape of the tail.
- Time-of-day and day-of-week volume against what a real storefront in that category looks like.
- Cross-border mix and issuer-country concentration relative to the stated customer base.
- Refund and reversal patterns, which behave differently when the “merchant” is testing card ranges rather than serving buyers.
- Descriptor churn and the frequency of new terminal IDs appearing under one MID.
None of these is conclusive alone. A florist can have a good December. The signal is the joint distribution drifting away from the boarded baseline and staying there, which is why a drift monitor on each merchant’s own history tends to beat a fixed threshold. You are asking whether this account still behaves like the business you underwrote.
Point-in-time features and the leakage trap
The mistake that quietly ruins these models is training on data the model would not have had at scoring time. If your label comes from an investigation that closed in March, and you build features from settlement data through April, the model learns from the future. It will look excellent in backtest and fall apart in production, because at inference the March-forward data does not exist yet.
Every feature has to be reconstructed as of the scoring timestamp. That means a feature store with proper as-of joins, not a snapshot of the current table. The merchant’s average ticket must be its average ticket up to the day you scored, computed on data that had actually settled and reconciled by then. Reconciliation lag matters here: a transaction authorised today may not settle for two or three days, so a naive feature that assumes today’s ledger is complete introduces lookahead. Build the eval set from frozen point-in-time snapshots and keep the lineage so a reviewer can reproduce any score.
The label side has the same problem in reverse. Confirmed transaction laundering is rare and confirmed late, often after a card scheme fine or a law-enforcement referral. Treat these as a small, precious positive set. We keep an eval set that a fraud investigator has actually adjudicated, and we resist the urge to pad it with weak heuristic labels, which teach the model to imitate the heuristic instead of finding the crime.
Linking the businesses that share a spine
The strongest evidence rarely lives in one account. A laundering operation usually spans several front merchants, and they leave shared fingerprints: the same payout bank account, the same beneficial owner under a different spelling, a checkout page hosted on the same server, an IP block that shows up across supposedly unrelated MIDs, a phone number reused in three onboarding files.
Entity resolution turns those fragments into links. Once you resolve accounts to the entities behind them, the portfolio becomes a graph, and transaction laundering shows up as structure: a cluster of thin front merchants funnelling settlement to one payout account, or a storefront URL that resolves to a product catalogue nobody boarded. A graph view also catches the reboarding move, where an operator whose MID was terminated simply opens a new one with a fresh descriptor and the same infrastructure underneath.
- Resolve payout accounts, owners, devices, and URLs to canonical entities before scoring.
- Score at the entity and cluster level, not only per transaction, so the risk of a shared payout account propagates to every merchant hanging off it.
- Keep the resolution decisions in the audit trail, because a link that triggers a termination has to survive scrutiny from the merchant, the scheme, and a regulator.
Where the model stops and a human starts
Terminating a merchant is a consequential action with real revenue and legal weight, so these models raise cases, they do not close them. The output that matters is a ranked queue an investigator can work through, with each score backed by the specific features that drove it: the ticket drift, the shared payout account, the storefront that sells something other than what was boarded. A score with no explanation is unworkable, because the analyst has to write a narrative that holds up if the merchant appeals or a scheme asks how the decision was reached.
That constraint shapes the whole build. A false-positive budget keeps the queue small enough that analysts investigate rather than rubber-stamp. Every case an investigator adjudicates flows back as a label, which is how the eval set grows and how you measure drift as launderers change tactics against you. Alert volume is the wrong target. Judge the model by what happens when an investigator works a case: does it surface the undisclosed business, or a florist that had a good December? One that keeps landing on the former, at a rate the queue can actually clear, is doing its job.
FAQ
How is transaction laundering different from ordinary card fraud?
Card fraud uses a stolen instrument against a real merchant. Transaction laundering uses a real card against a fake merchant, routing an undisclosed business through an approved account. The cardholder often consented to the purchase, so chargebacks stay low and the usual fraud triggers never fire.
Why don't chargeback rates catch it?
Because the buyer wanted the product. Someone buying counterfeit goods or unlicensed pharmaceuticals rarely disputes the charge, so the account can look pristine on the metric acquirers watch most closely. Absence of chargebacks is not evidence of a clean book.
What data do you actually need to start?
Settled transaction history with merchant, terminal, and descriptor detail; the onboarding file; and any device or IP telemetry the gateway captured. Web crawl data on the merchant's stated storefront helps but the settlement ledger is where the pattern lives.