Every payment platform — a card network, an acquiring bank, or a payment facilitator like Stripe or Adyen — signs up merchants after reviewing what they sell, how much they expect to process, and how risky their business is. That review, called underwriting, decides which bank the merchant settles through, what reserve is held back, and what fees apply. The entire system depends on one assumption: the merchant that was approved is the merchant that actually processes the transactions.

Transaction laundering breaks that assumption. A seemingly harmless merchant — say, a small online bookstore — gets approved through underwriting. Behind the scenes, that bookstore’s payment credentials are quietly used to process card payments for a completely different business: an unlicensed pharmacy, an offshore gambling site, or a subscription trap that generates a flood of chargebacks. The card network and the acquiring bank have no idea. They believe they are processing book sales. In reality, they are exposed to a business they never approved, never assessed, and would likely have rejected outright.

This is also called “factoring” or “packet laundering” in payments risk circles, and it is one of the hardest fraud patterns to catch because, transaction by transaction, nothing looks obviously wrong. The card is valid, the amount is reasonable, the cardholder authorizes it. The fraud is not in any single transaction — it is in the mismatch between what a merchant is supposed to be selling and what it is actually selling. Detecting that mismatch in real time, at the scale of millions of transactions per minute, is a genuinely hard distributed systems and machine learning problem, and it is the subject of this tutorial.

We will design a system end to end: how transactions are ingested and enriched, how a merchant’s behavior is compared against its declared business profile, how a network of shell merchants can be uncovered through graph analysis, how a hybrid of rules and machine learning produces a real-time risk score, and how human investigators are looped in without slowing down the 99.9 percent of transactions that are perfectly legitimate.

Transaction laundering is not a new problem — only the scale and automation are new. Understanding how the practice migrated from the physical world into online payments makes the modern architecture much easier to justify.

Transaction laundering predates online payments. In the physical world it was called “factoring” — a merchant with an approved card terminal would run transactions through their terminal on behalf of an unrelated business, taking a cut for the favor. Card networks caught on and began requiring merchants to only process transactions for their own registered business.

The internet made the problem worse in two ways. First, it became trivial to spin up a storefront that looked legitimate — a WordPress site selling “digital marketing services” — while the actual payment traffic flowing through it belonged to a pharmacy selling controlled substances without a prescription, or an adult content site operating in a jurisdiction where it was restricted. Second, payment facilitator (PayFac) models and platforms like Shopify, Stripe, and PayPal made merchant onboarding fast and largely automated, which sub-merchants could exploit: get approved quickly with a clean-looking front, then route disallowed traffic through it before anyone notices.

Early detection relied almost entirely on manual review: compliance teams would periodically sample merchant websites, or wait for chargeback spikes and card network fines (Visa’s Global Brand Protection Program and Mastercard’s similar mechanisms exist specifically to penalize acquirers for transaction laundering they fail to catch). This was reactive — damage was usually done before anyone noticed. As payment volumes exploded through the 2010s and PayFac models proliferated, manual sampling became mathematically impossible: you cannot manually review millions of merchant storefronts.

The modern approach, and the one this tutorial designs, treats transaction laundering detection as a real-time, always-on system: every transaction is scored the moment it happens, using a mix of behavioral analytics, network and graph analysis (since laundering rings often share infrastructure — IP addresses, bank accounts, device fingerprints, even website templates), and machine learning trained on historical laundering cases. This shift from periodic audits to continuous, transaction-level surveillance mirrors the same evolution seen in credit card fraud detection more broadly.

To design the system correctly we need a crisp definition, because every downstream component — from the rule engine to the graph model — is only as good as the precision of the problem statement.

Transaction laundering occurs when a payment is processed through a merchant account that was approved for one business, but the actual goods or services being paid for belong to a different, undisclosed business — usually one that would not have passed underwriting on its own, because it is higher risk, illegal in the relevant jurisdiction, or simply undisclosed for tax or compliance reasons.

There are three common structural patterns worth knowing, because each leaves different fingerprints in the data:

It is also worth distinguishing transaction laundering from money laundering in the traditional financial-crime sense, even though the two are related and the terminology overlaps. Money laundering, broadly, is the process of making illegally obtained funds appear legitimate by passing them through a series of transactions. Transaction laundering is one specific technique that can serve that goal — by disguising the true source or nature of a business’s revenue behind an approved merchant account — but transaction laundering can also occur for reasons that have nothing to do with dirty money, such as a legitimate but restricted business (an online pharmacy without proper licensing, an age-restricted product seller) simply trying to avoid the compliance burden and higher fees that come with proper high-risk underwriting. Both scenarios matter to a payment platform, and the detection system described in this tutorial does not need to determine intent — it only needs to reliably surface the mismatch between declared and actual business activity, and let compliance and legal teams determine the appropriate downstream response.

At a system level, five capabilities have to work together: ingest every transaction with enough context, enrich it, score it in parallel with rules and ML, route the risky cases to humans, and act on confirmed laundering merchants — all inside a tight sub-200 millisecond added-latency budget on the payment authorization path.

Payment approval is already a tight synchronous flow, so the risk platform lives at the edges of that flow: it must add value without adding much delay, and it must degrade gracefully when any of its own components are slow or unavailable.

graph TB
    A["Merchant Checkout or POS"] -->|"Transaction Request"| B["API Gateway"]
    B --> C["Load Balancer"]
    C --> D["Payment Authorization Service"]
    D -->|"Publish Event"| E["Transaction Event Stream Kafka"]
    E --> F["Real Time Feature Enrichment Service"]
    F --> G["Feature Store Online plus Offline"]
    F --> H["ML Scoring Engine"]
    F --> I["Rules Engine"]
    G --> H
    J["Merchant Network Graph DB"] --> H
    J --> I
    H --> K["Decision Orchestrator"]
    I --> K
    K -->|"Low Risk"| L["Auto Approve Continue Auth"]
    K -->|"High Risk"| M["Case Management Service"]
    K -->|"Medium Risk"| N["Step Up Review Queue"]
    M --> O["Investigator Dashboard"]
    O --> P["Merchant Risk Action Service"]
    P --> Q["Merchant Account Database"]
    P -->|"Suspend or Restrict"| D

Notice the design principle at the center: the ML Scoring Engine and Rules Engine run in parallel, not in sequence, and both feed a Decision Orchestrator. This is deliberate — rules give explainable, deterministic, low-latency signals (for example, “MCC declared as retail but 40 percent of SKUs match known pharmacy keywords”), while the ML model captures subtler statistical patterns that are hard to hand-write as rules (for example, a specific combination of ticket size distribution, decline rate, and payout account age). Combining them, rather than picking one, is a recurring theme in modern fraud systems.

Every transaction flowing through the platform carries two kinds of information — transaction-level attributes and merchant-level context — and the detection engine continuously compares what a merchant said it would do against what it is actually doing.

Transaction-level attributes are things like amount, currency, card BIN, time, IP, and device fingerprint. Merchant-level context includes the declared MCC, website URL, business description, historical processing volume, and payout bank account. The detection engine’s job is to continuously compare declared behavior against observed behavior, at both the individual transaction level and the aggregate behavioral level.

Internally, this comparison happens in three layers that all execute for every transaction:

These three layers’ outputs are combined by the Decision Orchestrator using a weighted, configurable policy (not a hardcoded average) so that risk teams can tune sensitivity per merchant category, per region, or per card network requirement without redeploying code.

Walking through a single transaction end to end clarifies how the pieces connect in time, and where the tight latency budget forces particular design choices.

graph LR
    A["1. Cardholder pays at merchant checkout"] --> B["2. Auth request hits API gateway"]
    B --> C["3. Payment service requests risk score"]
    C --> D["4. Feature enrichment real time plus cached"]
    D --> E["5. Parallel scoring Rules plus ML plus Graph"]
    E --> F["6. Decision orchestrator aggregates score"]
    F --> G{"7. Risk tier"}
    G -->|"Low"| H["8a. Approve and log for offline retraining"]
    G -->|"Medium"| I["8b. Soft hold and queue for investigator"]
    G -->|"High"| J["8c. Decline flag merchant open case"]
    J --> K["9. Case assigned to investigator"]
    K --> L["10. Investigator confirms or dismisses"]
    L --> M["11. Feedback loop updates ML training data"]

Two details matter here. First, the scoring step (step 5) must complete inside the payment authorization window, which is typically 150 to 300 milliseconds end to end across the whole payment stack. That leaves the risk platform a budget of roughly 30 to 60 milliseconds, which is why feature enrichment relies heavily on pre-computed, cached values rather than querying raw historical transaction tables on the fly.

Second, the feedback loop (step 11) is what makes the system improve over time rather than staying static. Every investigator decision — confirmed laundering or false positive — becomes a labeled training example. Without this loop, the ML model would slowly drift out of date as laundering rings adapt their tactics to evade whatever the model currently catches.

The single most powerful signal in transaction laundering detection is not any individual transaction attribute — it is the network structure connecting merchants.

Laundering rings almost always share infrastructure because setting up dozens of fully independent fronts is expensive and operationally painful for the fraudster. They reuse the same payout bank account, the same website template, the same hosting IP, the same phone number for onboarding verification, or the same device fingerprint when filling out merchant applications.

We model this as a graph: merchants, bank accounts, devices, IP addresses, and website templates are all nodes; an edge connects two nodes whenever they co-occur (for example, “Merchant A uses Bank Account X”). Once a single merchant in a connected cluster is confirmed as laundering, graph propagation algorithms (personalized PageRank, label propagation, or a trained Graph Neural Network) can surface every other merchant in that cluster as high-risk — often before any of them individually trip a rule or ML threshold.

graph TD
    M1["Merchant A Bookstore"] --> B1["Bank Account XXXX 4471"]
    M2["Merchant B Consulting"] --> B1
    M3["Merchant C Gift Cards"] --> B1
    M1 --> D1["Device Fingerprint FP 9921"]
    M2 --> D1
    M4["Merchant D Wellness"] --> D1
    M2 --> IP1["IP Subnet 41 20 x x"]
    M3 --> IP1
    M4 --> IP1
    B1 --> CL["High Risk Cluster Flagged"]
    D1 --> CL
    IP1 --> CL

This graph must be stored in a database purpose-built for traversal queries (see the Databases section), and updated incrementally as new merchant relationships form, since recomputing the entire graph on every transaction would be far too slow.

The ML layer answers a narrower question than the rules layer: given everything we know about this merchant’s behavior over time, and this specific transaction, how similar is this to confirmed historical laundering cases?

We frame this as a supervised learning problem with two related models working together.

8.1 Merchant-level behavioral model

This model scores a merchant’s rolling profile (updated hourly or daily), not a single transaction. Features include: ratio of average ticket size to the category norm for the declared MCC, velocity of new payout bank account changes, chargeback rate trend, ratio of international to domestic cards, time-of-day transaction distribution compared to the expected pattern for the declared business type, and website content-drift signals (has the site’s product catalog changed dramatically since onboarding, based on periodic crawls).

8.2 Transaction-level scoring model

This model runs on every individual transaction and combines the merchant-level score with transaction-specific features: is this a card BIN commonly associated with laundering rings, does the transaction amount match a known “structuring” pattern (kept just under a reporting threshold), does the device fingerprint match one seen at a previously confirmed laundering merchant.

Gradient-boosted trees (XGBoost or LightGBM) remain the workhorse here because they handle mixed categorical and numerical features well, train fast on labeled historical cases, and produce feature-importance explanations that satisfy audit requirements. Graph Neural Networks are increasingly layered on top to directly consume the merchant network graph as an input rather than hand-engineering graph-derived features, but they are more expensive to serve at low latency and harder to explain, so most production systems keep GBMs as the primary real-time scorer and use GNNs for offline, batch re-scoring of the entire merchant portfolio.

8.3 Feature engineering considerations

The quality of the feature set matters more than the choice of algorithm in this domain, because the underlying signal — a mismatch between declared and actual business activity — is fundamentally about comparing a merchant against a reference distribution. That means most of the highest-value features are relative, not absolute: not “average ticket size is 180 dollars” but “average ticket size is 4.2 standard deviations above the median for MCC 5942,” not “12 percent chargeback rate” but “chargeback rate is 8x the rolling 90-day median for merchants of similar size and category.” Building and maintaining these category-level reference distributions is itself a non-trivial engineering effort — they must be recomputed regularly as market conditions shift, segmented finely enough to be meaningful (a 50 dollar average ticket is normal for a bookstore and alarming for a dollar-store gift-card retailer), and protected from being skewed by the very laundering merchants they are meant to detect, which is typically handled by excluding confirmed and highly-suspected cases from the reference population calculation.

Time-windowed features also deserve care. A merchant’s behavior in its first 30 days after onboarding is qualitatively different from its behavior after a year of clean processing, so most production systems maintain separate feature sets and even separate model calibrations for “new merchant” versus “established merchant” populations, since laundering rings disproportionately target the early, less-scrutinized window right after approval.

Rules exist for three reasons ML alone cannot cover: instant reaction to newly discovered patterns, regulatory conditions that must always trigger review, and explainability — every automated decline needs a human-readable reason.

Rules provide instant reaction to newly discovered patterns (a new banned keyword list, a newly sanctioned bank), enforce regulatory requirements that specific conditions must always trigger review regardless of model score, and offer the explainability every automated decline needs, so a compliance officer or the merchant themselves can understand what happened and why.

A practical rules engine is built on a rule definition language interpreted at runtime (not hardcoded in application code), so risk analysts can add or adjust rules without a deployment. Each rule evaluates against the same pre-computed feature set the ML model uses, keeping latency budgets shared and predictable. Rules are versioned, and every rule firing is logged with the exact feature values that triggered it, both for audit and for later inclusion as ML training features.

The Decision Orchestrator combines rule outcomes and the ML score using a policy layer: some rules are “hard stops” that override the ML score entirely (for example, a sanctioned entity match), while others simply add weight to the aggregate risk tier. This separation between “must always act” rules and “contributes to score” rules is a critical design choice risk teams need control over.

No automated system should be trusted to permanently suspend a merchant’s account without a human check for anything short of the highest-confidence cases — such as a direct sanctions list match.

Medium and high risk scores instead create a “case” — a structured record containing the transaction and merchant data, the specific rules and model features that fired, related merchants from the network graph, and a recommended action.

The Case Management Service assigns cases to investigators based on workload, specialization (some investigators focus on specific regions or merchant categories), and case priority. Investigators use a dashboard that surfaces everything needed to decide quickly: a snapshot of the merchant’s website (crawled and archived, since fraudulent merchants often change their site after being flagged), the transaction pattern visualized over time, and the graph of related merchants.

Their decision — confirmed laundering, false positive, or needs more monitoring — feeds back into two places: the Merchant Risk Action Service (which can suspend the account, hold payouts, or request additional documentation) and the ML training dataset (closing the feedback loop described in Chapter 6). This human-in-the-loop design is not a workaround for an incomplete model; it is a permanent, necessary part of the architecture because laundering tactics evolve specifically to evade whatever the model currently catches, and investigators are often the first to spot a genuinely new pattern.

The system is decomposed into independently deployable services, each owning a narrow responsibility, communicating through well-defined synchronous APIs (for the real-time scoring path) and asynchronous events (for everything that can tolerate seconds to minutes of lag).

Keeping the synchronous path (Risk Scoring API and its direct dependencies) as small and fast as possible, while pushing everything else — case creation, notifications, model retraining triggers — onto an event bus (Kafka), is the key architectural decision that lets the system scale independently: the scoring path scales with transaction volume, while case management scales with the much smaller volume of flagged merchants.

No single database serves every access pattern this system needs, so it deliberately uses several, each matched to its workload.

Caching deserves special attention because it is what makes the latency budget achievable at all. Merchant-level features (which change slowly — hourly or daily) are computed by batch or streaming jobs and pushed into the online feature store ahead of time, so the real-time path only ever does fast key lookups, never expensive on-the-fly aggregation. A write-through cache pattern keeps the online store consistent with the latest computed features, and a short TTL combined with background refresh avoids ever serving badly stale data during a live laundering event.

Data retention policy is another storage design decision worth calling out explicitly. Raw transaction events in the Kafka log are typically retained for a shorter hot window (say, 7 to 30 days) before being tiered off to cheaper cold storage (object storage such as S3, queried through a tool like Athena or Presto when needed), while aggregated, anonymized feature history is retained far longer to support model training and long-run trend analysis. Case management records — since they may be needed for regulatory examinations, card network audits, or legal disputes with a merchant — are typically retained for several years under a much stricter, legally-driven retention schedule than ordinary application logs, and are stored with immutability guarantees (write-once, append-only) so that a closed case’s evidence trail cannot be altered after the fact.

At the API Gateway and Risk Scoring API layers, traffic distribution is not one strategy but a mix, chosen per path based on what will keep caches warm and dependencies healthy.

Traffic is distributed using a layer-7 load balancer with consistent hashing on merchant identifier for certain read-heavy paths (so repeated lookups for the same merchant tend to hit warm caches on the same downstream instances) and round-robin with health checks for the stateless scoring computation itself. Circuit breakers wrap every downstream dependency call (feature store, graph service) so that a slow or failing dependency degrades gracefully — falling back to a cached, slightly stale feature set and a conservative default risk tier — rather than taking down the entire payment authorization path.

Because payment authorization can never be allowed to fail open to attackers or fail closed to legitimate merchants at scale, the system defines an explicit fallback policy: if the Risk Scoring API cannot respond within its latency budget, the transaction proceeds with a “score unavailable” flag and is queued for asynchronous post-hoc scoring, rather than blocking the payment. This trades a small amount of detection delay for payment availability, which is the correct trade-off for a system whose primary product is still “process payments reliably.”

At the scale of a large card network or PayFac, the platform must sustain millions of transaction scoring requests per minute, with tail latency (p99) staying under roughly 50 milliseconds for the synchronous scoring path. Several design choices make this achievable.

First, feature computation is decoupled from feature serving. Expensive aggregations (rolling 30-day chargeback rate, graph cluster membership) run as streaming jobs (Flink or Spark Structured Streaming) consuming the Kafka transaction log, updating the online feature store incrementally rather than recomputing from scratch. This means the real-time path never touches raw historical data.

Second, the ML model itself is served through a low-latency model server (for example, NVIDIA Triton or a custom gRPC service hosting the GBM in a compiled, optimized format) with model instances horizontally scaled behind the load balancer, and models are kept small enough (a few hundred trees, bounded depth) that inference stays in the single-digit-millisecond range.

Third, the system uses horizontal partitioning (sharding) of the Merchant Profile and Case Management databases by merchant ID range or hash, so that no single database instance becomes a bottleneck as the merchant portfolio grows into the millions.

Every stateful component is replicated across at least three availability zones, and the transaction event log (Kafka) is configured with a replication factor of three and a minimum in-sync replica count of two, so that a single broker or zone failure never loses transaction events.

The online feature store (Redis or DynamoDB) runs in a multi-AZ configuration with automatic failover, and the ML model servers are deployed statelessly behind the load balancer so any instance can be replaced without data loss.

Because the scoring path sits on the critical payment authorization flow, the system is designed around graceful degradation rather than all-or-nothing availability: if the ML scoring service is unavailable, the system falls back to rules-only scoring; if the graph service is unavailable, cluster-membership lookups fall back to the last cached value; if everything is unavailable, transactions proceed with elevated logging and are queued for asynchronous re-scoring. This layered degradation ensures payment processing — the platform’s core promise — is never blocked by a failure in the risk subsystem, while still capturing enough signal to catch laundering after the fact.

Disaster recovery follows a standard multi-region active-passive pattern for the control-plane services (Merchant Profile, Case Management), with the transaction event log replicated cross-region asynchronously, and a documented, regularly tested runbook for promoting the passive region during a full regional outage.

This system handles some of the most sensitive data a payment platform holds: merchant banking details, cardholder transaction patterns, and active fraud investigation evidence. Several security layers are non-negotiable.

Three categories of metrics matter here, and they are tracked separately because they answer different questions.

17.1 System health metrics

Standard operational metrics — p50, p95, and p99 latency of the Risk Scoring API, error rates, Kafka consumer lag, feature store cache hit ratio — tracked through Prometheus and visualized in Grafana, with alerting on latency budget breaches, since a slow scoring path directly threatens payment authorization SLAs.

17.2 Model quality metrics

Precision and recall against confirmed investigator outcomes, tracked on a rolling window, alongside feature drift monitoring (are incoming transactions statistically different from the training distribution — a strong signal that laundering rings have changed tactics or that the model needs retraining). A sudden drop in precision (more false positives) or recall (missed laundering cases) triggers a model review.

17.3 Business and risk metrics

Dollar volume of transactions flagged, average time from first suspicious signal to case resolution, chargeback dollar amount prevented, and card network compliance metrics (since acquirers face direct financial penalties for failing to catch laundering merchants within network-mandated windows). These metrics matter to compliance and risk leadership, not just engineering.

Distributed tracing (OpenTelemetry) across every service in the synchronous scoring path is essential for debugging latency spikes, since a single slow transaction can be traced through the gateway, feature enrichment, ML scoring, and rules engine to pinpoint exactly where time was spent.

Alert design in this domain has a subtlety generic monitoring playbooks miss: not every anomaly should page an on-call engineer at 3 a.m. A spike in flagged transactions could mean the model is working exactly as intended against a live laundering ring, or it could mean a bug just started mis-scoring legitimate merchants. The monitoring layer therefore needs a secondary classification step — comparing the current spike’s characteristics (is it concentrated in a handful of merchants, consistent with a real ring, or spread evenly across the whole portfolio, consistent with a scoring bug) — before deciding whether to route the alert to the on-call engineering team, the risk operations team, or both. Getting this triage wrong in either direction is costly: alert fatigue from too many false pages erodes trust in the monitoring system, while under-alerting on a genuine scoring regression can let a wave of legitimate merchants get wrongly suspended before anyone notices.

The system is deployed as containerized microservices orchestrated on Kubernetes, with the latency-critical scoring path deployed with dedicated node pools, aggressive horizontal pod autoscaling based on request rate, and pod anti-affinity rules spreading replicas across availability zones.

graph TB
    subgraph REGA["Region A Primary"]
        A1["API Gateway Pods"] --> A2["Scoring Service Pods"]
        A2 --> A3["Feature Store Cluster"]
        A2 --> A4["ML Model Server Pods"]
        A5["Kafka Cluster"] --> A2
    end
    subgraph REGB["Region B Standby"]
        B1["API Gateway Pods"] --> B2["Scoring Service Pods"]
        B2 --> B3["Feature Store Cluster"]
        B5["Kafka Cluster Replica"] --> B2
    end
    A5 --> B5
    A3 --> B3
    C["Global DNS Traffic Manager"] --> A1
    C --> B1

Deployments use a canary rollout strategy for both application code and, importantly, ML model updates: a new model version is routed a small percentage of shadow traffic first, its predictions logged and compared against the current production model’s predictions on the same transactions, before it is promoted to serve real decisions. This shadow-mode evaluation is critical for fraud models specifically, because a regression here does not just mean a bug — it can mean missed laundering or a wave of false positives that suspend legitimate merchants.

Infrastructure is defined as code (Terraform), and cost optimization is achieved through mixed instance types — spot and preemptible instances for offline batch feature computation and model training, which can tolerate interruption, and reserved or on-demand instances for the always-on synchronous scoring path, which cannot.

The patterns below keep showing up across every serious real-time fraud platform; the anti-patterns keep sinking the ones that ignored them.

19.1 Patterns used

19.2 Anti-patterns to avoid

Every architectural decision here is a bet on which trade-off is worth accepting; understanding which one is chosen — and why — matters more than knowing the components.

The central trade-off running through the whole design is precision versus recall versus latency versus availability, and no configuration eliminates it — it can only be tuned deliberately, with risk leadership signing off on where the dial sits for different merchant categories and regions.

The gap between a working prototype and a system that survives production — and card network audits — is almost entirely made up of the practices below, and avoiding the mistakes across from them.

21.1 Best practices

• Precompute everything possible; the real-time path should be doing lookups, not computation.
• Treat the investigator feedback loop as a first-class data pipeline, not an afterthought — it is the system’s main source of new labeled training data.
• Version every rule and every model, and log which version produced each decision, for both debugging and regulatory defense.
• Design explicit, tested fallback behavior for every dependency on the synchronous scoring path before it ships, not after the first outage.
• Periodically re-crawl merchant websites; onboarding-time review only captures a single snapshot, and laundering merchants frequently change site content after approval.

21.2 Common mistakes

One organizational mistake is worth calling out separately from the technical ones: treating this system purely as an engineering deliverable rather than a joint effort between engineering, data science, compliance, and risk operations. The rule thresholds, the acceptable false-positive rate, and the criteria for what counts as “confirmed” laundering are policy decisions with real financial and legal consequences, not purely technical parameters to be tuned for model performance metrics alone. Systems built without that cross-functional ownership tend to either over-flag and damage merchant relationships, or under-flag and expose the platform to the exact card network penalties this system exists to prevent.

Every major card network and large payment platform runs some version of this architecture, adapted to their scale and regulatory footprint.

The questions below come up most often in real interviews, design reviews, and post-incident discussions of this system.

Rarely. Most individual transactions in a laundering scheme look perfectly ordinary — the signal is in the pattern across many transactions and in the merchant’s connections to other merchants, not in any single event.

General merchant monitoring looks for the merchant itself defrauding customers (for example, taking payment and never delivering goods). Transaction laundering detection specifically looks for a mismatch between the declared business and the actual business being paid for — the merchant may be delivering real goods, just not the goods it was approved to sell.

Because laundering behavior often only emerges after a merchant has been operating for a while — onboarding-time signals are limited to what the merchant discloses, which is exactly what a bad actor lies about. Continuous, behavior-based monitoring is necessary precisely because static onboarding checks can be gamed.

A well-designed case management process includes a dispute and appeal path: the merchant can provide documentation, and a senior investigator reviews the original case alongside the new evidence before any suspension is finalized or reversed. Minimizing false positives through good precision is treated as seriously as catching real cases.

The graph typically links business entities and payment infrastructure (bank accounts, business devices) rather than individual consumers’ personal data, and platforms operating in regulated regions design data retention, access, and processing of this graph data to comply with applicable privacy law, often with legal and compliance teams directly involved in feature and graph-edge design.

It varies enormously with how well-disguised the front merchant is and how much shared infrastructure the ring reuses. A ring that reuses payout bank accounts or device fingerprints across multiple front merchants can be caught within hours through graph propagation, since one confirmed member instantly raises suspicion on everything connected to it. A single, carefully isolated front merchant with no shared infrastructure and behavior deliberately kept close to its declared category’s norms can take weeks or months of accumulated behavioral drift before crossing detection thresholds — which is exactly why continuous monitoring, rather than a one-time onboarding check, is the core design principle of this whole system.

Not directly, though they typically share infrastructure. Most production risk platforms build transaction laundering detection as a distinct model and rule set, sharing the underlying event stream, feature store, and case management tooling with sibling systems for account takeover, first-party (friendly) fraud, and AML transaction monitoring. Keeping the models separate, even while sharing infrastructure, matters because the behavioral signatures of these fraud types are quite different, and a single combined model tends to perform worse at each specific pattern than specialized models do.

Designing a real-time transaction laundering detection system is fundamentally an exercise in balancing four forces that pull against each other: detection accuracy, decision latency, system availability, and explainability.

The architecture in this tutorial addresses that four-way balance by splitting work across specialized services — fast deterministic rules, a statistical ML scorer, and a network graph engine — running in parallel, backed by a feature store built for sub-millisecond lookups, with human investigators closing the loop on the hardest cases and continuously retraining the system. The same architectural instincts — precompute what you can, degrade gracefully rather than fail hard, keep decisions explainable and auditable, and treat human feedback as a first-class data source — show up across almost every real-time fraud and risk system in production today, which makes this a valuable pattern to understand well beyond payments alone.