Which AML Checks Are Needed Before Completing Onboarding
An AML check at onboarding solves a specific task: before establishing a business relationship, to determine whether serving the customer is permissible from the standpoint of anti-money-laundering and counter-terrorism-financing (AML/CFT) legislation. The FATF Recommendations and Federal Law 115-FZ structure this check on the principle of a risk-based approach: the volume and depth of procedures depend on the risk level rather than on a single template.
At the onboarding stage, three blocks are mandatory: identification of the customer and associated persons, screening against sanctions and other restrictive lists, and a preliminary assessment of the risk level. These blocks are completed before the customer gains access to services. Transaction monitoring, periodic data updates, in-depth behavior analysis — all of this relates to ongoing monitoring and is performed during the course of service.
An excessive volume of synchronous checks increases the time to pass onboarding and reduces conversion. An insufficient one creates regulatory risks and makes the system vulnerable to fraud. The balance is determined by a clear architecture: which checks block the granting of access and which work asynchronously.
Whom to Verify Besides the Customer
Verifying only the applicant is a common mistake that leads to missing risks at the level of the ownership and control structure. Federal Law 115-FZ (as amended taking into account Rosfinmonitoring Order No. 74, which took effect on July 1, 2025) directly requires identifying not only the customer themselves but also their representatives, beneficiaries, and beneficial owners (UBO). Similar requirements are contained in the FATF Recommendations and the European AML directives.
A beneficial owner is an individual who, directly or through a chain of legal entities, owns more than 25% of the customer’s capital or controls their actions. For legal entities, establishing the UBO is a mandatory step before the start of service. If the ownership chain is opaque or the customer does not disclose the ultimate beneficiary, this in itself is a signal of elevated risk and grounds for enhanced due diligence (EDD).
Customer representatives — persons acting on their behalf on the basis of a power of attorney, constituent documents, or other authority — are also subject to identification and screening. In particular, the sole executive body of a legal entity is verified as a representative. A beneficiary — the person in whose interests an operation is performed — is verified when the customer acts not in their own interests.
In practice, AML screening at onboarding covers at least four categories of persons: the customer themselves, their representative, the beneficial owner, and the beneficiary. For each of them, a check is performed against sanctions lists, lists of terrorists and extremists, as well as PEP screening. Automation through a single API call combining data from the KYC pipeline makes it possible to check all associated persons in one session without re-entering data and without a noticeable increase in time for the user.
Checking four categories — the customer themselves, the representative, the beneficial owner, and the beneficiary — requires access to up-to-date sanctions databases and a single integration point. The NeuroVision AML module accepts normalized data from the KYC loop and performs screening of all categories of persons in a single API call, accessing more than 1,700 sources — from UN and OFAC lists to national lists, PEP databases, and an array of adverse media. Sources are updated daily, which rules out checking against outdated data.
We will connect sanctions screening to your KYC pipeline so that the data of all associated persons is transmitted automatically, without re-entry. The average response time is under one second, and integration of the AML loop takes 1–2 days depending on the infrastructure and information-security requirements. You will get a process that covers the mandatory categories of persons to be verified per Federal Law 115-FZ and does not create a delay on the user’s side.
Which Lists and Risk Signals to Check in Real Time
The synchronous check before completing onboarding includes screening against three categories of sources: sanctions lists, PEP lists, and lists of terrorists/extremists.
Sanctions lists cover the restrictions imposed by international and national regulators. The minimum set: the consolidated list of the UN Security Council, the OFAC lists (SDN and derivatives — SSI, FSE, NS-CMIC), the consolidated EU lists, the UK HMT/OFSI sanctions lists, as well as the national lists of the jurisdictions in which the company operates. For organizations with international activity, it is recommended to take into account the debarment lists of international organizations. The lists must be updated daily: sanctions regimes change often, and screening against an outdated base creates a false sense of protection.
PEP screening identifies politically exposed persons and persons associated with them. PEP status does not mean automatic denial of service, but it requires enhanced due diligence (EDD) and approval from senior management. The practical difficulty is the volume of false matches: fuzzy-matching algorithms generate many candidates, some of which have no relation to the person being verified. High-quality screening systems apply relevance scoring to reduce the share of false positives before manual review.
Verification against lists of terrorists and extremists in the Russian Federation is regulated by Article 7.4 of Federal Law 115-FZ and includes reconciliation against the Rosfinmonitoring list. A match on these lists is a blocking signal: the operation cannot be completed until the suspicions are cleared.
During the initial screening, it is also advisable to take into account additional risk signals: the customer’s geography (a connection with higher-risk jurisdictions per the FATF classification), the type of activity, the complexity of the ownership structure. These signals do not necessarily lead to a rejection, but they influence the assignment of the risk level and determine the need for in-depth verification at the next stage.
All the listed checks are technically feasible in real time if the screening engine is integrated into the KYC pipeline and receives the customer’s data automatically. The average response time of a high-quality AML module working via API is under one second. This is comparable to the time of a biometric check and does not create a noticeable delay for the user.
The composition of the lists for real-time verification depends on the geography of the business: for some organizations the UN and OFAC lists are sufficient, while others need regional sanctions databases, debarment lists, and local registries. The NeuroVision AML module covers more than 1,700 sources — sanctions, PEP, lists of terrorists and extremists, adverse media, and reputational risks — and updates them daily, which rules out a false sense of protection due to outdated data.
We will analyze your set of jurisdictions, agree on the list of mandatory and recommended sources, and configure sensitivity thresholds taking into account the profile of your customer flow. Relevance scoring of matches is built into the module and reduces the share of false positives before the manual review stage. The service availability SLA is 99.99%, and the average API response time is under a second.
What to Move to Ongoing Monitoring
Not all AML checks make sense at the onboarding stage. Some of them require data that appears only after the start of service, and an attempt to perform them synchronously does not increase security but slows down the process.
Transaction monitoring is the main candidate for being moved out of onboarding. Before the first operation there is nothing to analyze: the customer’s behavioral profile is not formed, there is no historical data. Transaction monitoring is launched after the account is activated and works continuously, identifying deviations from the expected profile: structuring of amounts, atypical counterparties, sharp changes in turnover. This layer relates to KYT (Know Your Transaction) and requires streaming data processing rather than a one-time check.
Adverse media checks (negative mentions in the media and open sources) allow asynchronous execution. Their result usually does not block onboarding. Launching them in parallel with the completion of registration makes it possible to obtain the data within a few minutes after access is granted and, if necessary, initiate a manual review.
Periodic data updates and re-assessment of the risk level are ongoing-monitoring tasks by definition. According to current requirements, data on high-risk customers is updated at least once a year, and on low-risk customers once every three years. A review of the risk profile is also initiated by events: when sanctions lists change, when a customer or associated persons appear in new lists, when suspicious operations are identified.
The architecture of AML checks is distributed across two loops. The first is synchronous and blocking: sanctions screening, PEP, terrorist lists, UBO identification, and the preliminary risk assessment. The second is asynchronous and continuous: transaction monitoring, adverse media, periodic data updates, notifications when statuses change. Such a division makes it possible to fulfill regulatory requirements in full without overloading the entry point and while keeping onboarding speed at a level acceptable for digital services.
How to Embed AML and Sanctions Screening into KYC Onboarding
Sanctions screening and KYC verification solve different tasks but work with the same input data. If these processes are implemented as isolated systems, the customer is forced to enter the same information twice, and the business spends resources on repeat requests and reconciling results. The task of the onboarding architect is to link both loops into a single pipeline, where data is transmitted between modules automatically and the final decision is composed of the results of all checks without additional delays.
The FATF Recommendations and the requirements of Federal Law 115-FZ assume that customer identification and the assessment of AML/CFT risks are performed as parts of a single due diligence (CDD) process. A gap between them creates not only a technical but also a regulatory vulnerability: if a significant amount of time passes between the completion of KYC and the launch of the AML check, the organization effectively admits the customer to the service without a full risk assessment.
Which Data to Pass from KYC Without Re-Entry
At the KYC stage, the system already collects and verifies a set of data sufficient to launch sanctions screening. There is no need to request it from the customer again — it is enough to pass the normalized fields from the KYC module to the AML loop.
The minimum set for screening against most sanctions databases and PEP lists: full name (including Latin transliteration if the document contains an MRZ), date of birth, citizenship, country of document issue, document number. These fields are extracted during document recognition via AI-OCR and have already passed validation — repeat manual entry will only increase the likelihood of errors and discrepancies.
For extended screening and context assessment, it is useful to pass additional attributes: country of residence (if it differs from citizenship), registration address, INN or a similar identifier, as well as device and geolocation metadata obtained during the KYC session. These signals allow the AML system to more accurately determine jurisdictional risks and reduce the number of false matches — for example, when a common name matches an entry in a sanctions list but the country and date of birth do not confirm the connection.
A fundamental condition is the normalization of data before transmission. Names are brought to a single format (without abbreviations, taking into account the «surname — first name — patronymic» order and alternative spellings), dates to ISO 8601, countries to ISO 3166 codes. Without this step, the fuzzy-matching algorithm on the AML module’s side will generate an excessive number of alerts or, conversely, miss real matches due to format discrepancies.
Matching accuracy in the AML loop directly depends on the quality of the input data: discrepancies in the formats of names, dates, and country codes lead either to an avalanche of false alerts or to missing real matches. In the NeuroVision platform, normalization is built into the architecture — AI-OCR extracts the document fields, including the machine-readable zone, brings names and dates to a single standard, and automatically passes the result to the AML module together with the data of the biometric verification and liveness check.
We will design the KYC–AML linkage so that the customer goes through a single scenario without re-entry, while the orchestrator aggregates the results of both loops into a single decision. The platform supports more than 10,000 document types from 200+ countries in 90+ languages — the data is normalized at the recognition stage rather than manually before screening. Deployment is possible in the cloud, within your secure environment, or in a hybrid format, and integration is performed via REST API.
At Which Point to Launch Screening
The optimal moment is immediately after the KYC module has confirmed the authenticity of the document and extracted the data, but before the final decision on the success of onboarding is made. In practice: the document is recognized, the fields are extracted and validated, the biometric comparison (selfie with the document photo) and the liveness check are passed — and at this moment the normalized data is passed to the AML loop.
Such placement in the pipeline gives two advantages. First, screening works with already-verified data rather than «raw» user input, which increases matching accuracy. Second, by the moment the AML check is launched, the system has already weeded out obvious fraud (forged documents, deepfakes, repeat attempts), and the AML module processes only customers who have passed the basic trust threshold.
The choice between synchronous and asynchronous execution depends on the acceptable response time and the risk profile of the flow. With the synchronous scheme, AML screening is performed within the main onboarding session: the customer waits for the result but receives the final decision in a single pass. If the provider ensures a response time of under one second, the user experience practically does not suffer. With the asynchronous scheme, the customer is given a preliminary status («documents accepted, verification is being completed»), while screening is performed in the background — this is appropriate for low-risk segments where the regulator allows the start of limited service before the completion of the full check.
The FATF risk-based approach allows differentiation: for customers from higher-risk jurisdictions, PEP candidates, and operations above the thresholds of Federal Law 115-FZ, it is advisable to perform screening synchronously and before granting any access. For the standard flow from low-risk jurisdictions, an asynchronous model with a strict SLA for completing the check is acceptable — for example, no more than 30 minutes.
How to Combine AML Results with the KYC Decision
The KYC module and the AML loop return results in different formats: the former — a verification status and trust score (the document is genuine, the face matched, liveness passed), the latter — a list of matches with risk databases and their relevance. To turn two sets of data into a single decision, an orchestration layer with transparent routing logic is needed.
The basic decision-making model is built as a matrix. If KYC is passed and AML screening revealed no matches — the customer is approved automatically. If KYC is passed but a match is recorded — the case is routed to manual review by a compliance officer, and the customer is given a pending status. If KYC is not passed (a forged document, a biometric mismatch) — the process is terminated regardless of the AML results, since without a confirmed identity, further checks lose their meaning.
In practice, it is more effective to work not with binary statuses but with numerical scores. Each module assigns the session a score: the KYC score takes into account document quality, the confidence of the biometric match, and the result of anti-fraud checks; the AML score reflects the degree of relevance of the matches, the number of lists affected, and the risk level of the jurisdiction. The orchestrator aggregates both scores and applies rules configured for the policy of the specific organization: thresholds for automatic approval, automatic rejection, and the manual-review zone.
The regulator and internal audit must see why a specific customer was approved, rejected, or sent to manual review. The orchestration layer is obliged to log not only the final status but also the input data, the intermediate results of each module, the applied rules, and timestamps. Such an audit trail is a requirement of Federal Law 115-FZ and the FATF Recommendations regarding the documentation of CDD procedures, not an optional convenience.
The technical implementation of the linkage is most often built through REST API: upon completing the check, the KYC module sends the results to the orchestrator, which passes the data to the AML loop, receives a response, and forms the aggregated decision. With this approach, each module remains replaceable, and the decision-making logic remains configurable without changing the code. For organizations that value speed, the entire cycle — from data transmission to the aggregated status — must fit within the acceptable onboarding SLA.
How to Review Matches Without Losing Speed
Sanctions screening at onboarding inevitably generates matches — alerts indicating the possible presence of a customer in sanctions lists, PEP registries, or adverse media databases. The problem is not the alerts themselves but their volume and quality. According to PwC, between 90 and 95% of all triggers in AML screening turn out to be false — the customer is not connected to a sanctioned person, and the match is caused by name similarity, transliteration, or the incompleteness of the identifying data in the list. Each such alert requires verification, and if the review process is not established, the queue for manual analysis paralyzes onboarding.
The task is not to eliminate matches completely (this would increase the risk of missing real threats) but to minimize the share of false positives before manual review, clearly route the remaining cases, and set transparent deadlines for closing them.
How to Reduce False Matches Before Manual Review
The main source of false positives is primitive fuzzy matching, in which the system assesses only the degree of character similarity of the customer’s name to entries in sanctions lists. The name «Mohamed Ali» can produce dozens of matches with different sanctioned persons, none of whom relate to the real customer.
The reduction of false matches happens in several layers, before an alert reaches an analyst.
| Category | Description |
|---|---|
| The first layer — data normalization and tokenization | Before comparison, the system cleans the input data: removes stop words (Ltd, OOO, Inc, Bank), breaks the full name into components, brings transliteration to a single standard. Without this step, the word «Bank» in a customer’s name will produce a match with every other entry in the OFAC list. |
| The second layer — the use of secondary identifiers | The more additional parameters participate in the comparison, the more accurate the filtering. Date of birth, country of citizenship, place of registration, INN or document number — each of these attributes makes it possible to weed out matches based only on name similarity. If the KYC process has already collected these data, they must be automatically passed to the AML module. |
| The third layer — adaptive thresholds and risk profiling | A single sensitivity threshold for all customers is a typical cause of overload. For customers from low-risk segments, a stricter trigger threshold is acceptable (a higher match percentage needed to generate an alert), while for high-risk ones a more sensitive one is used. Threshold calibration must rely on the statistics of past alerts: if a rule generates 98% false matches, this is a signal to revise the parameters rather than a reason to hire additional analysts. |
| The fourth layer — automatic resolution of obvious non-matches | The system is able to close some alerts without human involvement: when the customer’s date of birth differs from the list entry by decades, when the country of registration does not match, when the customer’s sex differs from the sex of the sanctioned person. Such auto-resolution rules are documented and periodically reviewed — the regulator assesses not the absence of alerts but the soundness of the methodology for handling them. |
Together, the four layers make it possible to reduce the flow of alerts sent to manual review several times over. Automating the primary filtering can lower the share of manual review to 10–20% of the total number of triggers provided the input data is of high quality and the rules are regularly calibrated.
When the flow of false matches overloads analysts, both onboarding speed and the quality of reviewing real cases suffer. The NeuroVision AML module uses relevance scoring of matches, comparing not only the name but also secondary identifiers — date of birth, citizenship, document number — which automatically arrive from the KYC loop. Up to 90% of checks are closed without operator involvement, and the built-in case management with an audit log and a chronology of actions records every decision for the regulator and internal audit.
We will configure the trigger thresholds and auto-resolution rules for your risk profile and the statistics of past alerts, and connect continuous monitoring with notifications when customer statuses change. Sources are updated daily, and the average automatic response time does not exceed one second — only those cases that genuinely require an analyst’s decision end up in the manual queue.
When to Move a Match into Case Management
Not every alert deserves a full-fledged investigation. Moving a match into a case is the moment when the system records: the automatic checks did not give an unambiguous answer, and an analyst’s decision with documented justification is required.
The escalation criteria depend on the organization’s policy but usually include three conditions. First: the name match is confirmed by at least one secondary identifier (the country or age range matches). Second: the customer falls into a high-risk category by type of activity, geography, or ownership structure. Third: the source of the match belongs to a category of heightened regulatory attention — OFAC, UN, EU sanctions lists, or national terrorist lists.
A case in the case-management system is a structured object with mandatory attributes: customer identifier, source of the match, results of the automatic check, risk level, assigned analyst, chronology of actions, and the final decision. Every action is recorded in the audit log — this is a direct requirement of regulatory frameworks, whether Federal Law 115-FZ, 6AMLD, or the FATF Recommendations.
Here it is fundamental to distinguish two scenarios. If a match is identified at the onboarding stage, the case is created in parallel with registration, and until it is closed, onboarding is suspended or completed with limited access to services. If a match is discovered during ongoing monitoring for an already active customer, the case does not automatically block current operations but may initiate enhanced due diligence (EDD) and temporary restrictions.
Organizations that do not formalize the criteria for moving an alert into a case face two extremes: either analysts are overloaded with cases, most of which are closed in minutes, or real matches are lost in the flow of unreviewed alerts. Both variants create regulatory risks.
How to Set an SLA for Disputed Cases
An SLA in the context of AML cases is an internal standard defining the maximum allowable time for each stage of the review: from case creation to the final decision. Without an SLA, cases accumulate, investigation timelines stretch out, and during an audit the regulator sees a backlog indicating the immaturity of the compliance program.
The SLA structure is tied to the risk level of the case. For high-risk matches (direct sanctions, a match on several identifiers) — an initial assessment within a few hours, a final decision within one to two business days. For medium risk (PEP, adverse media with ambiguous signals) — up to three to five business days for the full investigation cycle. For low-risk cases that ended up in manual review due to a borderline score — no more than five to seven business days.
Separately, an SLA for the initial response is fixed — the time from case creation to the moment an analyst takes it into work. If this interval exceeds a few hours for high-risk cases, the process needs improvement: there are not enough analysts or the prioritization system is working incorrectly.
When defining the SLA, regulatory deadlines should be taken into account. If an investigation confirms suspicious activity, the organization is obliged to file a report (SAR/STR depending on the jurisdiction, a report to Rosfinmonitoring in the Russian Federation) within the deadlines established by law — as a rule, no more than 30 calendar days from the moment of identification. The internal SLA for reviewing a case must leave a sufficient margin for preparing and filing the report.
Three practical principles for implementing an SLA. Automatic escalation: if a case is not closed within the SLA, it is automatically passed to the head of the compliance unit or the MLRO. Visual monitoring: a dashboard with the current status of cases, their distribution by deadline, and the share of overdue ones makes it possible to identify bottlenecks before they become a systemic problem. Regular review: once a quarter, the actual closing time, the share of overdue cases, and the causes of delays are analyzed, and the standards and resources are adjusted.
Fixed SLAs turn the review of matches into a measurable and manageable process. For the customer this means predictable onboarding timelines even in the presence of matches. For the regulator it is proof that the organization controls its compliance processes and responds to risks in a timely manner.
How to Measure the Impact of AML on Onboarding Speed
AML checks protect the business from regulatory sanctions and financial losses, but at the same time they create an additional step in the customer journey. If you do not track how screening affects time and conversion, it is easy to fall into one of two traps: weakening controls for the sake of speed or losing customers for the sake of formal compliance. The solution is to fix a set of metrics that will show the real state of the process and point to the spots requiring adjustment.
Each metric is tied to a specific stage of the funnel — from the first request to the issuance of the final decision. What needs to be measured is not «the work of the AML module in isolation» but its contribution to the overall onboarding cycle.
First Response Time and Time to Final Decision
To assess the speed of AML screening, it is useful to separate two indicators: the time to the system’s first response (FRT, first response time) and the time to the final decision (TTD, time to decision).
FRT records how many seconds it takes the AML system to return the result of the automatic check — matches against lists, PEP status, adverse media. In solutions with API integration, the benchmark is under one second. Some platforms process requests in 60–250 milliseconds under high load. If FRT exceeds 2–3 seconds, this is already noticeable to the user and can provoke abandonment of registration, especially in mobile scenarios.
TTD accounts for the full cycle: the automatic check, review of matches (if any), manual verification, and the issuance of the final decision. For customers without matches, TTD practically coincides with FRT — the decision is made instantly. For cases with matches, TTD depends on the SLA for manual review and the complexity of the case. The gap between FRT and TTD is the main indicator of bottlenecks: if the automatic response arrives in half a second but the final decision takes hours or days, the problem is not in the screening but in the operational review process.
On the dashboard, it is worth tracking the median and the 95th percentile of FRT, the median and the 95th percentile of TTD, as well as a breakdown of TTD by result type: «clean» (no matches), «automatically resolved» (a match rejected by the algorithm), and «manual review». Percentiles are more informative than average values, since they show the delay customers in the «tail» of the distribution encounter.
The Share of Manual Review and the Share of False Matches
Two related indicators determine the operational load on the compliance team: the manual review rate (the share of cases going to manual review) and the false positive rate (the share of matches that turned out to be false).
The manual review rate shows what percentage of checks cannot be closed automatically. The higher the indicator, the more strongly AML affects the overall onboarding time: each manual case is a queue, waiting time, and the risk of losing a customer. In mature systems, the benchmark is automatic closure of up to 90% of checks without operator involvement. If the share of manual review exceeds 20–25%, it is worth revising the screening settings: fuzzy-matching thresholds, the use of secondary identifiers (date of birth, country, INN), stop words, and tokenization.
The share of false matches is an indicator of the accuracy of the system’s configuration. A false match occurs when the algorithm signals a match with a sanctions list or PEP database, but the review reveals that it is a different person or organization. According to PwC and a number of industry studies, the share of false positives in AML screening reaches 90–95%, and their manual review consumes a significant part of the operational costs of compliance. Reducing the false positive rate by even 30–40% through fine-tuning the matching algorithms, data normalization, and contextual filters can cut the queue processing time many times over.
These metrics work in pairs: if the false positive rate decreases, the manual review rate decreases too, and along with them TTD. A regular audit of false matches (which names, which lists, which algorithms cause the most noise) makes it possible to continuously improve screening quality without weakening controls.
Conversion After the AML Check
The final and most telling metric is conversion: what percentage of customers who passed the AML screening stage reach the completion of onboarding. This indicator links compliance with the business result and makes it possible to assess the real «cost» of the AML check in terms of customer acquisition.
Conversion after the AML step should be counted separately from the overall onboarding conversion. The overall funnel includes many stages (document upload, biometrics, liveness, form filling), and a drop at any of them masks the impact of a specific step. The isolated metric «passed AML — completed registration» shows how many customers are lost specifically at the compliance-check stage.
The causes of losses fall into two categories. The first is delays: the customer leaves without waiting for the result of the manual review. According to industry research, if the account-opening process takes more than 3–5 minutes, the drop-off rate can exceed 50%. The second is rejections: the customer receives a rejection based on the screening results. The levers of influence for them are different: delays are solved by speeding up the process, rejections by the correctness of the data and the adequacy of the thresholds.
For a complete picture, it is useful to compare conversion across three segments: customers who passed screening automatically (a fully automatic path); customers who ended up in manual review and waited for the decision; customers who ended up in manual review and left before receiving the result. The gap between the first and third segments is a direct assessment of the losses caused by insufficient automation.
The conversion gap between the fully automatic path and the manual-review segment is a direct indicator of losses caused by delays in AML screening. If some customers leave without waiting for a decision, the problem is most often not the screening itself but the share of cases that reach an analyst. The NeuroVision platform processes a request in under a second, and the automation of screening and case management makes it possible to close up to 90% of checks without operator involvement — this reduces the manual load on the compliance team by up to 80%.
We will review your current process — from the moment data is passed to screening to the final decision — and propose a configuration that will reduce the full-cycle time for the standard flow. Integration of the AML module via REST API takes 1–2 days, and deployment is possible in the cloud or within your environment. You will receive measurable benchmarks for FRT, the share of automatic approval, and conversion after each stage of the funnel.
All the listed metrics — FRT, TTD, manual review rate, false positive rate, and conversion after AML — are tracked regularly and over time. A one-time measurement is useful for diagnostics, but the real value comes from monitoring trends: how changes in screening settings, list updates, or growth in application volume affect each indicator. This approach makes it possible to find the balance between onboarding speed and compliance reliability not intuitively but on the basis of data.
Speed and compliance stop conflicting when sanctions screening is designed as part of the KYC pipeline rather than as a separate barrier after it. Dividing the checks into a synchronous blocking loop and asynchronous monitoring, automatically passing normalized data from KYC to the AML module, multi-layered filtering of false matches, and clear SLAs for case review — these architectural solutions make it possible to fulfill the requirements of Federal Law 115-FZ and the FATF Recommendations while keeping the automatic response time within a second and preserving conversion at every stage of the funnel.
The resilience of the model is determined not by a one-time configuration but by regular measurement: FRT, TTD, the share of manual review, the false positive rate, and conversion after the AML step show where the process works normally and where operational pressure accumulates. Companies that track these metrics over time and calibrate screening thresholds based on real statistics gain a manageable compliance process — predictable for the customer, transparent for the regulator, and scalable along with the growth of the user base.
