Using Claude and ChatGPT to build insurance pricing models: what works and what doesn't

AI clients such as Claude and ChatGPT can now connect to external tools through the Model Context Protocol (MCP). For insurance pricing, that means an AI assistant can read the rules for building a model, draft one, check it and run its tests, all from a conversation.

We have used this approach on a range of products. This article sets out what it does well, where it struggles and how to set it up so that people stay in control of every change.

Connecting an AI client

The Ptally MCP server is at https://ptally.ai/mcp. In Claude you add it as a custom connector, and in Claude Code or Cursor you add it as a remote MCP server. The client opens a Ptally sign-in page, you paste your API key pair once, and from then on the client works with a token rather than your keys. Our MCP page has the details for each client.

Once connected, the assistant can use these tools:

• get_docs and get_schema to read the modelling rules and the model layout;
• get_starter to fetch a ready-made example model for a common line of business;
• validate_project to check a model for mistakes;
• get_projects and get_project to read your saved projects;
• run_quote to price a quote as a dry run, with nothing saved;
• run_version_tests to price every test on a version and compare it with the expected result;
• patch_version to make changes to a draft version;
• get_health to check the service.

What works well

Drafting a model from a starter

Asking the assistant to start from a similar example model and adapt it to your rating guide is much more reliable than asking it to write a model from nothing. The starter gives it a correct structure, and it changes the inputs, tables and formulas to match your product.

Validating as it goes

The assistant can validate a model after each change and fix structural mistakes straight away, such as a missing default value or a reference to a field that does not exist. This catches most errors before any quote is priced.

Running the tests

With your worked examples stored as tests, the assistant can price every one and report which pass and which fail. When a test fails, it can read the debug trace and point at the step where the value first differs from what you expect. Our quote debugging page shows what that trace contains.

Small, targeted changes

For changes such as updating a region factor, adding a row to a table or adjusting a fee, the assistant sends a precise patch to a draft version. The server validates the result, saves it, records it in the audit trail and runs the tests, then the assistant reports what changed.

Explaining a model

Asking an assistant to explain how a model calculates a premium, or why a particular quote was referred, is one of the most useful things it does. It reads the model and the trace and answers in plain English.

Where it struggles

Ambiguous rating guides

If the rating guide does not say whether a discount applies before or after a minimum premium, the assistant will make an assumption. Sometimes it will be wrong. Ask it to list the assumptions it made, and check each one with the pricing team. Worked examples in the rating guide remove most of this ambiguity.

Very large tables

Clients can only take a limited amount of data in a single response, so rate tables over 100 rows are shown to the assistant as a sample. Changes to those tables go through download and upload: you download the full model, the assistant amends the file and checks it, and you upload it to a new draft. The assistant should tell you which route applies before it changes anything.

Changing expected results

The most serious mistake an assistant can make is to change a test's expected result so that a failing test passes. Expected results should only change when a person decides they should, with a reason. Make this an explicit instruction, and review any change to a test's expected output as carefully as a rate change.

Judgement calls

Decisions such as how to treat an unusual risk, whether to refer or decline, or how to handle a gap in the data are pricing decisions. The assistant can set out the options, but a person should make the call.

Keeping people in control

The setup that works for us has a few simple rules:

1. Agents edit drafts only. The patch tool only changes draft versions. Approving and publishing happen in the Ptally dashboard, by a person.
2. Tests run on every change. Every patch is followed by a test run, and failures are reported rather than hidden.
3. Every change is recorded. Patches are written to the audit trail, so you can see what the assistant changed and when.
4. Review the report, then the change. Read the test results and the summary first, then check the specific edits.

Used this way, an AI assistant takes on the slow, repetitive parts of model building while the pricing decisions stay with your team. Our article on why pricing models should be human readable explains why the model format makes this review practical.

Getting started

Connect your AI client to https://ptally.ai/mcp and start with the reference tools, which need no sign-in. When you are ready to build a real product, our consultants can work alongside your team or build the model for you. There is no implementation fee and nothing to pay upfront. Talk to our team.