Most AML platforms ask you to trust their console. RiskSonnar publishes every state change into an append-only hash chain, signs single events with per-tenant Ed25519 keys, and exposes both verification surfaces as plain HTTPS endpoints. A regulator with a public key and a 200-line script can replay any decision this platform ever made — without a vendor login.
Each capability below names the claim, the mechanism, and the orchestrator endpoint a sceptic can hit to verify it. The curl examples are copy-paste runnable against any RiskSonnar deploy — self-hosted, preview, or production.
Tamper-evident by construction
Every state-mutating action lands in an append-only chain. Reorder, delete, or modify a single event and the chain breaks at that event and every event after it. Regulators replay the chain byte-for-byte.
SHA-256(prev_hash || canonical-payload || metadata) per event. Genesis hash is 64 zeros. Per-tenant chains — cross-tenant reads return empty at the store level, not the query layer. /v1/audit/verify re-walks the chain server-side and reports the first break.
/v1/audit/verifyReturns {ok: true, chain_length: N} for an intact chain, or the first broken event id + reason if tampering exists.
curl -H "x-tenant-id: t-demo" \ https://orchestrator.risksonnar.com/v1/audit/verify
Offline-verifiable, regulator-friendly
A regulator who wants to prove a single decision happened shouldn't have to fetch the whole chain. Every audit event can be minted into a detached Ed25519 signature over the 7 identifying fields — verifiable with one public-key call.
One signing key per tenant, lazily minted on first request. The mint itself is logged into the chain as receipts.minted under RS-CTRL-FATF-0011 + RS-CTRL-SOC2-CC6.7. /v1/receipts/keys serves the public key (PEM). /v1/receipts/{event_id} mints a signed receipt over the canonical body. Cross-tenant signatures cannot verify — the per-tenant key isolation is enforced cryptographically.
/v1/receipts/keysReturns the tenant's Ed25519 public key in PEM. Any standard PKCS#8 / SubjectPublicKeyInfo parser (OpenSSL, Python cryptography, Node crypto) loads it; receipts verify offline against this key.
curl -H "x-tenant-id: t-demo" \ https://orchestrator.risksonnar.com/v1/receipts/keys
Compliance officers, not engineers
Adding a new TM scenario shouldn't need a Python deploy. RiskSonnar's no-code scenario builder lets a compliance officer compose a tree of filters, group-bys, and havings — saved as a tenant-scoped JSON document and dispatched by the same engine that runs the built-in scenarios.
Tenant-scoped scenarios persist in tenant_custom_scenarios with a stable csn_-prefixed id. The engine's run endpoint sniffs the prefix and routes csn_* ids to the generic evaluator. Built-in and custom scenarios share the same canonical model, so a custom scenario sees exactly what a built-in one sees.
/v1/engine/custom-scenariosLists the tenant's custom scenarios. POST against the same path to create one. POST /v1/engine/run/{csn_id} executes it against canonical transactions.
curl -H "x-tenant-id: t-demo" \ https://orchestrator.risksonnar.com/v1/engine/custom-scenarios
Continuous, not point-in-time
Onboarding-only KYC is yesterday's compliance. Every customer is continuously re-scored against the latest watchlist refreshes, alerts, transactions, and declared-country drift — band transitions emit pkyc.band.changed events the cockpit's elevated-risk feed reads in near-real-time.
/v1/pkyc/recompute re-scores one customer end-to-end. Band changes write a row to pkyc_events AND audit-emit pkyc.band.changed under RS-CTRL-FATF-0010 + RS-CTRL-SOC2-CC7.2. The events feed is paginated by since_utc so the cockpit doesn't re-walk the chain to render the elevated-risk surface.
/v1/pkyc/events?since_utc=...Returns pkyc events newest first. Each event names the customer, the old and new band, and the contributing factors (watchlist hit, alert burst, etc.).
curl -H "x-tenant-id: t-demo" \ "https://orchestrator.risksonnar.com/v1/pkyc/events?since_utc=2026-05-01T00:00:00Z"
FinCEN-shaped narrative in 30s
Investigators spend hours stitching a SAR narrative from an alert + customer profile + transaction context. /v1/sar/draft does the structured-fields + 3-6 paragraph draft in one call — and the audit chain captures the request and response hashes (never the prose) so the regulator can prove what was generated when.
Anthropic-backed real path; deterministic mock mode (ANTHROPIC_API_KEY unset OR RISKSONNAR_USE_MOCK=1) returns a stable narrative so preview deploys + offline tests keep working. PII is redacted to last-4 BEFORE the payload leaves the orchestrator. Audit emits as sar.drafted under RS-CTRL-FINCEN-SAR-01 + RS-CTRL-FATF-0017 + RS-CTRL-SOC2-CC7.4.
/v1/sar/draftPOST { alert_id } returns { structured_fields, narrative, model, request_hash, response_hash }. The hashes are also in the audit chain — anyone can re-derive them from the response body.
curl -X POST -H "x-tenant-id: t-demo" \
-H "content-type: application/json" \
-d '{"alert_id": "al_2014"}' \
https://orchestrator.risksonnar.com/v1/sar/draftBTC / ETH / TRON / POLYGON in one call
Every counterparty wallet on every transaction is screened against an 8-category risk taxonomy (clean / exchange / mixer / darknet / sanctioned / scam / theft / unknown). VASPs and crypto-curious banks get the same screening surface; the audit chain records every screen with a privacy-preserving truncated address.
Mock-mode-first deterministic classifier (sha256(address)[:2] mod 8) for sandbox + preview deploys. Real-mode path is wired to a commercial provider (TRM Labs) behind TRM_LABS_API_URL. 24-hour same-(tenant, address, network) cache. Every screen audits as crypto.address.screened under RS-CTRL-FATF-0012 + RS-CTRL-VASP-0001 with the address truncated to first8…last6.
/v1/crypto/screenPOST { address, network } returns { risk_category, risk_score, sources, cached, screened_utc }. Same address re-screened within 24h returns cached=true and skips the provider call.
curl -X POST -H "x-tenant-id: t-demo" \
-H "content-type: application/json" \
-d '{"address": "0x...", "network": "ETH"}' \
https://orchestrator.risksonnar.com/v1/crypto/screenEight endpoints, zero vendor login. A regulator, an internal auditor, or a sceptical CISO can stitch together a complete replay of any RiskSonnar tenant's decisions using nothing more than HTTPS and a public key.
GET /v1/audit/verifyGET /v1/receipts/keysGET /v1/receipts/{event_id}GET /v1/engine/custom-scenariosGET /v1/pkyc/eventsPOST /v1/sar/draftPOST /v1/crypto/screenGET /v1/trust/{tenant_slug}You don't take the vendor's word for it. You re-walk the chain server-side, verify any single decision off-line with the tenant's public key, and confirm every mutating action carries a named control id (FATF, AMLD6, OFAC, DORA, NIST, SOC 2).
No-code scenario authoring keeps tuning inside compliance, not engineering. Perpetual KYC closes the gap between onboarding and ongoing monitoring. LLM SAR drafting compresses investigator time without compromising auditability — the prose is generated, the hashes are signed.
Per-tenant Ed25519 keys, per-tenant audit chains, per-tenant custom scenarios — isolation is enforced at the store level, not the query layer. The mock-mode-first design lets every feature pass a preview deploy without surfacing a single live secret.
Spin up a 60-minute synthetic-data sandbox, or send us a note and we'll walk through the verification bundle live.