Virtual Asset Service Providers (VASPs)

A bank relationship with a virtual asset service provider is not simply a normal corporate account with a technology-heavy customer. A VASP can sit at the boundary between traditional money and virtual assets, receive or send very large volumes on behalf of many underlying customers, interact with multiple blockchains and wallet types, and serve customers across jurisdictions where licensing, supervision and financial-crime controls are uneven. The bank may see only the fiat side of that activity unless it deliberately designs the relationship so that legal status, business model, customer profile, blockchain exposure and payment behaviour can be understood together.

That makes the practical question more useful than “is crypto high risk?” The useful question is: what exactly is this provider doing, for whom, under which legal and supervisory perimeter, through which wallets and counterparties, and what evidence allows the bank to understand and control the resulting exposure? A bank that answers those questions can support legitimate innovation without treating every crypto-related customer as unacceptable. A bank that cannot answer them may be taking risk it cannot see.

The FATF global framework is the starting point. Recommendation 15 extends AML/CFT expectations to virtual assets and VASPs and expects jurisdictions to identify, license or register, supervise and, where necessary, sanction relevant providers. FATF's July 2026 targeted update found continued progress but also important gaps in effective implementation, including licensing and registration in practice, identification of unlicensed activity, supervision and enforcement. FATF has separately highlighted offshore VASPs as a continuing risk where firms serve customers across borders from jurisdictions with weak or ineffective oversight. Those findings matter directly to banks because a licence or registration is evidence of regulatory status, not a guarantee that the provider's control environment, customer base or cross-border activity is low risk.

A bank should understand the VASP across legal perimeter, business model, customers, wallets, payment flows and ongoing control outcomes rather than relying on registration alone.

The mental model: a gateway relationship, not a label

The term VASP is a functional concept. Under the FATF framework it broadly covers businesses that, for or on behalf of another person, provide activities such as exchange between virtual assets and fiat currency, exchange between virtual assets, transfer of virtual assets, safekeeping or administration of virtual assets or instruments enabling control over them, and certain financial services connected with the offer or sale of virtual assets. Local law may use different labels and may not map perfectly to the FATF definition. The European Union, for example, uses the term crypto-asset service provider, or CASP, under MiCA and related AML/CFT rules. The United Kingdom uses its own Money Laundering Regulations perimeter for in-scope cryptoasset businesses. Australia now uses VASP terminology in its reformed AML/CTF regime. A bank therefore needs both a global risk taxonomy and a jurisdiction-specific legal mapping.

This distinction is important because a customer may describe itself as an exchange while actually providing several services: spot trading, custody, staking, transfers, OTC brokerage, card products, merchant settlement, institutional execution or access to DeFi. Another firm may describe itself as a software business but operate a hosted wallet service or intermediate asset transfers in a way that brings it within a regulated perimeter. Conversely, a technology supplier may provide software to VASPs without itself taking custody or executing transfers for customers. The bank should classify the customer's actual activities, not only its marketing description.

The same discipline applies to wallets. A hosted or custodial wallet relationship generally involves a service provider controlling or administering keys or assets for a customer. A self-hosted or unhosted address may be controlled directly by an individual or entity. Neither category is automatically illicit. The risk arises from the combination of control, identity, transaction context, counterparties, geography, asset characteristics and behaviour. Treating every self-hosted address as suspicious creates noise; treating all hosted addresses as safe because a provider is involved can be equally misleading.

For a bank, the VASP relationship usually creates at least two layers of customers. The bank's direct customer is the VASP. Behind it sit the VASP's own customers and counterparties. The bank may not have a direct legal relationship with those underlying users, but their activity can materially shape the bank's financial-crime exposure. This is similar to the logic seen in correspondent banking, merchant acquiring and payment intermediaries: the bank needs sufficient transparency into the respondent or intermediary's business and controls to understand the risk it is accepting, while avoiding the false assumption that it must perform full KYC on every underlying end user.

Why the relationship matters to a bank

A VASP can use a bank for ordinary corporate services such as payroll and expenses, but the more important relationships usually involve customer money, settlement and liquidity. The provider may hold operating accounts, receive customer deposits used to purchase virtual assets, send withdrawals to customers, settle with market makers, move funds to other exchanges, maintain safeguarding or client-money arrangements where required, buy or sell fiat for treasury purposes, use cards or payment rails, or connect through APIs for high-volume collections and payouts.

Each service changes the risk profile. An operating account used only for salaries and vendors is different from a settlement account receiving thousands of retail deposits a day. A domestic exchange serving a narrow customer base under active supervision is different from a global platform onboarding customers from many jurisdictions through offshore entities. A provider offering only spot trading is different from one supporting privacy-enhancing assets, high-risk tokens, cross-chain bridges, mixers, lending or institutional OTC services. The bank's control design should be driven by the services actually provided and the way value moves through them.

The relationship can also create non-AML risks that still matter to the overall decision. Prudential exposure, counterparty credit risk, liquidity risk, custody risk, operational resilience, cyber risk, consumer protection and market conduct may all be relevant. The Basel Committee's cryptoasset exposure framework has a standard implementation date of 1 January 2026 and addresses prudential treatment and disclosure of certain bank cryptoasset exposures. Binding requirements and timing for a particular bank depend on the applicable national implementation. That standard is not an AML rule and should not be used as one. It is nevertheless a reminder that the relationship may need a joined assessment across financial crime, credit, treasury, legal, operational risk and regulatory reporting.

Regulatory architecture: global standard, local obligation

FATF Recommendation 15 gives the global architecture, but it does not create a single worldwide VASP licence. Jurisdictions implement the standard through local laws, regulatory perimeters and supervisory arrangements. A bank should therefore avoid statements such as “FATF requires this customer to hold licence X.” The correct question is whether the activity falls within the applicable local perimeter and, if so, which licence, registration or authorisation is required.

FATF's July 2026 update is especially relevant for bank due diligence because it identifies implementation gaps even where legal frameworks exist. A provider may be established in one country, serve customers in another, operate technology from a third, and route payments through entities elsewhere. The bank should not assume that incorporation jurisdiction, website location or a single regulatory registration describes the whole group. Legal-entity mapping needs to connect each entity to the services it provides, the customers it serves, the licences or registrations it relies on, and the wallets and bank accounts it operates.

The risk of offshore VASPs deserves separate treatment. FATF's March 2026 report described offshore VASPs as providers created under the law of one jurisdiction, with or without physical presence, that provide services to clients in another jurisdiction. The concern is not “offshore” as a moral label. The concern is the potential mismatch between where the activity occurs, where the firm is incorporated, who is supposed to supervise it and whether effective oversight can actually be exercised. A bank should therefore look for substance, governance, supervisory access and enforcement history rather than relying on a certificate of incorporation.

In the European Union, EBA guidance applicable to CASPs from 30 December 2024 sets out ML/TF risk factors relating to customers, products, delivery channels and geographies and also addresses credit and financial institutions that have CASPs as customers or are otherwise exposed to crypto assets. This is an EU-specific framework and should not be universalised. It is nevertheless a useful illustration of the questions a bank should ask: what services are provided, how customers are identified, how transactions involving self-hosted addresses are handled, how blockchain analytics is used and how higher-risk situations are mitigated.

In the United Kingdom, in-scope cryptoasset businesses carrying on business in the UK must register with the FCA under the Money Laundering Regulations before starting in-scope services. FCA registration is a legal status under that regime, not an endorsement of the business. The UK has also announced a broader future cryptoasset regulatory regime expected to come into force in 2027. A bank dealing with a UK-facing provider therefore needs to know which regime applies now, what changes are coming and whether the provider's claims about “FCA regulated” accurately describe the permissions it actually has.

Australia's AML/CTF reforms took effect on 31 March 2026, and AUSTRAC now uses VASP terminology for providers previously described as digital currency exchange providers. AUSTRAC's 2026 supervisory actions, including suspension of a crypto ATM operator's registration, demonstrate an important principle: registration can coexist with material compliance concerns and enforcement action. The bank should verify current status and supervisory history, not only whether the name appears on a register.

Sanctions add another layer. OFAC's U.S.-specific guidance for the virtual currency industry explains that sanctions obligations apply to virtual currency transactions just as they do to other transactions within U.S. jurisdiction and emphasises risk assessment, internal controls, testing, training and use of available location and customer information. A non-U.S. bank should not treat OFAC guidance as a universal rule, but it may still have U.S. sanctions exposure through U.S. persons, U.S. dollar clearing or other jurisdictional nexus. Other sanctions regimes have their own legal tests. A global VASP relationship therefore needs a sanctions-jurisdiction matrix rather than a single global “sanctions check”.

The bank's decision should move from regulatory perimeter and legal entity mapping through control assessment, residual-risk decision and ongoing monitoring.

Onboarding: prove what the VASP is before judging how risky it is

VASP onboarding should begin with legal identity and group structure. The bank needs the contracting entity, registered address, principal place of business, ownership chain, beneficial owners, controllers, directors and key senior managers. It should understand the wider group, including entities used for customer contracting, custody, technology, treasury, market making or licensing. Where the platform has a global brand but multiple legal entities, the bank should map which entity serves which customer population and which entity will use the bank account.

Regulatory status should be independently verified through the relevant regulator or public register where available. The evidence should capture the regulator, licence or registration type, reference number, covered legal entity, permitted activities, effective date and any material restrictions. Screenshots or downloaded records may be retained for audit, but the system should also record structured fields so changes can be detected later. If the provider relies on passporting, transitional arrangements, exemptions or a foreign licence, the bank should obtain an approved legal interpretation rather than allowing a relationship manager to infer coverage.

Ownership and control require more than a percentage threshold. Complex holding companies, trusts, nominee arrangements, venture investors or founder control can obscure who actually directs the business. The bank should resolve beneficial ownership under applicable KYC law and separately assess control, source of capital, reputation and sanctions exposure. It should also understand material investors or controllers whose influence may affect governance even if they fall below a statutory beneficial-ownership threshold.

The business model needs to be decomposed into products and services. A useful inventory includes spot exchange, brokerage, institutional trading, custody, hosted wallets, staking, lending or borrowing, derivatives, token issuance support, payment services, cards, merchant services, ATM or kiosk activity, stablecoin services, cross-chain bridges, DeFi access and any privacy-enhancing functionality. Not all services will be allowed in every jurisdiction. The point is not to create a long checklist for its own sake but to understand what creates customer and transaction risk.

The customer base should be examined at a level that can be tested. The bank should know whether the VASP serves retail, corporate, institutional, other VASPs, money service businesses, merchants or professional traders; the main customer jurisdictions; the proportion of activity from higher-risk locations; the onboarding channels; and whether anonymous or weakly verified activity is possible. Where the provider accepts customers from jurisdictions where it lacks clear authorisation, that is a different risk from merely having customers who travel or transact cross-border.

Customer due diligence controls should be assessed as an operating system, not a policy document. The bank should understand how identity is verified, how legal entities and beneficial owners are handled, how PEPs and sanctions are screened, when enhanced due diligence applies, how source of funds or source of wealth is considered for higher-risk activity, and how periodic and event-driven reviews work. Sampling actual anonymised case evidence, where law and confidentiality arrangements permit, can be more informative than reading a polished policy.

The bank should also assess how the VASP determines wallet ownership or control where relevant, how it treats self-hosted addresses, and how it manages transfers to or from other providers. Blockchain analytics can help identify exposure to known illicit or high-risk services, but analytics output is probabilistic and depends on vendor attribution, clustering methodology and data freshness. A score should not be treated as legal proof. The bank should ask how alerts are generated, what thresholds mean, how analysts investigate them, and how errors or disputed attributions are handled.

Travel Rule capability is relevant even though the detailed rule belongs in the next chapter. The bank needs enough understanding to know whether the provider can collect, transmit, receive and retain required originator and beneficiary information where local law applies, how it handles counterparties that cannot exchange the required data, and how exceptions are escalated. The existence of a technology vendor does not prove the obligation is implemented correctly.

Sanctions controls should cover customer and transaction screening, but virtual asset activity requires additional thought about wallet addresses, geolocation, IP and device information, counterparties and blockchain intelligence where available and legally usable. OFAC's virtual-currency guidance illustrates why screening only direct customer names can be insufficient when the provider possesses other information that indicates sanctioned-jurisdiction or sanctioned-party exposure. The exact legal outcome depends on the applicable sanctions regime, but the design principle is broader: relevant risk data should not be ignored merely because it lives outside the traditional name-screening system.

Building a VASP risk rating that explains itself

A VASP risk rating should not be a single “crypto = high” flag. It should explain the drivers and support consistent decision-making. Core dimensions usually include regulatory status, jurisdictional footprint, ownership and governance, products and services, customer types, delivery channels, asset and blockchain exposure, use of self-hosted wallets or privacy-enhancing features, transaction volumes, sanctions exposure, AML/CFT control maturity, Travel Rule capability, adverse information and enforcement history.

The weighting should reflect the bank's own services. If the bank only provides an operating expense account, customer-funds and blockchain factors may have lower relevance than in a high-volume settlement relationship. If the bank provides API collections and payouts that touch end-user money, underlying customer profile, transfer patterns and reconciliation become central. A risk-rating model that ignores the product supplied by the bank can produce a precise-looking but operationally meaningless result.

Risk scoring should distinguish inherent risk from control effectiveness and residual risk. An offshore, high-volume exchange may have high inherent risk because of its customer reach and transaction profile. Strong licensing, governance, CDD, transaction monitoring, sanctions controls and transparent audit evidence may reduce residual risk but do not erase the inherent exposure. Conversely, a smaller domestic provider may still be unacceptable if ownership is opaque, registration is doubtful or control testing reveals material gaps.

Override governance is essential. A model can produce a score, but unusual facts may justify escalation or a different decision. Overrides should require reason codes, evidence and an authorised approver. Repeated overrides in the same direction can reveal a model-calibration problem and should feed back into model governance.

Data and systems: connect fiat and virtual-asset evidence

Traditional transaction-monitoring systems see bank-account activity. Blockchain analytics sees on-chain activity. KYC systems hold customer and ownership data. Regulatory registers show licensing status. Screening engines cover sanctions, PEPs and adverse media. Case systems hold investigations. If those systems are not joined, each team may see only one fragment of the relationship.

A minimum VASP data model should include the legal entity and group identifiers; regulator and permission data; beneficial ownership and controllers; product and service inventory; customer and geography profile; approved bank products; expected fiat volumes and corridors; known wallet infrastructure or wallet categories where appropriate; blockchain analytics provider and policy; Travel Rule arrangements; sanctions-control information; risk rating and drivers; approval conditions; review dates; and open remediation actions.

Account data should distinguish customer-money or settlement accounts from operating accounts where the legal and operational model requires that distinction. Expected activity should include not only monthly volume but also transaction count, average and peak size, currencies, major corridors, counterparties and seasonality. A VASP can generate legitimate high-velocity activity, so generic velocity scenarios designed for ordinary corporates can create overwhelming false positives. Monitoring must be calibrated to the business model.

Entity resolution is particularly important. The same VASP group may use several legal entities and account names. Payments may come from payment processors, safeguarding institutions, market makers or treasury entities. Without group-level linkage, monitoring may miss concentration or circular movement across accounts that appear unrelated. At the same time, group aggregation must not collapse legally distinct entities in a way that obscures sanctions or licensing differences.

The bank should also retain evidence of changes. A VASP can add a new service, acquire another exchange, enter a new country, change ownership, launch a stablecoin product or alter its wallet architecture faster than a normal annual KYC cycle. Event-driven triggers should therefore include regulatory status changes, material adverse media, new products, significant geography changes, unusual volume growth, enforcement actions, ownership changes, sanctions events, major cyber incidents and material changes in the provider's own control environment.

The control architecture should join customer and licence data, bank payment flows, blockchain intelligence, screening, monitoring, cases and governance into one evidence chain.

Monitoring the relationship after onboarding

Ongoing monitoring starts by testing whether reality matches the approved business model. If the VASP was approved for domestic retail customers but its bank account begins receiving large transfers from overseas financial intermediaries, that is not automatically suspicious, but it is a profile deviation that needs explanation. If an operating account begins behaving like a customer-settlement account, the risk assessment and product permissions may no longer be valid.

Useful monitoring themes include rapid growth inconsistent with the business plan; material changes in countries or currencies; large flows to or from other VASPs without a clear purpose; transfers involving high-risk payment intermediaries; unexplained concentration in a small number of counterparties; movement between related entities without documented treasury rationale; repeated rejected or returned payments; abnormal cash or cash-equivalent exposure; and activity inconsistent with restrictions agreed at onboarding.

Where the bank has access to blockchain-related information, monitoring can also consider exposure to sanctioned addresses, ransomware, fraud infrastructure, darknet markets, mixers or other higher-risk services. Those labels should be treated carefully. Attribution can change and proximity alone does not establish criminal conduct. Direct exposure, indirect exposure, transaction direction, timing, asset type, counterparty context and the quality of the attribution all matter.

A good monitoring framework separates detection from decision. A rule or model identifies something that deserves review. The analyst then examines KYC data, bank payments, relevant on-chain intelligence, counterparty information, customer explanations and previous cases. The case outcome might be closed as expected activity, escalated for enhanced due diligence, converted to a suspicious activity investigation, referred for sanctions review, subjected to account restrictions, or sent to relationship governance. Different outcomes have different legal and customer consequences.

Banks should avoid using blockchain analytics as an automated de-risking switch. A vendor score can be a useful signal, but the bank remains responsible for understanding how the score was produced and whether it is appropriate for the decision. Thresholds should be tested against known cases and false-positive populations. Changes in vendor typologies or attribution logic should be controlled because they can alter alert volumes without any change in customer behaviour.

From alert to investigation and reporting

When an alert involves a VASP, the investigator often needs to reconstruct both fiat and virtual-asset context. The starting point is the bank transaction: who paid, who received, through which account, in what currency, at what time and for what apparent purpose. The second layer is relationship context: which VASP entity is involved, what service the account is approved for and whether the flow matches the expected customer or treasury model. The third layer is virtual-asset evidence where available: related wallet addresses, asset type, transaction hashes, counterparty VASP or service category, and analytics attribution.

Evidence should be timestamped because on-chain attributions, sanctions designations and customer information can change. An investigator should be able to show what information was available at the time of the decision, not only what the system displays months later. If a blockchain vendor changes an address label, the case should preserve the original label, version or evidence snapshot used in the decision.

Suspicious activity reporting remains jurisdiction-specific. A bank should not assume that every VASP-related alert requires a report, nor that the VASP has already reported the same activity. The bank applies its own legal obligation based on the facts it knows and the applicable reporting threshold. Information-sharing with the VASP must also respect tipping-off restrictions, privacy, bank secrecy and other legal constraints.

Sanctions cases require separate legal treatment. A suspicious transaction can often be investigated after execution depending on local law and control design; a sanctions prohibition may require action before or at execution. The workflow should therefore route possible sanctions matches or prohibited jurisdictional exposure to the appropriate sanctions decision process without forcing them through a normal AML queue.

Governance and decision rights

The VASP relationship should have a named business owner and a named financial-crime owner. Higher-risk relationships often need senior approval and periodic review by a governance forum. The forum should see the risk drivers, material incidents, control testing, alert trends, outstanding remediation, product changes, customer-impact issues and any breach of onboarding conditions.

Risk appetite needs to be specific enough to operate. Statements such as “we have low appetite for crypto” are difficult to implement. More useful boundaries might address unlicensed activity, opaque ownership, prohibited jurisdictions, unmitigated sanctions exposure, providers unable to demonstrate effective customer identification, unsupported privacy-enhancing products, unacceptable regulatory history or inability to provide required information. The exact boundaries are bank-specific and should be approved through governance.

Exit decisions require the same discipline as onboarding. A bank may restrict services, pause new flows, require remediation, reduce limits or terminate the relationship depending on the seriousness of the issue and local law. Immediate exit can create customer, liquidity and operational consequences, particularly where the VASP holds customer money. Legal, operations, treasury and communications teams may need to coordinate the execution. De-risking should not become a substitute for case-by-case risk management where proportionate controls can address the exposure.

Customer and operational impact

Poorly designed controls affect legitimate users behind the VASP. A bank that freezes or rejects the VASP's settlement activity without a clear legal or risk basis can prevent ordinary customers from receiving withdrawals, disrupt merchants and create liquidity pressure. On the other hand, controls that allow unexplained activity to continue can expose customers to scams, theft or failed providers. The objective is neither frictionless processing nor maximal intervention; it is controlled, explainable decision-making.

Service-level design matters because virtual-asset markets operate continuously while many bank investigations and governance functions do not. A provider may send withdrawal or settlement files overnight or on weekends. If the bank's control model requires manual review, it should define cut-offs, escalation routes, out-of-hours ownership and customer communication. Otherwise the control may be sound on paper but operationally impossible.

BA, architecture and testing considerations

Business analysts should translate the policy into observable requirements. “Perform enhanced due diligence on VASPs” is not buildable. A stronger requirement specifies the data fields, source, validation, trigger, workflow state, decision owner, approval rule, evidence retention, review frequency and exception handling. The requirement should also state what happens when a regulator lookup fails, blockchain analytics is unavailable, a required field is missing or the VASP introduces a new product.

Architects should define system boundaries and lineage. They need to know where regulatory status is stored, how group entities are linked, which accounts are tagged as VASP-related, how expected activity enters monitoring, how blockchain alerts are associated with fiat transactions, and how cases preserve point-in-time evidence. Access control is important because some data may contain sensitive investigative or customer information.

Testing should cover more than the happy path. Positive tests should prove that relevant high-risk facts create the expected escalation. Negative tests should prove that legitimate high-volume activity can clear without unnecessary manual intervention. Boundary tests should cover threshold edges, multiple VASP entities, changed licences, conflicting jurisdiction data and ambiguous wallet attribution. Failure tests should cover unavailable screening, stale register data, delayed blockchain feeds and duplicate or replayed events. Regression testing should confirm that tuning one scenario does not silently remove coverage elsewhere.

A release should not be considered complete merely because the screen displays a VASP risk score. The team should reconcile source records to the risk engine, risk engine to workflow, workflow to case outcomes and case outcomes to management information. A controlled sample should be reconstructable end to end.

Mini case study: a global exchange seeks settlement banking

Consider a fictional exchange, NorthBridge Digital Markets, incorporated in Jurisdiction A with operating subsidiaries in three countries. It seeks two bank accounts: an operating account for payroll and vendors and a settlement account for customer fiat deposits and withdrawals. The relationship manager presents the business as “fully regulated” and points to one licence held by the parent company.

The bank's legal-entity mapping shows that the entity holding the licence does not contract with customers in all three markets. One subsidiary relies on a local registration; another serves customers under a transitional arrangement that expires within six months. The ownership structure is transparent and the senior management team has relevant experience, but the group recently acquired a smaller exchange with a different transaction-monitoring system.

Financial-crime due diligence identifies several strengths. Customer identity verification is automated with manual escalation, sanctions screening covers customers and relevant wallet addresses, blockchain analytics is integrated into withdrawal monitoring, and the provider has a formal Travel Rule process. However, the acquired exchange has not yet migrated to the same customer-risk methodology, and historic cases from that platform cannot be searched from the new central case tool.

The bank does not reduce the decision to “approve” or “decline.” It approves the operating account immediately because it is not used for customer settlement. The settlement account is approved with conditions: the acquired customer population must be migrated within a defined period; historic cases must remain searchable and linked; the bank will receive monthly management information on migration exceptions; certain higher-risk corridors are restricted until controls are harmonised; and a trigger event requires review if the transitional regulatory arrangement is not replaced before expiry.

Three months later, monitoring shows rapid growth in payments from one country and a new group of counterparties that were not included in the expected profile. The relationship team explains that a marketing campaign drove growth, but one counterparty is an offshore VASP that the exchange began using for liquidity. The bank asks for evidence of the exchange's due diligence on that counterparty, assesses the offshore provider's regulatory status and transaction purpose, and checks whether the new flow changes the original risk rating. The result is an enhanced-review action, not an automatic suspicious-activity report. A separate alert involving a wallet directly attributed to a sanctioned person is routed immediately to sanctions specialists because the legal question and execution timing are different.

The case illustrates the real control objective. The bank is not trying to certify that NorthBridge is a “safe crypto company.” It is maintaining an evidence-based view of the exact services, entities, customers, counterparties and controls that create its exposure, and it is able to change the relationship when the facts change.

The evidence timeline should preserve what the bank knew at onboarding, what changed later, which controls fired and why the final decision was made.

Common failure modes

The first failure is relying on registration alone. Registration may establish that a firm is within a local regime, but it does not prove the effectiveness of its controls or the legality of every cross-border activity. The second is treating the whole group as one regulated entity when permissions actually belong to specific legal entities.

The third is collecting a policy pack without testing how the controls work. A sophisticated AML manual can coexist with weak customer verification, unmanaged alert backlogs or poor sanctions data. The fourth is using a generic corporate transaction-monitoring model for a high-volume settlement account and then accepting massive false-positive volumes as unavoidable.

The fifth is allowing blockchain analytics to become a black box. Analysts need to understand what direct and indirect exposure means, how attribution confidence works and when to challenge the vendor. The sixth is failing to connect fiat activity with on-chain context when the information is available. The seventh is ignoring product change: a provider approved for spot exchange may later add staking, lending, privacy-enhancing assets or DeFi access without triggering a review.

The eighth is weak evidence retention. If the bank cannot show which licence status, ownership data, sanctions lists, wallet labels and risk rules were used at the time, it cannot reliably defend the decision. The ninth is poor exit planning. Cutting off a settlement relationship without understanding customer-money, liquidity and operational dependencies can create avoidable harm.

What good looks like

A strong VASP relationship is not one with zero risk. It is one where the bank can explain the risk, evidence the legal and supervisory perimeter, understand the customer's products and underlying activity, see relevant changes, investigate anomalies, enforce conditions and make decisions through clear governance. The control is strongest when regulatory data, KYC, payment monitoring, blockchain intelligence, sanctions screening and case management tell the same story rather than existing as separate islands.

Clear decision rights keep business sponsorship, financial-crime challenge, legal interpretation, operations execution and senior risk acceptance distinct but connected.

Operational deep dive: proving the VASP relationship rather than trusting the label

The base chapter explains the control architecture. This deep dive focuses on the hardest part of onboarding: converting a VASP's public story, regulatory registrations and policy documents into evidence that the bank can rely on.

A provider can have a familiar brand and still operate through several legal entities. The website may show one global name while customer terms identify different contracting entities by country. Custody may sit in another subsidiary. Treasury may be centralised. A regulated entity may outsource technology or customer support to an affiliate. The bank therefore starts with an entity-service-permission map: which legal entity provides which service, to which customer population, under which licence or registration, using which bank account and wallet infrastructure.

This map solves several recurring problems. It prevents the bank from applying one entity's permission to the whole group. It exposes situations where customer activity is booked in an entity with weaker oversight. It helps sanctions teams identify which jurisdictional regimes may apply. It also allows transaction monitoring to compare the actual account behaviour with the approved service model.

Independent regulatory verification

A licence or registration should be verified independently using the regulator's own register or another approved primary source. The check should capture the exact legal name, reference number, status, permission or activity scope where available, effective date, restrictions and any public enforcement information. If the register is ambiguous, the uncertainty should be recorded and resolved rather than silently converted into a positive status.

Registration can mean different things in different places. The FCA expressly warns that UK registration under the Money Laundering Regulations is a legal requirement and not an endorsement. EU CASPs operate within a MiCA and AML/CFT framework that is different from the UK perimeter. Australia's reformed 2026 regime uses VASP terminology but has its own registration and supervisory requirements. A global bank's due-diligence screen should therefore store a jurisdiction-specific permission_type and permission_scope, not a simplistic Boolean field called regulated.

The bank should also determine whether the provider serves customers in jurisdictions where it has no direct local permission. This is not automatically unlawful because cross-border rules differ, but it is a material question. The VASP should explain the legal basis for major markets, including passporting, reverse solicitation where relevant, exemptions or transitional arrangements. The bank's legal or compliance function should decide whether that explanation is sufficient for the relationship. Relationship managers should not make jurisdictional conclusions from marketing statements.

Control effectiveness evidence

The VASP's AML/CFT framework should be assessed against its actual risk. A provider serving millions of retail customers across multiple regions should have governance, staffing, systems and escalation capacity consistent with that scale. A two-person compliance function may be appropriate for a small start-up with limited activity but not for a global settlement platform. The assessment should look at alert volumes, backlog, escalation rates, quality assurance, independent testing, regulatory findings and remediation—not merely the policy's page count.

CDD testing should ask whether the provider can demonstrate that identity controls work. For retail customers, this may include identity evidence, liveness or impersonation controls, sanctions and PEP screening, device or fraud signals and enhanced due diligence triggers. For legal entities it may include incorporation data, beneficial ownership, controllers, business purpose and source-of-funds information. The bank does not need to repeat the provider's KYC for every underlying user, but it needs confidence that the provider's framework is capable of managing its own obligations and the risks relevant to the bank relationship.

Transaction monitoring should be assessed across both fiat and virtual-asset activity. A mature provider can usually explain how it detects unusual account behaviour, rapid movement, fraud proceeds, high-risk counterparties, sanctioned exposure and suspicious wallet activity. The bank should understand how alerts are prioritised, whether blockchain analytics is used, how rules and models are tuned, what false-positive levels look like, and how analysts document closure or escalation.

Sanctions controls should be tested beyond name screening. Depending on the business model and applicable law, relevant information may include wallet addresses, IP or geolocation data, payment counterparties and blockchain attributions. The provider should be able to explain how sanctions-list updates reach its systems, how potential matches stop or hold activity where required, and how legal decisions are made when ownership or jurisdiction is complex.

Offshore and nested exposure

The most difficult relationships are often not the direct customer but the customer's counterparties. A VASP may send or receive liquidity from other exchanges, OTC desks or brokers. Some may be established offshore or operate outside effective supervision. FATF's March and July 2026 work makes clear that offshore VASP risk remains an important implementation challenge.

The bank should therefore understand how its VASP customer conducts due diligence on other VASPs. Relevant questions include whether counterparties are identified, whether regulatory status is checked, whether high-risk jurisdictions or services are restricted, whether Travel Rule data can be exchanged where required, and whether blockchain analytics informs counterparty assessment. This is analogous to nested risk in correspondent banking: the bank does not need a direct customer relationship with every downstream provider, but it should understand material nested exposure well enough to decide whether its customer can manage it.

Evidence grading

A practical due-diligence file should distinguish three categories. Verified facts are supported by independent or reliable evidence, such as a regulator register or corporate registry. Customer representations come from the VASP and may be reasonable but are not independently verified. Open assumptions or gaps identify what is still unknown. This distinction prevents a common audit problem where a customer statement gradually becomes treated as a verified fact as it is copied between systems.

Material gaps need owners and deadlines. A missing independent audit report may be acceptable before onboarding if other evidence is strong and the relationship is restricted. A missing licence for the entity receiving customer funds is different and may prevent onboarding entirely. The decision should explain why the gap is tolerable, who accepted it and what happens if remediation is not completed.

What the analyst should be able to reconstruct

Six months after onboarding, an independent reviewer should be able to answer: which VASP entity did the bank onboard; what services did it provide; what regulatory status was verified; which products and customer populations drove the risk rating; what material control weaknesses were found; what conditions were imposed; and whether the actual transaction behaviour remained within the approved model.

If those answers depend on personal email, an undocumented spreadsheet or the memory of a relationship manager, the control is not mature even if the original onboarding decision was sensible.

Advanced practice: monitoring, data lineage and change control

A VASP relationship changes quickly. The bank therefore needs a monitoring design that detects not only suspicious transactions but also changes in the customer's operating model that invalidate the original risk assessment.

Separate transaction risk from relationship risk

Transaction monitoring asks whether particular activity is unusual or suspicious. Relationship monitoring asks whether the customer still looks like the business the bank agreed to serve. Both are necessary.

A single payment from a customer of a crypto exchange may be perfectly normal. A sudden doubling of settlement volume, a new corridor, a new class of counterparties or the appearance of a second VASP entity may indicate a change in relationship risk even when no individual transaction is suspicious. The bank should therefore maintain profile metrics that can be compared over time: transaction count, value, currencies, origin and destination countries, major counterparties, proportion of inter-VASP flows, return and rejection rates, and concentration.

Trigger events should be explicit. Examples include licence suspension or restriction, regulator enforcement, ownership change, merger or acquisition, launch of new services, addition of higher-risk assets, material geography expansion, major cyber incident, significant fraud event, sustained monitoring backlog, change of blockchain analytics provider, and material deterioration in sanctions or AML testing.

Join the evidence through identifiers

The architecture should use stable identifiers. The direct VASP customer should have a customer ID and legal-entity identifier where available. Each bank account should be linked to the legal entity and approved purpose. Group relationships should be explicit. Regulatory records should identify the entity to which each permission applies. Cases should reference the relevant customer, account, transaction and, where used, blockchain evidence.

Where the VASP provides wallet identifiers or the bank uses blockchain analytics, wallet data should not be stored as free text in analyst notes. Structured fields should record the chain, address, asset where needed, attribution source, attribution date and confidence or category. This enables later re-evaluation if a vendor changes an attribution.

The same principle applies to external register data. A nightly or periodic API feed may not be available for every regulator, so some checks remain manual. Whatever the method, the bank should retain the source, lookup date and result. A current register status should not overwrite the historical status needed to explain a previous decision.

Monitoring scenarios that fit a VASP

Generic corporate scenarios often perform badly on VASP settlement accounts. A high transaction count, rapid in-and-out movement and repeated round-number transfers can be normal for an exchange. The scenario therefore needs context.

A useful approach combines business profile and counterparty information. For example, rapid pass-through activity becomes more meaningful when it is concentrated in new counterparties or unapproved jurisdictions. Inter-VASP settlement becomes more meaningful when the counterparty is not present in the approved counterparty set or has weak regulatory status. A sudden spike in retail inbound deposits becomes more meaningful when paired with fraud complaints, payment recalls or unusual beneficiary changes.

The bank should also detect attempts to route around restrictions. If a VASP is prohibited from using the account for customers in a particular jurisdiction, the control should not rely only on country fields supplied by the VASP. Payment originator information, bank identifiers, IP or device information held by the bank, intermediary banks and counterparty patterns may provide additional evidence, subject to law and data availability.

Blockchain intelligence without false certainty

Blockchain analytics can improve visibility, but it is not a truth oracle. Different vendors may classify the same address differently. Clustering can infer common control but can be wrong. Exposure scores depend on methodology, number of hops and weighting. New addresses appear faster than intelligence can be labelled.

A bank should therefore define how analytics is used. Direct exposure to a sanctioned address may require a very different response from three-hop exposure to a high-risk service. A high-risk attribution with low confidence may require investigation rather than automatic rejection. An analyst should be able to see the transaction hash, address, chain, attribution source, exposure type, time of attribution and any subsequent changes.

Vendor changes must be treated as model or rule changes where they materially affect outcomes. If a provider changes the definition of “mixer exposure,” alert volumes can move overnight without any change in customer behaviour. The bank should test material vendor updates before production where practicable, monitor post-change alert volumes and retain version history.

Case orchestration

A VASP alert may need several specialist queues. A payment anomaly may stay within AML investigation. A sanctions address match may route to sanctions operations. A customer-control failure may route to relationship risk and KYC remediation. A fraud complaint pattern may involve fraud operations. A prudential or credit concern may need treasury or credit risk. The case platform should support linked cases rather than forcing all issues into a single status.

Decision reason codes should distinguish outcomes such as expected activity, profile update required, enhanced review, suspicious activity escalation, sanctions escalation, fraud referral, account restriction, relationship-condition breach and exit review. This allows management information to reveal whether the control is detecting crime, poor customer controls or simple profile drift.

Resilience and failure modes

Virtual-asset markets operate continuously, but vendor services fail. The bank should define what happens when blockchain analytics, regulator-register access, sanctions screening or customer-profile services are unavailable. Some flows may be safely queued; others may use a controlled degraded mode; some may need to stop. The choice depends on the bank's legal obligations, product design and risk appetite.

Failure testing should include stale data, delayed feeds, duplicate events, partial outages and conflicting sources. The worst time to invent a fallback is during a high-volume weekend incident when the VASP is waiting for settlement.

Metrics that reveal control health

Useful VASP management information includes not only alert volume but also profile deviations, onboarding conditions past due, licence-status changes, material counterparties added, sanction and fraud referrals, investigation ageing, blockchain vendor coverage, unresolved data-quality issues and customer-impact events. Quality assurance should sample both escalated and closed cases.

A low alert rate can mean good customers or weak detection. A high closure rate can mean efficient investigation or overly broad rules. The governance forum should therefore look at outcomes and evidence quality, not only productivity.

Practice close: delivery checklist, acceptance criteria and testing

This section converts the chapter into delivery artefacts that a bank can use when designing or reviewing a VASP relationship.

Minimum onboarding evidence

Before the relationship is approved, the case should identify the contracting legal entity, group structure, beneficial owners and controllers; describe the actual products and services; independently verify applicable regulatory status; record principal customer and operating geographies; describe the customer base; identify the bank products requested; document expected fiat transaction behaviour; assess CDD, sanctions, transaction-monitoring and blockchain-control maturity; understand Travel Rule capability where relevant; and record material counterparties, outsourcing arrangements and open remediation.

The evidence should distinguish verified facts from customer representations. Material gaps should have an owner, due date and decision about whether onboarding can proceed before closure.

Example acceptance criteria for a VASP onboarding workflow

Regulatory status. When a VASP is onboarded, the workflow must capture regulator, jurisdiction, permission or registration type, reference, legal entity, verification source, verification date and status. If the status is expired, suspended, restricted or cannot be independently verified, the workflow must route to a designated compliance decision before activation.

Entity mapping. Every VASP bank account must link to the exact legal entity that owns the account and to its approved account purpose. Group relationships may be displayed, but they must not replace the legal-entity record.

Product scope. The workflow must capture the VASP services relevant to the bank's risk assessment, such as exchange, custody, transfer, staking, lending, institutional brokerage, merchant or card services. Addition of a configured material service after onboarding must create an event-driven review.

Expected activity. Monitoring must receive an approved profile containing expected currencies, countries, transaction volumes, transaction counts and material counterparty categories. Profile updates require version history and effective dates.

Conditions and restrictions. Any onboarding condition must have a machine-readable owner, deadline and status. Overdue high-severity conditions must appear in governance MI and, where policy requires, trigger restriction or reapproval.

Audit trail. The bank must be able to reconstruct who entered, reviewed and approved the risk assessment, which evidence was used and which policy or rule version applied.

Positive and negative testing

Positive testing should include a suspended regulatory registration, a new higher-risk country, a material unapproved VASP counterparty, direct exposure to a sanctioned address where the relevant legal regime applies, unexplained account-purpose change, and overdue high-severity remediation. Each test should prove the correct workflow routing and evidence capture, not merely that an alert appears.

Negative testing should include legitimate high-velocity settlement, expected transfers to approved liquidity providers, normal customer-withdrawal peaks and a verified licence renewal. The objective is to prove that the control can distinguish expected activity from risk signals and does not create unnecessary manual work.

Boundary testing should cover a counterparty exactly at a risk-score threshold, multiple legal entities with similar names, a licence whose permission covers one service but not another, a provider moving from transitional status to full authorisation, and blockchain attribution that changes after the original transaction.

Failure testing should cover unavailable regulatory registers, delayed blockchain feeds, sanctions-screening outage, stale customer-profile data and duplicate monitoring events. The test should verify the approved fallback rather than assume the service will always be available.

Investigation quality questions

A reviewer sampling VASP cases should ask whether the analyst understood which legal entity and account were involved; whether transaction context was compared with the approved profile; whether blockchain information was interpreted with appropriate uncertainty; whether sanctions and AML questions were separated; whether customer explanations were corroborated where necessary; and whether the final decision was supported by evidence.

Closure text such as “crypto activity expected” is not sufficient. A useful closure explains why the observed pattern fits the approved VASP model and identifies the evidence used. Escalation text should state the unresolved concern rather than repeat the alert description.

Governance questions

Senior governance should be able to answer which VASP relationships are highest residual risk; which have overdue onboarding conditions; which have experienced regulatory or enforcement changes; which have material new products or geographies; where transaction-monitoring backlogs or blockchain-data gaps exist; and what customer or operational impact current restrictions are creating.

The forum should also know whether the bank's VASP portfolio is concentrated in one provider, one jurisdiction, one payment corridor or one blockchain analytics vendor. Concentration can create resilience and risk-management issues even when individual relationships are acceptable.

Final learner check

A strong answer to “should we bank this VASP?” should never be only yes or no. It should explain the entity and service perimeter, applicable regulatory status, inherent risk, control effectiveness, residual risk, bank products requested, monitoring design, conditions, decision owner and review triggers.

If the evidence cannot support that explanation, the relationship is not ready for approval no matter how well-known the brand is.

Masterclass case: when a regulated VASP stops looking like the customer the bank approved

This fictional case is designed to show how regulatory status, fiat flows, blockchain evidence and governance interact. The names and figures are illustrative.

Onboarding

MeridianX Europe is a crypto-asset service provider serving retail and institutional customers. It is part of a larger global group. The bank onboards the European legal entity for EUR collections and withdrawals. Independent checks confirm its applicable EU authorisation status. Ownership is transparent, senior management has been screened, and the VASP provides evidence of customer due diligence, transaction monitoring, sanctions controls, Travel Rule capability and blockchain analytics.

The bank rates the relationship high inherent risk because the provider moves customer money at scale, operates across borders and interacts with other VASPs. Control effectiveness is assessed as strong enough for the relationship. Residual risk is accepted with conditions: settlement must remain within approved EEA corridors, material new VASP counterparties require notification, the provider must report significant control incidents, and a major product launch triggers a relationship review.

The account is tagged as a VASP customer-settlement account. Expected activity includes high transaction counts, rapid customer withdrawals and transfers to a documented set of liquidity providers. The bank tunes transaction monitoring accordingly so normal exchange velocity does not flood the alert queue.

The change

Six months later, the monitoring team detects three changes. First, monthly settlement value has risen sharply. Second, a new non-EEA payment institution has become one of the largest counterparties. Third, a growing share of outbound payments is associated with a group entity that was not part of the original account map.

None of these facts is individually suspicious. Marketing growth can explain volume. A new payment institution can support legitimate expansion. Group treasury structures change. But together they indicate that the approved relationship profile may be stale.

The relationship manager contacts MeridianX. The VASP explains that it launched services in two additional markets and acquired a smaller offshore exchange. The new payment institution collects funds for customers of the acquired business. The acquired exchange remains on a separate KYC and blockchain-monitoring stack while integration is underway.

The investigation

The bank opens a relationship-risk case rather than a suspicious transaction case. Compliance asks for the legal-entity and regulatory mapping for the new markets, the contractual role of the payment institution, the acquired exchange's AML/CFT control assessment, customer and geography metrics, and the integration plan.

At the same time, several AML alerts show rapid inbound funds from fraud-victim banks followed by transfers to the VASP settlement account. Blockchain analytics links some related withdrawals from the acquired platform to scam-associated addresses. The direct bank evidence does not prove that MeridianX knew of the fraud, but it indicates potential mule and scam exposure in the acquired customer base.

The bank separates three questions.

The first is legal and regulatory: is the entity using the bank account permitted to provide the relevant services to the new customer population? Legal and compliance validate the applicable perimeter rather than relying on the group's existing EU authorisation.

The second is control effectiveness: did the acquired business have adequate KYC, fraud and AML monitoring before integration, and can MeridianX demonstrate how alerts are being managed now?

The third is suspicious activity: do the specific fiat and virtual-asset transactions create suspicion under the bank's reporting obligations? Investigators assess the payment patterns and available blockchain evidence on their own merits.

The decision

The bank does not immediately exit the entire group. It restricts flows connected with the acquired offshore exchange while the control assessment is completed. It permits existing EEA settlement activity to continue because that part of the relationship still matches the approved model and no separate legal prohibition has been identified.

MeridianX is required to provide a remediation plan covering customer re-risking, integration of the acquired alert backlog, sanctions and wallet screening, governance of the payment institution, and migration to the group's monitoring stack. The bank sets milestones and senior escalation if dates are missed.

Several specific transaction cases are escalated for suspicious-activity consideration based on the bank's own evidence. A wallet match that may involve a sanctioned address is handled through a separate sanctions process because the applicable legal action and timing differ from AML reporting.

Why this case matters

The bank's strongest control was not a crypto-specific rule. It was the ability to detect that the relationship had changed and to connect profile drift with transaction evidence. If the bank had relied only on MeridianX's original authorisation, it would have missed the acquired offshore activity. If it had relied only on blockchain scores, it might have overreacted to ambiguous exposure without understanding the legal entities and customer flows.

The case also shows why “regulated VASP” and “unregulated VASP” are not sufficient risk categories. MeridianX remained regulated, but part of its operating model moved outside what the bank had approved. Conversely, the presence of an offshore entity did not automatically prove wrongdoing. The bank needed evidence, legal interpretation, control testing and proportionate restrictions.

For a business analyst, the key requirement is event-driven review: material acquisition, geography expansion and new settlement counterparties must create a workflow trigger. For an architect, the key is group and account linkage so new entities are visible. For testers, the key scenario is a legitimate-looking volume increase combined with a new counterparty and changed entity mapping. For governance, the key decision is whether residual risk can be controlled while remediation occurs.

References and further reading

These are the public, authoritative sources used for this chapter. Jurisdiction-specific sources are identified as such and should not be treated as universal law.