The 12 red flags automated transaction monitoring should catch in stablecoin and cross-border payments, with rule logic, actions, and the data each needs.
An automated transaction monitoring system should flag structuring, velocity spikes, rapid in-and-out movement, round amounts, high-risk corridors, activity that contradicts the customer's declared business, fan-in patterns, risky wallet addresses, dormant accounts waking up, changed customer data, bridge or mixer hops, and near-threshold payments across linked accounts. Each rule pairs a condition with an action: pass, hold, block, or review.
This article is general information, not legal advice. Thresholds below are illustrative, not recommendations.
Key takeaways
Automated transaction monitoring is software that checks every payment against a set of rules and models, and flags the ones that look like money laundering, sanctions evasion, or fraud. It replaces a person reading every transaction with a person reviewing only the flagged ones.
It's one of four parts of a risk monitoring program, next to KYC and KYB, sanctions screening, and alert handling. This guide is about the rule library itself: what to flag, how each rule works, and what happens next. The signals behind a stablecoin risk score, and why real-time beats batch, are covered in real-time transaction monitoring for stablecoin payments.
Rules check a fixed condition, baselines compare a customer with its own past and its peers, and risk scoring combines both into one number that drives the action. Most red flags below use more than one.
| Method | How it works | Good at | Weak at | Illustrative example |
|---|---|---|---|---|
| Rule-based alerts | A fixed condition fires when met | Hard limits, sanctions hits, known typologies | Too many alerts on large customers, easy to game once known | Any transfer to a wallet on the SDN List |
| Behavioral baselines (peer groups) | Compares activity with the customer's history and with similar customers | Catching change: spikes, new corridors, dormancy | Needs history; new customers have no baseline | 7-day volume at 3 times the customer's 90-day average |
| Risk scoring | Weights rule hits, baselines, and customer risk into one score | Ranking alerts, routing to pass, hold, or review | Hard to explain if weights aren't documented | Score above 70 holds the payment for review |
A peer group is a set of customers with similar type, size, and declared activity. A new marketplace seller gets compared with other new marketplace sellers until it has a history of its own.
These 12 cover the patterns that show up most often in stablecoin and cross-border payment flows. The thresholds are illustrative. Set yours from your own data and your risk assessment.
| # | Red flag | Rule logic (illustrative thresholds) | Typical action | Data needed |
|---|---|---|---|---|
| 1 | Structuring below a reporting threshold | 3 or more transfers between 90 and 99.9 percent of a threshold (USD 10,000 cash, USD 3,000 US travel rule, or an internal limit) within 48 hours | Review | Amounts, timestamps, customer ID |
| 2 | Velocity spike against baseline | 7-day volume above 3 times the customer's 90-day weekly average | Review | Transaction history, customer baseline |
| 3 | Rapid in-and-out movement | 80 percent or more of an incoming amount sent onward to a different party within 24 hours | Review | Payin and payout records, timestamps |
| 4 | Round amount patterns | 5 or more transfers in exact multiples of USD 1,000 in 30 days with no matching invoices | Review (low weight in score) | Amounts, declared activity |
| 5 | High-risk corridor | Origin or destination country on the internal high-risk list; prohibited countries stopped outright | Review or block | Customer country, bank country, IP and geolocation |
| 6 | Declared activity mismatch | Monthly volume above 2 times declared expected volume, or payments to industries outside the profile | Review | KYB profile, expected volume, counterparties |
| 7 | Many senders to one receiver | 10 or more distinct senders paying one beneficiary in 7 days | Review | Sender and beneficiary identifiers |
| 8 | Wallet linked to sanctions or illicit clusters | Address on the SDN List, or analytics exposure to sanctioned, mixer, or stolen-funds clusters above risk appetite | Block (direct hit) or hold | Wallet address, list data, analytics score |
| 9 | Activity after a dormant period | No activity for 180 days, then a transfer above the customer's historical maximum | Hold | Account history |
| 10 | Sudden change in verified data | New bank account, wallet, email, or phone within 72 hours before a large payout | Hold | Profile change log, timestamps |
| 11 | Bridge or mixer hops before deposit | Funds reach the deposit address through a mixer, or through 2 or more bridge hops within 24 hours | Hold or block | On-chain trace, analytics data |
| 12 | Near-threshold payments across linked accounts | Customers sharing an owner, address, device, or bank account each send just under a threshold on the same day | Review | Entity links: shared identifiers |
A few notes on the rows that trip teams up.
Row 1 needs care with the threshold. The currency transaction report (CTR) under 31 CFR 1010.311 covers transactions in currency of more than USD 10,000, which means cash. A stablecoin payout isn't cash. The same splitting behavior still matters, though: under the USD 3,000 US travel rule threshold, under a provider's per-transfer limit, or on the cash side of an on-ramp. Structuring to evade a reporting requirement is a crime under 31 USC 5324, whether or not the money is dirty.
Row 8 is the one rule with no judgment call on a direct hit. OFAC adds some wallet addresses to SDN List entries and says those listings are not likely to be exhaustive. So a clean list check isn't the end of it. Analytics exposure covers what the list misses.
Row 12 depends on entity resolution. Entity resolution means linking customers that share identifiers. Without it, a structuring ring split across five accounts looks like five clean customers.
Because a confirmed on-chain transfer is final. There is no recall and no chargeback, as covered in are stablecoin payments reversible, so a rule that fires after settlement can only produce a report.
That changes where the rules sit. In a wire program, monitoring can review yesterday's batch and still ask a bank to recall a payment. In a stablecoin program, the rule library has to run between the payment request and the transfer. That's why the holds in the table above exist at all: a hold is only possible if the check runs first.
Every transaction gets scored, and the score decides whether it passes, waits for a person, or stops. The flow below is the standard shape.
Step 6 is the one teams skip, and it's the one an examiner asks for first. A decision you can't reconstruct is a decision you can't defend.
The rule raises the question; the analyst answers it. Here's how one pattern moves through the flow.
Illustrative example: nine transfers of USD 9,800 in two days. A small import business, onboarded three months ago, declared expected monthly volume of USD 40,000. Over two days it requests nine stablecoin payouts of USD 9,800 each to three bank accounts in Mexico. Its provider caps single payouts at USD 10,000 (an illustrative internal limit).
The analyst asks the customer for invoices and the relationship with the three recipients. Two outcomes are possible.
If the customer shows three supplier invoices for USD 29,400 each, split because of the payout cap, the analyst clears the alert, writes down why, and the team considers a limit increase. The pattern was the limit, not the customer.
If the customer can't explain the split, or the recipients don't match the invoices, the case escalates. Here the line FinCEN draws matters. Its October 2025 SAR FAQs say amounts at or near a threshold alone don't require a suspicious activity report (SAR). A SAR is required when the institution knows, suspects, or has reason to suspect the transactions were designed to evade reporting, or are otherwise suspicious. Splitting with no business reason, after a request for invoices, is that kind of reason.
For a money services business, 31 CFR 1022.320 requires a SAR on suspicious transactions of at least USD 2,000, filed no later than 30 calendar days after initial detection, with the SAR and supporting documents kept for five years. The USD 88,200 here is well over the line.
They require that suspicious activity gets detected and reported; they don't prescribe a rule list. FATF Recommendation 20 requires financial institutions to report promptly to their financial intelligence unit when they suspect funds are the proceeds of crime or linked to terrorist financing. Countries implement that through their own laws.
In the US, the Bank Secrecy Act and FinCEN's rules carry it out. FinCEN's SAR FAQs say monitoring parameters should be commensurate with the institution's money laundering and terrorist financing risk, given its products, locations, and customers. That sentence is the reason a rule library has to be your own. A cross-border stablecoin business with Latin American payout corridors has different risk than a domestic payroll app, and its rules should show it.
Most weak programs fail in the same five or six places.
BlindPay runs KYC, KYB, sanctions screening, travel rule compliance, and transaction monitoring inside the API flow, before money moves. Customers are verified first: KYC Standard is automated and takes about 60 seconds for standard-risk individuals, while KYC Enhanced and KYB are reviewed manually in 3 hours to 1 business day.
On each payin or payout, monitoring can move a transaction to on_hold. The documented triggers include first-time withdrawals or unusual activity, amounts large relative to the customer's history, and sanctions or watchlist matches. Compliance reviews each held transaction for false positives and may send a request for information about the sender relationship, the purpose, and the expected outcome. An unanswered transaction request can lead to a refund to the sender after 24 hours, and a hold can take up to 30 days to resolve. The process is in on-hold transactions, and each status is explained in stablecoin payout statuses explained.
Take the 12-row table and mark each row: covered, partly covered, or missing. For every covered row, write down the threshold, why it's set there, and the test case that proves it fires. Start with rows 1, 8, and 12. They're the ones where a gap turns into a reportable failure fastest. If you're still choosing tools, how to choose an automated risk monitoring vendor covers what to ask.
This article is general information, not legal advice.
The evidence examiners expect from automated risk monitoring: a 10-item evidence table, good vs poor practice, SAR timelines, RFIs, and a 30-day plan.
Blockchain payments are legal for businesses in the US, EU, UK, Brazil, and Mexico, under different rules. What each country regulates, as of October 2026.
Stablecoin transfers settle final in minutes and cannot be reversed. That finality proves custody at every step, but it also opens a fraud gap on the fiat side of the payment.