Privacy Policy
Overview
How MonaxPay Community Project processes personal data when operating MonaxPay.
Key facts
Controller and contact
The controller is MonaxPay Community Project, Community project. Privacy requests can be sent to mail@monaxpay.com.
No data protection officer is appointed. Data-protection communication is handled by MonaxPay Community Project at the address above.
Data categories
- Account and login data: email, password hash, TOTP status, recovery status, roles, team members, social-login IDs.
- Profile and merchant data: display name, logo, legal name, business purpose, countries, categories, support and billing information.
- KYC/KYB and risk data: identity details, document metadata, liveness/review results, sanctions, PEP, adverse-media, wallet, and prohibited-use signals.
- Payment and receipt data: link, amount, currency, asset, wallet, provider status, onchain signature, fees, net settlement, receipts, dispute and support status.
- Technical data: IP address, user agent, device/session data, security logs, CSRF/session identifiers, API usage, webhook and audit logs.
- Communications: emails, support requests, delivery evidence, and statutory notices.
Purposes and legal bases
| Purpose | Legal basis |
|---|---|
| Account, login, dashboard, wallet verification | Art. 6(1)(b) GDPR |
| KYC/KYB, risk, sanctions, fraud, prohibited-use checks | Art. 6(1)(b), (c), and (f) GDPR |
| Payment links, receipts, settlement, support, disputes | Art. 6(1)(b) and (f) GDPR |
| Accounting, tax, trade, and audit obligations | Art. 6(1)(c) GDPR |
| Security, abuse prevention, audit, legal defense | Art. 6(1)(f) GDPR |
| Google Analytics | Consent under Art. 6(1)(a) GDPR and § 25 TDDDG |
Providers and transfers
Providers can include Hostinger, Onramper and underlying payment/onramp providers, Google, Telegram, WalletConnect/Reown, Helius, OpenRouter, and email infrastructure.
MonaxPay chooses EU/Germany storage where possible. Some providers may process data outside the EEA where technically or contractually necessary; in those cases MonaxPay relies on appropriate safeguards such as SCCs, adequacy decisions, DPF certifications, DPAs, or comparable safeguards.
Provider and transfer matrix
The following matrix describes the provider classes used in production. Exact subprocessors and routing providers can vary by country, payment method, wallet, route, and provider decision.
| Provider | Role | Purpose | Data | Location/safeguard |
|---|---|---|---|---|
| Hostinger | Processor | Hosting, email, database, backups | Account, technical, email, audit, and backup data | EU/Germany where configured; DPA and technical safeguards |
| Onramper and connected onramp/payment providers | Independent controller or processor depending on route | Checkout, payment methods, provider KYC, fraud, disputes | Payment, identity, risk, provider, and transaction data | Provider-dependent; provider terms, DPA/SCC/DPF, or comparable safeguards |
| Independent controller/provider | Google Login and Google Analytics G-WFNYVEW258 after consent | Login claims, technical analytics events, device/usage data | EU/US possible; DPF/SCC and Google privacy notices | |
| Telegram | Independent provider | Telegram Login if selected | Telegram ID, profile/login claims, technical auth data | Third-country processing possible; provider terms and appropriate safeguards |
| WalletConnect/Reown | Independent provider/technical relay | Wallet connection, session relay, QR/deep link | Wallet address, connection metadata, device/relay data | Third-country processing possible; provider terms and appropriate safeguards |
| Helius | Processor/technical provider | Solana RPC, webhooks, onchain verification | Wallet addresses, transaction signatures, network metadata | US/EU possible; DPA/SCC/DPF or comparable safeguards |
| OpenRouter | Processor/technical provider when enabled | AI-assisted triage and quality control | Reduced or derived review data; no raw biometrics by default | Third-country processing possible; DPA/ZDR/SCC/DPF or comparable safeguards |
AI and automated review
Automated checks and AI-assisted triage may support document classification, fraud detection, and risk review. A live approval or rejection with legal or similarly significant effects is not made solely by an LLM; high-risk cases require manual admin or compliance review.
Raw identity documents, selfies, or biometric media are not sent to LLM providers by default.
Retention
| Data type | Typical retention |
|---|---|
| Session, CSRF, and short-lived technical data | Until session end or up to 180 days for security purposes |
| Account, wallet, profile, and security evidence | For the relationship and up to 6 years afterwards |
| KYC/KYB and risk evidence | Usually 5 years after the relationship, longer for dispute, duty, or risk |
| Receipts, accounting, ledger, fees, and audit logs | Up to 10 years under trade and tax retention rules |
| Support, dispute, and legal-defense records | Until resolved and then under limitation/evidence periods |
| Cookie/analytics consent | Up to 12 months or until withdrawn |
Data-subject rights
Data subjects have GDPR rights to access, rectify, erase, restrict, port, object, and withdraw consent. Withdrawal does not affect processing lawfully carried out before withdrawal.
Requests can be sent to mail@monaxpay.com. Deletion can be limited where retention, audit, fraud-prevention, dispute, tax, or legal-defense duties apply.
Supervisory authority
You may lodge a complaint with a data protection authority. The regular authority for MonaxPay Community Project is Der Hessische Beauftragte für Datenschutz und Informationsfreiheit, Postfach 3163, 65021 Wiesbaden, poststelle@datenschutz.hessen.de.
Security
MonaxPay uses role-based access, TOTP, signed sessions, CSRF protection, scoped API credentials, audit logs, access separation, encryption, backup processes, and security reviews. No system is absolutely secure; security incidents are handled under legal notification duties.