TL;DR: Transaction monitoring best practices treat tuning as the control and the scenario library as inventory. Thresholds, segments, data quality, and the written reason for each alert decide whether the program catches what it claims to watch. A November 2024 EY survey found that over 80 percent of institutions cited regulatory-instigated changes to transaction monitoring in the prior two years.
Scenarios should come from your own risk
Scenarios should start from the institution's risk assessment, not from a vendor typology catalog. A scenario is a defined pattern the institution has decided to watch: a threshold, a sequence of movements, a counterparty type, a geography, or a break from the customer's own history. The pattern earns a place in the library when it maps to a product, a customer segment, a channel, or a suspicion the institution actually faces.
FinCEN's CDD final rule puts ongoing monitoring in its fourth requirement. That requirement calls for monitoring to identify and report suspicious transactions and, on a risk basis, to update customer information. A scenario that fires with no tie to who the customer is, what the customer was expected to do, and whether the activity changed, is a generic net. How transaction monitoring works is easier to defend when each scenario names the risk it serves and the customer attributes it reads.
EY's November 2024 survey found that over 80 percent of institutions cited regulatory-instigated changes in the prior two years. Regulation moves the library, and so do new products, new corridors, and a shift in the customer book. An industry typology is a prompt for that review. The list becomes a control only after the institution decides which items apply, which do not, and which risk statement supports the choice.
Write the tie-out in the scenario file. For each scenario, record the risk it addresses, the products and segments in scope, the fields it uses, why a rule was chosen, and the person who can explain a change. Two scenarios that alert on the same behavior double the queue and still leave a gap elsewhere. Ask which risk would go unwatched if the scenario were removed. If the answer is none, the scenario is inventory rather than detection.
The monitoring project is a data project
Monitoring quality follows data quality. Almost 65 percent of institutions in the EY survey cited data quality as an execution challenge. Scenarios that look precise in a workshop fail once account identifiers break across systems, counterparty names arrive truncated, transaction codes differ by channel, or expected-activity fields from onboarding never reach the monitoring feed. The rule can be correct against a data model the production feed does not match.
The fourth CDD requirement joins the two jobs. Ongoing monitoring identifies suspicious transactions, and it updates customer information on a risk basis. When monitoring shows that the stored profile is wrong, the update is part of the control. A cash-intensive business coded as a consumer will flood a consumer scenario or slip past the commercial one. Customer due diligence requirements for banks supply the attributes that segments and expected-activity tests use.
Run a field test before debating a threshold. List every input the scenario reads: customer type, occupation or industry, expected periodic volume, country, channel, counterparty, amount, and date. For a recent period, check whether each field arrives, whether the value is real rather than a default, and whether it matches the system of record. A scenario that depends on a field the feed does not reliably carry is not ready to tune. Narrow it to the population where the field exists, or fix the feed.
Rules-based detection remains dominant in the EY survey, and 43 percent of institutions use machine learning in detection. A model trained on miscoded customer types will learn the miscoding and return it as a score. The institution still needs field definitions, lineage from the source system to the alert, and a way to show which inputs drove a given alert. If the file cannot say where expected activity came from, neither a rule nor a model can show that the alert was a true break from the customer's profile.
Tuning is the control
Tuning is the control. The scenario library is the inventory. Every institution in the EY survey had optimized its transaction monitoring or planned to, and that work was mostly threshold tuning or segmentation. A scenario name on a slide does not separate suspicious activity from ordinary activity. The threshold and the segment do.
Segmentation keeps one scenario from applying one number to unlike customers. A payroll customer and a money-services business should not share a cash threshold only because both can deposit currency. Sound segmentation follows the risk assessment and uses attributes the feed actually holds: customer type, product, geography, tenure, and expected activity. Transaction monitoring rule tuning fails when a label cannot be populated, or when bands are so narrow that no one can tell whether a threshold is working. Too few segments, and ordinary activity floods the queue. Too many, and nobody can explain why a customer sits in one band.
Threshold changes need a before-and-after record. State the old value, the new value, the segment, the reason, what a sample of alerts looked like under both settings, and who approved the change. Judge the sample by whether the pattern the scenario was built to catch still alerts, not only by whether the count dropped. Raising a threshold to shrink the queue is a detection decision made for operational relief. Review a sample of activity the new setting no longer alerts on, and compare that activity with the original risk statement.
A SAS survey with KPMG of ACAMS members, published in February 2025, found that 38 percent named reducing false positives in existing surveillance systems as the priority for deploying AI or machine learning. A suppression, a score cutoff, or a new exclusion is still a threshold decision. The same record should exist: what changed, on which population, what the sample showed, and who approved it. Keep both the alerts the new logic still produces and a sample of alerts it now withholds.
What an examiner should be able to read
An examiner should be able to read the monitoring program as a chain of decisions, not as a tour of a system. Start from one scenario and walk outward. The file should show the risk the scenario addresses, the population it covers, the fields it uses, the current threshold, the history of threshold and segment changes, and a sample of dispositions a stranger can follow. If any link is missing, the system can still generate alerts while the program fails the read.
The disposition write-up is the link that usually breaks. A useful write-up names the alerted activity in figures taken from the transactions, compares those figures with the customer's expected activity and with the segment, states which other sources were checked, and gives a reason for clearing, for updating the profile, or for escalating. "Reviewed, activity consistent with profile" is not a reason unless the profile figures are in the note. When the activity shows that onboarding data was wrong, the update to customer information belongs in the same write-up.
Data lineage belongs in the same packet. For the fields the scenario uses, the institution should be able to name the source system, how often the feed runs, and what the rule does when a value is missing. An examiner who asks why an alert fired, or why a similar pattern did not, will land on that feed. Comparing transaction monitoring software is a question about the engine. The readable file is the control. A library export with no change history, no sample dispositions, and no data exceptions is a configuration dump.
Test the file on one alert chosen by someone who did not work the case. That reader should be able to name the risk the scenario serves, the segment and threshold that applied, the customer figures that were compared, and why the disposition followed. If the reader has to ask what "consistent" meant, the write-up failed. If the reader cannot tell whether a recent threshold change would have altered the alert, the tuning record failed.
Where Sphinx fits
Sphinx agents work the alert queue the monitoring system already produces, write the disposition, and leave the rule set with the institution. Scenarios, segments, and thresholds stay with the bank. The agent documents the close so a later reader can see why the alert ended where it did.
Frequently Asked Questions
How often should a bank retune transaction monitoring thresholds?
Retune when the risk, the products, the customer book, or the alert outcomes change, rather than on a date chosen in advance. Every institution in EY's November 2024 survey had optimized its monitoring or planned to, mostly by threshold tuning or segmentation, and over 80 percent cited regulatory-instigated changes in the prior two years. A review that only confirms the old number, with no sample of what the scenario still catches and no longer catches, is not tuning.
What should a scenario library be tied to besides a typology list?
Tie each scenario to the institution's risk assessment: the products, customer segments, geographies, and channels where that pattern would be suspicious. FinCEN's CDD rule expects ongoing monitoring to identify and report suspicious transactions and to update customer information on a risk basis, so the library should also name the customer attributes the scenario uses. A typology with no tie to that assessment is a catalog, not a control.
When is a rules-based alert still the right control?
A rules-based alert is the right control when the behavior can be stated as a condition on known fields and an examiner can read that condition exactly. EY's November 2024 survey found rules-based detection still dominant, with 43 percent of institutions using machine learning in detection. Keep the rule when the institution can tune the threshold, segment the population, and explain a single alert without translating a model score.
What does an examiner ask for besides a monitoring system?
Examiners ask for the risk assessment behind the scenarios, the data that feeds them, the record of threshold and segmentation changes, and dispositions that show why alerts were cleared or escalated. The system shows that alerts are produced. The file shows that the institution chose what to watch and can defend how a sampled alert was closed.
.png)
