On the day a VASP's examiner arrives, the compliance program has to produce records, not promises. A regulatory examination forces a virtual asset service provider to show, on demand, that its transaction monitoring actually runs. The examiner is not there to read a policy document. The examiner is there to follow a specific alert from detection to disposition and confirm that every step left a record. If any of those dispositions were automated, expect a follow-up question: whether auto-closing compliance alerts is legal turns on what the automation can prove. A VASP that cannot produce that trail reads as a program gap, regardless of how good the screening engine is. This guide covers what examiners ask for under the FATF risk-based approach. It walks through making audit trails exam-ready, explaining risk scores without a black box, keeping STR records complete, and running a mock exam. For the broader transaction monitoring workflow these records come from, see Phalcon Compliance. This page is part of the KYT Resource Center.
What Examiners Ask For Under the FATF Risk-Based Approach
The frame examiners work from is the FATF risk-based approach for virtual asset service providers, anchored in FATF Recommendation 1. Recommendation 1 obliges a VASP to identify, assess, and understand its money laundering and terrorist financing risks, and to apply controls proportionate to those risks. That decomposes into three things an examiner can test: ongoing monitoring, suspicious transaction identification, and auditable records. KYT, as onchain transaction risk monitoring, sits inside the first two. It is the control that watches every deposit, withdrawal, and counterparty exposure. It scores the risk and surfaces the alerts that feed the suspicious transaction reporting process.
The important line is what the obligation is not. FATF Recommendation 16, the Travel Rule, is a separate obligation about transmitting originator and beneficiary information between VASPs. KYT does not satisfy it. KYT satisfies the monitoring side of Recommendations 10 and 11: monitor, identify, and keep records that prove both happened.
In practice, examiners ask to see the risk assessment that justified the monitoring scope. They want a sample of alerts and their investigations, plus the suspicious transaction reports filed and the records behind them. They also want the audit trail connecting each step. That trail lets the alert, the investigation, the decision, and the filing read as one continuous record. The institution that has to reconstruct any of that after the request has already failed the examination. Reconstruction is itself evidence the records were never kept.
Build the Audit Trail Before the Examiner Asks
An audit trail is the artifact that turns a screening program into a defensible program. Compliance officers who have lived through examinations describe the standard in plain terms. They say perfect audit trails make the difference between a clean examination and a findings letter. The examiner reads the absence of an audit trail as the absence of a control, because there is no other way to read it. A control that ran but left no record is, from the examiner's chair, indistinguishable from a control that did not run.
A defensible audit trail for onchain monitoring has three layers, each present before the examination starts. The first is the alert trail: which screening fired the alert, on which address or transaction, and at what timestamp. It also records which risk indicators drove the score. The second is the investigation trail: who picked up the case and what fund flow traces they ran. It records what exposure figures they observed and what conclusion they reached. The third is the disposition trail: who reviewed the conclusion, who approved the decision, what was filed or closed, when, and on what grounds.
Phalcon Compliance produces all three layers through its Audit Trails, Audit Logs, and Risk Engine Details, each exportable to PDF or CSV. The Audit Trail captures the sequence of investigative actions on the case. The Audit Logs record who took each action and when, making the trail attributable rather than anonymous. The Risk Engine Details record which risk indicators fired and how the score was computed from them, making the scoring legible rather than opaque. Exported together, they form a record a regulator can follow from alert to disposition without a gap. They travel with the case file, so the evidence package and the audit package never drift apart.
The practical test of audit trail readiness is whether a second analyst, or an examiner, can reconstruct a decision from the records alone. If reconstruction requires the original analyst to remember what happened, the trail is incomplete.
Explaining Risk Scores to Regulators Without a Black Box
Examiners do not accept a risk score on its face. A score is a number, and a number without an explanation reads as a black box. That black box reads as a control the institution cannot defend. Compliance officers who have been through examinations put the core problem bluntly. They say the ability to explain why a transaction was flagged, and why it was handled that way, is what resolves examination issues. A risk score that cannot be decomposed into its reasons is a liability during an exam, not an asset.
The distinction between a glass-box model and a black-box model becomes an examination question, not just a product question. A screening engine that returns a score and nothing else forces the compliance team to defend a verdict they cannot show the workings of. A screening engine that returns the score plus the specific risk indicators that produced it gives the compliance team a different path. They can walk the examiner through the decision in the same terms the engine made it. The first turns the exam into an argument. The second turns it into a review.
Phalcon Compliance runs on a glass-box model built on 17 Risk Indicator categories. Each risk score comes with the specific indicators that fired to produce it. The score is a composite the compliance team can break open rather than a verdict delivered from above. When an examiner asks why a transaction was flagged as high risk, the answer has three parts. It is the named indicators, the onchain evidence each one attaches to, and the weighting that combined them into the score. That is what makes the scoring defensible: the regulator sees the same inputs the analyst saw, reaches the same conclusion, and moves on.
The same legibility matters in the other direction. When an examiner asks why a transaction was cleared, the compliance team has to show which indicators did not fire. They must explain why their absence supported a low-risk verdict. A glass-box model answers that directly. A black-box model does not answer it at all, and the silence is what examiners convert into a finding.
Keep SAR and STR Records Complete
A suspicious transaction report is the document an examiner reaches for early. It is where monitoring, investigation, and the decisions analysts make all become visible in one place. But the filing itself is only half the record. The other half is the case file behind it: the alert that started the investigation, the onchain narrative, the exposure figures, and the risk indicators. It also includes the review and approval chain and the audit trail connecting them. A STR or SAR filed without that supporting record is a filing the institution cannot defend. The examiner has no way to confirm it was the product of a real investigation rather than a reflexive template fill.
FATF Recommendation 20 sets the suspicious transaction reporting obligation for VASPs, and it ties back to Recommendation 11's recordkeeping requirement. In the United States, the report is the SAR filed with FinCEN under the suspicious activity reporting regulations (31 CFR 1022.320). The records have to exist before the examination, not be assembled in response to it.
The platform supports STR generation on the Essential tier and above. That means the case file, the audit trail, and the STR export are produced from the same surface. The alert, the investigation, the disposition, the audit trail, and the filing all live in one record that can be exported as a package. When an examiner asks for the supporting documentation behind a sample of filings, the response is a single export per case. It is not a reconstruction across disconnected tools.
The retention dimension matters as much as production. FinCEN retains a five-year recordkeeping expectation for SAR supporting documentation, and FATF-aligned jurisdictions set comparable horizons. An exam-ready program keeps the full case file, not just the filing, for the full retention period, retrievable and exportable on demand.
Common Exam Findings and How to Avoid Them
Examination findings in crypto compliance cluster around a small number of failure modes. Most trace back to the same root cause: a control that ran but was not recorded, or a record that could not be exported.
The first is a monitoring gap, where the screening cadence left a window between checks that funds could move through. A real-time check on every deposit and withdrawal, rather than a periodic batch, closes that window. The audit trail then has to show the check ran on the live flow.
The second is an unexplained disposition, where the institution closed or escalated an alert but the record does not show why. A glass-box model with named risk indicators prevents this. The reasons are captured in the Risk Engine Details at decision time, not reconstructed from memory.
The third is a STR or SAR filed without supporting documentation. The filing exists, but the case file behind it cannot be produced on request. Producing the STR and the audit trail from the same surface prevents this, because the two never separate.
The fourth is a recordkeeping failure. Here the records existed but have aged out, lost their tool access, or cannot be exported in a format an examiner can read. PDF and CSV export from a single surface prevents this, because the record is portable and does not depend on a live license to retrieve.
Avoiding all four comes down to one discipline: produce the record at the time of the action, in a portable format, attached to the case.
Mock Exam Checklist: Run It Before the Examiner Does
A mock exam is the cheapest way to find the gaps an examiner would otherwise find. It forces the institution to do what the real examination will demand. That means picking a sample of alerts and filings and producing the full record on demand. The checklist below is the set of artifacts a mock exam should produce for every sampled case.
Audit trail per case. For each sampled alert, produce the Audit Trail, Audit Logs, and Risk Engine Details exported together. Confirm the second-analyst test passes: a reviewer who did not work the case can reconstruct the decision from the export alone.
Risk score explanation per case. For each sampled disposition, produce the named risk indicators that drove the score. Include the onchain evidence each attaches to and the weighting that combined them. Confirm the explanation answers both directions: why flagged, and why cleared.
STR or SAR record completeness per filing. For each sampled filing, produce the case file, the onchain narrative, and the exposure figures. Also include the review and approval chain and the audit trail. Confirm the filing and its supporting record travel as one package.
Disposition rationale per case. For each sampled close or escalation, produce the documented reason captured at the time of the decision. That reason must not be reconstructed after the fact.
Monitoring coverage evidence. Produce evidence that screening ran on the live deposit and withdrawal flow rather than a periodic schedule, with no window between checks. Confirm the audit trail timestamps support continuous monitoring.
Recordkeeping and retrieval. For filings across the retention horizon, confirm the full case file can be retrieved and exported in PDF or CSV. The retrieval must be on demand and must not depend on a live session or a lapsed tool license.
A program that can produce all six for every sampled case is exam-ready. A program that cannot has found, in the mock exam, exactly the finding the real examination would have written up. KYT satisfies the ongoing-monitoring side of FATF Recommendation 10; the audit trail, the risk score explanation, and the STR record satisfy the recordkeeping side of Recommendation 11. See how Phalcon Compliance builds the audit trail and the 17 Risk Indicator categories into one record for the examination your program is going to face.