Compliance Reference
Swipelux regulatory framework, jurisdictional guidelines, and compliance requirements for merchants and end-users
General Information
Swipelux OÜ is an EU-licensed Virtual Asset Service Provider (VASP).
Swipelux performs 100% of the regulated crypto activity, including wallet creation, crypto custody, exchange, and blockchain execution.
Sub-merchants do not perform any VASP-regulated activity. They:
- control UX/UI and user acquisition
- redirect users to Swipelux orchestration (widget/SDK/API)
- never hold, control, or access private keys
- never custody funds or execute blockchain transactions
Regulatory Perimeter
Because Swipelux is the regulated entity performing the entire crypto leg, sub-merchants are not required to obtain VASP/CASP licenses for these flows (unless their own local sector licensing requires it—e.g., gambling, CFD, etc.)
Compliance Responsibilities
- Swipelux: KYC, sanctions, PEP screening, wallet screening, blockchain execution
- Sub-merchant: marketing compliance, UX geoblocking, sector-specific licensing
Supported Verticals
We strictly categorize business into three risk tiers.
OK/Allowed
- E-commerce & SaaS: Payments for goods/services
- Web3 Infrastructure: Non-custodial UI
- Other instruments that leverage blockchain technology on the UX/UI level
Conditional (Enhanced Due Diligence)
- Licensed Gambling: Must hold valid license (e.g. local authorizations on the target markets)
- Trading/CFD: Must hold a financial investment license
- Wallet Orchestrators: Must prove non-custodial status. UX/UI based
Prohibited (Rejected)
- Unlicensed Gambling: Any wagering without license
- Adult Content: Pornography or sexually explicit services
- Privacy Coins/Mixers: Monero, Tornado Cash, or obfuscation tools
- Shell Entities: Entities with no physical presence
- Sanctioned jurisdictions: Material exposure to sanctioned countries, regions and individuals
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*, Türkiye*, 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 | ✔ | ✔ | No | Allowed |
| Bhutan | N/A | ✔ | ✔ | No | Allowed |
| Maldives | N/A | ✔ | ✔ | No | Allowed |
| India | N/A | ✔ | ✔ | No | Allowed |
| Sri Lanka | N/A | ✔ | ✔ | No | Allowed |
| Brunei | N/A | ✔ | ✔ | No | Allowed |
| Cambodia | N/A | ✔ | ✔ | No | Allowed |
| Indonesia | N/A | ✔ | ✔ | No | Allowed |
| Malaysia | N/A | ✔ | ✔ | No | Allowed |
| Philippines | N/A | ✔ | ✔ | No | Allowed |
| Thailand | N/A | ✔ | ✔ | No | Allowed |
| Singapore | N/A | ✔ | ✔ | No | Fully Supported |
| Vietnam | N/A | ✔ | ✔ | No | Allowed |
3. LATAM
| Country (LATAM End-User) | Open Banking | Cards | Crypto Rails | Licensing Required? | Final Support |
|---|---|---|---|---|---|
| Argentina | N/A | ✔ | ✔ | No | Allowed |
| Bolivia | N/A | ✔ | ✔ | No | Allowed |
| Brazil | N/A | ✔ | ✔ | No | Allowed |
| Chile | N/A | ✔ | ✔ | No | Allowed |
| Colombia | N/A | ✔ | ✔ | No | Allowed |
| Costa Rica | N/A | ✔ | ✔ | No | Allowed |
| Dominican Republic | N/A | ✔ | ✔ | No | Allowed |
| El Salvador | N/A | ✔ | ✔ | No | Allowed |
| Guatemala | N/A | ✔ | ✔ | No | Allowed |
| Honduras | N/A | ✔ | ✔ | No | Allowed |
| Belize | N/A | ✔ | ✔ | No | Allowed |
| Mexico | N/A | ✔ | ✔ | No | Allowed |
| Panama* | N/A | ✔ | ✔ | No | Allowed |
| Paraguay | N/A | ✔ | ✔ | No | Allowed |
| Peru | N/A | ✔ | ✔ | No | Allowed |
| Uruguay | N/A | ✔ | ✔ | No | Allowed |
4. EMEA
| Country / Sub-Region | Open Banking | Cards | Crypto Rails | Local Licensing Required? | Final Status |
|---|---|---|---|---|---|
| Albania | N/A | ✔ | ✔ | No | Allowed |
| Andorra | N/A | ✔ | ✔ | No | Allowed |
| Israel | N/A | ✔ | ✔ | No | Allowed |
| Gibraltar | N/A | ✔ | ✔ | No | Allowed |
| Georgia | N/A | ✔ | ✔ | No | Allowed |
| UAE | N/A | ✔ | ✔ | No (VARA not triggered by orchestration) | Allowed |
| Saudi Arabia | N/A | ✔ | ✔ | No | Allowed |
| Qatar | N/A | ❌ | ❌ (crypto banned) | N/A | Not Allowed |
| Jordan | N/A | ✔ | ✔ | No | Allowed |
| Kenya | N/A | ✔ | ✔ | No | Allowed |
| South Africa | N/A | ✔ | ✔ | No | Allowed |
| Nigeria | N/A | ✔ | ✔ | No | Allowed |
| Morocco | N/A | ✔ | ✔ | No | Allowed |
| Algeria | N/A | ✔ | ❌ (crypto restricted) | Yes | Allowed – No Crypto |
| Turkey | N/A | ✔ | ✔ | No | Allowed |
5. Sanctioned / Not Supported
| Country | OB | Cards | Crypto | Final |
|---|---|---|---|---|
| Russia | ❌ | ❌ | ❌ | Not Supported |
| Belarus | ❌ | ❌ | ❌ | Not Supported |
| Iran | ❌ | ❌ | ❌ | Not Supported |
| Syria | ❌ | ❌ | ❌ | Not Supported |
| North Korea | ❌ | ❌ | ❌ | Not Supported |
| Cuba | ❌ | ❌ | ❌ | Not Supported |
| Venezuela | ❌ | ❌ | ❌ | Not Supported |
| Yemen, Sudan, South Sudan | ❌ | ❌ | ❌ | Not Supported |
| Haiti, Nicaragua | ❌ | ❌ | ❌ | 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.
End-User Identity Verification (KYC)
Swipelux mandates identity verification for all users interacting with the Orchestration flow. We offer two integration paths.
Path A: Standard KYC (Swipelux Hosted)
- Workflow: User is redirected (or sees an iframe) where Swipelux collects ID, Selfie, and Liveness data directly
- Best Value For: Sub-merchants who do not want to handle PII or do not have their own KYC solution
- Liability: Swipelux assumes full liability for verification
Path B: Sub-Merchant Reliance (Import KYC)
- Available only to regulated partners (Banks, Fintechs, etc)
- Workflow: Sub-merchant verifies the user in their own UX/UI. Merchant transmits verified PII (Name, DOB, Address, Doc ID) via secure API to Swipelux
- Requirement: Sub-merchant must hold a license in an equivalent jurisdiction (EU, UK, etc.) and pass a compliance audit
- Screening: Swipelux performs independent Sanctions/PEP screening on the data but does not re-collect documents from the user
Data Protection
Sub-merchants do not access user compliance data; all PII and documents remain in Swipelux's secure environment.
Wallet Architecture and Payouts
Swipelux utilizes a segregated wallet infrastructure.
Custodial MPC Wallets
- Structure: Every user session is assigned a segregated MPC wallet address managed by Swipelux
- Function: Holds stablecoins post-conversion or pre-payout
- Disclaimer: Swipelux does not pay yield on stablecoin balances held in custody
Non-Custodial Payouts (Self-Custody)
- Support: Users may withdraw stablecoins to verified personal wallets (e.g., MetaMask)
- Verification: Swipelux enforces ownership proof when accepting terms and conditions
- Restriction: We do not support payouts to unhosted wallets that fail blockchain risk screening resulted from internal tools
Payment Methods
Swipelux orchestrates multiple settlement rails.
Supported On-Ramp Methods
-
Fiat Deposits (User → Swipelux)
- Open Banking: Instant SEPA / Faster Payments
- Card Acquiring: Visa/Mastercard (subject to MCC restrictions)
-
Crypto Deposits (User → Swipelux)
- Users may deposit supported assets (USDC) directly into their segregated MPC wallet. All wallets are screening by a third party service provider
-
Third-Party Aggregators
- Swipelux supports orchestrated settlement from License third party partners. Swipelux acts as the wallet provider and final settlement agent in these flows
Supported Off-Ramp Methods
Fiat Payouts (Swipelux → User)
- Flow: Stablecoin → Swipelux Liquidity → Fiat Conversion → User Bank Account
- Rule: Payouts can only be sent to a bank account in the exact legal name of the verified KYC user. No third-party payouts
Merchant Onboarding (KYB)
Swipelux conducts KYB verification on all sub-merchants before activation.
Required Documentation
- Certificate of Incorporation / Registration
- Articles of Association
- Shareholder registry (showing all >20%)
- IDs + Proof of Address for UBOs >20%
- IDs for directors
- Business model explanation + flow-of-funds diagram
EDD Triggers
- High-risk jurisdictions
- High-risk verticals (gaming, trading)
- Complex ownership structures
Outcome: KYB approval, conditional approval with caps, or rejection
Travel Rule Compliance
Compliance with FATF Recommendation 16 for transfers > on local threshold.
- VASP-to-VASP: Swipelux identifies the counterparty VASP and transmits Originator/Beneficiary data via protocol (TRISA/Notabene)
- Unhosted Wallets:
- (a) Swipelux collects required Originator/Beneficiary information
- (b) No data is transmitted since no receiving VASP exists
- (c) Transfers may be blocked if blockchain analytics indicate high-risk exposure
Screening and Monitoring
Swipelux performs continuous AML/CTF monitoring:
- Sanctions/PEP: Daily screening + event-triggered screening (on signup, on changes)
- Blockchain Analytics: Every deposit/withdrawal screened for exposure to mixers, darknet markets, sanctioned entities
- Transaction Monitoring: Real-time detection of structuring, velocity anomalies, fraud patterns
- Case Escalation: High-risk alerts undergo manual review and may result in SAR/ISR filings
Governance and Roles
Liability Matrix
| Responsibility | Swipelux (VASP) | Sub-Merchant |
|---|---|---|
| Crypto Custody | 100% Responsible | Not-allow |
| Blockchain Execution | 100% Responsible | Not-allow |
| User Verification (KYC) | Responsible (Direct or Reliance) | Responsible for UX Handoff |
| Sanctions Screening | Responsible (All Users) | Responsible for own staff |
| Geoblocking | Enforces via IP/KYC | Must implement at UI level |
| Licensing | VASP License only | Sector License (e.g., Gaming) |
Responsibility Matrix
- Swipelux: custody, blockchain execution, KYC/KYB, monitoring, Travel Rule, sanctions
- Sub-merchant: user journey design, geoblocking, vertical licensing, marketing compliance, prevention of unsolicited US targeting
Swipelux is the only regulated crypto custodian in the flow. Sub-merchants never hold, control, or access user assets or private keys.
Auditability & Retention
Swipelux retains user identity and transactional data for 5 years, as required under EU AML laws and Estonia's MLTFPA.
Data subject deletion requests do not apply to AML-mandated records.
Swipelux stores all data within compliant EU infrastructure aligned with GDPR.