Inside a regulated financial institution, a familiar scenario unfolds. The fraud team is reviewing a real time alert that just blocked a $9,500 wire transfer at the authorization gateway. While two floors up, the AML team is opening an investigation file on the same customer's account because their transaction pattern over the last 30 days fits a structuring typology. Although the transaction involves with the same client same cash, there are two systems and two different squads working on two separate regulatory regimes. And far too often no common view of the matter.
This is what fraud detection and anti-money laundering (AML) transaction monitoring looks like today. The two disciplines have grown up in parallel, defending against overlapping threats with overlapping data, but they’re still mostly separate stacks with separate alerts and separate analysts. It is harder to defend that divide, because the criminal economy that feeds both queues is now one integrated operation. In this article we take a look at the differences, the overlap zone and what a unified architecture actually requires. The following sections:
- The Core Distinction: Different Goals, Different Architectures
- Real Time vs Near Real Time vs Batch
- The Overlap Zone: Where Fraud and AML Converge
- Rule Logic Differences
- Alert Handling and Escalation Paths
- Why Integrating Both Matters: The Unified Risk Score
- Practical Implementation: Building a Combined Architecture
- How Sanction Scanner Combines Both
The Core Distinction: Different Goals, Different Architectures
At first glance, fraud detection and anti money laundering (AML) transaction monitoring are the same. Both contract screens. Both generate alerts. Both rely on rules, models and analyst review. But underneath, they answer different questions, and that difference shapes everything else.
Fraud detection exists to prevent any direct financial loss. The loss may be to the institution itself (card fraud chargebacks, BEC initiated wires), the customer (account takeover, authorized push payment fraud) or a counterparty (merchant fraud, refund abuse). The goal is to prevent the transaction before money moves or recover it within hours of it moving. The success criteria are simple: Fraud losses avoided, false positive rate, customer friction at checkout.
AML transaction monitoring raises another question. Its purpose is to detect the flow of illicit proceeds in the financial system, regardless of whether someone is being defrauded in the specific transaction. The institution itself may never be the worse for any immediate financial harm, and often isn’t. The harm is regulatory, reputational and systematic. Failure to detect and report exposes the institution to enforcement, and allows criminal proceeds back in the legitimate economy. Success here is measured by the quality of investigations and the timely filing of Suspicious Activity Reports.
The two disciplines are also subject to different regulatory regimes and that difference makes a difference operationally. Fraud is governed by a patchwork of consumer protection rules (Regulation E in the US, the Payment Services Directive PSD2 in the EU, the UK’s APP fraud reimbursement regime), scheme level rules from Visa, Mastercard and faster payment operators, and PCI DSS for cardholder data. AML transaction monitoring is regulated by the Bank Secrecy Act and FinCEN in the U.S., the EU’s AML Directive series and the new AMLA, FATF Recommendations globally, and equivalent national regimes (Canada’s FINTRAC, the UK’s FCA and NCA, MAS in Singapore, and so on).
These dual regulations lead to two different architectures.
Fraud detection exists in the payment authorization path. It has milliseconds, and it’s often optimized for precision under pressure of speed, to block or allow, with minimum customer friction. It considers the one transaction in the context of the customer’s recent behavior, the device, the channel, and a handful of high signal external feeds.
AML transaction monitoring occurs downstream of the authorization. It has hours, or days, or more. Its rules are tuned for pattern detection over time and across counterparties, recurring structuring, layering of movement between accounts, geographic anomalies aggregated over weeks. It treats the customer's transaction history as a corpus rather than an individual payment.
The two systems are not in competition. They are mutual defenses, each blind to what the other can see.
Real Time vs Near Real Time vs Batch
The biggest architectural divider between fraud and AML stacks is the latency requirement.
In fraud detection a payment authorization request hits the issuer. The fraud engine is given anything from 50 to 300 milliseconds to score the transaction, check device intelligence, check velocity counters, run the rule set and return an approve/decline. Anything less speedy and you get timeout cascades, lost transactions. That is why modern fraud engines run in memory with pre computed customer behavioral profiles, GPU accelerated money laundering models and rule sets that are compiled to optimized execution paths.
On the other hand, most AML detection scenarios run close to real time or batch. For example, detecting a structure only makes sense once you have seen the second, third and fourth deposit that together suggest an effort to avoid reporting thresholds. A $9,500 deposit is just a deposit. That’s a pattern of three across three branches in two days. The detection logic needs the transactions to land, settle and be enriched with counterparty data for the pattern to show up, and that does not happen in milliseconds.
There are cases in the middle ground. Because the wire goes or it doesn't, sanctions screening at the wire level has to be in real time. Customer onboarding watchlist screening is more batch. As internal funds transfers in instant payment rails (FedNow, SEPA Instant, FAST, UPI) are pushing AML related checks more and more into the real time path. This is one reason the historical separation of fraud and AML is breaking down at the edges. The institution loses the comfortable window where AML pattern detection could be run before the funds leave, when a payment settles in five seconds and is irrevocable.
The architectural implications are real. Fraud platforms are built around throughput and low latency, with tight SLAs and limited data context per call. AML platforms are built to be complete, have historical depth and support analyst facing investigation workflows. Trying to run one on the architecture of the other usually results in something that does neither job well.
The Overlap Zone: Where Fraud and AML Converge
Most transactions fall neatly into either one or the other discipline. Fraud is an e-commerce purchase made with a card number. Buying real estate with cash through a shell company is AML. The boundary is clean.
The boundary is collapsing for an increasing number of typologies where the same event is both a fraud and a laundering case, and where, if the systems are working, you'll get alerts from both.
Money mules: A mule account is both a fraud problem (someone has been recruited to receive and forward stolen funds, often through a romance or job scam) and an AML problem (the mule account is part of a laundering chain moving proceeds of upstream crime). The fraud systems see the odd incoming activity and fast outbound dispersal. AML systems identify the structure pattern of a small balance account suddenly becoming a transit node. They’re both right. Both need to be connected.
Automated clearing house (ACH) and authorized push payment frauds: Happens when a victim is socially engineered into authorizing a payment to a fraudulent counterparty. The transaction is technically authorized, so it bypasses many traditional fraud rules. The downstream beneficiary account is almost always a mule account. The money goes fast. Even when fraud monitoring missed the initial push, AML monitoring picks up the dispersal pattern. The combined signal enables the institution to recover funds faster.
Trade based money laundering: Over or under invoicing of legitimate trade, phantom shipments and other trade finance distortions look like routine commercial activity to a fraud engine, but match AML typologies that examine invoice anomalies, counterparty risk and high risk geography exposure.
Synthetic identity fraud: A synthetic identity is used to open accounts (fraud), create a credit history (fraud) and then to receive and distribute illicit funds (AML). The same identity is in both queues at different points of its lifecycle, and the institutions that catch synthetic IDs at onboarding rarely correlate them to the AML alerts they generate two years later.
Crypto on ramp/off ramp abuse: Stolen funds in crypto and back is fraud up front and AML in the back. The two events may be days apart, on separate rails, and appear unrelated to systems that do not share data.
Check & Treasury fraud: “The proceeds of check fraud, business email compromise and corporate treasury manipulation have to be laundered on. The fraud event is detected by fraud rules, the downstream layering, first hop mule, second hop consolidation, third hop crypto or wire out, is detected (or missed) by AML monitoring. Recent enforcement actions against U.S. and EU institutions have revealed gaps exactly in this handoff.
Financial abuse of the elderly: A growing category that is certainly in the overlap zone. The first fraud (romance scam, tech support scam, government impersonation scam) looks like unexpected but authorized transfers from a senior customer’s account. When viewed over weeks, the same transfers align with AML typologies of victim exploitation and pass through abuse. U.S. is the reason for the specific Elder Financial Exploitation indicator within SAR filings is because the two angles must be reported together.
It’s this overlap where institutions running fraud and AML in silos lose the most money , and where regulators have been most active in raising expectations.
Rule Logic Differences
The rules that drive monitoring of fraud and AML are superficially similar. They are both “if then” statements over transaction attributes, but they are built around fundamentally different signal types.
Fraud rules work on immediate, micro level signals of the customer's session and device:
- Velocity: Transactions/minute/hour/day; unexpected spikes in spending relative to baseline.
- Geo mismatch: The customer's home geography does not match the transaction location, recent travel pattern, or the IP geolocation of the session.
- Device anomaly: New device fingerprint, jailbroken device, emulator detection, browser/OS signature mismatch.
- Behavioral biometrics: Typing cadence, swipe pressure, navigation patterns that deviate from the established profile.
- Channel anomaly: Customer who has never used the web suddenly makes a large transaction at 3 a.m.
- Counterparty novelty: Payment to a beneficiary that the customer has never paid before, especially in combination with other anomalies.
AML rules depend on structural, macro level signals associated with flows over time:
- Structuring: Multiple sub threshold transactions to avoid reporting requirements ($10,000 CTR threshold in the U.S., €10,000 thresholds in many EU jurisdictions, etc.).
- Layering patterns: Rapid movement of money through a series of accounts or institutions to conceal its origin.
- High risk jurisdiction flows: Transactions to or from jurisdictions identified by FATF as high risk or subject to enhanced due diligence regimes.
- Threshold avoidance: Transaction amounts clustering just below reporting or review thresholds, repeated over time.
- Pass through activity: Accounts that receive and disburse similar amounts in short windows of time without an apparent economic purpose.
- Unusual counterparty webs: Clusters of seemingly unrelated parties sharing addresses, beneficial owners or timing of transactions.
- Profile mismatch: Activity volumes or geographies which do not match the customer’s stated business or income profile.
A specific example shows the divide. Say a customer makes four ATM deposits of $2,400 each at three different branches over three days. The fraud engine sees each deposit as a standalone: Known device, known card, no velocity breach in any one session, in the customer’s normal range. The deposits are cleared. The AML engine is running a structuring scenario on the customer’s transaction history, and it sees those same four events differently: Four sub threshold cash deposits, multiple locations, three day window, no economic narrative to explain the cash. The red flag was raised. An investigator opens a case, reviews KYC and may submit a SAR. The same four trades. Two lenses, not the same. Two different (correct) answers.
Fraud asks “Is this transaction wrong for this customer at this time?” AML asks “Does this pattern, weeks and counterparties, look like proceeds of illicit activity moving through?” Different questions, different replies with the exact same data.
Alert Handling and Escalation Paths
After the detection engine gives a fraud alert, its lifecycle is vastly different than that of an AML alert.
A fraud alert takes immediate action: Blocking the authorization, holding the wire, locking the card, freezing the account, or increasing authentication. They contact the customer, often within minutes, by SMS, app push or call: Was this you? If the answer is yes, the transaction is released. If the answer is a no, fraud operations perform forensic steps, trace the beneficiary, file recovery requests with the receiving bank’s first hop response team, refund the customer per the applicable scheme rules. The alert closes in hours, or days. The case is transactional in the operative sense.
There is also a hard economic side. U.S. Regulation E generally mandates consumer reimbursement for unauthorized electronic transfers within strict timeframes. Similar protections exist in the EU under PSD2, but with carveouts for “gross negligence.” The UK’s regime for APP fraud reimbursement, requires receiving and sending payment service providers to share reimbursement for authorized push payment fraud over a defined threshold. So the fraud team is protecting the customer from loss and managing the institution’s own direct loss exposure on each alert.
An AML alert then starts a different workflow. Rarely will the transaction be blocked at the alert stage, because the activity underlying it is usually lawful on its face. The alert is assigned to a financial crime investigator who pulls the customer’s full transactional history, KYC file, counterparty data, adverse media, and any open prior cases. The investigation could take days or weeks. At the end, the analyst writes a disposition. False positive. No further action. File a SAR/STR. The institution may continue to monitor the customer with the SAR filing as context, de-risk the relationship, or freeze the account if a SAR is filed under certain legal authority. In many jurisdictions the regulator is a downstream reader of that filing, not a real time observer of the alert.
These timelines correspond to the escalation paths. Fraud alerts are fast tracked to customer service, payment operations, scheme dispute teams and sometimes law enforcement. AML alerts are deliberately fed to financial crime investigation units, Bank Secrecy Act officers, MLROs, compliance committees and the regulator. Both are right for their purpose. If you mix queues without knowing the difference, you create compliance gaps on both sides.
Why Integrating Both Matters: The Unified Risk Score
The best argument for treating fraud and AML as part of one system is not theoretical. It’s empirical. Criminals work end to end, and signals from each end improve the other end in a meaningful way.
The practical mechanism is a single risk score. Rather than asking each system a narrow question in isolation, the institution calculates an ever evolving customer risk score that leverages all the signals available to it: KYC and onboarding data, ongoing screening hits, behavioral insights, device intelligence, geographic exposure, beneficial ownership graphs, negative media coverage, sanctions and PEP matches, previous fraud history, previous SAR submissions (where legally permissible), transaction velocity, counterparty risk, and flows from high risk jurisdictions.
The score is fluid. This is not a number that is set at onboarding and refreshed annually. It moves with the behavior of the buyer. A long dormant account that suddenly initiates a high value wire to a new jurisdiction recalibrates its risk score in real time and that recalibration ripples into the fraud engine and into the AML monitoring system. The next transaction from the same customer comes with the updated risk context attached.
And this is where a big and varied data basis counts. The broader the input sources the platform can access global sanctions and watchlists, PEP databases, adverse media coverage in multiple languages, transaction monitoring history, customer behavioral profiles, beneficial ownership chains, device and session signals. Hence the more accurate the score and the lower the false positive rate. Sanction Scanner’s Fusion platform calculates a continuously updated customer risk score consumed by all downstream modules based on Sanction Scanner’s data foundation spanning hundreds of sanctions and watchlist sources, adverse media in multiple languages, and behavioral inputs from screening and monitoring activity.
What happens differently in practice? Let’s think about a borderline case. Say a mid-volume corporate customer wires $48,000 to a counterparty in a higher risk jurisdiction. In a siloed environment, the fraud engine sees a transaction within the customer’s normal range and passes it. The AML engine sees one cross border wire and waits to see if a pattern emerges. Nothing shoots. The counterparty’s adverse media hit came up two weeks ago in a unified environment; a recent KYB refresh showed a change in ownership; and there’s been a small upward drift in cross border activity over the past 60 days, all of which are already accounted for in the customer’s risk score. The aggregate score is high. The wire still clears, but it routes to a step up review queue, the AML investigator gets the full context up front, and the institution sees the risk before, not after, a SAR worthy pattern completes.
The downstream effect on false positives is also large. A single transaction that triggers a fraud rule might be ambiguous, but the same transaction with an aggregated risk score that indicates low underlying customer risk, no negative media, clean KYC and consistent historical behavior can be auto resolved with confidence. Conversely, a transaction may pass individual rule thresholds but still be escalated because of a high overall risk profile.
The difference between running two systems versus running one system with two views.
Practical Implementation: Building a Combined Architecture
Building a combined fraud and AML architecture is less about technology choice and more about operating discipline. Most of the work is done by a few principles.
Data shared, views different. Both systems need to refer to the same enriched transaction stream, same customer master, same counterparty data, same KYC and screening results, same risk score. On top you can have your own rules and models . But the truth should be one truth , not two approximate and reconciled truths .
Deduplication and correlation of alerts. If fraud and AML fire on the same customer or transaction, the system should recognize the connection and not create two work items for two teams that aren’t connected. The operational unit of interest is an individual case view that exposes both perspectives, with the fraud signal, the AML signal and the combined risk score visible to whomever opens the case.
Analyst workflows that share context. Investigators should be able to immediately see what the other discipline already knows about a customer. A fraud analyst who knows there is an open AML investigation on the same account can better make a decision about whether to release a held payment. An AML investigator who understands a recent fraud event has more background for the SAR narrative.
Governance that reflects the integration. Fraud and AML often report to different executives. A Chief Risk Officer or Chief Fraud Officer on one side, and a Money Laundering Reporting Officer or Chief Compliance Officer on the other. A combined architecture isn’t going to work unless there’s a forum where both sides meet and agree on thresholds, review false positive rates together, and coordinate on the overlap zone typologies. This is governance, not technology and it is often where integration efforts go to quietly die.
You do not need a monolithic application to implement. It requires shared data, correlated alerts, a workflow layer that allows the two disciplines to see what the other is doing, and the organizational commitment to act on what they find. Successful institutions in this area report material reductions in false positives, faster investigations and better quality SARs without compromising real time fraud prevention.
How Sanction Scanner Combines Both
The Sanction Scanner's AI-powered FUSION platform is designed on the unified risk score model described above. Our core modules are:
- Fusion: The unified compliance & fraud platform that brings together all module outputs into one risk view, calculates the dynamic customer risk score and serves it across all downstream checks.
- Fraud Detection: Transaction and session real time scoring, behavioral analytics, device and velocity rules, and anomaly detection powered by ML at the speed of payment authorization.
- Transaction Monitoring: AML pattern detection over time and across counterparties, including structuring, layering, pass through and high risk geography typologies, with configurable scenarios and case management.
- Transaction Screening: Real time screening of wires and other payments against sanctions, PEP and adverse media lists, with hit rate optimization and audit ready logs.
- AML Screening (Name Screening): On boarding and ongoing screening of customers and counterparties against global sanctions, watchlists and PEP databases.
- Adverse Media Screening: Multilingual adverse media coverage used at onboarding and ongoing thereafter and flowing directly into the risk score.
- Customer Risk Assessment: Live risk scoring at customer level blending KYC data, screening results, behavioral signals and transaction context.
- Know Your Business (KYB): Beneficial ownership resolution, corporate structure mapping and entity level due diligence for non individual customers.
- OngoingMonitoring: Ongoing re-screening of customer base and counterparties as lists, news and behavioural patterns change.
The point of the architecture is not that any one module is unique. They are designed to feed one another , fraud signals increase the AML risk score, AML alerts inform fraud rule thresholds, adverse media coverage tightens screening on related counterparties , so that the institution operates a single risk surface rather than a constellation of disconnected tools. Fraud and compliance teams don’t reconcile two views of the same customer, they work from one.
