A KYT API integration calls the screening endpoint on every deposit and withdrawal, parses the returned risk score, and routes the transaction before funds move. Batch screening and ongoing monitoring layer on top for history and address drift. The API belongs inside the transaction flow rather than running beside it, because real-time checks catch risky activity before settlement while batch jobs and monitoring cover everything in between. This guide walks through all three modes for a crypto exchange. For the broader workflow, see Phalcon Compliance. This page is part of the AML Compliance Hub.
Why Exchanges Need API-Level Real-Time Screening
The screening cadence an exchange picks is also the laundering window it accepts. A weekly or daily batch job screens every address at the moment the batch runs, but every deposit that arrives between batches enters the wallet unchallenged. Funds can land, move, and cash out inside that gap. Real-time API-level screening closes the gap because every deposit and withdrawal is checked before the transaction is released.
The driver is not only operational. FinCEN requires money services businesses, including crypto exchanges, to maintain an AML program (31 CFR 1022.210) and to report suspicious transactions (31 CFR 1022.320), read with its 2019 virtual currency guidance (FIN-2019-G001). In practice that combination is what makes ongoing monitoring necessary rather than a fixed real-time threshold. The FATF risk-based approach for virtual asset service providers converges on the same ask, obliging VASPs to monitor transactions on an ongoing basis rather than as a one-time check at onboarding. An exchange satisfies both by keeping a live control on every deposit and withdrawal, which is exactly what the real-time API mode described below provides. A batch-only cadence leaves a detectable distance between the duty to monitor and the control that actually runs. Examiners read that distance as a program gap, not as a deployment preference.
The developer side of the problem is its own constraint. No combination of off-the-shelf third-party tools fits an exchange's use case until those tools actually get access to internal systems, so integration, not feature count, is the underrated battle. A screening engine that cannot talk to the deposit flow, the withdrawal flow, and the alert routing path does not change what the exchange can catch. It only changes a dashboard. The integration work is what turns a screening capability into a screening program.
Pre-Integration Prep: Risk Thresholds, Alert Routing, System Access
Before any API call is written, three decisions have to be locked. They govern what the integration actually does once it is live, and changing them after deployment means reworking both the API client and the downstream alert path. These three decisions sit inside the broader AML compliance program for a crypto exchange, which covers risk assessment, screening, triage, and auditable records. This page focuses on the API integration layer of that program rather than on the program structure itself.
The first decision is the risk threshold rule set. A KYT API returns a risk score, but the score does nothing until the exchange decides which score bands trigger which action. A common shape is three bands: low risk clears the transaction automatically, medium risk holds the transaction for manual review, and high risk blocks the transaction and opens an alert. The thresholds have to be defined as code, not as policy, because the API client will route on them programmatically.
The second decision is alert routing. When a risk score crosses a threshold, the alert has to reach a human or a queue. The routing design covers which channel carries the alert, whether that is a webhook into a Slack or Telegram channel, a ticket in a case management tool, or an entry in an internal queue. The platform supports multichannel notifications including webhook, and the routing has to be mapped before the integration goes live, not bolted on after the first missed alert.
The third decision is plan gating. API access is available only on the Scale tier, starting at $699 per month, and on the Enterprise tier; the Free, Screening Packages, and Essential tiers do not include API access. A team that wants to embed screening inside its own deposit or withdrawal flow needs to reach the Scale tier first. Confirming that before integration starts avoids the situation where the code is written against a tier the team cannot actually use. Multi-seat team collaboration, if the compliance function needs more than one seat working inside the tool, is available only on Enterprise. How that gate sits inside the wider crypto AML compliance program is laid out on the hub page.
Integrate the Phalcon Compliance KYT and KYA API: Three Modes
The Phalcon Compliance API supports real-time checks, asynchronous CSV batch screening, and continuous monitoring. Real-time checks cover deposits and withdrawals. Batch screening covers historical addresses and backlogs. Monitor watches previously screened addresses for changes in risk. Exchanges can combine the three modes based on where and when screening is needed.
An exchange deposit and withdrawal flow has three screening needs that do not collapse into one. A live transaction needs an answer before it is released, which means a synchronous, low-latency call. A backlog of historical addresses needs to be screened in bulk without blocking the live flow, which means an asynchronous job. And an address that was clean at first screening can transact with a risky counterparty later, which means a continuous watch on already-screened addresses rather than a one-time verdict.
Phalcon Compliance exposes its screening API in three modes that map to those three needs. A real-time single-check mode covers the deposit and withdrawal gate. An asynchronous CSV batch mode covers backlog and historical screening. A continuous Monitor mode re-analyzes already-screened addresses on a dynamic schedule. The three modes share one authenticated surface, so a single API key governs access to all of them, and the exchange picks the mode per call rather than maintaining separate integrations.
| Mode | Trigger | Latency | Quota and rate limit | Use case |
|---|---|---|---|---|
| Real-time single check | Single address or transaction | Millisecond-level | 50 calls per minute per API key | Live deposit and withdrawal screening |
| Asynchronous CSV batch | CSV upload | Asynchronous | Address CSV up to 100 per file; Transaction CSV up to 400 per batch | Backlog and historical screening |
| Monitor | Continuous | Dynamic schedule | Does not consume Screening quota | Re-analysis of already-screened addresses on risk change |
The integration sequence is the same across all three modes. The client authenticates with the API key issued by the platform. It calls the screening endpoint with the address or transaction identifier. It parses the returned risk score, including the risk indicators and exposure figures that attach to the score. It routes on the threshold rules defined in pre-integration. And it emits the alert through the configured webhook or notification channel when a threshold is crossed. The screening API is rate-limited to 50 calls per minute per API key, and calls past that limit receive an HTTP 429, so the client has to handle 429 with backoff rather than retry-on-error.
BlockSec specifies real-time single-check latency as millisecond-level. Treat it as a figure to confirm against the team's own traffic: build the integration to tolerate latency rather than assume a specific millisecond target, and measure any internal SLA the exchange sets against production traffic.
Rate Limits, Quotas, and Plan Gating: Engineering Notes
The rate limit is the first engineering constraint the integration hits. The screening API is rate-limited to 50 calls per minute per API key, and calls past that limit receive an HTTP 429. For a live deposit flow that is rarely a binding constraint, because deposits arrive one at a time and a real-time check finishes before the next call. For a bulk operation it is, because screening a backlog of thousands of addresses synchronously would burn through the limit in minutes. The CSV batch mode exists precisely to move that load off the synchronous path. CSV Address screening accepts up to 100 addresses per file, and CSV Transaction screening accepts up to 400 transactions per batch. A backlog is therefore processed asynchronously, without competing with the live gate for rate-limit budget.
The quota model is the second constraint. Screenings draw down a balance, and the draw happens in a defined order. Subscription quota resets each cycle, then Top-up Screenings are consumed, then Referral Rewards, then Screening Packages. The integration does not need to pick which balance to use. The compliance team that owns the budget does need to understand the order, because it determines which balance is depleted first and when a top-up becomes necessary. Monitor mode is the exception. Monitor runs on a dynamic schedule and re-screens already-screened addresses when their risk changes, and it does not consume the Screening quota, so leaving Monitor on does not tax the per-check budget.
Plan gating is the third constraint and it is non-negotiable. As covered above, API access requires the Scale tier, starting at $699 per month, or the Enterprise tier; the Free, Screening Packages, and Essential tiers do not include API access. Beyond that gate, two add-on capabilities shape scope: webhook access lands on Scale or Enterprise, while custom Risk Engine configuration is available from the Screening Packages tier upward (3 engines on Screening Packages, 10 on Essential, 20 on Scale, unlimited on Enterprise), and multi-seat collaboration inside the tool is an Enterprise feature. The pricing detail behind those tiers is covered in the dedicated pricing Spoke; this page only covers the gating that affects how the API integration is planned.
Read the Phalcon Compliance API Docs
A KYT API integration is not finished when the first call returns a score. It is finished when the live gate, the backlog path, and the Monitor watch are all wired into the exchange's deposit and withdrawal flow. Thresholds are defined as code, alerts route to a real queue, and plan gating is confirmed before the first call. Read the Phalcon Compliance API docs for the endpoint reference, the webhook contract, and the Scale-tier trial path.