For security, compliance and audit review
Don’t trust RiskRouter. Verify it.
Every claim below is checkable without asking us anything. That is deliberate: a claim you have to take on faith is not evidence, and an audit trail whose only witness is the vendor who produced it is not one either.
What we send, what we store, where
No personal data in a quote
A quote payload is a vertical key and boolean component toggles. There is no field for a name, an email, or an identifier — not omitted by policy, absent from the schema.
Server-side pricing, always
The server looks up the price from its own matrix. A number a client sends is never read back as the answer, so a manipulated frontend cannot produce a cheaper quote.
Hosted in Frankfurt, EU
Supabase, eu-central-1. No record leaves that region as part of pricing or
recording a quote. Detail on the privacy page.
What the request path can reach, and what it cannot
One destination, mechanically enforced — not a policy someone has to remember.
The Worker that prices and seals a quote makes exactly one outbound call: to the Supabase URL from its own binding. Nothing else — no analytics, no third-party API, no carrier, no payment rail. A stranger's request cannot cause this Worker to contact anywhere else, and that property is asserted by an automated test on every change, not merely documented.
The separate administrative console adds exactly one more destination for its own use: Cloudflare Access's key endpoint, to verify who is signed in. It cannot price a quote, write to the ledger, or reach the public API at all — it does four things only: create a distributor, suspend or reactivate one, issue a credential, revoke one.
The ledger itself
Append-only, structurally
A database trigger refuses UPDATE and DELETE on the audit
table for every role, including the administrator's own. This is not a permission that
could be granted back — the trigger fires regardless of who is asking.
Chained, not just logged
Every entry's hash depends on the entry before it. Changing one historical value breaks every digest computed after it, which is checkable by recomputing them — not by trusting that nobody would.
Signed, not just chained
We periodically sign the current head hash with an ECDSA key and publish it. A saved, signed attestation is something we cannot later disown — it proves we asserted this history at this time, independent of whether the chain is later rebuilt.
Verifying it yourself, offline
A hash chain alone proves history was not edited. It cannot prove history was not rebuilt from scratch — a rebuild recomputes every digest consistently and looks perfect. The signed attestation closes that gap: it is a claim we cannot take back.
Export your own entries any time you hold a key:
curl -s -H "Authorization: Bearer $RISKROUTER_API_KEY" \
https://api.riskrouter.eu/api/v1/ledger/export > ledger-export.jsonThen run two dependency-free Node scripts against it — standard library only, nothing to install, no call back to us. They live in a separate, public repository that shares no code with the service you are checking, on purpose:
git clone https://github.com/aniljangrabe-dev/riskrouter-verify
node riskrouter-verify/tools/verify-attestation.mjs ledger-export.json # we signed this head; we cannot deny it
node riskrouter-verify/tools/verify-ledger.mjs ledger-export.json # your entries actually produce itKeep the export and the signed attestation somewhere we cannot reach. An export saved today still verifies against everything you hold, whether or not RiskRouter is still answering the phone a year from now. That is the actual answer to what happens if you disappear, not a promise standing in for one.
Want to see the chain break in real time instead of reading about it? Try it in your own browser — it lets you tamper with a record and watch the check refuse it.
What we do not overclaim
Precision matters more here than anywhere else on this site.
Not "zero GDPR liability"
A quote payload holds no personal data by design, which is a fact about the schema. It is not a legal conclusion about your own obligations, which depend on what you do with the response.
Not "regulator-approved"
Nobody has approved this. What exists is a record a regulator can independently verify without taking our word for it — a narrower, checkable claim.
Not a validation build claiming live rails
Every figure on this site is a simulation while we validate the routing path. See exactly what is and is not in place on the regulatory position page.