Jurisdiction Framework
End-user eligibility, supported regions, and jurisdictional requirements
Jurisdiction Framework
End-User Eligibility Overview
Swipelux applies a multi-tier jurisdictional framework aligned with EU AMLD, FATF guidance, and internal risk appetite. End-users fall into three categories:
A. Fully Supported (EEA + CH)
End-users may onboard using Passport / National ID / EU Residence Permit. Driver's licences & Paper IDs accepted with increased manual review.
Jurisdictions:
EEA Countries (EU + EFTA): Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Iceland, Liechtenstein, Norway.
Additionally accepted: Switzerland (adequate AML/CTF regulatory environment).
B. Global Coverage – Accepted With Enhanced Due Diligence
End-users from these jurisdictions are allowed but require additional KYC steps, including stricter document rules and potential video-verification based on transaction thresholds.
APAC (Asia-Pacific)
Accepted: Taiwan, India, Sri Lanka, Bhutan, Maldives, Indonesia, Malaysia, Brunei, Cambodia, Philippines*, Singapore, Thailand, Vietnam*, etc.
Document Requirements (APAC):
- Passport OR National ID (paper IDs require passport)
- Proof of Address: utility bill, bank statement, internet bill
LATAM (Latin America and Caribbean)
Accepted: Argentina, Bolivia, Brazil, Chile, Colombia, Costa Rica, Dominican Republic, El Salvador, Guatemala, Honduras, Belize, Mexico, Panama*, Paraguay, Peru, Uruguay.
Document Requirements (LATAM):
- Passport OR National ID (paper IDs require passport)
- Proof of Address required
EMEA (Europe ex-EEA + Middle East + Africa)
Accepted: Albania*, Algeria, Andorra, Angola, Bahrain, Israel, Gibraltar*, Georgia, Kenya, Kuwait, Oman, Qatar*, Saudi Arabia, South Africa*, Turkiye*, UAE*, etc.
Document Requirements (EMEA):
- Passport OR National ID (paper IDs require passport)
- Proof of Address required
- High-risk jurisdictions flagged with (*) require EDD at onboarding
C. No-Go Jurisdictions (Prohibited)
Swipelux does not onboard end-users from jurisdictions classified as:
- FATF Blacklist
- EU AMLD Article 9(2) high-risk third countries with inadequate AML/CTF measures
- OFAC-sanctioned countries
- Internal high-risk jurisdictions (Ecuador, Haiti, Nicaragua, certain overseas territories)
List Includes: Afghanistan, DPRK, Iran, Syria, Yemen, Uganda, Vanuatu, Guyana, Russia, Belarus, Cuba, Venezuela, Nicaragua, Somalia, Sudan, Zimbabwe, Burma, CAR, DRC, Ethiopia, Libya, Mali, Lebanon, etc.
Reason: Regulatory restrictions under EU AMLD, OFAC sanctions, and Swipelux risk appetite.
Important
- Jurisdiction rules apply to end-users, not to merchant incorporation
- Local verification rules (e.g., proof of address, video interview, document type) depend on the user's country of nationality and residence
- Swipelux screens all users using sanctions, PEP lists, and risk-based AML controls
- Users from prohibited jurisdictions cannot access Swipelux services, even via VPN or offshore entities
Simple Clarification Matrix
| Merchant Incorporation | End-User Location | Status | Notes |
|---|---|---|---|
| USA | USA | Not Allowed | We do not hold US Money Transmitter Licenses |
| USA | Global* / EU / UK | Allowed | Sub-merchants must strictly geoblock US IP addresses |
| EU / EEA | USA | Not Allowed | Swipelux cannot service US residents or citizens |
| EU / EEA | Global* / EU / UK | Allowed | Standard flow |
| UK / Canada | Global* / EU / UK | Allowed | Standard flow |
| APAC / LATAM | Global* / EU / UK | Allowed | Standard flow (e.g. India, Brazil) |
| Any Jurisdiction | Prohibited List | Not Allowed | Sanctions screening applies to all users |
Sub-merchant Jurisdictional Matrix
1. EEA+UK+CH
| End-User Region | Open Banking | Cards | Crypto Rails | Local Licensing Required? | Final Status |
|---|---|---|---|---|---|
| EEA | Yes | Yes | Yes | No | Fully Supported |
| UK | Yes | Yes | Yes | No | Fully Supported |
| Switzerland | N/A | Yes | Yes | No | Fully Supported |
2. APAC
| Country (APAC End-User) | Open Banking | Cards | Crypto Rails | Local Licensing Impact | Final Support |
|---|---|---|---|---|---|
| Taiwan | N/A | Yes | Yes | No | Allowed |
| Bhutan | N/A | Yes | Yes | No | Allowed |
| Maldives | N/A | Yes | Yes | No | Allowed |
| India | N/A | Yes | Yes | No | Allowed |
| Sri Lanka | N/A | Yes | Yes | No | Allowed |
| Brunei | N/A | Yes | Yes | No | Allowed |
| Cambodia | N/A | Yes | Yes | No | Allowed |
| Indonesia | N/A | Yes | Yes | No | Allowed |
| Malaysia | N/A | Yes | Yes | No | Allowed |
| Philippines | N/A | Yes | Yes | No | Allowed |
| Thailand | N/A | Yes | Yes | No | Allowed |
| Singapore | N/A | Yes | Yes | No | Fully Supported |
| Vietnam | N/A | Yes | Yes | No | Allowed |
3. LATAM
| Country (LATAM End-User) | Open Banking | Cards | Crypto Rails | Licensing Required? | Final Support |
|---|---|---|---|---|---|
| Argentina | N/A | Yes | Yes | No | Allowed |
| Bolivia | N/A | Yes | Yes | No | Allowed |
| Brazil | N/A | Yes | Yes | No | Allowed |
| Chile | N/A | Yes | Yes | No | Allowed |
| Colombia | N/A | Yes | Yes | No | Allowed |
| Costa Rica | N/A | Yes | Yes | No | Allowed |
| Dominican Republic | N/A | Yes | Yes | No | Allowed |
| El Salvador | N/A | Yes | Yes | No | Allowed |
| Guatemala | N/A | Yes | Yes | No | Allowed |
| Honduras | N/A | Yes | Yes | No | Allowed |
| Belize | N/A | Yes | Yes | No | Allowed |
| Mexico | N/A | Yes | Yes | No | Allowed |
| Panama* | N/A | Yes | Yes | No | Allowed |
| Paraguay | N/A | Yes | Yes | No | Allowed |
| Peru | N/A | Yes | Yes | No | Allowed |
| Uruguay | N/A | Yes | Yes | No | Allowed |
4. EMEA
| Country / Sub-Region | Open Banking | Cards | Crypto Rails | Local Licensing Required? | Final Status |
|---|---|---|---|---|---|
| Albania | N/A | Yes | Yes | No | Allowed |
| Andorra | N/A | Yes | Yes | No | Allowed |
| Israel | N/A | Yes | Yes | No | Allowed |
| Gibraltar | N/A | Yes | Yes | No | Allowed |
| Georgia | N/A | Yes | Yes | No | Allowed |
| UAE | N/A | Yes | Yes | No (VARA not triggered by orchestration) | Allowed |
| Saudi Arabia | N/A | Yes | Yes | No | Allowed |
| Qatar | N/A | No | No (crypto banned) | N/A | Not Allowed |
| Jordan | N/A | Yes | Yes | No | Allowed |
| Kenya | N/A | Yes | Yes | No | Allowed |
| South Africa | N/A | Yes | Yes | No | Allowed |
| Nigeria | N/A | Yes | Yes | No | Allowed |
| Morocco | N/A | Yes | Yes | No | Allowed |
| Algeria | N/A | Yes | No (crypto restricted) | Yes | Allowed – No Crypto |
| Turkey | N/A | Yes | Yes | No | Allowed |
5. Sanctioned / Not Supported
| Country | OB | Cards | Crypto | Final |
|---|---|---|---|---|
| Russia | No | No | No | Not Supported |
| Belarus | No | No | No | Not Supported |
| Iran | No | No | No | Not Supported |
| Syria | No | No | No | Not Supported |
| North Korea | No | No | No | Not Supported |
| Cuba | No | No | No | Not Supported |
| Venezuela | No | No | No | Not Supported |
| Yemen, Sudan, South Sudan | No | No | No | Not Supported |
| Haiti, Nicaragua | No | No | No | Not Supported |
Disclaimer
This jurisdiction matrix is not exhaustive and should be interpreted as a high-level overview of Swipelux's global support framework.
It is designed to give merchants a clear picture of where our payment rails (Open Banking, Card Payments, and Crypto Rails) may be used to onboard and serve end-users.
Swipelux's ability to provide services in a specific jurisdiction depends on:
- Local regulations governing crypto transactions and fiat on/off-ramp activity
- Card scheme and acquiring-bank restrictions
- Sanctions and AML/CTF obligations
- Swipelux's internal risk appetite
Crypto Rails refer to all on-ramp and off-ramp activity performed by Swipelux as a regulated VASP, including custody, conversion, and blockchain transfers initiated or executed by Swipelux.
Because regulatory requirements and scheme rules evolve, the countries and rules listed in this document may change at any time.
Swipelux reserves the right to accept or decline any merchant or end-user, or to restrict specific payment rails, based on regulatory, technical, or risk-based considerations—regardless of whether the jurisdiction appears in this matrix.
- For sensitive or unclear jurisdictions, Swipelux may require:
- Geo-blocking of certain end-users
- Rail-specific restrictions (e.g., cards disabled, crypto disabled)
- Enhanced due diligence
- Legal opinions or regulatory confirmations
Final onboarding decisions are made at Swipelux's sole discretion in alignment with our EU VASP license and internal risk frameworks.