Transaction Monitoring

Transaction monitoring is your primary mechanism for detecting money laundering. CIP tells you who your customers are. CDD tells you their risk profile. Transaction monitoring tells you what they're actually doing and whether that activity is consistent with their profile or indicates suspicious behavior.

A money transmitter that skips transaction monitoring or does it poorly is flying blind. You might be laundering money for criminals, financing terrorism, or violating sanctions without knowing it. Transaction monitoring is how you detect that activity, investigate it, and report it to authorities.

Transaction monitoring is also complex, expensive, and imperfect. Regulators expect transaction monitoring systems to catch suspicious activity. But transaction monitoring also generates false positives—alerts on transactions that are legitimate. The goal is to catch real suspicious activity while minimizing false positives. That balance is difficult to achieve.

What Transaction Monitoring Means in Practice

Transaction monitoring means analyzing every transaction your company processes against a set of rules and patterns to identify potentially suspicious activity. The rules are designed to catch specific types of suspicious behavior: unusually large transactions, unusually frequent transactions, transactions to high-risk jurisdictions, transactions to sanctioned parties, transactions that don't match the customer's profile, transactions that match known money laundering typologies.

In practice, here's how it works. A customer initiates a transaction. The transaction data—sender, recipient, amount, destination country, time, customer account history—flows into your transaction monitoring system. The system compares the transaction against your defined rules. If the transaction matches a rule (for example, "amount exceeds $20,000"), the system flags it as an alert. The alert goes to your compliance team, who investigate it. The compliance team determines whether the transaction is suspicious or legitimate. If it's legitimate, the alert is closed (usually documented as a "false positive"). If it's suspicious, the transaction is escalated to your SAR (Suspicious Activity Report) team, and a SAR is filed with FinCEN.

The transaction might be flagged for multiple reasons. A $50,000 transfer from a domestic customer to an OFAC-sanctioned country triggers multiple alerts: amount alert, jurisdiction alert, sanctions match alert. The compliance team's job is to determine whether there's a legitimate reason for the transaction or whether it's suspicious.

Transaction monitoring is rule-based or risk-based. Rule-based monitoring applies the same rules to every transaction: flag all transactions over $20,000, flag all transactions to Iran, flag all transactions occurring at 2 AM. Risk-based monitoring adjusts rules based on customer risk: for a high-risk customer, flag transactions over $10,000; for a low-risk customer, only flag transactions over $100,000. Risk-based monitoring is more sophisticated but requires more development and more data about customer risk.

Most money transmitters start with rule-based monitoring and evolve toward risk-based monitoring as they mature.

Rule-Based vs. Risk-Based Monitoring

Rule-based monitoring is simpler to implement and understand. You define rules, apply them consistently to all transactions, and investigate alerts.

A simple rule-based monitoring system might include: - Flag all transactions over $10,000 - Flag all transactions to high-risk jurisdictions - Flag all transactions involving sanctioned parties - Flag multiple transactions from the same customer within 24 hours - Flag transactions inconsistent with customer account history (rapid change in transaction amounts or frequency)

Rule-based monitoring generates a lot of alerts. A $15,000 transaction triggers the amount alert. A transaction to Mexico (not a high-risk jurisdiction, but sometimes flagged) triggers a jurisdiction alert. Multiple alerts on the same transaction create a compound alert volume. A company processing thousands of transactions per day might generate hundreds or thousands of alerts per day.

The challenge with rule-based monitoring is alert fatigue. If you're generating 500 alerts per day and only 5 are actually suspicious, your compliance team spends most of its time investigating false positives and misses time to investigate true positives.

Risk-based monitoring attempts to solve this by tuning rules based on customer risk. A customer who's been with you for five years, has a consistent transaction pattern, and operates in low-risk jurisdictions might not trigger an alert on a $15,000 transaction (it's within their normal range). The same $15,000 transaction from a new, high-risk customer triggers an alert because it's outside their expected range.

Risk-based monitoring is more efficient but requires more data and more development. You need to define customer risk scores or profiles. You need to track each customer's normal transaction patterns. You need to update those patterns as the customer's behavior changes. You need a system that can apply dynamic rules based on that data.

Many money transmitters use a hybrid approach: rule-based monitoring for high-risk alerts (OFAC matches, high-risk jurisdictions) and risk-based monitoring for pattern-based alerts (amount, frequency).

Building Monitoring Rules and Scenarios

Your transaction monitoring rules should be derived from your risk assessment and your business model.

Start with mandatory rules: - Screen every transaction against OFAC and sanctions lists - Screen every transaction for compliance with geographic restrictions (don't send to embargoed countries) - Identify transactions involving PEPs - Identify transactions to high-risk jurisdictions

Add rules based on your business model: - If you process high-value transactions, flag unusually large amounts - If you process time-sensitive transactions, flag unusual timing patterns - If you process primarily domestic transactions, flag international transactions - If you have known customer segments, flag transactions inconsistent with customer type

Add rules based on known money laundering typologies: - Structuring: Multiple transactions just below reporting thresholds ($9,999 transactions, for example) - Layering: Complex chains of transactions obscuring the source of funds - Integration: Large withdrawals followed by deposits to different accounts - Trade-based money laundering: Invoices that are inconsistent with typical business activity - Prepaid card manipulation: Purchases of prepaid cards followed by rapid transfers - Rapid movement: Funds flowing in and out of accounts very quickly

Develop specific scenarios based on your business. A company processing remittances to Somalia might have a scenario: "Flag customers sending to Somalia who are not known to have family ties to Somalia." A company processing bill payments might have: "Flag customers paying bills that are inconsistent with their known addresses." A company processing peer-to-peer transfers might have: "Flag transfers between first-time customers with no apparent relationship."

Each rule or scenario should have a documented rationale: why does this rule detect suspicious activity? What type of money laundering or financial crime does it catch?

Rules should also have thresholds: the specific values that trigger an alert. A rule might be "flag transactions over $10,000," but you need to document why $10,000 is the threshold. Is it based on reporting requirements? On your customer base's typical transaction size? On risk assessment findings?

Rules need to be reviewed periodically. A rule that was appropriate a year ago might not be appropriate today if your customer base or business model has changed. A threshold that made sense with 1,000 customers per day might not make sense with 10,000 customers per day (if volume increases by 10x, false positive volume increases by 10x unless thresholds are adjusted).

Alert Management and Investigation Workflows

Once alerts are generated, they need to be managed. Alert management means investigating alerts, determining whether they're suspicious or legitimate, and documenting the investigation.

A good alert management process includes: 1. Alert generation: The transaction monitoring system generates alerts based on rules 2. Alert review: A staff member reviews the alert and gathers additional information (customer profile, transaction history, other related transactions) 3. Investigation decision: The reviewer decides whether the alert warrants investigation or can be closed as a false positive 4. Investigation: For alerts requiring investigation, a designated investigator reviews the transaction in detail, contacts the customer if necessary, and determines whether the transaction is suspicious 5. Resolution: The investigator documents the investigation findings and closes the alert (false positive) or escalates to SAR team 6. Documentation: All investigations are documented with supporting information, analysis, and conclusions

The investigation should result in one of three outcomes: - Legitimate transaction: The transaction has a clear, documented legitimate explanation. Alert is closed. - Further monitoring: The transaction is not conclusively legitimate or suspicious. The customer and transaction are added to a watch list for further monitoring of related transactions. - Suspicious activity: The transaction appears suspicious, meets SAR criteria, and is referred to SAR team.

The time to resolve alerts should be documented. Most money transmitters aim to resolve alerts within 5-10 business days. Longer timeframes allow alerts to pile up and create a backlog. Shorter timeframes might not allow sufficient investigation.

Alert management workflows are often implemented in specialized software (AML case management systems) that track alerts, investigations, and resolutions.

Tuning and Calibration

Tuning is the process of adjusting rules and thresholds to improve the signal-to-noise ratio in your transaction monitoring system.

If you're generating 500 alerts per day but only 10 are actually suspicious, you need to tune your rules to reduce false positives. Possible approaches: - Raise thresholds (flag only amounts over $20,000 instead of $10,000) - Narrow the scope of rules (flag large amounts only for new customers, not for established customers) - Add conditions to rules (flag large amounts that are inconsistent with customer history) - Whitelist certain customer segments or transaction types that consistently generate false positives but are legitimate

Calibration is the process of validating that your rules are actually effective at catching suspicious activity. You can calibrate by: - Backtesting rules against historical suspicious transactions that were eventually caught (did your current rules catch them?) - Reviewing SARs to understand what kinds of transactions were actually suspicious (are your rules catching similar patterns?) - Benchmarking against peer companies or regulatory guidance on what patterns indicate suspicious activity

Tuning and calibration are ongoing. As your customer base changes, as regulatory guidance evolves, as new money laundering typologies emerge, your rules need to change.

Many money transmitters fail at tuning. They implement a monitoring system, generate thousands of alerts daily, and accept that as normal. They don't realize that a properly tuned system should generate alerts that are mostly legitimate but worth investigating, not mostly noise.

Technology Platforms for Transaction Monitoring

There are purpose-built transaction monitoring platforms designed for financial services companies. These platforms include Actimize (by FICO), LexisNexis HPAPI, Actinver, Kount, and several others.

These platforms typically provide: - Built-in rule sets based on regulatory guidance and industry best practices - Connection to OFAC lists and other sanctions lists for real-time screening - Customer profiling and risk scoring - Case management for alert investigations - Reporting and audit tools - Workflow management for alert resolution

The cost of these platforms ranges from $10,000 to over $100,000 annually depending on transaction volume and features.

For a company processing thousands of transactions daily, a purpose-built platform is usually more efficient than building in-house systems. For a company processing hundreds or low thousands of transactions daily, a platform might be overkill. Some companies use a hybrid approach: a platform for OFAC screening and basic rule-based monitoring, combined with manual monitoring and case management for complex investigations.

The platform should integrate with your transaction systems so that transaction data flows directly into the monitoring system without manual data entry. Integration reduces errors and delays.

Manual Monitoring for Smaller Operators

Not every money transmitter can afford a $100,000 transaction monitoring platform. Smaller operators often implement monitoring manually or with simplified tools.

Manual monitoring means a staff member periodically reviews transactions manually, looking for patterns or activity that seems suspicious. This is labor-intensive but can work for lower transaction volumes.

A simplified approach might use: - Spreadsheets to track transactions and calculate metrics (average transaction size, frequency, geographic distribution) - Google Sheets or similar tools to record alerts and investigations - Manual sanctions screening (periodically checking customer/recipient names against OFAC list) - Customer profiling documents that describe expected transaction patterns

Manual monitoring is error-prone (it relies on human review), is labor-intensive, and doesn't scale to high volumes. But for a company processing a few hundred transactions per month, it's workable.

As a company grows, manual monitoring should transition to semi-automated or fully automated systems. The transition point is usually when transaction volume exceeds a few thousand per month.

Documentation Requirements

Every alert, investigation, and monitoring activity must be documented. Documentation serves multiple purposes: - It provides a record for audits and examinations - It demonstrates that the company was investigating suspicious activity - It supports SAR filing decisions - It allows the compliance team to track patterns over time - It protects the company if there's ever a claim that it should have detected suspicious activity

Documentation should include: - Alert description (what rule triggered, what was the transaction, what was flagged) - Investigation notes (what information was reviewed, what was discussed with the customer, what was the conclusion) - Timeline (when was the alert generated, when was investigation started, when was it resolved) - References to supporting documents (transaction records, customer files, correspondence) - Final determination (legitimate, suspicious, under further monitoring)

Documentation should be detailed enough that someone unfamiliar with the transaction could review it months or years later and understand the investigation.

What Examiners Expect to See

During examination, regulators review transaction monitoring in detail. They're looking for: - Evidence that you're actually running transaction monitoring (not just claiming you are) - Rules that are appropriate for your business and risk profile - Alert volumes that seem reasonable (thousands of alerts daily suggests over-tuning; no alerts monthly suggests under-tuning or broken systems) - Investigation documentation showing that alerts are actually investigated - Evidence that suspicious activity is being caught - SARs that correspond to documented suspicious activity - Evidence of ongoing tuning and updating of rules

Examiners will pull a sample of transactions and verify whether they were monitored appropriately. They'll look for transactions that should have been flagged but weren't. They'll review investigations to see if they were thorough.

A common finding during examination is inadequate transaction monitoring: the company has a system, but the rules are ineffective, alerts aren't being investigated, or suspicious transactions are being missed.

Another common finding is excessive false positives: the system is generating so many alerts that investigations are superficial and real suspicious transactions are being missed in the noise.