AML API integration is the engineering work that connects a regulated platform to an anti-money-laundering screening service, so that sanctions, politically exposed person (PEP), adverse-media and wallet checks run automatically inside the platform rather than as separate searches a member of staff performs by hand. The platform sends the details to be screened and receives a structured result it can act on — proceed, hold, or block.
For a crypto exchange, an e-money issuer or any regulated firm onboarding customers and monitoring them over time, this is what turns AML screening from an occasional manual task into a dependable control. At real volumes, against lists that change from one day to the next, checks run by hand are neither consistent nor easy to evidence; an integrated API makes each check a repeatable step the platform performs at the moment a decision is made, with the outcome recorded against the customer or transaction.
This article sets out what the integration is, what an AML screening API receives and returns, where the calls belong in a platform, how real-time onboarding screening differs from ongoing screening, how an integrated API differs from manual and portal-based screening, and where the boundaries lie.
What AML API Integration Is
AML API integration connects a platform to a screening service through a programmatic interface, so that the checks are requested and answered in software as part of a workflow. When a customer is onboarded or a transaction is processed, the platform calls the screening API, passes the details to be checked and receives a result it can branch on automatically, rather than waiting for someone to open a separate tool and run a search.
The contrast is with portal-only screening, where a person logs into a provider's web panel and screens each party by hand. That approach is workable at low volume, but it does not scale, and the outcome depends on who ran the check and when. Integration moves the same capability inside the platform, so the check is triggered by an event — a new customer, a payment, a scheduled re-screen — and its result is captured against the record without a manual step.
What integration changes is the delivery, not the underlying check. The sanctions, PEP, adverse-media and wallet-risk logic is the same whether a person runs it in a panel or a platform calls it over an API. Integration makes that logic a consistent, repeatable and recorded part of the firm's own systems.
What an AML Screening API Receives and Returns
The input to the API is the identifying detail of the party being screened: a person's name and attributes, a company's details, or a blockchain address, submitted at the point the platform needs a decision. The firm sends only what the check requires, and the interface is designed to be called automatically as part of a flow rather than filled in by hand.
The output is a structured result rather than a document a person must read and interpret. A response typically carries a match or no-match signal, a risk score, the categories that produced it — sanctions, PEP, adverse media, wallet risk — and a reference to the supporting evidence. Because the result is machine-readable, the platform can act on it directly: clear the party, hold the case for review, or stop the action.
Alongside the structured result, a durable evidence record matters as much. A human-readable report — a PDF, for instance — gives the firm something to retain and show a supervisor or an auditor: the same finding, in a form a person can review. Keeping both the machine result and the evidence is what makes an automated decision defensible after the fact.
Grumpio delivers this through Legichain, its AML and KYC product: person and company screening against sanctions and PEP data, adverse-media screening and multi-blockchain wallet risk screening, returned as a fully automated API result with a risk score and a PDF evidence report, and available through both an API and a web panel drawing on a single credit pool across checks. Pricing and product detail are published on the Legichain site. Screening a company in this way is not a substitute for full know-your-business (KYB) verification, and no dataset reflects every party across every jurisdiction without gaps.
Where the Integration Runs in a Platform
In a working exchange or payment platform, an AML screening API is not a single call but a set of checks at the points where a decision depends on the result. A party is screened as it is onboarded, again when a transaction warrants it, and repeatedly over the life of the relationship as the underlying lists change. Each point catches a different slice of the same obligation.
| Point in the flow | What the call evaluates |
|---|---|
| Onboarding | The customer's details, screened before the relationship is active, with the result gating whether onboarding completes. |
| Transaction event | The parties or addresses in a payment, screened before it is released so a prohibited transfer is stopped rather than reviewed afterwards. |
| Ongoing and periodic | Cleared parties re-screened on a schedule as designations change, surfacing a customer who becomes relevant after onboarding. |
| Manual review | Flagged cases routed to a person in the web panel, where the evidence is examined and a documented decision is recorded. |
Screening of this kind can be consumed as a hosted API or deployed so that data stays inside the firm's own environment; firms with stricter data-residency requirements use on-premises or dedicated storage, the same architectural choice that recurs across regulated fintech platforms. The integration also sits next to identity verification, since AML screening and KYC checks are usually called across the same onboarding flow.
Real-Time Onboarding and Ongoing Screening
Two integration modes do most of the work, and they behave differently. A real-time, synchronous call is used where a result must gate an action: at onboarding, or before a transaction is released, the platform calls the API and waits for the response before it proceeds. The call therefore sits on the critical path and is designed to absorb that wait.
Ongoing screening is the second mode. A party who is clean at onboarding can be designated later, so cleared records are re-screened against updated lists over time. This runs on a schedule rather than blocking a live action, and its purpose is to surface a customer who becomes relevant after the fact, routing the match to a person for review rather than stopping anything automatically.
Deciding which mode applies where is an architecture question rather than a screening one: real-time where a result must gate a decision, periodic where the point is to catch change over time. Both write to the same record, so that a customer's screening history — every check, its result and its evidence — is complete and retrievable when a supervisor asks for it.
How It Differs From Manual and Portal Screening
An integrated API and a web panel are complementary rather than competing. The API carries the volume and the consistency: every party screened the same way, automatically, with the result recorded against the record. The panel is where a person investigates a flagged case, examines the evidence and records a decision. A capable provider offers both against a single credit pool, so the automatic checks and the manual review draw on one dataset and one cost base rather than two disconnected tools.
Manual-only screening — staff entering names into a search tool one at a time — runs into three limits that integration is meant to remove. Consistency suffers, because the outcome depends on who searched and how. Coverage over time suffers, because a one-off search does not see a designation added the following week. Auditability suffers, because there is no automatic, structured record of what was checked and when. An integrated API addresses all three, while still leaving the judgement on a flagged case to a person.
Scope and Boundaries
The most important limit is that an integrated API automates the screening and the record; it does not make the compliance decision. A match is a signal the firm assesses, not a verdict the software delivers: a confirmed sanctions hit is generally a hard stop, while a PEP or adverse-media flag calls for proportionate review. In every case the regulated firm owns the decision and the basis on which it is recorded.
Scope has edges too. An AML screening API is not a full case-management system, and screening a company against AML and PEP data is not full KYB. Manual review of a flagged case is work the firm's own staff carry out, in the provider's panel or the firm's own systems; it is not something the API decides on their behalf. How a platform behaves when the service is slow or briefly unavailable — how it queues, retries or holds an action — is the firm's own design responsibility and sits outside a general description like this one. We do not provide legal opinions or guarantee authorisation. We implement regulatory and audit requirements across technology, infrastructure and operations.
Note: An AML screening API returns a result; it does not make the decision. The regulated firm — not the screening provider — owns the outcome, the review of any flag, and the record that supports it.
Summary and Next Steps
AML API integration turns screening from a manual search into an automatic, recorded step in the platform: sanctions, PEP, adverse-media and wallet checks run at onboarding, on transactions and on a schedule, returning a structured result the platform can act on and a durable evidence record the firm can retain. It matters because screening at real volume has to be consistent, repeatable and easy to evidence, and because the lists behind it change too often for a one-off manual check to be enough.
Building it well means deciding which checks run synchronously and which run periodically, keeping both the machine-readable result and the human-readable evidence, pairing the automatic API with a panel for the cases that need a person, and holding the line between the signal the API raises and the decision the firm owns. Designing that in from the start is an exercise in regulatory readiness rather than a control retrofitted under supervisory pressure later.
Integrating AML screening into a regulated platform? Grumpio designs and implements sanctions, PEP and wallet screening that fit the onboarding and monitoring flows of a crypto, e-money or payments operation.