Trust centre
What is built, what is verified, and what is not yet
Everything on this page is taken from the engine repository’s security documents and the current release notes. Where a control is missing, it says so.
Control status
Tenant isolation
implementedPostgreSQL 16 with row-level security forced on every tenant table, keyed on a per-request connection setting. The application login owns nothing; start-up refuses a login that could bypass RLS; CI re-verifies on a fresh database.
Signed requests
implementedHMAC-SHA256 over method, path, timestamp, nonce and body with a five-minute skew window; a nonce store that holds across replicas and restarts; per-credential rate limiting.
Role-based permissions
implementedEvaluated before the handler runs. Rulesets, decision modes and integration policies that could ever act on a payment need a second approver.
Data minimisation
implementedTokenised identifiers derived by the partner with a key it keeps; the import gate refuses names, phone numbers, account numbers, national identifiers and secrets whole.
Evidence integrity
implementedSigned, hash-chained appends; anchors checked on every full verification; offline verification of exports; a tampered record fails verification at the record.
Auditability
implementedStructured logs that never carry secrets, payloads or entity tokens; an audit trail and change requests that the retention job never deletes.
Retention and legal hold
implementedPer-tenant policy with production and non-production retention days and legal hold; batched, audited deletion with a dry run.
Residency
implementedA Stage B deployment runs in the partner's residency zone on a host it chooses; backups are never edited to remove one tenant.
Observe-only modes
implementedSHADOW and MONITORING available; ADVISORY and ACTIVE closed for production tenants by a code constant that CI checks.
Key custody
pilot gradeEvidence signing keys are passphrase-encrypted files on a volume. The KMS/HSM provider abstraction exists and is tested against a test double only.
Write-once evidence store
not yetThe object-lock store abstraction exists with a directory implementation; no cloud WORM backend has been selected or written.
External penetration test
not yetScope, preparation and request for quotation are written; the test is not yet commissioned. A precondition for any decisioning mode.
Disclosures
Stated plainly, not hidden
We would rather list these than have a partner discover them.
Preparation and scope are written; the test is not commissioned. Precondition for opening any decisioning mode.
Signing keys are passphrase-encrypted files on a volume; the provider abstraction is tested against a double only.
Directory implementation of the object-lock abstraction only.
A production tenant cannot be configured to either; the gate is a code constant CI checks on every commit.
It makes no decision that affects a payment.
No result on this site is measured on real data.
Pilots use the partner's own push integration.
Listed so nobody reads more into the CI gates than they cover.
Data boundary
What the engine wants, and what it refuses
- Identifiers tokenised with a key the partner keeps
- Lifecycle state, timestamp with time zone
- Amount, currency, rail, channel
- Assurance levels as categories
- Optional device, API client, agent, merchant tokens
- Labels with the time each was learned
- Customer names
- Raw phone numbers
- National identity numbers
- Addresses, dates of birth, emails
- Account numbers, IBANs, card numbers
- Passwords, PINs, one-time passcodes
- PINs, passwords, one-time passcodes
- Private signing keys
- Customer credentials of any kind
- The partner's tokenisation key
- The partner's API credential back
A pilot starts with a non-disclosure agreement and a data-processing agreement with residency, retention and deletion clauses.
Engineering assurance
Every commit runs the gates
Tests on both storage backends, a linter with security rules, a type check, layer-boundary and security-regression suites, migration validation, a lock-file check, a dependency audit, a secret scan of history and tree, static analysis with a no-SQL-from-strings check and a readiness-constant check, alert-rule tests, a container build with a vulnerability scan, and a release gate that requires all of them. Actions are pinned to commit hashes and tools to checksums.
The container image is multi-stage on a digest-pinned base, installs dependencies by hash, ships no package manager or build tooling, runs as a non-root user, refuses to start without durable configuration and runs a preflight readiness check before it serves.
Retention and exit
What happens to partner data
Retention is a per-tenant policy with production and non-production retention days and legal hold, enforced by a batched, audited job with a dry run. The evidence record, audit trail, change requests, cases and configuration are never deleted by that job; their destruction at the end of the agreed record period is a documented act with the partner’s written agreement.
A rejected import is deleted from quarantine the same day and the deletion recorded with file hashes. Stage A replay data lives only in a throw-away engine and is gone when the run ends. At the end of Stage B a full evidence export is verified and handed to the partner.
This website
A separate, static-first application with no connection to any engine deployment. Strict content security policy with per-request nonces, HTTP strict transport security, frame denial, a no-referrer-leak policy and a restrictive permissions policy. No third-party scripts, fonts or analytics. The only form validates in the browser and on the server, rejects anything that looks like an account number, card number, PIN or one-time code, stores nothing itself, and tells you immediately if its intake inbox is not connected. Security or privacy teams can write to the address on the contact page; the full security pack is shared on request.