For procurement, risk and DORA review
Continuity and exit plan
RiskRouter is run by one person, Anil Jangra, and has no legal entity registered yet. If you depend on it, you should know what happens the day it stops, and the answer should not rest on our goodwill that day. DORA asks a financial entity to have an exit strategy for each ICT provider it relies on; this page is the part of that strategy we can write for you, and it says where it falls short.
What you keep
Your evidence outlives us
- Your entries, whenever you want them. One authenticated request to
GET /api/v1/ledger/exportreturns every entry you recorded, the digest skeleton of the whole chain they sit in, and the signed head. No ticket, no notice, no fee. - A verifier we do not control the outcome of. Dependency-free verifiers in a public repository that shares no code with the service. Clone it now and it keeps working without us.
- The public key and past heads. Published in that same repository, so an export you hold can be checked against a key and a head you did not get from us on the day.
- An open format. The export is JSON, and the canonical form of an entry is documented on the verify page, so any engineer can re-implement the check.
What makes this real is the copy you take. An export saved regularly, kept somewhere we cannot reach, is evidence that survives RiskRouter. One you meant to download is not.
What stops
What stops if we stop
| Function | If RiskRouter stops | What you need in place |
|---|---|---|
| Pricing | The API stops answering. | A fallback for quoting, or your own copy of the engine (see below). |
| Recording new quotes | Stops. A quote after that point is not in our ledger. | Your own record of new quotes from that date. |
| Your existing evidence | Unaffected, if you hold an export. | Regular exports, stored by you. |
| Checking that evidence | Unaffected. | A clone of the public verifier. |
Backups
Restore tested, and what backups exist
A restore drill runs every day, and every run so far has passed. Each day a backup of the production ledger and the evidence log is taken and restored into a fresh database, automatically; a failed drill alerts the owner and is written up on the changelog. The first drill was run by hand on 23 September 2026, and the job has run on a schedule since. In the first drills, all 46 entries came back, the database’s own chain check and an independent rebuild both reached the same head, that head is the one signed on 13 September and timestamped in Bitcoin, and the restored ledger still refused every edit and deletion. Loading took under a second; a real recovery would take as long as noticing, deciding and repointing the service.
What is not in place yet: the database runs on a plan that keeps no backups of its own. The only backups are our daily ones, kept encrypted on GitHub for 90 days, so entries recorded since the last one, at most a day’s, would be lost with the database. Your own exports are not affected: they verify without us.
Exit
The steps to leave, in order
- Take a final export and verify it with the public verifier, offline.
- Save the signed attestation it contains, and a copy of the public key from the verifier repository.
- Stop sending your key; record new quotes in your own system from that date.
- Ask us to revoke your key, so nothing more can be recorded in your name.
- Keep the export for as long as your own retention obligations require.
None of these steps needs our cooperation except the revocation, and even without it an unused key records nothing. That is deliberate: an exit that depends on the provider is not an exit.
Running it yourself
It runs in your own account, and the source is not public today
The engine is small: a SQL schema and one Worker, with no proprietary runtime. There is a deployment kit for running that same code in your own account: on your own Cloudflare and Supabase, or anywhere containers run (PostgreSQL, PostgREST and the API, started with one command). Your instance signs its heads with its own key, holds its own data, and calls nothing of ours: no licence server, no telemetry. Anchoring, witnesses and the conformance suite work against your instance the same way they work against ours. The kit is built and exercised end to end from nothing every week in our CI: a distributor and a key, a quote recorded, evidence recorded, and every signature checked with the instance’s own key by both verifiers.
The engine’s source code is still in a private repository; what is published, under the Apache License 2.0, is everything that checks or feeds it: the specification and test vectors, both verifiers, the conformance suite, the integration kit and the drop-in recorders. So running it yourself needs the source and a licence from us, agreed in writing. If that is a condition of your pilot, say so before it starts, and agree how you would get the source if we stopped: direct access, or an escrow arrangement. We would rather settle that at the start than have you discover it at the end.
DORA
Facts for your register of information
A financial entity keeps a register of its contractual arrangements with ICT third-party service providers. These are the facts about us you will need for it. The ones that count against us are stated as plainly as the rest; whether the function we support is critical or important is your assessment, not ours.
| Item | RiskRouter |
|---|---|
| Provider | RiskRouter. No legal entity is registered yet, so there is no LEI and no company number. A contract can only be signed once one exists. |
| Service | Software delivered as an API: deterministic server-side pricing from a published rating matrix, and an append-only, hash-chained audit ledger with a signed head. |
| Function it supports | Pricing configurations, and recording what was quoted as evidence for your IDD obligations. It does not hold the customer relationship, the demands-and-needs assessment, the IPID, claims or payments. |
| Personal data | None in a quote entry, by design. Enquiries sent through our contact form are the only personal data we hold, and they are not part of the service. |
| Where data is stored | Supabase, Frankfurt, Germany (EU). An encrypted daily backup is kept on GitHub for 90 days, outside the EU. |
| Where it is processed | Requests are handled by Cloudflare at the network location nearest the caller, which may be outside the EEA. Nothing is stored there. |
| Subcontractors | Cloudflare (network and compute), Supabase (database), GitHub (encrypted backups), Microsoft (the mailbox behind our published address). Listed on the data protection page. |
| Substitutability | Your data leaves in full, in an open format, verifiable without us. Pricing and recording would need replacing: see what stops, above. |
| Exit plan | This page. |
| Certifications and audits | None. No penetration test and no certification is claimed. See security. |
| Service level, incident notice | None offered today. To be agreed in writing per pilot. |
| Contract terms | Each provision DORA Article 30 requires, and the clause we offer for it: DORA Article 30, clause by clause. |
| Status | Validation build. Mock pricing, no carrier, no cover in force. See the regulatory position. |