Fintech Compliance Under Federal Law 115-FZ: How to Build a KYC and AML Loop Without Overloading the Team

How to Determine the Minimum Composition of the Loop Under Federal Law 115-FZ

A fintech company that accepts payments, issues loans, or conducts operations with digital assets is obliged to fulfill the requirements of Federal Law No. 115-FZ «On Countering the Legalization (Laundering) of Proceeds of Crime and the Financing of Terrorism». The law applies to credit and non-credit financial organizations, payment aggregators, microfinance companies, operators of digital platforms, and a number of other entities listed in Articles 5 and 7.1.

Before connecting specific services, it is necessary to fix the boundaries of the loop: which checks the law requires, from which sources to obtain data, and which events to document. Without this framework, automation turns into a set of disparate integrations — expensive to maintain and vulnerable during an audit by Rosfinmonitoring or the Central Bank.

Which Checks and Decisions to Enshrine in the Internal Control Rules

The basis of the loop is the internal control rules (ICR). The law obliges every entity under Federal Law 115-FZ to develop and approve ICR and then to regularly update them when legislation changes. Since 2025, the requirements for the composition of the ICR have expanded significantly: in addition to countering money laundering and terrorism financing, the document now includes sections on countering the financing of extremist activity (CFE) and the financing of the proliferation of weapons of mass destruction (CFP). Resolution of the Government of the Russian Federation of 02.08.2025 No. 1157 defines the current requirements for the structure of the ICR for organizations not supervised by the Central Bank; for supervised ones, the regulations of the Bank of Russia apply.

The minimum set of programs within the ICR includes several mandatory blocks.

The identification program describes the procedure for establishing the identity of the customer, their representative, beneficiary, and beneficial owner. For an individual, the following are recorded: full name, date of birth, details of the identity document, INN (if available), registration or residence address. For a legal entity — the name, OGRN, INN, address, information about founders and ultimate beneficiaries with an ownership stake of over 25%. The program determines in which cases simplified, standard, or in-depth identification is applied depending on the customer’s risk level.

The risk-assessment program sets the criteria for assigning a customer a degree of risk: low, medium, or high. The criteria rely on the customer type, country of registration or residence, nature of activity, source of funds, public status (PEP — a politically exposed person), and the history of the relationship. A risk-based approach makes it possible to direct the team’s resources toward customers with an elevated risk profile and, for low-risk ones, to reduce the volume of checks to the minimum permitted by law.

The program for identifying operations subject to mandatory control and operations with signs of a connection to money laundering or terrorism financing records the thresholds, types of operations, and signs of unusual transactions. The list of operations subject to mandatory control is set by Article 6 of Federal Law 115-FZ and supplemented by Rosfinmonitoring orders. The base threshold for most operations from the Article 6 list is 1 million rubles, but for certain categories (leasing operations — 600 thousand rubles, state defense orders — 10 million rubles, operations with precious metals and stones — 1 million rubles as of August 2025) the thresholds differ. The signs of unusual transactions were approved by the Rosfinmonitoring order of 08.05.2009 No. 103 and are periodically updated.

The program of actions upon refusal to execute a customer’s order describes the procedure for making a decision to refuse to conduct an operation and to notify the customer.

The staff preparation and training program defines the frequency and format of employee training, including introductory and additional briefings when legislation changes. Organizations are obliged to appoint a special official (SDL) responsible for implementing the ICR and meeting the qualification requirements.

When designing the KYC/AML loop, each of these programs is translated into a set of automated checks: which data to collect at onboarding, by which rules to assign a risk profile, under which conditions to block an operation or send a case to manual review.

The more precisely the ICR describe the decision logic, the easier it is to implement that logic in code and the fewer gray zones remain for the compliance officer.

Which Data and External Sources the Loop Needs

The loop works with two flows of information: data provided by the customer themselves and data the system obtains from external sources for verification and enrichment.

From the customer come questionnaire information and documents. For an individual — a scan or photo of the passport (the pages with the photograph and registration), a selfie for biometric verification, contact details. For a legal entity — constituent documents, an extract from the Unified State Register of Legal Entities (EGRUL), information about beneficial owners, documents confirming the representative’s authority. The law allows obtaining some data electronically if the organization ensures its authenticity and integrity.

External sources are divided into mandatory and additional. The mandatory ones include lists whose reconciliation is directly provided for by law: the list of persons involved in extremist activity or terrorism (maintained by Rosfinmonitoring), the list of persons involved in the proliferation of WMD (the UN Security Council), as well as lists under the decisions of the Interagency Commission on Countering the Financing of Terrorism. Reconciliation against these lists is conducted during identification and on an ongoing basis — with each update of the lists.

The sources needed for full-fledged identification and risk assessment include: the Ministry of Internal Affairs database of invalid passports, the Federal Tax Service registries (for checking the INN, the status of a legal entity, mass addresses and directors), the Federal Bailiff Service (for identifying debts and enforcement actions), the bankruptcy registry, sanctions lists — both Russian and international (UN, OFAC, EU, HMT/OFSI, and others depending on the customers’ jurisdiction). For fintech companies working with cross-border transfers or cryptocurrency, the set of international sources expands.

Additional sources depend on the risk appetite and business model: verification of the full-name–phone and full-name–email links, credit bureau data, arbitration and court cases, a check for PEP status, screening for negative mentions in the media and open sources (adverse media). The more sources connected to the loop, the higher the accuracy of the risk assessment and the fewer false positives, but each source increases the cost of the check and the response time. The optimal strategy is to connect sources in a cascade: mandatory reconciliations for all customers, extended ones only in the case of elevated risk or when deviations are detected at previous stages.

The technical implementation involves API integration with each source. In practice, fintech companies use one or several providers that aggregate access to dozens of registries through a single interface. This reduces the number of integrations and simplifies updating when sources change.

Which Events and Decisions the Loop Is Obliged to Record

Federal Law 115-FZ establishes the obligation to document information and store it for no less than five years from the moment the relationship with the customer ends. Not only the final decisions but also the intermediate steps that led to them are subject to recording.

From an architectural standpoint, these requirements translate into several components: a full audit log of all actions by the system and the operator, versioning of the rules and decision-making models (so that the logic of a decision can be reproduced as of the date it was made), a repository of documents and questionnaires with integrity control, and a module for generating and sending FEMs.

Recording must happen automatically at the moment of the event rather than after the fact. A gap between performing an action and documenting it is one of the typical complaints of the regulator during an audit. A loop in which every step generates an entry in the log reduces this risk and allows the compliance team to focus on substantive analysis rather than on filling out reports by hand.

How to Build a KYC Loop at Onboarding

A KYC loop at onboarding is a chain of automatic steps from the moment the customer opens the registration form to the decision: verified, rejected, or sent to manual review. The task of the loop is to collect the minimum necessary data, verify its authenticity, and assess the risk, staying within the framework of Federal Law 115-FZ and not losing the user halfway.

By law, identification must be completed before the start of servicing the customer — even for a one-time operation. Since July 11, 2025, the Rosfinmonitoring order of 23.04.2025 No. 74 has been in effect, which replaced the former orders No. 100 and No. 355 and clarified the requirements for the composition of identification data, the check against lists, and the recording of results in the questionnaire. For fintech, this means: the loop must collect the full set of information, check it against the mandatory lists, assign a risk group, and save an audit trail of each step — all of this preferably without operator involvement.

A KYC loop for fintech consists of three layers: data collection (documents and questionnaire), authenticity verification (document, face, signs of substitution), and decision-making (automatic or a route to a compliance officer).

Collecting the Questionnaire and Documents Without Manual Entry

The classic approach — asking the customer to fill out a questionnaire and upload a passport scan — leads to entry errors, low conversion, and an additional load on operators who reconcile the data manually. Automation begins with replacing manual entry with AI-OCR and built-in SDKs for document capture.

The AI-OCR engine accepts a photograph or video stream from the device camera, determines the document type (Russian passport, international passport, driver’s license, residence permit, and others), extracts the text fields (full name, date of birth, series and number, registration address, MRZ), and normalizes them into structured JSON. The customer questionnaire is formed automatically: the fields are filled in based on the recognized data. The customer sees a prefilled form and confirms its correctness — this is faster and more accurate than filling it out from scratch.

For a fintech company, the time of this stage is critical. Modern OCR platforms recognize a document in under a second with a field-extraction accuracy of 99% and above for printed text. For handwritten fields (for example, the registration address in a Russian passport), accuracy is usually lower — around 97–98%, and here it is important to choose a solution specializing in specific document types and languages.

What to pay attention to when choosing the OCR layer:

— Coverage by document types and countries: if the fintech works with non-residents, support for a wide set of ID documents is needed;

— The presence of SDKs for mobile platforms (iOS, Android) and a web widget, so that image capture happens inside the application rather than through file upload from the gallery;

— Image quality control before sending to the server: the SDK must prompt the user that the photo is blurry, cropped, or shot in poor lighting, otherwise the rejection rate at this step will grow;

— The ability to deploy in a secure environment (on-premises or private cloud) if regulatory requirements or the security policy do not allow transmitting document scans to an external server.

The collected data is supplemented by checks against external sources — the next mandatory step of identification under Federal Law 115-FZ. The loop automatically requests confirmation of the full-name–passport link, obtains the INN by full name and document details, checks the validity of the passport, self-employed status, and other parameters depending on the business logic. The results of these checks are recorded in the questionnaire and become part of the audit trail.

Verifying the Document, the Face, and Signs of Substitution

Data extraction is a necessary but insufficient step. The loop is obliged to ensure that the document is genuine, that the customer’s face matches the photograph in the document, and that a live person is in front of the camera rather than a photograph, video recording, mask, or deepfake.

Document authenticity verification includes several levels. The first is structure validation: the correctness of field placement, the presence of mandatory zones, the correspondence of fonts and sizes to reference templates. The second is integrity verification: the search for traces of editing, inconsistencies in the color model, artifacts of paste-in or retouching. The third is cross-validation: the MRZ is reconciled with the data from the document’s visual zone, and the checksums are verified algorithmically. Platforms with wide coverage use dozens of specialized algorithms for this, forming a document trust score.

Biometric verification is the comparison of the customer’s selfie with the photograph from the document (1:1 mode, face matching). Modern face verification algorithms achieve an accuracy above 99.7% with a false match rate at the level of one per million comparisons. The metric depends on the dataset and shooting conditions: camera quality, lighting, and head-tilt angle affect the result. The client-side SDK must control the capture conditions and guide the user (turn the head straight, remove the shadow, take off glasses).

A separate layer is the liveness check (Presentation Attack Detection, PAD). It determines whether a live person is in front of the camera or a substitution is being used. The types of attacks the loop must protect against:

— Presenting a printed photograph or the screen of another device showing an image;

— Playing back a pre-recorded video;

— Using silicone or 3D masks;

— Real-time deepfakes (face swap via tools like DeepFaceLive), when a generative model overlays a synthetic face on top of the attacker’s video stream;

— Injection attacks, in which a forged image or video is fed into the verification system while bypassing the device camera, directly into the software channel.

Passive liveness analyzes micro-signals in a single frame or a short series: skin texture, glare, depth, micro-movements. Active liveness asks the user to perform a random action — turn the head, blink, smile — and assesses the naturalness of the response.

The most resilient solutions combine both methods and supplement them with a device integrity check: they verify that the video stream comes from a real camera rather than a virtual source.

For fintech companies building a KYC loop under Federal Law 115-FZ, liveness is a mandatory element of protection against fraudulent registrations. Without it, the loop lets through synthetic identities and accounts opened using stolen documents with face substitution. The cost of a missed fraudster for fintech is direct losses, the risk of regulatory sanctions, the loss of a banking partner, and reputational damage.

Rules for Automatic Decisions and the Route to Manual Review

The collected data and the results of the checks must lead to a decision. In an established KYC loop, it is made automatically for the overwhelming majority of applications and is passed to manual review only in disputed cases.

The automatic decision is formed on the basis of an aggregated score that takes into account the results of each step: document recognition (quality, authenticity, completeness of data), biometric comparison (the face-match score), liveness (pass/fail and confidence level), checks against lists (sanctions lists, the Rosfinmonitoring list of terrorists and extremists, UN Security Council lists, PEP), as well as the results of external requests (passport validity, INN, Federal Bailiff Service, and others). Each parameter is given a threshold value, and the combination rules are configured in the loop’s configuration.

The typical routing logic is arranged as follows. If all checks are passed, the scores are above the threshold values, and no matches against lists are found — the customer is verified automatically (Straight-Through Processing, STP). If one or several scores fall into the «gray zone» (for example, the face score is between 75 and 90% at an automatic-approval threshold of 90%) — the application is routed to manual review by a compliance officer. If critical signs are detected (document forgery, a match against a sanctions list, a liveness failure) — the application is rejected automatically.

The share of automatic decisions (STP rate) is a key metric of the loop’s effectiveness. For mature KYC systems, the target benchmark is 85–95% of applications processed without operator involvement. The remaining 5–15% end up in the manual review queue. If the share of manual cases consistently exceeds 20%, this is a signal: the thresholds are configured too strictly, the OCR or liveness module generates an excessive number of uncertain results, or the flow contains systematic problems — for example, poor photo quality among a certain customer segment.

Configuring the thresholds is an iterative process. At the start, they are calibrated based on the results of a pilot on a limited sample, then revised as statistics accumulate. Key metrics for calibration: the false rejection rate (FRR — legitimate customers who are erroneously rejected), the false acceptance rate (FAR — fraudsters who passed the check), and the average time to decision. The balance between FRR and FAR determines how acceptable the loop is from the standpoint of both the business and the regulator.

For manual review, the loop must provide the operator with the full context: the source images of the document and the selfie, the extracted data, the results of each check with an indication of the reasons for entering the manual route, the history of the customer’s previous attempts (if any), and related records in the database. The operator confirms or rejects the application, and their decision and justification are recorded in the action log. This record becomes part of the audit trail that the loop is obliged to store and present upon the regulator’s request.

The entire scenario — from uploading the document photograph to the final decision — must take the customer no more than one or two minutes when passing automatically. An increase in this time directly affects onboarding conversion: according to industry data, each additional step or screen in the verification process reduces the share of those who complete registration by 5–15%. For fintech, where the cost of acquiring a customer can amount to hundreds of rubles, optimizing the KYC funnel is a matter not only of compliance but of the product’s economics.

How to Build an AML Loop

A KYC check at onboarding records who is in front of you. The AML loop is responsible for something else: whether the customer falls under restrictions, what their real risk profile is, and what happens with their operations after the account is opened. KYC is an entry filter; AML is a continuously operating surveillance system throughout the entire lifecycle of the customer relationship.

By the logic of Federal Law 115-FZ, the AML loop solves three connected tasks: the initial screening of the customer against lists and the assignment of a risk level, continuous monitoring of operations with a status review when circumstances change, as well as closing incidents and submitting information to Rosfinmonitoring within the established deadlines.

List Checks and the Customer Risk Profile

The first step of the AML loop is automatic reconciliation of the customer’s data against mandatory and additional lists. The mandatory minimum under Federal Law 115-FZ includes three lists: the list of persons involved in extremism and terrorism (formed by Rosfinmonitoring), the list of the Interagency Commission on AML/CFT/CFP, and the list of persons involved in the proliferation of weapons of mass destruction. Reconciliation is conducted not once — with each update of a list, the organization is obliged to check the entire customer base and, in the event of a match, immediately apply measures to freeze funds.

In practice, limiting oneself to the three mandatory lists is risky. A fintech company working with international payments or customers from different jurisdictions needs screening against the sanctions lists of the UN, OFAC (including SDN, SSI, NS-CMIC), the EU, the UK (HMT/OFSI), as well as the national lists of countries of presence. A check for PEP status and analysis of the negative media background (adverse media) deserve separate attention — these categories do not prohibit service but substantially raise the risk level and require enhanced due diligence.

The key technical problem is false matches. When reconciling against hundreds of sources, the system inevitably generates a mass of triggers due to partial name matches, transliteration, common surnames. Without a mechanism for assessing the relevance of matches (fuzzy matching with configurable thresholds, accounting for additional identifiers — date of birth, country, INN), the manual review queue will overflow on the very first day. A high-quality AML module must rank matches by degree of reliability and automatically reject irrelevant ones — this makes it possible to reduce the manual screening load by 70–80%.

Based on the screening results and questionnaire data, the loop assigns the customer a risk level. Federal Law 115-FZ obliges organizations to distribute customers into groups by the risk of committing suspicious operations and to apply the corresponding set of measures to each group. The typical model provides for three levels: low (standard procedures, data update at least once a year), medium (extended verification of documents, sources of funds, more frequent review), and high (in-depth verification, management approval, enhanced monitoring of operations). The organization itself defines the criteria for assignment to groups in the ICR, but the benchmarks are set by the recommendations of the Bank of Russia and the typologies of Rosfinmonitoring.

The risk profile is not a static label. It is recalculated when new data arrives: a change of jurisdiction, appearance on sanctions lists, atypical activity, negative publications. A loop that assigns risk once and does not review it does not comply with the requirements of the law and creates a vulnerability for the company.

Transaction Monitoring and Customer Status Review

After onboarding, the AML loop switches to continuous monitoring mode. Its task is to identify operations subject to mandatory control (Article 6 of Federal Law 115-FZ) and operations with signs of suspiciousness (Article 7).

Subject to mandatory control are operations whose amount is equal to or exceeds the established threshold and which belong to certain types: withdrawal or deposit of cash to a legal entity’s account, transfers in favor of non-residents, real estate transactions, and a number of others. The base threshold for most categories is 1 million rubles; for leasing operations — 600 thousand rubles; for real estate transactions the threshold is set by a separate Rosfinmonitoring order and cannot be lower than 5 million rubles. The list is regularly expanded — since 2025, operations with digital assets have come under control, and requirements for the jewelry industry have been tightened. For operations subject to mandatory control, the law requires documentary recording and the submission of information to Rosfinmonitoring no later than three business days after the operation.

Suspicious operations are a more complex category. There is no fixed amount threshold here. The loop must identify deviations from the customer’s usual behavior, signs of payment structuring (breaking up large sums), transactions with high-risk jurisdictions, atypical schemes of fund movement. For this, rules (rule-based logic) and, at a more mature level, behavioral models are used, analyzing the totality of signs of each transaction: amount, frequency, counterparties, geography, time, deviation from the customer profile.

The practical minimum for a fintech company is a set of configurable monitoring rules covering the Rosfinmonitoring typologies (they are published in information letters and on the agency’s website). Each rule sets a trigger condition, a threshold, and an action: automatic blocking, routing to the compliance officer’s queue, or recording for further analysis. The more precisely the rules are configured, the fewer false positives and the faster the team handles real incidents.

Reviewing the customer’s status is a mandatory part of ongoing monitoring. If a customer appears on an updated list, their operations systematically trigger alerts, or new circumstances are identified (a change of beneficiary, negative publications), the loop is obliged to initiate a review of the risk profile. Upon transition to the high-risk group, enhanced measures are applied: a request for additional documents, restriction of certain operations, escalation to the management level. In certain cases, the organization has the right to refuse to conduct an operation or terminate the contract, notifying Rosfinmonitoring.

For customers not classified as low-risk, the law requires updating information at least once a year, and when doubts arise about the reliability of the data — within seven business days. The loop must automatically track the update deadlines and generate tasks for the responsible specialist.

How to Close an Incident and Submit Information to Rosfinmonitoring

The deadlines for submitting information are strictly regulated. For operations subject to mandatory control — no later than three business days after the operation. For suspicious operations — no later than three business days after identification. For suspended operations — immediately. Violation of the deadlines entails administrative liability under Article 15.27 of the Code of Administrative Offenses of the Russian Federation: for officials — a fine of up to 50 thousand rubles, for legal entities — up to 500 thousand rubles or administrative suspension of activity for up to sixty days; in the case of repeated and gross violations, disqualification of the manager is possible.

Technically, the submission is carried out through the personal account on the Rosfinmonitoring website in the format of formalized electronic messages (FEM). Each message is signed with an enhanced qualified electronic signature and contains structured data: information about the operation participants (including the beneficial owner), the characteristics of the operation, the grounds for sending the message. There are several types of FEM depending on the type of event — for mandatory control, for suspicious operations, for informing about schemes of suspicious activity, and other cases.

A mature AML loop generates a draft FEM automatically based on the data from the incident card. The compliance officer checks its completeness, supplements it if necessary, and sends it. This is critically important for meeting deadlines: with a large flow of alerts, manually filling out each message from scratch consumes hours of working time and increases the risk of error.

All materials on operations for which information was submitted to Rosfinmonitoring, as well as customer identification documents, must be stored for no less than five years from the moment the relationship with the customer ends. The loop provides access to these data for internal audit and regulator inspections — with a full audit log of actions that makes it possible to reconstruct the chronology of every decision.

When designing the AML loop, it is worth building in the ability to adapt to changes from the outset. Federal Law 115-FZ is one of the most frequently updated federal laws: from mid-2025 to March 2026 alone, more than ten amendments took effect, expanding the list of entities subject to control, changing the threshold values for certain categories of operations, and updating the requirements for the ICR. Rosfinmonitoring regularly issues new orders, information letters, and typologies. A loop in which updating the rules and sources requires involving developers will systematically lag behind the regulatory framework — and therefore create legal and financial risk for the company.

How Not to Overload the Team

A compliance loop under Federal Law 115-FZ generates a flow of alerts, each of which requires an operator’s attention. The more customers and operations pass through the system, the faster this flow grows — and the higher the risk that the team will start missing real threats, immersed in reviewing false matches. The task is not to hire more people but to ensure that only those cases that genuinely need human judgment reach the operator.

Three directions make it possible to keep the load within manageable limits: reducing the volume of false positives, transparent accounting of the case queue, and regular calibration of rules.

How to Suppress False and Repeat Triggers

The main source of overload is false positive alerts. In classic rule-based monitoring systems, their share reaches 95–99%: the system finds a name match with a sanctions list, although it is a different person with a similar spelling. The compliance officer is forced to open the card, check the context, record the decision — and so on hundreds of times a day.

The share of false positives can be reduced at several levels.

Precise tuning of fuzzy-matching thresholds. Fuzzy-matching algorithms are inevitable: data arrives with typos, in different transliterations, with abbreviations. The sensitivity threshold needs to be calibrated separately for each type of list and category of customers, and then revised as the statistics of reviews accumulate. Too soft a threshold produces a barrage of matches, too strict a one misses real hits.

Context enrichment during screening. A match on a single field (name) is a weak signal. If the system simultaneously reconciles the date of birth, citizenship, INN, or another unique identifier, most false hits are weeded out automatically. The more attributes participate in assessing the relevance of a match, the fewer cases go to manual review. In the NeuroVision AML module, relevance scoring of matches is implemented as a standard function: the system reconciles a set of features and gives the operator a weighted score with reasons, which makes it possible to reduce the manual load by up to 80%.

Suppression of repeat triggers. If an operator has already reviewed a case and recorded a «false positive» decision — a repeat alert for the same customer and the same list must not enter the queue again. For this, a decision identifier is recorded in case management: during the next screening, the system checks whether a similar review took place and suppresses the duplicate alert. The suppression must be automatically lifted when the customer’s data changes or the source is updated — otherwise a compliance risk arises.

ML models for prioritization. Machine learning on the historical data of reviews makes it possible to rank alerts by the probability of a real match. The model takes into account the pattern: which combinations of features more often turned out to be false and which were confirmed. This does not replace the operator but changes the order of review: the most probable true positives rise to the top of the queue, while typical false positives go down or are closed automatically with a record in the log.

How to Measure the Case Queue and the Compliance Load

It is impossible to manage a load if it is not measured. A compliance unit in fintech needs the same operational metrics as any service with a task queue — but adjusted for regulatory deadlines.

Key indicators worth tracking on a dashboard.

The queue size (backlog) — the number of open cases awaiting review. If the queue is steadily growing, the team’s current capacity cannot cope with the flow. It is useful to track not only the absolute number but also the age of the oldest case: if it is approaching the regulatory deadline, this is a critical situation.

The average case closing time shows how long the review lasts from the moment an alert appears to the recording of the decision. Variation is normal: a screening false positive is closed in minutes, while an investigation of a suspicious operation can take days. The metric is better segmented by case type — screening, transaction monitoring, risk-profile review.

The share of automatic closures — the percentage of cases the system closes without operator involvement (an automatic false positive, duplicate suppression, automatic approval by a risk rule). The indicator directly reflects the effectiveness of the loop’s configuration. For mature systems, the benchmark is 80–90% of cases without manual intervention.

Operator throughput — the number of cases closed by one operator per shift, broken down by type and complexity. The metric helps forecast at what growth of the customer base the current staff will stop coping and to plan either hiring or additional automation.

All the listed indicators are available through the platform’s back office if it provides for an action log and analytics on operations. In NeuroVision, the operator interface records the history of actions for each case and aggregates the data on dashboards — this provides a basis for making decisions about the load without additional tools.

Separately, regulatory deadlines should be taken into account. Federal Law 115-FZ and subordinate acts establish specific deadlines: for recording an operation subject to mandatory control, for submitting information to Rosfinmonitoring. If the average case age is approaching these deadlines, this is not just an operational problem — it is a compliance risk with potential sanctions.

How to Revise Rules Without Expanding the Staff

Monitoring rules become outdated. Laundering schemes evolve, regulatory requirements are updated (from mid-2025 to March 2026, Federal Law 115-FZ underwent more than ten amendments, each of which requires updating the ICR), the profile of the customer base changes as the business grows. If the rules are not revised, some begin to generate useless noise while others stop detecting real risks.

Revising rules is not a one-time project but a regular cycle: analysis, hypothesis, change, measurement of the effect.

Analysis of the effectiveness of existing rules. Once a quarter (or more often if volumes are growing), it is useful to export statistics for each rule: how many alerts it generated, what share turned out to be true positive, what the average review time was. Rules with zero or near-zero conversion into real cases are candidates for threshold revision or deactivation. Rules with high conversion but an excessive flow are candidates for refining the conditions.

Iterative calibration. A rule change is not introduced immediately in live mode. It is safer to launch the new version in parallel: the system counts alerts by the old and the new rule, but only the old one enters the operator’s queue. After an observation period, the results are compared: has the noise decreased, were real incidents missed. After the hypothesis is confirmed, the rule is switched.

Accounting for regulatory changes. Each new version of Federal Law 115-FZ and subordinate acts can change the list of controlled operations, the amount thresholds, the composition of the lists, and the response deadlines. These updates must be reflected not only in documents but in the logic of the automated loop: which monitoring scenarios are activated, which thresholds are applied, which lists are connected. Without a linkage between the regulatory document and the system settings, a gap arises that is recorded during an audit.

Documenting changes. Each rule change — a new threshold, a new condition, the deactivation of a scenario — is recorded in the log with an indication of the reason, author, and date. During a regulator’s audit or an internal audit, it will be necessary to explain why the rule was changed and on the basis of what data the decision was made. Case management and the action log in the platform’s back office cover this task if they are configured to record not only operator decisions but also administrative actions on the rules.

The three directions together — noise suppression, load measurement, and regular calibration — make it possible to scale the compliance loop along with the business. A two- or threefold growth of the customer base should not automatically mean a proportional increase in staff: if the loop is configured correctly, the main load falls on the automation, while operators work with cases that genuinely require expert judgment.