Ticpoz Back to site

Security

What we do to protect your account, your broker credentials, and your trading data. Plain English. Implementation-level detail is available to enterprise customers under NDA.

Last updated · May 2026
The product reality
TICPOZ never holds your money. Your funds stay at your broker; we route orders, not deposits. The threat model below covers (a) your account on our platform, (b) the broker connection tokens we hold on your behalf, and (c) your strategy and trade data — not custody of capital.

1. Threat model

We design against four categories of threat, roughly in the order we worry about them:

Credential theft
Attackers stealing user passwords or broker connection tokens — by phishing, by data-store compromise, or by intercepting in-flight traffic.
Account takeover
Once an attacker has credentials, they try to log in, place trades, or exfiltrate strategy IP.
Insider risk
Anyone with operational access misusing privileges — accidentally or deliberately.
Supply-chain risk
A dependency or third-party service getting compromised and the blast radius reaching us.

2. Authentication

Passwords

We never store or transmit your password in plaintext. Passwords are protected with a modern, memory-hard password-hashing function that is intentionally expensive for attackers to brute-force even with GPU clusters. Each user has a unique random salt; the hash also incorporates a server-side secret kept outside the data store, so a stolen data export alone cannot be brute-forced offline.

Session tokens

Sessions are signed, time-limited tokens. Browser sessions expire on a 30-day cycle; internal worker-to-API tokens expire in minutes. Logging out invalidates the active token. The signing secret rotates on deployment.

Two-factor authentication

Time-based one-time-password (TOTP) 2FA — compatible with Google Authenticator, 1Password, Authy, and others — is available on every account. We strongly recommend enabling it, particularly if you have a broker connected. Recovery codes are provided at setup; lose them and we cannot recover the account beyond standard identity-verification.

3. Broker credentials

Broker connections are the most sensitive data we hold — whoever has them can place orders on your account.

cTrader (OAuth)

We use the cTrader Open API OAuth flow. You authenticate on the broker's own login page; we never see your broker username or password. The broker returns a short-lived access credential and a refresh credential which we encrypt and store. We can revoke a connection at any time; you can revoke it from cTrader's own settings page too.

MetaTrader 5 (signed bridge)

For MT5 brokers, you install a code-signed component that opens a local API channel. The bridge authenticates to our backend with a per-bridge credential (also encrypted at rest). We do not store your MT5 login.

Encryption at rest

Every secret we keep on your behalf — broker access & refresh tokens, MT5 API credentials, integration keys you optionally provide — is encrypted with a strong, modern symmetric cipher before it touches disk. Each record uses a unique initialisation vector. The decryption key is held outside the data store and is loaded only by services that need to decrypt at the moment of use. A stolen data export by itself is opaque.

4. Per-user dedicated outbound IPv4

Every paying user is allocated a dedicated, routable IPv4 address bound exclusively to their broker traffic. This gives three security and compliance properties:

  • Prop-firm compliance. Prop firms commonly flag accounts that share an outbound IP as suspected collusion. Each user's broker traffic egresses from a unique address, eliminating that flag.
  • Isolation. A network-level abuse from one user's strategy cannot blacklist another user's connection.
  • Auditability. Broker-side logs at your broker show one consistent source IP for your account — easier to reconcile.

Addresses are released automatically when a user account is closed, through a careful two-phase teardown that ensures we never leak an unused or stale address. Administrators can audit for orphaned allocations from the admin panel.

5. Transport security

  • All public traffic is TLS 1.3 (1.2 minimum). HSTS is enabled.
  • Public-facing HTTPS is fronted by a tier-1 edge network with DDoS protection. The origin is firewalled to only accept connections from that edge.
  • Origin-to-broker connections use TLS with hostname verification.
  • Internal service-to-service calls use loopback or a private network — they never cross the public internet.

6. Admin access & audit

  • The admin panel is locked to an IP allowlist. Visitors not on the list see a 404 — the panel does not reveal its own existence.
  • Admin login requires a separate password (independent from user passwords), with rate-limit lockout after repeated failed attempts.
  • Every admin action — user pause, plan change, deletion, address release — is recorded in an append-only audit log with admin identity, target, timestamp, source IP, user-agent, and full payload.
  • Admins cannot delete themselves, demote themselves, or block themselves — anti-lockout protection.
  • Permanent user deletion requires an explicit confirmation token in the request — accidental misclicks cannot destroy data.

7. Infrastructure

Compute
Production runs on tier-1 cloud infrastructure with redundant regions in the EU and US. Processes are supervised and auto-restart on failure.
Edge / CDN
Public traffic is fronted by a global edge network providing DDoS protection, TLS termination, and a web-application firewall.
Data storage
Customer data lives on a private volume with locked file permissions. No public network exposure. Backed up on a regular schedule with encrypted off-site copies.
AI inference
The AI builder relies on best-in-class language models accessed through a server-side API. Prompts are scrubbed of personal identifiers before transit; we never send your password, broker tokens, or account identifiers to any AI provider.
Payments
Payment processing is handled by a PCI-DSS Level-1 certified payment provider. We never touch your card number; the provider handles PCI-DSS obligations on our behalf.
Email
Transactional email (verification, password reset, billing) is sent through a reputable transactional-email provider. Marketing email only if you opt in.

8. Responsible disclosure

We welcome security reports from independent researchers. Findings are triaged, patched, and credited (with your permission) in our public changelog.

Email
[email protected]
security.txt
/.well-known/security.txt — machine-readable contact
Triage SLA
Initial response within 72 hours, validated severity within 7 days, fix or mitigation within 30 days for critical or high findings.
Out of scope
Social-engineering attacks against support, physical attacks, denial-of-service that simply floods the public site, vulnerabilities in third-party services that are their responsibility.
Bug bounty
A formal bug-bounty programme is on the roadmap. Until then, exceptional findings receive case-by-case reward at our discretion.
What we ask of researchers
Don't exfiltrate or modify other users' data. Use test accounts (you can self-register). Don't degrade service availability for other users. Don't publicly disclose a finding until we have had reasonable time to respond — typically 90 days from initial report. We commit to not pursuing legal action against good-faith researchers who operate within those bounds.

9. Enterprise vendor reviews

Enterprise / Desk-tier customers (and any procurement team running a vendor-security review) can request a more detailed security pack under NDA. The pack covers our implementation choices, key-management posture, sub-processor controls, and incident-response playbook. Email [email protected] to start that process.

10. Changes to this page

We treat this page as living documentation of the platform's actual security posture, not a marketing artefact. We update it whenever a meaningful change shifts the answer. Material changes get a note in /changelog.

11. Questions