Trust center

Our honesty is the product.

iso-compliant is a headless ISO 20022 compliance engine. We tell you exactly what is behind every rule pack and exactly where it sits in its lifecycle. No bank has endorsed iso-compliant unless the relevant pack page carries STATUS: VERIFIED. Today, zero packs are VERIFIED — and we would rather say that loudly than imply otherwise.

What this is built on

Real dependencies and standards — not logos we borrowed.

The wall below lists the infrastructure iso-compliant actually runs on and the message standards the engine actually speaks, sourced from public SIX / ISO / SWIFT documentation. There are no customer or bank logos here, because we have no bank endorsement to display.

Built onCloudflareSupabaseStripe
ImplementsISO 20022SEPA SCT/SDDCGI-MPSWIFT CBPR+Swiss QR (SPC v0200)

Lifecycle

Every pack carries an honest status badge.

A rule pack climbs three tiers. The badge on each pack tells you exactly what you are getting — public-IG scaffolding, a pack exercised against a bank UAT channel, or a signed bank attestation on file. Right now every published pack sits at the first rung.

1SKELETON

Public IG only — no bank UAT

Built from publicly available Implementation Guides (SIX Swiss Payment Standards, ISO 20022 base, SWIFT public bulletins). No bank UAT or attestation. Every rule cites a verifiable public URL.

Where every published pack sits today
2UAT_PENDING

Exercised against a bank UAT channel — awaiting attestation

Rules have been exercised against a bank UAT channel using credentials issued by the bank. The bank has not yet signed a formal attestation; results are awaiting bank-side review.

Not reached by any pack yet
3VERIFIED

Signed bank attestation on file

Signed bank attestation on file. Pack page carries a SHA-256 hash of the attestation document, the bank-side reviewer name, and the date of acceptance.

Not reached by any pack yet

Disclaimer

No bank has endorsed iso-compliant unless the relevant pack page carries STATUS: VERIFIED and a SHA-256 hash of the bank's signed attestation document. SKELETON and UAT_PENDING packs are useful engineering scaffolds built against public sources, but they are NOT an endorsement.

Current state

Where we actually stand, in numbers.

These counts are computed directly from the public attestation register that powers /proofs. If a number here is zero, it is zero on the source of truth too.

Packs published
6
SKELETON
6
UAT_PENDING
0
VERIFIED
0
First VERIFIED target
2026-Q3

Zero packs are VERIFIED today. All 6 published packs are SKELETON — derived from public Implementation Guides with zero bank attestation. The moat is the provable per-bank acceptance evidence we are building toward; it is prospective, and this page will not pretend otherwise.

Security posture

How customer data and requests are protected.

The controls below are in force today, with the single explicit exception of SOC 2, which is framed as a target — not a held certification.

Zero-retention by default

The only persisted artefacts are anonymised payload hashes plus the MsgId for idempotency. Plaintext payloads expire from the render cache in minutes — they are not kept.

Hash-chained 7-year audit log

Every request emits an attestation hash chained to the previous entry (Chainlog). Tamper-evident and retained for 7 years to back SOC2 / ISO 27001 / FINMA evidence requests.

Ed25519 / RFC 9421 request signing

Every request body is cryptographically signed and verified before the validator runs. RFC 9421 HTTP Message Signatures preferred; detached Ed25519 supported.

RLS + per-tenant KEK envelope encryption

Postgres row-level security isolates every tenant, and tenant data is sealed under a per-tenant key-encryption-key (KEK) envelope so one tenant can never reach another.

mTLS available

Mutual-TLS pinning is available for enterprise integrations that require client-certificate authentication on top of request signing.

SOC 2 (targeted Q4 2026)

We do NOT hold a SOC 2 report today. A Type II audit is targeted for Q4 2026; this line will only claim a report once one is actually on file.

Read the evidence, then build.

Every claim on this page is checkable on /proofs. When you are ready, an API key takes minutes.