When Manual Screening Stops Working
Manual screening fails for three reasons, and they arrive together. Volume climbs until copy and paste cannot keep up. The review queue backs up, and withdrawals slow down while users wait. And once a check is closed, nobody is watching that address anymore, so a risk change three weeks later goes unseen. Automation addresses all three at once.
The first pressure is sheer count. Deposits and withdrawal requests arrive in batches, and a person working through them one at a time becomes the slowest part of the pipeline. The second pressure is the queue itself. Every minute an address waits for review is a minute a user waits for money, and compliance starts to feel like the enemy of the product. The third pressure is time. A manual check is done when it is done; nothing about it keeps running.
The Financial Action Task Force expects ongoing monitoring as part of a risk-based approach, not just a check at the door. And sanctions lists change on their own schedule, which the OFAC recent actions page shows plainly: an address can land on a list on any given morning, whether or not anyone is looking. Those two facts are the core argument for wiring screening into your systems rather than leaving it in a browser tab.
What automation changes is where the check lives. A check inside the pipeline runs whether or not someone remembers it, applies the same standard to the ten thousandth address as the first, and writes down what it saw without being asked. That last part, the record, is what turns an audit from a project into a query.
| Aspect | Manual screening | Automated pipeline |
|---|---|---|
| Where the check lives | A browser tab a person remembers to open | Inside your deposit and withdrawal flow |
| Consistency at volume | Depends on the person and the hour | Same standard on every address |
| Watching after approval | Ends when the check is closed | Webhooks push risk level changes |
| Records | Rebuilt when an audit asks | Written by the pipeline as it runs |
The signals that it is time to switch are simple. Daily checks you could not skip a day on, audits that ask for records of every decision, and a monitoring duty your team is meeting only in spirit.
Batch Screening Through the API
The API turns one-off checks into a pipeline step. Requests go to the base address https://api.blocksec.com with the path prefix /phalcon/compliance/v2/, authenticated with an API key generated under System, then API, then Generate Key. Screening requests are metered at 50 per minute per key, other calls at 10 per second, and success is signaled by code=0.
Four screening endpoints carry the load: /address/screen for a single address, /addresses/screen for batches, /transaction/screen for one transaction, and /transactions/screen for batches of those. The single and batch forms mean your pipeline can call the same tool for the one-off manual case and the ten thousand item overnight job.
Around the endpoints, the usual pipeline hygiene applies. Treat the rate limit as a design input rather than a surprise: queue your batches, back off when you hit the ceiling, and keep a retry path for the calls that fail. Screen at the moment of decision, deposit or withdrawal, and store the result with the transaction it belongs to, so the two never drift apart.
Keys are managed per project. The full request and response details, field by field, live in the official API documentation, and this page stays at the workflow level rather than repeating them.
One planning fact belongs here because it affects your timeline: the API is available on the Scale and Enterprise plans, not on every plan. If your rollout assumes API access, confirm the plan first. This is a real gate, not a formality, and it is better to meet it in week one than week six.
Let Webhooks Watch for Changes
Webhooks are how the watching half works. You register an endpoint, and the service pushes two kinds of messages to it: type 1 notification messages carrying risk engine alerts, and type 2 monitorEvent messages carrying Monitor events. Those are the ones that say a wallet you already approved has changed.
The events that matter most to a compliance workflow are the risk level changes: Risk Level Increased and Risk Level Decreased. Each carries prevLevel and newLevel so your system can see the jump, plus the Risk Timeline for the address. A wallet that screened clean at onboarding and later touches sanctioned funds produces exactly this event, which is the machine-side answer to the question users keep asking: can a clean wallet turn risky? Yes, and this is what it looks like when it does.
One field name deserves a warning because it looks like a typo and is not: targetIdentifiter appears in the official payloads exactly as spelled there. Copy it as written in the documentation, mismatched letter and all, or your integration will fail in a way that wastes an afternoon to find.
Delivery does not stop at your server. The same alerts fan out across 7 notification channels, including Telegram, email, and Lark. The person who needs to act can be reached where they already sit, rather than through a dashboard nobody watches at 2 a.m.
Assign ownership alongside the channels. An alert that reaches everyone is an alert owned by no one. Each channel should map to a person or a rota, with a written rule for how fast a risk level change must be picked up and what the first response is.
What Automation Adds Up To
Once screening runs in the pipeline, three things settle into place. Every deposit gets checked before it is accepted, so decisions rest on evidence. Every approved wallet stays watched, so risk changes surface on their own. And every check leaves a record, so audits become retrieval rather than reconstruction.
The capacity side is built for this shape of work: screening responses in under 100 milliseconds, and more than 200 risk signals feeding the score (per BlockSec). Pricing starts with a free tier, then credit packages as you need them or a monthly subscription as the work grows.
The honest boundary is that automation widens coverage and speeds it up; it does not make risk disappear. A fast, well recorded wrong policy is still a wrong policy. The rate limits and the plan gate from earlier in this page are the practical edges. Work inside them, scale when you hit them, and revisit the policy itself on a schedule rather than only when something breaks.
For the concept layer underneath all of this, what labels and signals actually are and how a score gets built, read What Is Address Screening in Crypto Compliance?. The map of the whole topic, from first check to monitoring to records, is in the wallet screening hub.