What is transaction monitoring and how it works for high-risk accounts

A single large transfer rarely reveals the customer’s full risk. The beneficiary, geography, speed of fund movement, previous activity, and consistency with the declared source of funds all matter. Transaction monitoring combines this data and helps detect patterns that cannot be identified by reviewing one payment alone. However, an automated alert does not confirm a violation and requires professional analysis. In this article, we examine the full monitoring cycle, from setting risk-based scenarios to investigation, escalation, and filing a suspicious transaction report.

What transaction monitoring actually means

Transaction monitoring is the ongoing analysis of customer transactions to identify unusual or potentially suspicious activity. The system compares actual behaviour with KYC/CDD information, the declared source of funds, account purpose, transaction history, and patterns of a comparable customer group.

Monitoring may take place in real time before a transaction is completed or after it has been processed. Real-time monitoring allows the transaction to be paused for additional checks where permitted by applicable law and internal procedures. Post-transaction monitoring helps detect a sequence of related payments that cannot be assessed from a single transaction.

Several controls should be distinguished. Sanctions screening checks payment participants and details against sanctions lists. Transaction monitoring analyses behaviour, amounts, frequency, counterparties, and fund movements over time. Ongoing customer due diligence updates customer information and the risk profile. These processes are connected but do not replace one another.

Under the EBA Guidelines on ML/TF risk factors, monitoring should consider transaction size and frequency, products used, destinations of funds, and consistency with known customer information.

A high-risk classification does not mean that every transaction is suspicious. It requires more intensive monitoring, precise scenarios, and timely customer information updates. The system should identify transactions requiring analysis, not automatically terminate every higher-risk customer relationship.

Which accounts require enhanced monitoring

High-risk status is determined by a combination of customer, product, geographic, and transaction risks, not a single factor. The company should document its scoring methodology and explain why a particular account receives a higher risk rating.

Enhanced monitoring may be required if the customer:

• Is a PEP, family member, or close associate;
• Uses a complex ownership structure without an clear commercial purpose;
• Is connected to high-risk or sanctioned jurisdictions;
• Operates in a cash-intensive, gambling, crypto, payment, or other risk-sensitive industry;
• Conducts significant cross-border transactions;
• Uses correspondent, nested, or payable-through accounts;
• Has high volumes of chargebacks, refunds, or third-party payments;
• Cannot provide credible evidence of source of funds or source of wealth.

Private banking, trade finance, virtual assets, rapid payments, and products enabling fast cross-border fund transfers also increase risk. However, a customer’s industry or nationality alone should not automatically result in refusal of service.

The FATF risk-based approach requires controls proportionate to the identified risk. For high-risk accounts, this may mean more frequent reviews, lower thresholds, additional scenarios, manual analysis, and senior management approval.

The risk rating should be reviewed when ownership, activity, transaction patterns, geography, or adverse information changes. An account rated standard at onboarding may become high-risk after entering a new market or rapidly increasing turnover. A customer may also move to a lower category after a documented change in its model and a sufficient period of stable activity. Every decision should rely on verifiable data, not a formal label.

How the transaction monitoring process works

Monitoring starts with customer data, not an individual payment. The system must understand the customer’s expected activity to identify what constitutes a deviation.

The standard process includes the following steps:

1. Customer risk assessment. During onboarding, the company records business activity, ownership, geography, expected turnover, counterparties, products, source of funds, and intended account purpose.
2. Segmentation. Customers are divided into risk groups and peer groups. Comparing an international payment processor with a small local retailer is inappropriate because their volumes and transaction patterns differ.
3. Data collection. The monitoring system receives information about the amount, currency, date, location, payment channel, sender, beneficiary, device, and linked accounts. Incomplete or inconsistent data reduces coverage.
4. Scenario application. Rules and thresholds reflecting specific risks are applied to transactions. The system may detect rapid movement of funds, structuring, unusual geography, sharp increases in turnover, or payments involving unrelated third parties.
5. Alert generation and prioritisation. A triggered scenario creates an alert. Its priority depends on customer risk, transaction amount, combined indicators, and possible links to previous alerts.
6. Investigation. The analyst reviews the KYC file, transaction history, counterparties, linked accounts, and available external data. If necessary, the customer may be asked for invoices, contracts, source-of-funds evidence, or an explanation of the economic purpose.
7. Decision and feedback. The alert is closed as reasonably explained or escalated for a decision on an STR/SAR, transaction restrictions, or relationship review. Investigation results are used to update the risk score, scenarios, and customer profile.

Every stage should be preserved in the audit trail. Regulators need to see not only the alert but also the data, analyst’s findings, grounds for the decision, and decision date. An unsupported closure such as “activity appears normal” does not demonstrate adequate review.

Red flags and monitoring scenarios for high-risk accounts

A red flag does not prove money laundering or fraud. It indicates that a transaction or series of transactions deviates from expected behaviour and requires analysis within the customer’s context.

For high-risk accounts, monitoring usually covers:

• Splitting an amount across several transactions to avoid reporting or internal thresholds;
• Rapid receipt and almost immediate withdrawal of funds without a clear economic purpose;
• A sharp increase in turnover unsupported by changes in business activity;
• Payments from multiple unrelated third parties;
• Transfers to jurisdictions inconsistent with the customer profile;
• Movement of funds between linked accounts followed by withdrawal to another beneficiary;
• Significant activity resuming on a dormant account;
• Regular round-number payments without invoices or contracts;
• Transactions inconsistent with the declared source of funds, occupation, or revenue;
• Attempts to change the beneficiary, payment description, or channel after an additional request.

Scenarios must be adapted to the product. For merchant accounts, relevant risks include transaction laundering, unusual refunds, excessive chargebacks, and sales inconsistent with the declared business model. Crypto monitoring examines exposure to mixers, darknet markets, sanctioned addresses, rapid chain hopping, and transfers through self-hosted wallets. For correspondent accounts, relevant factors include nested activity, insufficient originator information, and respondent bank transactions involving unknown institutions.

A single indicator may have a legitimate explanation. Rapid withdrawal of funds, for example, is normal for a payment processor but unusual for a holding company. Risk increases when several indicators appear together, such as new geography, an unverified counterparty, an unusual amount, and an attempt to avoid document requests.

Scenarios and thresholds should not be copied from a universal template. They must reflect the enterprise-wide risk assessment, transaction volumes, and known typologies. Otherwise, the system may miss material activity or generate more false positives than the compliance team can review on time.

What happens after an alert is generated

An alert is not evidence of a violation and does not automatically require an STR/SAR filing. It starts an investigation to determine whether the activity has a reasonable explanation or creates grounds for suspicion.

The analyst reviews:

• The customer profile and current KYC information;
• Transaction history and previous alerts;
• Senders, beneficiaries, and linked accounts;
• Contracts, invoices, and payment purposes;
• Source of funds and source of wealth;
• Adverse media, sanctions exposure, and available registry data;
• Consistency with the declared business model.

The alert may be closed with a documented explanation, referred for enhanced due diligence, or escalated to the MLRO. An authorised person makes the filing decision under applicable law and internal procedures. The record should state the facts, identified indicators, checks performed, and reasons for the conclusion.

If suspicion is confirmed, the company files an STR or SAR with the relevant Financial Intelligence Unit within the required period. It also assesses whether to restrict the transaction, intensify monitoring, or terminate the business relationship. Funds may be frozen only where there is a legal basis, such as a sanctions requirement, authority order, or applicable AML procedure.

Employees must not tell the customer about a filed report or investigation if this would constitute tipping-off. Document requests should remain neutral and avoid revealing internal suspicions.

Delayed alert reviews create a separate compliance risk. In March 2026, FinCEN imposed an $80 million penalty on Canaccord Genuity, citing failure to file at least 160 SARs among the violations. A backlog should therefore not be concealed through automatic alert closures or artificial volume limits.

Technology, data quality and human oversight

Automated monitoring is necessary for high transaction volumes, but software does not make the final compliance decision. The system creates alerts based on available data, scenarios, and thresholds. A trained analyst then assesses the context and determines the next steps.

Monitoring quality depends directly on complete information. If the system does not receive data on the beneficial owner, payment destination, device, IP address, or linked accounts, even a properly configured scenario may miss a suspicious pattern.

The company should control:

• Data mapping from all products and payment channels;
• Completeness and accuracy of mandatory transaction fields;
• Version control for rules, thresholds, and risk scores;
• Timely generation and review of alerts;
• Causes of false positives and false negatives;
• User access and configuration changes;
• Retention of audit logs and investigation records.

Machine learning helps identify deviations from normal behaviour and links between accounts not covered by fixed rules. However, an opaque model does not remove the company’s duty to explain to the regulator why an alert was created, prioritised, or closed.

A third-party vendor does not assume regulatory responsibility either. Before implementation, the company should assess coverage, data security, model limitations, service levels, and record export options. Material scenario changes should undergo testing and approval before production release.

Independent validation should confirm that the system covers material risks and operates according to its design. Testing includes sample reviews, analysis of missed activity and alert backlogs, and the quality of analysts’ decisions. A high rate of automatically closed alerts or repeated threshold changes intended to reduce workload requires separate review.

How to build an effective monitoring framework

A transaction monitoring framework should reflect the company’s products, customer base, geography, and actual transaction volume. A standard set of rules not linked to the risk assessment does not demonstrate effective control.

Companies should:

• Identify material ML/TF, fraud, and sanctions risks;
• Divide customers into justified risk and peer groups;
• Link scenarios to specific products and typologies;
• Set documented thresholds and alert priorities;
• Cover all channels, currencies, and legal entities;
• Define investigation and escalation deadlines;
• Allocate enough trained analysts;
• Regularly test data quality and system coverage;
• Analyse false positives, missed activity, and backlogs;
• Update scenarios after new products, markets, and regulatory findings;
• Provide management with regular reports on monitoring quality.

Procedures should specify who may change a rule, lower a threshold, close an alert, or make a filing decision. Material changes require testing, approval, and retention of the previous version.

Effectiveness should not be measured only by the number of alerts or STRs/SARs. More useful indicators include review time, repeated alert rates, reasons for escalation, case file quality, and independent testing results. A sharp decline in alerts after a system change may indicate better precision, but it may also show reduced coverage.

The framework should be reviewed after launching a new product, completing an acquisition, changing customer geography, or significantly increasing transaction volume. If business activity grows faster than compliance resources, the system stops being risk-based and becomes an unmanaged backlog. Review results should be documented in a gap analysis with responsible persons and remediation deadlines.

How Key2Law supports transaction monitoring compliance

The Key2Law team advises financial institutions, payment companies, crypto businesses, and other regulated organisations on AML/CFT controls. We help align transaction monitoring with the risk profile, customer activity, and applicable reporting obligations.

To build or review a monitoring framework, Key2Law can:

• Conduct a transaction monitoring gap analysis;
• Develop customer risk methodology and segmentation;
• Define scenarios, red flags, and thresholds;
• Prepare alert investigation and escalation procedures;
• Align monitoring with KYC, sanctions, and fraud controls;
• Review STR/SAR decision-making and documentation;
• Assess outsourcing and third-party monitoring tools;
• Prepare a remediation plan and management reporting.

If your company needs to implement transaction monitoring, clear an alert backlog, or prepare for a regulatory review, contact the Key2Law team. We will help identify weaknesses, establish a controlled investigation process, and create a framework suited to the risks of high-risk accounts and the scale of operations.