Crypto Risk Framework: What Regulators Actually Expect from a VASP
🛡️ Compliance · VASP Risk
Crypto Risk Framework: What Regulators Actually Expect from a VASP
The risk-based approach explained — what it means in practice, what FATF, VARA, MAS, and FSC want to see, the most common failures, and a step-by-step guide to building a compliant risk framework from scratch.
1
Risk-based approach: what it actually means
The practical definition regulators use
2
The risk matrix: inherent vs residual risk
How risk is scored and where controls fit
3
What FATF, VARA, MAS and FSC expect
Regulator-specific requirements
4
Common failures in VASP risk frameworks
What regulators find and why it matters
5
Building a risk framework from scratch
Step-by-step guide with practical outputs
🎯 Section 1
Risk-based approach: what it actually means
Every VASP licensing regime requires a “risk-based approach” to AML/CFT. Most founders know the phrase — fewer understand what it actually requires in practice. Here is the functional definition that regulators use when they examine your framework.
The risk-based approach — three operational requirements
What it means when a regulator asks “describe your RBA”
3 requirements
1
You have assessed your own risk profile before applying controls
A risk-based approach starts with a documented assessment of your specific risks — not a generic list of crypto industry risks, but a structured analysis of your business: which products you offer, which customers you serve, which geographies you operate in, and which channels you use. This is your inherent risk profile — the risk before any controls are applied.
What regulators look for: A risk assessment document that is specific to your business. Not a template. Not a copy of FATF guidance. An analysis that demonstrates you have actually thought about your risks, scored them, and can explain the scoring methodology.
2
Your controls are proportionate to the risk you identified
The controls you apply — CDD level, transaction monitoring thresholds, EDD triggers, geographic restrictions — should be proportionate to the risks you identified. High-risk customers get enhanced due diligence. Low-risk customers get simplified due diligence. The controls must follow the risk assessment — not be applied uniformly regardless of risk level.
This is where most frameworks fail: they document the risk assessment and the controls separately, without connecting them. A regulator reading your framework should be able to trace from “we identified X as high risk” to “therefore we apply Y control” to “here is evidence we applied it.”
3
You review and update the framework as your business changes
A risk framework is not a document you write once and file. It must be reviewed whenever your business materially changes: new products, new markets, new customer segments, new channels, significant changes in transaction volumes. Most licensing regimes require an annual review at minimum.
Practical implication: Your risk framework must have a documented review history — version control, review dates, and a record of what changed and why. A risk framework with no review history since its initial creation tells a regulator that you are not actually operating it.
The regulator’s test
When a regulator examines your risk framework, they ask three questions: Can you explain your methodology? Can you show the connection between your risk assessment and your controls? Can you show that it is being operated, not just documented? If you cannot answer all three with evidence, you have a gap — regardless of how comprehensive the document looks on paper.
📊 Section 2
The risk matrix: inherent vs residual risk
The core structure of any VASP risk framework is the distinction between inherent risk (the risk your business carries before any controls) and residual risk (the risk that remains after controls are applied). Both need to be scored, documented, and managed.
📈 Inherent risk
Risk before controls — four dimensions
Customer risk
Who are your customers? Retail vs institutional. Jurisdictions of residence. PEP status, adverse media exposure. Business type for corporate customers. Each customer type carries a baseline risk rating — high, medium, or low — that determines the CDD level applied at onboarding.
Product and service risk
What do you offer? Spot exchange carries different risk from custody. Anonymity-enhancing products (privacy coins, mixers) carry higher risk than standard crypto exchange. High transaction volumes or large transaction sizes increase inherent risk. Each product in your portfolio needs its own risk rating.
Geographic risk
Where do your customers come from? Where do transactions flow to? High-risk jurisdictions — FATF grey/black list, EU high-risk third countries, OFAC sanctioned countries — carry elevated inherent risk. You need a documented geography risk rating table covering every jurisdiction you operate in.
Channel / delivery risk
How do customers access your service? Non-face-to-face onboarding (standard for crypto) carries higher inherent risk than in-person. Automated onboarding without live review for high-value transactions adds risk. The more distance between you and the customer, the higher the inherent channel risk.
📉 Residual risk
Risk after controls — what regulators assess
Control effectiveness reduces inherent risk
Residual risk = inherent risk minus the effectiveness of your controls. A robust CDD process reduces customer risk. Transaction monitoring reduces product risk. Geographic restrictions reduce geographic risk. Each control must be assessed for effectiveness — not just documented as existing.
Residual risk must be within risk appetite
Your risk appetite statement sets the maximum residual risk you are willing to accept. If residual risk in a category exceeds your stated risk appetite, you must apply additional controls — or exit that product, market, or customer segment. The framework must be actionable, not merely descriptive.
Residual risk triggers monitoring intensity
Higher residual risk triggers more intensive monitoring: lower transaction thresholds for alerts, more frequent CDD reviews, faster escalation of suspicious activity. The monitoring programme must be calibrated to residual risk — not set at a uniform level regardless of the customer or product risk profile.
Residual risk is what regulators examine
Regulators do not penalise high inherent risk — many crypto products carry inherently high risk and regulators know it. They examine whether your controls are adequate to bring residual risk to an acceptable level, and whether you can demonstrate that your controls are actually working in practice.
Scoring methodology matters
Your risk framework must include a documented scoring methodology — how you rate each dimension, what the scales are (e.g. 1–5 or low/medium/high), and how individual dimension scores aggregate into an overall risk rating. A framework that says “we consider customer, product, geography, and channel risk” without a documented scoring method is not a risk framework — it is a list of factors. Regulators will ask: “Show me how you calculated that this customer is medium risk.”
🏛️ Section 3
What FATF, VARA, MAS and FSC actually expect
Different regulatory bodies express the risk-based approach requirement differently — but all expect the same core elements. Here is what each major framework specifically requires for VASP risk frameworks.
International standard
FATF — the baseline everyone uses
Recommendations 1, 10, 15, and VASP guidance
Core requirement: FATF Recommendation 1 requires countries and financial institutions to identify, assess, and understand ML/TF risks. The 2023 FATF VASP guidance specifically requires VASPs to conduct business-wide risk assessments covering: products/services, customers, geographies, channels, and delivery mechanisms.
What FATF expects: A written, board-approved business risk assessment. Documentation of the risk assessment methodology. A risk appetite statement. Clear connection between the risk assessment and the controls applied. Evidence of review at least annually and when material changes occur.
Practical note: FATF guidance is the floor — national regulators build on it. If your framework meets FATF requirements, it satisfies the baseline for VARA, MAS, and FSC. But each adds jurisdiction-specific elements — do not assume FATF-compliant equals locally compliant without checking the local rules.
VARA / FSC
VARA and Mauritius FSC — practical requirements
What these specific regulators look for
VARA (UAE): VARA’s AML/CFT rulebook requires a documented Business Risk Assessment (BRA) specific to each licensed VASP. The BRA must cover all four risk dimensions, use a documented scoring methodology, be reviewed annually, and be approved by senior management. VARA’s examination teams specifically look for the connection between BRA findings and the transaction monitoring ruleset.
Mauritius FSC: The FSC’s VASP application process requires a risk framework as part of the compliance manual. FSC examiners look for: a geographic risk matrix covering all operating countries, a product risk assessment covering all services offered, and a customer risk rating methodology with documented EDD triggers. The FSC is particularly focused on geographic risk ratings given Mauritius’s FATF monitoring history.
Common gap: Both VARA and FSC find that VASPs submit risk frameworks that are copies of industry templates without jurisdiction-specific calibration. A framework with no reference to UAE-specific risks, VARA guidance, or the specific products you offer will generate queries.
MAS
MAS — the most rigorous standard
Singapore’s detailed risk framework requirements
MAS requirements: MAS Notice PSN01 and the accompanying AML/CFT guidelines for digital payment token service providers set detailed requirements for risk assessment, risk appetite, and controls. MAS requires annual enterprise-wide risk assessments (EWRA) — a comprehensive document covering all risk dimensions across all products and markets.
What MAS specifically expects: Quantitative risk scoring (not just qualitative descriptions). A risk appetite statement with specific thresholds. CDD triggers mapped to risk scores. A customer risk rating model applied consistently across the customer base. Transaction monitoring rules calibrated to the risk assessment findings. Evidence of board-level review and sign-off.
The MAS standard: If you are targeting a MAS licence, your risk framework must be the most sophisticated of the three. MAS examiners are experienced and will test the framework in practice — asking for specific customer examples to trace through the risk rating model. A framework that cannot be applied to real customers is not operationally compliant.
The template problem
The most common reason a risk framework fails examination is that it is a purchased or copied template that has not been calibrated to the specific VASP. Regulators see hundreds of risk frameworks — they recognise templates. A framework that describes “typical crypto industry risks” without reference to your specific products, customer base, geography mix, or transaction volumes is not a risk framework — it is a compliance decoration. It will not pass examination at any of these regulators.
🚫 Section 4
Common failures in VASP risk frameworks
These are the specific deficiencies that regulators most commonly identify in VASP risk framework examinations — and the ones most likely to result in remediation requirements, licence conditions, or enforcement action.
Common risk framework failures — the examiner’s checklist
Each is a finding regulators document in examination reports
Avoid these
No documented risk scoring methodology
The framework identifies risk factors but does not explain how they are scored or how scores aggregate into an overall risk rating. “We consider customer risk, product risk, geographic risk, and channel risk” is not a methodology — it is a list. Regulators need to see how you weight each factor and how the scores combine.
No geographic risk ratings table
A risk framework that does not include a jurisdiction-by-jurisdiction risk rating table is incomplete. Regulators expect to see every country you operate in (source of customers, destination of transactions) rated against criteria including FATF listing, sanctions status, corruption indices, and financial system maturity. “High-risk countries are restricted” without a list of which countries are rated high-risk is not a risk framework.
No product risk assessment
Each product or service offered needs its own risk rating. A VASP offering spot exchange, staking, and custody has three different product risk profiles — and its controls should differ accordingly. A single generic “crypto exchange risk” rating that covers all products is not sufficient for a multi-product VASP.
Controls not connected to the risk assessment
The risk assessment and the controls manual are written as separate documents with no connection between them. A regulator should be able to read: “We assessed X as high risk, therefore we apply Y control, as documented in Section Z of the compliance manual.” Without this explicit connection, the framework cannot demonstrate a risk-based approach — it demonstrates two unrelated documents.
No review history or version control
The risk framework has no documented review dates, no change log, and no evidence of board approval. A framework with the same version date from 18 months ago, during which time the business launched three new products and entered two new markets, tells a regulator that the RBA is not being operated as a live document.
Risk appetite not defined or not actionable
The risk appetite statement says “we have a low risk appetite for money laundering” without defining what that means operationally — which customer segments you will not serve, which jurisdictions you will not accept, which transaction patterns trigger mandatory rejection. An actionable risk appetite translates into specific operational decisions. A descriptive risk appetite is compliance theatre.
The examination consequence
When a regulator identifies a deficiency in your risk framework, the typical outcome is a formal remediation requirement — fix this within 60–90 days and demonstrate it in a follow-up review. Repeated or systemic deficiencies result in licence conditions, enhanced supervision, or enforcement action. The cost of a regulator-required remediation under examination pressure is 3–5 times the cost of getting the framework right the first time.
🏗️ Section 5
Building a compliant risk framework from scratch
Here is the practical sequence for building a VASP risk framework that will withstand regulator examination — with the outputs you need at each stage.
Five stages to a regulator-ready risk framework
Build in this sequence — do not skip stages
5 stages
1
Business mapping — understand what you are rating
1–2 weeks
Before you can assess risk, you need a complete map of your business: every product and service offered, every customer segment served, every jurisdiction where customers are located or transactions flow, and every channel through which services are delivered. This sounds obvious — but many VASPs start the risk assessment before they have a complete picture of their own business. Map it first.
2
Develop the scoring methodology
1–2 weeks
Define how you will score each risk dimension: the rating scales (1–5 or low/medium/high/very high), the criteria for each rating level, the weighting of each dimension, and the aggregation method to reach an overall risk score. The methodology must be documented and defensible — you will need to explain it to examiners. It does not need to be complex, but it must be consistent and applied the same way every time.
3
Build the risk assessment — score every dimension
2–3 weeks
Apply the methodology to produce: a product risk matrix (one row per product/service), a customer risk rating framework (risk criteria for each customer segment), a geographic risk ratings table (one row per relevant jurisdiction), and a channel risk assessment. Each dimension should have explicit scores with documented rationale — not just a rating but why that rating was assigned.
4
Define risk appetite and connect to controls
1 week
Draft the risk appetite statement: define the maximum acceptable residual risk level in each dimension, and specify what you will not do (refused customer types, restricted jurisdictions, products you will not offer). Then explicitly connect each risk finding to the controls in your AML/KYC policy — high geographic risk → mandatory EDD for residents of high-risk jurisdictions → see Section X of compliance manual. This connection is what makes it a risk-based approach, not just a risk assessment.
5
Board approval, version control, and review calendar
1 week + ongoing
Submit the completed BRA to senior management/board for formal approval. Document the approval with minutes or sign-off record. Establish version control and a change log. Set a review calendar: annual full review, plus a trigger-based review protocol (material change in product, market, or regulatory environment). From day one, the framework should look like it is being operated — dated versions, documented review meetings, clear ownership.
Build a risk framework that passes examination — not just inspection
Our compliance team builds VASP risk frameworks for FATF, VARA, MAS, FSC, and MiCA examination — calibrated to your specific business, products, customer base, and geographies. We have been through enough examinations to know what regulators actually look for — and what gets frameworks rejected.
Post Comment