Why AML/KYC setup breaks on the very first flow of clients
AML/KYC setup almost never breaks at the design stage — it breaks when the first real flow of clients goes through it.
Before that, client verification for a crypto project looks manageable: a few applications a day, an analyst manually cross-checks documents, disputed cases are handled by a senior compliance officer.
At a volume of hundreds of registrations per day, manual verification stops scaling: the queue grows faster than the team can process it, and the time to a decision on a client is no longer measured in minutes but in days.
The second point of failure is false positives. Rules configured "with a margin" start blocking honest clients: a name match with a sanctions list, a non-standard jurisdiction, a large one-time transaction.
Each such case means manual review, a lost user, and a reputational trace. The project either loosens the rules and gets a hole in its identification procedures, or keeps them strict and loses conversion at the entry point.
The third point of failure is fragmented rules. When verification logic lives in scripts, spreadsheets, and the heads of individual employees, it is neither reproducible nor explainable.
Regulatory requirements assume that every decision has a trace: what data was checked, under which rule, who made the decision and when. Without a single log and versioned rules, neither internal audit nor external supervision will pass.
The cost of these failures is made up of frozen funds in accounts, manual hours spent on review, and the risk of enforcement orders.
We break down how this is closed: where to place automated verification, how to configure trigger thresholds, and how to build procedures that withstand both the flow and the review.
What a well-built AML/KYC setup delivers: rules, roles, reporting
Identification levels: how many checks are actually needed
The first level is basic identification: matching the document to the person and screening against sanctions and politically exposed persons lists.
The second is enhanced source-of-funds verification; it is not enabled for everyone, but triggered by specific events: a large one-time deposit, a mismatch between the document's country and the transaction's country, or falling into a risk group based on activity profile.
The third is ongoing monitoring after onboarding. Splitting into levels delivers the main benefit: manual review goes only where it is needed, while standard registration passes automatically.
Transaction monitoring rules
Rules describe not "suspiciousness" in general, but specific scenarios: splitting an amount into a series of transactions below the threshold, funds transiting through a high-risk address, a sharp change in geography while the profile remains stable.
Each rule has a trigger threshold and a level — from "flag" to "suspend the transaction pending an officer's decision." Configured thresholds remove the bulk of the load: the share of manual reviews drops from nearly half of all transactions to single-digit percentages, and the review time for a typical client shrinks from hours to minutes.
Roles and reporting
The compliance officer receives not a raw stream, but a prioritized queue with the decision history for each client. Permissions are separated: the analyst works through alerts, the officer decides on blocking and unblocking, and the auditor sees only the log.
Reporting is generated from the same data — a regulatory request export is assembled without manual reconciliation of spreadsheets, because every action is already recorded with a timestamp and an author.
| Verification approach | When it fits | Limitations |
|---|---|---|
| Manual review of every client | Low volume, isolated large transactions | Does not scale, review time grows linearly |
| External verification provider | Fast start, no in-house team | Dependence on someone else's logic, limited rule configuration |
| In-house setup with external lists | Your own flow, your own risk scenarios | Requires configuration and maintenance of rules |
We build the operational setup on a combination of open tools and trusted data sources — Chainalysis and similar services provide address risk scoring, on top of which our team configures rules and roles for your flow.
Stages of implementing a compliance loop: from audit to handover
Setting up AML/KYC is not installing an off-the-shelf product, but assembling a loop tailored to a specific flow-of-funds model: where the source is, where assets go, which jurisdictions are involved.
A mistake at the design stage of the verification scheme is the most costly: rules written "from a template" either let risky transactions through or block bona fide clients and create a queue of manual reviews. That is why the work proceeds in stages, and each one ends with a verifiable artifact.
- Audit of compliance procedures. We examine the current checks, sources of client data, transaction logs, and the points where the decision to "pass or stop" is currently made. The output is a gap map: which scenarios are not covered, where there is no trail for the regulator.
- Designing the verification scheme. We define the tiers: basic data collection, screening against sanctions and reputational lists, enhanced due diligence for elevated risk. We set the thresholds at which a transaction goes to manual review.
- Configuring monitoring rules. We formalize the scenarios: structuring of amounts, transit through intermediate addresses, activity atypical relative to the client's profile. We tie the rules to events rather than to manual review of exports.
- Integrations. We connect verification services and internal systems so that the decision on a client is made at the moment of the transaction, not after the fact. We separately work out the behavior when an external service is unavailable — a queue and retry instead of a rejection.
- Testing scenarios. We run the loop on prepared cases: a clean client, a list match, structuring, a refund. We look at the false-positive rate — the workload of the review team depends on it.
- Calibrating thresholds. Based on the test results, we fine-tune the sensitivity of the rules to remove noise without losing coverage of risky transactions.
- Handover of documentation. We provide the scheme description, the regulation for reviewing alerts, the risk matrix, and instructions for operators. The client's team then runs the loop independently.
Each stage is agreed upon before moving to the next — this way changes remain reversible rather than turning into a rework of the entire loop. Describe your flow-of-funds model — we will come back with an assessment and a stage-by-stage plan.
How does manual review differ from automated review in a crypto project?
Manual customer review and automated review solve different tasks, and confusing them is costly.
Automation cross-checks incoming data against sanctions and PEP lists, calculates risk using a scoring model, checks documents for signs of forgery, and assigns a risk level in seconds.
Manual review is needed where the model hits ambiguity: a name match against a sanctions list without corroborating indicators, a non-standard ownership structure, a source of funds whose explanation cannot be reduced to a field in a form.
The load on the compliance team is distributed by thresholds. If automation filters out the low-risk flow and passes only triggered signals to the analyst, one specialist closes several times more cases, and the response time to suspicious activity drops from hours to minutes.
Without thresholds, the team drowns in routine: it checks everyone, burns out, and misses real triggers against the background of noise.
A hybrid process is built on three rules. Automation makes a decision only where the model's confidence is high and confirmed by rules. Every trigger goes into a queue prioritized by risk level, not into a general list.
Any manual decision is recorded with a rationale — this is both protection during a regulator's review and a training signal for the model.
Quality of review matters more than speed at the top risk level. There is no point in reviewing a high-risk customer faster — the value there lies in depth: ownership chains, counterparty connections, transaction dynamics. Automation frees up the analyst's time precisely for these cases, rather than replacing them.
A practical sign of a properly built process: the share of cases closed without manual intervention grows, while the share of false positives falls. If it is the opposite, the model is configured too sensitively, and the team is sorting through noise instead of risks.
Case study: how we reduced the share of manual reviews and client verification time
Before implementation, client verification relied on manual review: an analyst opened each application, cross-checked data against sanctions lists, manually flagged matches, and passed questionable cases to a second level.
With a flow of several hundred registrations per day, the queue grew faster than it was processed, and suspicious transaction reports were filed late.
The main cost of such a scheme is not the analysts' hours, but the delay in onboarding: the client waited days for a decision, and some went to competitors.
What we changed
We broke verification down into layers and set up automated rules at each one.
Primary identification and screening against sanctions and politically exposed persons lists is performed at intake, risk scoring evaluates the client profile by country, transaction type, and history, and transaction monitoring rules catch deviations from normal behavior.
Typical cases — low risk, clean name matches — are closed automatically, and only what genuinely requires a human decision goes to manual review.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Share of applications in manual review | most of the flow | a few percent |
| Client verification time | a day or more | minutes for low risk |
| Overdue reports | regularly | isolated cases |
| False positives on sanctions | many, due to name matches | filtered out by rules before reaching an analyst |
The queue stopped being a bottleneck: analysts handle complex and borderline cases rather than mechanical cross-checking. Reports are generated on schedule, not as an afterthought.
What made it sustainable
We moved scoring rules and thresholds into configuration rather than code — they can be changed without a release when regulatory requirements are updated.
Every automated decision is logged with its rationale, so a reviewer can see why an application passed or was sent to review. This approach complies with FATF requirements for a risk-based approach and traceability of decisions.
What if the rules start filtering out too much? Thresholds are calibrated on historical data before being enabled in the flow, and disputed matches go to manual review rather than being rejected automatically — the client is not lost due to a false match.
Describe your registration flow and current verification workload — we will come back with an estimate and a setup plan tailored to your risk profile.
Concerns before implementation: compatibility, migration, rollback, access
The key concern with AML/KYC setup is that checks will have to be embedded into an already running product and this will affect live scenarios: registration, withdrawal of funds, limits.
In practice, the module connects at the service layer level: verification rules are moved into a separate component, and business logic accesses it as an external dependency.
The current infrastructure stays in place — only the point where the decision on whether to allow an operation is made changes.
We build the migration so as not to stop the product: the new verification loop is brought up in parallel, part of the traffic is routed to it, decisions are compared across both branches, and only after the results match is the old path switched off.
The rollback plan is a pre-prepared switch back to the previous logic and saved configurations: if metrics go beyond the boundaries, reverting takes minutes, not hours.
What if the checks start rejecting legitimate users?
Thresholds and rules are agreed with you before launch, and for the first weeks the work runs in observation mode: the system flags operations but does not block them.
This way you can see how many false positives each setting produces, and thresholds are calibrated on real data rather than assumptions.
Who will get access to the settings? We build in access separation from the start: roles for an analyst, a verification operator, and a rules administrator, plus an action log for every change.
Access to personal data is separated from access to verification logic — the operator sees the result but cannot rewrite a rule to suit themselves.
What if we have a non-standard stack? We check compatibility at the scoping stage: we look at how your queues, storage, and authentication are set up, and we select the connection method to fit them, not the other way around.
What you receive:
- verification rule and trigger threshold configurations;
- data flow diagrams between the product and the verification module;
- AML/KYC policies in a form suitable for internal regulations;
- a description of roles and an access separation matrix;
- instructions for scheduled rollback and switching between loops;
- documentation on logging and exporting reports for auditors.
Describe your task and current infrastructure — we will come back with an assessment and an implementation plan.