A KYT tool choice is a multi-year commitment, and the cost of getting it wrong lands when a regulator asks why a screening failed. The wrong choice shows up later as alerts an analyst cannot explain, a chain footprint that stops short of where the business operates, or a contract that charges the same whether the team screens five thousand addresses or fifty thousand. This guide gives a compliance officer a six-axis framework to evaluate any KYT tool against. The decision is then built on capability dimensions rather than a sales narrative. For the broader KYT product context, see Phalcon Compliance. This page is part of the KYT Resource Center.
One boundary matters before the framework starts. This page covers choosing a KYT transaction monitoring tool, the layer that scores risk and produces an action before or during a transaction. It is not about choosing a post-incident tracing or fund-following layer, which answers a different question and is evaluated on different axes. Conflating the two layers is the most common selection mistake.
What a KYT Tool Must Do
A KYT transaction monitoring tool has one job at the decision layer. It reads the risk of an address or transaction, returns a score, and returns enough evidence behind that score for a compliance team to defend the resulting action. That job breaks into three requirements no tool can collapse.
The first is real-time screening at the transaction gate. A deposit or withdrawal arrives, the tool returns a risk result before the transaction is released, and the gate routes on that result. A tool that only runs in batch is not a monitoring tool in the regulatory sense. The FATF risk-based approach for virtual asset service providers obliges VASPs to monitor transactions on an ongoing basis. FinCEN's AML program rule (31 CFR 1022.210) and suspicious activity reporting rule (31 CFR 1022.320), taken together, make ongoing monitoring necessary for crypto exchanges and other US money services businesses. A batch-only cadence leaves a distance between the duty to monitor and the control that runs, and examiners read that distance as a program gap.
The second is explainable scoring. A risk score on its own is not defensible; the analyst, the auditor, and the examiner all need to see why the score landed where it did. The third is an auditable record. Every screening, disposition, and rule change has to be recoverable. The audit trail is what turns a screening capability into a program an examiner can sign off on. It is also what feeds a suspicious transaction report when one is required.
Evaluate Vendors on Six Axes
Most KYT selection conversations drift into feature lists because the category has no shared evaluation framework. The six axes below are the dimensions that actually separate a tool a compliance team can operate from one it cannot. They are independent, and the ones that matter most depend on the team's volume, chain footprint, and regulatory exposure.
Axis 1: API latency for real-time screening. A KYT tool embedded in a deposit or withdrawal flow has to return before the transaction is released. A working ceiling for a pre-transaction screen is roughly 500 milliseconds end to end. The API itself has to consume only a fraction of that, leaving room for routing, logging, and the threshold decision.
Axis 2: Rule tunability to drive down false positives. Every KYT tool produces alerts. The question is whether the team can tune the rules behind those alerts without filing a change request with the vendor. That calibration is the only durable path to a false-positive rate an analyst team can survive.
Axis 3: Explainable, glass-box scoring. A black-box score is a liability. Glass-box scoring exposes the risk indicators behind a score, so an analyst can read which exposures drove the result and a regulator can reconstruct the decision.
Axis 4: Multi-chain coverage. A KYT tool only catches risk on the chains it reads. A tool with deep coverage on three major chains but nothing on the long tail leaves a blind spot where exposure often grows fastest. The axis to evaluate is whether the tool covers the chains the business transacts on.
Axis 5: Audit trail and STR automation. Monitoring produces records, and those records have to feed the reporting layer. An audit trail that captures every screen and disposition is the baseline. Automation that turns an investigated alert into a suspicious transaction report draft is what separates a defensible case file from a screenshot.
Axis 6: PAYG versus subscription pricing. A quote-based enterprise subscription charges a fixed annual allowance whether the team uses it or not. Pay-as-you-go credit pricing charges for actual screening volume. The right model depends on whether volume is predictable and high or lumpy and unknown. Ignoring this axis ends in overpayment for unused capacity or a contract that does not match the program's cadence.
Evaluating Each Axis
The six axes are evaluated differently, and treating them as a single checklist is where selections go wrong. Each axis has its own test, usually a measurement rather than a vendor claim.
For API latency, the test is a measurement under the team's own traffic, not the published figure. A published sub-100 millisecond response is a target to confirm, not a benchmark to build an SLA on. Run real addresses through the API, measure at peak and idle, and confirm the number holds before committing the gate to it.
For rule tunability, the test is what the team can change without the vendor. A tool where every tuning change is a ticket is a tool the team does not control. For explainable scoring, the test is whether the risk indicators and exposure figures ship with the score. If the API returns only a number, the team cannot defend a held transaction. For multi-chain coverage, the test is the team's actual footprint. A tool covering ten native chains is sufficient only if those ten include every chain the business transacts on.
For the audit trail and STR layer, the test is whether the path from an investigated alert to a suspicious transaction report runs inside the workflow. For pricing, the test is volume shape: predictable high volume favors a subscription, lumpy or unknown volume favors pay-as-you-go.
How Phalcon Compliance Maps to Each Axis
Phalcon Compliance anchors this hub. The point of this section is not to argue it is the only tool that satisfies the framework. The goal is to show how a specific platform reads against the six axes, so a compliance team has a worked example to compare other tools against.
On API latency, BlockSec specifies sub-100 millisecond response for its real-time screening API. Read it as a target to confirm against production traffic before an internal SLA is built on it.
On rule tunability, the platform exposes a configurable Risk Engine that ships five rule templates plus a default built around the FATF risk-based approach. A compliance team can calibrate scoring to its own risk appetite, rather than filing a change request for every threshold shift. On explainable scoring, every score ships with its risk indicators and exposure figures attached. The model 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. An analyst reading a held transaction sees which exposures drove the score, which is what makes the decision defensible.
On multi-chain coverage, the tool reads ten native chains; whether that is sufficient depends on the team's footprint. On the audit trail and STR layer, every screen and disposition is captured in a recoverable record. STR export is available on the Essential tier and above.
On pricing, it uses pay-as-you-go as the entry point. Screening Packages start at $95, with a unit price between $1.10 and $1.90 per screening. The Scale tier at $699 per month is the API entry for teams embedding screening in a product flow. The pricing detail is covered in the dedicated pricing Spoke. The point here is that PAYG exists as a structural alternative to the quote-based subscription. A team can evaluate against real volume before committing to a tier.
Spot These Red Flags Before You Buy
A handful of patterns recur across weak KYT selections. Each one shifts work onto the compliance team that the tool should have absorbed.
A black-box score is the first red flag. If the API returns a risk number without the indicators behind it, the team cannot defend a held transaction or explain a decision to an examiner. Single-chain or shallow coverage is the second. A tool that reads one or two chains deeply forces a second vendor for the long tail, or a blind spot on every uncovered chain. No audit trail is the third. A tool that does not capture every screen and disposition in a recoverable record leaves the compliance team to reconstruct the program manually when an examiner asks.
A rigid subscription with no PAYG path is the fourth. A quote-based enterprise contract is legitimate for a large institution with predictable volume. But a vendor offering no pay-as-you-go alternative forces every mid-market team into a procurement cycle sized for an enterprise. The absence of PAYG is a signal about who the vendor built the product for.
Selection Checklist
The framework collapses into a checklist a compliance team can run against any KYT tool.
- Does the tool return a risk score inside the latency budget the gate allows, measured under the team's own traffic rather than against the vendor's published figure?
- Can the team tune rules, thresholds, and risk indicators without filing a change request with the vendor?
- Does every score ship with the risk indicators and exposure figures that drove it, so a held transaction is defensible?
- Does the tool cover every chain the business transacts on, evaluated against actual exposure rather than a headline chain count?
- Does the tool capture every screen and disposition in a recoverable audit trail, and produce an STR draft from an investigated alert inside the workflow?
- Does the pricing model offer a pay-as-you-go path so the team can evaluate against real volume before committing to a contract?
A tool that passes all six is one a compliance team can operate. A tool that fails one or two is not automatically disqualified. The failed axes are the ones the team will carry the cost of for the life of the contract. Run the framework against any candidate, including Phalcon Compliance, and let the axes make the decision.