Security is the baseline of RDVCC Virtual Card, not a marketing line

We take no shortcuts with users' identity data, card numbers or funds ledgers. Below is what we actually do today, not vague promises.

Encryption

✓Standard double-entry bookkeeping: assets + expenses = liabilities + equity + revenue
✓PostgreSQL BEFORE INSERT trigger enforces debit-credit balance
✓user_balance trigger forbids negative values (prevents over-deduction)
✓Real-time reconciliation on the admin dashboard, automatic alerts on fund drift
✓Daily automatic reconciliation of sub-accounts + card limits + ledger integrity
✓Account balance refundable to USDT on request anytime; on-chain fees covered by the platform

✓Upstream licensed issuers
✓Cardholder information completed before card issuance (compliance requirement)
✓Cash-out / prohibited industries / grey business / money laundering strictly forbidden (violations frozen immediately)
✓On-chain top-up addresses that hit blacklists are blocked immediately
✓We cooperate with lawful law-enforcement investigation requests

✓Tamper-proof audit logs for all admin actions (reason required)
✓Sensitive user actions (password change, KYC submission, card close) written to user_activity_log
✓Full logs of upstream API calls (api_logs table)
✓Audit logs kept 18 months, KYC 5+ years, transactions 7 years

The platform covers 80%; do these last 5 things and your account will rarely run into trouble.

Use a password of 8+ characters mixing letters, digits and symbols; don't reuse it across sites;
Use your primary email (no throwaway email) — 3DS codes are delivered there;
Enable 2FA (once it launches);
Split cards by use: separate cards for ad accounts / subscriptions / overseas shopping to reduce single-point risk;
Support will never ask for your password / OTP / card number — anyone who does is a scammer.

If you find any security vulnerability, privacy issue or compliance risk in RDVCC Virtual Card, please report it via [email protected]. We promise:

RDVCC's data storage uses a three-tier "primary / replica / backup" architecture, balancing availability, disaster recovery and compliance:

Primary: PostgreSQL 16 on a Hong Kong CN2 node. Sustains 100+ tps writes, AES-256-GCM field-level encryption.
Read replicas: one on the same node + one off-site. Used for reporting and reconciliation, reducing primary load.
Encrypted backups: automatic daily backups to cloud storage, kept off-site for 90 days + monthly archives for 5 years. Backup files are encrypted separately (keys independent from the primary), so even a cloud-storage breach cannot decrypt them.
RTO / RPO: target RTO ≤ 4 hours (disaster recovery), RPO ≤ 15 minutes (maximum data loss). A full disaster-recovery drill every quarter.

Platform security is only part of the picture — user-side practice matters just as much. We strongly recommend:

① Enable 2FA (two-step verification). Account Settings → Security → enable TOTP verification (Google Authenticator / Authy). Once on, an attacker cannot log in even with a leaked password.
② Use a strong password + never reuse it. Your RDVCC password should differ from your passwords elsewhere. Use a password manager (1Password / Bitwarden) to generate 16+ character random passwords.
③ Set an independent limit per card. Set daily / monthly limits at 1.2× your actual budget. Even if a card number leaks, losses stay capped.
④ Review transactions regularly. Check your in-account transaction details weekly; on anything unusual, freeze the card immediately and contact support.
⑤ Beware of phishing. RDVCC will never ask for your password / SMS code via email / SMS. The only login entry is rdvcc.com — verify the URL and the HTTPS certificate.

1 USDT per card · field-level encryption · 7-year audit retention