VASP License Compliance Setup in Estonia

Obtaining a VASP license in Estonia requires detailed compliance system setup. After the reform, the regulator tightened requirements: a real office, a local MLRO, capital from €125,000. Many companies get rejected due to a formal AML policy or lack of actual presence. We specialize in documentation preparation and support with the FIU. Our experience: over 5 years and 20+ successful cases. Meanwhile, independent preparation often leads to additional regulator inquiries, doubling the average timeline — our compliance setup cuts this time in half compared to independent preparation.

A typical problem is a generic AML policy that does not account for the business model. We develop a policy from scratch, including transaction monitoring rules and EDD procedures, which reduces the number of follow-up inquiries from the regulator by three times. In this article, we break down the key FIU requirements and steps for successful license acquisition. Special attention is given to details that most often lead to rejection. Understanding these nuances will save you months of waiting.

How have requirements changed after the reform?

Real presence in Estonia: an office and at least one director or employee physically located in Estonia. Nominal director without actual presence is no longer accepted.

Local AML Compliance Officer: an appointed MLRO (Money Laundering Reporting Officer) with confirmed AML experience. The Estonian FIU checks CVs and may request an interview with the candidate.

Minimum capital: €125,000 for VCES, €250,000 for VCWS. Capital must be documented in the articles of association and confirmed by a bank statement. Important: these funds are not a license fee but serve as a guarantee of liability.

IT audit: an external IT audit by an Estonian auditor. Compliance with GDPR, security of client data storage, backup procedures, and transaction monitoring are checked. The auditor must be accredited by the FIU.

What requirements does the FIU have for the AML Policy?

The Estonian FIU expects specific elements in the AML Policy. We develop a document fully compliant with the Money Laundering and Terrorist Financing Prevention Act and considering the regulator's practice.

Mandatory sections according to MLTFPA:
1. Business model and risk description
2. Customer Due Diligence procedures (including enhanced for high-risk)
3. Transaction monitoring system with example rules
4. SAR reporting procedure (via FinanceIntelligence.ee portal)
5. Sanctions screening
6. Record keeping (5 years)
7. Staff training
8. Internal audit
9. Board-level oversight

The FIU is known for requesting additional documents in 2–3 rounds. A generic policy from the internet leads to immediate rejection. We prepare the policy considering typical FIU remarks: a detailed business model description, realistic transaction rule examples, enhanced due diligence procedures for high-risk countries. For example, for an exchange service, we include structuring detection rules (more than 3 transactions just below the threshold within 24 hours) and mandatory sanctions screening via Chainalysis or similar.

How to set up transaction monitoring to meet FIU requirements?

Transaction monitoring is a key compliance element. The FIU expects the monitoring system to detect suspicious patterns in real time. In our practice, we define at least five rules: structuring, high-value transactions, rapid fund movement, interaction with high-risk countries, and abnormally frequent small deposits. Each rule must be documented with threshold values and actions triggered.

Example monitoring rules:
1. Structuring: >3 transactions below €1000 in 24h (alert + manual review)
2. High value: single transaction >€10,000 (automatic AML check)
3. Rapid movement: deposit + withdrawal within 24h (includes enhanced KYC)
4. High-risk country: any transaction involving FATF blacklist country (block)
5. Anomalous patterns: multiple small deposits from different addresses (manual review)

Why does the FIU reject VASP license applications?

Most common reasons for rejection:

• Incomplete AML policy – missing sections, no example monitoring rules.
• Formal approach to MLRO – candidate lacks real AML compliance experience.
• Lack of real presence – declared office turns out to be virtual.
• Lack of transparency on source of funds – company cannot explain capital origin.

We help avoid these mistakes during the preparation phase.

Technical requirements for IT infrastructure

// For the Estonian license, you need to document:
const EstoniaVASPRequirements = {
  // Transaction monitoring rules (with examples of how they work)
  tmRules: [
    "Structuring detection: >3 transactions just below €1000 within 24h",
    "High-value: single transaction >€10,000",
    "Rapid fund movement: deposit + withdrawal within 24h",
    "High-risk country: any transaction involving FATF blacklist country",
  ],
  
  // KYC levels linked to limits
  kycLevels: {
    BASIC: { limit: 1000, required: ["email", "phone", "wallet_screening"] },
    STANDARD: { limit: 15000, required: ["government_id", "address", "liveness_check"] },
    ENHANCED: { limit: Infinity, required: ["source_of_funds", "source_of_wealth", "video_call"] },
  },
  
  // SAR reporting
  sarReporting: {
    platform: "FinanceIntelligence.ee",
    deadlineDays: 10, // Estonia has stricter deadline than FATF standard
    reportingCriteria: ["suspicion of ML/TF", "unusual transaction patterns"],
  },
};

Application process

1. Preparation of all documents (8–12 weeks)
2. Submission via Estonian Business Register
3. FIU review (60 working days by law, actually 3–5 months)
4. Follow-up questions from FIU (usually 2–3 rounds)
5. Receipt of license or reasoned refusal

State fees are paid separately.

What is included in our work

• Development of AML Policy and CDD/EDD procedures
• Setup of transaction monitoring rules tailored to business model
• Preparation of document package for FIU
• Support at all stages, including responses to FIU inquiries
• Staff training on AML and KYC basics
• Recommendations for MLRO selection and physical presence setup

Our compliance setup outperforms independent preparation: it cuts the license acquisition time in half.

Timeline

Compliance documentation preparation takes 4 to 8 weeks. The full license acquisition process (including FIU review) takes 3 to 6 months.

How to start

Contact us for an audit of your current documentation. We will assess readiness and propose an action plan. Request a consultation on compliance setup for the Estonian license — the first analysis is free.

Why does your project risk without blockchain compliance services?

We see the regulatory landscape for the crypto industry changing faster than protocols can adapt. If your project operates in the EU, MiCA is no longer a recommendation but a mandatory requirement. The FATF Travel Rule has been in force for several years, but real enforcement is growing. Protocols that launch without a compliance architecture later redesign it under pressure—this is more expensive, more painful, and risks downtime. Blockchain compliance services cover the full cycle: from gap analysis to launch and support during licensing. We have implemented 15+ AML/KYC projects for crypto exchanges and DeFi, working with Chainalysis, Elliptic, Sumsub, TRM Labs. We have processed over 1 million transactions in on-chain monitoring, with an average false positive rate of 2.3% for AML screening.

Why is the Travel Rule a technical, not a legal challenge?

FATF Recommendation 16 (known in banking as the FinCEN Travel Rule) requires VASPs to transmit sender and receiver KYC data from one VASP to another for transfers above a certain threshold (varies by jurisdiction). This requirement, copied from traditional bank wire transfers, creates technical problems in blockchain that do not exist in SWIFT.

The first problem is determining VASP-to-VASP. If a user sends from a custodial exchange address to a self-custodial wallet, the FATF Travel Rule does not apply because one counterparty is not a VASP. But how does a VASP automatically determine that the destination address is truly self-custodial and not another VASP? The solution: on-chain analytics (Chainalysis, Elliptic, TRM Labs) for address clustering + using the Travel Rule protocol only for VASP-to-VASP.

The second problem is interoperability between VASPs. There are several Travel Rule protocols: TRUST (consortium under Coinbase/SWIFT), TRISA (gRPC-based, open standard), OpenVASP (Ethereum-based), Sygna Bridge. They are not interoperable. Most major exchanges support several simultaneously. The technical implementation is an API gateway that detects the counterparty's protocol and routes the request.

TRISA implementation (most open): gRPC service, mTLS for authentication, PII data encrypted with the recipient's public key (envelope encryption, AES-256 + RSA-4096). To register in the TRISA Directory Service, you need verification via a TRISA member. The code is an open SDK in Go and Python.

Specific pain point: timing. Travel Rule data must be transmitted before or simultaneously with the transaction. On the Ethereum blockchain, a transaction is confirmed in about 12 seconds—within that time, the TRISA handshake must complete. If the counterparty does not respond, the transaction is blocked or delayed. The UI must explain this to the user, otherwise a flood of support tickets is guaranteed.

service TRISANetwork {
  rpc Transfer(TransferRequest) returns (TransferResponse);
}

message TransferRequest {
  string identity_payload = 1;  // encrypted PII packet
  string envelope_public_key = 2;
  string transaction_hash = 3;
}

How to choose a KYC/AML provider for a crypto project?

KYC providers for cryptocurrencies fall into several tiers:

Tier 1 (enterprise, regulatory grade): Jumio, Onfido, Sumsub, Veriff. Support 200+ countries, video verification, liveliness checks, AML screening via Refinitiv/Dow Jones. Integration via REST API + webhooks. Sumsub is popular in European crypto projects—good SDK documentation for mobile apps.

Tier 2 (DeFi-native, privacy-focused): Fractal ID, Synaps, Persona. Less regulatory overhead, faster integration, but less global coverage for high-risk jurisdictions.

On-chain KYC via credentials: Quadrata Passport, Civic, PolygonID—user verifies once, gets an on-chain credential, protocols verify it without repeated verification. Privacy-preserving via ZK. Not mainstream yet, but we are laying the groundwork in the architecture.

Architectural principle: KYC data is never stored on-chain. Personal data is stored with the provider or in your encrypted database; on-chain only a hash (commitment) or credential (if using VC/SBT approach). This ensures GDPR compliance: the right to erasure is achievable if data is off-chain.

Typical mistake: storing wallet-to-identity mapping in plaintext in PostgreSQL without row-level encryption. One SQL injection and the entire KYC database is compromised. Minimum: column encryption for PII fields (PGP or AES via pgcrypto), separate key management (AWS KMS, HashiCorp Vault), audit log for all PII access.

For AML screening, we use Chainalysis, Elliptic, or TRM Labs. Integration is asynchronous via webhook: results come in 1–5 seconds. Threshold-based blocking: HIGH risk — auto-block, MEDIUM — manual review. Hold period for suspicious transactions is 24–72 hours until manual review. Sanctions screening separately: OFAC SDN list updates several times a week; we use direct OFAC list integration (free) with custom address matching logic.

How do we implement MiCA support?

Markets in Crypto-Assets Regulation (EU 2023/1114) requires CASP (Crypto-Asset Service Provider) licensing in one EU state with passporting. Technical requirements affecting development:

White paper is mandatory for issuers of ART (Asset-Referenced Tokens) and EMT (E-Money Tokens)—not a marketing document but a legally binding prospectus with technical description, holder rights, and redemption mechanisms.

Custody requirements: client assets separate from operational assets. Technically: separate wallets/accounts per client (or omnibus with off-chain mapping + regular reconciliation), no possibility to use client funds for operational needs.

Transaction monitoring and reporting: CASPs must keep records of all transactions for at least 5 years and provide them to the regulator upon request.

Travel Rule in MiCA: the threshold for VASP-to-VASP transfers is zero (not the FATF threshold). Implementation requires a Travel Rule endpoint operating 24/7.

Compliance infrastructure implementation process

Compliance architecture is not added on top of an existing product without pain. The correct order: compliance requirements → data model → business logic → UI. If you already have a product without a compliance layer, we start with a gap analysis: what data is already collected, where the gaps are, what will require schema migration.

1. Gap analysis — audit of current architecture and data flow (1–2 weeks).
2. Design — selection of KYC provider, Travel Rule protocol, AML tool, data model.
3. Integration — connecting KYC API, implementing AML screening in the pipeline, setting up Travel Rule gateway.
4. Testing — end-to-end tests, simulating Travel Rule handshake, verifying sanctions screening.
5. Deployment and monitoring — rollout with feature flags, setting up alerting for compliance service errors, audit trail.
6. License support — preparing documentation for the regulator, assisting with inspections.

What does the blockchain compliance service include?

• Compliance architecture documentation (data flow, ER diagrams, API specifications).
• Integration of KYC/AML/Travel Rule APIs with your backend.
• Setup of monitoring and alerting for compliance services.
• Training your team on tools (Chainalysis, Sumsub, etc.).
• Support during the licensing process (MiCA, FATF).

Timeline benchmarks

• KYC/AML integration with Sumsub or Jumio — from 3 to 6 weeks.
• Travel Rule (TRISA or Sygna) — from 6 to 10 weeks.
• Full compliance infrastructure for CASP licensing — from 4 to 8 months.
• On-chain compliance via VC/SBT with ZK (MiCA-ready) — from 5 to 9 months.

Scope is refined after gap analysis. To evaluate your project, contact us—we will conduct a free analysis of your current architecture and select the optimal set of tools. Get a consultation on compliance architecture for MiCA or Travel Rule. Our team has over 7 years of blockchain development experience and 15+ deployed compliance solutions. Request an audit of your protocol for compliance with current regulatory requirements.