Manual AML checks stop scaling at roughly the point where a product starts succeeding. A desk that clears ten counterparties a day can screen them in a dashboard; a platform crediting thousands of deposits an hour cannot, and neither can a payment provider whose merchants expect a payout queue that never waits for a human. An AML API moves the check into the software, at the moment the software makes its decision. This guide is for the people who have to design that integration — product owners, backend engineers and the compliance officer who has to sign off on the logic — and covers what an AML API is and is not, where it belongs in a transaction flow, how to turn its response into a decision, what to do when it is slow or unavailable, and how to keep the record a regulator will ask for.
What an AML API is — and what it is not
An AML API is an interface that lets your systems ask an AML question about a crypto address or a transaction and receive a machine-readable answer: the risk exposure of those funds as seen in blockchain analytics data — connections to sanctioned addresses, darknet markets, mixers, scams, stolen funds and other labelled categories, direct or through intermediate hops. It is the same check an analyst runs by hand in a dashboard, without the analyst in the middle.
It is not a KYC API. The phrase "KYC/AML API" appears in many search queries and some vendor pages, and it conflates two different products. Identity verification — document checks, liveness, beneficial-owner lookups — is delivered by identity providers and tells you who the customer is. An AML screening API works on blockchain data and tells you where the funds have been. It cannot identify the owner of an address and does not try to. A platform needs both integrations, and they answer different questions at different points in the flow.
Nor is it a compliance programme. The API returns a risk signal; what your system does with it — credit, hold, refuse, escalate — is your policy expressed in code, and the obligations to monitor, keep records and report suspicion stay with your business.
Where screening belongs in the transaction flow
Screening is worth most at the point before something becomes irreversible. In a typical platform there are four such points:
- Deposit detected, before crediting. Your node or deposit service sees an incoming transaction. Before the balance is credited, the sending address is screened. A clean result credits; anything else goes to a review state. This is the highest-value integration point, because it is the last moment at which refusing the funds is still an option.
- Withdrawal requested, before broadcast. The destination address is screened before the transaction is signed. A payout that lands on a sanctioned or scam-linked address becomes a question about your platform, not only about the customer who requested it.
- Counterparty onboarding. A merchant, partner or OTC counterparty wallet is screened when it is registered — and submitted for continuous monitoring at the same time, because an address that is clean today can receive tainted funds tomorrow.
- Periodic re-screening. Addresses already on your books are re-evaluated on a schedule or, better, kept under monitoring so that the re-evaluation happens when their activity changes rather than when a cron job runs.
Screening after crediting — nightly batches over the day's deposits — is better than nothing, but it turns the check from a control into a report. If batch is the only option, it should be the interim state, not the design.
Designing the decision logic
The response from an AML API is data; the decision is yours. The parts of the response that matter to the decision are the risk score or level, the exposure by category, and whether that exposure is direct or indirect. The design work is turning those into a small number of outcomes your system can act on. A common shape:
| Condition | System action | Human involvement |
|---|---|---|
| Low risk, no exposure to serious categories | Proceed automatically | None; report stored |
| Medium risk, or indirect exposure to serious categories above your threshold | Hold; open a case | Analyst review, possibly a source-of-funds request |
| Any direct exposure to sanctions, stolen funds or ransomware | Hold; do not credit or broadcast | Compliance officer; reporting decision |
| Screening unavailable | Fail-closed or a documented fail-open exception — see "Timeouts, outages and the fail-open question" below | Per policy |
Three principles keep this defensible. First, the thresholds live in configuration and in the written policy, not hard-coded in a service nobody remembers. Second, the system holds; it does not decide. Automated blocking sounds efficient, but a hold with a human decision is what a regulator expects to see and what a customer can be given a reason for. AMLOfficer's own position on this is explicit: it delivers the risk signal, and the decision to accept, hold or refuse stays with the business. Third, every automated outcome is logged with the response that produced it.
Handling several providers
If your integration draws on more than one blockchain analytics provider — directly or through an aggregator — you will see the providers disagree. Each builds its own dataset — its own labels, its own rules for grouping addresses into entities, its own depth of tracing for indirect exposure — so an address that is clean in one dataset is flagged in another. This is the main reason to integrate several sources: a single provider gives you one view of an address, and a clean result from it is not evidence that the others agree.
Your decision logic has to say what happens on disagreement. The conservative and, in practice, correct rule for serious categories is that any provider's flag is a flag: one source reporting direct sanctions exposure sends the transaction to hold regardless of the other three. For lower-severity categories, a flag from a minority of sources can route to a lower-priority review rather than a hold. Whatever you choose, store every provider's response, not only the aggregate, so that a reviewer can see who said what.
Integrating providers one by one means one contract, one key, one response format and one outage per provider — plus the aggregation logic itself. AMLOfficer is an aggregator of four AML providers in one interface. It enables fast screening of crypto wallet addresses and provides 24/7 monitoring through Web, API and Telegram Mini App. Three of the four providers are publicly named — BitOK, Global Ledger and Beosin; the fourth is also a third-party AML provider whose name is not disclosed; in the product it is called Secret Sauce. Each of the three named providers announced the partnership on its own site, naming StarCompliance, AMLOfficer's parent company, as the partner. With one account and one API in front of them, the disagreement between providers reaches your risk logic without four separate integrations on your side.
Timeouts, outages and the fail-open question
Every external dependency fails eventually, and screening sits on the critical path of a deposit or payout. Decide the behaviour before it happens:
- Timeouts. Set one that fits the flow. A deposit credit can wait a few seconds; a payout queue may tolerate more. A request that exceeds it should be treated as "no answer", not as "clean".
- Fail-closed versus fail-open. Fail-closed — hold everything until screening is back — is the safe default for withdrawals and for high-value deposits. Fail-open — credit and screen later — may be acceptable for small deposits under a written exception, with mandatory re-screening once the service is available. Which one you pick is a compliance decision and belongs in the policy, with the compliance officer's name on it.
- Retries and idempotency. Retry with backoff, and make sure a retried request cannot create two cases or two charges for the same transaction.
- Asynchronous results. For continuous monitoring, the result arrives later than the request. Design the consumer so that an alert about a wallet monitored last month reaches the case that wallet belongs to, not a generic inbox.
Logging, retention and data protection
The response you receive is the evidence of what you knew when you decided. Store it as received — score, categories, direct/indirect, provider, timestamp — against the transaction or customer it concerns, and keep it for the retention period your jurisdiction requires (five years is the baseline under FATF Recommendation 11; some regimes require longer). Providers keep labelling addresses after your decision, so the same request next quarter may score differently; only the response you actually acted on proves the decision was reasonable when it was made.
Two data-protection points are easy to miss. A blockchain address on its own is pseudonymous, but once your system links it to a verified customer it is personal data, and the combined record falls under whatever data-protection law applies to you — the GDPR for EU customers, for example. Keep the mapping between addresses and identities in your own systems, and send the screening provider only what the screening needs: the address and the network. Screening does not require the customer's name, and there is no reason for it to travel.
Testing the integration before it carries real decisions
A useful test set costs nothing to assemble. Addresses that appear as identifiers on the OFAC SDN list are public (OFAC's virtual currency FAQs explain how they are listed) and should come back with direct sanctions exposure from any competent provider; your own historical deposits, including any you later had questions about, make a realistic second set. Run the set through the integration and check four things: that each response lands in the outcome your matrix predicts, that a disagreement between providers is visible in what you stored, that a timeout produces the fail mode you chose rather than a silent credit, and that a reviewer looking at a held case a week later can see why it was held without asking an engineer.
Then test the people, not the code: does a held deposit reach someone within the time your policy promises, and does that person know what to do with it?
Integrating the AMLOfficer AML API
Access is through a REST API; API integration is included for corporate plans. Every API call is asynchronous: the result is delivered to your webhook. The API runs on the same account as the dashboard and the Telegram alerts, with the same AML providers available under your plan, so an address submitted through the API can be kept under continuous monitoring with alerts reaching your team as usual.
API access is issued with a business account: credentials and the technical documentation come with the account rather than being published on the site, and AMLOfficer's team goes through the integration with your developers — setup on the AMLOfficer side is designed as a one-day step, and a corporate integration — monitoring configuration plus the API connection — typically takes one to two weeks, with the AMLOfficer team supporting it. Commercial terms appear in the account once it is registered; the plans are described on the pricing page. To see the data before writing integration code, the same checks can be run by hand through the online AML check, and wallets your integration submits are covered by transaction monitoring.
AML API: common questions
What does an AML API return?
A risk assessment of a crypto address or transaction: a score or level, the exposure by category (sanctions, darknet, mixers, scams, stolen funds and so on), whether that exposure is direct or indirect, and the counterparties involved — as seen in the datasets of the blockchain analytics providers behind it.
Is an AML API the same as a KYC API?
No. A KYC API verifies a person's identity from documents and registries. An AML screening API evaluates blockchain addresses and transactions. They answer different questions and a platform usually needs both.
Where in the flow should screening run?
Before a deposit is credited, before a withdrawal is broadcast, when a counterparty wallet is onboarded, and continuously for wallets you keep dealing with. Screening after crediting turns the control into a report.
Should the API block transactions automatically?
It should hold them for a human decision, not block them outright. AMLOfficer delivers the risk signal; the decision to accept, hold or refuse — and any freeze — stays with your business, and a supervisor expects to find it there.
What happens if the screening service is unavailable?
Whatever your policy says. Fail-closed (hold until screening is back) is the safe default for withdrawals and large deposits; a documented fail-open exception with mandatory re-screening may be acceptable for small deposits. The choice is a compliance decision, not an engineering default.
Where is the AMLOfficer API documentation?
Technical documentation and credentials are issued with a business account rather than published on the site, and the AMLOfficer team walks through the integration with your developers.
