Summary
A small insurer's work is mostly the same few things done again and again: renewals, payment runs, reminders, broker downloads, statistical files and data keyed from one form into another. Most of it needs no judgment. Most of it is still done by hand, one file at a time, or by a legacy system that only its vendor can change.
A machine-first mutual flips that arrangement. The system does the routine work by itself, on a business clock, under rules the mutual writes and dates itself. People spend their time on the decisions that need a person: the risks outside appetite, the claims that need a conversation, the changes to price and wording. Anything that binds a policy, cancels one, or moves money waits for a person to confirm it, and every action, by a person or a machine, is recorded with who did it and why.
And because the rules, screens and letters that run a mutual are data rather than code, one mutual's good work can be handed to the next as a package, reviewed and installed in minutes. A platform shared by mutuals gets more useful with each one that joins, which suits a sector that was built on members pooling what they have.
That is the design of MutualOS. This paper sets out the argument for it, the commitments that make it safe, and what it does not yet prove.
Machine-first, people in charge. The machine does the routine; people make the calls; the record shows which was which.
Three costs that keep mutuals still
Work done one file at a time
In a file-by-file operation, a renewal diary asks the same question of hundreds of policies one at a time. A broker's application arrives as a document and is keyed in again. A data problem found on one policy is fixed on that policy, and the next one with the same problem waits for someone to notice it. The people with the most judgment spend a large share of their day on work that needs none.
Every change is a project
On many legacy systems, adding a question to the home application, changing a surcharge or rewording a letter means a request to the vendor, a quote, a wait and a release. So the mutual stops asking. Underwriting rules that should be in the system live in a binder, a spreadsheet or someone's memory.
Switching is the scariest project a mutual will run
Everyone knows the legacy system is holding them back, and everyone knows a conversion can go wrong in public: premiums that do not match, balances that do not reconcile, a renewal cycle missed. The cost of switching is the real reason small insurers stay where they are.
Three whys
- Why machine-first? Because routine work done by hand is slow, uneven and expensive, and it crowds out the judgment that members pay a mutual for. A system that renews, bills, reminds, reports and downloads by itself does those things the same way every time, and shows its working.
- Why people in charge? Because an insurer's decisions are promises to members, and a board, a regulator and a court will ask who made them. Automation that cannot be traced to a rule a person approved, or a click a person made, is a liability, however clever it is.
- Why now? Because the tools to do both have become practical for a small insurer. Rules can be written, checked and forecast by the people who own them, without a developer. An AI assistant can read a broker's application, fill a quote and explain a bill, while the system makes sure it cannot do more than the person using it. And a small insurer can run its own isolated system in a Canadian cloud region without running a data centre.
What machine-first means
Machine-first is a division of labour, written down and enforced. The system's share is everything that follows from a rule. The people's share is everything that needs judgment, and every change to the rules themselves.
| The system does | People decide |
|---|---|
| Offers renewals, rated by the mutual's own rules | The rules, the rates and when a change takes effect |
| Refers a risk outside appetite, with the rule that caught it | Whether to accept the risk, and on what terms |
| Runs payment withdrawals, reminders and non-payment notices | Refunds over a limit, write-offs and exceptions |
| Builds broker downloads and the statistical file each period | What the mutual reports and to whom |
| Reads a broker's application and fills the quote | Whether to bind it |
| Reminds the right person on the right day | What to do about it |
The line between the two columns is not a matter of trust in the software. It is set by the mutual and checked on the server, every time.
Six commitments that make it safe
1. One API for people, machines and the assistant
Every screen in MutualOS calls the same API that a nightly job, a partner system or an AI client calls, through the same permission check and into the same audit log. There is no back door for automation and no second integration layer to drift out of step. If a person cannot do something, neither can a job or an assistant acting for them.
2. The assistant acts as you, and waits for you
The assistant uses the signed-in person's own permissions. It prepares freely: it finds the policy, opens the change, fills what it knows and quotes. It does not commit. Binding, cancelling, reinstating, moving money and changing access each wait for that person's Confirm, and every action it takes is marked in the audit log as the assistant's.
3. Rules and rates are dated data, and money needs two people
The mutual's underwriting rules, variables and rate tables live in its own system as versions with effective dates. A rule is checked when it is saved. Before a change that moves premium goes live, the people proposing it see a forecast over real policies: premium now against proposed, decisions that would flip, and the effect by broker and premium band. Then a second person approves it. A rule written by the assistant is only ever a draft.
4. History is never rewritten
Every policy change carries two dates: when it applies and when the mutual knew it. So the question "what did this policy say on 1 March, as we knew it then" always has an exact answer, which is what a claim dispute or an audit needs. Policy history, the ledger and the audit log are insert-only, refused at the database, and kept for good.
5. One model, with your own fields on top
Each kind of record has a fixed base, which is the record a regulator relies on and which staff cannot edit in place. Everything else the mutual wants to keep is a custom field it adds itself. The model changes with the business; the record of what was promised does not.
6. Exceptions, not files
People are brought in where judgment is needed: referrals that go to someone with the authority, reminders on a policy or claim for a given day that never stop a renewal, review lists set to the mutual's own thresholds, and batches that change a whole set of policies at once with a preview first. The file reaches a person when it is an exception, not because the calendar says so.
Mutuals share what works
Mutuals are not each other's main competition. Many write the same lines in neighbouring counties, face the same weather, answer to the same regulator and report to the same statistical agent. Yet each one works out its farm questions, its referral rules and its renewal letters by itself, and pays for it again every time the legacy vendor makes the change.
A machine-first platform changes that, because the setup that runs a mutual is configuration, not code. Fields, screens, option lists, rules, variables and letters are already dated data that an administrator reviews before they publish. Wrap a selection of them in a signed file and they can travel. Built
- A package is configuration only. It carries no code and no member data, so installing one can do nothing an administrator could not have typed in, and sharing raises no privacy question.
- It goes through the receiver's own review. A preview shows every item it adds or changes before anything is written. It installs as a draft, and anything that moves premium needs a forecast and a second person, exactly like a change made in house. Undo takes it back in one step.
- It says who built it. Each mutual signs what it shares, and the receiver can see the file was not changed on the way.
- The receiver's own edits survive upgrades, and removing a package retires what it added rather than deleting answers policies already hold.
This is the network effect a mutual platform should have. Each mutual that joins brings work the next one can start from, so the cost of a good setup falls for everyone, and the sector's knowledge stops living in one binder at one company. It is also the old idea of a mutual, members pooling what they have, applied to the systems that run them.
A day at a machine-first mutual
This is an illustration. The mutual and its people are invented.
- Before anyone arrives, the daily jobs run: renewal offers inside the renewal window, rated by this year's rules; the day's PAC withdrawals; payment reminders; a non-payment notice where the period has run out; reminders that fall due today, sent to the person or team named on them.
- At 8:30, an underwriter opens My work. Three renewals were referred overnight, each saying which rule caught it. She accepts two and calls the broker on the third. A fourth policy, not due for months, is already flagged: its next term was re-worked after a claim last week and now needs a look.
- At 9:15, a customer service rep asks the assistant to add a lender to a member's policy. It opens the change, fills the lender's details and shows the result. She checks it and confirms.
- At 11:00, the underwriting manager drafts a change to the wood stove surcharge, forecasts it over the book, and sends it to a colleague to approve, effective at the next renewal date she chooses.
- At 2:00, finance approves the refunds over the mutual's limit and a supplier's invoice that arrived by email.
- At the end of the business day, each brokerage's AL3 file goes out over CSIOnet and the closed day is posted to the books. At month end, the statistics file and the board pack are made by themselves.
Nobody keyed in a broker's application, chased a payment by hand or opened a policy because a diary said so.
What a board will ask, and the answers
A mutual's board, its regulator, its auditor and its reinsurer will each ask a version of the same questions about any automated decision. The design has to answer them by construction, not by a report written afterwards.
- Who decided this? Every change names the person, their role, the reason, and whether the assistant or a job acted. Every rule that fired says so in the policy's history.
- What did you know when you decided? Two dates on every change, and the outside data a quote was priced on kept with the rating, so a past decision can be replayed exactly.
- Who approved the rule? Every rule and rate change is a dated version, with its forecast and its second approver on record.
- Can you stop it? Rules have effective and expiry dates; a rule can be retired; the assistant can only prepare until a person confirms.
- Is it fair to members? Automation only applies the mutual's own approved rules. Rate experiments are bounded and recorded per policy, and are refused on lines with filed rates, such as Ontario auto.
Model-risk guidance, such as OSFI's Guideline E-23, and Ontario's rules on unfair or deceptive practices are the yardsticks these questions come from. A mutual should take its own advice on how they apply to it; the platform's job is to make the evidence easy to produce.
Conversion is the way in
None of this matters if a mutual cannot get onto it safely. So MutualOS treats conversion as part of the product, not a services project:
- Load the legacy book from the mutual's own extract, as often as it likes, and reconcile it to the cent per policy.
- Map legacy codes once; a person confirms each mapping the assistant proposes, and any value with no mapping is listed with how many records hold it, never guessed.
- Run both systems side by side for weeks, with a cutover checklist and sign-offs, so cutover weekend is a refresh the team has already done many times.
- One direction, one cutover, no write-back: one system of record at a time.
Where it goes next
The next step is to move people from working on files to working on the book. The groundwork is going in now: every policy carrying its projected next term, kept current as the policy, its claims and the rules change, so a renewal that will need a person shows up months ahead. Built Two larger pieces are in design.
Pending fixes
Find a data problem across the book, such as every policy renewing next year with a missing roof year, record the fix once, and let each policy take it up at its next renewal. Nothing is stopped and no endorsement is issued for a correction that only matters to the next rating. Fixes that change the premium are disclosed in the renewal notice; facts material to the risk today are refused as pending fixes and handled as a change now.
The Portfolio desk
One screen for the person who owns a segment of the book, such as seasonal dwellings or one brokerage's business. It shows what the segment writes, keeps and loses money on, with every figure opening the policies behind it and a warning where the counts are too small to trust. A rate or rule change is forecast over the segment before it is made, through the same review the platform already uses.
What we do not claim
We have no customer results to publish yet, so we publish none. MutualOS does not claim a percentage of time saved, an improvement in loss ratio, or that an insurer can be fully automated. The research and the regulators point the same way we do: the machine does more of the work, and a person stays accountable for the decision. When a design partner's own figures exist, we will publish them with their source.
MutualOS is built by 10xtech. Everything described as present in this paper runs in MutualOS today; items marked Coming are in design or being built.