A virtual asset service provider (VASP) that cannot demonstrate a credible, documented business risk assessment is already behind the regulatory line. Supervisors across every major licensing hub – from VARA in Dubai to MAS in Singapore to ESMA and the national competent authorities implementing MiCA – treat the risk assessment as the foundation of the entire compliance architecture. Without it, your AML program has no calibration, your transaction monitoring has no thresholds, and your regulator has no basis for confidence. This guide walks through each step of the process in the order it matters, with the regulated basis at each stage and the cross-border complications that operators most frequently underestimate.
Running a VASP business risk assessment means systematically identifying, measuring and documenting the money-laundering, terrorist-financing and sanctions risks that your specific business model generates – then building proportionate controls around them. The FATF Recommendations, particularly Recommendation 15 on virtual assets, set the international baseline. Every jurisdiction that has implemented a licensing or registration regime for VASPs expects that baseline to be operationalized in writing before any application is filed or any service goes live. The steps below track that logic.
Why the Risk Assessment Comes First
The business risk assessment is not a compliance checkbox – it is the document from which every other control is derived. A well-constructed assessment tells the regulator, and your own MLRO, which customer segments carry the highest exposure, which transaction types require enhanced due diligence, and where in your product suite the controls need to be tightest. Regulators under MiCA, the MAS Payment Services Act regime, and the VARA rulebooks all expect the risk assessment to precede the compliance manual, not follow it.
Operating without this foundation creates compounding exposure. If your transaction monitoring thresholds are not tied to a documented risk rating, a supervisor can challenge whether your program is fit for purpose – even if your KYC onboarding looks clean. In our practice, we have seen firms arrive at a licensing review with excellent customer due-diligence procedures but no coherent risk assessment to justify why those procedures were calibrated the way they were. The result is a remediation request that delays authorization by months.
The cross-border dimension sharpens the stakes further. A VASP serving customers in multiple jurisdictions carries layered risk: the entity is licensed in one place, the user base sits in another, the banking infrastructure is somewhere else entirely. Each of those layers adds a risk dimension that a single-jurisdiction assessment will miss.
Step 1: Define Your Regulated Perimeter
Before you can assess risk, you must define precisely which activities your business conducts and in which jurisdictions those activities attract regulation. Under the FATF virtual-asset framework, the regulated perimeter turns on the functions you perform – exchange, transfer, custody, administration, participation in token offerings – not on how you describe them internally. The same activity may trigger a CASP authorization requirement under MiCA, a Digital Payment Token licence under the MAS regime, and a separate VASP registration under the FCA's Money Laundering Regulations simultaneously, if your user base spans those jurisdictions.
Map every product against the activity categories defined by your primary regulator and each material secondary jurisdiction. Common mistake at this step: firms include only the jurisdictions where their entity is incorporated, ignoring the jurisdictions where their customers actually sit. Regulators increasingly take a customer-location view of regulatory perimeter. A firm with a BVI entity serving EU-resident retail customers does not avoid MiCA by virtue of its offshore incorporation – it may still fall within the regime's scope depending on how the service is marketed and where customers access it.
The regulated perimeter must be documented in writing and reviewed whenever a new product, market or customer segment is added. This document becomes Schedule A of your risk assessment – the factual predicate on which everything else rests.
Step 2: Identify Your Inherent Risk Categories
Inherent risk is the risk your business carries before any controls are applied, and the FATF framework organizes it across four primary dimensions: customer risk, product and service risk, delivery channel risk, and geographic risk. Each dimension requires a structured analysis, not a narrative paragraph.
Customer risk covers the types of counterparties you onboard: retail versus institutional, high-net-worth individuals, politically exposed persons, corporate structures with complex ownership, customers from high-risk jurisdictions as classified by the FATF or ESMA's updated lists. Product risk covers the specific assets and services you offer: privacy-enhanced tokens carry a different inherent risk profile than mainstream exchange-traded assets; peer-to-peer lending introduces counterparty opacity that centralized exchange does not. Delivery channel risk addresses how customers access the service: anonymous app download, business-to-business API, or fully verified institutional onboarding. Geographic risk maps the countries from which your customers originate and to which transfers flow, cross-referenced against FATF grey-list and blacklist designations.
Common mistake at this step: treating inherent risk as a one-time exercise. Inherent risk changes every time the product changes. Adding a new token pair, opening a new corridor or shifting from B2B to retail changes your inherent risk profile and requires a documented update. Regulators under the VARA rulebooks and the MAS Payment Services Act regime both expect the assessment to reflect the current business, not the business as it was at authorization.
Step 3: Assess Your Controls and Calculate Residual Risk
Residual risk – the exposure that remains after your controls are applied – is what the regulator is actually assessing when it reviews your AML program. Calculating it requires an honest evaluation of whether each control is designed adequately and operating effectively. A KYC framework that requires enhanced due diligence for high-risk customers reduces inherent customer risk only if the EDD procedure is actually triggered consistently and documented for each affected account.
For each inherent risk identified in Step 2, document the corresponding control, its design adequacy (does it address the risk in principle?) and its operational effectiveness (is it actually being applied?). Where a control gap exists – where inherent risk is high and the control is either absent or under-tested – that gap must be flagged as a priority remediation item before the assessment is filed with a regulator or relied upon in an audit.
Transaction monitoring calibration lives here. The thresholds, rules and typologies loaded into your monitoring system should be a direct output of the residual risk analysis: the corridors you flagged as high geographic risk should carry tighter monitoring parameters than low-risk domestic flows. A common mistake is running a vendor's default rule-set without adjusting it to the business's own risk profile. Supervisors across every major hub have cited this as a finding in inspection reports.
The cross-border note at this step is critical. If you operate across the EU under MiCA passporting, your residual risk assessment must be consistent with the risk appetite and control standards of your home-state competent authority – but it must also account for the specific risk environment in each member state where you passport. A CASP authorized in one member state cannot simply apply a uniform residual risk rating to the entire EU footprint; local product and customer dynamics differ.
Step 4: Address the Travel Rule Obligation
The Travel Rule – the obligation under FATF Recommendation 16 (as applied to virtual assets under Recommendation 15) to pass originator and beneficiary data with every covered virtual-asset transfer – is a standalone compliance layer that must be integrated into the business risk assessment, not treated as a separate operational project. Under MiCA, the MAS regime, VARA, and the ADGM/FSRA framework, Travel Rule compliance is a condition of authorization. A risk assessment that does not address it is incomplete on its face.
Document the following within the assessment: the jurisdictions where the Travel Rule is in force for your business, the data fields required in each, the technical protocol your firm uses to transmit and receive Travel Rule data (IVMS 101 is the near-universal data standard), and the procedure for handling transfers to or from counterparty VASPs that cannot demonstrate Travel Rule capability. That last point is material: sending to a non-compliant VASP is itself a risk event that must be managed, either by blocking the transfer or by applying enhanced due diligence to the transaction.
Common mistake at this step: treating the Travel Rule as a technology problem rather than a legal one. The choice of Travel Rule protocol and counterparty VASP vetting policy is a legal and compliance decision. The technology solution implements that decision; it does not substitute for it.
Step 5: Document the Risk Appetite Statement
A risk appetite statement translates the inherent-risk and residual-risk analysis into a set of defined limits: which customer segments the firm will and will not serve, which jurisdictions are restricted or prohibited, which product features require board-level approval before launch, and what residual risk level the business is prepared to accept in each category.
The risk appetite statement serves two functions. First, it gives the MLRO a documented mandate: when a borderline onboarding decision comes up, the MLRO can point to the statement to justify the outcome. Second, it gives the regulator evidence that the business has exercised genuine judgment, not just copied a template. Supervisors at the FCA, MAS and VARA have all signaled that a risk appetite statement that looks identical to a generic model will attract scrutiny.
In our practice, we have worked through risk appetite reviews with firms that discovered, in the process of documenting their statement, that their actual onboarding behavior was inconsistent with what they were about to sign off as policy. That discovery – early, in the drafting stage – is far less damaging than the same finding surfacing during a supervisory inspection. The risk appetite statement is the document that forces that alignment.
The cross-border note: if your entity structure includes subsidiaries or affiliated entities in multiple jurisdictions, each entity may need its own risk appetite statement calibrated to local regulatory expectations, even if the group-level assessment sets the overarching risk tolerance. VARA, for example, applies its rulebooks at the Dubai licensed entity level; group policies do not substitute for entity-level documentation.
Step 6: Assign Ownership and Set the Review Cycle
A business risk assessment without a named owner and a scheduled review cycle is a static document in a filing cabinet. Regulators across every major VASP regime expect the assessment to be a living instrument, updated at defined intervals and whenever a material change in the business occurs.
Ownership sits with the MLRO in most framework structures, but the board or senior management must formally approve the assessment and its updates. That approval creates accountability at the governance level and gives the document regulatory weight. A risk assessment approved only at the compliance team level will not satisfy a supervisor who asks who in the firm's leadership has read and taken responsibility for the risk posture.
Set a minimum annual review cycle and add triggers for interim reviews: a new product line, a new jurisdiction, a new banking partner, a material change in the customer base, or a public FATF or regulator guidance update affecting your risk categories. Document each review in a version log that records what changed, why, and who approved the update.
Common mistake at this step: conflating the review of the risk assessment with the review of the compliance manual. They are separate documents with different review logics. The risk assessment drives the compliance manual; changes to the assessment must flow through to the manual, but reviewing the manual does not substitute for reviewing the underlying risk analysis.
Step 7: Integrate with the Wider Compliance Architecture
The business risk assessment should be the top-level input into your entire compliance architecture: the KYC framework, the enhanced due-diligence triggers, the transaction monitoring rule-set, the sanctions screening parameters, the Travel Rule policy, and the suspicious activity reporting procedure should all trace back to specific findings in the assessment. If a control exists that is not referenced anywhere in the risk assessment, that is a signal that either the control is unnecessary or the assessment is incomplete.
In cross-border structures, this integration requires explicit mapping between the group-level assessment and the entity-level compliance manuals. A firm operating under MiCA passporting, a separate MAS licence and a VARA licence needs to show that each entity's controls reflect the risk profile of that entity's specific activity and customer base – not just a copy-paste of the group document with the entity name changed.
Regulators increasingly conduct thematic reviews of how compliance documents relate to each other. An inspector at the Bank of Lithuania, for example, may ask for the risk assessment and then trace a specific customer segment or product feature through the KYC framework, the monitoring rules and the MLRO reporting line. If those documents are not coherent – if the monitoring thresholds do not reflect the geographic risks in the assessment, or the EDD triggers do not match the customer risk ratings – the finding is a systemic one, not a procedural one.
To pressure-test your compliance architecture before you commit to a licensing application or a new market entry, write to us at info@oboluslaw.com.
A Cross-Border Case Illustration
In a recent compliance matter, a custodian operating under both a Gulf-region VASP authorization and a European AML registration engaged us to review why its compliance program had generated a supervisor query at the point of a routine inspection. The firm had a well-drafted group risk assessment but had not translated it into entity-level documentation for its European-registered entity. The European supervisor's inspection focused on the registered entity; the group-level document was not considered responsive. We worked through a rapid entity-specific risk assessment for that entity, mapped the inherent and residual risk findings to the existing monitoring rules, and produced a revised risk appetite statement calibrated to the entity's actual customer base. The supervisor accepted the remediation within the statutory response period and closed the query without a formal finding. The lesson was immediate: group documents do not substitute for entity-level analysis in multi-jurisdictional structures.
Common Structural Mistakes and How to Avoid Them
A common assumption in the industry is that a template risk assessment – particularly one supplied by a compliance software vendor or derived from a competitor's public documentation – satisfies the regulatory expectation. It does not. Regulators distinguish between a document that reflects genuine analysis of the specific business and one that is formulaic. The distinction is visible in the specificity of the risk ratings: a generic document rates all customer risk as "medium"; a genuine assessment rates retail customers in a FATF grey-list jurisdiction as "high" and documents exactly why.
A second structural mistake is underweighting the geographic risk dimension in the context of a cross-border VASP structure. The risk is not simply where the entity is licensed; it is where the customers are, where the transactions flow, and where the counterparty VASPs are incorporated. A VASP whose entity sits in a well-regulated hub but whose transaction flows run predominantly through high-risk corridors carries a high geographic risk profile that must be reflected in both the risk assessment and the monitoring calibration.
A third mistake is failing to document the rationale for accepting a residual risk level that sits above low. Regulators do not expect every residual risk to be reduced to low – that would make many legitimate business models commercially unviable. What they do expect is a documented, board-approved rationale for any residual risk accepted above the base level, together with the enhanced controls applied to contain it.
If a prior application stalled or a supervisor query has been received, a second read of the risk assessment can surface the structural reason and the route back. Contact OBOLUS at info@oboluslaw.com to discuss your situation under NDA.
Self-Assessment Checklist
Before filing a risk assessment with a regulator or relying on it internally, confirm the following:
- The regulated perimeter is mapped across all jurisdictions of customer activity, not entity incorporation only.
- Inherent risk is rated across all four FATF dimensions: customer, product/service, delivery channel and geography.
- Residual risk is calculated for each inherent risk category, with the specific controls listed and their operational effectiveness assessed.
- Transaction monitoring thresholds trace directly to the residual risk analysis.
- The Travel Rule obligation is addressed: protocol, data fields, and non-compliant counterparty procedure are documented.
- The risk appetite statement has been approved at board or senior-management level.
- A named MLRO owns the document and a review cycle is set, with interim-trigger events defined.
- Entity-level assessments exist for each licensed or registered entity; group documents do not substitute for them.
- The document has been reviewed by qualified legal or compliance counsel with VASP-specific expertise.
Related at OBOLUS
- AML, Travel Rule and Compliance for Digital-Asset Businesses – our full practice coverage for VASP compliance mandates across major licensing hubs
- Transaction Monitoring Setup for Established Operators – calibrating monitoring rules to your specific risk profile and regulatory perimeter
- Fiat On/Off-Ramp Banking: Where the Legal Lines Are Drawn – the banking and payment-infrastructure risks that compound compliance exposure
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a VASP to collect, verify and transmit originator and beneficiary information alongside each covered virtual-asset transfer. The specific data fields and the transfer-value threshold above which the obligation applies vary by jurisdiction, but the FATF standard – implemented through MiCA, MAS, VARA and other regimes – is the international baseline. VASPs must also vet the Travel Rule capability of counterparty VASPs before sending to them and have a procedure for handling transfers to non-compliant counterparties.
Who must act as MLRO for a crypto firm?
Most licensing regimes require a Money Laundering Reporting Officer (MLRO) who is a fit-and-proper individual approved by the regulator, with sufficient seniority, authority and independence to discharge the role. The MLRO must have direct access to senior management or the board, cannot be the same person as the CEO in most structures, and must be named in the compliance documentation submitted to the regulator. Some regimes permit an outsourced MLRO function in early-stage firms, subject to conditions. The specific requirements vary by jurisdiction and licence category.
How do regulators audit crypto AML programs?
Regulators conducting AML inspections of VASPs typically request the business risk assessment, the compliance manual, a sample of customer files, transaction monitoring alert logs, and MLRO reports for a defined period. They then trace the consistency of those documents: do the monitoring thresholds reflect the risk assessment? Are high-risk customer files showing the EDD steps the manual requires? Inspectors under the MiCA regime, VARA and MAS have all signaled that document coherence – not just document existence – is the standard against which the program is measured.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the tax, banking and compliance that sit around them. Digital assets are the whole of our practice. We map the licence, compliance and banking stack across operating, custody and payment layers before you commit – and our disputes team coordinates freezing relief and on-chain tracing across leading common-law forums when it matters most. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in VASP compliance architecture, AML program design and multi-jurisdictional risk assessment across the major licensing hubs.
This publication is general information about the law and does not constitute legal advice. It is not a substitute for advice tailored to your circumstances. OBOLUS accepts no liability for action taken or not taken on the basis of this material. For advice on your situation, contact info@oboluslaw.com.