Crypto fraud can hit a startup at every transfer point - and in 2024, about 5.14% of stablecoin volume, or roughly $649 billion, touched high-risk addresses. If I were setting up fraud checks for a startup, I’d keep it simple: pull on-chain, customer, device, and sanctions data into one pipeline; score each transaction with rules plus AI; and send gray-area cases to a person for review.
Here’s the short version of what matters:
- Use three layers together: hard-stop rules, AI risk scoring, and human review
- Build one pipeline: on-chain data, KYC data, device signals, and OFAC/watchlist data in one place
- Normalize data first: UTC timestamps, token decimals, and USD values based on transaction time
- Group wallets into entities: exchanges, mixers, bridges, scam clusters, and sanctioned actors
- Score in real time: map alerts to allow, verify, hold, or block
- Keep evidence with every alert: transaction hash, wallet labels, risk tier, feature values, IP, and device data
- Start with simple models: logistic regression or random forest before moving to XGBoost, LightGBM, or graph-based scoring
- Measure the right metrics: focus on precision, recall, and PR-AUC, not plain accuracy
- Tie scores to U.S. compliance work: OFAC, AML/KYC, SAR support, case files, and audit logs
- Track the money impact: restricted cash, fraud loss, recoveries, reserves, backlog, and model drift
A few points stand out fast. Bridge protocols received $743.8 million from illicit addresses in 2023, up from $312.2 million in 2022. And for startups with small finance and compliance teams, that means manual review alone won’t scale.
I’d sum up the article this way: AI helps most when it sits inside a clean process. Rules catch direct sanctions hits. Models spot odd behavior, wallet links, and fund-flow patterns. People make the final call when the case is not clear.
The rest of the article breaks down how to build that process, connect it to U.S. compliance work, tune false positives over time, and show fraud risk in your books and board reporting.
AI in Financial Crime: How Banks Detect Fraud in 2026 (Full Breakdown)
sbb-itb-17e8ec9
Build a Data and Detection Architecture That Works
Once your rules set the hard stops, the data pipeline turns those rules into live decisions. A simple way to think about the detection stack is in four layers: ingest, enrich, score, and act. Each layer hands data to the next. And the whole setup works a lot better when the input data is clean and consistent from day one.
Pull On-Chain, Customer, and Sanctions Data into One Pipeline
Your pipeline needs four core inputs:
- On-chain transaction data: hash, from/to addresses, token type, amount, token decimals, block height, and gas fees
- Customer and KYC data: verified identity, addresses, risk rating, and account status
- Device and session data: IP address, device fingerprint, geolocation, login time, and failed login count
- Sanctions and adverse lists: OFAC SDN lists, sectoral sanctions, crypto watchlists, and scam intelligence feeds from blockchain analytics providers
Before you score anything, normalize every field. Store timestamps in UTC as ISO 8601, then show them to analysts in U.S. date and time format. Normalize token amounts by decimals, then convert them to USD using the transaction timestamp. That cleanup step cuts down false matches and keeps review output consistent.
Once those inputs are in shape, the next move is to convert wallets into entities before you score behavior.
Turn Addresses into Entities and Behavior Signals
Raw wallet addresses, on their own, don't tell you much. The useful move is to cluster them into entities - exchanges, mixers, bridges, sanctioned actors, and scam-linked services - so your rules and models work with known counterparties instead of random pseudonymous strings. That's how raw blockchain activity becomes something a reviewer can use. Start with labeled address data from a blockchain analytics provider. Store each cluster's type, risk tier, and source, and keep an audit trail for every linkage.
Once addresses map to entities, you can build behavior features that point to risk. Transaction velocity looks at total USD sent or received over 1-hour, 24-hour, and 7-day windows, which helps catch sharp bursts tied to scam cash-outs. Counterparty diversity can flag accounts touching an unusual number of wallets. Round-number transfers - repeated transactions at exactly $100.00, $1,000.00, or $10,000.00 - may point to structuring. Bridge-use frequency and rapid cash-out behavior also belong in the core feature set.
Score Transactions in Real Time and Route Evidence to Case Review
After clustering and feature building, route each score to an automated action or an analyst queue. Map each score to allow, additional verification, hold, or hard block with an immediate alert. Cache sanctions and wallet-risk checks so live scoring stays under a few hundred milliseconds.
If a transaction triggers a hold, generate a structured evidence packet automatically. It should include:
- The transaction hash, date and time in U.S. format, token amount, and USD amount
- Wallet labels, cluster type, and risk tier
- Recent behavior feature values
- Sanctions and watchlist hits with match confidence
Investigators need this context to make fast, well-documented decisions. It also helps with SAR narratives and audit trails. FinCEN has specifically identified wallet addresses, transaction hashes, transaction history, IP addresses, and device identifiers as especially useful for law enforcement in crypto-related investigations. Use those fields in every evidence packet to speed investigations and preserve audit trails.
Pick AI Models That Match Crypto Fraud Patterns
AI Crypto Fraud Detection: Model Types Compared
Once your pipeline provides real-time financial insights to score transactions, the next step is picking the right model for the fraud pattern in front of you. There isn't one model that handles every type of crypto fraud well. The better move is to match the model to the pattern you want to catch and the quality of your labels. A good rule: start with the simplest model that can explain the alert.
Use Supervised Models for Transaction-Level Risk Scoring
Start with logistic regression or random forest as your baseline.
Logistic regression trains fast, is easy to ship, and gives you coefficients that are simple to explain to compliance teams, auditors, and your board. Random forest gives you non-linear decision boundaries while still offering feature importance that investigators can use during case review.
For your first live model, stick to fields you can collect with confidence from your payments and KYC stack, such as:
- transaction amount in USD
- asset type
- on-chain versus off-chain status
- timestamp
- hop distance from the source wallet
- network
- KYC risk rating
- jurisdiction
- account age
- historical chargeback rate
- prior sanctions hits
- device fingerprint risk score
- velocity metrics
- number of new counterparties in the last 24 hours
As labeled transactions build up, move to tree-based models like XGBoost or LightGBM. These models handle non-linear relationships well and often improve fraud recall compared with logistic regression. The tradeoff is lower explainability, so they fit best when you keep clear feature explanations and solid review steps around them.
Add Graph-Based Models for Wallet Relationships and Fund Flows
When wallet connections matter more than any single transaction, add graph features to the score. Graph models turn clustered wallets and transfers into a network for risk scoring. That makes it easier to spot fraud structures that stretch across many addresses or even multiple chains.
These models are especially useful for finding peel chains, bridge hops, and indirect sanctions exposure. Instead of looking only for direct contact with a risky address, they estimate how close a wallet is to a risky cluster.
A practical place to start is a hybrid setup. Run graph scoring in batch every hour to create enrichment features like minimum hop distance to a sanctioned address and cluster risk score. Then pass those features into your real-time supervised model. This keeps latency and infrastructure cost under control while still adding network-level risk signals.
Compare Model Types by Data Needs, Strengths, and Limits
Use the table below to match model choice to data volume, latency, and explainability.
| Model Type | Data Required | Best Use Case | Explainability | Latency | Strengths | Limitations |
|---|---|---|---|---|---|---|
| Supervised ML (logistic regression, random forest, XGBoost, LightGBM) | Labeled transactions and tabular features | Real-time transaction-level risk scoring | High to medium | Milliseconds to seconds | Strong on known patterns; fast to deploy; auditable | Needs labeled data; weaker on novel typologies |
| Graph Models | On-chain transaction graph, entity labels, sanctions data | Wallet relationships, fund flows, bridge hops, peel chains | Medium to low | Real time or batch | Captures indirect exposure and complex laundering paths | Computationally heavy; harder to explain |
| Anomaly Detection (Isolation Forest, autoencoders) | Large volumes of unlabeled transactional data | Surfacing novel or rare patterns | Medium | Real time or near real time | Detects unknown risks without labels | Higher false positives; needs strong human review |
For evaluation, do not use accuracy as your main metric. Fraud datasets are highly imbalanced, so accuracy can look great even when the model misses most bad activity. Focus on precision, recall, and PR-AUC for the fraud class.
Think of it this way: precision shows how much investigator time is getting burned on false positives. Recall shows how much fraud you're actually catching.
Connect Blockchain Intelligence with US Compliance Controls
After you score risk, add blockchain intelligence before you block, review, or file. Your internal transaction data only shows part of what’s going on. A transfer that looks normal in your ledger can, with blockchain analytics, turn out to be one or two hops away from an OFAC-listed address or moving funds through a mixer like Tornado Cash. That outside context turns raw transaction data into a usable decision signal.
Use Blockchain Analytics to Trace Exposure and Label Counterparties
This layer helps turn model scores into compliance actions by spotting sanctions exposure, mixers, and counterparties. Blockchain analytics can add entity labels, risk scores, and exposure flags before scoring - for example, links to an OFAC-listed address within three hops. Store those fields in your feature store for real-time scoring.
These labels close blind spots. An internal-only model may treat a $50,000 outbound transfer to an unknown wallet the same way every time, no matter where that wallet has been. With entity attribution, the model can tell the difference between a transfer to a reputable, regulated exchange and one sent to a newly labeled scam cluster or mixer, even when the amount and timing are identical.
Attribution also helps cut false positives. Payroll flows to large exchanges or known payment processors can be whitelisted with full auditability, so investigators don’t waste time on clean transactions.
Flag many-to-many transfers, equal outputs, and rapid multi-hop transfers through known services as high-risk routing behavior. For sanctions exposure, block direct hits right away and send indirect exposure - wallets within one or two hops of a sanctioned entity - to manual review instead of auto-blocking. OFAC guidance stresses the need to analyze indirect exposure, not only exact address matches.
Combine On-Chain Alerts with KYC, Jurisdiction, and Adverse Media Data
Once on-chain risk is labeled, combine it with customer context to decide whether to allow, review, or block. A wallet flagged for mixer usage can mean very different things depending on who’s behind it. A verified U.S. resident with a clean history is not the same as an unverified account from a high-risk jurisdiction with recent adverse media hits.
Build one risk profile for each customer that merges:
- On-chain analytics
- KYC records
- Jurisdiction risk ratings
- Sanctions screening against OFAC and other watchlists
- Adverse media signals
Your compliance policy should spell out which signal combinations lead to which outcomes. A practical framework is below.
| Signal Combination | Outcome |
|---|---|
| Direct OFAC match or transaction through a known sanctioned mixer or service provider | Immediate block + exception log |
| On-chain risk score ≥ 90 + sanctions tag | Immediate block |
| Score 70–89 + high-risk jurisdiction or adverse media | Enhanced due diligence |
| Mixer exposure + unverified identity | Enhanced due diligence |
| Low score + reputable exchange + clean KYC | Allow with standard logging |
Re-screen existing customer wallets whenever new OFAC designations are released or your analytics vendor publishes updated high-risk entity labels. Log every change in risk classification.
Connect Alerts to Investigations, SAR Support, and Audit Trails
Each decision outcome should kick off a standard case path and audit record. Auto-create a case record with transaction IDs, wallet addresses, customer IDs, risk scores, and trigger labels. Then route it through triage, evidence collection, analyst review, and BSA/AML escalation when needed. If the case leads to a Suspicious Activity Report, the record should already hold the structured facts needed for SAR prep.
For audit trails, timestamp every sanctions finding and risk score at the moment of the decision. Retain alerts, investigation notes, model version IDs, and reviewer decisions for at least five years, in line with U.S. BSA/AML record-keeping expectations. Store these records in immutable logs so regulators, banking partners, or investors can trace each decision back to the exact data and model setup that produced it.
Run, Tune, and Connect Fraud Detection to Financial Reporting
Build Feedback Loops That Cut False Positives Each Quarter
Every alert should feed into next quarter’s tuning. But that only works if the outcome labels are clean.
Tag each alert with a clear reason code, such as confirmed fraud, customer error, technical anomaly, or benign. Use standard investigator labels too, including chargeback fraud, promotion abuse, sanctions match, and new scam pattern.
Then track precision and recall by fraud type each quarter. Start with the weakest segment first. If one area is creating too much noise, fix that before moving on.
Set clear quarterly targets. For example, cut false positives by 15% while keeping fraud losses below 0.20% of monthly volume. For low-risk segments that create a lot of user friction, move thresholds up. For mixers and high-risk jurisdictions, keep thresholds tighter. Make ONE threshold change at a time, then check the result after two to four weeks. That gives you a clean read on what changed and what didn’t. Use those quarterly results to tighten controls before the next retraining cycle.
Protect Financial and Customer Data Across the AI Workflow
As models learn, the data behind them needs tight control.
Use RBAC, MFA, TLS, AES-256, and immutable audit logs. Limit raw PII access to a small, named group. Data scientists should work only from de-identified datasets.
Your audit logs need to show:
- Every access to sensitive records
- Every model or rules change
- Every manual override, with timestamps, user identity, and reason codes
Keep those logs for at least five to seven years, in line with U.S. BSA/AML and financial record-keeping expectations.
Reflect Fraud Risk in Your Books, Runway, and Board Reports
When fraud is found, finance has to show the effect in cash, reserves, and reporting.
Frozen balances should appear as restricted cash or liabilities so runway reflects cash you can actually use. Confirmed losses should hit the income statement as a dedicated fraud loss line item in the period when they happen. Recoveries - like chargebacks won or clawed-back funds - should be booked as offsets to that same account so the trend stays visible over time.
Fraud reserves should be booked as a provision or accrued liability, then updated as volume and loss rates shift. If that doesn’t show up in the books, burn is being measured off an incomplete picture.
For the board, keep the view short and direct. Focus on losses prevented, losses realized, recoveries, reserve balance, alert backlog, and drift. Show quarter-over-quarter movement, not just point-in-time numbers. Add a plain summary of risk scope, detection layers, and upcoming initiatives so investors can judge operating risk alongside growth metrics. Keep the dashboard short enough that finance and the board can act on it fast.
FAQs
How much training data do I need to start?
Not necessarily much. If you want to spot known fraud patterns with supervised models, you do need past labeled fraud data.
But you can still get started with unsupervised models.
These models learn what normal activity looks like from your current financial data. That can include transaction amounts, timing, locations, and records from banking, payroll, the general ledger, and expenses. From there, they flag unusual behavior even if you don’t have past fraud examples on hand.
When should a transaction be held instead of blocked?
Hold a transaction for manual review when its risk score goes past your threshold, but the risk isn’t clear yet, or when you need more checks to confirm the payment is legitimate.
This gives your team time to look into suspicious activity without turning away a payment that may be valid. It can help cut down on false positives while keeping funds on hold until the risk has been checked.
How often should fraud models and sanctions data be updated?
Fraud models and sanctions data need constant monitoring and frequent updates to support compliance and solid fraud prevention. Rules change all the time, so automated systems can track rule updates and risk exposure 24/7 without missing a beat.
It also helps to check model performance on a regular basis for drift or bias, compare results against established standards, and set up automated alerts for major shifts in customer risk profiles or data integrity issues.
