VASP licensing: documentation and technical infrastructure

Why VASP licensing stalls at the verification stage

The regulator checks not a declaration of intent, but the coherence of data: from client to operation, from operation to source of funds, from source to reporting.

That is why VASP licensing more often stalls not on the legal part, but at the junction where compliance documentation must be confirmed by extracts from a working system.

The dossier is assembled as a set of files, while the examiner follows the chain and looks for confirmation at each step.

The first typical failure is an incomplete dossier. Some procedures are described in different revisions, some live only in correspondence, and policy versions are not linked to their introduction dates.

The second is that transaction flows are not described: it is unclear which deposit and withdrawal channels are used, who the counterparty is, how operation status is recorded and which employees have access to it.

The third and most expensive is the source of client funds. If it is confirmed by a manually saved screenshot rather than an extract from the system with client identifier, date and responsible person, the review does not accept such confirmation.

Here regulator requirements and infrastructure diverge: the procedure exists, but there are no traces of its execution.

Our experience: the discrepancy between the described process and what the system actually records is the main cause of returns and additional requests. We explain how this is closed at the preparation stage.

What changes after implementation: timelines, refusals, requests

When documentation and infrastructure are designed together, the effect is visible in numbers, not descriptions.

Before this, the dossier for a license is assembled over months: part of the transaction history is missing, part of the correspondence lives in email, and system extracts do not reconcile with each other. Each gap has to be closed manually — and that is exactly where the examiner stops most attentively.

The key metric is the share of operations with complete, recoverable history. If the transaction flow is written to an immutable log, and address checks and travel rule data are linked to it, this share stays around 95% instead of 60–70%.

Analytics like Chainalysis covers counterparty risk assessment, while own storage covers retention period and completeness: data does not depend on whether the provider or extract format changed.

Dossier preparation time is reduced from weeks to several days, because the risk profile, fund flow scheme and procedure descriptions are taken from the working system. They are not reconstructed from memory or rewritten for each request anew — only the accompanying part changes.

Then the number of follow-up requests falls: the initial package already contains answers to typical questions on sources of funds, counterparties and control.

This is resilience to review — not a one-time folder of documents, but a state confirmed at each subsequent reconciliation.

VASP licensing formats: comparison of options

VASP licensing is not limited to submitting a package of documents: there are several options for obtaining status, and each defines its own perimeter of operations, requirements for technical infrastructure and time to market. The choice depends on whether you work with custody and fiat or limit yourself to exchange.

Below are four schemes most often chosen among. Comparison goes along three axes: speed of start, scope of obligations to the regulator and the extent to which the infrastructure remains yours.

Limitations of the approach are not a formality: they determine which AML program will have to be built and whether a local compliance officer is needed.

Maintaining status also requires infrastructure: transaction logging, key storage procedures and reporting regulations must be documented and reproducible from day one — otherwise a repeat regulator review turns into reworking processes.

Work stages: audit, integration setup, handover

The order of steps here is not a formality: if integrations are connected before data flows are described, checks begin to duplicate, and reporting is assembled manually.

We go from analysis of the current contour to a working scheme, and each stage relies on the artifact of the previous one.

1. Infrastructure audit. We look at where keys are stored and how operations are signed, who has access to systems, which verification services are already connected. The output is a gap map: shared accounts, incomplete logs, checks whose result cannot be reproduced.
2. Data flow scheme. We describe the route of client data, reconciliation points with lists, retention periods and events that enter the immutable log and are exported upon regulator request.
3. Access segregation. We build roles so that check settings are not changed by the operator handling alerts. Two-factor confirmation, separate environments for test operations and production work.
4. Integration setup. We connect identity and document verification, screening against sanctions and politically exposed persons lists, blockchain analytics, and exchange of transfer data with other providers. Each channel has failure and retry handling.
5. Scenario testing. We run controlled cases: match against a list, amount structuring, transfer to an address from a risk group. An alert must lead to a clear action, and a false one must be cleared with justification.
6. Documentation and regulations. Internal control rules, investigation procedure, escalation matrix, list update periods. Everything is tied to the actual configuration, not written separately from it.
7. Handover. We provide access, flow schemes, regulations and a trained team: we walk through incidents using live examples and show how to change rules without stopping the service.

At the output, the client receives a scheme that can be shown to the regulator and further maintained in-house.

Configurations, access policies and document package

The document package is not a folder assembled for submission for a VASP license, but a working description of the system.

If configurations, access policies and regulations diverge from how the infrastructure is actually arranged, the first regulator request or incident investigation reveals this gap.

We assemble artifacts so that the environment can be reproduced from them and every decision explained.

• System configuration — composition of components, connections between them, deployment parameters and environment separation, so that the environment can be brought up from the description, not from the engineer's memory.
• Access policies — role and permission matrix, procedure for granting, reviewing and revoking, rules for confirming critical operations by two employees.
• Role descriptions — who is responsible for what: from administrator to compliance officer, with areas of responsibility and substitution procedure.
• Data flow diagrams — where client data comes from, where it is stored, where it is transferred, and at which stages operation traces are recorded.
• Operating procedures — handling regulator requests, incident response, recovery after failure, procedure for changing configurations.
• Logs and operation traces — what exactly is recorded, how long it is stored, who has the right to export.
• Update procedure — owner of each document, review triggers, versioning and change recording rules.

Each artifact has an owner and a review rule: when system composition, roles or data routes change, the document is updated together with them, not after a comment. Versions are stored alongside, so it is visible which revision was in effect at the time of a specific operation.

The package ceases to be a formality and becomes a tool used by both engineers and those responsible for compliance.

Case study: preparation for review without stopping the service

The client — a virtual asset service provider preparing for a regulator review as part of the licensing procedure. Transaction history lived in four places: exchange module, fiat desk, manual registers for large transactions and exports from blockchain analytics.

Assembling a complete picture for a specific client over an arbitrary period could only be done manually: each request took about nine business days, and for some operations the link to the source of funds was lost.

What was changed

We consolidated history into a single register with an immutable log: each record received a client identifier, amount and direction, a link to the on-chain transaction and the risk assessment rule under which the operation was checked on its date.

Daily reconciliation with exports from Chainalysis transaction analytics closed discrepancies between internal accounting and network data — the discrepancy went into a separate review queue instead of surfacing during a review.

Risk assessment rules were versioned, so it is possible to reproduce why an operation was considered low-risk then, not only now.

Dynamics by control metrics

The migration was carried out without stopping the service: the new register was populated in parallel with current operations, modules were connected one by one with rollback switching if reconciliation produced a discrepancy.

The review passed without comments on data completeness, and regulator requests are now closed by a query from the register, not by assembling statements across departments.

What to do if the infrastructure is already deployed?

A working infrastructure is not rebuilt from scratch — a second contour brought into compliance with requirements is assembled alongside it, and the load is migrated there in parts.

The service does not stop at any step, and rollback is flipping one switch, not restoring from a backup with loss of operations sent over the last hour.

They start with an inventory of systems: which services actually serve client operations, where signing keys are stored and how outgoing transactions are confirmed, which external interactions go outside the contour, who and with what rights is allowed to each link.

The output is a scheme of the actual operation flow and a list of discrepancies between how things are arranged in reality and what is described in the documentation. Some nonconformities are resolved by configuration, some require code changes.

Access segregation is introduced in stages: first roles with minimally necessary rights and separate confirmation for critical actions, then separation of duties between the one who initiates an operation and the one who authorizes it.

Previous broad rights are disabled only after the log shows that the new role set covers all working scenarios. Otherwise a night operation will stall due to closed access to the service.

Supervisory authority requirements, including the FATF approach to virtual assets, are checked for alignment between the regulation and the actual execution contour.

Documentation is edited in the same shift where configuration changes: routing diagrams, role matrix, event logs and incident response procedure are updated together with code, not as a separate stage at the end.

The output is an operating service without downtime, formalized access rights, reproducible operation logs and descriptions that an examiner can reconcile with the system in one pass.

After that, scheduled maintenance remains: any change follows the same path as the initial improvement.

Common doubts: data storage, integrations, reporting

Objections regarding VASP licensing are almost never about the document package itself — they are about the infrastructure under it: how much and how long to store data, how to connect already working systems, in what form to provide reporting and how to confirm that transaction history has not been altered. We address each.

Our accounting is scattered across several systems — does everything have to be rewritten?

Usually not: an integration layer is assembled that links the accounting contour, payment and monitoring by a single client and operation identifier. Event ingestion is idempotent — a repeated package does not create a duplicate, and reference data is matched once.

The report is then built from one picture instead of being reconciled manually between three exports.

In what form should reporting be provided and how to prove its reliability?

We select the export format for regulator requirements, not for the convenience of internal systems, and fix it with a schema — reconciliation is automatic, discrepancies are visible before a request, not after.

History integrity rests on an append-only log: each record receives a checksum, records are linked to each other, so backdated edits are detected without manual inventory.

Let's discuss the task and come back with an estimate and plan

The conversation starts with input data, not with a presentation: to come back with a scope estimate and work plan, we need to see how the business is arranged now. The more specific the inputs, the fewer assumptions in the estimate and the more precise the stage boundaries.

What to send to start:

• jurisdictions of registration and planned service markets — regulator requirements, identification procedures and reporting rules depend on them;
• model of working with client assets: custodial or non-custodial, who controls keys and how roles are separated;
• list of operations: exchange, transfers, fiat deposit and withdrawal, settlements with counterparty platforms;
• current infrastructure: what is already deployed, which contractors and systems are in the contour, where data and logs are stored;
• documentation status: whether there are drafts of AML/CFT policies, client identification programs, descriptions of internal procedures and controls;
• deadlines for filing the application and the expected procedure for interaction with the regulator.

In response, we send a staged work plan, documentation composition with responsible persons and a draft contour architecture. Describe the task — we will come back with a scope estimate and work format.