---
title: "Insurance AI data layer vs investigation agent: where Verisk's Claude connectors stop"
description: "Verisk put two governed data connectors inside Claude on May 5, 2026. MCP's own architecture documentation calls that the data layer. What happens after the data arrives is a different layer entirely."
date: "2026-09-09"
lastModified: "2026-09-09"
author: "Nitish Badu"
tags: ["Vendor Comparison"]
canonical: "https://gethesperai.com/blog/verisk-mcp-data-layer-vs-investigation-layer/"
---

# Insurance AI data layer vs investigation agent: where Verisk's Claude connectors stop

> **TL;DR** On May 5, 2026 Verisk exposed two connectors inside Anthropic's Claude, Verisk Underwriting Intelligence (ISO Indications) and Verisk XactRestore, so insurance professionals can query governed data conversationally. The Model Context Protocol's own architecture documentation calls that layer the data layer. The layer above it, which decides what a flagged claim needs, reconciles sources that contradict each other and writes a defensible finding, is still a person's job at every carrier in the market.
>
> - Verisk's Claude launch surface is 2 connectors, neither of them fraud data
> - MCP's own docs name the inner layer the data layer, not Hesper marketing
> - New York logged 52,105 fraud reports in 2024 against 316 investigations opened

- **52,105 → 316** - Reports of suspected fraud received vs new investigations opened, New York Insurance Frauds Bureau, 2024 (NY DFS Consumer Protection and Financial Enforcement 2024 Annual Report)
- **2 connectors** - Verisk's launch surface inside Claude: Underwriting Intelligence and XactRestore (Verisk newsroom, May 5, 2026)
- **~60 platforms** - Online marketplaces Digital Asset Finder monitors, against 8 billion+ indexed data points (Verisk and Legentic, August 21, 2025)
- **~25% → 100%** - Flagged-claim coverage, manual SIU vs an autonomous investigation layer (Hesper internal benchmarks)

A data layer makes information reachable. An investigation agent decides what to do with it. The vocabulary there is not ours: the Model Context Protocol's own [architecture documentation](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture) calls its inner layer the data layer, and defines its job as context exchange rather than deciding anything. On May 5, 2026, Verisk shipped two MCP connectors into Anthropic's Claude and did exactly what that layer does.

If you already pay Verisk and you just watched its analytics land inside Claude, the practical question is whether that closes the investigation line item on your roadmap. It does not, and Verisk has not said it does. Lee Shavel, Verisk's President and CEO, framed the launch around explainability, saying decisions must be explainable and accountability remains with people. Read that sentence as an architecture statement rather than a compliance disclaimer and it tells you precisely where the product stops.

This is not a takedown. Verisk did what it said it did, and did it well: it made regulatory-grade data reachable inside a conversation, under its own governance framework. The interesting question is not whether Verisk left a gap. It is what still has to happen after the data arrives, and which layer of the stack owns that work.

The category frame underneath all of it is our [three-layer model of prevention, detection and investigation](/blog/insurance-fraud-prevention-vs-detection-vs-investigation/). This post extends that model into protocol territory. For the vendor-level version of the same argument, our [Hesper and Verisk comparison](/blog/hesper-vs-verisk/) covers what a data utility owns and what it does not.

## What Verisk actually shipped into Claude

Verisk's May 2026 collaboration with Anthropic exposes Verisk data to Claude through Model Context Protocol connectors, launching with two: Verisk Underwriting Intelligence, carrying ISO Indications loss costs, and Verisk XactRestore, carrying restoration and repair pricing. Both are query surfaces over governed data. Neither is a fraud product, and neither was presented as one.

The [announcement](https://www.verisk.com/company/newsroom/verisk-brings-its-trusted-analytics-and-generative-ai-capabilities-directly-into-anthropics-claude/) is dated May 5, 2026 out of Jersey City, and its own description of the mechanism is worth quoting in full: "Through MCP connectors, insurance professionals can access Verisk's proprietary, regulatory-grade data and analytics through generative AI, governed by Verisk's established data governance framework to support customers' controlled access and compliance needs." [Reinsurance News](https://www.reinsurancene.ws/verisk-integrates-insurance-analytics-gen-ai-with-anthropics-claude-via-mcp-connectors/) reported the launch the same day and named the same two connectors.

The precision matters more than it looks. Trade summaries compress this into "Verisk brings its analytics into Claude," and a claims reader can walk away believing ClaimSearch went into a chat window. It did not. ISO Indications is loss-cost guidance for pricing decisions. XactRestore is restoration pricing. ClaimSearch, ClaimDirector scoring and Xactimate estimating were not part of the launch surface. Anyone building a stack diagram off the headline should redraw it off the connector list.

> **What the launch connectors are, and what they are not**
>
> The two initial Verisk MCP connectors are Verisk Underwriting Intelligence (ISO Indications) and Verisk XactRestore. The first is underwriting loss-cost data. The second is restoration and repair pricing. Nothing in the May 5, 2026 launch surface is fraud-facing, and Verisk did not claim otherwise. Any statement that Verisk put its fraud data into Claude is wrong on the record as published.

Verisk's own framing is consistently human-centered, and it is stated plainly rather than buried. The release describes AI-enabled insurance workflows with "embedded governance and security controls that reinforce trust, ensure humans remain at the center of every decision," and notes that Verisk has deployed approximately 40 agentic and generative AI solutions grounded in proprietary data, domain expertise and transparent, explainable methodologies. Mike Ram, Head of Insurance at Anthropic, described the collaboration as showing how generative AI can enhance professional decision-making without compromising the rigor and accountability the industry demands.

> Trust is the foundation of insurance, and that doesn't change as new technologies emerge. What is changing is how professionals expect to interact with information.
>
> - Lee Shavel, President and CEO, Verisk, May 5, 2026

That is an accurate description of the shipped thing. How professionals interact with information changed. What a professional has to do with the information after they get it did not. Both of those can be true at once, and the second one is the whole subject of this post.

## What MCP is, in the protocol's own words

The Model Context Protocol is an open-source standard for connecting AI applications to external systems. Its documentation compares it to a USB-C port for AI applications. It defines a host, clients and servers, a JSON-RPC 2.0 message format, discovery and invocation methods, and three server primitives. It does not define what an application should conclude from any of it.

The [protocol introduction](https://modelcontextprotocol.io/docs/getting-started/intro) sets the shape. An MCP host is the AI application, Claude in this case, coordinating one or more clients. An MCP client maintains one connection to one server. An MCP server is described as "a program that provides context to MCP clients." Verisk built two servers. Claude is the host. That is the entire topology of the May announcement.

The architecture documentation then splits the protocol into two layers of its own: a data layer, covering the JSON-RPC 2.0 protocol, lifecycle management, discovery and the primitives, and a transport layer, covering stdio or Streamable HTTP, authorization and message framing. The phrase in this post's title is the protocol's own terminology. It is not a positioning device invented by a vendor with an investigation product to sell.

> MCP focuses solely on the protocol for context exchange.
>
> - Model Context Protocol architecture documentation, protocol version 2026-07-28. The same sentence goes on to state that MCP does not dictate how AI applications use LLMs or manage the context they are given.

The server primitives are equally explicit. Tools are "executable functions that AI applications can invoke to perform actions," with file operations, API calls and database queries given as examples. Resources are "data sources that provide contextual information to AI applications." Prompts are "reusable templates that help structure interactions with language models." On the client side, elicitation lets a server ask the user for more input or confirmation. Sampling and logging are deprecated as of protocol version 2026-07-28, which is a useful currency check when a vendor deck cites older MCP capabilities.

The method names tell the same story: server/discover, tools/list, tools/call, subscriptions/listen. Every request carries its protocol version and capabilities in a _meta field. That is a well-designed catalog-and-invoke interface, and it is a genuine improvement over bespoke point-to-point integrations, which is exactly why insurance vendors adopted it fast.

Where the deciding happens is stated in the spec documentation without ambiguity: when the language model decides to use a tool during a conversation, the AI application intercepts the tool call, routes it to the appropriate MCP server, executes it, and returns the results back to the LLM. The choosing sits in the model and the host application. MCP is the wire.

Two lazy readings need heading off here, because a technical reviewer will catch both. First, an MCP tool can be called by an agent, not only by a person typing into a chat window, so "MCP means a human is asking" is false. Second, an MCP integration is not a chatbot integration by definition. The narrower claim is the one that survives: exposing a capability over a protocol does not supply the thing that decides which capabilities a particular claim needs, in what order, and what to do when two of them disagree.

## The jobs between a data connection and a finished investigation

Between a reachable data source and a resolved claim sit four distinct jobs: access, invocation, orchestration and judgement. A protocol handles the first two. Anthropic's own engineering taxonomy separates the rest, and since the Verisk connectors run inside Claude, Anthropic's definitions are the fairest available yardstick.

[Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) defines workflows as "systems where LLMs and tools are orchestrated through predefined code paths," and agents as "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." The building block underneath both is what Anthropic calls the augmented LLM: a model enhanced with retrieval, tools and memory. Anthropic recommends MCP as the way to integrate that augmentation with third-party tools. So MCP sits underneath workflows and agents alike. It is the augmentation channel, not the autonomy.

Anthropic also states when an agent is the appropriate design: open-ended problems where it is difficult or impossible to predict the required number of steps, and where you cannot hardcode a fixed path. A flagged insurance claim is the textbook instance. You cannot know in advance how many checks a specific claim needs, because what phase three returns determines whether phases seven through eleven are required at all. A marketplace listing hit turns a total-loss file into a title-history file. A pay-stub inconsistency turns a lost-wages claim into an employment-verification file. The path is discovered, not scheduled.

The same document is honest about the cost of that design, and any SIU director should hold a vendor to it. Anthropic notes agents carry higher costs and the potential for compounding errors, and require extensive testing in sandboxed environments along with appropriate guardrails. That is the correct posture for anything that touches a claim file, and it is why the grading methodology matters as much as the architecture. We laid out how to test one in [evaluations for fraud investigation agents](/blog/evaluations-for-fraud-investigation-agents/).

What an investigation agent does with those four jobs is the difference. Hesper runs [15+ investigation phases in parallel](/blog/parallel-processing-siu-investigation-phases/) on every flagged claim, spanning document forensics, OSINT, statement cross-reference, timeline reconstruction and financial pattern analysis, then reconciles what those phases return into a single documented finding. The orchestration and memory design that makes that work is covered in our breakdown of [AI agent architecture for claims investigation](/blog/ai-agent-architecture-claims-investigation/).

For a CIO the integration shape is deliberately small, and it is the same shape whether the evidence arrives over MCP, an API, or a file drop. Read the flagged claim and its attached documents. Run the investigation outside the core system, against evidence the claims system was never designed to reach. Write one audit-ready finding back against the existing SIU activity, with sources, reasoning and timestamps attached. Nothing in that surface touches policy, billing, payments or reserves. The [architecture and audit-trail detail](/technology/) sits on our technology page.

## Where Verisk does automate investigative work

Verisk automates specific investigative checks and runs them continuously. In August 2025 it launched Digital Commerce Detector and Digital Asset Finder through an alliance with Legentic, monitoring nearly 60 online platforms against more than 8 billion indexed open-source data points. Neither tool waits for a human to commission a scan. That is the strongest counter-example to everything above.

The [August 21, 2025 launch](https://www.verisk.com/company/newsroom/verisk-unveils-new-claimsearch-tools-to-detect-digital-commerce-and-locate-assets-in-insurance-investigations/) describes an alliance rather than an acquisition. Legentic's technology was already deployed with European insurers and scales into the US for the first time through ClaimSearch, with Legentic citing more than 8 billion digital transactions indexed and over 6,000 platform users.

Digital Commerce Detector automates identification of suspicious activity on online marketplaces tied to stolen or total-loss assets, comparing claim details including VINs against a database of current and archived online sale listings. Verisk's own description of the trigger point is specific: as early as first notice of loss, claims professionals can have total loss claims flagged for further investigation based on attempts to sell those vehicles or their parts. Digital Asset Finder works the other end of the lifecycle, locating assets after settlement for recovery and subrogation using VINs, license plates, phone numbers and email addresses.

Concede the point plainly, because it is real. This is automated investigative work, running continuously, with no human commissioning each scan, and Digital Asset Finder pursues recovery after a claim has closed, which almost nothing else in the claims stack does. Verisk's own summary is that ClaimSearch users can monitor digital marketplaces continuously, automate investigative workflows, and improve claim outcomes. That is a fair description of what the pair does.

> Through seamless integration with ClaimSearch, this launch delivers automated access to previously hard-to-find, critical data points.
>
> - Jeff Ryan, Chief Product Officer, Anti-Fraud Analytics, Verisk, August 2025

Ron Vermeulen, CEO of Legentic, tied the timing to conditions on the ground, citing the surge in complex insurance fraud and theft cases in the US. For carriers, the auto book is where this lands hardest, and it is also where the public funnel data is most complete. Our [auto claims use case](/use-cases/auto-claims/) covers the VIN, total-loss and staged-accident patterns these tools touch.

## One standing question is not an investigation

The line between a monitoring tool and an investigation is scope and arbitration, not automation. A monitoring tool answers one standing question against one evidence class, continuously and well. An investigation decides which questions a specific claim raises, runs them together, and resolves what happens when two of the answers contradict each other.

Verisk's own phrasing draws the boundary better than any competitor could: the output is a claim flagged for further investigation. That is not hedging. It is an accurate statement of where a detection-and-monitoring product's job correctly ends and someone else's begins. Detection is upstream; investigation is downstream.

Take the case where the tool works perfectly. Digital Commerce Detector matches a VIN on a total-loss file against an archived marketplace listing. That hit is a lead, and a good one. Now list what has to happen next: pull and timestamp the listing history before it disappears, establish whether the listing is the whole vehicle or a parts teardown, reconcile the posting date against the reported date of loss, compare it against the insured's recorded statement about where the vehicle was, check the tow and salvage records, check whether the seller account ties to any party already on the claim, and decide whether the combination supports a referral, an examination under oath, or nothing at all. Then write it up so a state examiner reading the file in eighteen months can follow how the conclusion was reached.

None of that is a criticism of the tool. The tool answered its question. The list above is the investigation, and every item on it is currently a person's calendar entry. That is where 14+ days per case comes from, and it is why an investigator carrying 200+ open cases completes roughly 10 investigations a month.

### More matchable data does not change who arbitrates the match

On [July 23, 2026](https://insurance-edge.net/2026/07/23/weightmans-teams-up-with-verisk-on-anti-fraud-data/), UK law firm Weightmans and Verisk launched Fraud Rely, joining Weightmans' proprietary fraud database and counter-fraud legal expertise to Verisk's detection, matching and intelligence capability. The stated aim is moving teams "beyond reactive investigation towards earlier, proactive identification of potential fraud." Chris Sawford, Managing Director at Verisk, framed the driver as complexity: fraud is becoming more complex and connected, which makes early visibility increasingly important. No performance metrics have been published, and none should be inferred.

Read structurally, Fraud Rely widens the pool of things that can be matched. It does not change who resolves a match once one lands. That distinction is the whole subject of our piece on [what cross-carrier fraud data networks catch and what they miss](/blog/cross-carrier-fraud-data-networks-limits/), where the operating rule is that a match is a lead, not a verdict. The regulatory driver is UK rather than US: the article ties the appetite for early identification to the Economic Crime and Corporate Transparency Act 2023 and its new corporate offence of failure to prevent fraud. Prevention, detection and investigation are being regulated as separate obligations, which is the same taxonomy this post is drawing, arriving from the legal side.

### Ordering an investigation is not running one

The strongest version of the counter-argument comes from Carpe. Its [July 21, 2026 Carpe Claims launch](https://carpe.io/resources/press/carpe-launches-carpe-claims/) states that products support fully headless operation, native Model Context Protocol support and complete agentic interactivity, and that "a carrier's own AI systems can order an investigation, monitor a claimant, question the findings, and route the results without a human touching a screen." CEO Max Drucker's line is the short version: "We spent ten years building the deepest view of claims activity on the open web. Now we've given it hands." That is ahead of most of the market and it is a real architectural step. It is also a procurement action. Carpe's own Investigative Reports page schedules fulfilment at one to four days with human analyst verification, which we documented at length in [Carpe Data alternatives: ordering an investigation is not running one](/blog/carpe-data-alternatives/). Ordering is not running, and the full version of that argument lives there.

*Figure: The data arrives in a second. What it means is still sitting in someone's queue.*

## Everyone is building the seat

Five insurance MCP moves shipped between February and July 2026: One Inc, Duck Creek, Verisk, ACORD Solutions Group and Carpe. All five expose data, transactions or service orders. Four of the five explicitly keep a human or the carrier's own orchestrator in the deciding seat. That is an observation about the market, not a claim about any one vendor.

| Vendor | Date | What went over the protocol | Who holds the deciding seat |
| --- | --- | --- | --- |
| One Inc | February 3, 2026 | PremiumPay and ClaimsPay, running inside the customer's own approved AI environment | The carrier's own AI environment and its people |
| Duck Creek | April 28, 2026 | AI Gateway supporting MCP and A2A, to register Duck Creek, partner and customer-built agents | Whichever agent the carrier deploys into the gateway |
| Verisk | May 5, 2026 | Underwriting Intelligence (ISO Indications) and XactRestore, into Claude | The professional asking, with accountability remaining with people |
| ACORD Solutions Group | May 28, 2026 | ADEPT and ACORD Transcriber, over an MCP-enabled architecture | Agents operating within defined compliance, validation and audit controls |
| Carpe | July 21, 2026 | Online Injury Alerts and Investigative Reports, headless and MCP-native | The carrier's agent orders; a human analyst fulfils |

[Duck Creek's Agentic AI Platform](https://www.prnewswire.com/news-releases/duck-creek-launches-insurance-native-agentic-ai-platform-and-unveils-new-applications-to-transform-underwriting-and-claims-302755119.html), announced April 28, 2026, is the most architecturally ambitious of the five. It is built to deploy, orchestrate and govern AI agents across the insurance lifecycle, with an AI Gateway providing standardized protocols including MCP and A2A to integrate Duck Creek, partner and customer-built agents, and an AI Assurance component covering decision traceability, auditability, observability and compliance controls. CEO Hardeep Gulati described agentic AI as redefining how insurance operates, enabling carriers to move from manual, fragmented processes to orchestrated end-to-end decisioning. Its named claims application is Agentic FNOL: capture, validate and route at intake, with policy verification, coverage validation and early fraud detection at the front door.

That is the shape worth noticing. Duck Creek is building the orchestration seat inside the core system, positioned at intake, which is upstream of the flagged claim. [ACORD Solutions Group](https://www.prnewswire.com/news-releases/insurance-industry-is-now-agentic-ai-ready-with-mcp-architecture-from-acord-solutions-group-302784267.html) shipped the standards-body version on May 28, 2026, adding MCP-enabled architecture to ADEPT and ACORD Transcriber so agentic AI can execute end-to-end business and technical workflows spanning indication and appetite, quote, firm order, bind, endorsement, accounting, claims and financial settlement, within defined compliance, validation and audit controls. President and CEO Chris Newman called it a move from digital connectivity to intelligent, autonomous interaction. That is transactional workflow over standardized messages, which is a different thing from investigative reasoning and is not presented as one.

[One Inc](https://www.oneinc.com/resources/news/one-inc-unveils-model-context-protocol-to-accelerate-insurance-payments-integration-and-secure-ai-data-access) got there first, on February 3, 2026, exposing PremiumPay and ClaimsPay over MCP inside each customer's own approved AI environment rather than One Inc's hosted infrastructure, across a footprint the company puts at 300+ insurance carriers and $120 billion in premiums and claims annually. The named use cases are code generation, documentation, validation, testing and business-user reporting. It is the cleanest example in the set of MCP as an integration accelerator rather than as autonomy.

Put the five together and the pattern is hard to miss: nobody has shipped an MCP-callable thing that reasons across contradictory evidence and writes a defensible finding on a flagged claim. Detection vendors flag. Core systems file. Data utilities match, price and monitor. Service providers fulfil orders. The investigation layer has no incumbent except manual SIU teams, which is the same conclusion we reached counting agent launches in [agentic AI for insurance claims, where eight of nine agents talk and one investigates](/blog/agentic-ai-insurance-claims-beyond-fnol/), and the same stage-level gap mapped in our [claims automation guide](/blog/claims-automation-pillar/).

Duck Creek and ACORD should be read as a tailwind rather than a threat, and saying so costs nothing. A governed agent gateway with a registry, standardized protocols and decision traceability is more valuable to an investigation agent than to almost any other kind of software, because it is the deployment surface. Building the seat is genuinely useful work. It is just not the same work as supplying the investigator who sits in it.

## What the gap costs while the plumbing improves

Better access to data does not change how many flagged claims get worked. The clearest public illustration is New York's Insurance Frauds Bureau, where reports received rose from 30,113 in 2020 to 52,105 in 2024, a 73% increase, while new investigations opened moved from 324 to 316, a 2.5% decline. Input scaled. Investigative capacity did not.

| New York Insurance Frauds Bureau, 2020-2024: bar length is reports of suspected fraud received; the label carries new investigations opened that year | Value | Share |
| --- | --- | --- |
| 2020 - 324 new investigations opened | 30,113 reports | 58% |
| 2021 - 283 new investigations opened | 34,201 reports | 66% |
| 2022 - 279 new investigations opened | 38,554 reports | 74% |
| 2023 - 341 new investigations opened | 44,998 reports | 86% |
| 2024 - 316 new investigations opened | 52,105 reports | 100% |

Those figures come from Appendix 1 of the [New York Department of Financial Services Consumer Protection and Financial Enforcement Division 2024 Annual Report](https://www.dfs.ny.gov/system/files/documents/2025/03/nysdfs-2024-cpfed-annual-rpt-20250315.pdf), published March 15, 2025. Read the caveat before you use the numbers: the Insurance Frauds Bureau is the state regulator's bureau. The 52,105 are reports insurers sent to the state, and the 316 are cases the state opened. This is not carrier SIU coverage and should never be quoted as such. What it is, is a primary-source illustration of the same structural pattern that shows up inside a carrier: referral volume scales with automation, and investigative capacity does not.

| Jurisdiction and unit | Period | Referrals received | Cases opened or assigned | Arrests |
| --- | --- | --- | --- | --- |
| New York Insurance Frauds Bureau, all units | 2024 | 52,105 | 316 | 227 |
| New York Medical and No-Fault Unit | 2024 | 41,686 | 71 | Not reported separately |
| New York Auto Unit | 2024 | 5,451 | 97 | Not reported separately |
| California Fraud Division, automobile program | FY2023-24 | 12,559 | 602 | 272, plus 354 cases referred to prosecutors |

The Medical and No-Fault row is the most extreme sub-funnel in the dataset: 41,686 reports received in 2024 against 71 investigations opened. California tells the same story from a different regulator. In fiscal year 2023-24 the [California Department of Insurance Fraud Division](https://www.insurance.ca.gov/0300-fraud/0100-fraud-division-overview/10-anti-fraud-prog/Automobile.cfm) received 12,559 suspected fraudulent claims in its automobile program, assigned 602 new cases, made 272 arrests, referred 354 cases to prosecuting authorities, and put the potential loss at $207,629,944. Dividing the first two numbers gives 4.8%, a calculation from the department's own published figures rather than a published statistic.

None of this says the work is not worth doing. The same New York report states that insurers reported $3.5 billion in savings resulting from SIU investigations in 2023, the most recent year available, plus $40.3 million in recoveries, filed under the annual SIU reporting obligation that accompanies New York Insurance Law section 409 and its requirement that a fraud prevention plan provide for a full-time Special Investigations Unit with staffing levels set on objective criteria. Investigation returns money. There is simply a hard ceiling on how much of it any staffed unit can do.

For a claims VP the implication is a single line: adding a connector to a data utility does not change how many flagged claims get worked. It changes how quickly a person can look something up. The coverage number moves only when the unit cost and cycle time of a full investigation move. Manual SIU runs 14+ days and roughly $2,500 per case, which is why carriers fully investigate about 25% of flagged claims while the rest are paid, denied without full work, or queued. At roughly $150 per case, and hours rather than weeks, the threshold for what is worth working moves and coverage goes to 100%. Those are Hesper internal benchmarks; the model behind them is on our [coverage and cost calculator](/roi/).

The pool being drawn from is not small. The [Coalition Against Insurance Fraud](https://insurancefraud.org/fraud-stats/) puts US insurance fraud at $308.6 billion a year and reports that fraud occurs in about 10% of property-casualty insurance losses. Every improvement in detection, matching and monitoring raises the number of claims that arrive at the investigation layer. That is the mechanism by which better plumbing makes the downstream bottleneck worse rather than better.

> **Where Hesper sits, stated plainly**
>
> Hesper AI does not score claims for a carrier that already has a scoring vendor, does not adjudicate, and does not replace a system of record. It takes a flagged claim, runs 15+ investigation phases in parallel, reconciles what they return, and produces an audit-ready finding in hours instead of 14+ days, with sources, reasoning and timestamps logged as it goes. Hesper is complementary to FRISS, Shift Technology, and Verisk - not a replacement. It also has built-in fraud detection and works standalone, which matters for carriers whose referrals come from adjuster judgment and configured rules rather than a purchased score. From fraud detection to fraud resolution describes the layer, not the decision. The SIU lead still signs the finding.

## The layer table

Seven layers sit between a record in a database and a documented investigative conclusion. Each one has a different actor, a different output and a different stopping point. Most vendor confusion in this category comes from comparing products that occupy different rows as though they were competing for the same one.

| Layer | What it does | Who acts | What it outputs | Where it stops |
| --- | --- | --- | --- | --- |
| System of record and data utility (ISO ClaimSearch, Xactimate, ISO Indications, Legentic listings index) | Holds records, prices, matches and scores | The carrier's system, on a schedule or on submission | A record, a match, a score, a price | It knows what is in the data. It does not know what this claim needs |
| Access protocol (MCP) | Standardizes how an AI application discovers and calls tools and reads resources over JSON-RPC 2.0 | Nobody. It is a wire format | A tool result, returned to whoever asked | It moves context. It does not decide anything |
| Assistant with connectors (Verisk data inside Claude) | Lets a professional query governed data in natural language, in one window | A human, asking | An answer in a conversation | The human sets the goal, judges the answer and carries it into the file |
| Continuous monitoring tool (Digital Commerce Detector, Digital Asset Finder, Online Injury Alerts) | Runs one standing query against one evidence class, continuously | The tool, autonomously, within its scope | A flag, an alert, a hit, flagged for further investigation | One question, one evidence class. It does not reconcile its hit against contradicting evidence |
| Agent-callable service (Carpe Claims over MCP) | Lets a carrier's own AI order a service without a screen | The carrier's agent orders; a human analyst fulfils | A commissioned report, delivered later | Ordering is not running. Someone still fulfils, reconciles and concludes |
| Orchestration platform (Duck Creek AI Gateway, ACORD ADEPT) | Registers, routes and governs agents across the lifecycle | Whichever agent the carrier deploys into it | A governed execution path | It provides the seat. It does not supply the investigator who sits in it |
| Investigation agent (Hesper) | Decides which checks a flagged claim needs, runs 15+ phases in parallel, resolves contradictions, writes the finding | The agent, end to end, with a human SIU lead reviewing | An audit-ready investigative report with sources, reasoning and timestamps | Adjudication. The SIU lead and the adjuster make the call |

Two rows in that table do work most comparisons skip. The continuous monitoring row is the honest concession: it is autonomous, it is investigative, and it is genuinely valuable. The orchestration row is the one carriers most often mistake for the last row, because a platform that can govern agents sounds like a platform that has one. The seat and the occupant are different purchases.

> Every layer below the investigation agent answers a question somebody already knew to ask. The layer that has never been productized is the one that decides which questions this claim raises, runs them together, and says what the combination means when two of them disagree.
>
> - Hesper AI product research

## How to tell which layer a vendor is selling

Four questions separate a data connection from an investigation agent, and all four can be asked in a demo without a technical briefing. They work because they interrogate the artefact at the end rather than the architecture in the middle, and the artefact is what a state examiner eventually reads.

1. Who decides which checks this claim needs, your system or my staff? If the answer is your staff, you are buying a data layer, and that is a legitimate purchase. It is just not investigative capacity.
2. What happens when two of your sources disagree with each other? A marketplace listing that contradicts a recorded statement is the normal case, not the edge case. Ask to see the arbitration behavior on a real file, not on a slide.
3. What is the artefact at the end: a result, a report, or a documented decision with its reasoning attached? Results and reports are inputs. Only the third one closes anything.
4. If a state examiner pulls this file in eighteen months, what does the record show about how the conclusion was reached? Ask which sources were consulted, in what order, what each returned, and what was concluded from the combination.

The fourth question is where most stacks come apart, because the documented chain usually reconstructs from a completion date and a disposition code typed in after the fact rather than from the work itself. That is the standard we wrote up in [the defensibility standard for fraud investigation AI](/blog/fraud-investigation-ai-defensibility-standard/), and it is the reason an investigation agent has to be audit-trail-native rather than audit-trail-capable. Logging is a design decision made before the first phase runs, not a report generated afterward.

Nothing here argues that a carrier should buy fewer data layers. ISO Indications, XactRestore, ClaimSearch, Digital Commerce Detector and a governed agent gateway are all worth what they cost, and Verisk making them reachable in a conversation is a real improvement to a professional's day. The argument is narrower: those purchases do not add investigative capacity, so they should not be scored against that line in a procurement memo. If you are building that memo now, our [rundown of Verisk alternatives](/blog/verisk-alternatives/) covers the detection shortlist and the [2026 AI fraud platforms buyer's guide](/blog/ai-fraud-platforms-compared-2026-pillar/) maps prevention, detection and investigation vendor by vendor.

The honest read on May 5, 2026 is that Verisk shipped a useful thing and described it accurately. Trusted data became reachable in a conversation, under governance, with accountability remaining with people. Take that last clause literally and it is a statement about where the work still lives. Every hour of investigative work behind that accountability is still a person's hour, and the queue those hours are drawn from keeps getting longer. Make every flagged claim investigable and the rest of the stack gets to keep doing what it already does well.

## Key takeaways

- Verisk's May 5, 2026 Anthropic collaboration launched with two MCP connectors, Verisk Underwriting Intelligence (ISO Indications) and Verisk XactRestore, covering underwriting loss costs and restoration pricing rather than anything fraud-facing.
- The data layer framing is the protocol's own vocabulary: MCP's architecture documentation names its inner layer the data layer and states that MCP focuses solely on the protocol for context exchange, without dictating how an application uses a model or manages context.
- Verisk does automate investigative work through Digital Commerce Detector and Digital Asset Finder, which run continuously across nearly 60 platforms and more than 8 billion indexed data points, and Verisk's own description of the output is a claim flagged for further investigation.
- Five insurance MCP moves shipped between February and July 2026 across One Inc, Duck Creek, Verisk, ACORD Solutions Group and Carpe, and all five expose data, transactions or service orders rather than investigative judgement.
- New York's Insurance Frauds Bureau received 52,105 reports of suspected fraud in 2024 and opened 316 new investigations, up from 30,113 reports and 324 investigations in 2020, which is what it looks like when referral volume scales with automation and investigative capacity does not.

## Frequently asked questions

### What is the difference between an AI data layer and an AI investigation agent in insurance?

A data layer makes information reachable. An investigation agent decides what to do with it. Verisk's May 2026 MCP connectors put governed analytics inside Claude, specifically ISO Indications loss costs and XactRestore restoration pricing, so a professional can query them conversationally. The Model Context Protocol's own architecture documentation calls that its data layer and states that MCP focuses solely on the protocol for context exchange, without dictating how an application uses a model or manages context. An investigation agent sits above that. It decides which checks a flagged claim needs, runs them in parallel, reconciles sources that contradict each other, and produces an audit-ready finding. One makes data available. The other reaches a documented conclusion a human reviews.

### Does the Model Context Protocol make an AI system autonomous?

No. MCP is a connection standard, not an agent architecture. It defines a client-server protocol over JSON-RPC 2.0 with three server primitives: tools, which are executable functions an AI application can invoke, resources, which are data sources that provide contextual information, and prompts, which are reusable templates. It also defines discovery and invocation methods such as tools/list and tools/call. What MCP does not define is which tool to call, in what order, or what to conclude. The protocol documentation is explicit that the language model decides to use a tool and the host application intercepts, routes and executes the call. Autonomy lives in the model and the orchestration around it, not in the wire between them.

### What did Verisk actually announce with Anthropic?

On May 5, 2026, Verisk announced that its analytics are available inside Claude through Verisk MCP connectors, launching with two: Verisk Underwriting Intelligence, carrying ISO Indications, and Verisk XactRestore. Underwriters can query loss-cost indications and claims professionals can query restoration pricing in natural language without moving between systems. Verisk framed the launch around governance, stating that decisions must be explainable and accountability remains with people, and that humans remain at the center of every decision. The company noted it has deployed approximately 40 agentic and generative AI solutions. The launch connectors are underwriting and restoration data. They are not ClaimSearch, not ClaimDirector scoring and not any fraud-investigation surface.

### Does Verisk automate fraud investigation?

Verisk automates specific investigative checks, which is real and worth stating plainly. In August 2025 it launched Digital Commerce Detector and Digital Asset Finder through a strategic alliance with Legentic. Digital Commerce Detector compares claim details including VINs against current and archived online listings so total-loss claims can be flagged as early as first notice of loss. Digital Asset Finder monitors nearly 60 online platforms and indexes more than 8 billion open-source data points to detect when a stolen asset resurfaces for sale after settlement. Both run continuously without a human commissioning each scan. Both answer one standing question against one evidence class, and Verisk's own language for the output is that the claim is flagged for further investigation.

### If our carrier already uses Verisk, do we still need an investigation layer?

Yes, because they solve different problems, and Verisk's own launch language says so. Verisk supplies contributory data, cross-carrier matching, scoring, pricing and targeted monitoring, and positions all of it as supporting human decisions with accountability remaining with people. None of that changes how many flagged claims a Special Investigations Unit can work in a month. New York's Department of Financial Services recorded 52,105 reports of suspected fraud in 2024 against 316 new investigations opened by its Insurance Frauds Bureau. California's Fraud Division received 12,559 automobile suspected fraudulent claims in fiscal 2023-24 and assigned 602 new cases. Detection is upstream; investigation is downstream. Hesper is complementary to Verisk, not a replacement.

### Which insurance vendors have shipped MCP integrations?

Five notable moves in six months. One Inc exposed PremiumPay and ClaimsPay over MCP on February 3, 2026, running inside each customer's own approved AI environment. Duck Creek launched its Agentic AI Platform on April 28, 2026, with an AI Gateway supporting MCP and A2A to register Duck Creek, partner and customer-built agents. Verisk shipped Claude connectors on May 5, 2026. ACORD Solutions Group added MCP-enabled architecture to ADEPT and ACORD Transcriber on May 28, 2026. Carpe made its flagship claims products headless and MCP-native on July 21, 2026. All five expose data, transactions or service orders, and four of the five explicitly keep a human or the carrier's own orchestrator in the deciding seat.

### Is an MCP connector the same as an agent-callable investigation?

Not quite, though the gap is narrower than it looks. An MCP tool can be called by an agent rather than a person. Carpe's July 2026 launch says a carrier's own AI systems can order an investigation, monitor a claimant, question the findings and route the results without a human touching a screen, which is a genuine architectural step. But ordering is not running. Something still has to fulfil the order, and something still has to decide which orders this particular claim warrants, sequence them, resolve them when they conflict, and write the finding. Exposing a capability over a protocol does not supply the judgement that selects among capabilities and arbitrates between their answers.

### How do you tell whether a vendor sells a data layer or an investigation layer?

Ask four questions in the demo. First, who decides which checks this claim needs, your system or my staff? Second, what happens when two of your sources disagree with each other? Third, what is the artefact at the end: a result, a report, or a documented decision with its reasoning attached? Fourth, if a state examiner pulls this file in eighteen months, what does the record show about how the conclusion was reached? Data layers answer the first question with your staff and the third with a result. That is not a criticism of them. It is the boundary of what they sell, and most of them state it clearly in their own materials.

### Does an agentic claims platform like Duck Creek's replace an investigation agent?

No, and the two are complementary rather than competing. Duck Creek's April 2026 Agentic AI Platform provides an AI Gateway with standardized protocols including MCP and A2A, so carriers can deploy, orchestrate and govern agents across the lifecycle, with an AI Assurance component covering decision traceability, auditability, observability and compliance controls. Its named claims application is Agentic FNOL: capture, validate and route at intake, with policy verification, coverage validation and early fraud detection at the front door. That is a governed seat for agents to run in, positioned at the front of the claim. An investigation agent is an occupant of that seat, working the flagged claim downstream. Building the platform is not the same as building the investigator.

### What does an AI investigation agent do that a data connector does not?

It takes a flagged claim and runs the SIU playbook end to end. Hesper runs 15+ investigation phases in parallel, including document forensics, OSINT, statement cross-reference, timeline reconstruction and financial pattern analysis, then reconciles what those phases return and produces an audit-ready report with sources, reasoning and timestamps attached. Manual SIU investigation runs 14+ days per case; the agent works in hours, not weeks. The practical consequence is coverage rather than speed: carriers fully investigate roughly 25% of flagged claims today, and the model is built to make every flagged claim investigable. The human SIU lead still reviews the finding and makes the adjudication call, and the investigator's role shifts from execution to decision-making.