Case study: launching a compliant VASP

Every part of this course meets in one question: could you launch a crypto business and show a supervisor, 18 months later, that its program works? This case follows a fictional exchange from its first risk assessment to its first inspection, applying each module in turn. Names, countries and identifiers are invented.

The firm and its markets

Veltora Exchange is a start-up based in Country A. It will offer crypto-to-fiat and crypto-to-crypto exchange, custody, and withdrawals to external addresses: four of the five FATF VASP activities (see the lesson The VASP as an obliged entity). It plans to launch at home, then expand to Country B, a large retail market, and Country C, a smaller market with fast-growing crypto use. Mapping the three regimes with the method from the lesson How national regimes implement the standard gives:

The case runs over 18 months:

Step 1: Risk assessment and appetite

At month 0 the compliance lead runs the enterprise-wide risk assessment described in the lesson The risk-based approach, using the national risk assessments of all three countries as input.

The board's risk appetite statement turns the assessment into decisions: no privacy coins, no crypto kiosks, no peer-to-peer marketplace, direct withdrawals to mixers and sanctioned services blocked, and only spot trading with lower limits for Country C residents in the first year. Each choice mitigates a technology risk from the lesson Technology risks specific to crypto instead of exiting a whole market. Increased monitoring is treated as a risk factor that calls for enhanced measures, not as a reason to refuse every customer from Country C.

Step 2: Program design

Following the lesson Building the compliance function, the board appoints an MLRO with a direct line to its risk committee and a trained deputy. Veltora uses a hub-and-spoke model: monitoring, investigations and Travel Rule operations sit in Country A; Country B gets a resident compliance officer; Country C is served from the hub. The headcount model gives 12 compliance staff at launch and is rerun before each expansion. Level-1 alert review is outsourced, with a 5% quality sample reviewed in-house.

A group policy is written to the strictest common standard, with short addenda for each country. The risk and control matrix holds 140 controls, 38 of them key. For technology, Veltora buys identity verification, list data, blockchain analytics and a Travel Rule solution that supports IVMS101 and two open protocols, and builds its own data platform and decision logic. Pre-transaction checks fail closed.

Step 3: Customers

Onboarding applies the methods of Module 2. Two files show the hard cases:

• A customer from Country B deposits 35 BTC from a self-hosted wallet and says the coins were bought in 2013. Source of funds is evidenced by a signed message proving control of the address, the on-chain history back to a 2013 withdrawal from an exchange, and a dated purchase record. The file is approved with EDD and recorded as such.
• Tolvik Pay, a payment processor in Country B, applies for an institutional account. Its shareholder is an offshore holding company with nominee directors. Veltora asks for the ownership chain and the agreements that give control; when the beneficial owners cannot be identified, it declines the application and considers whether a report is warranted.

Step 4: Travel Rule

Instead of three rule sets, Veltora sends full IVMS101 originator and beneficiary data on every transfer to another VASP, whatever the amount, which also satisfies Country B's zero threshold. Every counterparty VASP passes due diligence before it receives customer data. Incoming transfers that arrive without required data are held for up to two business days while data is requested, then returned.

Country C is a sunrise case: its VASPs have no legal duty yet. Veltora sends data to Country C counterparties that pass due diligence and can receive it securely, and blocks withdrawals to those that cannot. For unhosted wallets, it collects counterparty information from its own customer and requires proof of control by signed message above Country B's threshold and above its own internal limit everywhere (see the lesson Unhosted wallets and self-hosted transfers).

Step 5: Sanctions

Veltora screens names and wallets against the UN Security Council consolidated list and every autonomous list that applies in Countries A, B and C, rescreening the whole customer base on each list change. Geoblocking combines the address on file, IP data, VPN and hosting-provider detection, and device signals.

At month 11, pre-credit screening flags a deposit of 4.2 ETH from an address added to a list two days earlier. The funds are frozen in a segregated account, the customer's account is restricted without explanation that could tip them off, the competent authority in Country A is notified within the required period, and an investigation reviews the customer's other counterparties (see the lesson Wallet and transaction screening).

Step 6: Monitoring and reporting

Fourteen scenarios go live at launch, among them a rapid in-and-out rule for new accounts:

-- TM-07: accounts opened in the last 30 days that withdraw at least
-- 90% of a day's deposits, when deposits reach USD 5,000 or more
WITH daily AS (
  SELECT customer_id, CAST(event_at AS DATE) AS day,
         SUM(CASE WHEN direction = 'IN'  THEN amount_usd ELSE 0 END) AS dep,
         SUM(CASE WHEN direction = 'OUT' THEN amount_usd ELSE 0 END) AS wd
  FROM transfers
  GROUP BY customer_id, CAST(event_at AS DATE)
)
SELECT d.customer_id, d.day, d.dep, d.wd
FROM daily d
JOIN customers c ON c.customer_id = d.customer_id
WHERE c.onboarded_at >= CURRENT_DATE - INTERVAL '30' DAY
  AND d.dep >= 5000
  AND d.wd >= 0.9 * d.dep;

The query totals each customer's deposits and withdrawals per calendar day, then keeps new accounts whose same-day outflows reach 90% of inflows. A calendar day is a simplification of a rolling 24-hour window; interval syntax differs between engines.

After the Country B launch, alerts jump to 11,000 a month. Below-the-line testing (see the lesson Tuning, metrics and model governance) supports raising one threshold, and a new scenario targets a pattern found in investigations: first-time buyers sending their whole balance to new addresses later linked to investment scams. Each licensed entity files reports with the financial intelligence unit of its own country, and suspicion is shared within the group only where the law allows.

Step 7: The first inspection

At month 15 internal audit tests the whole program. At month 18 Country A's supervisor inspects, requesting the risk assessment, policies, board minutes and management information, 60 customer files, 25 alerts, all reports filed, Travel Rule logs, training records and the audit report.

The supervisor credits Veltora for finding the first issue itself. The remediation plan names owners and dates, internal audit validates each fix before closure, and progress is reported quarterly, as described in the lessons Training, culture and independent testing and Supervision, examinations and enforcement.

What the case teaches

• The risk assessment drives every later choice, and it must be redone before each new market, not after.
• One strict global rule, such as full Travel Rule data on every VASP transfer, is often cheaper than several local ones.
• Most findings trace to process changes that skipped the control framework: a new country, an exception, an outsourced task.
• Evidence that the firm found and fixed its own problems carries real weight with supervisors.

Exam focus: using the enterprise-wide risk assessment and national risk assessments to set risk appetite; treating a country under increased monitoring as a risk factor, not an automatic exit; designing a hub-and-spoke function and rerunning the headcount model before expansion; evidencing source of funds for early holdings and declining when beneficial ownership is unclear; a single global Travel Rule standard, sunrise counterparties and unhosted-wallet controls; freezing and reporting funds from a newly designated address; tuning after launch; tracing inspection findings to root causes and validating remediation.