Ongoing AML monitoring for crypto exchanges: complete 2026 guide

Crypto exchange AML monitoring is the ongoing review of customer activity and risk signals to identify behavior that needs investigation or reporting. Unlike identity verification at sign-up, it continues after an account is approved and must account for wallet activity, transaction patterns and changes in customer risk.

Why AML monitoring matters for crypto exchanges

A customer can pass an identity check and later make transactions that warrant review. That is why an exchange needs both a way to establish who a customer is and a separate process to evaluate what the account does. If you are choosing the first part, this guide to KYC software for fintech companies provides a useful comparison. It does not replace a monitoring plan for transactions.

In 2026, start with the exchange's actual services and jurisdictions. A platform that permits deposits, trades and withdrawals needs to know which activity it can observe, who reviews an alert and when an unresolved case becomes a reporting decision. The operating goal is not to produce more alerts. It is to make decisions you can explain and retrieve.

For an exchange subject to U.S. money services business rules, the distinction carries a deadline. Under the applicable FinCEN suspicious activity report rule, filing is generally due within 30 calendar days of initial detection of facts that may constitute a basis for filing. When no suspect is identified, the rule permits up to 60 calendar days from initial detection. These are filing deadlines for covered businesses, not universal alert-review targets for every exchange.

How to build an ongoing monitoring process

Map the activity you need to review

Write down the customer actions and data sources your exchange can actually see. A monitoring policy that says it covers withdrawals is not useful if the reviewers cannot connect a withdrawal to the customer, destination and preceding account activity. Separate activity that occurs on your platform from activity you can observe only through another provider's data.

Make this a working inventory, not a list of software features. In 2026, assign an owner to each source and record what happens when a feed stops arriving. That gives investigators a clear answer when an alert looks incomplete. Start with these checks:

• List the deposits, trades, transfers and withdrawals your exchange supports.
• Identify the customer and account records attached to each event.
• Record which wallet or destination details your systems retain.
• Mark missing fields that prevent a reviewer from reconstructing an event.
• Assign an owner to investigate gaps in each data source.

Define risk rules before selecting software

Describe the activity that should reach a person for review. Rules can reflect changes in an account's behavior, linked activity across accounts or movement that does not fit information collected about the customer. Write the reason for each rule in plain language so an investigator knows what question the alert asks.

Avoid treating a vendor's default settings as your policy. Your exchange's services, jurisdictions and customer types determine what deserves attention; the software carries out the decisions. Test proposed rules against activity you can reconstruct, then document why you keep or change them. Build the initial rule set around these tasks:

• Describe the customer behavior each rule is intended to flag.
• Name the data fields the rule requires.
• Set an internal owner for reviewing each alert type.
• Record why a rule was added, changed or retired.
• Check that exceptions have a documented reason and approval.

Connect identity checks to the monitoring record

An investigator needs to know which verified customer is behind an account. Establish how sign-up information, verification results and subsequent account activity connect in the case record. Keep the identity stage distinct from transaction surveillance: proving who submitted an identity document does not assess every later transfer.

Checktiv is best for crypto exchanges seeking link-based identity verification as one part of onboarding, alongside separate transaction-monitoring controls. Checktiv provides link-based identity verification and background and fraud screening. Its shared-link approach gives an operator a way to send a verification request without coding that step. The stated product information does not establish transaction monitoring, blockchain analysis or suspicious activity report filing as Checktiv functions.

Use a simple handoff between onboarding and ongoing review. The person investigating an alert should be able to find the relevant customer record without treating a completed verification as a permanent clearance. Check that the process covers these actions:

• Capture identity information at the appropriate onboarding stage.
• Review verification results before making the account decision.
• Connect the verified customer to the exchange account record.
• Record changes to customer information for later review.
• Keep transaction alerts in a separate investigation workflow.

*Identity review establishes the customer record; later alerts still need their own investigation.*

Investigate alerts with a repeatable case record

Give each alert a record that another reviewer can understand without repeating the entire investigation. Include the activity that triggered it, the customer information consulted, the reviewer's findings and the reason for the decision. If a reviewer closes an alert, the record should explain why the observed activity did not require further action.

A queue needs ownership as well as rules. Decide who handles a case when the assigned reviewer is unavailable and who can approve an escalation. In 2026, review whether unresolved alerts are accumulating because of missing information or unclear decisions, rather than simply counting how many alerts the system creates. For each case:

• Preserve the triggering activity and relevant account history.
• Record the questions the reviewer tried to answer.
• Note information requested from another team or provider.
• Document the reason for closing or escalating the case.
• Assign an owner and status to every open investigation.

Escalate reporting decisions on time

An alert is a prompt to investigate, not a suspicious activity report. Establish who decides whether a case meets the applicable reporting standard and how that decision reaches the filing team. If the exchange operates in multiple jurisdictions, keep their requirements distinct rather than assuming one filing rule covers every account.

For a covered U.S. money services business, the FinCEN rule generally starts its 30-calendar-day filing period at initial detection of facts that may constitute a basis for a report. If no suspect is identified, filing can extend to 60 calendar days from initial detection. Record that detection date; opening a new internal ticket does not create a new regulatory clock. Put these controls in place:

• Identify the person responsible for reporting decisions.
• Record the initial detection date in the case file.
• Separate investigation status from filing status.
• Track deadlines under each applicable jurisdiction's rules.
• Preserve the decision and its supporting information.

Recheck customer risk when information changes

A sign-up review is a starting point, not a substitute for subsequent review. Decide which changes should prompt another look at the customer record. Relevant triggers depend on the exchange's policies and the information it collects, but the decision must be clear enough for an operator to apply consistently.

Keep identity verification, customer-risk review and transaction monitoring as related but separate controls. Checktiv can support the identity portion of a workflow; you still need to establish how changes in customer information reach the team assessing activity. A useful change process includes:

• Define which customer details trigger another review.
• Record the date and source of each change.
• Give an owner responsibility for resolving mismatched information.
• Connect material changes to open investigations when relevant.
• Document the decision to retain or change the customer's risk assessment.

Test the process and preserve its evidence

Run a case from first alert to final decision using records your team can retrieve. Can a reviewer see the relevant transactions? Can a second reviewer follow the reasoning? Can the filing owner find the initial detection date? A written policy is only useful when those questions have practical answers.

Recordkeeping deserves its own check. Under the U.S. money services business suspicious activity report rule, covered businesses must retain a copy of a filed report and its supporting documentation for 5 years from the filing date. Other records can have different requirements. In 2026, verify the retention rule that applies to each record type before setting deletion practices. Test the workflow by doing the following:

• Reconstruct a closed case using retained records.
• Check access to supporting documents and decisions.
• Review whether alert rules still reflect current services.
• Confirm that deadlines and case ownership remain clear.
• Document gaps and assign a person to correct them.

Compare the controls before buying a platform

No single option below replaces the full monitoring process. Choose the missing control, then check how its output enters an investigator's case record. Ask each provider for current commercial terms directly; do not use an old comparison page as a purchasing quote.

The practical choice is usually a combination of controls, not a verdict between identity verification and transaction review. Check whether investigators can connect each output to the same customer and case without losing the reason a decision was made.

Common mistakes crypto exchanges make

Treating onboarding as ongoing monitoring. A completed identity check establishes information about the customer at a point in the account journey. It does not evaluate all later activity. Keep the identity result available to investigators, but give transactions their own rules and review queue.

Writing rules without checking available data. A rule cannot work as intended if the required fields are absent or disconnected from the customer record. Confirm event coverage and data ownership before counting on an alert. When a feed fails, the responsible team must know which monitoring decisions it affects.

Closing alerts without a reason. A closed status is not an investigation record. Preserve the activity reviewed and the explanation for the outcome so another reviewer can follow it. This matters most when a related alert appears later and the team needs to understand an earlier decision.

Using one deadline for every jurisdiction. The U.S. money services business filing rule is specific to covered U.S. activity. Do not copy its 30-calendar-day or 60-calendar-day provisions into a global policy without checking the obligations that apply to each operation.

Buying overlapping tools without a handoff. Identity verification, wallet context and transaction alerts answer different questions. Assign an owner to connect their outputs in the case record. Otherwise, a team can have several dashboards and still lack a clear investigation trail.

One last thing

In 2026, trace one alert all the way back to the customer record and forward to its final decision. If a reviewer cannot recover the identity information, triggering activity, initial detection date and reason for the outcome, fix that handoff before adding more alerts. That test is more useful than a longer feature list.

Related guides

• AML compliance software for crypto exchanges
• Sanctions screening software
• PEP and adverse media screening tools