Key Takeaways
- Most Know Your Transaction (KYT) programs fail regulatory examinations not because the monitoring software missed a transaction, but because operators cannot evidence the human decisions made after an alert fired.
- Know Your Customer (KYC) is a point-in-time identity snapshot. A user with an unblemished onboarding file can easily receive funds two hops from a sanctioned entity months later; only continuous, automated transaction monitoring catches this drift.
- Frameworks including FATF Recommendations, MiCA, the U.S. Bank Secrecy Act, MAS, and VARA explicitly mandate risk-based transaction monitoring as a core legal obligation for digital asset operators.
- Standalone third-party tools that sit outside the core transaction execution path often fail to block high-risk transfers before settlement. Modern platforms require compliance tooling embedded natively into the deposit and withdrawal pipelines.
A user clears your onboarding process cleanly. Name verified, source of funds documented, risk rating assigned. Ninety days later, funds arrive in their account two hops from a sanctioned entity. Nothing in their Know-Your-Customer (KYC) file has changed. The file still looks fine. But the money trail does not.
This is the decay problem. Identity verification is a snapshot taken at a single point in time. On-chain activity is continuous, and the risk profile of any given address changes every time a new counterparty touches it. KYC tells you who walked through the door. It cannot tell you what they did after. That gap is exactly where Know-Your-Transaction (KYT) operates.This is precisely where most compliance programs fail under regulatory examination, usually not because the monitoring missed the transaction, but because the operator could not show what it did once the alert fired.
KYT is the layer of crypto AML compliance that monitors blockchain transactions in real time, tracing fund flows, assessing counterparty exposure, and generating risk scores on every deposit and withdrawal. Think of it as the alarm system that runs after the locks are in place. Without it, exchanges, Virtual Asset Service Providers (VASPs), Crypto-Asset Service Providers (CASPs), and Web3 infrastructure operators are making risk decisions based on information that may be months out of date.
What Do Crypto Regulators Actually Expect From Compliance Programs?
Crypto compliance is not a separate discipline invented for digital assets. Regulators are applying the same Anti-Money Laundering (AML) and counter-terrorist financing expectations that have governed TradFi banks for decades: know who you are dealing with, understand the source and destination of funds, monitor activity on an ongoing basis, escalate what looks anomalous, and be able to evidence every decision you made. What changes in crypto is the medium, not the standard. The ledger is public, settlement is close to irreversible, and the counterparty is frequently an address rather than a named institution.
In correspondent banking, an operator can hold a payment, request more information, and reverse a transfer. On-chain, once a withdrawal confirms, the funds are gone. Regulators know this, which is why the supervisory focus has shifted from periodic review toward controls that operate before settlement.
The second thing examiners look for is proportionality. Supervisors are not asking operators to apply a uniform rule to every user and every transfer. They expect controls calibrated to the actual risk each asset holder presents, based on their transaction behavior, counterparty exposure, jurisdiction, and product usage. A blanket threshold applied identically across the book is treated as evidence that the operator has not performed a risk assessment at all. A documented, risk-based tiering, where higher-exposure holders receive tighter screening and enhanced due diligence, is what a defensible program looks like.
Singapore: What MAS Expects Under Notice PSN02
The Monetary Authority of Singapore (MAS) provides a clear framework for operationalizing these requirements. Under the Payment Services Act, digital payment token service providers must maintain a comprehensive AML/CFT program rather than a static checklist.
In practice, examiners look for four things:
- Enterprise-wide risk assessment: A documented assessment that justifies the controls chosen.
- Proportionate Customer Due Diligence (CDD): CDD tailored to assessed risk, including enhanced due diligence and source of wealth verification for higher-risk holders.
- Contextual transaction monitoring: Ongoing monitoring against the expected profile of that specific customer rather than a generic baseline.
- Rigorous reporting: Prompt suspicious transaction reporting backed by a clear audit trail.
MAS also applies the Travel Rule to transfers at a SGD 1,500 threshold and expects screening of counterparty VASPs, not just of the customer.
The operative phrase in Singapore supervision is “ongoing monitoring.” MAS is explicit that onboarding diligence alone does not satisfy the obligation. An operator has to demonstrate that it kept watching, that it noticed when behavior diverged from the profile it recorded at onboarding, and that it acted on what it noticed.
How Other Jurisdictions Frame the Same Obligation
The wording differs by regime, but the expectation converges. FATF Recommendations 15 and 16, MiCA and the EU Transfer of Funds Regulation, the US Bank Secrecy Act, and Dubai’s VARA rulebook all require risk-based transaction monitoring and Travel Rule data transmission on qualifying transfers. The comparison table further down sets out who each regime applies to and at what threshold. For operators serving several markets, the practical answer is to build to the strictest applicable standard rather than maintain parallel control sets.
Where KYT Fits Against KYC and KYB
KYT (Know Your Transaction) is the control that operationalizes the ongoing monitoring obligation. It is a real-time blockchain transaction monitoring framework that assesses the risk profile of individual transactions by analyzing fund origins, destinations, counterparty exposure, and behavioral patterns. It is distinct from Know-Your-Customer (KYC) and Know-Your-Business (KYB), which operate at the identity and entity verification layer and satisfy a different part of the same rulebook.
The three controls serve different purposes and catch different failure modes:
| KYC | KYB | KYT | |
| What it checks | Individual customer identity | Business entity legitimacy | Transaction-level fund flows and counterparty exposure |
| When it runs | At onboarding; periodic refresh | At onboarding; periodic refresh | Continuously, on every transaction |
| What it catches | Synthetic identities, document fraud, sanctions matches at point of onboarding | Shell companies, unlicensed entities, corporate sanctions matches | Structuring, layering, mixer exposure, sanctions drift, cross-chain obfuscation |
| What it misses | Post-onboarding behavioral risk, counterparty changes, sanctions added after verification | Same limitations as KYC applied to entities | Cannot verify the real-world identity behind a wallet |
KYC tells you the user identity. KYT tells you what they are doing. Neither works alone. And a compliant program needs both while sequenced correctly.
How Does KYT Actually Work?
Address Clustering and Heuristics
Address clustering groups wallets that are likely controlled by the same entity, based on common input ownership heuristics, behavioral patterns, and co-spend analysis. Doing this manually is not viable at volume, which is the practical case for KYT. A KYT system maintains the clustering graph continuously, attributes newly observed addresses to known entity clusters as they transact, and inherits the risk attribution of the cluster onto every address inside it.
The compliance value is attribution rather than list-matching. KYT allows a platform to recognize that a deposit from a brand new address is functionally connected to a wallet cluster already flagged for illicit activity, even if that specific address has never appeared on any sanctions list. It also works in the other direction: when a single address is designated or tied to an exploit, KYT propagates that flag across the full cluster and rescreens historical counterparties against it. That is the difference between screening addresses and screening entities, and it is the level at which examiners assess whether an operator can actually identify who it is transacting with.
Counterparty Exposure: Direct vs. Indirect
Counterparty exposure is assessed at two levels. Direct exposure covers funds received immediately from, or sent directly to, a flagged entity. Indirect exposure covers funds that passed through intermediate wallets before reaching the platform. Both matter for regulatory purposes, but indirect exposure requires hop tracing to detect.
Hop Tracing and Taint
Hop tracing follows funds backward (and forward) through the transaction graph, recording the percentage of value at each step that originated from a flagged source. Consider a concrete example: a user deposits funds to an exchange from Wallet A. Wallet A received those funds from Wallet B, which received them from Wallet C, which received them directly from an address tagged in a publicly documented exploit. The deposit is three hops from the exploit address. Depending on the percentage of tainted value and the platform’s threshold settings, that transaction should trigger a review, not a straight clearance.
Risk Scoring and Threshold-Setting
KYT tools produce a risk score for each transaction based on the volume of direct and indirect exposure to flagged categories, including sanctioned entities, mixers, darknet markets, ransomware wallets, and high-risk exchanges. Platforms configure thresholds that determine when a score triggers an alert, requires enhanced review, or blocks a transaction outright. Threshold-setting is a documented compliance decision, not a default configuration.
KYT risk scoring flow:
Transaction in → address clustering and graph analysis → direct and indirect exposure calculation → category weighting → risk score → alert
Rules-Based Screening vs. Behavioral Detection
Rules-based screening checks addresses against known flagged entities. Behavioral detection identifies anomalous patterns, such as sudden velocity changes, fan-in patterns consistent with aggregation ahead of laundering, or fan-out patterns consistent with layering and structuring. Either alone fails: rules-based screening misses novel threat actors with no prior flags; behavioral detection without rules creates alert noise that buries genuine risk. A functioning KYT program uses both.
What Fraud and Risk Does KYT Catch That KYC Cannot?
Structuring and Smurfing
Structuring involves breaking large transactions into smaller ones designed to stay below reporting thresholds. On-chain, this appears as a cluster of deposits from multiple wallets, often sequenced within a short time window, each individually unremarkable. KYT’s behavioral detection layer identifies the aggregated pattern that no single transaction would trigger.
Layering Through DEX Swaps
Funds are cycled through Decentralized Exchange (DEX) liquidity pools to obscure their origin. Each swap changes the asset and the address trace, making manual analysis impractical. KYT tools that track cross-pool flows can follow value through swap sequences and flag the resulting exposure.
Mixer and Privacy-Tool Exposure
When funds pass through a mixing protocol, the transaction graph breaks. KYT tools detect mixer interaction either directly (address tagged as a mixer input or output) or indirectly (behavioral signatures consistent with mixer output, such as normalized transaction amounts and timing patterns). Both Office of Foreign Assets Control (OFAC) and Financial Action Task Force (FATF) treat mixer exposure as a material risk indicator.
Cross-Chain Bridge Obfuscation
Assets are bridged from one blockchain to another specifically to break transaction graph continuity. A platform monitoring only one chain sees only one leg of the movement. KYT infrastructure with multi-chain coverage connects the originating chain activity to the destination chain deposit.
High-Velocity Fan-In and Fan-Out Patterns
Fan-in patterns, where many addresses funnel funds into a single wallet in rapid succession, are consistent with aggregation before laundering. Fan-out patterns, where a single wallet distributes to many addresses quickly, are consistent with layering or payout to a network. Neither requires any individual transaction to be large or to involve a previously flagged address.
Sanctions Exposure Acquired After Onboarding
A counterparty sanctioned six months after a user’s onboarding date does not appear in that user’s KYC file. KYT’s continuous monitoring catches the first transaction that touches a newly designated address and flags the exposure regardless of when the original sanctions listing occurred.
Where Do KYT Programs Fail?
- Over-Automation: A risk score is evidence, not a decision. Programs that auto-approve below a threshold and auto-block above it remove the analyst judgment that regulators expect to see documented. When an examiner reviews a suspicious transaction that cleared, “the score was 24 and the threshold was 25” is not a defensible answer.
- Black-Box Scoring Without Documented Thresholds: If the compliance team cannot explain why a threshold is set where it is, and cannot produce documentation showing that the threshold was deliberately chosen and periodically reviewed, the audit exposure is significant. Scoring logic needs to be explainable and recorded.
- False Positives and Alert Volume: An over-sensitive configuration generates alert volumes that a small compliance team cannot process. The result is queue backlog, delayed withdrawals for legitimate users, and the kind of alert fatigue that causes genuine risk to be missed. Calibration is an ongoing operational task, not a one-time setup.
- Unhosted Wallet Edge Cases: Unhosted wallets present a specific challenge. There is no VASP counterparty to request Travel Rule data from, and the wallet’s on-chain history must carry the full compliance burden. Programs that treat unhosted wallet deposits identically to VASP transfers are either over-blocking legitimate users or under-screening genuine risk.
- Counterparties on Incompatible Travel Rule Protocols: The Travel Rule protocol landscape remains fragmented. When a counterparty VASP operates on an incompatible protocol, data transmission fails silently or not at all. This is a known gap that requires procedural escalation paths, not an assumption that the transfer cleared correctly.
- Bolt-On Tooling Outside the Transaction Flow: KYT tooling that sits outside the core transaction system can monitor and report, but it cannot block before settlement. If an alert is generated after funds have already moved on-chain, the remediation options are significantly narrower. Integration at the transaction flow level, not the reporting layer, is a fundamental architectural requirement.
Operationalizing KYT: Sequencing, Workflows, and Architecture
Sequencing
The correct sequencing for a new platform is: identity verification infrastructure before launch, transaction monitoring before meaningful volume reaches the platform, and Travel Rule tooling before cross-border transfers begin. Implementing KYT retrospectively, once transaction volume has grown, creates a backlog of unreviewed historical activity and a gap that regulators will find.
Integration Points
KYT should screen at three points: deposit screening before funds are credited, withdrawal screening before funds leave the platform, and periodic portfolio rescreening to catch counterparties sanctioned after initial clearance. Deposit-only screening is insufficient.
The Operating Workflow
A functioning workflow runs from alert generation through triage, escalation, decision, and documented outcome. Each step requires a timestamp and an accountable analyst. The workflow is not complete until the outcome is recorded, whether that is a cleared transaction, a blocked transfer, or a filed SAR.
Audit Trail Requirements
Every alert, every triage decision, every override, and every escalation needs to be logged with sufficient detail to reconstruct the compliance decision under examination. Regulators reviewing a program failure will look at what information was available, what decision was made, and whether that decision was documented. Gaps in the audit trail are treated as gaps in the program.
Build vs. Buy vs. Infrastructure-Native
Building a proprietary KYT system requires sustained investment in analytics vendor relationships, graph database infrastructure, and ongoing model maintenance. Buying a standalone KYT tool adds an integration layer that may sit outside the transaction flow. Infrastructure-native KYT, built into the compliance layer of the exchange or wallet system itself, removes the integration gap and positions screening within the transaction execution path rather than alongside it.
Enterprise Compliance With ChainUp KYT
Return to the scenario from the introduction. The user who cleared onboarding ninety days ago has not changed. The risk environment around them has. Sanctions lists are updated daily. New exploit addresses appear with each protocol attack. Mixer usage patterns shift as regulators target specific tools. A static identity check cannot track any of that.
KYT is the control that turns compliance from a point-in-time event into a continuous process. It does not replace identity verification. It extends it forward in time, covering the full duration of a customer relationship rather than just the moment of entry. Platforms that operate without it are not simply under-resourced. They are structurally blind to a category of risk that regulators have explicitly defined, measured, and begun enforcing.
The question is not whether blockchain transaction monitoring is necessary. It is whether the implementation is deep enough to actually intercept risk before settlement and documented well enough to survive examination.
ChainUp’s KYT and blockchain transaction monitoring solution is built into the compliance infrastructure layer, not bolted on after the fact. With MiCA enforcement and the Travel Rule now fully in effect across major jurisdictions, and transaction volumes continuing to grow past the point where manual review is viable, the cost of a misconfigured or absent KYT program is measurable in regulatory action, not just operational inconvenience. Book a demo to see how ChainUp’s KYT solution fits into your compliance architecture.
Frequently Asked Questions
What is KYT in crypto compliance?
KYT (Know Your Transaction) is a blockchain transaction monitoring framework that assesses the risk of individual transactions by analyzing on-chain fund flows, counterparty exposure, and behavioral patterns in real time. It operates continuously after onboarding, unlike KYC, which is a point-in-time identity check.
What is the difference between KYT and KYC?
KYC verifies the identity of a customer at onboarding. KYT monitors what that customer does on-chain after onboarding. KYC catches identity fraud and sanctions matches at entry. KYT catches structuring, layering, mixer exposure, and sanctions drift that emerge during the ongoing customer relationship.
Is KYT required by regulators?
Yes. FATF Recommendation 15 requires VASPs to implement risk-based transaction monitoring. MiCA and the EU Transfer of Funds Regulation impose monitoring obligations on CASPs. The US Bank Secrecy Act requires an AML program inclusive of transaction monitoring for money services businesses. MAS and VARA carry equivalent requirements in Singapore and Dubai respectively.
How does KYT relate to the Travel Rule?
They are separate obligations. KYT screens the risk profile of a transaction and its counterparties. The Travel Rule requires VASPs and CASPs to transmit originator and beneficiary data alongside qualifying transfers above threshold. A compliant platform needs both: KYT to determine whether a transfer should proceed, and Travel Rule tooling to transmit the required data if it does.
What are the most common KYT implementation failures?
The most common failures are: treating risk scores as automated decisions rather than inputs to analyst judgment; using black-box scoring without documented thresholds; generating alert volumes that exceed the compliance team’s capacity to review; and deploying tooling that sits outside the transaction flow and cannot block before settlement.
What is counterparty exposure in blockchain transaction monitoring?
Counterparty exposure is the percentage of transaction value that can be traced to a flagged entity, either directly (one hop) or indirectly (through intermediate wallets). Both direct and indirect exposure are assessed by KYT tools, with risk scores weighted by the category of the flagged counterparty and the volume of tainted funds.
