Skip to main content
This page is the developer-facing summary. The canonical compliance hub is algovoi.co.uk/AlgoVoi/compliance.html, which carries the full status-badge dashboard, document binder, and DD-pack request CTA.

​
At a glance

No custody

Settlement is direct on-chain customer-wallet to merchant-wallet. AlgoVoi never holds, controls, or transmits funds.

KYC at-rest encryption

KYC/KYB documents are encrypted at the application layer with a versioned Fernet scheme using a key separate from the general database key.

Risk-based onboarding

Customer due diligence is risk-tiered per the BWRA — geography, sector, ownership, product mix, and volume all factor in. Higher-risk onboardings escalate to EDD.

Sanctions screening

Wallet-level sanctions screening live against UK (OFSI), US (OFAC SDN), and EU Consolidated lists with daily feed refresh. UN designations cascade through EU implementing regulations and are screened transitively. Name-level + PEP screening framework defined; commercial data feed in preparation.

URL / IP screening

4 enforcement points: signup IP, checkout redirect_url, webhook config, webhook delivery DNS-rebinding guard. 7 free threat-intel feeds (Tor, SpamHaus, URLhaus, ThreatFox, OpenPhish, PhishTank, MaxMind GeoLite2) refreshed hourly. SSRF defense always on.

​
URL / IP screening

Four enforcement points run synchronously, each blocking the operation before completion:
  1. Signup IP at /cloud-signup/create — Tor exit nodes, SpamHaus DROP/EDROP, GeoIP-based sanctioned-jurisdiction (DPRK / Iran / Syria / Cuba) hard-block; FATF grey-list jurisdictions escalate to MLRO.
  2. Checkout redirect_url at every checkout-link creation — sanctioned-jurisdiction TLD; URLhaus / PhishTank / OpenPhish / ThreatFox feed match; UK bank-brand homograph; RDAP-based newly-registered-domain (under 30 days); redirect-chain following up to 5 hops.
  3. Webhook destination at every webhook configuration — SSRF defense (RFC 1918, link-local, cloud-metadata, RFC 6761 reserved suffixes, non-HTTPS) plus the same threat-feed checks as above.
  4. DNS-rebinding guard at every webhook delivery attempt — the destination hostname is re-resolved and re-checked against the private-IP deny list. Catches TTL-0 rebinding attacks where a webhook URL passed registration screening but now resolves to 169.254.169.254 or similar.
Threat-intelligence feeds refreshed hourly by an in-process reaper. No proprietary lock-in — all signals are on public feeds an acquirer or successor operator can continue consuming directly. Lawful basis for IP processing: UK GDPR Art. 6(1)(f) legitimate interests with documented LIA + Article 22 mitigation (every block response carries an appeal-email path). The full controls and lawful-basis write-up are documented in the AML Policy §8a and the RoPA §3.7, available under NDA (see the policy library below).

​
Regulatory position

AlgoVoi has self-assessed against FCA Policy Statement PS19/22 (“Guidance on Cryptoassets”) and concludes that its core business proposition — payment-message infrastructure between self-custodial wallets — falls outside MLR Schedule 6A registration as a cryptoasset exchange provider or custodian wallet provider. A formal external legal opinion is in preparation.
FrameworkStatus
UK MLRs 2017 (voluntary alignment)Active
FCA MLR Sch 6A registrationOut of scope per PS19/22 self-assessment; legal opinion in preparation
UK GDPR / DPA 2018Aligned
HMT Cryptoasset Travel RuleNot in scope under current architecture
FSMA 2023 SI regimeMonitoring (~2027)
HMRC CARFAssessment in progress
ICO data-controller registrationIn preparation
Cyber EssentialsPlanned Q3 2026
SOC 2 Type ITargeted Q2 2027
SOC 2 Type IITargeted Q4 2027

​
Policy library

AlgoVoi maintains a full compliance binder — the Information Security Policy & ICT Risk Management Framework (v2.0) plus the supporting policies and procedures below. This page lists what the binder contains; the full documents are available for review under signed NDA via security@algovoi.co.uk.

​
Governance & security policies

  • Information Security Policy — defence in depth, classification, encryption, vulnerability management.
  • Access Control — least privilege, MFA, SSH key management, quarterly access reviews.
  • Change Management — git-based workflow, code review, rollback, emergency-change discipline.
  • Incident Response Plan — severity levels, containment playbook, blameless post-mortems.
  • Business Continuity & DR — RTO/RPO, backup strategy, disaster scenarios, annual DR drill.
  • Vendor Management — subprocessor register, onboarding criteria, breach notification.
  • Acceptable Use — confidentiality, device hygiene, AI tooling rules, reporting.
  • AML / CTF Policy — three-line-of-defence model, MLRO, regulatory position, BWRA approach.
  • DPA Template — Article 28 DPA template aligned to UK GDPR, DPA 2018, UK IDTA / SCCs.
  • Data Breach Procedure — detect, contain, assess, notify (72-hour ICO), remediate, review.
  • Complaints Procedure — channels, timelines, escalation routes (ICO, FCA, OFSI, Action Fraud).
  • Retention Procedure — per-category retention, erasure handling, backup ageing.

​
Risk & AML procedures

  • Business-Wide Risk Assessment (BWRA) — UK MLR Reg 18: risk dimensions, conclusions, residual risk.
  • CDD / EDD Procedure — standard CDD, EDD triggers, KYC-unlocks-mainnet gate, ongoing monitoring.
  • Transaction Monitoring Procedure — rule families, alert handling, segregation of duties, tuning cadence.
  • Record of Processing Activities (RoPA) — Article 30: controller / processor split, lawful bases, retention.
  • Customer Risk Scoring Matrix — risk dimensions, banding, decision overrides, re-scoring cadence.
  • Sanctions Screening Procedure — UK / EU / US coverage (UN cascading via EU regs), match handling, OFSI reporting trigger.
  • PEP Screening Procedure — PEP definitions, FCA FG17/6 risk-based handling, EDD checklist.
All documents above are available under signed NDA — request via security@algovoi.co.uk.

​
Travel Rule and A2A

The UK HMT Cryptoasset Travel Rule applies to FCA-registered cryptoasset businesses making cryptoasset transfers above £1,000. AlgoVoi is not an FCA-registered cryptoasset business and does not initiate or receive transfers on its own account; settlement is direct wallet-to-wallet on public blockchains. AlgoVoi is consequently not a Travel Rule originator or beneficiary institution. For agent-to-agent (A2A) flows, the same KYC-unlocks-mainnet gate, wallet-level sanctions screening, and transaction monitoring apply to AI-initiated payments as to human-initiated ones (name-level + PEP screening data feed in preparation, applies equally once live). AI agents inherit their tenant’s risk tier; an agent cannot transact on behalf of a tenant whose mainnet access is not active. See Concepts → KYC and mainnet.

​
Transaction retention & tamper-evident audit chain

AlgoVoi maintains five hash-chained audit logs. Every row in each chain receives a chain_position, a content_hash (SHA-256 of the RFC-8785 canonical JSON of its immutable fields), and a prev_hash linking it to the previous row. An advisory lock serialises concurrent inserts, preventing chain forks.
ChainWhat it covers
audit_logAdmin and operator actions, access events
screening_hitsWallet sanctions / PEP screening outcomes
compliance_eventsKYC / KYB state transitions
negotiation_trace_eventsx402 / MPP / A2A negotiation protocol traces
payment_ledgerEvery verified payment across all 7 chains and both MPP routes

​
B2 Object Lock shipping

A background reaper runs every ~5 minutes and batches newly chained rows for each chain into NDJSON files: 
payment_ledger/000000001-000000250-<batch-sha256>.ndjson
audit_log/000000001-000000500-<batch-sha256>.ndjson
Files are written to Backblaze B2 in COMPLIANCE mode Object Lock — the provider cannot delete or shorten the retention period even on operator request. Retention is set to 7 years (UK MLRs Reg 40 requires a minimum of 5 years).

​
What is locked in each payment record

For every MPP, x402, A2A, or checkout payment, the following fields are cryptographically sealed in the chain hash at the moment the payment is recorded:
  • tenant_id — the merchant whose resource was paid
  • resource_id — the specific resource or checkout token
  • tx_id — on-chain transaction identifier
  • chain and asset_id — the blockchain and token used
  • amount_microunits — payment amount at capture time
  • verified_at — UTC timestamp of verification
  • payer_address — the sender wallet at time of recording
  • status — verified
These fields cannot be altered post-insert without breaking the chain, and the WORM copy in B2 is permanent. GDPR erasure of payer_address applies to the live Postgres copy after 90 days; the B2 COMPLIANCE-mode copy is outside the erasure scope per legitimate legal obligation under UK MLRs.

​
Subprocessors

VendorPurpose
CloudflareCDN, WAF, DDoS, TLS termination
VultrProduction compute and database hosting
GitHubSource code and CI
MintlifyPublic docs hosting (this site)
Let’s EncryptTLS certificate issuance
Sanctions list providersUK (OFSI) / US (OFAC SDN) / EU Consolidated data
Public RPC providersOn-chain verification

​
Reporting a vulnerability

Email security@algovoi.co.uk or consult /.well-known/security.txt. Acknowledgement target: 1 business day. Triage outcome: 3 business days.

​
Request the full DD pack under NDA

Email security@algovoi.co.uk with your organisation, contact, and the documents you need. The pack covers every Tier B document in full, sample-tested cases, the BWRA with residual risk scores, the executed legal opinion when delivered, and the SOC 2 evidence package as it builds.