Turnkey AML screening integration (Chainalysis, Elliptic, Crystal)

AML screening of cryptocurrencies: where compliance breaks down

While the volume of operations is small, transaction checks are done by hand: an analyst opens an address in a block explorer, cross-checks it against sanctions lists, and writes a comment into a spreadsheet.

While a dozen payouts pass per day, the delay in withdrawing funds is unnoticeable — at hundreds of operations the queue grows faster than it is worked off, and the response time to the client slips from hours to a day.

The second point of failure is false positives. Automatic rules flag as suspicious transfers that are only indirectly linked to a mixer or an exchange wallet, and up to 80% of such flags are closed as unfounded.

The analyst spends the day sorting through noise, while a genuinely risky transaction slips by: attention has already been exhausted.

Then the external contour comes into play. A liquidity partner or a correspondent bank sees an opaque transaction history and blocks the account until things are cleared up — payouts stall entirely, not for a single client.

During an audit of crypto operations it turns out that decisions on past flags were never recorded anywhere: it is unclear who let a transaction through and on what grounds.

This is exactly where compliance risks are lost — not in the absence of screening, but in its manual mode.

Let us break down how this is closed: Chainalysis and similar services provide an address assessment, but the effect only appears when that assessment is embedded into the payout process itself and leaves a trace for the reviewer.

What automatic screening delivers: the effect in measurable terms

Screening is embedded at the moment of deposit or withdrawal, so every operation receives a risk score before the funds move, rather than retroactively.

The speed of processing operations is set by the service's throughput, not by the number of analysts on shift: the stream of addresses is checked automatically, and manual work remains only on hits.

The share of false positives is a manageable value. The assessment is built on data from blockchain analytics providers, such as Chainalysis, while risk thresholds are tuned to your client profile, payment geography, and typical amounts.

After tuning, signals surface genuinely non-standard routes rather than every new counterparty — this unloads the review queue and reduces the number of cases where documents have to be requested from the client.

Case review time shrinks thanks to a ready-made card: sender address, counterparty, fund route, linkage to known services, and the history of past checks.

The analyst confirms a decision instead of gathering data manually — a routine case closes in minutes instead of an hour or more.

The main effect is an eliminated class of failures. Operations that a partner bank or exchange rejected because of an opaque source of funds now go through with a confirmed risk and a justification.

Downtime cost shrinks along with this: a frozen deposit or withdrawal means hours and days without operations, and such downtime is closed before it begins.

Ways to integrate screening: comparing operating modes

The screening mode is determined by where in the transaction flow the analytics service call sits and what happens to the operation before a verdict is received.

Inbound screening assesses the sender's address before funds are credited; outbound screening — before a payout is formed, so that the transaction does not go to a sanctioned or high-risk address.

A hybrid scheme combines both contours and adds periodic re-review of history: an address that was clean at the time of inbound screening is re-assessed as the provider's data updates. The modes differ in the cost of delay and in risk coverage.

So that the modes do not sprawl across the codebase, connections to analytics services — Chainalysis, Elliptic, Crystal — are made through a single adapter: a normalized verdict, per-address score caching, request retry on unavailability.

Then switching a provider or adding a second one is a configuration change, not a rewrite of screening logic.

Implementation stages: from operations audit to handover

Implementing screening is not installing a ready-made module but tuning the process to how funds actually move in your product. Below are the stages we go through together with the client's team: from an operations audit to handing the contour over to production.

1. Operations audit. We break down inbound and outbound flows: top-ups, withdrawals, transfers between accounts, exchange. We pin down where full address screening is needed and where a sanctions-list cross-check is sufficient.

2. Risk profile. We define the criteria of a suspicious operation: jurisdiction, source of funds, address age, share of inflows from mixers and platforms without client verification.

3. Scheme design. We select a provider for your networks and assets — Chainalysis, Elliptic or Crystal — and describe the actions on a hit: blocking, manual review, document request.

4. Integration and trigger thresholds. Screening is embedded at the moment a transaction is created and in the background so as not to delay payments. We set thresholds not by default but from your risk profile and acceptable false-positive rate.

5. Testing on historical data. We run accumulated transactions through the ready rules and see how many hits fall on real risks and how many on noise. Only this way are thresholds calibrated before launch.

6. Regulations and handover. We describe the analyst's actions for each risk class and the storage of evidence for reporting, hand over the configuration and instructions — and remain on support when new networks are connected.

What stays in your hands: configuration and regulations

After the project is handed over, your team retains not only a working service but a full set of artifacts by which it can be operated, developed, and passed on to new engineers.

The configuration lives in your repository with a change history, decisions are documented — the integration does not depend on the contractor.

• Integration scheme — the path from an address or transaction to a screening verdict: where screening is called, how a provider timeout is handled, and what goes to the fallback channel.
• Configurations — risk thresholds, trusted-address lists, routing across providers for different networks and assets, separate sets for test and production environments.
• Hit review regulations — risk levels, response deadlines, who a finding is escalated to, and how the decision on it is recorded.
• Access policies — roles, separation of rights to change thresholds versus to view screening data, logging of operator actions.
• Support instructions — what to do when a provider is unavailable, how to check the status of a specific screening, and how to handle typical client requests.
• Operations reporting — exports on screenings, rejections, and escalations for a period, in a format accepted by compliance.
• Development plan — how new networks and providers are connected, and how rules change without stopping the service.

We hand over each item with a walkthrough on a call and in a recording — so that an on-duty engineer can act by the document, not from memory.

Case study: how manual reviews were cut on a transaction stream

The client is a payment service with a flow of inbound and outbound transfers across several blockchains and an obligation to verify the source of funds for every address.

Screening was connected but worked as a "black box": the rules fired on the entire traffic indiscriminately, and decisions were made by people.

What it was before

Alerts dropped into one common queue without priority, and analysts worked through them in order. Up to 71% of hits turned out to be false: deposit addresses of major platforms, clients' own wallets, legitimate turnover through exchange services.

The queue grew faster than it was cleared, and a client payout waited for a verdict for up to 26 hours — longer under peak load.

What was changed

We split the flow by risk levels and added deduplication: an address from the same cluster no longer raised a new alert every time. Trusted addresses and known service wallets went into automatic closure, and only operations with uncovered history landed in the review queue.

The trigger threshold was tuned using a cluster-scoring methodology — it is openly described in Chainalysis materials — rather than set "by eye".

Manual reviews dropped almost sixfold, and withdrawal time fell by more than an order of magnitude.

The key consequence: operations that genuinely require it now land in screening, and every decision remains in the log with a justification — when a bank or regulator requests it, the export is assembled in minutes rather than weeks of correspondence.

How does built-in screening differ from manual review?

Screening in the flow is a synchronous risk-score request at the moment of the operation: the address is checked before a withdrawal or credit is confirmed, and if the threshold is exceeded the operation goes into hold, and only then does an analyst pick it up.

To fit inside the processing window, scores are cached, and cross-checking runs against an already labeled attribution base, without recomputing clusters on every request.

Deferred screening collects operations into a batch and reviews them on a schedule or on demand — with full multi-hop cluster analysis and history review. Accuracy is higher, but the result arrives with a delay, and every finding lands in the manual review queue.

The choice is determined by the control point, not by convenience. In the flow you screen what cannot be undone: credits, withdrawals, adding an address to a whitelist.

Deferred — periodic re-checking of the client base, history review, and sampling for reporting, where completeness matters more than speed.

The load on the analyst differs by an order of magnitude. In the flow, only hits above the threshold form the queue, and typical cases are closed automatically by rules — with tuned thresholds, up to eight out of ten hits require no human.

Deferred review produces a stream of manual work proportional to the number of operations: every finding is reviewed by a human.

In practice, AML screening of cryptocurrencies does not come down to choosing a single mode: the flow covers operations on the way in and out, while deferred review covers depth and periodicity.

Risk is caught at the moment of the operation, and the team's time goes to non-obvious cases rather than mechanical cross-checking.

Common technical questions about implementing screening

Before starting an integration, clients ask the same questions: they concern not the choice of service but the junction with a working infrastructure. Below are five doubts that most often stall a decision.

Can the analytics service be replaced without losing history?

Switching a provider is a migration of verdicts, not a clean install. We compare the risk scales of the two systems and re-check disputed addresses manually so that client statuses do not "drift" after the migration.

How do you cut off false positives?

Mixers, darknet addresses, and partial cluster matches produce noise. We tune thresholds and the review queue: some cases close automatically by attributes, while complex ones go to an analyst with ready context.

What do banks and counterparties request?

Confirmation of the origin of funds. The report is generated in a format accepted by the counterparty's compliance service, together with the screening log and the history of verdicts for the address.

Where does client data go?

Only the address or transaction hash is transmitted externally, not personal data. Verdicts, history, and the access log remain in your contour: the role model, retention period, and export per policy.

Let's discuss the task: what data is needed for an assessment and a plan

The more accurate the source data at the start, the fewer assumptions in the assessment. Below is the minimum set, after which we come back with an implementation plan by stages and work timelines — not with "we'll clarify as we go".

• List of networks and assets: which blockchains are in use, including L2 and sidechains, which tokens and standards — the coverage of address risk assessment depends on this.
• Types of operations to be screened: inbound deposits, withdrawals, internal transfers between clients, P2P and exchange scenarios.
• Current infrastructure: where transaction and client address history is stored, whether there are proprietary nodes or an indexing service, and in what form accounting is kept.
• Risk policy and thresholds: from what risk level an operation goes to manual review, who makes the decision, and how the justification is recorded.
• Audit and regulator requirements: the composition of reporting, data retention periods, and whether exports in an agreed format are needed.
• Integration points and access: test keys for the analytics service (for example, Chainalysis), access to the test contour, roles for our engineers.
• Constraints: sanctions lists, client geography, personal data processing rules.

Based on these points we assess the scope, assemble an implementation plan, and state the work timelines. Describe your task — we will come back with an assessment and a plan.