A regulated digital-asset business that gets its KYC and onboarding framework (the documented suite of customer identification, verification and risk-rating controls required under applicable anti-money laundering law) wrong does not simply face a fine. It risks having banking rails suspended, regulatory authorisation withdrawn and, in serious cases, criminal liability for senior management. With AML supervisors across the EU, the Gulf and Asia-Pacific intensifying reviews of crypto businesses, the window for gap-remediation is narrowing fast. This page sets out the legal basis, the architecture, the common failure points and the cross-border considerations that every regulated entity must address.
What is the regulated basis for a KYC onboarding framework?
Every VASP (virtual asset service provider) and CASP (crypto-asset service provider) operating under a supervised regime is required to maintain a documented customer due diligence program as a condition of authorisation. The obligation is not optional and is not satisfied by a terms-of-service click-through. Under MiCA and the ESMA joint guidelines that accompany it, a CASP must apply customer due diligence proportionate to the risk profile of the customer and the service. Under the FATF Recommendations – in particular Recommendation 10 on customer due diligence and Recommendation 15 on virtual assets – the same logic applies to every VASP in a FATF-member jurisdiction, regardless of whether local law has been updated. The VARA regime in Dubai, the FSRA framework in Abu Dhabi, the Payment Services Act supervised by MAS in Singapore, the VASP regime overseen by the SFC in Hong Kong, and the FCA's Money Laundering Regulations registration in the United Kingdom all reproduce the same structural expectation: know your customer before you onboard them, and document that you did.
The practical consequence is that a KYC framework is simultaneously a licensing condition, an ongoing supervisory expectation and a civil liability management tool. Regulators in the leading hubs increasingly expect to inspect the framework on day one of a thematic review. If the documentation does not exist, or exists only in template form without evidence of execution, the regulated status of the entity is immediately at risk.
In our practice, we have seen businesses authorised under one regime assume that their existing documentation satisfies a second regulator when they expand geographically. That assumption is routinely wrong. Each regime has nuances – in the identity-verification methods it accepts, in the source-of-funds thresholds it applies and in the enhanced due diligence triggers it mandates.
The cross-border reality begins at the onboarding screen. A CASP passporting under MiCA into a new EU member state carries its authorisation but must still comply with local AML implementation. A firm licensed by VARA in Dubai serving institutional clients domiciled in Singapore is simultaneously inside MAS's AML perimeter for those clients. The framework must be designed for this reality from the outset.
For a scoped assessment of your current KYC documentation against the regimes that govern your user base, contact OBOLUS at info@oboluslaw.com. The process above describes the standard expectation. Your entity structure, your user base and the jurisdictions your banking lives in will each shift the analysis. Map your options.
What are the core components of a compliant KYC onboarding framework?
A compliant KYC onboarding framework has six structural layers, each of which must be documented, tested and updated on a defined schedule. Absence of any one layer is treated by AML supervisors as a systemic deficiency rather than a minor gap.
The first layer is the customer identification program (CIP): the rules that determine what identity evidence the firm will collect at the moment of account opening. For natural persons this means government-issued identity documents, proof of address and – for higher-risk profiles – source-of-wealth evidence. For legal entities it means beneficial ownership mapping down to the natural-person level, corporate registry verification and, where relevant, regulatory status checks. The standard required varies by jurisdiction: the FCA regime, MiCA/ESMA guidance and VARA each specify the minimum identity-data set differently, and a framework that passes one audit may fail another.
The second layer is risk classification. Every customer must be assigned a risk tier – typically low, medium and high – based on factors including geography, business type, transaction profile and politically exposed person status. The risk tier drives the depth of due diligence applied and the frequency of periodic review. Regulators expect to see a documented risk matrix, not a binary pass/fail gate.
The third layer is enhanced due diligence (EDD): the additional steps applied to high-risk customers, PEPs, customers from high-risk jurisdictions identified on the FATF grey or black lists, and customers whose transaction patterns generate alerts. EDD typically requires senior management sign-off on onboarding, source-of-funds documentation and more frequent account reviews.
The fourth layer is sanctions screening. Every customer must be screened against relevant sanctions lists – OFAC, the EU consolidated list, the UN list and, depending on the jurisdictions involved, national designations. Screening must happen at onboarding and on an ongoing basis as list updates occur. This is not a one-time checkbox: a customer who was clean at onboarding can appear on a list the following week.
The fifth layer is transaction monitoring (TM): the automated and manual systems that flag suspicious patterns in customer activity after onboarding. For crypto businesses this includes on-chain analytics, counterparty risk scoring and integration with blockchain forensics tools. Transaction monitoring is the layer where VASP supervision most visibly diverges from traditional financial institution expectations – the on-chain data dimension adds a technical requirement that a purely document-based AML team cannot satisfy alone.
The sixth layer is the governance and record-keeping wrapper: the MLRO (money laundering reporting officer) appointment, the suspicious activity reporting pipeline, the staff training log and the independent audit cycle. Without this layer the other five cannot be demonstrated to a regulator.
How does the Travel Rule integrate with the onboarding framework?
The Travel Rule (the obligation, derived from FATF Recommendation 16, to pass originator and beneficiary identifying data with every virtual asset transfer above the applicable threshold) is not a separate program: it is an extension of the KYC framework into the transfer layer. A VASP that has complete onboarding data but no Travel Rule procedure has a structural gap that regulators across MiCA, MAS, the SFC and VARA now consistently cite in supervisory findings.
The Travel Rule obligation runs in both directions. The originating VASP must collect and transmit the required data. The beneficiary VASP must receive, verify and retain it. When the counterparty is an unhosted wallet – a wallet not associated with a regulated intermediary – the VASP must apply the unhosted-wallet policy mandated by its own regime. Under MiCA, for example, the treatment of transfers to and from unhosted wallets is more prescriptive than earlier national VASP guidance was.
In practical terms, Travel Rule compliance requires: (a) a message-format solution compatible with leading protocols (TRISA, OpenVASP, or an established VASP directory); (b) a counterparty verification procedure to confirm that the receiving entity is itself a regulated VASP; and (c) a documented policy for transactions where Travel Rule data cannot be obtained or verified. Regulators treat that third element as the hardest to satisfy and the most frequently absent.
We regularly advise businesses that their Travel Rule gap is discovered not during a regulator's audit but when a correspondent bank requests evidence of Travel Rule compliance as a condition of maintaining the account. At that point the remediation window is measured in days, not months.
What are the most common KYC onboarding failures in practice?
The failures we see most frequently fall into four categories, each with a distinct legal consequence.
The first is template adoption without localisation. A business purchases an AML policy template from a compliance vendor, files it with its regulator and treats the exercise as complete. The template may satisfy the base FATF standard but will not reflect the specific CDD requirements of VARA, the ESMA joint-guidelines obligations under MiCA, or the SFC's particular expectations for VATP operators. When the regulator conducts a thematic review, the gap between the template and the actual regime requirements is immediately apparent. The consequence ranges from a remediation direction to a licence condition restricting new customer onboarding.
The second is the PEP and sanctions gap. Many crypto businesses apply sanctions screening at onboarding but run it against an incomplete list set – typically OFAC only – and do not screen for PEPs at all. For a business with users in multiple jurisdictions, the EU consolidated list, the UN list and relevant bilateral designations are equally relevant. Missing a designation is not a defence; it is evidence of an inadequate program.
The third is the absence of a documented periodic review cycle. Risk classification is not a one-time event. A customer who was low risk at onboarding may become high risk because their transaction volume grew, their jurisdiction of incorporation changed or their wallet counterparties began appearing on adverse-media or sanctions databases. Without a documented trigger-based and calendar-based review cycle, the entity's KYC data becomes stale – and stale KYC is treated as no KYC by supervisors.
The fourth – and by some distance the most consequential – is transaction monitoring that exists on paper but is not calibrated to the entity's actual product and user base. The default alert thresholds in a generic transaction monitoring system are set for retail bank behavior, not for the high-value, high-velocity patterns of a crypto exchange or a DeFi-adjacent custody business. When a suspicious transaction passes through without generating an alert, and is later traced by law enforcement, the regulator's question is not whether the system existed but whether it was fit for purpose.
How does the cross-border dimension change the analysis?
Operating across more than one jurisdiction means operating across more than one AML perimeter, and those perimeters do not always agree. The starting assumption – that a single offshore licence covers global user onboarding – is the most expensive myth in crypto-business compliance.
Consider a business licensed under the BVI FSC's VASP Act that serves institutional clients in the EU. MiCA's CASP authorisation regime applies to services provided to EU-based persons; the BVI licence is irrelevant to that analysis. ESMA and the national competent authority of the member state where those clients are based will assess whether the firm's KYC and AML procedures meet the MiCA standard. If the firm is also banking in a EU-regulated institution, that bank's own AML program will independently assess the firm's KYC documentation as part of its correspondent due diligence.
For a business sitting between the UAE and Singapore, the legal question turns on whether the entity's activity triggers VARA's activity-based licensing requirements and simultaneously falls within the Payment Services Act's DPT service framework supervised by MAS. The KYC framework must satisfy both regulators' expectations simultaneously – not as a matter of choice but as a condition of serving users in both geographies and maintaining banking in both hubs.
The practical approach we map for clients is a jurisdiction-by-jurisdiction gap analysis against the highest applicable standard, followed by a single consolidated framework that meets that standard in every relevant market. A framework built to MiCA's ESMA-guided standard, with VARA and MAS overlays, will in most cases satisfy the requirements of lower-intensity regimes. The reverse – building to the lowest common denominator and then adding – almost always leaves a material gap.
The Travel Rule adds a further cross-border dimension: the threshold at which originator and beneficiary data must be transmitted varies by jurisdiction. A business operating across MiCA, the UK FCA regime and the MAS Payment Services Act must manage three potentially different threshold rules simultaneously and document how the highest obligation is met across all transfers.
If your KYC program was built for one regime but your users or banking now span multiple jurisdictions, a gap has likely opened. To identify it before your regulator or your bank does, write to OBOLUS at info@oboluslaw.com or message us via t.me/oboluslaw. Map your options.
KYC remediation under regulatory pressure: a worked example
In a recent matter, a payments-adjacent crypto business operating under a Gulf-region authorisation received a supervisory letter from its regulator citing inadequate customer due diligence documentation and an absent Travel Rule procedure. The firm had onboarding forms but no risk-classification matrix, no EDD trigger logic and no counterparty-VASP verification protocol. We conducted a rapid gap analysis against the applicable VARA rulebook requirements, restructured the CDD tiers, drafted the Travel Rule policy and counterparty-verification workflow, and engaged allied counsel in the relevant jurisdiction to manage the regulator's remediation dialogue. The firm responded within the regulator's stated timeframe, the enforcement direction was lifted and the business resumed unrestricted onboarding within weeks. The outcome was not guaranteed – it turned on the pace of remediation and the quality of the submission – but the structured response controlled the downside.
Which businesses need the most intensive KYC architecture?
Not every regulated entity requires the same level of KYC infrastructure. The intensity of the required framework tracks three variables: the regulatory regime the entity sits under, the risk profile of its user base and the complexity of the products it offers.
Profile A – Exchange or trading platform with retail and institutional users. This is the highest-intensity profile. The firm must maintain tiered CDD for both retail and professional clients, apply EDD to institutional counterparties with their own compliance programs, run real-time transaction monitoring with on-chain analytics integration and maintain a full Travel Rule messaging solution. Under MiCA, the SFC regime or VARA, this profile will face the most detailed thematic reviews. The KYC framework must be audited by an independent party on a schedule acceptable to the regulator.
Profile B – Custody-only or wallet-infrastructure provider. Custodians hold assets rather than facilitate high-frequency trading, but they still process deposits and withdrawals that trigger Travel Rule obligations, and their clients – often institutional – carry their own beneficial ownership complexity. The framework is less transaction-monitoring intensive but more demanding on the beneficial-ownership and source-of-funds documentation side. Under the FSRA framework in ADGM and under the AFSA digital-asset custody regime in the AIFC, custody-specific requirements apply alongside the base AML obligation.
Profile C – Token issuer or DeFi-adjacent protocol with a regulated front end. The regulated perimeter for this profile is still being defined in most jurisdictions, but where a business operates a regulated interface or issues an asset classified as an ART or EMT under MiCA, the CDD obligation attaches to the issuance and distribution activity. The risk here is underestimating the perimeter: a protocol that assumes it is outside the regulated space because it is "decentralized" may still operate through a legal entity that is itself a regulated entity.
Profile D – Fund or family office with digital-asset exposure. This profile typically falls under the fund's existing AML program rather than a VASP-specific one, but the crypto dimension adds requirements around the verification of counterparty exchanges (are they regulated?), the Travel Rule compliance of the custodian used and the on-chain provenance of assets received. Institutional investors in this profile are increasingly asked by their own LPs or trustees to demonstrate that their crypto-asset holdings were acquired from regulated, KYC-compliant counterparties.
Self-assessment: is your onboarding framework fit for review?
A supervisor or correspondent bank will typically work through the following questions when assessing a crypto firm's KYC program. A "no" or "not documented" answer to any of them is a material gap.
- Is there a written AML/KYC policy that has been approved by senior management in the current calendar year?
- Does the policy reference the specific regulatory regime(s) under which the entity operates?
- Is there a documented risk-classification matrix with defined criteria for low, medium and high risk tiers?
- Is sanctions screening applied at onboarding and updated continuously as list changes occur?
- Is there a documented EDD procedure triggered by defined risk factors, including PEP status and high-risk jurisdiction flags?
- Is there a documented periodic review schedule, with evidence of reviews actually conducted?
- Is there a Travel Rule procedure, including a counterparty-VASP verification step and an unhosted-wallet policy?
- Is transaction monitoring calibrated to the entity's actual product, user base and transaction volume?
- Is there a named, qualified MLRO with a documented reporting line to senior management?
- Is there an independent audit of the AML program on a schedule acceptable to the applicable regulator?
If two or more of these questions cannot be answered affirmatively with reference to current documentation, the framework is not fit for a supervisory review. In our practice, the most common failure mode is not that businesses lack a policy but that the policy exists and the evidence of execution does not.
Related at OBOLUS
- AML and Travel Rule compliance for digital-asset businesses – the full practice overview covering program design, MLRO services and regulatory engagement.
- Sanctions screening for crypto in Brazil – jurisdiction-specific guidance on Brazilian AML and sanctions obligations for VASPs.
- Creditor claims in crypto insolvency in South Africa – how AML documentation affects creditor standing in digital-asset insolvency proceedings.
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule, derived from FATF Recommendation 16, requires a VASP to collect and transmit identifying information about both the originator and the beneficiary with every virtual asset transfer above the jurisdiction's applicable threshold. The originating VASP sends the data; the receiving VASP must verify and retain it. Where the counterparty is an unhosted wallet, the firm must apply its documented unhosted-wallet policy. Failure to maintain a Travel Rule procedure is now a standard supervisory finding across MiCA, the MAS Payment Services Act regime and VARA.
Who must act as MLRO for a crypto firm?
The MLRO (money laundering reporting officer) is the individual within the regulated entity responsible for receiving internal suspicious activity reports, assessing them and filing external reports with the relevant financial intelligence unit. Most major regimes – including the FCA's Money Laundering Regulations framework, the VARA rulebooks and MiCA's accompanying guidelines – require the MLRO to be a named, suitably qualified individual with a direct reporting line to senior management. The role cannot be outsourced to a third-party compliance vendor without specific regulatory permission, and the individual must have sufficient authority and resources to act independently.
How do regulators audit crypto AML programs?
Supervisors typically conduct thematic reviews rather than purely documentary audits. They request the written AML policy, the risk-classification matrix, sample customer files, evidence of EDD for high-risk customers, transaction monitoring alert logs and evidence that alerts were actioned. On-chain analytics are increasingly incorporated: some regulators will independently trace a sample of the firm's historical transactions to assess whether the monitoring system would have detected known typologies. The most common finding is not an absent policy but a gap between the documented procedure and the actual execution – specifically, stale KYC data and unactioned alerts.
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 compliance, AML and Travel Rule architecture that sits around every regulated activity. We map the licence, banking and KYC stack across operating, custody and payment layers before you commit – so that your program is built for the highest applicable standard, not the lowest common denominator. We work alongside forensic partners to convert on-chain evidence into court-ready disclosure applications when matters escalate. Digital assets are the whole of our practice. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML program design, KYC framework architecture and cross-border VASP compliance across EU, Gulf and Asia-Pacific regimes.
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.