Northbridge Mutual
Replacing a claims platform on a deadline that cannot move, with a pack where every requirement, risk and control was signed off by a named person.
Northbridge Mutual is a fictional company used to demonstrate Requio with a realistic, fully worked example — built end to end through the real product, not written as marketing copy. No client relationship is implied.
View the full DRP onlineThe challenge
Northbridge Mutual is a mutual insurer with 410,000 members, handling 38,000 claims a year across household, motor and small commercial property. Its claims platform, CLARIS, was bought in 2004. The supplier withdrew mainstream support in 2023, and the extended support agreement it now pays £310,000 a year for expires at the end of 2027 and will not be renewed at any price.
That deadline is the easy part of the problem. The harder part is everything the platform cannot do. Every claim is notified by telephone or post. A web form added in 2016 writes to a mailbox, so a handler rekeys it — 2,900 claims a year, eleven minutes each. Members cannot see their own claim, which generates an estimated 71,000 status calls a year. Reserves are set from a laminated table last revised in 2019, and the 2025 actuarial review found escape-of-water claims under-reserved by about 14 per cent. Vulnerability is recorded, when it is recorded at all, as a free-text note that the next handler may or may not read.
As a mutual, Northbridge has no shareholders: its members are its owners, and the board treats claims experience as the measure of whether the mutual is doing its job. A replacement had to be specified to a standard the regulator would accept, not sketched.
How Requio was used
Grounded in the organisation’s own documents, not general knowledge
Three reference documents were uploaded to the project’s AI Knowledgebase before a word of the pack was drafted: the current claims operating model with its real figures, the board-approved business case including the options that were rejected and why, and Compliance’s statement of the regulatory obligations the platform has to satisfy.
Every section was then drafted against those documents as citable source material. The difference shows: the pack argues from the 14 per cent under-reserving the actuarial review actually found, the two treaty notifications genuinely missed in the last three years, and the counter-fraud audit action that falls due before the platform can possibly deliver. None of that is available to a model working from general knowledge about insurance.
A sign-off trail with names on it
All eighteen reviewable sections were submitted by the Lead Analyst, reviewed by a second person and approved by a third — Daniel Fairhurst, Priya Raman and Michael Brennan, each doing only their own part. The pack records who did what and when, section by section, and the published document shows that table.
It is worth being precise about what that proves. It is not that the content is correct — no process proves that. It is that the pack went through the governance it claims to have gone through, and that the claim can be checked rather than taken on trust.
RAID, Controls and Test Cases that argue from the same facts
The RAID log runs to 19 entries, including the dependency on the policy administration replacement landing in Q3 2027 — within weeks of the CLARIS deadline, with no contingency behind it — and the counter-fraud audit action due 30 June 2026 that the platform cannot meet, which is why an interim manual control had to be agreed with Internal Audit.
The controls register (11 entries) and the test cases (9) argue from those same facts rather than from generic good practice: segregation of duties expressed as the specific rule that whoever set the reserve may not be the sole authoriser of a payment on it, and a test that a reserve moving from £240,000 to £260,000 raises the treaty alert and starts the five working day clock.
A traceability matrix with nothing left to assume
Every requirement traces to the business objective it serves, the user story that expresses it and the test case that verifies it. There are no gaps.
That was not true on the first pass, and the pack said so itself: every row read "Requirement has no user story. Requirement has no test case." The module reports what it can see, and at that point there was nothing to see. User stories were written for each requirement and the matrix was asked again. The gaps closed because the work was done, not because the table was edited — which is the only way a traceability matrix is worth anything.
Current and future state as real BPMN
The business process section carries genuine BPMN 2.0 diagrams for both states, generated from the pack’s own process narrative: the current journey — telephone notification, a separate policy lookup, a reserve from the printed table, suppliers instructed by email and recorded as a note — and the target, where notification creates the claim directly, screening runs on every claim, and a reserve crossing the treaty threshold raises its own alert.
The outcome
The pack reached version 7. Each version carries the reason it was issued, and each reason describes a change that was actually made — reserve override reasons made mandatory after the actuarial review, counter-fraud screening brought forward to satisfy the audit action, reinsurance tracking added after the missed notifications. Where a section was revised after approval, it was reopened, changed, and taken back through review before the version was issued.
For a programme with a deadline that cannot move and a regulator entitled to ask how a decision was reached, that is the point. Not a document that looks thorough — one where every claim in it can be checked against a record of who agreed to it.
Build your own Digital Requirements Pack
Start free, no commitment, and see what Requio drafts for your project.
Get Started