AI for Fraud and Financial Crime: Transaction Monitoring, KYC/AML, and Claims Fraud

Fraud and financial crime are the rare enterprise AI use cases where the business case writes itself and the constraint is everything else: latency budgets measured in milliseconds, filing deadlines measured in calendar days, and model-governance expectations measured in examiner patience. This piece maps the three workloads — transaction monitoring, KYC/AML, and claims fraud — and the build-versus-buy call each one actually presents.

Three workloads, one discipline

"Fraud AI" is a category label that hides three genuinely different engineering problems. Card and payment fraud is a real-time scoring problem: the decision window is the authorization itself, and the cost of a false positive is a declined legitimate customer. AML is a regulatory workload: the outputs are risk scores, alerts, and ultimately SAR filings with statutory deadlines, and the cadence is closer to monthly than to milliseconds. Claims fraud in insurance is a document problem first and a scoring problem second — nothing can be scored until the claim file has been extracted into structured data.

The common discipline underneath all three is model governance. Every one of these systems makes adverse decisions about real people, operates under some combination of banking, insurance, and consumer-protection law, and will eventually be examined. The frameworks for that are covered in depth in /guides/model-risk-management-guide — treat everything below as sitting inside that envelope, not as a substitute for it.

Transaction monitoring: the real-time workload

The modeling pattern for payment and card fraud has converged. Supervised classifiers — gradient-boosted trees remain the workhorse — learn from labeled historical fraud. Unsupervised anomaly detection catches what has no label yet: novel attack patterns that deviate from a customer's behavioral baseline. Graph models sit above both, scoring relationships between accounts, devices, merchants, and IP addresses to surface fraud rings and synthetic identities that look clean transaction-by-transaction. Sequence models add a fourth lens, flagging chains of individually benign transactions that are only suspicious in order.

The cloud reference architectures make the same pairing explicit. AWS's fraud-detection guidance deploys two Amazon SageMaker endpoints side by side — one assigning anomaly scores, one assigning classification scores — invoked by a Lambda function as transactions arrive, with an API gateway in front for signed real-time prediction requests.^[4] Microsoft's equivalent reference architecture on Fabric Real-Time Intelligence ingests event streams from mobile banking apps, ATMs, e-commerce sites, and call centers; normalizes and enriches them against customer profiles; computes a fraud risk score per transaction; and fires automated alerts to fraud teams when a score crosses threshold or matches a known signature.^[5]

Two operational details separate production systems from proofs of concept. First, feature freshness: velocity features — transaction counts per user and device over sliding windows, geographic dispersion, merchant-category consistency — carry much of the signal, and they decay in seconds, which is why the streaming layer and the feature store are architecturally load-bearing, not plumbing. Second, the feedback loop: fraud labels arrive weeks after the transaction, via chargebacks and investigations, so drift monitoring and a scheduled retraining cadence are part of the initial design, not an operations afterthought.

KYC and AML: the regulated workload

AI in KYC automates a legal obligation with fixed contours. Under 31 CFR 1020.220, a bank must run a written Customer Identification Program that collects, at minimum, name, date of birth, address, and an identification number before opening an account, and must apply risk-based verification procedures sufficient to form "a reasonable belief that it knows the true identity of each customer."^[6] The rule is technology-neutral: it fixes the outcome and leaves the method to you. That is exactly where document-verification AI earns its place — OCR and vision models extracting and validating identity documents, forgery and liveness detection, and entity resolution matching applicants against sanctions and watchlist data. The regulation defines done; the models define fast.

On the monitoring side, the SAR obligation shapes everything downstream of the model. A bank must report any transaction conducted or attempted through it that aggregates at least $5,000 and that it knows, suspects, or has reason to suspect involves illicit funds, evasion of Bank Secrecy Act requirements, or activity with no apparent lawful purpose. The filing deadline is 30 calendar days from initial detection, extendable by another 30 only when no suspect has been identified — and in no case beyond 60. Supporting documentation must be retained for five years, and the SAR itself is confidential.^[3]

The most instructive first-party product in this space is Google Cloud's Anti Money Laundering AI. It is an API that generates monthly AML risk scores for retail and commercial banking customers, trains exclusively on the bank's own core banking and SAR data — Google states it does not enrich customer datasets with Google data — and is positioned to replace or complement legacy transaction monitoring. Its documentation leads with model governance: the scores are designed to be explainable to analysts, risk managers, auditors, and regulators, and the product ships with guidance on collecting model and risk governance artifacts and evaluating model fairness.^[2] Note what that design admits: customer-level AML risk scoring is a monthly batch discipline, not a real-time one, and explainability is a product feature because examiners made it one.

Scope boundaries matter as much as capabilities. AML AI's supported products cover checking, savings, cards, mortgages, and loans on the retail side and cash accounts, loans, and lines of credit on the commercial side — explicitly excluding brokerage, trading, cryptocurrency, insurance, capital markets, trade finance, and foreign exchange.^[2] If your risk sits in the excluded categories, a specialized product's coverage map is the first evaluation criterion, before any accuracy conversation. And when identity or risk models gate account opening or credit, adverse-action and fair-lending obligations attach; those regimes, including Regulation B's notice requirements, are mapped in /guides/sectoral-ai-regulation-regtech rather than repeated here.

Claims fraud: the document-heavy workload

Insurance claims fraud inverts the transaction-fraud problem: the raw material is not a clean event stream but a heap of variably formatted documents — claims forms, policy schedules, medical records, invoices, repair estimates, often handwritten. The pipeline is therefore two-stage. Stage one is extraction: OCR, layout-aware models, and increasingly LLM-based document understanding turn the claim file into structured fields — parties, dates, policy numbers, diagnoses, amounts — validated against business rules before anything downstream sees them. Stage two is scoring: supervised models trained on adjudicated claims, anomaly detection for novel schemes, and graph analytics linking claimants, providers, body shops, and addresses to expose organized rings that no single-claim model can see.

The operational failure modes are also document-shaped. Extraction accuracy degrades on handwriting, poor scans, and unusual layouts, so production deployments route low-confidence extractions to human review rather than letting bad fields silently poison the fraud score. And the label problem is worse than in payments: confirmed claims fraud emerges from special-investigation-unit outcomes months later, so the feedback loop from investigations back into training data is the single highest-leverage process to build early. Explainability, again, is not optional — an adjuster who cannot see why a claim was flagged will either ignore the flag or, worse, treat it as a verdict, and insurance regulators increasingly ask which one happened.

The buy-side reality: products retire, platforms persist

Here is the fact that should reframe your vendor shortlist: the hyperscalers have been exiting turnkey fraud AI. Amazon Fraud Detector — AWS's fully managed, train-on-your-data fraud service — is no longer open to new customers as of November 7, 2025; AWS's own documentation points prospective users to SageMaker, AutoGluon, and AWS WAF instead.^[7] Azure's Anomaly Detector service stopped accepting new resources in September 2023 and is being retired on October 1, 2026, with Microsoft recommending migration to Microsoft Fabric or the open-source anomaly-detector project.^[8] The pattern is consistent: narrow managed AI services are being folded into general-purpose ML and analytics platforms.

The strategic read is not "avoid cloud fraud tooling." It is that the durable cloud offerings are platform-level — SageMaker, Fabric, Vertex-hosted pipelines — plus a small number of deeply regulated specialized products like AML AI, while the mid-tier of convenience services has proven mortal. Specialized fraud and financial-crime suites from long-standing vendors — FICO, SAS, NICE Actimize, Feedzai, Featurespace, and peers — remain the incumbency in bank fraud operations, and evaluating them is a matter for direct proof-of-concept testing rather than vendor-published accuracy claims, which this piece deliberately does not repeat. What the retirements change is diligence: for any fraud AI product, the exit path — model portability, feature-pipeline portability, and what a forced migration would cost mid-contract — is now a first-order selection criterion, not an appendix.

The deepfake front: fraud AI versus fraud-by-AI

The same generative techniques enterprises deploy for service automation are now attack tooling. The FTC moved on this in February 2024, proposing to extend its impersonation rule to individuals precisely because AI-driven voice cloning was scaling impersonation fraud.^[9]

For financial institutions this lands in two places. Contact-center authentication that leans on voice biometrics as a primary factor needs re-scoring as an attack surface, and callback verification procedures for payment instructions — the classic defense against executive-impersonation wire fraud — need to assume the voice on the line can be synthetic. The architecture and countermeasures for voice channels, including liveness and injection detection, are covered in /guides/enterprise-voice-ai-guide; the fraud-stack implication is that impersonation signals belong in the same feature space as transaction signals, because the scam that starts on a phone call ends as a payment your monitoring model will see.

Honest objections

The skeptical case deserves a fair hearing, because parts of it are right. First: rules engines are transparent, cheap, and examiner-legible, and every model you add brings validation, documentation, drift monitoring, and explainability obligations that rules never carried. That governance overhead is real and recurring — which is why the right posture is layering models onto rules where rules demonstrably fail, not a rip-and-replace that trades a maintenance burden you understand for one you do not.

Second: the false-positive economics are unforgiving. Every alert consumes investigator minutes, and every false decline burns customer goodwill in the moment of purchase. A model that catches marginally more fraud while doubling alert volume is a net loss, and vendor accuracy claims measured on curated datasets say nothing about your alert queue. The honest evaluation metric is precision at your fixed review capacity, measured on your data in a pilot — which is also why this article cites no vendor detection-rate percentages: the portable number does not exist.

Third: labels are scarce and late. Fraud base rates are tiny, chargebacks and SIU outcomes lag by weeks or months, and a model trained on yesterday's confirmed fraud is structurally blind to today's novel scheme. Anomaly detection mitigates but does not solve this — it trades missed-novel-fraud risk for noisy-alert risk. None of these objections argues for standing still while reported fraud losses climb double digits year over year;^[1] they argue for sequencing the investment behind the operational capacity to absorb it.

The read

For a CIO or platform lead, the decisions stack up like this. Build transaction-fraud scoring on your general-purpose ML platform — the data is proprietary, the feature pipelines are your competitive asset, and the reference architectures are mature; reserve specialized products for workloads where the vendor's regulatory artifacts are the point, as with AML risk scoring. Keep the rules layer and the human-review band permanently. Treat CIP and SAR obligations as fixed constraints that size your alert-handling capacity, not as downstream paperwork. Put every model — bought or built — through the same model-risk validation you would show an examiner. And underwrite vendor mortality: the last two years retired first-party fraud services from two hyperscalers, and your architecture should survive the next such notice without a crash program.