Trust & Compliance

Security & Compliance Architecture

PredSouq is built for regulated financial operators. This document covers the security architecture, compliance controls, data handling, and audit capabilities available to every tenant.

Non-custodial
RLS tenant isolation
HMAC audit chain
Pen-test ready
Overview

Architecture

PredSouq is a multi-tenant SaaS platform. Each broker is a separate tenant with fully isolated data. The operator runs their own branded trader-facing app and retains control over their PSP, KYC provider, and trading ledger. PredSouq never touches end-user funds.

Trader (browser / app) Broker-branded app
hosted on broker's domain
PredSouq API
tenant-scoped, RLS enforced
Trader funds flow: broker's PSP only — PredSouq never appears on a payment receipt
Broker PSP (Stripe / custom) HMAC-verified webhook Ledger credit (tenant-isolated)
KYC flow: broker's existing provider, result posted via webhook
KYC provider (Sumsub / Onfido) HMAC-verified webhook KYC tier update + AML flag
Fund safety

Non-custodial by design

PredSouq is not a financial institution, does not hold a money services licence, and never holds, commingles, or transmits end-user funds. All deposits and withdrawals are processed by the operator's own PSP under the operator's own licence.

No commingling
Trader balances are ledger entries scoped to the operator's tenant. No pooled wallet, no PredSouq bank account.
PSP stays the operator's
The operator's Stripe (or custom PSP) account receives all deposits. PredSouq receives only a signed webhook confirming the amount.
Ledger reconciliation
Double-entry accounting enforced. A reconciliation endpoint verifies that all debits equal all credits to the cent — runnable on demand.
Treasury reconciliation
Live report comparing settled deposits (PSP) against ledger credits. Discrepancies are surfaced to the operator immediately.
Data isolation

Row-Level Security tenant isolation

Every table that contains tenant data is protected by Postgres Row-Level Security (RLS) policies enforced at the database layer. This is not application-level filtering — it is a database-enforced constraint. Even a compromised application layer cannot read another tenant's data.

RLS policies on every table with a tenant_id column — enforced at the Postgres layer
Application sets app.current_tenant session variable; all queries are automatically scoped
Server boot verifies RLS is enforced on all tables — startup fails if any table is missing its policy
API keys are scoped per-tenant — a key from tenant A cannot query tenant B's data even if the key is leaked
Auditability

Verifiable HMAC audit chain

Every ledger entry, trade, settlement, and operator action is recorded in an append-only audit log. Entries are HMAC-chained: each record includes the hash of the previous record. Any insertion, modification, or deletion of a historical record breaks the chain and is immediately detectable.

Append-only audit log
Every entry is immutable once written. The chain can be verified at any time via GET /v1/audit/status.
On-chain anchoring
The audit head hash can be anchored on a public blockchain. Third-party auditors can verify the chain independently without access to the database.
Actor attribution
Every action records who acted: staff ID + role, or system (seed / sweep / scheduled). No anonymous mutations.
Ledger conservation
POST /v1/reconcile verifies that the double-entry ledger sums to exactly zero. Runnable on demand or scheduled.
Compliance controls

AML & KYC workflow

The platform ships a complete AML lifecycle integrated into the operator console. Operators connect their existing KYC provider (Sumsub, Onfido, or custom) via a signed webhook — no migration required.

ControlDescription
KYC tiersConfigurable tiers (0 = unverified, 1 = basic, 2 = enhanced). Deposit and withdrawal limits are gated per tier.
KYC relay webhookProvider posts a signed result to /kyc/inbound/:tenantId. Signature verified before any update.
Pending review queueAccounts in "pending" KYC status are surfaced in the console for manual review and approval.
SAR / STR workflowOperator can file a Suspicious Activity Report or Suspicious Transaction Report from within the console. Lifecycle tracked with timestamps and operator ID.
Jurisdiction policyAllowlist of permitted jurisdictions enforced at account creation and deposit. US and OFAC-sanctioned jurisdictions are platform-level blocked and cannot be enabled.
Automated AML flaggingSurveillance engine flags abnormal stake size (z-score), velocity bursts, insider timing, and unusual deposit patterns. Flags are reviewed in the console's compliance panel.
Compliance controls

Sanctions & adverse media screening

The platform integrates with World-Check, ComplyAdvantage, or any compatible sanctions screening provider via a signed webhook relay. Screening runs on user creation and on a configurable schedule (daily / weekly).

Screening on user creation — new accounts are checked before deposits are accepted
Scheduled re-screening — existing accounts can be re-screened on a configurable cadence
Hit outcomes: clear (no match), review (possible match — manual review), blocked (confirmed match — account frozen)
Fails safe — if the screening provider is unreachable, outcome defaults to "review" (not "clear")
US + OFAC-sanctioned jurisdictions are platform-enforced blocks — operators cannot whitelist them
Staff security

Access control & staff authentication

Staff access is role-based. Sensitive operations require step-up authentication. All staff actions are attributed in the audit chain.

RolePermissions
ownerFull access including staff management, policy write, and settlement. Required step-up for destructive actions.
adminFull operational access. Cannot manage other staff accounts.
supportRead access + withdrawal approval. Cannot create markets or modify policy.
api key (admin)Programmatic full access. Used for backend integrations. Scoped to one tenant.
api key (public)Read-only market data and trader-facing operations. Cannot access reports or compliance data.
TOTP 2FA enforced for all staff accounts (configurable as mandatory in policy)
Step-up authentication required for: market settlement, kill-switch, audit anchoring, policy write
Login lockout after 10 failed attempts with exponential backoff
Session tokens rotated on each request (sliding expiry). Sessions invalidated on password change.
Data handling

Data storage & residency

All data is stored in a managed Postgres database. The region is configurable at contract time. Enterprise tenants receive a dedicated database instance with Point-In-Time Recovery enabled.

ItemDetail
DatabaseManaged Postgres (DigitalOcean Managed Databases or customer-specified). PITR enabled on Enterprise.
Encryption at restAES-256. Managed by the database provider. Tenant secrets (API keys, webhook secrets) additionally encrypted with a tenant-specific key derived from the master key.
Encryption in transitTLS 1.2+ enforced end-to-end. HSTS preloaded. No plain-HTTP fallback.
Data residencyDefault: EU-West (Amsterdam). GCC/UAE region available for Enterprise. Confirm at contract.
BackupsDaily automated snapshots, 7-day retention (Pilot/Professional). PITR with 30-day retention (Enterprise).
PII handlingTrader PII (name, email, phone) stored in the tenant's own ledger. PredSouq does not export or transmit PII to third parties without operator instruction.
Data deletionOn contract termination, tenant data is purged within 30 days. Audit log is retained for 7 years for AML compliance unless jurisdiction requires otherwise.
Security testing

Pen-test & production hardening

The platform ships with a documented pen-test readiness checklist and security review scope document. Enterprise tier includes a third-party pen-test certification as part of the implementation fee.

Security headers enforced: HSTS, X-Content-Type-Options, X-Frame-Options, CSP
Rate limiting: 20 req/min on public endpoints, 60 req/min on authenticated endpoints, stricter on auth routes
All inbound webhooks verified via HMAC-SHA256 signature before processing
Idempotency keys on all trade and funding operations — replay attacks are rejected
Parameterised queries throughout — no string interpolation in SQL
WAF and DDoS mitigation via Cloudflare (recommended for all production deployments)
Pre-launch automated verification script (scripts/golive-verify.sh) covering health, audit chain, ledger, treasury, headers
Operations

Incident response

Operators have platform-level tools to respond to incidents without waiting for PredSouq support.

Kill-switch
Single console action (requires step-up auth) halts all trading across the entire book in under 1 second. Individual markets can be suspended independently.
User-level controls
Operators can freeze individual accounts, reverse pending withdrawals, and escalate AML flags — all audited and attributed to the acting staff member.
Exposure ceiling
Per-market and platform-wide exposure limits are configurable. The engine enforces them automatically — new positions that would breach the ceiling are rejected.
Disaster recovery
A documented DR runbook and restore-check script (scripts/restore-check.sh) are included. Enterprise: PITR + standby node.
Security research

Responsible disclosure

We welcome security researchers. If you discover a vulnerability, please report it privately before public disclosure so we can investigate and remediate.

Report vulnerabilities to [email protected]. Include a description, steps to reproduce, and potential impact. We target a first response within 24 hours and a resolution timeline within 72 hours for critical issues. We do not pursue legal action against good-faith researchers.

Report a vulnerability

For enterprise security reviews, pen-test scheduling, or to request the full SECURITY-REVIEW-SCOPE and PEN-TEST-READINESS documents, contact [email protected].