Stablecoins now account for more on-chain transaction volume than any other asset class on most major blockchains. USDT alone settles more daily volume than Bitcoin on many networks. For exchanges, that concentration creates a compliance gap that most blockchain analytics tools were not built to close.
Generic KYT tools were built around one assumption: a high-risk transaction touches a known bad address. That works reasonably well for Bitcoin tracing. The transaction graph is sparse. The attribution database covers most significant entities. It breaks down for stablecoin flows, where volume is higher, entities are more diverse, and risk surfaces through patterns rather than direct address contact.
The stablecoin-specific risk profile
Stablecoin transactions carry risks that differ from native cryptocurrency transactions in three ways.
Velocity is the first. Stablecoins are used for settlement, not just store of value. A customer who holds Bitcoin may transact a few times a year. A customer using USDT for payments or DeFi activity may transact hundreds of times a month. Alert models tuned for cryptocurrency frequency produce unworkable false-positive rates when applied to stablecoin flows. Examiners have noted this pattern. FinCEN's 2019 guidance on convertible virtual currency explicitly anticipated that volume-based thresholds would need calibration by asset type.
Counterparty breadth is the second. Stablecoins flow through DeFi protocols, DEX aggregators, cross-chain bridges, payment processors, and OTC desks. Many of these counterparties carry no label in standard databases. An unlabeled counterparty is not a sanctioned counterparty. But that gap requires a documented risk decision, not silence. NYDFS Part 504 examiners ask specifically whether exchanges have procedures for counterparties not covered by their primary screening database.
Sanctions lineage is the third. When OFAC designates an address under 31 CFR Part 501, stablecoin issuers exercise freeze authority immediately. For an exchange, the live question is twofold: has any customer recently transacted with an address now on the SDN list, and does any customer account hold tokens that originated from a frozen address? OFAC's 50% rule extends liability to entities owned 50% or more by designated parties. The freeze perimeter is wider than most exchanges assume. That lineage analysis requires a different query than a real-time sanctions screen.
What configurable risk rules actually require
Sophisticated exchanges do not run out-of-the-box risk models. They run models tuned to their customer base, product mix, and regulatory posture. A retail exchange licensed under MiCA has different thresholds than a derivatives platform operating under MAS MAS-MTC. Those differences are not preferences. They are regulatory requirements.
Hop depth is the configuration that matters most. It controls how many transaction hops the system analyzes when assessing address exposure to a risk category. Set it too high and you flag customers three hops from a mixer via a major exchange, exposure that FATF Recommendation 16 commentary explicitly treats as attenuated. Set it too low and deliberate layering goes undetected. The right setting reflects the exchange's risk appetite and the written expectations of its primary prudential supervisor. It should be documented, reviewed annually, and defensible in an examination.
Category risk levels also need jurisdiction-aware calibration. Gambling services are high risk under BSA guidance in the US and fully regulated in several EU member states. An exchange serving customers in both jurisdictions needs category risk rules applied at the customer-jurisdiction level. A single global model that treats every customer identically fails both the EU customer and the BSA exam.
Alert management at scale
The operational pressure of stablecoin KYT is alert volume. A single OFAC designation (a large exchange added to the SDN list, a significant mixer designated) can generate tens of thousands of alerts in minutes. Compliance teams sized for routine alert volumes collapse under these events.
BSA Section 5318(g) requires SARs to be filed within 30 days of initial detection of a suspicious transaction, with a 60-day extension available. That deadline does not pause during an alert surge. Exchanges that have addressed this problem use three mechanisms in combination.
First, alert prioritization that surfaces high-confidence, high-impact alerts first. Analysts see the most actionable work before the queue grows. Second, batch processing for low-risk alert groups, closing them with a documented rationale rather than one by one, with that rationale stored in the audit record. Third, time-range filtering that distinguishes post-designation exposure from pre-designation exposure. An examiner evaluating SAR coverage needs to see that the exchange made that distinction deliberately, not that it treated all alerts as equivalent.
SAR narratives for stablecoin transactions have a specific problem: the analyst reviewing the narrative may not be a blockchain expert. The most defensible implementations produce a structured narrative (the address, the entity attribution, how funds reached the flagged address, the confidence level of that attribution) that the analyst reviews and approves. The analyst's judgment is the record. Strix produces that structured narrative automatically. The analyst reviews it, edits where needed, and approves it. SAR prep time drops from over an hour to minutes for the common case. That is analyst hours recovered, not analyst judgment bypassed.
Auditability as a product requirement
When a regulator examines an exchange's KYT program, one of the first questions is: how do you know your labels are accurate, and when were they last validated? An exchange that cannot show a label audit trail (what entity owns this address, when that attribution was assigned, what evidence supports it, when it was last reviewed) faces examination findings even if the underlying risk decisions were correct. NYDFS and FinCEN both treat label provenance as a first-order requirement, not a technical detail.
Label auditability is not optional. It is the foundation every other part of the program rests on. When a customer disputes a transaction flag, the exchange must show not just the current risk score but the full history of how that score was derived. Model risk guidance (SR 11-7 and its BSA/AML analogs) requires that automated decision systems used in regulatory workflows be documentable, validatable, and subject to ongoing performance monitoring. That standard applies to KYT scoring models, not just credit models.
The compliance record is built in daily operation. It cannot be reconstructed after the fact. Exchanges that discover this during an examination have already lost.
Multi-jurisdictional risk is not a single model problem
The exchanges that will face the hardest examination pressure in the next three years are operating under multiple regulatory regimes simultaneously. MiCA Travel Rule obligations in the EU, FATF Recommendation 16 implementations across Asia-Pacific, FinCEN BSA requirements in the US, and the OFAC sanctions program running in parallel across all of them. These regimes do not share thresholds, do not share SAR equivalents, and do not share expectations about what "reasonable" counterparty due diligence looks like.
A KYT program built for one jurisdiction is a liability in the others. The exchange that serves customers in Singapore, Germany, and New York with a single undifferentiated risk model has a documentation gap that examiners in at least two of those jurisdictions will find. The answer is not to run three separate programs. The answer is jurisdiction-aware policy layers applied to a single consistent transaction record, with each layer's logic documented, versioned, and auditable.
That architecture is harder to build than a single threshold. It is the only architecture that survives a cross-border examination.