Gibraltar's crypto licensing regime – built on the Distributed Ledger Technology (DLT) Providers Act, supervised by the Gibraltar Financial Services Commission (GFSC) – sits at the crossroads of British legal tradition and EU-adjacent market ambition. For any operator holding a DLT Provider licence, or one actively seeking it, sanctions screening is not an optional compliance enhancement. It is a mandatory component of the AML/CFT programme, and the GFSC tests it directly.
The practical question most general counsel face is not whether to screen but how – which lists, at what frequency, against which counterparty data fields, and how to evidence that programme to a regulator that has grown increasingly granular in its expectations. This page answers that question for the Gibraltar environment, addresses the cross-border dimensions that make the screening obligation more complex in practice than in principle, and explains where the analysis changes for an operator whose entity sits in Gibraltar but whose users, banking and liquidity sit elsewhere.
The Regulatory Basis for Sanctions Screening in Gibraltar
Sanctions compliance in Gibraltar derives from two converging obligations: the AML/CFT requirements embedded in the DLT Provider licensing regime administered by the GFSC, and the sanctions regime maintained by His Majesty's Government of Gibraltar, which mirrors UK sanctions law following Brexit. Every DLT Provider must maintain an effective customer due diligence programme, and sanctions screening is the mechanism that makes that programme operative at the point of onboarding and during the ongoing relationship.
The GFSC applies a risk-based supervisory model. That means the regulator evaluates not whether a firm has a policy document titled "Sanctions Screening" but whether the programme is proportionate to the risk profile of the business – the jurisdictions it serves, the token types it handles, the volume and velocity of transactions, and the nature of counterparties on both sides of a transfer. In our practice, we regularly advise operators who discover that what they built for a low-volume European retail base is structurally inadequate for a business that has since scaled into emerging-market corridors.
Gibraltar has historically been attractive precisely because its GFSC-licensed operators can point to a credible supervisory relationship with a recognised regulator. That credibility depends on the AML/CFT programme – including sanctions screening – holding up under scrutiny. An operator whose screening fails a GFSC examination risks licence suspension and, critically, the banking relationships that anchor the business.
What Must Be Screened – and Against Which Lists?
The screening obligation extends to every customer, beneficial owner, connected party and – under Travel Rule (the obligation to pass originator and beneficiary data with every qualifying virtual-asset transfer) obligations – counterparty data received from other VASPs. Gibraltar does not operate a separate crypto-specific sanctions list. The operative lists are those maintained under Gibraltar's own sanctions instruments, which closely track the UK's Office of Financial Sanctions Implementation (OFSI) consolidated list, and the UN Security Council consolidated list.
In practice, most GFSC-licensed operators also screen against the EU consolidated list and the OFAC Specially Designated Nationals (SDN) list maintained by the US Treasury. This is not technically mandated by Gibraltar law alone, but it reflects the commercial reality that an operator whose US-dollar flows pass through US correspondent banking – which is most of them – carries independent OFAC exposure. The GFSC understands this and expects operators to articulate, in their written AML programme, why the lists they screen represent a defensible risk-based decision.
Screening must be real-time at onboarding and event-triggered thereafter – specifically, when a customer data point changes, when a new sanctions designation is published, and at intervals calibrated to the risk tier of the customer relationship. Static batch-screening run monthly is not adequate for a high-volume exchange. The GFSC has noted this explicitly in published supervisory guidance, and enforcement findings in the wider UK-adjacent regulatory environment confirm the point.
The data fields that must be screened include full legal name, date of birth, nationality, country of residence, and – for corporate customers – registered name, registration number and jurisdiction. For wallet-level screening under the Travel Rule, the originator's and beneficiary's identifying information received in a transfer must also be checked against applicable lists before the transaction is completed.
To map how your current screening programme compares to GFSC expectations, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity structure, the user base, the banking corridors – change the analysis materially.
How Does the GFSC Examine a Sanctions Programme?
GFSC supervisory examinations of DLT Providers are structured reviews that evaluate the full AML/CFT control environment, with sanctions screening typically assessed as a discrete module. The examination process usually begins with an information request covering written policies, system architecture documentation, screening vendor details and a sample of alerts and their disposition records.
Examiners look at three things in particular. First, coverage – whether every required list is loaded, current and actually applied at every required point in the customer lifecycle. Second, governance – whether the Money Laundering Reporting Officer (MLRO) has reviewed and signed off on the programme, and whether the board has been presented with a sanctions compliance report at least annually. Third, alert quality – the ratio of true positives to noise, and the documented rationale for clearing false positives.
An examiner finding a high false-positive rate that is not documented and cleared in a consistent, auditable way will treat that as a governance deficiency, not a purely technical one. We have seen firms where the technology was adequate but the alert-disposition workflow was undocumented, creating material supervisory risk from what was operationally a functioning system.
The MLRO role deserves particular emphasis. Gibraltar requires a designated MLRO who is a Gibraltar-resident individual approved by the GFSC. That person holds personal regulatory accountability for the adequacy of the AML/CFT programme. A DLT Provider whose MLRO is not genuinely engaged with the sanctions screening function – reviewing escalated alerts, approving policy updates, certifying the annual AML report – is exposed both regulatorily and personally.
How Does the Travel Rule Interact with Sanctions Screening Across Borders?
The Travel Rule amplifies the sanctions screening obligation for every Gibraltar-licensed VASP that transacts with counterparty VASPs in other jurisdictions. When a transfer is received from a VASP domiciled under a different regime – say, a MAS-licensed operator in Singapore, an SFC-licensed platform in Hong Kong, or a VARA-supervised exchange in Dubai – the Gibraltar VASP receives originator and beneficiary data in a structured message. That data must be screened against applicable sanctions lists before the incoming transaction is settled into the beneficiary's account.
The challenge is data quality. Not every counterparty VASP delivers originator data that is complete, accurate and in a consistent format. A name field that arrives as a partial string, or a date of birth that is missing, is still a screening obligation – the Gibraltar operator cannot simply settle the transaction because the data was incomplete. The written programme must specify how the firm handles these scenarios, what hold period applies, and at what point an incomplete-data transaction is rejected or escalated to the MLRO.
In a cross-border context, the jurisdictional coverage of the sanctions programme also becomes a genuine legal question. An operator who receives a transfer that the originating VASP's jurisdiction would not sanction – but that appears on the OFSI or OFAC list – must follow Gibraltar's (and commercially, the US-correspondent bank's) obligations, not the originating jurisdiction's more permissive stance. The GFSC expects the operator to have a policy that resolves this conflict clearly and in advance.
We regularly advise on the interplay between Gibraltar's sanctions obligations and those of MiCA-governed EU operators, MAS-regulated Singapore entities and VARA-supervised Dubai platforms. The matrix of overlapping obligations is genuinely complex, and operators who manage it through a single-jurisdiction compliance manual are systematically under-protected.
The Banking and Payment-Rails Dimension
Banking access is the practical amplifier of the sanctions risk. A Gibraltar DLT Provider that processes fiat through a UK or EU correspondent bank is subject to that bank's own sanctions screening layer, which is almost always more stringent than the regulatory minimum. Banks screen not only against official lists but against their own proprietary risk models, and a crypto-sector client whose transaction monitoring generates elevated alerts will find that the bank's relationship managers become interested very quickly.
The connection matters for structuring. A GFSC-licensed operator whose fiat flows route through a UK-regulated EMI, a Maltese payment institution or a Lithuanian bank is operating under at least three overlapping sanctions regimes simultaneously – Gibraltar's, the intermediate payment institution's, and the correspondent bank's. We have seen operators discover this only when a payment is held and a wire arrives from the correspondent requesting documentation that the operator's compliance team was not configured to produce on short notice.
The practical response is to design the sanctions programme so that it is over-inclusive rather than merely compliant with Gibraltar's minimum. That means list selection, data completeness standards and alert-disposition timelines that can withstand scrutiny from a bank's de-risking committee, not just a GFSC examiner. This is not gold-plating; it is the commercially rational baseline for an operator that depends on fiat rails to function.
A Cross-Border Screening Challenge: An Illustrative Matter
In a recent compliance mandate, a Gibraltar DLT Provider operating a multi-asset trading venue identified a gap in its Travel Rule screening workflow during pre-examination preparation. Originator data from counterparty VASPs in two non-EU jurisdictions was being received but not systematically screened before transaction settlement; the firm's system had been configured to screen onboarding data only. The screening vendor's API covered both flows, but the integration had not been extended to the inbound Travel Rule data stream. Working with the firm's MLRO and technology team, we mapped the gap, scoped the remediation, drafted the updated policy and alert-disposition procedures, and prepared the board presentation required to document governance sign-off. The GFSC examination took place within weeks of the remediation going live; the examiner reviewed the workflow and found the programme adequate. No enforcement action followed.
Which Operator Profile Faces the Highest Sanctions Screening Exposure?
Not every Gibraltar DLT Provider faces the same screening risk. The profile that matters most is the combination of activity type, counterparty geography and fiat-rail architecture.
An operator providing custody services to a closed pool of institutional clients with full KYC and no Travel Rule inflows from third-party VASPs faces a relatively contained screening obligation – deep onboarding due diligence, periodic rescreening, and a governance framework. The timeline to build an adequate programme is manageable, and the alert volume is predictable.
An exchange operator receiving retail deposits and settling outbound transfers to wallets and counterparty VASPs in high-risk jurisdictions faces a materially different exposure. Screening must be real-time, alert volumes will be high, the MLRO must be genuinely resourced, and the integration between the screening vendor and the transaction execution layer must be technically robust. The timeline to build this adequately – not just to document it, but to run it – is longer, and the consequences of failure are immediate: a single unsanctioned payment processed to a designated entity creates regulatory and, potentially, criminal exposure.
A stablecoin issuer or payment-service provider operating under the DLT regime faces a third profile: the obligation extends not only to its own customers but to the end-users of its token wherever it circulates. Under the applicable GFSC framework, the issuer cannot outsource the sanction-screening obligation to downstream distributors without retaining primary oversight responsibility.
If your structure places you in the second or third profile above, the screening programme deserves urgent attention. Write to OBOLUS at info@oboluslaw.com to scope a gap analysis before the examination finds the gap first. If a prior review stalled or a banking relationship was closed, a second read can surface the structural reason and the route back.
What Does an Adequate Sanctions Programme Look Like in Practice?
An adequate sanctions programme for a Gibraltar DLT Provider has seven components that the GFSC consistently tests. First, a written sanctions policy approved by the board, reviewed annually and updated within a defined period following a regulatory or operational change. Second, a defined list of the sanctions lists screened, with a documented rationale for that selection. Third, a technical integration between the screening vendor and the firm's customer-data systems that is tested at least quarterly and covers all required customer data fields. Fourth, a Travel Rule data-handling protocol that addresses incomplete or inconsistent originator data received from counterparty VASPs. Fifth, an alert-disposition workflow with defined escalation paths, hold periods and rejection criteria. Sixth, a documented MLRO oversight function including regular reporting to the board. Seventh, an annual AML/CFT compliance report that covers the sanctions programme explicitly, including statistics on alert volume, true positives identified and actions taken.
The common failure mode is not a missing component – most operators can point to something for each of the seven. The failure mode is a programme that exists on paper but has not been operationalised: the policy was not updated after a material business change, the vendor integration was not re-tested after a system migration, or the board report was a single slide that did not address the firm's actual alert data. A GFSC examiner distinguishes between a programme and a documented programme in less time than most operators expect.
A Common Assumption About Gibraltar Crypto Compliance
A common assumption is that a GFSC DLT Provider licence is sufficient to serve users in any jurisdiction without additional regulatory engagement. That assumption is wrong, and it creates the specific conditions under which sanctions programmes fail. A Gibraltar entity whose actual user base is concentrated in a jurisdiction with its own VASP regime – the EU under MiCA, the UK under FCA registration, the UAE under VARA – is likely subject to that jurisdiction's AML and sanctions requirements independently of its Gibraltar licence.
The sanctions obligation follows the activity, not the licence. An operator screening only against Gibraltar's lists while running material volume through EU-based users subject to MiCA's AML obligations, or through US-dollar rails subject to OFAC jurisdiction, has a programme that is locally compliant and globally inadequate. This is the structural mismatch we diagnose in a disproportionate share of the compliance mandates we take on, and it is consistently the vector through which banking relationships deteriorate.
The correct approach is to map every jurisdiction in which the entity has regulatory exposure – entity domicile, user geography, banking jurisdiction, liquidity provider jurisdiction – and build the sanctions programme to the highest applicable standard across that matrix. Gibraltar's GFSC is a credible regulator and the DLT regime is well-regarded. That credibility is a reason to maintain the programme carefully, not a reason to assume it covers everything.
Related at OBOLUS
- AML, Travel Rule and Compliance for Digital-Asset Businesses – full-scope compliance advisory across licensing, screening and Travel Rule obligations
- Regulator AML Audit Defence: What Recent Enforcement Tells Operators – practical analysis of how AML enforcement is conducted and what it reveals about examination risk
- How to Document Tax Substance That Survives Audit – building the documentary record that supports substance claims across jurisdictions
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a VASP (virtual asset service provider) to collect, verify and transmit originator and beneficiary information alongside qualifying virtual-asset transfers. Under the applicable FATF standard, this covers the full legal name, account identifier and address or identifier information for both parties. The obligation applies both to outbound transfers the VASP initiates and to inbound transfers it receives from counterparty VASPs. Incomplete data received on an inbound transfer does not extinguish the screening obligation – it triggers a defined handling procedure instead.
Who must act as MLRO for a crypto firm?
Under the Gibraltar DLT licensing regime, the MLRO must be a named individual approved by the GFSC as a fit-and-proper person. That individual holds personal regulatory accountability for the adequacy of the AML/CFT programme, including sanctions screening. The MLRO must be sufficiently senior and genuinely resourced to perform the role – not a nominal appointment. In practice, the GFSC tests MLRO engagement through the quality of internal reporting, the frequency of board presentations and the documented rationale for escalated decisions.
How do regulators audit crypto AML programs?
Regulators such as the GFSC typically audit AML programmes through a combination of document review and targeted testing. Examiners request written policies, screening vendor documentation, alert-log samples and evidence of board-level governance. They then test whether the programme as documented matches the programme as operated – examining alert-disposition records, Travel Rule data-handling logs and MLRO reporting trails. The most common findings relate not to absent policies but to policies that have not been updated, tested or operationalised following material changes to the business.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the tax, banking and compliance that sit around them. Digital assets are the whole of our practice. We map the licence, compliance and banking stack across operating, custody and payment layers before you commit – and we structure those workstreams as one integrated mandate rather than three disconnected engagements. To discuss your situation, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML/CFT programme design, sanctions screening architecture and GFSC supervisory engagement for licensed DLT Providers.
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.