A deposit lands from a wallet that looks clean on the surface. The compliance team has seconds, not hours, to decide whether to release it, hold it, or escalate. Real-time transaction risk scoring is the machinery that makes that decision defensible: it scores each transaction against known risk intelligence and behavioral patterns before the funds move further. This page, a child of the real-time KYT scoring platform hub, covers the detection architecture, not the compliance obligation itself. For the obligation layer and the risk-stratified disposition matrix, see the KYT compliance obligations page. Here the focus is how risk gets scored, and where batch screening leaves a gap.
The Four Risk Signals KYT Scores in Real Time
Risk scoring begins with signal identification. Phalcon Compliance evaluates every screened address and transaction against 17 risk indicators, and four signal classes carry most of the weight in a real-time decision. Mixer exposure is flagged by the Mixing indicator, which marks wallets that have interacted with coin mixing services. Darknet exposure is covered by two indicators: Dark Market and Darkweb Business, which surface wallets tied to illicit marketplaces. Sanctions exposure is covered by the Sanctioned indicator. Two further indicators flag addresses linked to high-risk or grey-listed countries: FATF High Risk Jurisdiction and FATF Grey List Jurisdiction. The fourth signal is cross-chain exposure, where funds route through bridges or multi-chain hops to break a single-chain trace. Cross-chain appears here as one signal class among four. The tracing methodology that penetrates bridges, DeFi paths, and mixers across chains is a separate topic outside this page's scope.
Each signal maps to the Risk Exposure Engine, which evaluates whether the screened target connects to a known risk entity. The engine uses an Interaction Risk template that traces fund flows across multiple transaction hops. If any address along the path carries a risk label, the engine fires an alert based on customizable rules covering transfer direction and value threshold. Exposure Value quantifies the total USD amount of assets that originated from or interacted with a risk source. Exposure Percentage expresses the tainted share relative to total inflow or outflow. These two metrics turn a binary clean or dirty verdict into a graded score a compliance officer can act on.
The four signal classes align with the FATF virtual assets risk framework, which expects VASPs to apply risk-based controls across on-chain exposure rather than only at onboarding. A screen that checks only the direct sender misses contamination two or three hops upstream. The Exposure Engine is what closes that gap in real time.
AI Behavioral Modeling for Patterns Rules Cannot Catch
Rule-based screening catches what is already labeled. AI behavioral modeling catches what is not yet labeled but behaves like illicit flow. The Behavioral Risk Engine runs three address templates to flag patterns rules miss: Large-Value Transfers, High-Frequency Transfers, and Transit Address. It also runs two transaction templates: Large-Value and Rapid Transit.
Large-Value Transfers flags addresses where a single transfer exceeds a threshold set against typical user behavior. High-Frequency Transfers catches wallets making many small transfers below the alert threshold, a classic smurfing or layering signature. Transit Address detects wallets that receive funds and move them out quickly, the intermediary pattern common in laundering chains. On the transaction side, Rapid Transit flags transfers where funds are pulled out within a short window after arrival, indicating layering or evasion.
Beyond the manual templates, the platform integrates an AI behavioral model that identifies patterns such as rapid in-and-out movement, address peeling, and micro-amount splitting. The model covers newly generated wallets too, which carry no history and no labels but can still exhibit laundering behavior on their first transactions. This is where rule-based screening alone falls short. A legacy AML tool that screens only against a static label database reads a fresh wallet as clean. That holds even when the wallet's first action is to split a large inflow into dozens of micro-transfers. The AI layer, running alongside 200-plus risk signals, catches the behavior the labels have not yet caught.
Mixer Detection: Signals, Hops, and the Limits of Labels
Mixer detection is the hardest problem in real-time scoring, because the whole purpose of a mixer is to break the trace between deposit and withdrawal. Phalcon Compliance approaches this through the Mixing risk indicator, one of the 17 in its indicator list. When a screened address or any address in its fund-flow path has interacted with a known mixer, the Risk Exposure Engine flags the exposure. It does so through its Interaction Risk template, which traces fund flows across multiple transaction hops.
The engine does not stop at the direct counterparty. Interaction Risk follows the fund path across hops, and if any hop connects to a mixer-labeled address, the customizable rule fires. This multi-hop tracing is what separates a surface-level screen from a deeper one. It catches contamination routed through intermediate wallets before it reaches the platform. The platform also supports cross-chain tracing with unlimited hops. It penetrates DeFi paths, mixers, and bridges rather than halting at the first counterparty on a single chain.
The deeper detection question is whether a mixer deposit pattern can be identified from the behavior itself, before a label exists. BlockSec's published research has examined mixer interaction signatures, but the precise deposit-pattern methodology is not documented in the platform's product specifications. This article therefore carries the detection capability at the qualitative level: the Mixing indicator, the Interaction Risk multi-hop trace, and the unlimited-hop cross-chain penetration together form the detection surface. Anything beyond that, including specific deposit-pattern heuristics, is left to the underlying research rather than asserted here as a product fact.
Real-Time Versus Batch Architecture and the Detection Window
The architecture a compliance team chooses determines the size of its detection window. A real-time API screen scores a transaction in milliseconds before the funds are released. A batch screen scores a weekly CSV upload after the funds have already moved. The gap between those two points is where risk hides.
Real-time screening runs through the single-address and single-transaction API endpoints. A single address screen returns synchronously when it completes within ten seconds. If processing takes longer, the call converts to an asynchronous task and returns a Task ID the client polls. Batch address screening is always asynchronous and returns an array of Task IDs. The screening endpoints are rate-limited to 50 calls per minute per API key, and the API is available on the Scale and Enterprise plans. Batch CSV screening handles up to 100 addresses per file and up to 400 transactions per batch. Monitor, the continuous re-analysis layer, runs on a dynamic schedule without consuming screening quota, and pushes notifications when risk changes.
The architectural difference maps to the detection window. A real-time API screen scores a deposit before the platform releases the funds. If the screen flags the address, the platform can hold the transfer. A weekly batch screen scores the same deposit days later. By then the funds have moved on, the counterparty may have changed, and the only remaining action is retrospective escalation. Monitor closes a third gap: an address that was clean at the real-time screen but gets flagged days later. Monitor re-runs on its dynamic schedule and notifies the team when the risk level changes, an alert triggers, or an alert expires. The combination of real-time screening at each control point plus continuous monitoring is what keeps the detection window closed. For a broader technical review of how KYT platforms structure these capabilities, see the KYT platform technical review. For the AML monitoring obligations that make this architecture necessary, see the FinCEN guidance on money laundering obligations.
Assess Your Real-Time Risk Scoring Posture
Real-time transaction risk scoring reduces to three capabilities working together. The four signal classes, mixer, darknet, sanctions, and cross-chain, cover the exposure a label-only screen misses. The AI behavioral model covers the patterns no label has caught yet, including newly generated wallets. The millisecond API plus continuous monitoring covers the time window, so an address flagged three weeks after a clean screen still surfaces. Phalcon Compliance is built against that shape. Its 17 risk indicators feed the Exposure Engine, and five behavioral templates feed the Behavioral Risk Engine. The AI model runs alongside 200-plus risk signals, processing over 500 transactions per second with millisecond-level API response.