How to Configure AML Screening to Reduce False Positives
Most AML screening systems generate from 90 to 95% false positives out of the total number of alerts — this is the estimate given by PwC and a number of industry studies. Out of a hundred matches requiring a compliance officer’s attention, only five to ten turn out to be real risks. The rest are the result of inaccurate name matching, outdated data, or excessively broad rules. Each such alert costs time: by regulators’ estimates, processing a single suspicious activity report (SAR) takes about two hours, and independent studies record even higher costs.
Systems working «out of the box» with default thresholds and without adaptation to the customer base profile inevitably overload the manual review team. Excessive alerts do not increase security — they create «alert fatigue», due to which analysts start missing real matches. Regulators record this effect: fines for ineffective alert management have become as much a reality as fines for missing sanctioned persons.
Reducing false positives is an engineering task. It is solved by a combination of four settings: separate rules for different types of lists, normalization of input data before matching, accounting for secondary identifiers, and threshold calibration. Each of these elements removes its own layer of «noise», and only together do they yield a measurable result without an increase in regulatory risk.
How to Separate Rules for Sanctions, PEP, and Adverse Media
Sanctions lists, databases of politically exposed persons (PEP), and sources of adverse media in the press solve fundamentally different tasks and imply different response logic. Sanctions are a legal prohibition: a match with an entry from the OFAC SDN list, the UN consolidated list, or the EU list requires immediate blocking of the operation. PEP screening is an assessment of elevated risk: the status of a politically exposed person does not by itself prohibit service but obliges the application of enhanced due diligence (Enhanced Due Diligence). Adverse media is a signal, not a verdict: a media publication may indicate corruption connections, or it may relate to a namesake.
When all three categories are handled by a single set of rules with a unified sensitivity threshold, the system generates excessive «noise». A threshold optimal for sanctions (where the cost of a miss is a fine and criminal liability) will be excessively strict for PEP and adverse media, where more flexible routing is acceptable.
Separating the rules means that for each list category, its own parameters are set: the matching algorithm, the match threshold, the set of confirming fields, and the route for handling the result. For sanctions it is reasonable to keep a low threshold with mandatory escalation of any match above the minimum score. For PEP — to set a higher threshold and add automatic filtering by date of birth and country, which immediately weeds out a significant portion of namesakes. For adverse media it is more effective to use NLP filtering by content relevance: the system analyzes whether the mention is related to financial crimes, corruption, or terrorism rather than merely containing a matched name.
Sanctions matches are still handled with maximum strictness, while the freed-up resource of the compliance team is redirected to genuinely significant cases instead of the mass review of PEP namesakes.
Separate logic for sanctions, PEP, and adverse media requires not only different thresholds but also different sources, matching algorithms, and result-handling routes. Without a precise binding of each loop to up-to-date databases and without daily data updates, the separation of rules remains theoretical — the system continues to generate «noise» where it could be removed at the input.
We will analyze your current screening configuration and set up the AML module with separate rules, thresholds, and routes for each list category. Screening is conducted against more than 1,700 databases and sources — from OFAC SDN and the UN consolidated list to Rosfinmonitoring lists and reputational media. Key sources are updated daily, which rules out triggers on outdated entries. Connecting the AML loop takes 1–2 days depending on the composition of the sources and information-security requirements, after which you will receive working alert routing with documented decision logic.
How to Normalize Names, Spelling Variants, and Transliteration Before Matching
Transliteration is one of the main sources of false positives. The Arabic name عبد الرشيد can be written in Latin script as Abdal-Rachid, Abd al-Rashid, Abdulrasheed, or a dozen other variants — and each of them is technically correct. Cyrillic names produce similar variability: «Евгений» becomes Evgeny, Evgeniy, Yevgeny, or Yevgeniy depending on the transliteration system. If the screening system compares strings «as is», without prior normalization, it either misses a real match or triggers on every close variant.
Normalization is a set of transformations that bring the input data and the entries in the lists to a single format before matching begins. The basic steps: bringing the case to a single form, removing titles and forms of address (Mr., Dr., Sheikh), excluding stop words in company names (Ltd, Inc, GmbH, OOO), standardizing the order of the name components (first name–patronymic–surname or surname–first name), and unifying special characters — hyphens, apostrophes, diacritics.
The next level is phonetic and linguistic matching. Algorithms like Double Metaphone, Beider-Morse, or Daitch-Mokotoff convert a name into a phonetic code and compare the sound rather than the spelling. This makes it possible to link «Mohammad» and «Muhammad», «Sergey» and «Сергей» without manually maintaining synonym tables. For languages with non-Latin scripts, the presence of semantic transliteration is critical, which takes into account not only the sound but also the meaning — for example, for Chinese and Japanese characters, where a single character can have several readings.
In practice, normalization is implemented as preprocessing at the input to the screening engine. The customer’s data and the entries from the sanctions databases pass through the same chain of transformations, after which the already-normalized forms are matched. This removes a layer of false positives generated solely by spelling variability — by various estimates, from 20 to 40% of the total volume.
Transliteration variability is capable of generating from 20 to 40% of all false positives — and this share grows in proportion to the number of jurisdictions in which your customers operate. For normalization to genuinely remove «noise» rather than create new misses, the matching algorithms must take into account the specifics of particular languages and name-recording systems.
We will select and configure a chain of normalization and phonetic matching for your customer profile. The platform supports more than 200 countries and 90 languages, and the AI-OCR module recognizes over 10,000 document types, including machine-readable zones — this makes it possible to extract data in a unified format before it is even passed to the screening engine. The average API response time is under 1 second, so the additional normalization layer does not slow down the check. To start, we will need information about the geography of your customer base and the lists used — based on it, we will agree on the optimal configuration.
How to Assess the Significance of Matches by Secondary Identifiers
A name match is a necessary but insufficient condition for confirming a connection to an entry in a sanctions list or PEP database. The name «Alexander Ivanov» or «Mohamed Ali» occurs so often that matching by it alone is guaranteed to generate dozens of false alerts for every real case. Secondary identifiers — date of birth, country of citizenship or residence, document number, address — make it possible to assess how likely it is that the matched name belongs to a person from the list.
Sanctions lists often contain a minimum of secondary data. An entry may include only a name and country, without a date of birth or with an approximate date (for example, «approximately 1970»). The screening system must take this deficit into account: if a secondary identifier matches — the weight of the match grows; if it does not match — it decreases; if the identifier is absent from the list — it should neither raise nor lower the final score.
The practical implementation looks like a multifactor assessment. Each matched attribute adds points to the final score: an exact match of the date of birth — the maximum weight; a match of the year of birth without the month and day — medium; a match of the country — an additional but not decisive factor. The final score determines the route: high — escalation to manual review; medium — a request for additional information from the customer; low — automatic closure with a record in the audit log.
This approach fundamentally differs from the binary «matched / did not match» logic. It allows the system to handle uncertainty: when the data is incomplete, the decision is made not by a single attribute but by the totality of available signals. The analyst receives not just a list of names but a ranked queue with an explanation — which attributes matched and with what weight. This reduces the review time of each case and lowers the probability of error during manual review.
How to Configure Match Thresholds and Suppress Repeat Matches
The match threshold is a numerical value below which the system does not generate an alert. It determines the balance between sensitivity (the ability to detect a real match) and specificity (the ability to filter out a false one). Too low a threshold captures everything and overloads the team; too high a one misses real matches, which creates regulatory risk.
There is no universal «correct» threshold — it depends on the customer base profile, the geography of operations, the lists used, and the matching algorithm. Regulators (FinCEN, FCA, Rosfinmonitoring) do not prescribe specific values but require that the chosen threshold be substantiated, documented, and periodically reviewed. The justification is built on testing: a sample of real data is taken (for example, 1,000 customer records), run through the system with different thresholds, and for each value the number of true positives, false positives, and false negatives is recorded. The optimal threshold is the one at which all known sanctioned persons are detected (a zero level of false negatives for sanctions) while the volume of false positives is minimal.
It makes sense to differentiate thresholds by list type. For sanctions screening, the threshold is usually set lower (for example, 70–80% on the fuzzy-matching scale) so as not to miss spelling variants. For PEP screening, a higher threshold is acceptable (85–90%), especially if it is backed by verification of secondary identifiers.
A separate task is suppressing repeat matches (deduplication and whitelisting). If a customer has already been checked against a specific entry in a sanctions list and deemed a non-match, a repeat alert at the next screening carries no new information — it duplicates an already-made decision. The system must remember resolved matches and not generate an alert again until the entry in the list has changed. If the data in the list has been updated — a new alias has been added, the date of birth has changed, information about associated persons has been expanded — the previously closed match must go through verification again. This requires the screening system to have record versioning and tracking of the deltas between the current and previous versions of the list.
Suppressing repeats is one of the fastest ways to reduce the volume of manual work. In organizations with a large customer base and regular batch screening, repeat alerts can make up to half of the total volume. Their correct handling frees up the resource for reviewing new and genuinely significant matches.
Repeat triggers on already-checked entries can make up to half of all alerts during regular batch screening — this is a direct cost of the compliance team’s working time without any gain in security. For the correct suppression of repeats, the system needs record versioning, a binding of decisions to a specific version, and automatic reopening of a case when the data in the list is updated.
We will configure whitelisting and deduplication in combination with case management, which records every decision in the audit log with a binding to the rule and the record version. The platform’s AML module reduces the manual compliance load by up to 80% through the automation of screening and routing — analysts work only with new and genuinely significant matches. Sources are updated daily, and at each update the previously resolved matches undergo re-reconciliation. The solution is available both in the cloud and within the customer’s environment — on-premises or private cloud.
How to Reduce Escalations to Manual Review
Configuring thresholds and matching rules reduces the total number of alerts, but even with correctly configured screening, some matches continue to require attention. If every such alert turns into an escalation, the compliance team spends the bulk of its resource on reviewing obviously irrelevant cases, while real matches are lost in the flow.
Between screening and manual review, an intermediate layer of three mechanics is needed: automatic closure of alerts with demonstrably low risk, a request for a single clarifying attribute from the customer, and passing to an analyst only those cases where the automation cannot make a decision. Such a layer frees up analysts’ time for work on genuinely complex matches and makes each decision more substantiated.
Which Matches Can Be Closed Automatically
Automatic closure of an alert is not the ignoring of a match but a documented decision of the system, made on the basis of objective criteria, with the reason recorded in the audit log. Regulators, including FATF, allow automation at the alert-review level provided the process is reproducible, transparent, and subject to verification.
Typical categories of alerts that can be closed without an analyst’s involvement:
| Category | Description |
|---|---|
| Date-of-birth mismatch | The system found a name match, but the customer’s date of birth diverges from the date in the sanctions list by more than a set threshold (for example, by 3 years or more), and there are no other confirming signs — the alert is closed automatically. The date of birth remains one of the most reliable discriminators when screening individuals. |
| Country mismatch | The customer is registered and operates in a jurisdiction in no way connected to the sanctions entry, while there is neither a common date of birth nor matching secondary identifiers. Such alerts often arise because of common first names and surnames (Mohammed, Ali, Smith, Ivanov) and generate the bulk of the «noise». |
| Repeat matches with previously resolved entries | A specific customer has already passed manual review for the same sanctions match and was deemed irrelevant — a repeat alert during rescreening or continuous monitoring can be closed automatically provided the entry in the sanctions list has not been updated since the last decision. Whitelisting requires a binding to a specific version of the entry: if the regulator has added new identifiers or changed the wording, the alert must go through verification anew. |
| A match on a partial name only with a complete divergence of all other attributes | The match score is below the confidence threshold, no secondary identifier confirms the connection — the system records the reason and closes the case. |
For each auto-closure category, it is necessary to fix a rule in the policy and ensure three things: recording the reason for closure in the log, the ability to review the decision manually at any time, and regular validation of the rules on a sample (for example, quarterly) to confirm that auto-closure does not miss true matches.
When to Request a Single Clarifying Attribute Instead of an Escalation
Between an obvious false positive and a confirmed match there is a «gray zone» — alerts where the data is insufficient for an automatic decision but there are also no grounds for a full escalation. Requesting a single additional attribute from the customer makes it possible to resolve the case in minutes rather than in hours of an analyst’s work.
If a match is based on a name and one of the secondary identifiers partially matches (for example, the year of birth matches, but the day and month are unknown), the system requests from the customer a specific attribute that will make it possible to unambiguously separate them from the sanctions entry: the full date of birth, citizenship, document number, or place of birth — depending on which data the corresponding entry in the list contains.
Such a request is embedded in the onboarding process as an additional form step rather than as a suspension of the check. The customer fills in one field, the system compares the received value with the entry in the list and makes a decision. If the attribute confirms the divergence — the alert is closed with a «resolved by clarifying attribute» mark. If it confirms the match — the case is escalated.
The conditions for applying this mechanic:
The request must be proportional to the risk. A single text attribute is a reasonable and familiar step; a passport copy for the sake of an adverse media check is excessive.
The attribute must be discriminating. Requesting data that is not in the sanctions entry is useless — there will be nothing to compare against. Before configuring the rule, it is worth analyzing the completeness of attributes in the lists used: for example, in the OFAC SDN list the date of birth is indicated for approximately 70–80% of individual records, and the passport number much less often.
The request timeout must be finite. If the customer has not provided the attribute within the set period (for example, 24–48 hours), the case is escalated to an analyst. Infinite waiting creates «stuck» cases that worsen both the metrics and the customer experience.
Which Cases Genuinely Require Manual Review
After auto-closure and clarifying requests, only cases where the automation is unable to make a defensible decision should remain in the analyst’s queue — specific categories with elevated regulatory or reputational risk.
An exact match against a sanctions list. The name and at least two secondary identifiers (date of birth, citizenship, document) match an entry in the OFAC, EU, UN, or a national list — the case is passed to an analyst immediately. Even if the customer claims the match is coincidental, it is precisely the analyst who must verify the data, document the conclusion, and, if necessary, prepare a report to the regulator.
A PEP match with a high-level position. Politically exposed persons of the first category — sitting heads of state, members of governments, senior judges, heads of state corporations — and their immediate relatives require enhanced due diligence (Enhanced Due Diligence). It is impossible to automatically determine whether a business relationship with such a customer is permissible: here an assessment of the source of funds, the nature of operations, and the risk level taking into account the organization’s internal policy is necessary.
A match against an adverse media entry related to financial crimes. Screening identified a relevant publication in an authoritative source indicating the customer’s involvement in money laundering, corruption, terrorism financing, or fraud — closure without manual analysis carries regulatory risk. The analyst assesses the reliability of the source, the recency of the publication, the presence of refutations, and the connection to the specific person.
Several simultaneous matches against different lists. The same customer «triggers» simultaneously against a sanctions list and a PEP database, or against sanctions and adverse media — the totality of signals amplifies the risk and requires a comprehensive assessment that cannot be reduced to a single auto-closure rule.
Cases with incomplete data where it is impossible to either confirm or rule out a match. The customer has not provided the requested clarifying attribute, and the available data is insufficient for an automatic decision — the case goes to an analyst. The decision «not enough data, let’s close it as false» is unacceptable from a compliance standpoint.
Based on the experience of projects in financial compliance, dividing alerts into three streams — auto-closure, clarification, escalation — makes it possible to reduce the volume of manual reviews by 60–80% without increasing regulatory risk. This is achieved because each alert passes through an additional layer of verifiable logic before it enters the analyst’s queue.
Dividing the flow into auto-closure, clarification, and escalation is capable of reducing the volume of manual reviews by 60–80%, but the specific result depends on the customer base profile, the completeness of secondary identifiers, and the set of lists used. Without testing on real data, it is impossible to assess what share of alerts will fall into each of the three streams.
We will conduct a pilot configuration of the AML module on a limited sample of your customers and show how auto-closure, clarifying-attribute requests, and escalation distribute the alert flow. Per the platform’s benchmarks, the share of cases not requiring manual review reaches 90% — we will record the actual value on your data within a trial period of up to one month. Every automatic decision is recorded in the action log with an indication of the rule and reason, which ensures reproducibility and audit readiness. To launch the pilot, it is enough to agree on the composition of the sources and the routing scenario — connection takes 1–2 days.
How to Preserve Onboarding Conversion During the AML Check
AML screening protects the business from regulatory risks, but with a poor configuration it cuts off legitimate customers. According to industry research, up to 40% of users abandon onboarding if the process takes more than ten minutes, and about 68% of consumers have abandoned an application for a financial product at least once in the past year without completing it. In most cases, the reason for the delay is not a real risk but the system’s excessive caution: false matches generate escalations, escalations slow down decision-making, and the customer leaves for whoever checks faster.
Which Matches Should Block Onboarding
Blocking registration at the onboarding stage makes sense only for matches that carry a direct regulatory prohibition.
The first category is a confirmed match with an active sanctions list (OFAC SDN, EU Consolidated List, UN Security Council, national lists). Sanctions are a strict-liability regime: even an unintentional transaction with a sanctioned person entails fines and criminal prosecution. If the system has matched the customer against an active sanctions entry with a high degree of confidence and the additional identifiers confirm the match — onboarding is halted.
The second is the identification of a customer in lists related to terrorism and extremism (the Rosfinmonitoring list, the FATF high-risk jurisdictions subject to a call for action lists). The requirements of Federal Law 115-FZ and similar laws in other jurisdictions do not allow establishing a business relationship until the check on these grounds is completed.
Matches with PEP databases, mentions in adverse media, fuzzy name matches with a low score — do not require immediate blocking. PEP status does not mean a prohibition on service: FATF directly states that PEP customers are subject to enhanced due diligence, but a match by itself is not grounds for refusal. Blocking onboarding for every PEP match creates an unnecessary load on the compliance team and cuts conversion without a real reduction in risk.
A practical rule: in a properly configured system, the blocking grounds for stopping onboarding are a few percent of the total volume of checks. If there are noticeably more blocks — the problem is in the calibration of the screening.
What to Check at Onboarding and What in Continuous Monitoring
The risk-based approach, enshrined in the FATF Recommendations and in Russian Federal Law 115-FZ, implies not a one-time check but the distribution of control measures across the customer’s lifecycle. In practice this means dividing the tasks between two loops.
At onboarding it is enough to perform three actions: screening against sanctions and terrorist lists (the result — admission or blocking), basic identification through the KYC pipeline (document, biometrics, liveness), and a preliminary risk-level assessment for assigning a monitoring profile. These steps are performed automatically, take seconds, and do not require manual intervention in the overwhelming majority of cases.
Everything related to in-depth analysis is moved to continuous monitoring (ongoing screening): periodic repeat screening against updated lists (sanctions are updated several times a week, PEP databases daily), tracking the customer’s appearance in adverse media, analysis of transactional behavior through the KYT loop, review of the risk level when circumstances change — a change of jurisdiction, a sharp rise in turnover, the appearance of connections with high-risk counterparties.
This division yields two effects. Onboarding becomes fast and predictable: the customer gains access to the service after passing the minimum mandatory set of checks. Risk is controlled continuously — and this corresponds to regulatory expectations. Regulators assess not only the fact of screening at entry but also the presence of an operating continuous-monitoring system with documented response procedures.
For customers with elevated risk (a high-risk jurisdiction, a complex corporate structure, large amounts), it is acceptable to request additional data before completing onboarding, but the process must not hang. Requesting a single clarifying attribute (for example, confirmation of the source of funds) solves the task faster than a full escalation.
Dividing the checks between onboarding and continuous monitoring removes the excessive load from the customer’s entry point but requires the coordinated operation of several loops — from document recognition and biometrics to AML screening and subsequent monitoring. If even one link slows down, the customer sees the delay and leaves.
We will assemble a KYC pipeline in which sanctions screening, document verification, biometric comparison, and the liveness check are performed automatically and fit within seconds. The full verification cycle — document, face, liveness, and AML — costs approximately 35–50 rubles depending on the connected modules and volume. Continuous monitoring is connected in parallel and works against updated lists without delaying registration. Per the platform’s implementation data, this approach makes it possible to increase onboarding conversion by 15%. A full integration launch, including the configuration of scenarios and thresholds, takes from 3 to 7 days.
Which Check Duration and Which Statuses Do Not Reduce Conversion
Onboarding conversion depends not so much on the fact of the check itself as on two parameters: waiting time and informational transparency. The customer is willing to wait if they understand what is happening and how long it will take. The customer leaves if the process looks like a black box with an indefinite timeline.
The optimal architecture provides for three statuses visible to the customer in real time.
«Check passed» — assigned automatically if the screening revealed no matches or all matches were closed by the system as obviously false. By industry benchmarks, this status should cover 85–95% of applications and be assigned within seconds.
«Check in progress» — used when the system has detected a match requiring additional verification but not a blocking one. The customer gains access to the basic functionality of the service (viewing, profile setup, familiarization with the product) while the check is completed in the background. If manual review fits within 24 hours, the impact on conversion is minimal. Dragging it out beyond 48 hours leads to noticeable churn.
«Check suspended, information required» — applied when there is not enough data from the customer to make a decision. Here it is critical to formulate the request specifically: which document or attribute is needed, in what format, by what deadline. Vague wording like «provide additional documents» is a direct path to losing the customer.
The «Blocked» status is assigned only in the case of a confirmed sanctions match or the customer’s refusal to provide mandatory data within the set period.
Such a status model solves two tasks. From a compliance standpoint — every decision is documented, the audit trail records the grounds and deadlines, and the regulator sees a working process. From a conversion standpoint — the customer sees progress and retains the motivation to complete registration. Introducing transparent intermediate statuses combined with the automatic closure of false positives makes it possible to keep onboarding conversion at a level comparable to processes without AML screening, in full compliance with regulatory requirements.
How to Ensure There Are Fewer False Positives and No Higher Risk
Any AML screening adjustment — a change of thresholds, suppression rules, auto-closure logic — carries the risk of shifting the balance between false positives and missed matches. Reducing false positives in itself proves nothing: if true matches disappeared along with them, the system did not become more accurate but blinder. Every parameter change requires measurable confirmation that there are fewer false alerts while the ability to identify real threats has not suffered.
For this, a system of metrics fixed before the reconfiguration begins is needed. It answers three questions: how accurately the system distinguishes true and false matches, what load manual review creates, and how screening affects the customer’s passage through onboarding.
How to Measure False Positives and Screening Accuracy
The main metric of screening quality is the share of false positives among all generated alerts. In machine-learning terminology this is the inverse of precision: the higher the precision, the less often alerts turn out to be false. The formula: precision = TP / (TP + FP), where TP is true matches with sanctions, PEP, or adverse media lists, and FP is matches that turned out to be false upon verification.
In typical AML systems, precision is 5–10% (that is, 90–95% of alerts are false). After competent tuning of thresholds, filtering rules, and secondary-identifier logic, the figure can grow to 20–40%, and in some scenarios higher. The difference between 5% and 30% precision is the difference between a team drowning in manual reviews and a team working with alerts in a targeted way.
Precision cannot be considered in isolation. Alongside it there must always be recall — the share of detected true matches out of all the matches the system was supposed to find. Recall = TP / (TP + FN), where FN is missed matches. Precision and recall are inversely related: tightening the thresholds raises precision but can lower recall.
For AML screening, missing a true match with a sanctions list is an event with incomparably more severe consequences than an extra false alert. Regulators’ fines, reputational losses, and the personal liability of compliance officers make recall the priority metric. When tuning the system, recall is controlled first: every change must be verified on historical data with confirmed true matches to ensure that none of them dropped out of sight.
Before reconfiguration, fix a baseline — the current values of precision and recall on a labeled sample for the last 3–6 months. The labeling is done based on the results of manual reviews: each closed alert receives the status «true match» or «false positive». After the parameters are changed, run the same sample through the updated configuration and compare the results. If recall has not decreased while precision has grown — the tuning works. If recall has dropped by even a fraction of a percent — it is necessary to review each missed case and adjust the rules.
It is useful to track the false positive rate in the breakdown of check types: separately for sanctions, PEP, and adverse media. False positives in these categories have a different nature, and an aggregated figure can hide problems in a specific segment.
How to Measure the Escalation Rate and Time to Decision
Precision and recall describe the quality of the screening itself but do not show how it loads the operational team. For this, two metrics are needed: the escalation rate (the share of cases passed to manual review) and the time to decision on a case.
Escalation rate = the number of cases sent to an analyst / the total number of generated alerts. In a poorly configured system, this figure approaches 100% — every alert requires human attention. The goal is to reduce it through the automatic closure of obvious false positives and the request for clarifying data without an analyst’s involvement.
Time to decision (resolution time) shows how quickly a case goes through the full cycle — from the generation of the alert to the final status. It must be measured correctly as the median rather than the average: isolated complex cases with investigations lasting several days strongly distort the average figure.
Resolution time should be broken down by case category. Automatically closed cases are handled in seconds. Cases closed after a request for a clarifying attribute — in minutes or hours, depending on the speed of the customer’s response. Cases with a full manual review — in hours or days. If after reconfiguration the median resolution time for manual cases has not changed but the overall median has fallen — the easy cases have been successfully filtered out and no longer clog the queue.
It is also worth tracking the reverse flow: the share of cases initially closed automatically that were subsequently reopened or led to an incident. This metric is an indicator of whether the automation is closing cases that require attention. If reopenings are absent or isolated — auto-closure works correctly. If their share grows — the rules need revision.
All the listed indicators must be recorded in the decision log (audit log) with a binding to the specific rule or threshold by which the case was handled. Without this it is impossible either to analyze the cause of an error or to substantiate the decision to the regulator.
How to Measure Onboarding Conversion Before and After Configuration
AML screening is one of the stages of onboarding, and its impact on conversion is measured only in conjunction with the rest of the process. Onboarding conversion is the share of users who successfully completed all identification steps and gained access to the service, out of the total number who started the process.
To assess the impact of the AML configuration specifically rather than other factors, a cohort approach is needed. Isolate two cohorts comparable in volume: «before» and «after» the changes. The period of each cohort is no less than two to four weeks to account for seasonal fluctuations and the specifics of acquisition channels. Compare conversion precisely at the compliance-check step rather than the end-to-end conversion of the entire onboarding: changes in other modules (OCR, liveness, UX) can affect the final figure and distort the conclusions.
Key measurement points: the share of customers who passed the check automatically, the share of customers who waited for manual review, and the share of customers who abandoned continuing before receiving the result. The last indicator is the most sensitive indicator of a problem. If the waiting time exceeds the tolerance threshold (from a few minutes for online services to one or two business days for banking products), the customer leaves. A reduction in the number of departures at this step is a direct consequence of reducing false positives and speeding up case handling.
When measuring, it is worth taking into account the flip side as well. If after reconfiguration conversion has grown but at the same time the number of customers who subsequently became objects of investigations or blocks has increased — the growth in conversion happened at the cost of missing risks. Conversion is always assessed in pair with precision and recall, as well as with the «post-onboarding incidents» indicator — the share of customers admitted at the screening stage for whom suspicious activities or regulatory inquiries arose within the first 90 days.
The final picture is composed of three layers: screening accuracy (precision/recall by check type), operational load (escalation rate and resolution time), and business impact (onboarding conversion and post-onboarding incident rate). If after a parameter change precision grows, recall does not decrease, the escalation rate falls, resolution time shortens, conversion increases, and post-onboarding incidents do not grow — the tuning is successful. A deviation of any of the parameters in an undesirable direction requires analysis and adjustment before the changes are rolled out to the entire customer base.
Precision and recall, escalation rate, resolution time, onboarding conversion, and post-onboarding incident rate form a coherent picture only when the measurements are taken on real data under comparable conditions — before and after a parameter change. Without a controlled pilot, any reconfiguration remains an experiment with an unknown impact on regulatory risk.
We will launch a test environment lasting up to one month in which your sample will pass through the updated screening configuration. At each stage we will record the key metrics — the share of false positives, the share of escalations, the case closing time, and the conversion at the compliance-check step. A personal account manager will be assigned to you, and technical support is available 24/7 throughout the pilot. As a result, you will receive an agreed-upon picture: which parameters changed, by how much, and by what means — with a binding to specific rules and thresholds.
Reducing false positives in AML screening is achieved by the precise tuning of each link: separate rules for sanctions, PEP, and adverse media eliminate excessive «noise» at the input, name and transliteration normalization removes false discrepancies before matching, a multifactor assessment by secondary identifiers ranks matches by their real significance, and calibrated thresholds with repeat suppression filter out what has already been checked. The intermediate layer between screening and the analyst — auto-closure, clarifying requests, and clear escalation criteria — turns the flow of alerts into a manageable queue where every case is justified. Dividing the checks between onboarding and continuous monitoring preserves the speed of the customer’s passage, and transparent statuses hold conversion.
The stability of the result is confirmed by metrics: precision and recall record the quality of the screening, escalation rate and resolution time record the operational load, and onboarding conversion and post-onboarding incident rate record the balance between business and regulatory risk. When all six parameters are measured before and after reconfiguration on labeled cohorts, any shift in the balance becomes visible before the changes affect the entire customer base.
