Elliptic integration: where manual AML screening breaks down
Manual withdrawal screening depends on an operator: they open the recipient address in a web interface, check it against sanctions lists, and mark it in a spreadsheet. As long as there are dozens of requests per day, this is enough.
When the flow grows severalfold, the withdrawal queue becomes a bottleneck, and the time to transaction confirmation starts to be measured in hours.
The second problem is that decisions are not reproducible. One operator interprets an address's risk score as grounds for manual review, another lets the payment through because everyone keeps the "gray zone" threshold in their head.
The same wallet passes on the morning shift and gets stuck on the night shift—not because of the risk level, but because of who was doing the screening.
The third is that screening history spreads across spreadsheets, logs, and chats. Wallet address screening is not tied to a specific request, and a screenshot from the interface does not replace a record of when, against which list, and with what result the address was checked.
In total, these are three classes of costs: downtime in the withdrawal queue, blurred criteria, and provability that is hard to present to a partner bank.
Integrating Elliptic addresses them not with the slogan "let's speed up operators" but by moving transaction AML screening into an automated loop with a recorded result. We break down how this works and where a manual decision deliberately remains.
What changes after implementation: speed, risk, reporting
The share of manual checks drops to the target threshold
Scoring rules are configured for the product's risk profile: transaction volume, age and activity of the counterparty wallet, source of funds, proximity to sanctioned addresses.
Transactions with an unambiguous verdict are closed automatically; only the gray zone goes to manual review—a few percent of the flow instead of the previous tens of percent.
The threshold changes without code edits: a risk analyst edits the rule, and the Elliptic service applies it to the next check.
Withdrawal processing time is reduced to one cycle
The wallet verdict is requested before the withdrawal is queued for signing—without it, the transaction is not signed. This is not a delay but a condition of passing control, so withdrawal processing time is determined by the processing cycle, not by the manual review schedule. The client sees the final status immediately, not the next morning.
The decision log addresses audit questions
Each check leaves an immutable record: verdict, risk assessment, triggered rules, time, initiator, and exception confirmation.
The partner bank receives an export showing why a specific transaction passed, and the share of disputed decisions falls—the question is resolved by fact, not by correspondence.
Transaction screening history is stored for any depth
Transaction screening history is tied to the address and internal client identifier, so the wallet chain can be retrieved for any period. This addresses compliance requests when investigating an incident or reassessing a counterparty and provides a ready basis for reporting.
Comparison of approaches: manual control, in-house registry, ready-made service
The screening mode is chosen not by company size but by transaction flow and the requirements of partners and correspondent banks.
Manual control handles small volumes, but with hundreds of addresses per day, screening hits a human limit: decisions diverge, review history is not preserved, and no one is responsible for a repeat transaction.
There is one fork—where the risk signal comes from: an in-house risk registry or external address analytics.
The second question is who applies the automated screening rules: a person using a checklist or an engine that calculates the assessment itself and sends borderline cases for review.
| Option | When it fits | Limitations |
|---|---|---|
| Manual control | Isolated checks, a flow of a few transactions per day | Does not scale, depends on shift, no decision log |
| In-house risk registry | Closed perimeter, own addresses and known incidents | Must be updated manually, third-party addresses are not assessed, share of false positives grows |
| External address analytics (Elliptic) | Need an assessment of an address not in your own data | Vendor dependency, thresholds are configured for its risk model |
| Hybrid screening scheme | In-house registry plus external analytics on a mixed flow | Requires source priority and a procedure for diverging assessments |
The chosen mode is recorded in the rules: risk threshold, action on trigger—blocking, manual review, or document request—and who closes those reviews.
After that, the scheme is changed in a targeted way: individual areas are moved to automated screening rules without rebuilding the entire process.
How Elliptic integration works: stages of work
Screening is not connected with a single button: first you need to understand where funds enter and exit your infrastructure, otherwise screening either slows down legitimate clients or leaves a gap on intermediate transfers.
Below is the sequence we follow when implementing Elliptic: from flow inventory to handing the system over to operations.
Screening implementation stages
- Flow audit and address inventory. We build a map of client, custodial, and hot wallets and mark flows through intermediate addresses and contracts.
- Design of transaction screening points. We define what is checked on deposit, on withdrawal, and in the background: incoming deposit, outgoing transfer, address change in the user account.
- Configuration of risk score thresholds. A low score passes automatically, a medium score goes to manual review, and a high score blocks the operation until a compliance officer decides.
- Automated actions by address. We define policies: flagging in the database, withdrawal restriction, blocking, scheduled re-screening.
- Engineering integration. Asynchronous request queue, retries when the service is unavailable, storage of already screened addresses, and a log of all decisions for audit.
- Testing on real data. We run historical transactions, measure the false positive rate, and calibrate thresholds for your client profile.
- Handover to operations. Manual review procedures, monitoring dashboard, support instructions, and the rule update procedure.
After launch, thresholds do not remain frozen: once a quarter we compare the share of manual reviews and false blocks and revise policies so that screening does not become a brake on normal operations.
What the client's team retains after launch
After the Elliptic integration launches, screening continues to work without our involvement—we hand over not only the configured service but also the rules by which it makes decisions. Incident investigation, threshold changes, or connecting a new area are done by your team.
- False positive procedure: which flags are considered borderline, at what risk level a transaction goes to manual review, who and within what timeframe removes the flag, and what is recorded in the log.
- Data exchange scheme: which address and transaction attributes are sent for screening, what comes back in the response, how identifiers are matched, and where screening history is stored.
- Screening data access policy: roles, who can see the results, who is authorized to change thresholds, and how service request logs are maintained.
- Screening documentation: rule descriptions, current threshold values, settings change history, analysis of typical cases, and the procedure for adding new scenarios.
- A set of configurations and access keys in your perimeter with rotation and recovery procedures.
- Procedure for actions on confirmed risk: blocking, notification, reporting, and response times for each level.
- Handover checklist for the responsible person: what to check, where to view logs, and whom to contact if screening fails.
The handover also includes the procedure for testing new rules on historical data—comparing results before and after the change so that configuration does not break already reviewed cases.
You run screening yourself; we step in when the data scheme changes or new assessment logic is needed.
Case study: reducing the share of manual checks and response time
The client is a payment service that withdraws user funds to the network. Before screening, every withdrawal went to manual review: an analyst checked the recipient address against lists and open sources and made a decision only after the client had started writing to support.
What it was like before implementation
There were 400–600 screening requests per shift, and they piled up: the same address was rechecked if it appeared in another payment. Automation closed about 38% of cases; the rest hung in the queue—average client response time was 6–8 hours, and on peak days it reached 24 hours.
The main class of failures was not about a ban but about silence: the user saw "withdrawal in process" and did not understand what to expect.
What was changed and what it delivered
We connected Elliptic as a risk assessment source: the recipient address is checked before the payment is queued, and the result is written to the transaction record along with its history.
Then come compliance-approved rules: high risk blocks the withdrawal automatically with a clear message for the client, medium goes to the analyst's priority queue, and low is passed without human involvement. Repeat checks of the same address are cached, so the review workload does not grow with turnover.
The share of automated decisions grew from 38% to 91%, and average response time for disputed transactions dropped from 6–8 hours to 12–20 minutes. Manual checks decreased fourfold, and support requests on the topic of "where is my withdrawal" decreased threefold.
A separate effect was the disappearance of the surprise failure class: the client receives a reason and a reference to the decision, not a silent delay.
How address blocking differs from lowering a risk score
Address blocking is a hard ban: the address goes on a blacklist, and a transaction with it does not pass under any circumstances.
Lowering a risk score is a different class of measure: the address assessment shifts toward risk, but the final decision on the transaction remains with your policy, not with an external source.
In Elliptic and similar scoring sources, an address receives a numerical assessment based on a combination of signals: proximity to mixers, links to sanctions lists, and the number of "hops" from the source of funds.
Transaction risk levels are calculated across the entire chain, not at a single node—two addresses with the same score produce different outcomes if the paths to them differ.
The distinction directly affects withdrawal decisions. Blocking is binary and easy to automate, but an erroneous listing cuts off legitimate payouts without an option for a partial measure.
Lowering the score provides gradation: suspend the transaction until the source of funds is confirmed, reduce withdrawal limits, or send it to manual review instead of rejecting it.
For handling client inquiries, these are also different scenarios. With blocking, you show the basis for the ban and cannot offer a workaround; with a score reduction, you name the triggered signals and the list of documents that will restore the address's normal assessment.
Both decisions are recorded in the log: you can see who closed the operation, when, and on what basis.
Technical concerns before connecting screening
When the transaction flow is already deployed, questions about Elliptic integration are usually not about "is screening needed" but about integration points: how to embed it without rewriting the logic, what to do with partial address risk, which client data leaves the perimeter, and who is responsible for false positives. Below are the things technical teams most often clarify before starting.
Can screening be embedded into an already running flow?
Yes, you do not need to rewrite the logic. Screening is placed at points where the address is already known: when forming the transaction, on deposit, on withdrawal. A call and response handling are added—the rest of the chain remains as it was.
What is considered partial address risk?
The response does not come as "clean or dirty" but with a risk share and the signals it is composed of: a link to a mixer, inclusion in a sanctions list, a counterparty without screening procedures.
Then the threshold applies: below it, we pass; above it, manual review; at the upper boundary, we block. The threshold is set by policy and changes without a release.
Which client data leaves the perimeter?
Only what is needed to match against the risk database leaves the perimeter: the public address or its hash.
Personal data remains in your perimeter, and the set of transmitted fields is configurable—from a single address to a transaction identifier, without the client's name and documents.
Who is responsible for false positives?
A false positive is not a failure but a working case: the response contains the signal that caused it and a rule that allows the decision to be overridden with a log entry.
During the first month, we work through the queue together—this way the thresholds match your real transaction profile.
Let's discuss the task and come back with an estimate and plan
To come back with a transaction flow diagram, work plan, and implementation estimate, we need a minimum of inputs: which networks and assets are serviced, at what point in your perimeter the address or transaction hash appears, and who makes the decision on an alert.
This is enough to break the integration into stages and give timelines—without long introductory meetings and a week of correspondence.
- List of networks and asset types: native coins, tokens, internal transfers between your own wallets—this determines the depth of analysis and the set of rules.
- Integration points: deposit, withdrawal, outgoing payment, one-off address request—and where in these scenarios a blocking versus deferred decision is needed.
- Risk policy: thresholds by counterparty risk level, what is considered a stop factor, and who reviews a disputed case and within what timeframe.
- Roles and access: who sees the alert, who can remove the block, and how the justification is recorded—this goes into the log for the regulator.
- Reporting requirements: exports, retention periods for screening history, and the response format for requests from the control function.
- Load profile: peak screening frequency and acceptable delay for transaction confirmation—this determines the queue and caching scheme.
From this we assemble a flow diagram, stage descriptions, and acceptance criteria—a document you can use to make a decision. Describe the screening task in two or three paragraphs, and we will come back with a plan and estimate.