---
title: "Transaction monitoring red flags for stablecoin payments: 12 rules to automate"
seoTitle: "12 transaction monitoring red flags for stablecoin payments"
description: "The 12 red flags automated transaction monitoring should catch in stablecoin and cross-border payments, with rule logic, actions, and the data each needs."
date: "2026-09-30"
updated: "2026-09-30"
category: "compliance"
author: "BlindPay Team"
howto:
  name: "How an automated transaction monitoring alert becomes a decision"
  steps:
    - name: "Score"
      text: "Run every rule, baseline comparison, and wallet check against the transaction before it settles, and combine the results into one risk score with the rules that fired attached."
    - name: "Pass"
      text: "Release transactions that score below the review band. Keep the score and the rule results, even for clean payments, so the decision can be reconstructed later."
    - name: "Hold"
      text: "Pause transactions that score into the review band. Funds stay where they are and the customer sees a pending state, not an error."
    - name: "Block"
      text: "Stop transactions that hit a hard rule, such as a confirmed sanctions match or a prohibited country. A block needs no analyst to take effect."
    - name: "Review"
      text: "Send held transactions and blocked edge cases to an analyst, who gathers evidence, asks the customer for information if needed, and decides to release, reject, or escalate to a suspicious activity report."
    - name: "Log"
      text: "Record the score, the rules that fired, the evidence, the analyst, the decision, and the timestamps for every case, so an examiner can follow it from alert to closure."
faq:
  - q: "What is a red flag in transaction monitoring?"
    a: "A red flag is a pattern that suggests a payment may be linked to money laundering, sanctions evasion, or fraud, such as transfers split just under a threshold or funds that leave minutes after they arrive. A red flag is not proof. In an automated system, each red flag becomes a rule that raises an alert, and an analyst decides what it means."
  - q: "How is structuring detected in stablecoin payments?"
    a: "With a rule that counts transfers just under a threshold within a time window, per customer and across linked customers. The classic US threshold is the USD 10,000 currency transaction report, which applies to cash. In stablecoin and wire flows, the same splitting shows up under the USD 3,000 US travel rule threshold and under a provider's own per-transfer limits."
  - q: "Does a transaction near USD 10,000 require a suspicious activity report?"
    a: "Not on its own. FinCEN's October 2025 SAR FAQs say that transactions at or near the USD 10,000 threshold are not enough by themselves to require a SAR. A filing is required when the institution knows, suspects, or has reason to suspect the transactions were designed to evade reporting. The rule raises the alert, and the analyst makes that call."
  - q: "How many rules should a transaction monitoring system start with?"
    a: "Enough to cover every risk in your own risk assessment, and no more than your team can explain. There is no regulatory rule count. The 12 red flags in this guide are a reasonable starting library for stablecoin and cross-border flows. Each rule needs a written reason, a threshold set from your data, and a test case that proves it fires."
  - q: "What is the difference between holding and blocking a transaction?"
    a: "A hold pauses a transaction until an analyst reviews it, and most held payments are released once the evidence checks out. A block stops a transaction outright because it hit a hard rule, such as a confirmed sanctions match or a prohibited country. Holds are for doubt. Blocks are for cases where the answer is already known."
  - q: "Should transaction monitoring thresholds be the same for every customer?"
    a: "No. A single threshold floods analysts with alerts on large, legitimate customers and misses unusual activity from small ones. Segment customers by type, risk rating, and expected volume, then compare each customer with its own history and with a peer group of similar customers. Fixed thresholds still make sense for hard rules like sanctions hits."
---

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**

- A red flag only works in automation when it's written as a rule: a condition, a threshold, an action, and the data it needs.
- Fixed rules, behavioral baselines, and risk scoring do different jobs. A working system uses all three.
- Stablecoin transfers are final once confirmed, so the rules have to run before settlement, not on yesterday's file.
- Structuring rules raise alerts, not reports. FinCEN says amounts near a threshold alone don't require a suspicious activity report.
- Every rule needs a documented reason and a test case. Copied vendor defaults fail both.

## What is automated transaction monitoring?

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](/resources/more/what-is-automated-risk-monitoring-fintech), 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](/resources/more/real-time-transaction-monitoring-stablecoin-payments).

## How do rules, behavioral baselines, and risk scoring differ?

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.

## What are the 12 red flags an automated system should flag?

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](https://www.law.cornell.edu/cfr/text/31/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](/resources/more/travel-rule-stablecoin-off-ramps), 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](https://www.law.cornell.edu/uscode/text/31/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](https://ofac.treasury.gov/faqs/562) 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.

## Why do stablecoin transfers need pre-settlement checks?

Because a confirmed on-chain transfer is final. There is no recall and no chargeback, as covered in [are stablecoin payments reversible](/resources/more/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.

## What happens from alert to decision?

Every transaction gets scored, and the score decides whether it passes, waits for a person, or stops. The flow below is the standard shape.

1. **Score.** Run every rule, baseline comparison, and wallet check before settlement. Combine them into one score, with the rules that fired attached.
2. **Pass.** Below the review band, release the payment. Keep the score anyway.
3. **Hold.** Inside the review band, pause the payment. The customer sees a pending state.
4. **Block.** On a hard rule, such as a confirmed sanctions match or a prohibited country, stop it. No analyst is needed for the block to take effect.
5. **Review.** An analyst works the held and edge cases: checks the evidence, asks the customer for information, and decides to release, reject, or escalate.
6. **Log.** Store the score, the rules, the evidence, the analyst, the decision, and the timestamps, for every case.

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.

## How does a structuring rule work on a real pattern?

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).

- Total: 9 × USD 9,800 = USD 88,200, more than twice the declared monthly volume, in 48 hours.
- Rule 1 fires on the third transfer: three amounts at 98 percent of the internal limit within 48 hours.
- Rule 2 fires: weekly volume is far above the customer's baseline.
- Rule 6 fires: volume contradicts the declared profile.
- The score lands in the review band. Transfer three and everything after it are held. Transfers one and two have already settled.

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](https://www.fincen.gov/system/files/2025-10/SAR-FAQs-October-2025.pdf) 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](https://www.law.cornell.edu/cfr/text/31/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.

## What do FATF and FinCEN require from a monitoring program?

They require that suspicious activity gets detected and reported; they don't prescribe a rule list. [FATF Recommendation 20](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html) 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.

## What are the common mistakes when building a rule library?

Most weak programs fail in the same five or six places.

- **Copying vendor default rules.** Defaults are a starting point. Shipping them unchanged means the rules reflect someone else's customers, and you can't explain why a threshold is what it is.
- **One threshold for all customers.** A USD 50,000 weekly trigger is noise for a marketplace and blind for a freelancer. Segment first.
- **No peer groups.** Without them, new customers have no baseline, and the system can't tell unusual from normal for the first 90 days.
- **No documented rationale per rule.** Every rule needs a sentence on what risk it covers, why the threshold sits where it does, and when it was last reviewed.
- **No scenario testing.** Build test cases, like the nine-transfer pattern above, and prove each rule fires on them before and after every change.
- **Rules that run after settlement.** For stablecoin flows, a post-settlement rule is a report generator, not a control.

## How does BlindPay run these checks inside the payment flow?

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](/docs/kb/cut-off-times) 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](/docs/kb/on-hold-transactions), and each status is explained in [stablecoin payout statuses explained](/resources/more/stablecoin-payout-statuses-explained).

## What to do next

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](/resources/more/how-to-choose-automated-risk-monitoring-vendor) covers what to ask.

## Sources and further reading

- [FATF Recommendations](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html), including Recommendation 20 on suspicious transaction reporting.
- [31 CFR 1022.320](https://www.law.cornell.edu/cfr/text/31/1022.320), suspicious activity reports by money services businesses.
- [FinCEN SAR FAQs, October 2025](https://www.fincen.gov/system/files/2025-10/SAR-FAQs-October-2025.pdf), on structuring and continuing activity.
- [31 USC 5324](https://www.law.cornell.edu/uscode/text/31/5324), structuring transactions to evade reporting requirements.
- [31 CFR 1010.311](https://www.law.cornell.edu/cfr/text/31/1010.311), currency transaction reports.
- [OFAC FAQ 562](https://ofac.treasury.gov/faqs/562), digital currency addresses on the SDN List.

*This article is general information, not legal advice.*