Operating a digital-asset business without a properly structured KYC and onboarding framework (the layered set of know-your-customer, due-diligence and monitoring controls that a regulated firm must maintain) is one of the fastest routes to enforcement action, frozen payment rails and sudden bank de-risking. Regulators across every flagship hub – ESMA and national competent authorities under MiCA, VARA in Dubai, the MAS in Singapore and the FCA in the UK – now treat the onboarding program not as a back-office checkbox but as a structural control embedded in the firm's licensing posture. Get the structure wrong before you apply and the regulator sees it on day one of the review.
This analysis examines the KYC and onboarding framework from the structuring angle: how the design choices a firm makes early – entity location, user geography, product scope – determine what the AML/CFT program must look like, where the Travel Rule obligation bites and how a second-layer licensing jurisdiction changes the picture. The analysis is written for the general counsel or compliance officer who already understands the mechanics and needs the legal read.
Why the legal structure drives compliance cost and risk before a single user is onboarded
The structure of the operating entity determines which regulatory regime owns the KYC obligation – and that choice, once made, is expensive to unwind. A VASP (virtual asset service provider) incorporated in one jurisdiction but serving users in another faces a compliance stack that can be two or three regimes deep before the first trade executes. Under MiCA, a CASP (Crypto-Asset Service Provider) authorised in one EU member state may passport across the EEA, but passporting does not eliminate local AML obligations in the host state – it shifts which authority monitors them. VARA in Dubai applies to mainland activity and has its own rulebook expectations; ADGM/FSRA in Abu Dhabi operates a separate recognized-activities regime. A firm that straddles both free zones and the mainland quickly accumulates overlapping obligations on the same customer file.
In our cross-border practice, we regularly advise firms that built their onboarding program around the lightest-touch regime available at incorporation and discovered, months later, that the jurisdiction where most of their users are located imposes a materially heavier standard. The gap between the two is not a theoretical risk – it is the gap a regulator will walk through during an audit.
The structural question, therefore, is not only "where do we incorporate?" It is: "For every jurisdiction where we have users, banking or operational staff, which AML regime applies, and is our onboarding program calibrated to the most demanding of those regimes?" A cross-border KYC framework must be designed from the highest common denominator, not the lowest available standard. That principle sounds obvious; the structural incentive runs exactly the opposite way.
For a scoped assessment of your compliance structure before your next licensing application, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity, the user base, the banking – change the analysis entirely.
What do regulators actually examine when they audit a KYC framework?
Regulators auditing a crypto AML program focus on five structural elements: the risk appetite statement, the customer risk classification methodology, the source-of-funds and source-of-wealth process, the screening architecture and the transaction-monitoring calibration. Each of these has a structural dimension that predates the compliance operations team.
The risk appetite statement is the document that tells the regulator whether senior management has actually thought about which customers the firm will not serve and why. A firm whose risk appetite statement says "we accept retail customers globally" with no geographic carve-outs will face hard questions from any competent-authority examiner. FATF Recommendation 15 – the standard that covers virtual assets and VASPs – requires risk-based procedures, which means the board must be able to demonstrate that the appetite is calibrated to the actual product risk, not inherited from a generic template.
Customer risk classification is where the structural choice of product matters enormously. A firm offering a non-custodial wallet faces a different classification problem from a firm offering margin lending or a fiat on-ramp. The regulator does not care that the firm used the same onboarding form for both – it cares whether the enhanced-due-diligence trigger was set at the right point for each product. In our practice, we have seen firms apply a single risk matrix across materially different products because the original compliance program was drafted for the first product and never updated when the second was added. That is a structural deficiency, not an operational one.
Source-of-funds and source-of-wealth documentation requirements escalate sharply for high-value or high-risk customers. Most flagship regimes set a risk-based threshold for enhanced due diligence that varies by jurisdiction and by the nature of the business relationship. What does not vary is the expectation that the firm can produce the documentation on request. A firm that onboards a customer under simplified due diligence and later cannot explain why that customer qualified for simplified treatment has a gap the regulator will notice.
Transaction monitoring calibration – the tuning of automated systems to flag suspicious behavior – is increasingly a primary audit focus. Regulators in the major hubs, including the FCA and MAS, have published guidance signaling that poorly calibrated systems (either too many false positives drowning the compliance team or thresholds set too high to catch real risk) are a supervisory concern. The structural point is that calibration decisions are made at system design stage, often before the firm is fully operational, and are hard to correct retrospectively without a formal system redesign.
How does the Travel Rule obligation change with the firm's structure?
The Travel Rule (the obligation, derived from FATF Recommendation 16 as applied to virtual assets, to pass originator and beneficiary information along with a transfer between VASPs) is one of the clearest examples of a compliance obligation whose cost and complexity are determined by structural choices made before the firm begins operating. Where the sending VASP is incorporated, where the receiving VASP is located and whether either operates under a regime that has formally implemented the Travel Rule in binding regulation – all of these interact.
Under MiCA's Transfer of Funds Regulation extension, EU CASPs are subject to Travel Rule requirements on transfers of any size – there is no de-minimis carve-out at the EU level that would permit a CASP to ignore the obligation for small transfers. That is a structurally different position from some non-EU regimes where a de-minimis threshold applies. A firm structured to serve both EU and non-EU users therefore needs a Travel Rule solution that can operate at the EU standard even when the counterparty VASP is in a regime with a higher de-minimis.
The practical structuring problem is that a VASP cannot always verify whether the counterparty VASP has a compliant Travel Rule system before executing a transfer. The sunrise problem – the period during which some jurisdictions have implemented the rule and others have not – created asymmetric compliance positions that still affect cross-border transfers. A firm whose structure includes a regulated entity in an implemented jurisdiction and an affiliated entity in a non-implemented jurisdiction needs internal protocols that prevent the non-implemented entity from being used to route around the obligation.
In our cross-border practice, we regularly advise on the Travel Rule interaction between EU-licensed entities and entities in jurisdictions where implementation is at various stages. The answer is almost never "implement the minimum required by the entity's home regime." It is "implement the standard required by the most demanding regime in which the entity has material activity" – and then document why that standard was chosen.
Onboarding framework design for multi-product businesses: where the structural tension sits
A multi-product digital-asset business – an operator running an exchange, a custody service and a lending product under one or more regulated entities – faces a structural tension in onboarding design that single-product operators do not. The customer admitted through the exchange onboarding flow may also use the custody or lending product; the risk profile relevant to one product may be inadequate for another. Most regulators expect the firm to apply the higher of the applicable standards to the overall customer relationship once the customer is active across products.
The structural choice is whether to run one onboarding program that is calibrated to the most demanding product in the portfolio or to run product-specific programs with a reconciliation layer. Both are defensible architecturally, but the second is materially harder to audit and more prone to gaps at the seams. A firm that onboarded a customer under exchange standards and then extended credit to that customer under the same file – without triggering the enhanced due diligence process required for the lending product – has a structural compliance deficiency that a regulator will characterize as a systemic failing, not an isolated error.
The cross-border dimension adds further complexity. A customer who is resident in the EU triggers MiCA's CASP-level obligations; the same customer, if also a US person, may trigger FinCEN expectations under the Bank Secrecy Act framework. Neither obligation disappears because the other exists. An onboarding framework that satisfies one but not the other leaves the firm exposed in one direction, and the exposure may not become visible until a law-enforcement inquiry or an enforcement action arrives from the less-satisfied regulator.
In a recent matter, a multi-jurisdictional exchange operator asked us to review its onboarding program ahead of a licensing application in a new jurisdiction. The review identified that the firm's source-of-funds process, adequate for its existing licensed activities, did not meet the enhanced standards required by the target regulator for the lending product it planned to add. We restructured the EDD triggers before the application was filed. The regulator's examination subsequently confirmed the framework without requiring remediation – a materially better outcome than a post-application request for information.
Decision matrix: which onboarding architecture fits which operator profile?
The right onboarding architecture depends on the operator's product scope, user geography and entity structure – not on what is cheapest or what a peer firm is using. The following profiles illustrate the principal decision branches.
Profile A – Single-product EU CASP with passported services. An exchange licensed under MiCA in one member state, passporting across the EEA with no products outside the EU. The applicable standard is the MiCA/CASP regime plus the national AML transposition of the relevant AMLD generation in the home member state. The onboarding framework should be built once to the highest-standard member state's transposition – typically that means a conservative reading of the EDD triggers and a Travel Rule implementation with no de-minimis tolerance. Timeline to implement a compliant framework from scratch is typically measured in months, not weeks, if technology vendors need to be onboarded alongside the process design.
Profile B – Dual-hub operator (EU entity + Gulf entity). A firm with a MiCA-licensed entity serving European users and a VARA-licensed entity serving UAE and regional users. These entities operate under materially different rulebooks. The EU entity's onboarding obligations are set by MiCA/AMLD; the VARA entity's obligations are set by VARA's own activity-specific rulebooks. The structural question is whether the group's onboarding technology and data architecture can support both sets of obligations without cross-contaminating data that should be ring-fenced between entities. This profile typically requires a compliance program designed at group level with entity-level annexes – not two separate programs that happen to share a technology platform.
Profile C – Offshore-domiciled operator serving retail globally. A firm incorporated in a low-regulation jurisdiction (BVI, Cayman) with the VASP Act registration but seeking to serve retail users in the EU, UK and/or Singapore. This profile carries the highest structural risk: the firm's home regime sets a baseline, but each major market in which it operates applies its own standard to the firm's activities – potentially without the firm having applied for authorization there. The onboarding framework must be designed around the most demanding market in scope. A VASP Act registration in the BVI does not satisfy EU CASP requirements, UK MLR registration requirements or Singapore's Payment Services Act licensing requirements. Operating under the false assumption that it does is one of the most common structural errors we see in practice.
Profile D – Institutional-only platform. A firm serving only institutional counterparties (funds, corporates, other VASPs) with no retail exposure. The onboarding framework shifts from consumer-protection-adjacent KYC to counterparty due diligence under an institutional framework. Simplified due diligence may be available for certain counterparty types in certain regimes, but the Travel Rule obligation applies regardless of the counterparty's sophistication. The structural benefit of this profile is that the risk classification matrix is significantly simpler; the structural risk is that institutions, particularly other VASPs, carry their own compliance obligations and a firm that onboards a non-compliant VASP as a counterparty inherits reputational and, in some regimes, regulatory risk for the association.
Where should the MLRO and compliance function sit in a cross-border structure?
The MLRO (Money Laundering Reporting Officer) is the designated individual responsible, under most FATF-aligned regimes, for receiving and filing suspicious activity reports and for overseeing the firm's AML program. The structural question of where the MLRO sits has direct compliance and legal-liability implications that are frequently underestimated at the entity-design stage.
Most flagship regimes require the MLRO to be sufficiently senior, sufficiently resourced and – critically – genuinely independent of revenue-generating functions. VARA in Dubai, the FCA in the UK and MAS in Singapore all impose prescriptive expectations on the MLRO's seniority and access to senior management. An MLRO placed in an offshore holding company with no operational staff is unlikely to satisfy those expectations for a regulated operating subsidiary. The regulator's expectation is that the MLRO has real authority within the actual operating entity, not nominal authority within a holding structure.
In a group structure with multiple regulated entities, each regulated entity typically requires its own MLRO – or, where a group MLRO model is used, documented protocols that demonstrate the group MLRO has effective authority over each entity's AML program and is accessible to each entity's staff. The cross-border point is that the group MLRO cannot be an officer of only one group entity and be treated as the MLRO for a separate entity in a different jurisdiction without that entity's regulator agreeing to the arrangement. We have seen this assumption create significant problems at the authorization stage, when the target regulator declines to accept the group MLRO as the entity's designated officer.
If a prior application stalled because the compliance structure was questioned, a structured second review can identify the gap and the route forward. Write to info@oboluslaw.com to open a matter.
What are the most common structural errors in KYC frameworks, and how are they corrected?
The most common structural errors in KYC frameworks are, in our experience, not failures of operational execution – they are failures of design that were visible before the firm onboarded its first customer. Identifying and correcting them early is materially less costly than remediating them under regulatory pressure.
The first error is building the framework around the home-jurisdiction standard without mapping the applicable standards in every jurisdiction where the firm will have users, banking relationships or operational presence. A regime that requires risk-based AML/KYC controls does not limit that requirement to users in the licensed jurisdiction. It applies to the firm's entire activity – and a regulator that finds users in a high-risk jurisdiction being onboarded under procedures designed for a lower-risk environment will treat that as a systemic failure, not a gap in geographic coverage.
The second error is treating the onboarding framework as a compliance-team deliverable rather than a structuring deliverable. The design choices that determine the framework's complexity – which entity contracts with which user, which jurisdictions are in scope, which products are offered – are legal and structural decisions. By the time the compliance team is asked to build the framework, those decisions are already made and frequently cannot be changed without corporate restructuring. Engaging compliance design at the same stage as entity design is not a luxury; it is a cost-saving measure.
The third error is failing to account for the ongoing maintenance obligation. A KYC framework that was compliant at licensing is not automatically compliant two years later. Regulatory standards evolve. FATF mutual evaluations result in jurisdiction-level recommendations that translate into tighter national standards. MiCA's secondary technical standards continue to develop. A firm that treats the onboarding framework as a static document – reviewed at licensing and then filed – will drift out of compliance on the regulatory timeline, not on its own operational timeline. The framework must have a documented review cycle tied to the regulatory calendar of every jurisdiction in which the firm operates.
A common assumption in the market is that a single offshore licence is sufficient to serve clients globally. That assumption is false. Every major user market – the EU, the UK, Singapore, Hong Kong – has its own authorization or registration requirement for firms actively marketing to or serving users in that market. The offshore licence is the firm's home-jurisdiction compliance baseline; it does not substitute for market-by-market analysis of whether additional authorization is required.
How does the KYC framework interact with the firm's banking relationship?
A well-constructed KYC framework does more than satisfy regulators – it is increasingly the document that a correspondent bank or EMI partner reviews before opening an account for a digital-asset business. Banks conduct their own AML due diligence on VASP clients, and the quality of the VASP's own KYC program is a primary input into that assessment. A framework that is thin, generic or visibly template-derived signals to a bank's financial-crime team that the VASP's risk management is not serious – and in the current banking environment, that signal almost always results in a declined or terminated relationship.
The structural point is that the same framework document that satisfies the licensing regulator should be the document presented to the bank. That means it must be sufficiently detailed that a bank's compliance officer can verify, from the framework, that the VASP applies enhanced due diligence to high-risk customer categories, has a calibrated transaction monitoring system, conducts periodic review of existing customers and has a documented escalation path to the MLRO for suspicious activity. A framework that answers those questions clearly is a banking relationship asset as well as a regulatory compliance document.
In our practice, we structure the licensing, banking and compliance mandate as a single integrated workstream rather than three separate engagements. The reason is that the decisions made in each workstream affect the others – and sequential engagement, where the banking strategy is addressed after the licensing is complete, routinely results in a licensed entity that cannot bank. The order of operations matters: the banking strategy should inform the entity structure, which should inform the onboarding framework design, before any application is filed.
Objection: "We already have a KYC framework – why does the structure need to be reviewed again?"
A common assumption held by operators who have already obtained a licence and built a compliance program is that the existing framework does not need to be revisited when the firm expands to a new jurisdiction, adds a product or changes its banking structure. That assumption is the structural equivalent of assuming that a contract drafted for one counterparty needs only a name change to work for a different counterparty in a different legal system.
The existing framework was designed for a specific entity, in a specific jurisdiction, for a specific product set, with a specific risk appetite. When any of those variables changes materially, the framework needs to be reassessed against the new variable set. A framework designed for a Singapore MAS-licensed entity onboarding retail users does not automatically satisfy the obligations of an EU MiCA CASP onboarding EU retail users – even if the underlying technology is identical and the due-diligence steps look similar. The applicable regime has changed, the supervisory authority has changed and the Travel Rule implementation standard may have changed.
The more subtle version of this objection is: "We reviewed the framework six months ago and it was fine." Regulatory timelines do not pause because a firm recently conducted a review. MiCA's technical standards continue to develop. VARA's rulebooks are updated on VARA's schedule. FATF guidance on virtual assets evolves. A framework that was compliant at the last review date is compliant as of that date – not as of today. The structural requirement is a review cycle that tracks regulatory developments in real time, not a point-in-time sign-off.
Operators we advise routinely discover, on a structured review, that their framework's risk classification methodology has not been updated since the firm's original licence was granted – and that the firm's current product suite includes instruments that the original matrix did not contemplate. That gap is not a compliance-team failure. It is a governance failure at the structural level, and it is correctable before an examiner finds it.
Related at OBOLUS
- AML and Travel Rule compliance for digital-asset businesses – end-to-end compliance structuring from licensing through to ongoing AML program management
- MLRO and compliance officer function in Mauritius – the designated compliance role requirements under Mauritius's VAITOS Act framework
- Permanent establishment risk for distributed crypto operations – how staff and server location create unexpected tax obligations across borders
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule, derived from FATF Recommendation 16 as extended to virtual assets, requires a VASP to collect, verify and transmit originator and beneficiary information alongside a virtual-asset transfer to the receiving VASP. The precise threshold at which the obligation applies varies by jurisdiction: under EU rules, there is no de-minimis exemption, meaning the obligation applies to transfers of any size. In other regimes a threshold applies, but VASPs serving multiple markets should implement the most demanding standard applicable to their user base rather than the lightest available.
Who must act as MLRO for a crypto firm?
The MLRO (Money Laundering Reporting Officer) must be a sufficiently senior individual within the regulated entity – not a holding company or a nominee service – with genuine authority over the AML program, access to senior management and the independence to file suspicious activity reports without commercial pressure. Most flagship regimes, including VARA, the FCA and MAS, specify seniority and independence requirements. In a group structure with multiple regulated entities, each entity generally requires a designated MLRO, or a group MLRO model with documented entity-level authority protocols accepted by each relevant regulator.
How do regulators audit crypto AML programs?
Regulatory audits of crypto AML programs typically examine five elements: the risk appetite statement, the customer risk classification methodology, enhanced due diligence processes for high-risk customers, screening and sanctions-list integration, and transaction-monitoring calibration. Examiners increasingly focus on whether the framework reflects the firm's actual product suite and user geography – not a generic template. A firm that cannot demonstrate that its transaction-monitoring thresholds were set with reference to its specific risk profile, or that its EDD triggers are calibrated to its highest-risk product, will face remediation requirements regardless of whether a suspicious transaction was ever missed.
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 structure licensing, banking and compliance as one integrated mandate rather than three disconnected workstreams – a discipline that matters most when a new jurisdiction, a new product or a bank de-risking event puts the existing structure under pressure. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in cross-border AML program design, VASP licensing and Travel Rule implementation for digital-asset businesses operating across multiple regulatory 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.