Security

This page is written for security teams, procurement reviewers, auditors, and anyone evaluating whether AlgoVoi is safe to put behind their checkout, AI agent, or marketplace. Every claim below is concrete and backed by source-pointer evidence. For developers, the protocol pages and the Compliance overview are likely a better starting point. The canonical compliance hub lives at algovoi.co.uk/compliance.html — status-badge dashboard, regulatory scope table, AML/CTF programme detail, server-by-server security ratings, and the full policy library. The full Information Security Policy & ICT Risk Management Framework (v2.0, 1,239 lines covering SOC 2 CC1–CC9, DORA Articles 5–11, the Top-15 risk register, 8 incident runbooks, 9 BCP playbooks, and the exception register), together with the Tier B documents (BWRA full text, CDD/EDD full text, RoPA full text, transaction-monitoring rule values, pen-test report when produced, SOC 2 evidence package as it builds), are available for review under signed NDA — request via security@algovoi.co.uk.

​

At a glance

​

Encryption

​

In transit

• TLS 1.3 everywhere. All public traffic terminates at Cloudflare with TLS 1.3 enforced. AlgoVoi nginx accepts only TLS 1.3 + 1.2 with modern ciphers.
• Cloudflare-only origin. Production hosts enforce a strict Cloudflare IP allowlist via host firewall rules on the public interface: a dedicated chain accepts only Cloudflare’s published IPv4 ranges and the private VPC, and drops everything else on the HTTPS/HTTP ports. Direct-IP bypass attempts are dropped silently — no TCP handshake completes.
• Database TLS. Postgres on the production database hosts enforces ssl_min_protocol_version = TLSv1.3 with ssl_prefer_server_ciphers = on. Same-host bridge connections continue without TLS for negligible CPU overhead on loopback-equivalent traffic; any non-bridge / non-loopback source MUST use TLS via hostssl scram-sha-256 with a hostnossl reject belt rule against config drift. Self-signed CA (4096-bit RSA) issues per-server certs; CA private key kept offline.
• Private inter-host routing. All control-plane / facilitator / KYB-verif / bot traffic between production hosts traverses a private VPC with sub-1ms RTT. No inter-host control traffic crosses the public internet.

​

At rest

• Two-key separation. Tenant secrets (HMAC keys, OAuth tokens, MFA TOTP seeds, webhook secrets) use one Fernet key. Special-category personal data — KYB documents, beneficial-owner identity scans, KYC selfies — uses a completely separate Fernet key. Production validation refuses application startup if the keys are equal or unset.
• MultiFernet rotation. Both keys support zero-downtime rotation via a fallback-key slot. Documented procedures in the Information Security Policy.
• Magic-prefix forward compatibility. KYB document files on disk carry an AVK1 4-byte prefix so the loader can transparently distinguish encrypted files from any legacy plaintext, and so future encryption schemes (AVK2, AVK3) can ship with backward-compatible decryption.
• Path-traversal hardening. All file-system access through KYB storage routes through a _safe_path() guard that rejects null bytes and any path attempting to escape the documents root.

​

Audit trail and tamper-evidence

This is where AlgoVoi differs from every other crypto-payments stack we’ve seen. Three layers of defence, not one.

​

Layer 1 — write-once at the database

Three Postgres tables — audit_log, screening_hits, and compliance_events — are protected by Postgres RULE directives that block UPDATE and DELETE at the SQL level. The application can only INSERT.

​

Layer 2 — cryptographic hash chain

Every row inserted into the three protected tables also stores a chain_position, a content_hash (SHA-256 of the row’s RFC 8785 canonical-JSON content), and a prev_hash linking to the previous row’s content_hash. Genesis row uses 0 × 64. Inserts are serialised by Postgres advisory lock so concurrent writers cannot fork the chain. Tampering (UPDATE of an inserted row, DELETE of a row, INSERT of a forged row out of band) breaks a verifiable property. We expose three verify endpoints under admin scope:

• GET /internal/audit-log/verify-chain
• GET /internal/compliance/screening-hits/verify-chain
• GET /internal/compliance/compliance-events/verify-chain

Each returns chain_intact: true|false plus, if broken, the exact chain_position of the break and a human-readable failure reason. SOC 2 auditors and FCA examiners can run these endpoints under audit credentials any time.

​

Layer 3 — off-VM Object Lock with COMPLIANCE retention

Every batch of new chained rows is exported as immutable NDJSON to S3-compatible Object Lock storage with ObjectLockMode=COMPLIANCE and a 7-year retention period. Even the bucket owner with full IAM permissions cannot delete or overwrite the object before retention expires. The retention period (7 years) is configured per-object at upload and exceeds the UK MLR 2017 Reg 40(3) statutory minimum (5 years) and the FCA SYSC requirement. A 5-minute reaper sweeps for un-shipped chained rows, batches them, computes the batch SHA-256, and uploads each batch with the position range and SHA encoded into the object key. An external auditor can fetch the NDJSON files, recompute hashes, and reconcile against in-DB rows. If the in-DB rows have been tampered with or even fully deleted, the Object Lock copy is the source of truth.

​

Sanctions screening (SAMLA 2018, UK MLR 2017, OFAC)

• Local cache, daily refresh. Sanctions list data from OFSI (UK), OFAC (US), and the EU consolidated list is refreshed daily into a local Postgres cache. No third-party API call sits on the payment hot path.
• Indexed lookup, sub-3ms. screen_wallet() performs an indexed wallet_address_normalised lookup. Returns hit/clear plus a server-side action (blocked / flagged / escalated).
• Tipping-off prevention. Per SAMLA 2018 s.20, the gateway and facilitator only ever receive a boolean hit/clear result. The list source, entity name, and match metadata are confined to the compliance admin namespace and the MLRO review queue.
• Multiple screening points. Wallets are screened in real time at challenge issuance and verification, plus at tenant onboarding (KYB approval), plus at risk-tier change, plus by a daily background sweep that catches wallets which became sanctioned after their last screening.
• Write-once hit records. ScreeningHit rows are protected by the same three-layer audit defence as audit_log: Postgres RULE, hash chain, Object Lock shipping.

​

Access control

​

Tenant API authentication

• API keys hashed with Argon2id (resistant to GPU brute-force).
• Plaintext returned once at issuance, never persisted.
• Key states: active, grace, revoked, suspended. Grace-period rotation supports zero-downtime replacement.
• Per-tenant rate limits enforced at nginx and the application layer.
• Generic 401 Unauthorized on all auth failure — no internal detail leaks.

​

Admin authentication

• Bearer tokens hashed with SHA-256, stored in a database table with O(1) lookup via a key-id alias plus a timing-safe full-hash comparison (hmac.compare_digest).
• Token expiry enforced per-key.
• TOTP MFA mandatory for the admin dashboard, with a tight clock-drift window.
• Scope-restricted access via a require_scope() dependency. Current scopes include audit:read, compliance:read, compliance:admin, tenants:read, tenants:write, apikeys:admin, payouts:read, payouts:write, disputes:write, kyb:write, subscriptions:admin.
• In-process auth-outcome counters surface authentication health to the operator without an external metrics dependency.

​

Webhook signing

• Stripe-style HMAC-SHA256 signing on every outbound webhook delivery.
• Per-destination secret, Fernet-encrypted at rest.
• X-AlgoVoi-Signature: t={timestamp},v1={sig} header pattern customers’ code can verify in any language.
• Retry queue with 30s → 32h escalating backoff and dead-letter capture (FOR UPDATE SKIP LOCKED for multi-replica safety).

​

Compliance posture

​

Vulnerability management

• Patching cadence: OS critical patches within 7 days, Important within 30. Application dependency patches: confirmed CVEs in our usage path within 7 days, otherwise within 30.
• Dependency scanning: GitHub Dependabot enabled across chopmob-cloud/platform and chopmob-cloud/AlgoVoi. Weekly automated scan, monthly manual review.
• Pinned versions: Python and Node dependencies pinned at minor version in pyproject.toml / package.json.
• Penetration testing: annual external pentest scheduled for Q4 2026 alongside the first-paying-tenants milestone. Internal lightweight quarterly OWASP Top 10 + STRIDE walkthrough until then.
• Software Bill of Materials: CycloneDX SBOM generated per release tag. First public SBOM ships with this trust page.

​

Incident response

• Classification: P0 (catastrophic — fund loss, key compromise, sanctions failure) — immediate 24/7 response, founder ack within 15 min. P1 (severe service degradation) — 4h business-day SLA. P2 / P3 — documented business-day SLAs.
• Regulator notification: UK ICO within 72 hours for personal-data breaches per UK GDPR Art. 33. NCA SARonline within 30 days statutory for AML implications. Affected data subjects per Art. 34 timing.
• Customer notification: Affected tenant(s) within 1 hour of P0/P1 confirmation via email + dashboard banner. Material outage = status-page banner + all-tenant email within 1 hour.
• Post-incident review: Within 5 working days for every P0/P1, written timeline + root cause + action items + risk-register update + policy update if controls need strengthening.
• Per-scenario runbooks: 8 documented incident runbooks in the Information Security Policy (admin-key compromise, encryption-key compromise, sanctions failure, KYB document leak, VM full host failure, Cloudflare account compromise, audit-log integrity break, smart-contract bug).

​

Business continuity and disaster recovery

Daily encrypted Postgres dumps + KYB-doc rsync to a secondary VM. Weekly automated restore-test on the secondary. First annual tabletop exercise scheduled 2026-08-03; 9 documented BCP playbooks for specific failure modes.

​

Vendor and supplier risk

ICT suppliers in scope are categorised T1 (critical — outage = platform outage, requires SOC 2 report on file), T2 (important), or T3 (routine). Inventory of 13 current suppliers tracked with onboarding date, last review date, next review date, and a documented termination plan for every T1. T1 suppliers: Vultr (compute + Object Storage), Cloudflare (edge + WAF + DNS + TLS), GitHub (source control). Each has a signed Data Processing Agreement.

​

Coordinated vulnerability disclosure

We welcome responsible security research. Contact details and policy live in the standard security.txt location:

• Machine-readable: api.algovoi.co.uk/.well-known/security.txt
• Email: security@algovoi.co.uk
• PGP key: Available on request from security@algovoi.co.uk. Will be published alongside this page once a stable rotation cadence is established.

When reporting, please include enough detail to reproduce the issue. We commit to acknowledging receipt within 2 business days, providing a triage classification within 5 business days, and a remediation timeline appropriate to severity. We will not pursue legal action against good-faith researchers who follow our coordinated-disclosure policy.

​

Frequently asked questions

​

Request additional documentation

For procurement, vendor security review, or audit fieldwork:

• security@algovoi.co.uk — vendor security questionnaires answered within 5 business days
• Information Security Policy v2.0 (1,239 lines, SOC 2 CC1–CC9, DORA Arts 5–11, full risk register, 8 incident runbooks, 9 BCP playbooks, exception register) — available under signed NDA via security@algovoi.co.uk
• Tier B documents (BWRA full text, CDD/EDD full text, RoPA full text, transaction-monitoring rule values, customer risk-scoring matrix full) — available under signed NDA
• Latest annual penetration test report — available on signed NDA once first test completes (Q4 2026)
• Latest SOC 2 report — when published

​

External security audit — 2026-05-27

Self-conducted external audit covering all algovoi.co.uk subdomains and production VMs. Methodology: TLS probe (OpenSSL), HTTP header inspection, DNS record analysis, port scan from external IP, nginx config review.

​

TLS / HTTPS

​

HTTP security headers

F-3 (LOW): algovoi.co.uk marketing site missing four security headers. No API or user data is exposed on this domain; risk is limited to clickjacking of the marketing page. Fix: Cloudflare Transform Rule or HTML <meta> tags.

​

Email security (DMARC / SPF / DKIM)

F-5 (LOW): SPF in ~all mode. Upgrade to -all once all sending sources are confirmed stable. F-6 (LOW): DMARC at p=none. Upgrade path: p=none → p=quarantine → p=reject after reviewing aggregate reports for two weeks.

​

Network exposure

Production hosts sit behind Cloudflare. On the public interface only the HTTPS/HTTP ports are open, and they are firewalled to Cloudflare’s published IP ranges plus the private VPC — every other source is dropped with no TCP handshake. All application and database service ports are bound to the private VPC only and are not reachable from the public internet; a second, independent firewall layer blocks external access to internal service ports even where a container binds broadly. Two independent firewall layers (host origin allowlist + container-level egress/ingress controls) are persisted across reboots. Specific host addresses, interface names, port numbers, and VPC ranges are held in the internal infrastructure documentation (available under NDA), not published here.

​

Open API surface

/openapi.json and /docs (Swagger UI) are intentionally public on api.algovoi.co.uk. AlgoVoi is a developer-facing payment gateway and the OpenAPI schema is a selling tool, not a secret. All endpoints require tenant API key or admin bearer token; schema disclosure does not grant access.

​

Summary

Audit conducted 2026-05-27 by AlgoVoi operator. External probe from non-VPC IP. Next scheduled external pentest: Q4 2026.

---

​

Document changelog