Is my personal data safe?
Sensitive data is encrypted at rest; neither support nor admin interfaces can view full card numbers.
'Is my data safe?' — the question as phrased carries no information; you have to break it apart before you can verify anything. Personal data security is really three independent questions: what information the platform collects about you, who can see that information and under what conditions, and what form it is stored in. If any one of the three links is loose, it isn't safe. Below we take them apart link by link, and you can use this framework to measure any comparable platform.
Here is a counterintuitive conclusion up front: the hardest layer of privacy protection is not the encryption algorithm, but 'collecting less.' The more sensitive information a platform holds, the larger your exposure once there is a leak. Our approach is the opposite: identity data is collected under the minimum-necessary principle and used only for card-issuer compliance, preventing duplicate registrations and risk control (logging in additionally needs an email and password, which are functional credentials every website requires and are not part of your identity information). The less that is collected, the smaller the surface that can leak — this is the lowest-cost and most thorough form of protection.
Basic Data Items Collected, at a Glance
| Data Item | Category | Collected? | Purpose / Notes |
|---|---|---|---|
| Account credential | Yes (at registration) | Used as the login account and to receive verification codes | |
| Password | Account credential | Yes (at registration) | Stored as an irreversible hash; no plaintext is kept |
| ID details (document type and number, name, date of birth, nationality, expiry date, address on the document) | Identity data | Yes (once, before your first card) | Card-issuer compliance, preventing duplicate registrations and risk control; the document number and address are stored encrypted |
| ID photos and a face photo | Identity data | Yes (once, before your first card) | Confirms the ID is yours; stored privately with an off-site backup, and viewing requires a second admin verification and is logged |
The key to reading this table is to separate two categories: email and password are account login credentials — functional items that let you sign in and receive verification codes, not your identity data; identity data is collected once, before your first card, by a third-party identity verification provider on the verification page; we follow the minimum-necessary principle and use it only for card-issuer compliance, preventing duplicate registrations and risk control. When we say 'minimum necessary,' we mean exactly this identity-data scope, not that login credentials are counted in as well.
The Same Piece of Data Is Visible at Different Granularity to Different Roles
After shrinking the collection scope, the second line of defense is access control. The principle is simple: the full card number belongs to you alone, internal access follows a least-privilege 'granted only when needed' rule, and every retrieval of sensitive information leaves a traceable record.
| Viewing Scenario | Visible Granularity | Constraints |
|---|---|---|
| You view your own card details | Full card number shown directly; expiry and CVV shown after verification | Viewing the expiry and CVV requires passing two-step verification first |
| Support helps troubleshoot | Cannot see the full card number (masked) | Masked at the interface layer; support cannot retrieve it |
| Admin retrieves sensitive information | Retrievable only when genuinely needed | One-time passcode + mandatory audit log |
The audit log is easy to overlook, yet it is the crucial one: it turns 'whether it can be viewed' into 'whoever views it is accountable' — who, at what time, retrieved what is recorded throughout and auditable afterward, so internal overreach cannot happen quietly. Layered on top with the one-time passcode required for admin retrieval, sensitive information cannot be viewed on a whim; every single access is logged and carries accountability.
Encrypted Storage of Sensitive Data Is the Default, Not an Add-On
Being authorized to view something does not mean it sits in the database as-is. The full card number and CVV are never stored at all: when you view them, the system fetches them in real time from the card issuer and returns them straight to your browser, and the database keeps only the last four digits; sensitive fields that do need to be stored, such as ID numbers and addresses, are encrypted with AES-256-GCM, and passwords are stored as irreversible hashes. Even if someone reaches the storage layer without authorization, what they obtain is ciphertext rather than directly usable raw data. At this point all three layers of protection are stacked: collect little (identity data on a minimum-necessary basis), hard to view (role-tiered authorization), and even what is viewed is ciphertext (encrypted storage) — if any single layer falls, the other two still catch it.
Data Leaves the Platform Only at Two Necessary Steps: Identity Verification and Card Issuing
When you care about data security, beyond who can see it inside the platform, there is one layer easy to miss: whether it flows outside. Here we state the boundary honestly. Your data leaves the platform in only two places: during identity verification, the ID and face images you capture are collected and checked by a third-party identity verification provider, which returns the result and the ID details to us; and when a card is issued, cardholder identity information (name, ID details and so on) is provided to the licensed card issuer as its compliance rules require, for issuance and compliance review. Beyond that, nothing is shared with other third parties, and user data is never sold. The smaller the collection scope, the smaller the surface that can be exposed outward — the minimum-necessary principle holds equally for outbound flows.
You Can Verify These Points Yourself, Not Just Take Our Word
- Registration: the whole process needs only email, verification code, and password.
- When you verify your identity before your first card: what is collected should match what the privacy policy lists (ID details, ID photos and a face check), and it happens only once.
- When viewing the CVV: watch whether two-step verification is triggered — you should be wary only if the verification that ought to appear does not.
- When contacting support: ask the agent to read out your full card number; under normal circumstances they cannot, because it is masked in the interface.