The previous installment in this series outlined the four broad categories that can lead to a hold on an active account: transactional pattern monitoring, on-chain address screening, third-party reports, and user-side protective triggers. The first category is the one users ask about most often, usually as some version of “I didn’t do anything, why was my account flagged?” This guide answers that question at the level the industry actually operates at. It describes the categories of signals that regulated financial institutions are obligated to watch for. It does not describe the internal rules of any specific platform, including Bitbase.

“Suspicious” is not a label any exchange invents on its own. It is a category defined by international anti-money-laundering frameworks and continuously refreshed through public reports.

The institutional history runs along three milestones. The U.S. Bank Secrecy Act of 1970 introduced Currency Transaction Reports (“CTRs”) — the first federal requirement to report cash transactions above a threshold, and the first official recognition that behavior designed to evade that threshold was itself a signal. The Financial Action Task Force (“FATF”), established in Paris in 1989 by the G7, has since published recurring Typologies Reports — case-based catalogs of how money laundering, terrorist financing, and related abuses actually appear in financial systems. After 2013, blockchain analytics methodology emerged as a third layer, applying address-based pattern recognition to public ledger data.

Most regulated financial institutions — banks, brokerages, money transmitters, crypto exchanges — converge on highly similar monitoring dimensions. The reason is structural: they answer to the same body of international standards. FATF Recommendation 10 (customer due diligence), Recommendation 11 (record keeping), and Recommendation 20 (reporting of suspicious transactions) form the common spine.

A note on terminology before the categories. AML practitioners refer to monitoring signals as “red flag indicators” — observable patterns that warrant further attention, not findings of wrongdoing. This guide uses “signal” in that sense throughout.

Structuring is the textbook AML signal. The concept predates crypto by decades. In its original BSA-era form, structuring meant breaking a single large cash deposit into several smaller ones, each just below the threshold that triggered a CTR filing, in order to avoid the reporting requirement. U.S. law has treated structuring as a distinct offense since 1986, when 31 U.S.C. § 5324 — a Bank Secrecy Act provision — made it one.

The reason this pattern is so persistently flagged is that it can be observed without any access to the customer’s intent. A monitoring system does not need to know why the transactions are sized that way. It only needs to observe that they consistently land just under reporting thresholds, that they come in unusual clusters, or that they distribute across accounts in ways that statistically resemble evasive structuring more than they resemble normal commercial activity.

In crypto, structuring has variants. Splitting a large transfer into multiple smaller transfers to or from the same counterparty. Routing similar amounts through several accounts under different names. Test transactions of small amounts immediately followed by a large one, in a sequence that mirrors known laundering scripts. FATF’s Updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs (June 2019, revised October 2021) names these patterns in its typology catalog.

Two characteristics of structuring as a signal. First, what is monitored is the pattern, not any individual transaction. A single transaction below any threshold is unremarkable. The shape of a sequence is what registers. Second, the surface appearance of structuring does not by itself imply illicit intent — many legitimate behaviors (recurring vendor payments at standardized amounts, payroll cycles, routine subscription splits) can produce surface-level similarities. That is precisely why the signal triggers a review rather than a conclusion.

Every account establishes a behavioral baseline as it is used. The dimensions are familiar to anyone who has read a bank statement: typical funding sources, typical counterparties, typical asset categories, typical transaction sizes, typical timing. The baseline itself is not disclosed to the account holder, and for monitoring purposes it does not need to be.

When activity departs from that baseline in ways that exceed what normal variation would explain, the account enters review. Departures that frequently trigger attention fall into several patterns: an order-of-magnitude increase in transaction sizes; a shift in funding sources from established channels to new ones; new counterparties concentrated in higher-risk geographies. Rapid changes in asset composition also register — for example, an account that has long traded major-cap assets suddenly cycling through a series of low-liquidity tokens. So do transactions clustered at unusual times relative to the account’s established rhythm.

The baseline is not punitive in design. Its function is the reverse: it provides the comparison standard that allows the system to treat normal account activity as normal, rather than treating every transaction as worth checking by default. The cost of that approach is that any sufficiently sharp departure from baseline, even one with a benign explanation, registers as a signal.

Practically, life events with legitimate explanations can produce baseline departures. Inheriting funds, selling a business, receiving a large bonus, beginning a new investment strategy, or simply resuming activity after a long period of dormancy can all show up as deviations. The monitoring system has no access to the underlying reason. It registers the shape of the change. Verification, supplied by the user during review, is the mechanism through which the explanation enters the record.

The framing point: deviation from baseline is not a verdict that something is wrong. It is the system noting that the picture has changed, and that a human reviewer should take a look.

FATF and its regional bodies have published Typologies Reports continuously since the 1990s. So have national Financial Intelligence Units — FinCEN in the United States, the FCA in the United Kingdom, AUSTRAC in Australia, and others. These reports are case-based catalogs of how specific abuse patterns have manifested in observed cases: account takeover fraud, layering chains in money laundering operations, market manipulation playbooks, ransomware payment flows, sanctions evasion methods.

Monitoring systems use these typologies as reference templates. When an account’s activity exhibits enough similarity to a known typology — across transaction patterns, counterparty profiles, timing, and other features — the similarity assessment crosses a threshold and the account enters review. This is what is meant by “typology matching.”

Two characteristics matter.

First, matching is probabilistic. A monitoring system does not declare in any binary sense that an account “matches” a money laundering scheme. It produces a similarity assessment, which can be high, moderate, or low. Low-confidence matches still need to be reviewed because the cost of missing an actual case is greater than the cost of clearing a false positive. The cost asymmetry is why monitoring is designed to be over-inclusive at the signal stage.

Second, typologies update. New abuse patterns appear; old ones evolve; the catalog is continuously revised. Account behavior that produced no match six months ago can produce a match today, not because the account has changed but because the typology library has expanded to cover a newly identified pattern. This is one reason monitoring is described as ongoing rather than as a check at any single point in time.

What typology matching is not: a determination that the account is engaged in the activity the typology describes. It is the observation that the surface of the behavior, on the features the system can measure, resembles a known pattern enough to warrant a closer human look.

The first three signal types read the user’s behavior. This fourth type reads something different: the upstream history of the user’s funds.

Public blockchain analytics frameworks — developed by firms such as Chainalysis, Elliptic, and TRM Labs since approximately 2013 — maintain large libraries of address-level risk labels derived from public on-chain data, public investigations, and law-enforcement disclosures. Common categories include: addresses tied to OFAC-sanctioned entities; addresses operated by known mixers; addresses linked to publicly attributed exploits, theft incidents, or ransomware payments; addresses associated with darknet markets; addresses involved in confirmed scam operations.

When funds arrive at an exchange account from an address carrying one of these labels, the receiving account can enter review independent of the user’s own conduct. The outbound direction works the same way: a withdrawal address matching a sanctions or theft label triggers comparable attention. The European Union’s Transfer of Funds Regulation, which entered into force alongside MiCA, formalizes a parallel duty on VASPs to exchange originator and beneficiary information for transfers above defined thresholds.

The user-facing implication is that fund provenance, not only fund destination, can affect account status. A user who received a transfer whose upstream history was unknown to them may find that the receiving account requires verification. This is a structural feature of how on-chain transparency interacts with AML obligations: the chain is public, the labels are public methodology, and regulated institutions are required to read both.

As with the previous three signal types, an address-label match is a review trigger, not a finding. Many label associations resolve once the user provides documentation of the source of funds.

This framing carries through every preceding section.

In each of the four categories, the system action is the same: a signal triggers a review obligation. The review is performed by humans, typically with the cooperation of the user. The user is asked to provide context — explanations, documentation, supporting records. The signal, the user’s explanation, and the objective facts available to the reviewer together determine what happens next.

A signal, taken alone, is not a determination that anything is wrong. It is a flag that warrants attention. Most signals, on review, are cleared. A smaller share lead to further steps, such as additional verification or account restrictions. In cases involving suspected serious abuse, escalation to the relevant authorities follows the legally defined path. The proportions are not published by any platform because doing so would defeat the monitoring function.

For a user whose account has been flagged, the implication is direct. The review is procedural. Cooperating with verification requests, providing accurate documentation, and using official customer-service channels are the only relevant actions. There is no faster route, no person to negotiate with on the inside, no signal-removal technique. The system is designed to weigh evidence. The matching response is to provide it.

Read next. The previous installment of this series: Why ExchangesRun Strict Account Controls: A Plain-Language Guide to KYC and AccountHolds.