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 atDocumentation Index
Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt
Use this file to discover all available pages before exploring further.
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) is fully public at chopmob-cloud/AlgoVoi-Platform-Adapters/compliance/INFORMATION_SECURITY_POLICY.md. 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) remain available on signed NDA — request via security@algovoi.co.uk.
At a glance
Compliance as an enabler
KYC, KYB, MLRO sign-off, AML monitoring, sanctions screening, and Fernet
at-rest encryption shipped — not a roadmap. Your CFO signs off, your
auditor doesn’t have to ask twice.
Hash-chained audit log
Every audit event, sanctions hit, and compliance event is SHA-256
hash-chained at insert time. Tampering breaks a verifiable property
detected at export. RFC 8785 canonical JSON.
Object Lock retention
Every audit batch is shipped to S3-compatible Object Lock storage in
COMPLIANCE mode with 7-year retention. Even the bucket owner cannot
delete or overwrite for the retention period.
Two-key encryption separation
Special-category personal data (KYB documents) and operational secrets
(HMAC, OAuth, MFA seeds) are encrypted with separate Fernet keys.
Production startup refuses to start if the keys are equal.
UK-registered, FCA-aware
UK Limited operating entity. Information Security Policy aligned to
UK Money Laundering Regulations 2017, UK GDPR, SAMLA 2018, and the
DORA / MiCA framework for EU customer expansion.
Cloudflare-only origin
VM1 firewall is a strict allowlist of Cloudflare IP ranges scoped to
the public interface. 225,000+ direct-IP probe attempts blocked since
enforcement landed. Verifiable in our incident logs.
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. VM1 + VM4 enforce Cloudflare IP allowlist via
iptablesrules scoped to the public network interface. Direct-IP bypass attempts are dropped silently at the firewall — no TCP handshake completes. - Database TLS. Postgres on both production database hosts (VM1 + VM3) enforces
ssl_min_protocol_version = TLSv1.3withssl_prefer_server_ciphers = on. Same-host Docker-bridge connections continue without TLS for negligible CPU overhead on loopback-equivalent traffic; any non-bridge / non-loopback source MUST use TLS viahostssl scram-sha-256with ahostnossl rejectbelt rule against config drift. Self-signed CA (4096-bit RSA, valid 2026 → 2036) issues per-server certs (2048-bit RSA, valid 2026 → 2028). CA private key kept offline. - Inter-VM private routing. All control-plane / facilitator / KYB-verif / bot traffic between VM1, VM3, and VM4 traverses Vultr’s private VPC (
10.8.96.0/20) with sub-1ms RTT. No inter-VM 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
AVK14-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 achain_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-chainGET /internal/compliance/screening-hits/verify-chainGET /internal/compliance/compliance-events/verify-chain
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 withObjectLockMode=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.
What this means for an auditor: the SOC 2 / FCA evidence ask “demonstrate that audit log entries cannot be tampered with after creation” has a three-layer answer that holds up under technical scrutiny — Postgres RULE, hash chain, off-VM immutable copy. We can demonstrate each layer with a working endpoint or bucket inventory in the auditor’s presence.
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 indexedwallet_address_normalisedlookup. 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.
ScreeningHitrows 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 Unauthorizedon 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 includeaudit: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 LOCKEDfor multi-replica safety).
Compliance posture
| Standard | Applicability | Status |
|---|---|---|
| UK Money Laundering Regulations 2017 | UK-registered crypto-asset service provider | Compliant: KYC, KYB, sanctions screening, transaction monitoring, MLRO, audit retention |
| UK GDPR / DPA 2018 | All UK personal data | Lawful bases documented, subject rights operational, DPIA + ROPA scheduled Q3 2026 |
| SAMLA 2018 | UK financial sanctions | Compliant: tipping-off prevention enforced, OFSI feed daily refresh, write-once hit log |
| DORA (EU 2022/2554) | Applicable on MiCA CASP authorisation | Information Security Policy v1.0 published 2026-05-03, mapped to DORA Articles 5–11 |
| MiCA (EU 2023/1114) | When EU-resident customers are onboarded | Authorisation tracked separately; no active solicitation of EU customers prior to authorisation |
| SOC 2 Trust Services Criteria | Customer-required for enterprise B2B | Information Security Policy mapped to CC1–CC9; SOC 2 Type II audit scheduled subject to ≥5 paying-tenants milestone |
| PCI DSS | Triggered if card data is processed | Not applicable — AlgoVoi is crypto-only |
| ISO/IEC 27001 | Optional certification | Roadmap item Q4 2026 if customer demand drives it |
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/platformandchopmob-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
| Service | RPO (data loss) | RTO (downtime) |
|---|---|---|
| Payment processing (gateway) | 0 | 1 hour |
| Control plane | 0 | 1 hour |
| Facilitator | 0 | 1 hour |
| Postgres | 24 hours | 4 hours |
| KYB documents | 24 hours | 4 hours |
| Sanctions cache | 24 hours | 1 hour |
| Audit log + chain | 0 (hash chain detects loss) | 4 hours |
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 standardsecurity.txt location:
- Machine-readable:
api1.ilovechicken.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.
Frequently asked questions
Are you SOC 2 audited?
Are you SOC 2 audited?
Not yet. SOC 2 Type I targeted Q2 2027; Type II targeted Q4 2027. The
Information Security Policy v2.0 is mapped to SOC 2 Common Criteria CC1–CC9
today, so the audit is a fieldwork exercise rather than a controls-design
exercise. The full policy is publicly published in the
AlgoVoi-Platform-Adapters/compliance/
repository — anyone can review the controls today.Where is data stored?
Where is data stored?
All production data is stored on Vultr Cloud Compute infrastructure in EU /
US regions. Vultr operates SOC 2 Type II audited datacentres. KYB documents
and operational secrets are application-layer encrypted before disk write
using two separate Fernet keys (see Encryption section). Daily encrypted
backups to a secondary Vultr instance.
What happens to my data if I close my account?
What happens to my data if I close my account?
Tenants can request deletion via the dashboard. Deletion routes through
gdpr_purge_service which removes the tenant record and all linked
operational data. Exception: records under AML hold (KYB documents,
transaction logs, audit log, screening hits) are retained for the
statutory minimum of 5 years per UK MLR 2017 Reg 40(3), as required by
law. After the retention period expires, AML-hold records are purged
automatically.Can I get a copy of my data?
Can I get a copy of my data?
Yes. Tenants can export their full data record via a GDPR data-export
request. Currently a manual operator process; self-service export
endpoint is on the Q3 2026 roadmap.
Do you have a bug bounty programme?
Do you have a bug bounty programme?
Not yet. We accept coordinated disclosure via security@algovoi.co.uk and
follow the policy in our security.txt. A formal paid bug bounty is on
the roadmap once the platform crosses material revenue scale.
What about smart-contract security?
What about smart-contract security?
Two on-chain components are in production: the Solana Pay reference-binding
flow (uses the standard Solana Pay primitive — no custom contract) and the
xChain LogicSig on Algorand (custom AVM v11 contract at
chopmob-cloud/xchain-accounts, internally peer-reviewed, external audit
scheduled before xChain expands beyond Algorand mainnet).Do you operate any custodial wallets?
Do you operate any custodial wallets?
No. Settlement is direct customer-wallet → merchant-wallet on the public
blockchain. AlgoVoi never holds, controls, or transmits customer or
merchant funds. The xChain feature uses a deterministic LogicSig address
derived from the customer’s existing EVM wallet — the customer signs an
EIP-712 message in their own wallet to authorise each transfer.
What if you go out of business?
What if you go out of business?
The non-custodial model means there are no customer funds at risk if
AlgoVoi shuts down. KYB documents and audit records remain in
customer-readable form for the statutory retention period via the off-VM
Object Lock storage which is independently accessible. Documented
business-continuity exit plan in the Information Security Policy on
request.
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) — fully public at
AlgoVoi-Platform-Adapters/compliance/INFORMATION_SECURITY_POLICY.md - Tier B documents (BWRA full text, CDD/EDD full text, RoPA full text, transaction-monitoring rule values, customer risk-scoring matrix full) — public summary in the same repo, full document on signed NDA
- Latest annual penetration test report — available on signed NDA once first test completes (Q4 2026)
- Latest SOC 2 report — when published
Document changelog
| Date | Change |
|---|---|
| 2026-05-03 (rev 3) | Postgres TLS in-transit deployed on VM1 (Postgres 17.9) + VM3 (Postgres 16.13). VM2 → VM4 migration completed: secondary facilitator + KYB-verif + Twitter bot now live on UK-region VPC-attached host (10.8.96.5); inter-VM control traffic routes over private VPC, sub-1ms RTT. KYB sanctions screening pipeline activated end-to-end on VM1 control plane (was a silent no-op pre-migration). |
| 2026-05-03 (rev 2) | Reconciled with the canonical compliance hub at algovoi.co.uk/compliance.html. Information Security Policy upgraded to v2.0 (1,239 lines) and reframed as fully-public rather than NDA-tier. Tier B document policy (NDA-only) clarified. SOC 2 dates aligned to public roadmap (Type I Q2 2027, Type II Q4 2027). |
| 2026-05-03 | Initial publication. Hash-chained audit log and Object Lock shipping marked live. VM1 firewall enforcement marked live. |