Tamper-evident records for finance, AI, security and any decision you may one day have to defend
When a decision is challenged, show the record. Then prove nobody changed it.
A complaint, an inspection, an audit, a claim, a lawsuit: each ends with the same three questions. What did you decide or advise? When? And has the record been touched since? A record kept in a system you control answers the first two on your word alone. RiskRouter answers all three with evidence anyone can check themselves, without asking us, and without your client’s data ever leaving your system.
No form, no contract, no card. Seal a file from this site in two minutes, or your first record from your own software in one request.
The ledger right now: entries chained, head
, .
Check it yourself
-
#44sealed recordprev8205f994…965a4chash8688a6a0…b50303
-
#45sealed recordprev8688a6a0…b50303hashc06ca6e2…4ff694
-
#46sealed recordprevc06ca6e2…4ff694hashf95974f5…d8c225
Change one character of #44 and its hash changes, so #45 no longer points at it, and so on to the end. Try it.
Computed from the anchors and witness keys in the repository when this page was built. Why these cannot be faked
- 1 requestTo seal a record, and one more to fetch its proof
- 0 personal dataLeaves your system: we receive a salted fingerprint
- OfflineVerification needs no account and no call to us
- 6 lawsRecord templates mapped article by article
Built first for the software two kinds of firm already use
One integration in the software a firm already runs reaches every firm on it. That is where we start: the evidence stays in the product they know, and the record never reaches us.
- Software for regulated finance
- Broker, insurer, investment-advice and lending platforms. Their customers must keep the advice or decision record (IDD, Article 20; MiFID II, Article 25; Consumer Credit Directive, Article 18) and may one day have to show it was never changed.
- AI-governance and deployment platforms
- For high-risk AI systems, the logs a system generates must be kept by the provider and by the deployer for at least six months (AI Act, Articles 12, 19 and 26(6)). Sealed logs show they were not rewritten once a decision was contested.
Not software? Seal a file by hand. Another field? Every industry.
Who it is for: anyone who may one day have to show a record was never changed
Most of these people are required by law to keep a record. None of them is required to prove it was never edited, until the day someone contests it. The log takes the fingerprint of any record, so the list below is where we have looked, not where it stops.
| You are | What you may one day have to show | What changes with RiskRouter |
|---|---|---|
| Financial services | ||
| An insurance broker or agent | Why you recommended this policy to this client, years later (IDD, Article 20) | Each advice note is sealed the moment it is written. In a dispute you hand over the note and its proof, and the other side checks it without trusting you or us. For brokers |
| An insurer, MGA or compliance lead | Advice, incidents and reports under IDD and DORA, as they were on the day | Records sealed as they happen, with signed heads, two independent time-stamps and a Bitcoin anchor: a date nobody can move, including you. For insurers |
| An investment firm or financial adviser | Why a product was suitable for this client, and what the suitability report said (MiFID II, Article 25) | Each suitability assessment sealed as it is made. The MiFID II template maps each field to its article. For investment advice |
| A lender or credit platform | How a creditworthiness assessment reached its result (Consumer Credit Directive (EU) 2023/2225, Article 18), and the logic of an automated decision (GDPR, Article 22) | Each assessment sealed with the inputs and the rule version it used, so the decision can be shown exactly as it was taken. For lenders |
| A bank, payment or crypto firm | That customer due diligence was done, and its records kept for five years (Directive (EU) 2015/849, Article 40); what happened in an ICT incident and when it was reported (DORA, Articles 17 and 19) | Each completed check and each incident report sealed when it happens. The customer’s file stays in your system. For AML and KYC |
| A software vendor serving any of the above | That the records your product keeps for hundreds of customers can be relied on | One integration gives every customer a record they can show a supervisor, an auditor or a court. You keep the customer, the data and the interface. The vendor case |
| Any organisation | ||
| A team running AI or automated decisions | What the system decided, and that its log was not rewritten afterwards (AI Act, Articles 12, 19 and 26; GDPR, Article 22) | Drop-in recorders for your existing logs, LangChain and OpenAI Agents, and an MCP server. One sealed record per decision or agent run. For AI decisions |
| An HR team using software to screen or rank candidates | How each candidate was assessed; AI used in hiring is high-risk under the AI Act (Annex III, point 4) | Each screening decision and each human review sealed as it is made, with the version of the tool that made it. For hiring |
| A security or IT lead | What your logs said before an incident, and when each notification went out (NIS2, Article 23; GDPR, Article 33) | Logs sealed segment by segment as they are written, so an edit made afterwards is caught. Sealed security logs |
| A data protection officer | That every personal-data breach was documented, and what was known when (GDPR, Article 33(5)); that you can demonstrate compliance at all (Article 5(2)) | Breach records, impact assessments and changes of consent sealed when written, with no personal data sent to us. For data protection |
| Beyond financial services | ||
| A software maker | What you shipped, its bill of materials, and when you learned of a vulnerability (Cyber Resilience Act, Regulation (EU) 2024/2847) | Register a signed statement for each release through the IETF SCITT interface; the artifact never reaches us. For software makers |
| A pharmaceutical, biotech or testing laboratory | That results and batch records were not altered after the fact (EU GMP, Annex 11 on computerised systems) | Seal each result’s fingerprint as it is created; the data stays in your systems. For laboratories |
| A company publishing a sustainability report | The figures behind it as they stood when they were reported and assured (CSRD, Directive (EU) 2022/2464) | Seal each dataset and each version of the report, so a later correction shows as a correction. For sustainability reporting |
| A researcher, designer or inventor | That a document, design or dataset existed by a certain date, without publishing it | Seal its fingerprint. The content stays private, and the date rests on public time-stamps and Bitcoin, not on your word. For research and inventions |
| A legal, company secretarial or finance team | Which version of a contract was signed, and what the board resolved and when | Seal each version when it is agreed or signed; anyone can later check it is the sealed one. For contracts and boards |
| A contracting authority | Each step of a procurement procedure, enough to justify every decision (Directive 2014/24/EU, Article 84) | Seal the scores and the evaluation report as each step closes, so they cannot be quietly adjusted after a challenge. For public procurement |
| Anyone else | A quality inspection, a policy in force, a record nobody has thought of yet | The same call, a different kind, or a file sealed by hand. Every industry · The quickstart |
Record templates exist today for IDD, MiFID II, the AI Act, the GDPR, consumer credit, anti-money laundering, DORA, NIS2, the Cyber Resilience Act, VAT invoices and public procurement. For everything else the log already takes any record you send; there is simply no field template for it yet. Sealing a record makes it provable, not compliant: what a law requires you to keep is still yours to judge.
Why a record in your own system is not enough
Anything that can store a record can also correct it. That is not an accusation, it is how databases work, and it is why a supervisor, a mediator or an insurer cannot tell an accurate history from a tidied one. The question is not whether you keep records. It is whose word they rest on.
| Your own database or archive | A supplier’s audit report | RiskRouter | |
|---|---|---|---|
| Who can change a record later | Anyone with write access, often without a trace an outsider can check | The supplier who runs the system | Nobody, including us: one changed entry breaks every entry after it, against heads already published |
| Whose word the proof rests on | Yours | The supplier’s | Nobody’s: open-source verifiers, public keys, Bitcoin |
| Where your client’s data goes | Stays with you | To the supplier | Stays with you; only a salted fingerprint is sent |
| If the supplier disappears | Not applicable | The report goes with it | An export you hold still verifies, offline, without us |
Compared with the other ways to prove a record’s date
Time-stamping services and ledger databases are good tools, and a buyer should weigh them. This is where each one stands, including the row where they are ahead of us today.
| A time-stamping or notarisation service | A ledger database | RiskRouter | |
|---|---|---|---|
| What leaves your system | A hash of each document | Usually the record itself, in their database or one you run | A salted fingerprint, never the record |
| What it proves | That one document existed at a time | That the history inside that database was not edited | That each record existed unchanged from a moment, in a public log nobody can edit |
| Who can check it | Anyone with the authority’s certificate | Usually the vendor’s own client or service | Anyone, offline, with open-source verifiers in JavaScript and Python and a published specification |
| Legal weight of the time | Can be qualified under eIDAS, with a legal presumption of accuracy | None of its own | Not qualified today; the time-stamps are from free authorities and every page says so |
| To start | A contract and a call per document | A database to run or a cloud account | A free key with no form, one HTTPS call, drop-in recorders, or no integration at all |
| If the provider stops | The token still checks against the authority’s certificate | Depends on what the vendor lets you export | Your proofs still check, offline, without us (continuity plan) |
How it works
- You keep writing records as you do today
- The advice note, the decision, the log line stays in your system, in your format. Nothing about your client is sent anywhere.
- Your system sends a fingerprint
- One HTTPS call with the record’s salted SHA-256 and a short tag, or a drop-in recorder that does it for you in Python or Node. No SDK is required. Integration guide
- We seal it where nobody can edit it
- The database itself refuses any change or deletion, for every role, including ours. Heads are signed, time-stamped by two independent authorities (not qualified under eIDAS) and anchored in Bitcoin.
- Anyone checks it, any time, without us
- Hand over the record and its proof. Free verifiers in JavaScript and Python check them offline. Watch a changed record get caught
Nothing to lose by trying it
- Free sandbox, today
- A key in under a minute, with no form and no sales call. Every endpoint, every proof and both verifiers work against it.
- No lock-in
- The format is published, the verifiers are open source and the recorders are Apache-2.0. Take every entry, with its proofs, in one call, whenever you like. The specification
- Your evidence outlives us
- RiskRouter is run by one person today. If it stopped tomorrow, every export you hold would still verify. What you keep and how to leave are written down in the continuity and exit plan.
- Or run it yourself
- The same service runs in your own cloud account, against your own database, calling nothing of ours. Run it yourself
Built for the day it is tested
Evidence is only worth something if it holds up when things go wrong, so most of the engineering went there.
- A failed write is reported as failed
- If a record cannot be sealed, the answer says so. It never claims a record that does not exist, because that is precisely what an audit looks for.
- Nothing is lost in an outage
- The recorders write each record to your own journal first and send it when the log answers again. A test cuts the API mid-run and checks every record arrives.
- Backed up daily, restored daily
- Encrypted backups are kept 90 days, and a restore drill rebuilds the chain from them every day. Status and uptime
- The log limits its own write rate
- Because nothing can be deleted, a flood would be permanent. The database caps how fast it accepts entries, even if the API in front of it is bypassed.
One log, fourteen laws
The same log takes the fingerprint of any regulated decision. For each law, a record template says which fields to keep and which article each one answers: IDD, MiFID II, the AI Act, the GDPR, the Consumer Credit Directive, the Anti-Money Laundering Regulation, DORA, NIS2, the Cyber Resilience Act, the VAT Directive, the public procurement directive, the Clinical Trials Regulation and the two medical device regulations. The law names no product, and sealing a record does not make anyone compliant; it makes the record you keep provable. What each law asks you to record
Where this stands today
RiskRouter runs as a validation build. The evidence log, its proofs and the verifiers are live and usable today with a free sandbox key. A quote endpoint in the developer documentation shows a decision being priced and recorded in one call; it prices a simulated sample matrix, places no cover, involves no carrier and takes no payment. Production pricing for the evidence log is not published yet. The regulatory position sets out what is and is not in place.