A real-time KYT API answers one question at the only moment it can still change the outcome: before the transaction is released. On-chain transfers are irreversible, so once a deposit or withdrawal is broadcast, the only remaining options are investigation and reporting. Pre-transaction screening moves the decision earlier, into the window where a high-risk counterparty can still be blocked or held. This guide stays inside that pre-tx window - why it matters, the latency requirement, how the API returns a decision, the block/hold/allow disposition, when to use real-time versus batch versus monitor, and a pre-tx integration checklist. For the full KYT surface, see Phalcon Compliance. This page is part of the KYT Resource Center.
Why Pre-Transaction Screening Matters
The irreversibility of on-chain transfers is the structural reason pre-tx screening exists. A fiat wire can be reversed, recalled, or frozen through correspondent banking. A blockchain transfer cannot. Once it is confirmed, the funds belong to the recipient, and the only recourse is post-hoc investigation, law enforcement requests, or an STR filing. By that point the funds have often moved again. A control that runs only after the transaction settles is, in effect, a control that runs after the harm.
Post-transaction monitoring cannot replace a pre-transaction check. The FATF risk-based approach for virtual asset service providers obliges VASPs to monitor transactions on an ongoing, risk-sensitive basis, not as a single onboarding check. FinCEN frames continuing AML monitoring obligations under its AML program rule for money services businesses (31 CFR 1022.210) in the same direction for crypto exchanges and other US money services businesses. Neither framework specifies a hard latency number, but both expect the control to actually run on the transaction it governs. A program that detects risk only after the funds have moved has a gap examiners read as a program weakness, not a deployment preference.
The economics favor the earlier decision. Blocking a high-risk deposit at the gate costs one API call. Chasing the same deposit through three hops across mixing services costs an analyst days, and recovery is rare. Pre-tx screening is the difference between a control that prevents and one that reports.
How Fast a Screening Call Must Return
Pre-tx screening is bounded by user experience, not by vendor capability. A withdrawal that sits for two seconds while a screen runs feels broken. A deposit held for ten seconds while an analyst reviews it feels frozen. The latency budget for a pre-tx decision is therefore tight, measured in hundreds of milliseconds, not seconds. A common working ceiling is roughly 500 milliseconds end to end, from the moment the transaction hits the gate to the moment the allow, hold, or block decision is returned. Below that ceiling, the screen is invisible to the user. Above it, the screen starts to look like friction, and friction drives users to bypass the control.
The ideal target is lower. Sub-100 millisecond response, from the API itself, leaves room for the rest of the gate to run. Network round trip, internal routing, logging, and the threshold decision all consume budget on top of the raw API call. If the API alone consumes 300 milliseconds, the rest of the stack has nothing left. Latency is not a feature on a spec sheet. It is the difference between a control that runs in line with the transaction and one that races it.
BlockSec specifies millisecond-level latency for its real-time screening API. Treat it as a target to confirm against production traffic before building an internal SLA on top of it. A gate that assumes 50 milliseconds and actually sees 400 will degrade before the first alert fires. The gate has to measure the real number and degrade gracefully when it is missed.
How a Real-Time KYT Screening API Works
A real-time KYT screening API sits in the decision path of the transaction, not next to it. The flow has four steps that have to complete inside the latency budget. The client authenticates and submits the address or transaction identifier. The API resolves the address against its risk data and returns a risk score with the evidence behind it. The client's gate then maps the score to a disposition - block, hold, or allow - using thresholds defined as code, and releases or intercepts the transaction. The call is synchronous and single-address, because the decision has to come back before the transaction is released.
Phalcon Compliance exposes its real-time screening API in exactly this shape. A single API key governs access. The call returns a risk score, the exposure figures behind it, and the risk indicators that drove the score. The risk data is built on more than 600 million labeled addresses and over 17 risk indicator categories, covering behavioral patterns, exposure to known illicit services, and counterparty risk. The score is what the gate routes on. The indicators and exposure figures are what an analyst reads if the transaction is held for review, and they are what make the decision auditable rather than opaque.
Two constraints shape how the API is used. First, access is gated to the Scale tier, starting at $699 per month, and the Enterprise tier. The Free, Screening Packages, and Essential tiers are for interactive screening through the platform interface, not for embedding inside a transaction gate. A team building a pre-tx screen has to be on Scale or Enterprise before the first call is written. Second, the latency figure - a millisecond-level response for the real-time API - is what determines whether the API can serve a pre-tx gate or has to fall back to a post-tx monitor. Confirming the real number under the team's own load is part of going live, not a formality after it.
Block, Hold, or Allow: Decide Before Funds Move
A real-time screen is only useful if the gate knows what to do with the answer. The framework that fits pre-tx screening is a three-band layered disposition, not a binary allow-or-flag. The bands are defined by the risk score, and each carries a specific action the gate executes without waiting for a human.
The first band is allow. Low-risk addresses clear automatically, in line, inside the latency budget, and this band has to be the majority of volume. The second band is hold. Medium-risk addresses do not clear and are not blocked. The transaction is paused, an alert is routed to a review queue, and an analyst decides the disposition with the risk indicators and exposure figures in front of them. Hold catches the cases where the score is ambiguous and human judgment is worth the delay. The third band is block. High-risk addresses are intercepted before release, the transaction is not broadcast, and an alert opens with the full evidence trail. Block is the band that does the prevention work post-tx monitoring cannot.
| Band | Risk score | Action | Latency impact | Review path |
|---|---|---|---|---|
| Allow | Low | Release in line | None | None |
| Hold | Medium | Pause and route to queue | Transaction waits | Analyst reviews indicators and exposure |
| Block | High | Intercept before release | Transaction not broadcast | Alert opened with evidence trail |
The strength of this framework is in the audit chain, not just the decision. Every disposition has to be reproducible: which score was returned, which band it fell into, which indicators drove it, and which action the gate took. A block has to be justifiable as a decision based on evidence, not a heuristic. A hold has to be auditable as a pause that was actually reviewed and resolved, not a transaction quietly dropped. The risk indicators and exposure figures are what make the chain complete. Without them, the disposition is a verdict. With them, it is a documented decision an examiner or auditor can read.
Real-Time vs Batch vs Monitor - When to Use Which
Pre-tx screening is not the only screening mode, and confusing the modes is a common failure pattern. A real-time KYT API runs in three modes, each answering a different question. Real-time single check answers "is this transaction safe to release now." Batch screening answers "what is the risk profile of this backlog." Monitor answers "has the risk on an address we already screened changed since we last looked." The three modes do not collapse into one, and using the wrong one either burns quota or misses risk.
Real-time single check is the pre-tx mode. It is synchronous, low-latency, and runs once per transaction at the gate. Batch screening is asynchronous, runs on CSV uploads against historical backlogs, and does not run inside the transaction path. Monitor is continuous. It re-analyzes already-screened addresses on a dynamic schedule and fires when risk on a previously clean address changes - for example, when a counterparty is later sanctioned.
The practical split: real-time handles the live gate, batch handles the backlog, monitor handles the drift. A program that runs only real-time is blind to risk that emerges after the first screen. A program that runs only monitor has no pre-tx decision. A program that runs only batch has neither. The sound setup uses all three, each in its lane. Monitor mode notably does not consume the Screening quota, so leaving it on does not tax the per-check budget that real-time and batch draw from. This page stays inside the real-time lane; wiring all three into an exchange flow is a separate integration topic.
Integration Checklist for Pre-Tx Screening
A pre-tx screening gate is finished when it can answer for any transaction what disposition it took, why, and how long the decision took. The checklist below is the real-time view, focused on the gate itself.
-
Confirm the API tier. Real-time API access requires the Scale tier, starting at $699 per month, or Enterprise. Confirm before writing the first call.
-
Set the latency budget in code. Define the ceiling for the full screening path - commonly around 500 milliseconds - and measure the real round trip on production traffic. Treat the published millisecond-level response as a target to confirm, not an assumption.
-
Define threshold bands as code. Block, hold, and allow must be programmatic, routing on the returned risk score. Policy that lives in a document but not in the gate does not run on the transaction.
-
Wire the alert path before going live. Holds and blocks must reach a real queue - a webhook, a ticket, or an internal channel. Routing bolted on after the first missed alert is already a failure.
-
Persist the evidence with every disposition. Score, threshold band, risk indicators, and exposure figures must be stored with the transaction record. The disposition must be reproducible months later.
-
Build the degradation path. If the API exceeds the latency budget or errors, the gate must fail in a defined direction - hold for review, or allow with a post-tx monitor flag - not silently drop the transaction.
-
Handle rate limits. The screening API is rate-limited per key, and calls past the limit return HTTP 429. The client must back off, not retry on error.
-
Turn Monitor on for drift. Pre-tx screening catches risk at the gate. Monitor catches risk that emerges after. Monitor does not consume Screening quota, so it can stay on without taxing the real-time budget.
A gate that clears this checklist runs the pre-tx decision inside the transaction path, with thresholds that fire, alerts that reach a human, evidence that persists, and a degradation path that fails safe. That is what real-time pre-tx screening means in practice. Read the Phalcon Compliance KYT API docs for the endpoint reference, the Scale-tier entry path, and the full risk-indicator schema.
