VASP crypto compliance rests on five obligations: customer diligence, transaction monitoring, record-keeping, suspicious activity reporting, and sanctions screening. If you operate a virtual asset service provider (exchange, custodian, payment platform), those five are the frame every regulator will examine you against. No jurisdiction scales them down because your compliance team is two people. What a small VASP can control is sequence: which obligations stand up first, which tools carry which load, and what "done" looks like for each. This checklist maps all five to their tooling and lays out a quarter-one build order a lean team can actually run.
What VASPs Are On the Hook For
Strip the acronym and the obligations are concrete: know your customers, watch their transactions, keep the records, file the reports, screen against sanctions. The set is not a menu: regulators treat them as an integrated program, and gaps in one surface as failures in all. A virtual asset service provider is any business that exchanges, transfers, safekeeps, or administers virtual assets for others; the obligations attach to the activity, not to the license label.
The obligations do not scale with headcount. Enterprise-grade compliance staffing and tooling carry budget weight a two-person platform cannot match, so at small platforms the obligations go under-manned instead of away. The exposure does not shrink either: a small platform receives the same phishing proceeds, hack-linked wallets, and sanctioned-entity interactions a large one does.
What differs at small scale is which failures hurt first. Monitoring and reporting break earliest, with alert queues nobody can triage and filings nobody has time to structure, because they are the obligations with continuous volume. The checklist below accounts for that failure order.
The Five Obligations, Mapped to Tooling
VASP obligations map to tool categories: API screening platforms carry monitoring, while identity and transfer-message tools cover the rest. The mapping matters because no single tool class covers all five obligations, and pretending one does is how platforms end up with a monitoring gap dressed up as a compliance program. The table below is the honest version: each obligation, what fulfills it, and which tool category actually does the work.
| Obligation | What it requires | Common fulfillment | Tool category that carries it |
|---|---|---|---|
| Customer diligence | Know who you serve; assess risk at onboarding | Identity verification flows; risk questionnaires | Identity verification vendors and in-house flows (identity checks are a distinct discipline from on-chain screening) |
| Transaction monitoring | Watch flows for risk signals; alert on exposure | Real-time screening APIs; rule-based alerting | On-chain screening APIs (the on-chain layer) |
| Record-keeping | Retain screening and decision records | Automated audit trails; structured logs | Platform tooling; screening tools that log automatically |
| Suspicious activity reporting | Structure and file reports within deadlines | Templated filing workflows; case management | Reporting tooling and process; screening feeds the evidence |
| Sanctions screening | Screen counterparties against designations | List-based and label-based screening | On-chain screening APIs with labeled intelligence |
Three boundary notes the table encodes. Customer diligence's identity verification (document checks, liveness, identity resolution) is a distinct discipline handled by identity verification vendors or the platform's own flows; on-chain screening tools complement it rather than replace it. Transfer-information obligations, in the jurisdictions that impose them, are carried by dedicated transfer-message tooling, again a separate category. And PEP screening — name-based checks against politically-exposed-person data — is likewise its own discipline with dedicated vendors; on-chain screening carries the sanctions and illicit-exposure half of that row, not the PEP half. The FATF basis for the VASP obligation set is Recommendation 15 with its Interpretive Note, and Recommendation 16 — the virtual-asset standards and the travel rule — not the PEP recommendations that govern a different obligation.
Where Small VASP Teams Actually Break
The break point for lean teams is the monitoring-to-reporting pipeline, and it breaks for arithmetic reasons: alert volume scales with customer count, analyst capacity does not. Hand-assembled filings — pulling evidence, reconstructing timelines, formatting the narrative — can eat a morning each at small-team staffing. That throughput ceiling turns a busy quarter into a backlog, and a backlog into unfiled reports. High false-positive rates in transaction monitoring make the arithmetic worse: when most of the queue is noise, the queue is the crisis. How explainable risk scoring addresses that noise is covered in a dedicated piece.
The failure sequence is predictable. Monitoring turns on; alerts flow; the team triages what it can; the queue grows; filings slip past deadlines; the record of what was flagged and why fragments across spreadsheets. Nothing in that sequence is a policy failure. It is a capacity failure, and capacity failures have tooling answers, not policy answers.
Record-keeping breaks the same way. The obligation is being able to produce, for any given customer or alert, what was screened, what was found, and what was decided, months later, on demand. Manual record assembly at that standard does not survive a growing customer base.
A Sequenced Checklist You Can Run This Quarter
VASP build order runs sanctions screening first, monitoring second, reporting templates third, because each layer feeds the next. Screening standing alone already catches the hardest exposures, designated entities and flagged addresses, at the lowest integration cost. Monitoring turns point-in-time checks into continuous coverage. Structured reporting turns the monitoring output into filings that meet deadlines. A lean team that runs this order ends the quarter with the two highest-risk obligations automated and the third templated.
Three steps in sequence, plus one practice that runs throughout:
-
Sanctions screening first. API integration is the lightest lift: a screening call at onboarding and at transaction events. Phalcon Compliance screens addresses against over 600 million labeled addresses with sanctioned-entity detection among its categories; the entry path runs from the free tier through credit packages to a subscription as volume grows. This step alone puts the hardest legal exposures behind automated checks. PEP screening is not part of this step — name-based PEP checks are a separate discipline with dedicated vendors, and on-chain screening carries the sanctions half. The KYA discipline behind the address side is unpacked in a standalone guide.
-
Transaction monitoring second. With screening live, monitoring extends it: continuous watching of customer flows for risk transitions, such as a clean wallet receiving exposed funds or a counterparty link forming. Alert tiering keeps the queue inside analyst capacity; tiering is the difference between monitoring and drowning.
-
Reporting templates third. With monitoring producing structured alerts, filings become assembly rather than authorship; the evidence trail is already machine-generated. Filings compress when the screening record is a lookup rather than a reconstruction.
-
Record automation throughout. Each step above logs its own audit trail when built on API tooling; the record-keeping obligation is satisfied as a byproduct rather than a fourth project.
To start the screening step, open Phalcon Compliance and run a first screening: start on the free tier, add pay-as-you-go credit packages as volume picks up, and step up to a subscription tier when screening becomes routine.
FAQ: VASP Obligations in Practice
Does every VASP need all five controls on day one? Day one, no; that is why sequencing exists. But the obligations attach with customers, not with comfort: the first real customer brings screening obligations immediately, and monitoring follows within the first growth phase. The honest framing is that the sequence compresses as volume grows; it does not wait for readiness.
Which obligations can one API tool cover? An on-chain screening API covers the on-chain layers: sanctions and risk screening, transaction monitoring, and the audit trails both generate. It does not cover identity verification (that is a separate discipline with dedicated vendors), and it does not assemble filings, though it feeds them evidence. Phalcon Compliance, for one, carries those three layers. One tool carrying three of five obligations well beats five tools carrying them badly.
What records survive a regulator visit? The four-part answer: what was screened, against what intelligence, what was found, and what the platform's policy did with the finding. Screening tools produce the first three automatically; the disposition log is the platform's own. Records that require a week of assembly are records that answer questions too late; the automation step exists so the answer is a query, not a project. The BSA recordkeeping rule carries the five-year retention floor U.S. examiners test against; FinCEN's enforcement actions show what enforcement looks like when records are missing.
How do small teams handle SAR volume? Structure over headcount. Templated filings built on machine-generated screening records collapse the per-filing cost; tiered alerts keep the reviewable queue proportionate to capacity. The teams that survive volume treat filing as assembly: evidence already exists, the template already exists, the analyst is confirming rather than composing. The multi-hour filing is a process design problem with a known fix.
