EST · MMXXVI
Home/Services/Compliance Aml Travel Rule/KYC and onboarding framework from a Cross-border Perspective
Compliance, AML & Travel Rule

KYC and onboarding framework from a Cross-border Perspective

Kyc and onboarding framework from a Cross-border Perspective. Cross-border digital-asset legal counsel for business – licensing, disputes and structuring. Talk

Operating a digital-asset business across borders without a coherent KYC and onboarding framework (the structured identity-verification, risk-scoring and ongoing-monitoring architecture required under anti-money-laundering law) is one of the fastest routes to frozen banking rails, regulatory enforcement and lost operating licences. As VASP supervision tightens across the major hubs – from MiCA in the European Union to the VARA regime in Dubai and the MAS Payment Services Act in Singapore – the baseline expectation has risen sharply. Regulators now scrutinise not only whether a firm collects identity documents, but whether its onboarding logic is calibrated to the jurisdictions it serves, the assets it handles and the risk profile of each customer.

This page sets out the regulated basis for a cross-border KYC and onboarding programme, the process a well-structured firm should follow, the common failure points we see in our practice, and the questions a general counsel or MLRO should answer before committing to a compliance architecture.

A cross-border digital-asset business faces layered and sometimes contradictory AML compliance obligations – the regime where the entity is licensed, the regime where the user resides and the regime where banking is conducted may each impose different identity-verification standards, risk-scoring thresholds and record-keeping requirements. That layering is the core legal problem.

A firm licensed under MiCA and passporting across the EU/EEA must satisfy ESMA guidance and the relevant national competent authority. The same firm serving users in Singapore must also consider MAS expectations for digital payment token service providers. If its custodian banks in a third jurisdiction, that jurisdiction's financial intelligence unit may impose its own customer due-diligence rules as a condition of maintaining the account.

In our cross-border practice, we regularly advise operators who built their KYC programme around a single jurisdiction's rules, then discovered on expansion – or on banking review – that the programme was silent on risk factors that other regulators treat as mandatory. The cost of remediation at that stage is substantially higher than designing correctly at the outset.

The FATF Recommendations, including Recommendation 15 on virtual assets, establish the global baseline. Every major licensing jurisdiction – the EU under MiCA, Dubai under VARA, Singapore under the Payment Services Act, Hong Kong under the SFC VATP regime – implements those recommendations in its own regulatory instrument. The firm must map each layer explicitly.

For a scoped assessment of your current KYC architecture against the regimes you operate in, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity structure, the user base, the banking relationship – change the analysis materially.

The regulated basis across key hubs

Every major VASP regime derives its KYC requirements from the FATF framework, but each jurisdiction translates that framework differently, and the differences matter operationally.

Under MiCA, a CASP (crypto-asset service provider) authorised in one EU member state may passport across the EU/EEA. The AML obligations, however, are not fully harmonised at the MiCA level alone – the EU's anti-money-laundering directives, as implemented by each member state, overlay the MiCA CASP authorisation. The result is that a CASP passporting from, say, Lithuania must satisfy both the Bank of Lithuania's supervisory expectations and the AML rules of each member state into which it passports services. Customer due-diligence depth, enhanced-due-diligence triggers and politically-exposed-person screening requirements can vary at the national level.

VARA in Dubai operates an activity-based licensing model. Its rulebooks specify onboarding obligations that apply at the activity level – exchange, custody, lending and so on. A firm holding multiple VARA activity licences must ensure its KYC programme addresses the risk profile of each activity, not just the one the compliance team first designed for. VARA's supervisory posture has become increasingly granular; in our practice we have seen requests for detailed policy documentation on onboarding logic and adverse-media screening at early stages of the application process.

In Singapore, MAS applies a risk-based approach under the Payment Services Act. The depth of due diligence required scales with the assessed risk of the customer and the nature of the digital payment token service. Major payment institutions face more intensive obligations than standard payment institutions. Firms serving institutional clients and retail clients simultaneously must maintain clearly separated risk tiers.

The FCA in the United Kingdom requires cryptoasset businesses to register under the Money Laundering Regulations. The FCA's financial-promotions regime adds a further compliance layer for firms marketing to UK users, even without a UK-incorporated entity. Cross-border businesses frequently underestimate the reach of the UK promotions rules.

What a cross-border KYC framework must contain

A compliant cross-border KYC and onboarding framework is not a single policy document – it is a layered architecture covering identity verification, risk classification, ongoing monitoring, and jurisdiction-specific overlays, each with documented governance.

The minimum structural components are:

  • Customer identification and verification (CIV) layer – the rules specifying what identity evidence is collected, how it is verified (document authenticity checks, liveness testing, third-party database screening) and what the acceptable verification methods are for each customer type and jurisdiction of residence.
  • Risk classification engine – the documented logic that assigns each customer to a risk tier (standard, elevated, high) based on factors including nationality, business type, source of funds, product type and transaction patterns. The risk classification must be defensible to regulators; undocumented manual overrides are a consistent finding in supervisory reviews.
  • Enhanced due diligence (EDD) protocols – triggered by risk classification, PEP status, adverse-media hits or specific transaction patterns. EDD must be documented and signed off at an appropriate management level.
  • Jurisdiction-specific overlays – the layer that translates the firm's base programme into the specific requirements of each regulator. This includes, for example, the EU's PEP definition (which differs from FATF's) and VARA's specific onboarding documentation requirements.
  • Ongoing monitoring and refresh – the rules for transaction monitoring, periodic review of customer files and trigger-based re-KYC. A static onboarding programme that does not monitor the customer relationship over time will fail regulatory review.
  • Record-keeping architecture – the systems and documented retention policies that satisfy the longest applicable retention period across the firm's operating jurisdictions.

The Travel Rule as an onboarding input

The Travel Rule (the obligation, derived from FATF Recommendation 16, to pass originator and beneficiary information with a virtual-asset transfer) is not a standalone compliance function – it interacts directly with the onboarding framework. A firm that has not correctly onboarded its customers cannot satisfy its Travel Rule obligations for transfers involving those customers.

Under MiCA and the EU Transfer of Funds Regulation, a CASP must transmit originator and beneficiary data with every transfer above the applicable threshold. Below the threshold, a lighter-touch obligation applies, but the customer record must still support identification on request. In practice, this means the onboarding system must generate and retain the data fields the Travel Rule requires at the point of customer onboarding – not attempt to reconstruct them later.

For unhosted wallets – transfers to and from wallets not held at a regulated VASP – the regulatory expectation varies by jurisdiction. Some regimes require the firm to conduct additional due diligence on the beneficial owner of the unhosted wallet before processing the transfer. VARA, MAS and the FCA each have distinct postures on this point. A cross-border firm must map its unhosted-wallet policy to the most demanding applicable regime or maintain jurisdiction-specific policies with a clear routing logic.

In our cross-border practice, the Travel Rule integration point is where onboarding programmes most commonly break down. The customer file contains the right information, but the systems are not configured to extract it in the format a Travel Rule counterparty or regulator expects. This is a technical and legal problem simultaneously.

Common mistakes in cross-border onboarding programmes

The most expensive KYC failures we see share identifiable patterns. Recognising them at the design stage is substantially cheaper than remediating them under regulatory pressure.

First: a single-jurisdiction policy applied globally. A common assumption is that a well-drafted programme for the primary licensing jurisdiction is sufficient for all markets. It is not. Each jurisdiction where users reside, where assets are custodied or where banking is maintained may impose additional obligations. A VARA-licensed firm serving EU users must also satisfy MiCA AML expectations for those users; its VARA programme alone will not satisfy a MiCA-aligned national competent authority.

Second: undocumented risk classification. Regulators in every major hub expect to see the logic behind each customer's risk classification. A programme that assigns risk scores without documented criteria – or that allows underwriters to override the model without a written rationale – will fail a supervisory review. ESMA, MAS and the FCA all emphasise the documentation of risk-scoring methodology in their supervisory guidance.

Third: EDD that is triggered but not completed. The onboarding queue contains customers flagged for enhanced due diligence that was never resolved. This is one of the most common findings in AML audits. The firm has the right policies; it simply does not have the operational capacity or the governance to enforce them consistently.

Fourth: static programmes with no refresh cycle. A KYC programme designed at launch but not updated as the regulatory environment changes is a liability. MiCA introduced new obligations for CASPs that a programme built before MiCA's application date will not address. VARA's rulebooks have been updated repeatedly. Firms need a documented programme-review cycle with clear ownership.

Fifth: Banking-triggered remediation. In our practice, we have seen firms face bank requests for complete KYC programme documentation as a condition of maintaining a fiat account. Banks assess the AML programme of a crypto client as part of their own due-diligence obligations. A programme that satisfies the primary regulator but does not address the bank's risk appetite can result in account closure regardless of licence status.

To pressure-test your KYC programme architecture before your next banking or supervisory review, message us via t.me/oboluslaw. If a prior application stalled or an account was closed, a second read can surface the structural reason and the route back.

The MLRO function in a cross-border business

Every regulated digital-asset business is required under applicable AML law to designate a Money Laundering Reporting Officer (MLRO) – the individual responsible for receiving and assessing internal suspicious-activity reports, making external disclosures to the relevant financial intelligence unit and overseeing the AML programme. In a cross-border business, the MLRO function is structurally complex.

A firm licensed in multiple jurisdictions may face competing requirements on where the MLRO must be located, what qualifications they must hold and to which regulator they must report. VARA expects the MLRO to be a designated individual within the firm's governance structure with documented authority. MAS similarly expects a clearly identified compliance function with appropriate seniority. Some EU member states require the MLRO to hold specific AML certifications recognised by the national competent authority.

For cross-border businesses, a single global MLRO with jurisdiction-specific deputies – each reporting to the global function but responsible for the local regulatory relationship – is a common and defensible model. The governance documentation must make clear who holds ultimate responsibility for each regulatory relationship, who signs off suspicious-activity reports to each jurisdiction's financial intelligence unit, and what the escalation path is between the local and global functions.

The MLRO must also have genuine authority over the business. A nominal appointment that does not come with the authority to delay or block transactions, to access customer data and to escalate to the board is not compliant with the spirit of the applicable regime in any jurisdiction. Regulators have acted against firms where the MLRO was a title without substance.

Decision matrix: which programme architecture fits which profile

There is no single KYC programme architecture that fits every cross-border digital-asset business. The right design depends on the firm's entity structure, its regulated activities, the jurisdictions it serves and the sophistication of its customer base.

Profile A – Single-hub CASP, EU-only users. A CASP authorised in one EU member state and serving only EU/EEA users operates within a broadly harmonised MiCA and AML regime. The core programme can be built around the ESMA and national competent authority expectations, with a passporting overlay for the member states served. The Travel Rule obligation runs under the EU Transfer of Funds Regulation, which is uniformly applicable. The key risk is underestimating national-level variations in EDD and PEP screening. Timeline for a well-resourced programme build: a matter of weeks for the core policy suite, longer for system configuration and testing.

Profile B – Multi-hub operator, UAE and EU. A firm holding both a VARA licence and a MiCA CASP authorisation must maintain two regulatory relationships with distinct supervisory expectations. VARA's rulebook is prescriptive on onboarding documentation; MiCA's AML obligations are layered with those of the relevant EU member state. The programme architecture must have a common core (FATF-aligned) and separate jurisdiction modules. The MLRO structure needs clear delineation of UAE and EU reporting responsibilities. Risk: the two modules drift apart as each regulator issues updated guidance; a quarterly programme-alignment review is advisable.

Profile C – Global exchange, multiple jurisdictions including Singapore and UK. The most complex profile. MAS, FCA, VARA and MiCA-aligned regulators each have distinct customer-type risk-weighting approaches. Transaction monitoring must be calibrated to each product and market. The Travel Rule obligation runs under different instruments in each jurisdiction. The MLRO structure will likely require a global function with local deputies. The onboarding system must be capable of applying jurisdiction-specific routing logic at the account-opening stage. This profile requires a programme-governance committee with regular review, not a static policy document.

A practice note: onboarding remediation after a supervisory query

In a recent cross-border compliance matter, an exchange operating under two separate VASP registrations approached us after receiving a supervisory information request from one of its home regulators. The regulator had identified a gap between the firm's stated risk-classification methodology and the customer records produced in a sample review. The firm's onboarding policy described a three-tier risk model; the customer files showed a large cohort of customers classified at the lowest tier without the documented rationale the policy required.

We conducted a rapid programme audit, mapped the gap between the policy and the operational reality, and drafted a remediation plan that addressed both the immediate regulatory request and the structural causes of the inconsistency – primarily that the risk-scoring logic in the onboarding system had been modified after the policy was drafted, without updating the policy documentation. We also identified that the firm's Travel Rule data fields were incomplete for a material share of its customer base, creating a secondary exposure.

The remediation plan was accepted by the regulator. The experience is consistent with what we observe across the sector: the documentation gap between the written KYC programme and the operational reality is, in many firms, the primary supervisory risk.

Self-assessment checklist

Before a regulatory review or a banking due-diligence request, a general counsel or MLRO should be able to answer yes to the following:

  • Does the KYC programme document the specific requirements of each jurisdiction in which the firm is licensed or serves users, not just the primary licensing jurisdiction?
  • Is the risk-classification methodology documented, with the criteria for each tier explicitly stated and the process for overrides recorded?
  • Are EDD cases tracked from trigger to resolution, with management sign-off recorded?
  • Is the Travel Rule data captured at onboarding and retrievable in the format required by each applicable regime?
  • Is the MLRO's authority documented and does it include the power to delay or block transactions?
  • Is the programme reviewed and updated on a defined cycle, with changes tracked and version-controlled?
  • Have banking counterparties reviewed the programme and confirmed it meets their own due-diligence requirements?

A gap against any of these questions is a risk item that should be addressed before, not during, a supervisory inquiry.

Related at OBOLUS

FAQ

What does the Travel Rule require from a VASP?

The Travel Rule, derived from FATF Recommendation 16, requires a VASP (virtual asset service provider) to collect and transmit originator and beneficiary information – including name, account identifier and, in most regimes, an address or national identification number – with every qualifying virtual-asset transfer. The precise threshold above which the full dataset must travel varies by jurisdiction; below the threshold, lighter obligations typically apply. The sending VASP must verify originator data; the receiving VASP must screen beneficiary data against sanctions and AML requirements.

Who must act as MLRO for a crypto firm?

Every regulated digital-asset business must designate a Money Laundering Reporting Officer (MLRO) – a named individual with documented authority to receive internal suspicious-activity reports, make external disclosures to the relevant financial intelligence unit and oversee the AML programme. The specific qualification, seniority and location requirements vary by jurisdiction: VARA, MAS and MiCA-aligned national competent authorities each set their own expectations. The MLRO must hold genuine operational authority, not simply a nominal designation; regulators in the leading hubs have taken action where the MLRO lacked substantive power.

How do regulators audit crypto AML programs?

Regulators typically audit a crypto firm's AML programme through a combination of document review, system walkthroughs and sample-file testing. They will request the written policy suite, the risk-classification methodology, a sample of customer onboarding files across risk tiers and evidence of ongoing monitoring. They assess whether the written programme matches operational practice – gaps between documentation and reality are the most common finding. VARA, MAS, the FCA and MiCA-aligned national competent authorities increasingly conduct on-site or virtual inspections rather than relying solely on periodic reporting.

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. We map the KYC and AML compliance stack across operating, custody and payment layers before you commit – giving general counsel and MLROs a defensible programme architecture from the outset. We advise crypto exchanges, custodians, token issuers and funds across more than seventy licensing jurisdictions. Digital assets are the whole of our practice. To discuss your situation, contact info@oboluslaw.com.

By Victor Olsen, Regulatory & Compliance Analyst – specialising in cross-border AML programme design and VASP compliance architecture across EU, UAE 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.

Tell us the task — we'll map your options in 30 minutes.

Fixed-fee packages with defined scope and SLAs. The first call is free and under NDA. Business clients only.

Map your optionsinfo@oboluslaw.com · t.me/oboluslaw · reply < 2 hours