Compliance Engine

Documentation 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.

The AlgoVoi compliance engine is a synchronous, multi-layered control system that runs on every payment processed by the platform before any webhook fires or settlement is confirmed. It is not an optional add-on and cannot be bypassed. Every payment across all seven supported chains and five supported protocols passes through the same compliance stack in the same order. Three pillars form the engine:

1. Wallet-level sanctions screening against three sovereign lists
2. URL and IP threat intelligence screening at four enforcement points
3. KYC and KYB identity gating controlling mainnet access

The engine is designed to be SAMLA 2018 s.20 tipping-off compliant throughout. Verdicts returned to callers are generic. The name of the list that produced a match is never disclosed to the payer or to any unauthenticated party.

---

​

Sanctions Screening

Sanctions screening runs at every payment submission, every mandate activation, and every Tier 2 standing-authority pull. The payer wallet address is matched against three sovereign lists maintained as in-process data structures with daily feed refresh.

​

Screening Sources

UN designations are screened transitively through the EU and UK cascades. No separate UN feed is required. A wallet that appears on a UN Security Council consolidated list is captured by the EU and UK lists at the point of each implementing regulation.

​

Match Handling

Wallet addresses are normalised to a canonical form per chain before comparison. The match logic distinguishes three outcomes: The daily reaper runs as an in-process scheduled job. It downloads the three list feeds, parses them into normalised canonical form, and hot-swaps the in-memory screening set without a service restart. The last successful refresh timestamp is visible on GET /compliance/attestation.

​

Name-Level and PEP Screening

The framework for name-level screening and Politically Exposed Person (PEP) classification is defined and wired into the risk-tier model. Wallet-level sanctions screening incorporates a PEP flag where the list source provides one. Full name-level PEP screening per FCA FG17/6 risk-based methodology is in preparation, pending integration of a commercial data feed. The field name pep_flag is present in the risk model and is settable by MLRO override today.

---

​

Pre-Payment Screen Endpoint

Any party — merchant, agent, wallet application, or x402 facilitator — can call the pre-payment screen endpoint before submitting a payment. This endpoint is unauthenticated and rate-limited. Endpoint: POST /compliance/screen Request fields: Response fields: The reasons array uses generic phrasing only, in compliance with SAMLA 2018 s.20. Examples of valid reason strings: “wallet address matches a sanctions designation”, “wallet address is associated with a flagged entity”. The list or program name is never included. This endpoint is called automatically by the AlgoVoi MCP tool screen_recipient, by x402 facilitators before issuing a payment challenge, and by the control plane before activating any mandate.

---

​

URL and IP Threat Intelligence Screening

The URL and IP screening layer operates at four distinct enforcement points. Each point is synchronous and blocking. A failed check at any point returns an error response and records the event in the compliance_events audit chain. Seven threat-intelligence feeds are maintained in-process. All seven are refreshed hourly without a service restart.

​

The Seven Feeds

MaxMind GeoLite2 GeoIP database is also maintained in-process for jurisdiction classification. It is updated on the MaxMind release schedule (typically weekly).

​

Enforcement Point 1: Signup IP

Applied at: POST /cloud-signup/create (tenant account creation) Checks performed synchronously, in order: The lawful basis for IP processing is UK GDPR Article 6(1)(f) legitimate interests, with a documented Legitimate Interests Assessment (LIA) on file. Article 22 automated-decision mitigation is documented: MLRO review is available to any applicant who believes their IP address has been misclassified.

​

Enforcement Point 2: Checkout redirect_url

Applied at: POST /v1/payment-links (every checkout link creation) Redirect-chain following is capped at five hops to prevent infinite-loop abuse. If a redirect chain exceeds five hops, the link creation is blocked.

​

Enforcement Point 3: Webhook Destination Registration

Applied at: POST /v1/webhooks (every webhook endpoint registration) This enforces the SSRF defence layer. An attacker cannot register a webhook that would cause the AlgoVoi delivery system to make requests to internal network addresses or cloud metadata services.

​

Enforcement Point 4: Webhook Delivery DNS-Rebinding Guard

Applied at: Every webhook delivery attempt (before each HTTP POST is sent) The registered destination hostname is re-resolved immediately before each delivery attempt. The resolved IP is re-checked against the private-IP deny list and the link-local deny list. If the hostname now resolves to a blocked address — for example because of a TTL-0 DNS rebinding attack where the hostname passed registration but was subsequently pointed at an internal address — the delivery attempt is aborted and the event is queued for retry against the original destination. This guard runs on every delivery, including retries, not only on first delivery.

---

​

KYC and KYB Identity Gating

Mainnet payment acceptance is blocked for any tenant whose kyc_status is not approved or whose mainnet_active flag is not true. These two conditions are set independently and both must be true for a tenant to accept live payments.

​

KYC Auto-Approval (Individuals and Sole Traders)

Individual and sole_trader applicants who submit a recognised identity document plus a liveness selfie are automatically approved provided:

• Document type is passport, national identity card, or driving licence from a non-sanctioned jurisdiction
• Liveness check passes (anti-spoofing, face-match against document)
• No sanctions match on name (where list source provides name data)
• Signup IP did not generate a hard-block at enforcement point 1

Auto-approval is not available for:

• Applicants from FATF grey-list jurisdictions (MLRO manual review required)
• Applicants whose document jurisdiction is sanctioned
• Company and company_director KYB applications (always require MLRO review)

​

KYB (Company Onboarding)

Company KYB always requires MLRO manual review. The following data is collected: All KYB documents are encrypted at rest using the platform’s document encryption key family. Key material is held outside the codebase. Loss of the key renders encrypted files unrecoverable.

​

Risk-Based Onboarding

Every onboarding is assigned a risk_tier. The tier is computed from a combination of:

• Geographic risk (signup jurisdiction, business jurisdiction, UBO jurisdictions)
• Sector risk (regulated sector, high-risk sector as per FATF sector guidance)
• Ownership complexity (number of UBO layers, nominee directors, bearer shares)
• Product mix (high-velocity micropayments vs low-volume B2B)
• Anticipated volume (low, medium, high, very high)

Higher-risk tiers trigger Enhanced Due Diligence (EDD). EDD items include source of funds evidence, business plan, reference checks, and periodic re-screening schedule.

---

​

Risk Tier Model

Risk tier can be changed by MLRO action at any time. Every change is recorded as a compliance_events audit chain row with state_from, state_to, reason, and actor.

---

​

Regulatory Alignment

The compliance engine is designed and operated with reference to the following regulatory frameworks. Alignment status is assessed against each framework’s requirements as they apply to the platform’s operating model.

---

​

Public Attestation Surface

The compliance attestation endpoint is a public, unauthenticated endpoint that provides a machine-readable snapshot of the current compliance posture. Endpoint: GET /compliance/attestation Response fields: This endpoint is used by:

• Buyers conducting technical due diligence
• Downstream agents verifying platform compliance posture before submitting a payment
• The AlgoVoi MCP tool get_compliance_attestation
• The standalone audit verifier at verify.algovoi.co.uk when checking live chain heads against B2 Object Lock anchors

The response does not require authentication. It is intended to be publicly inspectable.

---

​

Compliance Events and Audit Integration

Every significant compliance decision is recorded as an immutable row in the compliance_events audit chain. The chain is hash-chained (SHA-256 over RFC 8785 JCS canonical JSON), shipped to Backblaze B2 in COMPLIANCE-mode Object Lock with retention to 2033. See the Audit Chain specification for full chain mechanics. Key event types recorded in compliance_events: Every compliance_events row participates in the same hash chain and B2 Object Lock retention as all other audit chains. The compliance history of every tenant is therefore immutable from the moment it is written.