Is my personal data safe?
We collect the minimum necessary: name + phone only. No ID cards, passports or facial data. 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 'not collecting it at all.' The more sensitive information a platform holds — ID cards, passports, facial data — the larger your exposure once there is a leak. Our approach is the opposite: identity data is compressed down to the minimum set required for card-issuing compliance, name plus phone number, and we never touch documents or biometrics (logging in additionally needs an email and password, which are functional credentials every website requires and are not part of your identity information). Identity data that is never stored cannot be leaked — this is the lowest-cost and most thorough form of protection.
What We Collect and What We Don't, in One Table
| 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 in encrypted form; no plaintext is kept |
| Name | Identity data | Yes (before your first card) | Cardholder information; required for compliance at the card-issuing stage |
| Phone number | Identity data | Yes (before your first card) | Cardholder contact information |
| ID card / passport | Identity data | No | No document-based identity verification |
| Face / biometrics | Identity data | No | No liveness detection or facial recognition |
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; in the identity-data category, we follow the minimum-necessary principle and collect only name and phone number, and never touch documents, passports, or facial data. When we say 'only name + phone number,' 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 / expiry / CVV | Must pass 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. Sensitive fields such as passwords and card information are stored in encrypted form, not in plaintext; 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 (the smallest identity-data collection scope), 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 Flows to the Issuer Only at the Necessary Card-Issuing Compliance Step
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. Card issuing has to be completed on the issuer's side, so name and phone number, as cardholder information, need to be passed to the licensed card issuer to complete the issuance — this is a data flow required for card-issuing compliance. As for highly sensitive items like documents, passports, and facial data, we do not collect them in the first place, so naturally there is no question of such information flowing outward. 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 — there is no step to upload documents or scan your face.
- When completing your profile before card issuance: you are only asked to fill in name and phone number, never asked for an ID number, passport, or facial data.
- When viewing card details: 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.