Swipelux

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 IncorporationEnd-User LocationStatusNotes
USAUSANot AllowedWe do not hold US Money Transmitter Licenses
USAGlobal* / EU / UKAllowedSub-merchants must strictly geoblock US IP addresses
EU / EEAUSANot AllowedSwipelux cannot service US residents or citizens
EU / EEAGlobal* / EU / UKAllowedStandard flow
UK / CanadaGlobal* / EU / UKAllowedStandard flow
APAC / LATAMGlobal* / EU / UKAllowedStandard flow (e.g. India, Brazil)
Any JurisdictionProhibited ListNot AllowedSanctions screening applies to all users

Sub-merchant Jurisdictional Matrix

1. EEA+UK+CH

End-User RegionOpen BankingCardsCrypto RailsLocal Licensing Required?Final Status
EEAYesYesYesNoFully Supported
UKYesYesYesNoFully Supported
SwitzerlandN/AYesYesNoFully Supported

2. APAC

Country (APAC End-User)Open BankingCardsCrypto RailsLocal Licensing ImpactFinal Support
TaiwanN/ANoAllowed
BhutanN/ANoAllowed
MaldivesN/ANoAllowed
IndiaN/ANoAllowed
Sri LankaN/ANoAllowed
BruneiN/ANoAllowed
CambodiaN/ANoAllowed
IndonesiaN/ANoAllowed
MalaysiaN/ANoAllowed
PhilippinesN/ANoAllowed
ThailandN/ANoAllowed
SingaporeN/ANoFully Supported
VietnamN/ANoAllowed

3. LATAM

Country (LATAM End-User)Open BankingCardsCrypto RailsLicensing Required?Final Support
ArgentinaN/ANoAllowed
BoliviaN/ANoAllowed
BrazilN/ANoAllowed
ChileN/ANoAllowed
ColombiaN/ANoAllowed
Costa RicaN/ANoAllowed
Dominican RepublicN/ANoAllowed
El SalvadorN/ANoAllowed
GuatemalaN/ANoAllowed
HondurasN/ANoAllowed
BelizeN/ANoAllowed
MexicoN/ANoAllowed
Panama*N/ANoAllowed
ParaguayN/ANoAllowed
PeruN/ANoAllowed
UruguayN/ANoAllowed

4. EMEA

Country / Sub-RegionOpen BankingCardsCrypto RailsLocal Licensing Required?Final Status
AlbaniaN/ANoAllowed
AndorraN/ANoAllowed
IsraelN/ANoAllowed
GibraltarN/ANoAllowed
GeorgiaN/ANoAllowed
UAEN/ANo (VARA not triggered by orchestration)Allowed
Saudi ArabiaN/ANoAllowed
QatarN/A❌ (crypto banned)N/ANot Allowed
JordanN/ANoAllowed
KenyaN/ANoAllowed
South AfricaN/ANoAllowed
NigeriaN/ANoAllowed
MoroccoN/ANoAllowed
AlgeriaN/A❌ (crypto restricted)YesAllowed – No Crypto
TurkeyN/ANoAllowed

5. Sanctioned / Not Supported

CountryOBCardsCryptoFinal
RussiaNot Supported
BelarusNot Supported
IranNot Supported
SyriaNot Supported
North KoreaNot Supported
CubaNot Supported
VenezuelaNot Supported
Yemen, Sudan, South SudanNot Supported
Haiti, NicaraguaNot 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:

  1. Local regulations governing crypto transactions and fiat on/off-ramp activity
  2. Card scheme and acquiring-bank restrictions
  3. Sanctions and AML/CTF obligations
  4. 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

  1. Fiat Deposits (User → Swipelux)

    • Open Banking: Instant SEPA / Faster Payments
    • Card Acquiring: Visa/Mastercard (subject to MCC restrictions)
  2. 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
  3. 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

ResponsibilitySwipelux (VASP)Sub-Merchant
Crypto Custody100% ResponsibleNot-allow
Blockchain Execution100% ResponsibleNot-allow
User Verification (KYC)Responsible (Direct or Reliance)Responsible for UX Handoff
Sanctions ScreeningResponsible (All Users)Responsible for own staff
GeoblockingEnforces via IP/KYCMust implement at UI level
LicensingVASP License onlySector 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.