Security at TradersFlow

Security is treated as an engineering discipline, not a checkbox. Every change to TradersFlow goes through code review with security considerations. We follow the principle of least privilege across our codebase and infrastructure.

• Secure-by-default configuration for every new service and table.
• Automated dependency scanning to catch vulnerable libraries early.
• Secrets stored in a managed vault — never in code, never in logs.
• Role-based access controls on all internal admin tooling.

TradersFlow runs on hardened cloud infrastructure (Supabase on AWS) in EU regions, with Cloudflare in front for DNS, edge networking and DDoS protection. Our hosting partners maintain SOC 2 Type II and ISO 27001 certifications and operate physically secured data centres with 24/7 monitoring.

Application traffic is served over HTTPS only. Insecure HTTP requests are automatically upgraded. We enforce HSTS, modern TLS ciphers, and a strict Content Security Policy.

All customer data is encrypted at rest using AES-256 and in transit using TLS 1.3. Database access is locked down with row-level security so a query for one user can never return another user's data — even in the event of an application bug.

Uploaded photos and documents are stored in isolated, per-account buckets with signed URLs that expire automatically. Passwords are never stored in plain text — only as salted, modern cryptographic hashes.

Every request to a protected resource is checked on the server against the authenticated session — we never rely on hiding UI as a security measure. Database row-level security and server-side permission checks both have to pass before any read or write is allowed.

Optional sign-in with Google delegates authentication to a provider with a strong, mature security model, including support for hardware-backed multi-factor authentication. Suspicious sign-in attempts are rate limited by our authentication provider. You can sign out from your account settings at any time, and you can permanently delete your account and data from Settings → Account & Data.

Subscription billing is powered by Google Play Billing, with RevenueCat, Inc. as our subscription management layer. Card details are entered directly into Google Play — they never touch our servers. We only store a Google Play purchase reference and a high-level subscription status.

Subscription state — active, trialing, past-due, cancelled — is reconciled from Google Play and RevenueCat via signed webhooks (see next section), so what you see in the app reflects what Google Play holds. Invoice payments to you are made by your customers directly by bank transfer; TradersFlow never holds or processes customer funds.

TradersFlow processes webhook events from Google Play and RevenueCat for subscription updates. Every incoming webhook is verified against its signing secret before any business logic runs. Unsigned, expired or tampered events are rejected. Processed events are logged so we can reconcile any discrepancy and detect duplicates.

The TradersFlow admin area (used for support, billing operations and platform analytics) is restricted to a small, hardcoded allow-list of TradersFlow owners. Access is enforced server-side on every request — not only in the UI. Non-owners attempting to reach an admin route receive a 403.

Sensitive admin actions — generating a temporary sign-in link, issuing a refund, suspending or reinstating an account, extending a trial, exporting reports — are protected behind explicit confirmation and recorded in the audit log described below.

Administrative actions are written to an immutable audit log that records who did what, against which account, and when. The same approach extends to security-relevant events on your account — sign-ins, password and email changes, subscription state changes and deletions — so we can investigate anything unexpected.

Every transactional email TradersFlow sends — verification, password reset, trial reminders, invoices, payment notices — is logged with its template, recipient, send status and downstream events (delivered, opened, clicked, bounced, complained, unsubscribed). We use these signals to retry failed sends, prevent duplicates, respect suppression lists, and alert ourselves if the overall failure rate exceeds a healthy threshold.

Our systems are monitored with automated alerts on errors, latency spikes, failed webhooks, email delivery health and security events, and we review these alerts as part of running the service. Account activity is logged for fraud prevention and incident review. We aim for high availability but do not offer a contractual uptime guarantee or service-level agreement.

We have a documented incident response plan covering detection, containment, eradication, recovery and post-incident review. If an incident affects your data, we will notify you without undue delay — and, where GDPR requires, within 72 hours of becoming aware.

If you're a security researcher and have found a vulnerability, we'd like to hear from you. Please email security@tradersflow.co.uk with details and we aim to acknowledge within 5 working days.

We commit to: investigating in good faith, keeping you updated, and not taking legal action against researchers who follow this policy and act in good faith. Please don't access data that isn't yours and don't disrupt the Service for other users.

For anything security-related — questions, concerns, vulnerability reports — email security@tradersflow.co.uk.