Stablecoin transaction monitoring is the continuous checking of payments, wallet addresses and customer behavior against rules, so that activity that does not fit a customer's profile is held and reviewed by a person. It works when every rule has a threshold, a known source of false alerts and a reviewer who can close the alert in one step.
We covered the basics of the regulatory duty in stablecoin AML compliance for fintechs. Here the focus is detection rules and alert quality, on rails such as Pix (Brazil's instant payment system, run by the Central Bank), SPEI (Mexico's interbank transfer system, run by Banxico) and Bre-B (Colombia's instant payment system, launched in 2025).
Which rules does stablecoin transaction monitoring run?
Here are twelve rules a payments business can run. Each has a normal explanation that produces false alerts, and one check that usually settles the alert.
Twelve monitoring rules for stablecoin payments, the normal activity that trips each one, and the check that settles it. A working catalogue, informed by the FinCEN and OFAC material cited at the end of this post, not a list of the rules Lumx runs.
# | Rule | Fires when | Usual benign cause | Check before closing |
1 | Listed party or wallet | A sender, receiver or address matches a sanctions list | A common name with no second identifier | Compare country, birth date or registration number. An address must match exactly |
2 | Indirect exposure | Funds reached the address through a flagged service | An exchange wallet that pools many users | Read the share of funds and the hops, not the mere presence of exposure |
3 | Rescreen after a list update | A party cleared at onboarding now matches an updated list | The name collision of rule 1 | Re-run with every identifier |
4 | Velocity against baseline | Count or value over 24 hours or 30 days far above the customer's history | A payroll run or peak the customer declared | Compare with the declared volume, not with other customers |
5 | Amounts just under a threshold | Several amounts cluster below a limit | The limit itself: a provider cap or rail ceiling | Find the cap above the cluster. Proximity alone is not a basis for a report |
6 | Pass-through | Funds arrive and leave within minutes in near-equal amounts | A marketplace or payroll flow, where that is the product | Check the declared business model and holder relationship |
7 | Third-party payer | A named account receives funds from a payer whose name differs from the holder | A parent company or the customer's own treasury | Ask for the relationship. A parent is a third party |
8 | Destination change | A new destination is followed by a large payout | The customer changed banks | Confirm through a channel already on file |
9 | Profile mismatch | Actual flows differ from declared activity | The business grew into a second line | Update the expected activity and collect supporting documents |
10 | First-seen address | A large first transfer involves an address with no history | A new wallet the customer owns | Ask for proof of control of the address |
11 | Round amounts to a new counterparty | Repeated round-number payouts to someone new | Rent, retainers, fixed salaries | Check whether the invoice repeats the amount |
12 | Repeated failures or returns | Several rejected or returned payouts to one beneficiary | A typo in the account details | Fix the data. Escalate only if details keep changing |
Twelve is a catalogue, not a launch list. Rules 1 to 3 compare against a list, rules 7 to 9 against what the customer said, and rules 4, 5, 6, 11 and 12 against a baseline that exists only after weeks of data. On Lumx, a platform supplies the purpose on every on-ramp and off-ramp and the holder relationship on every destination, and these are the fields a reviewer compares.
Why stablecoin payments are checked before they settle
A confirmed stablecoin transfer cannot be recalled, so a monitoring result that arrives after confirmation is a report about something that already happened. The score runs first, the transaction settles, is held or is stopped, and a person reviews the held ones.
The counterparty also changes. A wire names a beneficiary bank with its own obligations. A wallet address carries only a transaction history, so the system has to read it. List screening alone does not do it: OFAC states in its FAQ 562, released March 19, 2018, that its digital currency address listings are "not likely to be exhaustive". A list lookup is rule 1 of twelve, not a program.
That is also the difference from wallet screening. Screening asks whether a party or an address is on a list or exposed to a flagged service. Monitoring asks whether the behavior fits the customer, after every transaction. KYT (know your transaction) is the usual name for the second kind of check. The screening side is in wallet screening for stablecoin payouts.
Lumx puts on-ramps and off-ramps flagged by its transaction monitoring on hold pending review. Chainalysis KYT covers blockchain activity only, across every type of wallet, including funds received from an external address. Fiat legs are monitored with Lumx's own systems plus the oversight of its banking partners. The rules and thresholds are internal compliance policy and are not published.
Where false alerts come from
Most false alerts come from four sources, and none is a bad customer.
The first is a cap the customer is obeying. Amounts under a limit look like rule 5, but a customer with a fixed limit will send amounts under it. A KYC (know your customer, verification of an individual) Standard customer on Lumx has a per-transaction limit of $7,500, and a KYB (know your business, verification of a company and its owners) Standard business has $50,000. A run of $7,400 payouts from the first is most likely sizing to the cap, so the first check is the limit, not the intent. The same holds on Bre-B, where payouts above 1,000 UVB (COP 12,110,000 for 2026, under the Banco de la República's Circular Reglamentaria Externa DSP-465) are refused, so amounts can cluster just under the ceiling.
The second is a stale profile. Rule 4 compares today with the baseline declared at onboarding, so a business that doubled its payroll will alert every month until someone updates the expectation.
The third is a name-only match. Rules 1 and 3 on a common name produce the largest queue on any screening system, and a second identifier removes most of it. A named virtual account (a local account number issued in the customer's own name) sharpens rule 7, because the holder name is a hard fact to compare the payer against. See what a named virtual account is.
The fourth is the network. A first transfer from an unseen address is routine for a business that has just opened a wallet, including on USDT over Tron (USDT on Tron for business payouts).
FinCEN draws a similar line from the regulator's side. Its October 2025 SAR FAQs say that a transaction at or near the $10,000 currency transaction reporting threshold is not, by itself, enough to require a suspicious activity report, and that monitoring parameters should be commensurate with the institution's money laundering and terrorist financing risk. That $10,000 figure is the US cash threshold, so it applies to stablecoin payouts only by analogy: clustering just under a line is a signal to check, not proof.
Lumx rejects a transaction that would pass its type's single, daily or monthly limit with a 422 and the TRANSACTION_LIMIT_EXCEEDED code, and the customer record can return the amount used and remaining for each type.
How to tune the rules without missing real risk
Tune in this order.
Give every rule an owner and a reason it exists.
Set the baseline from what each customer declared, by segment. A payroll platform and a marketplace have different normal months.
Require a second identifier before a name match reaches a reviewer.
Move thresholds only with data, and review activity just below the new line as if it had alerted. If real suspicious activity appears there, the change went too far.
Measure per rule: the share of alerts closed as normal, the time to close and how many needed a document. A program-wide rate hides the two rules that make most of the noise.
Write down each change, its reason and who approved it.
I would launch with the rules whose alert ends in a question the customer can answer with one document: profile mismatch, third-party payer and destination change. The statistical rules can wait for a month of alert data. A rule with no baseline is a guess that teaches reviewers to close alerts without reading them. I would rather start with five rules that people read than twelve that people clear.
The declared profile is the cheapest baseline you have. When a customer is verified on Lumx, the transactional information collected covers the source of funds, the expected monthly volume or revenue and the counterparties, and a material change in expected activity is a situation in which Lumx asks for source-of-funds documents. What business verification covers is in what KYB is.
What happens when a transaction is flagged
A flag opens a hold. A reviewer decides whether it is a false positive and, if not, asks the customer for context, then releases, rejects or escalates.
A rejected tax ID or malformed account number is a validation failure, not a monitoring decision (why payouts get rejected). A hold is not a report. For a money services business in the United States, 31 CFR 1022.320 requires a suspicious activity report for a transaction of at least $2,000 that the business knows, suspects or has reason to suspect involves illicit funds or is designed to evade reporting, due no later than 30 calendar days after initial detection of the facts (eCFR). FinCEN's October 2025 FAQs describe a 90-day review and a filing 120 days after the previous one as a suggested cycle for continuing activity, not a requirement. Filing duties depend on the entity and the jurisdiction, and this section covers the US only. On Lumx's side, an external transfer in Brazil is identified and reported to COAF, and in Colombia the reports to the UIAF are the banking partner's. A business in Brazil or Mexico should read its own regulator's rules, which this post does not cover.
On Lumx, compliance reviews a flagged transaction manually. If it is not a false positive, they contact the customer on the usual channel, email or Slack, with the transaction details, and the customer has 24 hours to respond or the transaction may be refunded to the sender.
Should you build, buy or inherit transaction monitoring?
Building means your own rule engine and analysts. Buying means a vendor tool you configure. Inheriting means relying on the monitoring your provider runs on the flows it carries.
Build, buy and inherit compared. Judgment, not vendor data.
Build in-house | Buy a vendor tool | Inherit from the provider | |
Who writes the rules | Your team | You, from vendor templates | The provider, for flows it carries |
What it sees | Everything you log | What you feed it | Transactions through the provider |
Who staffs review | You | You | The provider, with questions to you |
Covers your users before they reach the provider | Yes | Yes | No |
Best when | Several jurisdictions and your own analysts | You hold funds or run your own ledger | The provider carries the money and you are the product layer |
A business that sends payouts through a provider should inherit the provider's monitoring on its flows and add a small layer on what only it can see: who its users are and what they are supposed to do. How to weigh a provider's controls is in choosing a stablecoin infrastructure provider, and the split between people and software in compliance agents for cross-border payments.
With Lumx, monitoring on on-ramps and off-ramps runs inside the flow, so a platform integrating it inherits that layer. Each seller, employee or sub-merchant is onboarded as its own customer, so the platform's part is knowing its users.
When transaction monitoring is the wrong tool
Monitoring is the wrong control when the problem is what the system cannot see. Nested payments are the clearest case: a customer who routes other parties' money through its own account produces flows that look like its own activity, and no rule can compare a payer to a holder when the real payer is hidden.
It is also the wrong control at very low volume, where reading every payout beats tuning rules.
What a flagged payout looks like on Lumx
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
On the global payments API, the monitoring inputs are fields a platform fills in. Every on-ramp and off-ramp carries a purpose from a closed list of nine values. A value that does not match what the funds are used for can hold up the transaction or trigger an RFI (request for information, a compliance hold that asks for a document). Every destination declares who holds it.
When a flag happens, the platform's job is small: watch the channel compliance writes on, and have the sender and receiver relationship, the purpose and the expected outcome ready. On a flagged transaction, compliance writes on the customer's usual channel, email or Slack, and the 24-hour window applies. The customer-level RFI is a separate state, for KYC and KYB. Live countries and rails are on the coverage page, and the countries Lumx onboards are on the supported countries list.
Methodology and sources
Read on November 1, 2026: Lumx documentation on RFI, identity verification, limits, purpose, destinations, nested payments and prohibited activities (docs.lumx.io); 31 CFR 1022.320 on eCFR; FinCEN, Frequently Asked Questions Regarding Suspicious Activity Reporting, October 2025; OFAC FAQ 562, March 19, 2018; FinCEN Advisory FIN-2019-A003, Advisory on Illicit Activity Involving Convertible Virtual Currency, May 9, 2019; and the Banco de la República's Circular Reglamentaria Externa DSP-465 for the 1,000 UVB ceiling.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Igor Saikin on Unsplash.
What is stablecoin transaction monitoring?
Stablecoin transaction monitoring checks payments, wallet addresses and customer behavior against rules and risk scores, and holds activity that does not fit the customer's profile for a person to review. On Lumx, on-ramps and off-ramps flagged by transaction monitoring are held for review, and Chainalysis provides the blockchain transaction monitoring.
How do you measure false alerts in transaction monitoring?
Count, per rule, the share of alerts a reviewer closes as normal, the time to close and the number that needed a document. No source read for this post publishes a target rate, so set one from your own baseline.
Does every flagged transaction have to be reported?
No. A flag opens a review, and a report follows only if the reviewer knows, suspects or has reason to suspect that the transaction involves illicit funds or is designed to evade reporting. The test comes from 31 CFR 1022.320, and a transaction sitting near a reporting threshold does not meet it on its own. On Lumx, compliance reviews the hold and asks the customer for the relationship between sender and receiver, the purpose and the expected outcome.
Should a fintech build its own transaction monitoring?
Usually not at the start. A platform that sends payouts through a provider inherits the provider's monitoring on those flows and needs its own layer only for what the provider cannot see, such as who its users are. Building makes sense when the platform holds funds or spans jurisdictions with different rules. With Lumx, monitoring on on-ramps and off-ramps runs inside the flow, and each of the platform's users is onboarded as its own customer.
