Your data. Your clients.
Under lock and key.
IBHQ stores Telegram session keys, lead contact details, and payment history for thousands of introducing brokers. We take that seriously. Here's exactly what we do — and what we don't.
Encryption at rest & in transit
All traffic is TLS 1.3. Telegram session keys, API keys, and tokens are encrypted with Fernet (AES-128-CBC + HMAC-SHA256) before hitting the database.
Tenant isolation
Every row in every table is scoped by tenantId. Queries are tenant-aware. Cross-tenant access is impossible by construction, not by convention.
GDPR & data portability
Export everything you've put in. Delete everything on request. Data stored in EU datacentres by default, with US residency available on request.
How we handle Telegram credentials
- API ID, API Hash, and session strings are encrypted with a per-deployment Fernet key before insertion — the database never sees plaintext credentials.
- The encryption key is held in environment variables, never committed, and rotated on a quarterly cadence.
- Session strings are decrypted into memory only inside the listener process, and only for the duration needed to start a client.
- Disconnect a Telegram account and the session is revoked and the encrypted blob deleted within seconds.
Lead and contact data
- Lead records live in isolated tenant-scoped tables. No IBHQ team member can query across tenants without explicit, logged access.
- Contact data is never shared, sold, resold, or used to train any model.
- Export your full lead database — with activity history — as JSON or CSV, any time, with no throttle.
- On tenant deletion we hard-delete all lead and activity rows within 30 days, and verify backups no longer retain them within 90.
Infrastructure
- Primary deployment: Frankfurt (EU). US region available for enterprise tenants.
- PostgreSQL 16 with automated daily backups, retained 30 days, encrypted at rest.
- Redis for session state and queues — no persistent customer data beyond 24 hours.
- TLS termination at Caddy with automatic renewal. HTTPS-only, HSTS enabled, no weak ciphers.
Operational security
- Every deployment runs through CI with lint, typecheck, and build gates — no unchecked code reaches production.
- Database migrations are reviewed before merge and recoverable via point-in-time backup.
- Production access is restricted to SSH keys on hardware tokens, with 2FA on every critical account.
- All admin actions are logged to an append-only audit trail — deletions, exports, and role changes reviewable forever.
Incident response
- Tenants are notified within 4 hours of any confirmed breach affecting their data (GDPR Article 33).
- Post-incident reports are published publicly on the changelog for any severity-1 incident, anonymised where needed.
- We do not silently patch security issues; fixes are disclosed in the changelog, with credit to the reporter.
The things you shouldn't have to ask about.
- ✕We don't sell your data.No ad networks, no third-party trackers, no "partners" with your lead list. The business model is your subscription.
- ✕We don't log plaintext passwords or tokens.Passwords are bcrypt-hashed. API tokens and Telegram sessions are Fernet-encrypted. Debug logs redact these fields by default.
- ✕We don't train AI on your data.Lead contents, signal messages, and conversation history are never forwarded to any model provider for training — only for the per-tenant inference you initiated.
- ✕We don't store card data.Because we don't accept cards. USDT on TRC-20 only — the only thing we store is the on-chain tx hash and amount.
Found a vulnerability?
Responsible disclosure is welcome. Email security@ibhq.io with steps to reproduce and we'll respond within 48 hours. Good-faith research will not result in legal action.