For insurance brokers, agents and MGAs
When a client says you gave the wrong advice, show the note, and prove it is the one you wrote.
A claim is refused and the client remembers being told they were covered. What settles it is the demands-and-needs note and your reasons for the recommendation. What weakens it is any doubt that the note in your file is the one you wrote at the time, and not one corrected once the claim came in.
- When it is tested
- A complaint after a refused claim, taken to the insurance ombudsman; your supervisor’s inspection of your files; a claim against your professional liability cover; a court.
- What you will be asked for
- The client’s demands and needs, specified before the contract, and, when you advised, the reasons for what you recommended (IDD, Article 20). What the IDD asks
- What goes wrong today
- The note lives in Word, in an email or in your broker software, and any of them can be edited later without a trace an outsider can check. It is your word against the client’s.
- What changes
- The note is sealed the day you write it, by your broker software or by hand on this site. In a dispute you hand over the note and its receipt, and the other side checks both themselves, without trusting you or us. Nothing about your client reaches us: only a salted fingerprint.
Try it in two minutes
- Choose a demands-and-needs note or an advice note of your own. It is read in your browser and never uploaded.
- Seal it on Seal a file. A free sandbox key is issued on the page; only a salted fingerprint reaches the log.
- Make a copy, change one character in it, and check both against the receipt at Check. The copy fails; the original passes.
Most brokers will never integrate anything themselves: their broker software would, once, for everyone on it. Send your vendor this page. Evaluating any system? Start with the twelve-question audit-trail checklist.
Where you sit relative to us
Money, the customer relationship and the advice note itself stay exactly where they are today. Only a fingerprint reaches us.
- Your advicethe note, made in your own system, as today
- Your systemhashes the note with a salt only you hold and sends us the fingerprint
- RiskRouterseals the fingerprint into the log and signs the head
- Your filethe note, and proof it has not changed since that day: not by you, not by us, not by anyone with database access
The questions your compliance file actually asks
Answered directly, not deferred to a call.
What data do we send?
For an advice note: its salted SHA-256 fingerprint and a short tag such as
advice.note. The note, the customer’s name and everything else stay in
your system; the fingerprint cannot be turned back into any of them.
Does it replace my carriers’ prices?
No. Your carriers price their products, as today. What you seal is the record of what you advised. RiskRouter’s own rating engine is optional and prices sample rates; you do not need it to record evidence.
What gets permanently recorded?
The fingerprint, its tag, the time and your distributor id, in a log with a signed head. You can prove one record to a supervisor without showing them any other. A priced quote is recorded in full, chained to the entry before it.
Where is it hosted?
Records are stored in Frankfurt, Germany, inside the EU; requests are processed at Cloudflare’s nearest location, which may be outside the EEA, with nothing stored there. An encrypted daily backup is kept on GitHub for 90 days, outside the EU. The full position is on the privacy page.
Can we verify it ourselves?
Export your own entries and check them offline with our open-source verifiers, in JavaScript or Python, standard library only, with no call back to us. See how the tamper check works.
What if RiskRouter disappears?
An export you downloaded last year still verifies after we have stopped answering the phone. That is the actual answer to the actual question, not a promise.
How much engineering work is required?
If your broker software integrates RiskRouter, none: the note is sealed when you save it. Otherwise, one HTTP call per record and no SDK, with working code in Python, PHP, C#, Java and JavaScript.
How do we test it before committing?
Take a sandbox key on the integration page, with nobody in the loop. It records in the real log under its own distributor id, so you test the real thing; entries are permanent, and the page asks you to accept that first.
If you are an MGA rather than a broker
Nothing above changes. The distributor id in the ledger is yours whether you write the recommendation yourself or aggregate it from a panel of agents underneath you — the chain records who was attributed, at the level you issue keys to.
What this replaces
A spreadsheet nobody can date-stamp
A cell that says "reviewed" proves nothing about when, or whether it looked different last month.
An argument about which version is real
When the note in the file and the one in the CRM disagree, the fingerprint says which one existed on the day. A three-person practice gets the same answer a compliance department would.
Trusting the operator's word
A database dump is a claim. A chain a holder can verify offline, against a signed head hash, is evidence.