Download Report

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Read the Complete Report!

Thank you! Your submission has been received, Now you can view the complete report!
Oops! Something went wrong while submitting the form.

The Real Cost of Carrier Integrations

Cyrus-Karai
April 7, 2026
1 min read

How $500K Becomes $2M+ — And Why the Math Never Works Out

Competitors are quoting and binding faster, winning business that used to come easily. The problem is familiar: submission and quoting processes still run through email threads, spreadsheets, PDFs, and manual portal logins. The solution seems obvious — build an in-house API integration layer. Connect directly to your top carriers. Automate quote requests, bind confirmations, and policy issuance. Own the technology.

So you hire. Three engineers. Or maybe offshore, to stretch the budget further. Someone who’s worked at a carrier and understands their system structures. You set a budget of $500,000–$600,000 and a timeline of 12 months. The pitch is compelling: one-time investment, permanent competitive advantage.

Eighteen months later, you’ve spent over $1,000,000. The team needed more oversight than expected. Scoping gaps surfaced early, features like multi-location quoting weren’t in the original spec, because no one asked the right questions upfront. Two engineers moved on. You have three carrier connections in production for a single line of business, and one broke last month when they updated underwriting questions without notice.

Here’s the math that should have been on the whiteboard from day one: each carrier integration takes six to nine months and the maximum throughput is six integrations — for a single line of business. But wholesalers don’t operate in a single LOB. Clients want Workers’ Comp and BOP and General Liability. Each additional line multiplies the integration count. And none of this accounts for the hours consumed every month by maintenance on recently built connections.

Carrier integration is not a discrete build. It’s an ongoing operational capability, and the economics behave accordingly. This pattern repeats across the wholesale insurance industry with remarkable consistency. The details vary, but the arc is almost always the same.

It’s not a failure of execution. It’s a failure of scope. The project is never as contained as it looks on the whiteboard. Can you afford 18 months of building something that won’t differentiate — while your competitors are already out there selling?

Why Build In-House

Understanding why companies make this choice is important, because the reasoning is not irrational. The problems that drive the decision are real. The competitive pressure is real. The frustration with manual processes is real. What’s missing is an accurate picture of what the solution actually entails.

Trigger 1: Competitive Pressure Peaks

At some point, competitors start winning on speed. A quote-and-bind that took two days now takes them two hours. The intelligence from the field is consistent: companies that invested in digital connectivity are taking market share.

Sometimes the pressure arrives as a specific, painful failure closer to home — a quote lost in an email chain, a renewal that lapsed because a manual follow-up fell through the cracks, a client lost coverage during a gap that a digital workflow would have prevented.

The response: catch up. The fastest path seems to be building what competitors appear to have. What’s invisible from the outside, however, is how much those competitors actually spent — and continue to spend to maintain it — and how many now question whether in-house was the right call. Competitive urgency drives toward the fastest-seeming solution, not the most sustainable one.

The Big Mistake: Treating carrier API connectivity as a one-time project rather than an ongoing, resource-intensive operational capability. Connecting to a carrier API isn’t like installing software — it requires continuous maintenance as dozens of independent systems evolve on their own timelines.

Trigger 2: The Manual Process Breaking Point

The daily reality of quoting through manual workflows eventually becomes untenable. Your team is logging into 5, 8, 12 different carrier portals every day. Each has a different interface, its own login credentials, its own quirks. Submission data must be re-keyed from emails into spreadsheets, into portal forms — each handoff introducing error and eating time better spent on underwriting and client relationships.

The frustration compounds. A retail agent sends a submission. Your team enters it into one carrier portal, waits, enters it into another, waits again. Two days later, they assembled three quotes that took six hours of manual entry. The agent already placed the business elsewhere.

The build-it-yourself instinct makes sense: if we can automate these submissions using direct API connections, we eliminate the portal juggling, reduce errors, and get quotes back in minutes instead of days. The logic is sound. What’s underestimated is the engineering complexity required — and to keep it working once built.

Trigger 3: Control Over the Quoting Experience

In a desire to own the entire end-to-end quoting process, there’s often a strategic dimension to the build-out. Wholesalers want to control how quotes are presented to agents — their own UI, workflow logic, branding. The fear with a third-party platform is that the quoting experience becomes commoditized, and the wholesaler loses the ability to differentiate how they deliver quotes, not just that they deliver them.

This is a legitimate concern. But it introduces a critical confusion that trips up many organizations: the customer-facing experience and the backend connectivity layer are two fundamentally different engineering problems. You absolutely should own and customize your front-end — the interface retail agents interact with, the workflow logic that reflects underwriting appetite, the branding that reinforces market position.

What you don’t need to build is the plumbing underneath. The API connectivity, carrier data normalization, and ongoing maintenance of those connections are infrastructure problems, not differentiation problems. When companies confuse the two, they end up splitting their engineering resources between front-end experience work and back-end connectivity work — and both suffer. The team that should be building a best-in-class quoting interface is instead debugging carrier payload schemas.

How the Build Unravels

The first sign something’s off usually appears around month four or five. The initial estimate assumed a relatively clean integration process: a carrier provides documentation, the team builds to spec, the connection goes live. The reality is far messier.

Problem 1: Carrier APIs Are Moving Targets — And the UWQ Problem Is Massive

Carrier APIs do not arrive as finished products with stable specifications. They’re living systems, updated continuously in response to new product launches, regulatory changes, rating engine migrations, and internal platform upgrades. But the most persistent and painful changes aren’t the big, announced ones, rather they’re the constant shifts in underwriting questions and class codes.

Each carrier maintains over a thousand underwriting questions per line of business. These questions change regularly, and a carrier regularly updates their risk appetite, adds a new eligibility criterion, restructures their class code taxonomy, or modifies how they want location data submitted. These changes often arrive without advance notice. An integration that returned quotes yesterday now returns errors, and your team must spend days identifying which of the thousand-plus fields changed and how.

Now multiply this across carriers. Finding and maintaining common underwriting questions across ten carriers, each with their own terminology, their own question hierarchies, their own answer formats, is an enormous normalization challenge. It’s not just mapping; it’s ongoing reconciliation as each carrier independently evolves their question sets on their own timeline.

The math worsens fast. Each integration takes six to nine months to build properly. With three engineers working in parallel, maximum throughput is six integrations — and that covers a single line of business. When your clients need Workers’ Comp, BOP, and General Liability, the integration count doesn’t just add — it multiplies. A 10-carrier, 3-LOB strategy means 30 carrier-LOB integrations. Even with parallel development, you’re looking at years of build work before you’re fully connected.

And none of this includes the maintenance burden. With 10 carriers each making 3 to 5 significant changes per year, the team is managing 30+ change events annually — all before they’ve written a single line of new feature code.

Based on CoverForce’s integration experience across its carrier network: carriers make an average of 3–5 significant API changes per year. A 10-carrier integration portfolio generates 30+ change events annually that require immediate engineering response — and that’s before counting UWQ and class code updates, which happen far more frequently.

Problem 2: The Universal Data Model Problem

The single hardest technical challenge in carrier integration isn’t connecting to any one carrier’s API. It’s building a data model that works across all.

Each carrier structures data differently. One expects location data as a nested object with separate fields for each address component. Another wants a flat string. One carrier uses SIC codes for business classification; another uses NAICS; a third uses a proprietary class code system. Underwriting questions that seem equivalent, “Does the business have a swimming pool?” arrive in different formats, with different answer options, under different field names, in different positions within the payload.

The technology diversity compounds the problem. Carrier APIs span decades of technology evolution. Some carriers offer modern REST APIs with JSON payloads. Others still operate on SOAP services with XML schemas. A few require direct database connections or flat file exchanges. Building an integration layer that normalizes all of this — that presents a clean, consistent interface to your front-end, while translating to and from each carrier’s particular technology and data format behind the scenes — is an extraordinarily complex engineering challenge.

Most teams underestimate this by an order of magnitude. The initial plan assumes a shared data model with carrier-specific adapters. In practice, the adapters grow into complex subsystems of their own, each carrying carrier-specific business logic, exception handling, and transformation rules that resist standardization. The “universal” model becomes a patchwork of compromises that works adequately for three carriers and breaks when you add a fourth.

Problem 3: The Insurance + Engineering Knowledge Gap

Building a carrier integration layer requires a rare intersection of skills: deep insurance domain expertise and serious API systems engineering experience. This combination doesn’t really exist in the talent market.

Engineers who have built robust API platforms — who understand rate limiting, retry logic, webhook orchestration, data pipeline architecture, fault tolerance — typically come from fintech, e-commerce, or SaaS backgrounds. They’ve never navigated the specifics of insurance underwriting workflows, carrier submission requirements, or the nuances of how a BOP class code differs from a WC class code.

People who understand insurance — who can read a carrier’s underwriting guidelines and know what a submission needs to look like — typically haven’t built API abstraction layers. They know what the data should say, but not how to build the systems that move it reliably at scale.

Building a common abstraction layer requires a very specific engineering experience: not just API development, but the discipline of building middleware that brings together wildly diverse systems never designed to talk to each other. This is the core technical challenge: taking REST APIs, SOAP services, JSON payloads, XML schemas, and proprietary formats from dozens of carriers and unifying them behind a single, reliable interface. Great technology-building experience is as important as insurance domain knowledge, and finding both in the same team is exceptionally difficult.

This is why teams that look strong on paper still struggle. Three excellent engineers who have never built cross-system integration middleware and who are simultaneously learning insurance domain logic, will take twice as long and build something half as robust as a team that has done it many times before.

The True Cost — And Why the Budget Always Doubles

Every problem described above feeds the same outcome: the budget doubles, the timeline stretches, and the scope contracts. A 9-month project becomes 14 months. What was budgeted at $500,000 tracks toward $900,000 before the first carrier goes live.

The project doesn’t fail dramatically — it doesn’t get cancelled. It erodes. The ambitious 10-carrier plan becomes 5, then 4. Each review brings a revised timeline and a revised budget. Leadership remains committed because the sunk cost is real, and the original problem — the need for digital carrier connectivity — hasn’t gone away.

The project has consumed the engineering capacity that was supposed to be building the product features customers actually want and need. A year and a half of competitive product development has been traded for integration infrastructure that’s partially functional and fully expensive to maintain.

When organizations tally an in-house build, they typically only count direct engineering spend. What they undercount or miss entirely are the costs that make the actual number two to four times higher.

3-Year Total Cost of Ownership: In-House Carrier Integration Build

Article content

The opportunity cost line deserves particular attention, because it doesn’t appear in any budget. If your engineering team spends 40–45% of its capacity maintaining carrier integration infrastructure, and that team costs $1.2M annually, you’re paying $480,000–$540,000 per year in foregone product development — features not built, improvements not shipped, competitive ground not gained. Over three years, that number rivals the direct build cost itself.

A Different Way to Think About It

Think of carrier connectivity like a city’s water infrastructure. Every building needs clean water. But no one expects each building to dig a well, build its own treatment plant, and maintain its own pipe network from source to tap.

The city builds the water main, the shared infrastructure that serves everyone. Each building only needs to construct the last mile: the internal plumbing that delivers water exactly how they need it, to the specific fixtures and layouts that make their building unique.

Carrier integration works the same way. The connectivity layer — the API connections, the data normalization, the carrier relationship management, the ongoing maintenance — is the water main. It’s essential infrastructure that everyone in the wholesale insurance ecosystem needs. But it’s infrastructure that every participant shouldn’t have to build separately.

Your differentiation isn’t in the pipes. It’s in the last mile — the quoting experience, the underwriting logic, the client-facing workflows that make your operation distinct. That’s where your engineering investment should go.

How CoverForce Changes the Equation

CoverForce was built on this insight. By connecting once to CoverForce’s API platform, wholesalers and agents access a continuously updated, maintained, and growing network of carrier integrations — without inheriting build cost, maintenance burden, or the opportunity cost that comes with running that plumbing infrastructure themselves.

Today, CoverForce maintains live integrations with 25+ carriers across 6 lines of business — Workers’ Comp, BOP, CGL, Cyber, MPL, and Builders Risk — with 50+ unique carrier-LOB combinations in production. Carriers like CHUBB, GAIG, and Hiscox are connected across four lines of business each. The network continues to grow.

The costs that are fixed and unavoidable when building in-house — dedicated engineering capacity, carrier API monitoring, UWQ change management, relationship management — are amortized across CoverForce’s entire network of participants. Each organization pays a fraction of what they would bear alone, while benefiting from infrastructure maintained by a team whose sole focus is exactly this problem.

Engineering capacity returns to your core product. Carrier connections stay current without your team touching them. UWQ and class code changes are absorbed centrally. And the 12–18 months you would have spent building become months of competitive product development instead.

Internal Build vs. CoverForce Comparison

Article content

The Decision

Carrier connectivity will only expand in scope as insurers continue to modernize systems and regulatory expectations evolve. The capability will be mandatory.

The question isn’t whether your team can build carrier integrations. With enough time and money, they will eventually get there. The question is whether building and maintaining that infrastructure is the highest-value use of their time — and whether your organization should bear the full cost of a problem that every participant in the wholesale insurance ecosystem shares.

The wholesale market is consolidating around speed and access. The firms pulling ahead aren’t doing it by out-engineering their competitors on plumbing. They’re doing it by making smarter decisions about where engineering effort actually creates value.

Carrier integration is shared infrastructure. Building it independently multiplies cost without multiplying advantage. The firms that outperform will be those that directed engineering capital toward underwriting intelligence, analytics, and client experience — not those that spent it maintaining API connections.

How $500K Becomes $2M+ — And Why the Math Never Works Out

Competitors are quoting and binding faster, winning business that used to come easily. The problem is familiar: submission and quoting processes still run through email threads, spreadsheets, PDFs, and manual portal logins. The solution seems obvious — build an in-house API integration layer. Connect directly to your top carriers. Automate quote requests, bind confirmations, and policy issuance. Own the technology.

So you hire. Three engineers. Or maybe offshore, to stretch the budget further. Someone who’s worked at a carrier and understands their system structures. You set a budget of $500,000–$600,000 and a timeline of 12 months. The pitch is compelling: one-time investment, permanent competitive advantage.

Eighteen months later, you’ve spent over $1,000,000. The team needed more oversight than expected. Scoping gaps surfaced early, features like multi-location quoting weren’t in the original spec, because no one asked the right questions upfront. Two engineers moved on. You have three carrier connections in production for a single line of business, and one broke last month when they updated underwriting questions without notice.

Here’s the math that should have been on the whiteboard from day one: each carrier integration takes six to nine months and the maximum throughput is six integrations — for a single line of business. But wholesalers don’t operate in a single LOB. Clients want Workers’ Comp and BOP and General Liability. Each additional line multiplies the integration count. And none of this accounts for the hours consumed every month by maintenance on recently built connections.

Carrier integration is not a discrete build. It’s an ongoing operational capability, and the economics behave accordingly. This pattern repeats across the wholesale insurance industry with remarkable consistency. The details vary, but the arc is almost always the same.

It’s not a failure of execution. It’s a failure of scope. The project is never as contained as it looks on the whiteboard. Can you afford 18 months of building something that won’t differentiate — while your competitors are already out there selling?

Why Build In-House

Understanding why companies make this choice is important, because the reasoning is not irrational. The problems that drive the decision are real. The competitive pressure is real. The frustration with manual processes is real. What’s missing is an accurate picture of what the solution actually entails.

Trigger 1: Competitive Pressure Peaks

At some point, competitors start winning on speed. A quote-and-bind that took two days now takes them two hours. The intelligence from the field is consistent: companies that invested in digital connectivity are taking market share.

Sometimes the pressure arrives as a specific, painful failure closer to home — a quote lost in an email chain, a renewal that lapsed because a manual follow-up fell through the cracks, a client lost coverage during a gap that a digital workflow would have prevented.

The response: catch up. The fastest path seems to be building what competitors appear to have. What’s invisible from the outside, however, is how much those competitors actually spent — and continue to spend to maintain it — and how many now question whether in-house was the right call. Competitive urgency drives toward the fastest-seeming solution, not the most sustainable one.

The Big Mistake: Treating carrier API connectivity as a one-time project rather than an ongoing, resource-intensive operational capability. Connecting to a carrier API isn’t like installing software — it requires continuous maintenance as dozens of independent systems evolve on their own timelines.

Trigger 2: The Manual Process Breaking Point

The daily reality of quoting through manual workflows eventually becomes untenable. Your team is logging into 5, 8, 12 different carrier portals every day. Each has a different interface, its own login credentials, its own quirks. Submission data must be re-keyed from emails into spreadsheets, into portal forms — each handoff introducing error and eating time better spent on underwriting and client relationships.

The frustration compounds. A retail agent sends a submission. Your team enters it into one carrier portal, waits, enters it into another, waits again. Two days later, they assembled three quotes that took six hours of manual entry. The agent already placed the business elsewhere.

The build-it-yourself instinct makes sense: if we can automate these submissions using direct API connections, we eliminate the portal juggling, reduce errors, and get quotes back in minutes instead of days. The logic is sound. What’s underestimated is the engineering complexity required — and to keep it working once built.

Trigger 3: Control Over the Quoting Experience

In a desire to own the entire end-to-end quoting process, there’s often a strategic dimension to the build-out. Wholesalers want to control how quotes are presented to agents — their own UI, workflow logic, branding. The fear with a third-party platform is that the quoting experience becomes commoditized, and the wholesaler loses the ability to differentiate how they deliver quotes, not just that they deliver them.

This is a legitimate concern. But it introduces a critical confusion that trips up many organizations: the customer-facing experience and the backend connectivity layer are two fundamentally different engineering problems. You absolutely should own and customize your front-end — the interface retail agents interact with, the workflow logic that reflects underwriting appetite, the branding that reinforces market position.

What you don’t need to build is the plumbing underneath. The API connectivity, carrier data normalization, and ongoing maintenance of those connections are infrastructure problems, not differentiation problems. When companies confuse the two, they end up splitting their engineering resources between front-end experience work and back-end connectivity work — and both suffer. The team that should be building a best-in-class quoting interface is instead debugging carrier payload schemas.

How the Build Unravels

The first sign something’s off usually appears around month four or five. The initial estimate assumed a relatively clean integration process: a carrier provides documentation, the team builds to spec, the connection goes live. The reality is far messier.

Problem 1: Carrier APIs Are Moving Targets — And the UWQ Problem Is Massive

Carrier APIs do not arrive as finished products with stable specifications. They’re living systems, updated continuously in response to new product launches, regulatory changes, rating engine migrations, and internal platform upgrades. But the most persistent and painful changes aren’t the big, announced ones, rather they’re the constant shifts in underwriting questions and class codes.

Each carrier maintains over a thousand underwriting questions per line of business. These questions change regularly, and a carrier regularly updates their risk appetite, adds a new eligibility criterion, restructures their class code taxonomy, or modifies how they want location data submitted. These changes often arrive without advance notice. An integration that returned quotes yesterday now returns errors, and your team must spend days identifying which of the thousand-plus fields changed and how.

Now multiply this across carriers. Finding and maintaining common underwriting questions across ten carriers, each with their own terminology, their own question hierarchies, their own answer formats, is an enormous normalization challenge. It’s not just mapping; it’s ongoing reconciliation as each carrier independently evolves their question sets on their own timeline.

The math worsens fast. Each integration takes six to nine months to build properly. With three engineers working in parallel, maximum throughput is six integrations — and that covers a single line of business. When your clients need Workers’ Comp, BOP, and General Liability, the integration count doesn’t just add — it multiplies. A 10-carrier, 3-LOB strategy means 30 carrier-LOB integrations. Even with parallel development, you’re looking at years of build work before you’re fully connected.

And none of this includes the maintenance burden. With 10 carriers each making 3 to 5 significant changes per year, the team is managing 30+ change events annually — all before they’ve written a single line of new feature code.

Based on CoverForce’s integration experience across its carrier network: carriers make an average of 3–5 significant API changes per year. A 10-carrier integration portfolio generates 30+ change events annually that require immediate engineering response — and that’s before counting UWQ and class code updates, which happen far more frequently.

Problem 2: The Universal Data Model Problem

The single hardest technical challenge in carrier integration isn’t connecting to any one carrier’s API. It’s building a data model that works across all.

Each carrier structures data differently. One expects location data as a nested object with separate fields for each address component. Another wants a flat string. One carrier uses SIC codes for business classification; another uses NAICS; a third uses a proprietary class code system. Underwriting questions that seem equivalent, “Does the business have a swimming pool?” arrive in different formats, with different answer options, under different field names, in different positions within the payload.

The technology diversity compounds the problem. Carrier APIs span decades of technology evolution. Some carriers offer modern REST APIs with JSON payloads. Others still operate on SOAP services with XML schemas. A few require direct database connections or flat file exchanges. Building an integration layer that normalizes all of this — that presents a clean, consistent interface to your front-end, while translating to and from each carrier’s particular technology and data format behind the scenes — is an extraordinarily complex engineering challenge.

Most teams underestimate this by an order of magnitude. The initial plan assumes a shared data model with carrier-specific adapters. In practice, the adapters grow into complex subsystems of their own, each carrying carrier-specific business logic, exception handling, and transformation rules that resist standardization. The “universal” model becomes a patchwork of compromises that works adequately for three carriers and breaks when you add a fourth.

Problem 3: The Insurance + Engineering Knowledge Gap

Building a carrier integration layer requires a rare intersection of skills: deep insurance domain expertise and serious API systems engineering experience. This combination doesn’t really exist in the talent market.

Engineers who have built robust API platforms — who understand rate limiting, retry logic, webhook orchestration, data pipeline architecture, fault tolerance — typically come from fintech, e-commerce, or SaaS backgrounds. They’ve never navigated the specifics of insurance underwriting workflows, carrier submission requirements, or the nuances of how a BOP class code differs from a WC class code.

People who understand insurance — who can read a carrier’s underwriting guidelines and know what a submission needs to look like — typically haven’t built API abstraction layers. They know what the data should say, but not how to build the systems that move it reliably at scale.

Building a common abstraction layer requires a very specific engineering experience: not just API development, but the discipline of building middleware that brings together wildly diverse systems never designed to talk to each other. This is the core technical challenge: taking REST APIs, SOAP services, JSON payloads, XML schemas, and proprietary formats from dozens of carriers and unifying them behind a single, reliable interface. Great technology-building experience is as important as insurance domain knowledge, and finding both in the same team is exceptionally difficult.

This is why teams that look strong on paper still struggle. Three excellent engineers who have never built cross-system integration middleware and who are simultaneously learning insurance domain logic, will take twice as long and build something half as robust as a team that has done it many times before.

The True Cost — And Why the Budget Always Doubles

Every problem described above feeds the same outcome: the budget doubles, the timeline stretches, and the scope contracts. A 9-month project becomes 14 months. What was budgeted at $500,000 tracks toward $900,000 before the first carrier goes live.

The project doesn’t fail dramatically — it doesn’t get cancelled. It erodes. The ambitious 10-carrier plan becomes 5, then 4. Each review brings a revised timeline and a revised budget. Leadership remains committed because the sunk cost is real, and the original problem — the need for digital carrier connectivity — hasn’t gone away.

The project has consumed the engineering capacity that was supposed to be building the product features customers actually want and need. A year and a half of competitive product development has been traded for integration infrastructure that’s partially functional and fully expensive to maintain.

When organizations tally an in-house build, they typically only count direct engineering spend. What they undercount or miss entirely are the costs that make the actual number two to four times higher.

3-Year Total Cost of Ownership: In-House Carrier Integration Build

Article content

The opportunity cost line deserves particular attention, because it doesn’t appear in any budget. If your engineering team spends 40–45% of its capacity maintaining carrier integration infrastructure, and that team costs $1.2M annually, you’re paying $480,000–$540,000 per year in foregone product development — features not built, improvements not shipped, competitive ground not gained. Over three years, that number rivals the direct build cost itself.

A Different Way to Think About It

Think of carrier connectivity like a city’s water infrastructure. Every building needs clean water. But no one expects each building to dig a well, build its own treatment plant, and maintain its own pipe network from source to tap.

The city builds the water main, the shared infrastructure that serves everyone. Each building only needs to construct the last mile: the internal plumbing that delivers water exactly how they need it, to the specific fixtures and layouts that make their building unique.

Carrier integration works the same way. The connectivity layer — the API connections, the data normalization, the carrier relationship management, the ongoing maintenance — is the water main. It’s essential infrastructure that everyone in the wholesale insurance ecosystem needs. But it’s infrastructure that every participant shouldn’t have to build separately.

Your differentiation isn’t in the pipes. It’s in the last mile — the quoting experience, the underwriting logic, the client-facing workflows that make your operation distinct. That’s where your engineering investment should go.

How CoverForce Changes the Equation

CoverForce was built on this insight. By connecting once to CoverForce’s API platform, wholesalers and agents access a continuously updated, maintained, and growing network of carrier integrations — without inheriting build cost, maintenance burden, or the opportunity cost that comes with running that plumbing infrastructure themselves.

Today, CoverForce maintains live integrations with 25+ carriers across 6 lines of business — Workers’ Comp, BOP, CGL, Cyber, MPL, and Builders Risk — with 50+ unique carrier-LOB combinations in production. Carriers like CHUBB, GAIG, and Hiscox are connected across four lines of business each. The network continues to grow.

The costs that are fixed and unavoidable when building in-house — dedicated engineering capacity, carrier API monitoring, UWQ change management, relationship management — are amortized across CoverForce’s entire network of participants. Each organization pays a fraction of what they would bear alone, while benefiting from infrastructure maintained by a team whose sole focus is exactly this problem.

Engineering capacity returns to your core product. Carrier connections stay current without your team touching them. UWQ and class code changes are absorbed centrally. And the 12–18 months you would have spent building become months of competitive product development instead.

Internal Build vs. CoverForce Comparison

Article content

The Decision

Carrier connectivity will only expand in scope as insurers continue to modernize systems and regulatory expectations evolve. The capability will be mandatory.

The question isn’t whether your team can build carrier integrations. With enough time and money, they will eventually get there. The question is whether building and maintaining that infrastructure is the highest-value use of their time — and whether your organization should bear the full cost of a problem that every participant in the wholesale insurance ecosystem shares.

The wholesale market is consolidating around speed and access. The firms pulling ahead aren’t doing it by out-engineering their competitors on plumbing. They’re doing it by making smarter decisions about where engineering effort actually creates value.

Carrier integration is shared infrastructure. Building it independently multiplies cost without multiplying advantage. The firms that outperform will be those that directed engineering capital toward underwriting intelligence, analytics, and client experience — not those that spent it maintaining API connections.

Related Articles

Insights
Kaivan Wadia
July 8, 2026
1 min read

You have the green light. The contract is signed, the kickoff meeting is on the calendar, and your engineers are ready to ship. They still can't write a line of carrier-specific code — and depending on which carrier sits across the table, they might not be able to for another four weeks.

The prerequisite stage doesn't look like engineering work. It is engineering work. And it's where most integration timelines quietly break.

In Part 1 we laid out the full seven-stage map of a carrier integration. This post zooms in on stage two — the gap between contract signed and first line of code written.

What "ready to build" actually means

On paper, the prereq stage sounds like paperwork — kickoff calls, doc exchanges, a sandbox login. In practice, it's a technical stage with three technical exit criteria, and all three have to land before engineers can productively build.

First, a working communication cadence. Named technical POC on the carrier side — and the right one: many carriers route integration questions through program managers or support engineers rather than the engineers who built the API, which means answers come back slower and sometimes wrong, because the person on the other end is guessing too. A channel better than email-only. An SLA on response time that you actually trust. Shipping an integration requires hundreds of small questions — why did this endpoint return 500, what does this enum value actually mean, what's the expected payload shape for this edge case — and the answer speed on those questions is what determines whether a four-week build takes four weeks or ten.

Second, complete documentation in hand. Not "partial docs, we'll figure the rest out later." Complete — API reference, appetite, class codes, underwriting questions, sample payloads, producer-code model, supported states and products. Incomplete documentation doesn't show up as a visible blocker; it shows up as silent rework three weeks into the build, when an endpoint behaves differently than the PDF said it would.

Third, a successful sandbox call. Your code, authenticated, hitting their test environment, getting a non-error response back. This is the canonical proof point — but by itself it's not enough. Skip any of the three and the build phase turns into a multi-week discovery phase in disguise.

Not when the contract closes. Not when a kickoff call happens. That's when the prereq stage actually ends.

A median integration

One recent integration is a useful composite. The contract closed on a Tuesday. Week one, we were told the carrier required a live agency partner — a real human at a real agency customer — to co-sign the sandbox setup before we could get a login. That partner had a day job, and took six days to respond. Week two, we learned the carrier required IP whitelisting, which meant our request had to route through their security team's change-management queue, behind a stack of unrelated tickets. Week three, the API documentation arrived — three PDFs, an Excel workbook of class codes, another workbook of underwriting questions, and no Swagger at all. Week four, we finally got a 200 back from their sandbox.

But we still didn't have a real communication channel — the carrier's tech lead only answered questions in a 30-minute weekly sync. And two of the seven endpoints we needed were missing from the documentation entirely.

Four weeks in, zero lines of carrier-specific code written, and we weren't actually ready to build yet. This isn't a horror story. Every one of these moments has actually happened — sometimes on one integration, more often spread across several. The variance is the point.

The real pattern is variance

Here's the part that doesn't fit on a project plan: every carrier surfaces a different subset of the same list of potential roadblocks.

Some carriers drop you into a shared sandbox with generic credentials on day one. Others require a dedicated test agency that takes weeks to provision. Some expose token-based auth with a clean OpenAPI spec. Others require static-IP whitelisting routed through a security review queue. Some ship documentation as a Postman collection you can import in thirty seconds. Others arrive with a ZIP of sample XML on an email thread. Some have a Slack Connect channel and answer questions in under an hour. Others only answer questions in a 30-minute weekly meeting.

You can't reliably predict which combination a specific carrier will surface until you're already in it. The master list is knowable. The specific subset for any given integration is not — until someone has already taken the punches on that carrier before.

Variance, not volume, is the real problem. And variance compounds as the number of carriers in your portfolio grows.

Knowing what to ask is the skill

Our preliminary-question list reads as a forensic checklist because it is one. Every item exists because an earlier integration stalled on something we forgot to ask about in week one.

We now ask, before a single engineer opens a code editor: What's your preferred communication channel? What's your API documentation format, and can you share it end-to-end? How do you deliver appetite, class codes, and underwriting questions — and in what format? What states and products are in-scope? Do you require IP whitelisting? What's the producer-code provisioning model — self-served or manual per agency? Are there test-environment requirements we should know about now, including sponsored agency setups or special credentials? Can you share at least one sample end-to-end request and response?

The length of that list is not a bug. It's the argument. Carriers routinely ship incomplete documentation — not because they're sloppy, but because nobody on their side has been asked the right question before. The integrator's job is to ask it.

What good looks like

Not every integration is painful. AmTrust is a useful counter-example. Their API surface is well-structured. Their documentation is coherent. Their discovery package arrives organized enough that the prereq stage closes on the shorter end of our range rather than the longer end. When a carrier arrives this well-organized, integrations ship weeks sooner, with fewer back-and-forth cycles.

In our experience, the quality of the discovery package is a leading indicator of the quality of the integration three months later. Carriers who take documentation and onboarding seriously tend to have APIs that take edge cases seriously. It's not a coincidence. It's the same engineering culture showing up in both places.

What this means if you're integrating in-house

You can build the muscle to run this checklist on every carrier. You can develop the institutional memory to know which roadblocks to anticipate on which carrier. You can stand up the infrastructure — proxy services, credential stores, standardized sandbox provisioning — that makes the prereq stage repeatable.

Or you can rent it.

If you're integrating one or two carriers, the in-house path works. You'll take the scars and you'll earn them. If you're integrating ten, the variance compounds faster than your engineering capacity scales. That's the trade-off, and it's a cleaner trade-off than most conversations make it out to be.

Part 3 digs into what happens after that first sandbox call lands — when the carrier's documentation and the carrier's actual API start to disagree.

Insights
Kaivan Wadia
July 6, 2026
1 min read

Every brokerage, wholesaler, MGA, bank, and insurtech eventually asks the same question: should we build this ourselves?

It sounds like an engineering question. It isn't. It's a commitment question. And almost every organization that asks it is working from an incomplete map.

We've built more than sixty carrier integrations across thirty-plus carriers. Along the way we've learned something that isn't obvious from the outside: a carrier integration is not a project you ship once. It's an operational discipline you commit to indefinitely. The code is the smallest part.

This is the first post in a ten-part series on the hidden cost of carrier connectivity. Think of it as the map. Every post that follows is a deep dive into one region of that map.

Why we're the ones drawing this map

We've built more than sixty carrier integrations across thirty-plus carriers. Travelers, Liberty Mutual, Chubb, AmTrust, CNA, Nationwide, Employers, Guard, Pie, Coterie, Hiscox, Coalition, and most of the rest of the admitted and surplus market. Six lines of business: Workers' Comp, BOP, General Liability, Cyber, MPL, and Property. The full carrier list, by line and state, lives in our appetite guide.

Our platform powers ISU, AmWins, One80/PMC, Jencap, Bridge Specialty Group, Normandy, and many more.

We ship five to ten new integrations every quarter. Our team can take a new carrier from first technical call to production in eight to ten weeks. The industry average for a single direct carrier integration, from what peer teams tell us, is closer to nine months.

More than one carrier has told us, unprompted, that we were the fastest integration they'd ever worked with.

We say all of that not as a credential check, but because everything that follows in this series comes from scars. We've made most of the mistakes the series is about to describe. The map we're drawing is the one we wish someone had drawn for us four years ago.

The map

A carrier integration, end to end, is seven stages. Only three of them look like engineering.

  1. Legal and business case. Data-sharing agreements, PII handling, and aligning on the business case with the carrier. Often the first thing to stall, and the last thing anyone plans for.
  2. Technical kickoff. Finding the actual engineers on the carrier side, getting documentation, getting credentials for the sandbox and a test agency, agreeing on how both teams will communicate for the next two months.
  3. Capability mapping. Which of the seven capabilities does this carrier's API actually support — bindable quote, quote proposal, bind, payment plans, policy documents, appetite, underwriting questions? Almost no carrier supports all seven. The gaps are the work.
  4. Build. Mapping the carrier's data model to a canonical model, handling authentication quirks, implementing retry and idempotency, building the error taxonomy, writing the audit log that has to be replayable for years.
  5. Carrier testing. Running the carrier's test cases. Re-running them when sandbox and production diverge — which they will.
  6. Rollout. Staged launch: internal dogfood, pilot agencies, then broader release, with per-carrier monitoring that surfaces what testing missed.
  7. Monthly maintenance. Appetite revisions, class-code changes, underwriting-question drift, API version upgrades, new functionality. Forever.

Most internal estimates describe stages three through five. That's where teams imagine the work lives. In our experience, stages one and seven are where the calendar actually disappears — regardless of whether the company doing the build is a brokerage, a wholesaler, or an insurtech.

The part the carrier team rarely sees

Here is the central insight we've earned by doing this sixty-plus times:

The team that built the carrier's API rarely experiences the real integration burden.

They wrote a spec. They implemented it. They tested it against their own internal callers. They didn't translate their class codes into someone else's canonical schema while that schema also had to work for twenty-nine other carriers. They didn't maintain a conditional underwriting-question engine that renders the right questions for the right applicant to the right carrier — versions of which will change without notice. They didn't reconcile a bind confirmation against a payment captured two systems away.

Every one of those problems is real. Every one of them is where the time goes. And every one of them is invisible from the side of the table that wrote the API. That asymmetry is the source of most of the misaligned expectations in this work.

The tax you pay every month

The other thing missing from most build estimates is maintenance.

Carriers ship appetite changes. They revise class codes. They add required underwriting questions. They deprecate API versions. They fix a bug in production that quietly changes the shape of a response. None of this arrives with a changelog you can subscribe to.

Across our integrations, something changes on the carrier side roughly every week. It's on the integrator to detect, reconcile, and either absorb transparently or surface to the customer — before an agent finds out the wrong way.

If your organization builds this in-house, every hour your engineers spend here is an hour they are not spending on the product your customers are actually paying you for. That opportunity cost compounds — whether you're a brokerage, a wholesaler, or an insurtech building a differentiated experience on top of carrier rails.

What the rest of the series covers

Every post from here is a deep dive into one piece of this map.

  • Part 2 — Before the first line of code. Discovery, identifying technical POCs, spinning up a test agency, and getting access to the carrier's developer environment.
  • Part 3 — Reading the menu. How to assess a carrier API before committing to build against it.
  • Part 4 — The translation problem. Data normalization: class codes, legal entities, payroll, losses, limits.
  • Part 5 — The integration stack. Authentication, transformation, retry, normalization, audit — layer by layer.
  • Part 6 — The 500-question iceberg. Underwriting questions: the single most underestimated piece of a carrier integration, and the one that reshapes the application as you answer it.
  • Part 7 — Testing carrier integrations. Why sandbox isn't enough, and what replaces it.
  • Part 8 — Beyond quote. Bind, payment, and document retrieval — where integrations quietly fall apart.
  • Part 9 — The silent-breakage tax. Why every carrier integration decays without notice — class codes, underwriting questions, and appetite all change without a changelog — and what it costs to keep one alive.
  • Part 10 — Build vs. buy. The honest decision framework, once the full picture is on the table.

If you're evaluating the build

Over the next few months we'll go deep on each of these. If your company is evaluating whether to build carrier connectivity in-house — brokerage, wholesaler, MGA, bank, or insurtech — start here. It's the cheapest place to change your mind.

We've been down this road more than fifty times. We'd rather you make the decision with a clear map than a clean slate.

June 1, 2026
1 min read

Commercial insurance has its own language, and most of it isn't written down anywhere a founder can find it. You'll hear "BOR" in your first carrier call and nod like you know what it means. You'll get a question about whether your platform supports "IVANS download" and feel the floor tilt. You'll watch a deal stall because someone said "non-admitted" and you didn't catch the implication.

This glossary is the cheat sheet I wish someone had handed me. Fifty-plus terms, grouped by where they actually show up in your day. Each one gets a plain-English definition, why founders should care, and where you'll trip over it in practice.

Bookmark this. Link to specific terms. Share it with new hires.

Key Stakeholders

Carrier

What it is: The insurance company that underwrites the risk and pays the claims. Travelers, Chubb, The Hartford, Liberty Mutual, AIG, GAIG, Hiscox. The capital is theirs; the policy is on their paper.

Why founders care: Carriers are the source of supply. Every product you sell, every quote, every bind, runs through one of them. Your distribution model is only as viable as the carriers willing to put paper behind it.

How it shows up: "Which carriers are you on?" is the second question any sophisticated partner will ask you. The first is what lines you write. No carriers, no product.

Retail Broker / Agent

What it is: The broker that sits across from the insured business and places their coverage. Marsh and Aon at the top, HUB and Acrisure and USI in the middle, and tens of thousands of independent agencies in small commercial. "Agent" usually implies a captive relationship with one carrier; "broker" implies independent placement across multiple carriers. The terms get used interchangeably in casual conversation.

Why founders care: Retail brokers and agents own the customer relationship. If your model touches the insured, you'll either disintermediate retail (hard) or partner with retail (more common). Either way, understanding their economics is non-negotiable.

How it shows up: "We have 200 retail agency relationships" is the kind of number that wins partnerships. The retail channel still controls the majority of US commercial premium.

Wholesaler / Wholesale Broker

What it is: The intermediary between retail brokers and carriers, especially for risks that don't fit standard admitted markets. RT Specialty, Amwins, CRC, Burns & Wilcox. A retail broker brings a hard-to-place account to a wholesaler, who shops it across surplus-lines and specialty carriers.

Why founders care: Wholesale is where the harder, larger, more lucrative risks live. If your product is aimed at retail-only small commercial, wholesale is irrelevant. If you're touching anything specialty, wholesale is the buyer.

How it shows up: "We placed it through Amwins" means the retail broker couldn't find admitted capacity and went to E&S via a wholesaler.

MGA (Managing General Agent)

What it is: A delegated-authority firm acting on behalf of one or more carriers. MGAs typically have authority to bind coverage, set pricing within carrier-defined parameters, and sometimes handle claims, all on the carrier's paper without being the carrier themselves. Compensated via commission and often a profit-share/override.

Why founders care: "Become an MGA" is the most common platform-building move in insurtech. It lets you control underwriting, pricing, and product without raising the capital to become a carrier. But MGA economics are tighter than they look, and carrier appointments are harder to win than they sound.

How it shows up: Almost every modern insurtech is structurally an MGA, even if they market themselves as a "platform" or "marketplace."

MGU (Managing General Underwriter)

What it is: Narrower than an MGA in theory. An MGU typically has delegated underwriting authority — quote, set pricing within parameters, bind — but not the broader administrative authority an MGA may carry (claims handling, full distribution authority, sometimes premium collection). The label distinction has eroded in practice: many firms operate as MGUs but call themselves MGAs because MGA is the more recognized term, and many MGAs technically lack claims authority. The functional question is what authorities the contract actually grants, regardless of which acronym appears on the masthead.

Why founders care: If a carrier offers you an "MGU" arrangement instead of an "MGA" arrangement, read the contract. The authorities you actually get — bind, claims handling, premium collection, product modification, sub-appointment — matter more than the label on the agreement. Some carriers use "MGU" specifically when they want to retain claims handling, which has real economic implications: claims handling is one of the most operationally expensive parts of running an insurance program, and not staffing it changes your cost structure meaningfully.

How it shows up: A founder describes their company as an MGA in pitches, but the underlying contract is technically an MGU agreement without claims authority. The distinction doesn't matter for the pitch deck. It matters when they want to differentiate the program through claims experience and discover they can't.

Reinsurer

What it is: The insurance company that insures other insurance companies. Munich Re, Swiss Re, Hannover Re, Everest. Carriers cede a portion of their risk to reinsurers in exchange for ceded premium. Reinsurance comes in two main flavors: treaty reinsurance (a standing agreement covering a defined class of business, most common), and facultative reinsurance (placed risk-by-risk for individual large or unusual accounts). MGAs typically build their capacity stack with reinsurer capital fronted by a primary carrier. The primary "fronts" the paper (so the policy is admitted and rated) while the reinsurer takes most of the economics and most of the risk.

Why founders care: If you're building a program or MGA, your capacity structure usually depends on reinsurer support. Reinsurer appetite — for your class, your geography, your loss results, and the macroeconomic moment — determines whether the program exists at all. Reinsurer pricing and terms reset on an annual cycle (most treaty renewals happen January 1, with smaller cycles April 1, June 1, and July 1), which means MGAs often discover next year's program economics only a few weeks before they need to commit to writing it.

How it shows up: An MGA founder mid-year says "we have committed capacity for the next two years." That's strong. An MGA founder in November says "we're waiting on 1/1 renewals." That's the honest answer, and it means next year's capacity, pricing, and terms aren't locked yet.

Insured

What it is: The business (or individual) whose risk is being underwritten and who the policy will pay if a covered loss occurs. Distinct from "policyholder" (the named contract holder on the policy, usually but not always the same as the insured) and from "additional insured" (a separate party named on the policy to receive coverage for liability arising from the named insured's operations). In a master policy structure, common in PEOs and association programs, the policyholder and the insured are different entities.

Why founders care: Founders use "insured," "policyholder," "client," and "customer" interchangeably. They're not the same. The insured is the entity whose loss the policy pays. The policyholder holds the contract. The customer of an insurtech is often the broker or platform partner, not the insured. Getting these terms right matters in legal, compliance, and product contexts. Additional-insured endorsements in particular have driven a meaningful chunk of commercial litigation in the past decade.

How it shows up: In a PEO arrangement, the PEO is the policyholder on a master WC policy; the client businesses are the insureds. A landlord requires a tenant to add the landlord as additional insured on the tenant's GL policy. The tenant is the insured, the landlord is the additional insured, and a covered claim by a visitor against the landlord can now be tendered to the tenant's carrier.

Market Structure

Admitted

What it is: A carrier licensed in a given state, with rates and forms filed and approved by the state insurance regulator. Admitted carriers participate in the state guaranty fund: if they go insolvent, the state covers claims up to a limit. Most standard commercial business runs on admitted paper.

Why founders care: Whether your product is admitted or non-admitted determines which brokers can sell it, who can buy it, and how fast you can iterate on form and rate. Admitted means slower changes (state filings) and broader distribution. Non-admitted means faster iteration and narrower distribution.

How it shows up: "Is this admitted?" is the first question a retail agent asks when you bring them a new product.

E&S

What it is: Excess & Surplus lines. Carriers not licensed in the state, accessed through surplus lines brokers, used when the admitted market won't write the risk. Also called surplus lines or non-admitted. Rate and form flexibility is far higher (no state filings), but coverage isn't backed by the guaranty fund, and only surplus-lines-licensed brokers can place it. Most surplus-lines transactions also pass through a state stamping office, a quasi-regulatory body that reviews and stamps policies for compliance with surplus-lines eligibility rules.

Why founders care: E&S is where new products get tested, where harder risks get placed, and where most insurtech innovation happens, because the regulatory loop is shorter. If you're building a novel coverage, you're almost certainly starting in E&S.

How it shows up: "We're surplus lines only" means broader product flexibility, narrower broker network, and a surplus-lines tax (typically in the low to mid single digits, varies meaningfully by state) layered onto every policy.

Hard/Soft Market

What it is: The two phases of the underwriting cycle. A hard market is one of constrained capacity, rising rates, narrowing terms, increased underwriting scrutiny, and carriers exiting classes or geographies. What insureds experience as "premiums going up and coverage getting worse." A soft market is the opposite: abundant capacity, falling rates, broadening terms, eager underwriting. Markets harden line by line and geography by geography, not uniformly.

Why founders care: The market cycle is the single largest external variable in commercial distribution economics. A platform that launched in a soft market may have built its growth math on rates that no longer exist; a platform launching in a hard market sees capacity providers more selective about new MGA partnerships. Whether your insureds renew with you, switch, or shop is significantly cyclical. Most insurtech founders underestimate how much of their early growth was tailwind from a hardening market.

How it shows up: A retail agency's renewal book in the recent property hard market showed double-digit rate increases across most lines without producer effort. That's the cycle doing the work. The same book in a softening market shows flat or declining renewal premium and producers having to fight for accounts that used to renew on autopilot.

Key Products

WC (Workers' Compensation)

What it is: State-mandated coverage for workplace injuries. Pays medical costs and lost wages for employees injured on the job. Required in nearly every state for nearly every employer with employees. Priced by payroll × class code rate, with experience modification (E-mod) for larger employers.

Why founders care: WC is the most heavily regulated, most data-rich, most workflow-intensive commercial line. It's also the most embedded. Payroll platforms like Gusto, Rippling, and ADP increasingly bundle WC. PEOs are essentially WC arbitrage businesses with HR layered on top.

How it shows up: Workers' comp comes up in literally every conversation about embedded insurance, payroll partnerships, or small-employer benefits.

BOP (Business Owner's Policy)

What it is: A package policy combining commercial property (the building, contents) and general liability into a single policy, designed for small-to-mid commercial businesses. The default product for restaurants, retail shops, small offices, small contractors. BOP is the package version; standalone Property and GL handle the same risks for businesses too large or too specialized for BOP.

Why founders care: BOP is the single largest small-commercial product. If you're building for small commercial, you're building for BOP first.

How it shows up: A 6-employee retail boutique buys one BOP and is largely covered. They don't think of it as "property plus GL." They think of it as "the business policy."

GL (CGL)

What it is: Commercial General Liability. Third-party liability coverage: bodily injury and property damage that the business causes to others. The "slip and fall" coverage. Standalone GL is less common than GL bundled into BOP; CGL standalone is typical for contractors, manufacturers, and businesses too large for BOP.

Why founders care: GL is the second-most-common commercial coverage after WC. Every business needs it; pricing varies enormously by class code.

How it shows up: A general contractor needs GL with specific additional insured endorsements before they can step on a job site.

Cyber

What it is: Coverage for data breach response, ransomware, business interruption from cyber events, regulatory fines, and (sometimes) social engineering fraud. A relatively young line whose underwriting has tightened sharply since the ransomware wave.

Why founders care: Cyber is the fastest-growing commercial line. Underwriting has shifted toward structured controls (MFA, EDR, security questionnaires). The data inputs are highly structured, which makes the line especially API-friendly. Lots of insurtech activity here.

How it shows up: A 100-person SaaS company gets quoted cyber and the carrier wants to scan their externally-facing infrastructure before binding.

Inland Marine

What it is: A confusingly named line covering property in transit, property on the move, and specialty property that doesn't fit standard property forms. Includes contractor's tools and equipment, fine art, electronic data processing equipment, transportation/cargo, and bailee's liability. Has nothing to do with the ocean. The name dates to when this line split off from ocean marine insurance in the 1800s.

Why founders care: Inland Marine has unusual underwriting flexibility (manuscript forms, individual valuation, no standard rating bureau) and has been one of the most profitable P&C lines for carriers. It fits embedded models well: equipment dealers, contractor platforms, freight brokers, and similar platforms sit on natural inventories of insurable property.

How it shows up: A contractor's $200K of tools and equipment is covered under an Inland Marine policy rather than their BOP. A photographer's $40K of camera gear, same. A trucking company's cargo, same.

Builders Risk

What it is: Property coverage during construction. Covers the structure being built, materials on site, and (sometimes) materials in transit, against fire, theft, weather, and other perils. Time-bounded: the policy starts at groundbreaking and ends at substantial completion. Specialized form because insurable value grows during the policy period as construction proceeds.

Builders Risk is technically a form of inland marine insurance — most builders risk policies are written on inland marine forms rather than commercial property forms — but distributed and underwritten as a distinct product with its own carriers, MGAs, appetite, and submission workflows.

Why founders care: Builders Risk is the standard coverage on every commercial and residential construction project, plus most renovations above a certain size. Distribution is fragmented and heavily wholesale-oriented.

How it shows up: A general contractor breaking ground on a $5M strip mall buys a 12-month Builders Risk policy with the project owner as named insured. The premium scales with completed value at takeoff plus materials on site.

Commercial Property

What it is: Standalone coverage for the buildings, equipment, inventory, and contents owned by a business. Pays out when fire, theft, vandalism, weather, or other covered perils damage physical assets. Sold standalone (vs. packaged into BOP) for businesses too large for BOP, businesses with cat-exposed locations, or risks needing bespoke coverage like high-value buildings or complex multi-location schedules.

Why founders care: Property is one of the largest commercial P&C lines by premium and one of the most cyclical. Cat-exposed property — coastal, wildfire zones, convective storm regions — has been through a sustained hard market, with capacity withdrawal and rate increases routinely in the double digits, often well into the 20%+ range annually in the most exposed zones. If your insureds have buildings, expect to navigate this market dynamic.

How it shows up: A 50,000 sq ft warehouse in Florida is bound at a $250K premium with a 5% wind deductible. Two years ago the same property bound at $90K with a 2% wind deductible.

Commercial Auto

What it is: Coverage for vehicles used in business: delivery vans, contractor trucks, sales fleets. Includes liability, physical damage, and various endorsements (hired/non-owned auto, MCS-90 for trucking).

Why founders care: Commercial auto is one of the hardest lines in the market. Loss ratios have been elevated for years, capacity is constrained, rates have risen sharply. If your insureds have vehicles, this will be a pain point.

How it shows up: A landscaping company with three trucks needs commercial auto, and the rate has probably risen 15–20% at the last renewal.

Umbrella / Excess Liability

What it is: A liability policy that sits above an insured's underlying liability policies (GL, Auto, Employers Liability, sometimes E&O). When an underlying limit is exhausted, the umbrella drops down to provide additional coverage. "Umbrella" technically refers to coverage that's broader than the underlying (drops down to cover gaps); "Excess" strictly means higher limits on the same coverage. The terms get used interchangeably in practice.

Why founders care: Umbrella attaches on top of almost every commercial insured of meaningful size. Underlying limits define the "attachment point"; umbrella limits stack on top. Capacity has been tight for years due to nuclear verdicts: jury awards of $10M+ that exhaust primary limits and pierce umbrella layers.

How it shows up: A trucking company carries $1M of underlying auto liability and $5M umbrella on top, for $6M total liability capacity. After a serious accident with a $4M settlement, $1M comes from the auto policy and $3M comes from the umbrella.

Professional Liability (E&O / MPL)

What it is: Coverage for claims arising from professional services rendered negligently or with errors. Distinct from GL: GL covers bodily injury and property damage; E&O covers financial loss from professional advice or service. MPL (Miscellaneous Professional Liability) is the catch-all flavor of E&O for professionals whose work doesn't fit a named profession-specific product: consultants, marketing agencies, IT services firms. Profession-specific E&O products exist for lawyers, architects/engineers, accountants, doctors (medical malpractice), and real estate agents.

Why founders care: E&O is required by almost every B2B services company before a Fortune 500 client will sign their MSA. MPL specifically is a strong fit for embedded models targeting professional services. The classes are heterogeneous, which makes underwriting harder but creates room for differentiated products. Founders conflate E&O with GL constantly.

How it shows up: A boutique branding agency needs MPL before signing a new enterprise client. A consultancy gets sued for bad advice and the E&O policy responds. GL would not.

D&O (Directors & Officers Liability)

What it is: Coverage for directors and officers of a company (and the company itself) against claims arising from their decisions in those roles. Covers defense costs and settlements for shareholder suits, regulatory actions, breach of fiduciary duty claims, and management decision lawsuits. Three coverage parts: Side A (individuals when company can't indemnify), Side B (company reimbursement), Side C (entity coverage, mainly for public companies).

Why founders care: D&O is essential for any company taking institutional money. Every VC term sheet requires it. Pricing varies dramatically with stage and exposure: a pre-revenue startup might pay in the low five figures, a growth-stage SaaS company in the high five to low six figures, and a pre-IPO company well into six figures or more. An active line for insurtech embedded in startup-adjacent platforms.

How it shows up: A startup closing a Series A buys D&O within days of close. The investor's term sheet requires it, often with specific minimum limits and a named lead carrier.

EPLI (Employment Practices Liability)

What it is: Coverage for claims by employees against the company: wrongful termination, discrimination, harassment, retaliation, FMLA violations, and wage-and-hour claims (though wage-and-hour is often excluded or sub-limited). Excludes WC (which is the no-fault statutory regime for workplace injuries) and ERISA-governed benefits claims (which require fiduciary coverage). Often packaged with D&O and fiduciary as "management liability" for small to mid-sized companies; sold as a standalone product for larger employers.

Why founders care: EPLI claim frequency is materially higher than D&O frequency. Most companies will face an employment claim long before they face a securities claim. Even claims that are clearly meritless run well into the five- and six-figure range in defense costs before resolution, because employment cases rarely dismiss at the pleadings stage. Particularly relevant for embedded HR and payroll platforms looking to bundle insurance: the data is already in the platform (headcount, payroll, employee turnover), the underwriting is structured, and the buyer is an HR or finance leader who already has the platform open.

How it shows up: A 40-person company gets a wrongful termination claim from a former VP. The EPLI carrier assigns counsel; defense costs hit six figures before the case settles for a fraction of demand. The company's premium roughly doubles at renewal.

Key Terminology

LOB (Line of Business)

What it is: The product category: Workers' Comp, BOP, GL, Commercial Auto, Cyber, MPL. Each LOB is its own world: distinct carriers, distinct underwriting questions, distinct regulatory regime, distinct workflows, distinct economics. "WC" and "Cyber" share almost nothing operationally except that they're both called insurance.

Why founders care: LOB count is the single biggest driver of operational complexity in commercial distribution. Adding a second LOB doesn't double your work. It more than doubles it. Each LOB requires its own carrier appointments, its own underwriting questions, its own appetite intelligence, its own ACORD forms, its own claims workflow. Founders who say "we'll launch in WC and add BOP in Q3" routinely miss that timeline by 12+ months.

How it shows up: "How many LOBs?" is the single question that calibrates how seriously to take an insurtech's stated GWP. A $50M single-LOB program is a meaningfully different business than a $50M multi-LOB program.

BOR (Broker of Record)

What it is: The broker of record is the licensed broker entity formally designated on a policy as the party authorized to transact with the carrier on behalf of the insured. The BOR is who the carrier communicates with, takes instructions from, services the account through, and pays commission to. Every policy has exactly one BOR at any given moment. A "BOR letter," signed by the insured, is the document by which that designation is established or transferred. The letter is the instrument; the BOR is the role.

Why founders care: BOR is the unit of competition in retail brokerage. Books of business are bought, sold, and benchmarked based on BOR control. Carriers communicate with the BOR, not the insured. If your platform isn't the BOR, you have no direct carrier access on those accounts and no claim on the commission. Any insurtech that wants to own the customer relationship and the commission economics has to either be the BOR itself (which requires the licenses and the operational capacity to service the account) or partner with brokers who are. "Disintermediating the broker" almost always means becoming the BOR.

How it shows up: A retail agency's "book of business" is the set of policies on which they are the BOR. When an account changes brokers, what changes is the BOR designation. The policy stays in force, the carrier stays the same, but the broker the carrier talks to and pays now flips. A competing broker presents better terms, the insured signs a BOR letter, and at the next touchpoint the new broker is the one fielding the underwriter's call.

Submission

What it is: The complete application package sent from a retail broker (or wholesaler) to a carrier or MGA requesting a quote. A submission typically includes the ACORD application(s), supplementals, loss runs (for accounts with prior coverage), and any required carrier-specific documents. "The submission" is shorthand for the entire bundle that an underwriter needs to underwrite the account.

Why founders care: Submission quality is one of the strongest predictors of bind outcomes. Underwriters quote what they can read and decline what they can't. Incomplete submissions sit in a queue; clean submissions get quoted same-day. Almost every workflow automation product in commercial distribution is, at some level, a submission improvement product: better ACORD extraction, automated loss run requests, supplemental pre-fill, document validation.

How it shows up: A retail broker emails the submission to three wholesalers. The one with the cleanest packaging gets the first response. The other two get back to the broker after the deal has already moved.

Indication vs. Quote

What it is: Two different stages of carrier feedback. An indication is an early, non-binding estimate of where pricing might land, sometimes called a "ballpark" or "indication of interest." A quote is a firm, bindable offer with specific terms, conditions, and pricing. Indications often come back same-day from a brief submission; quotes require the full submission and complete underwriting. Many E&S and specialty risks live in indication territory for days or weeks before the broker decides which carriers to push to formal quote.

Why founders care: Conflating indications with quotes is one of the most common founder mistakes when looking at funnel data. "Quote-to-bind" calculated on indications looks artificially low because indications never bind. They only convert to quotes that then convert to binds. Bind rate calculated on indications instead of quotes is meaningless.

How it shows up: A broker shopping a complex restaurant property risk gets indications from five carriers between $35K and $80K, then decides which two to take to formal quote. Only the formal quotes show up in bind-rate calculations.

Subjectivities

What it is: Conditions a carrier attaches to a quote that must be satisfied before the policy will bind. A quote can carry subjectivities like "subject to satisfactory inspection," "subject to receipt of signed application," "subject to MFA implementation" (common in cyber), "subject to roof replacement" (common in coastal property). Until all subjectivities are cleared, the quote is not bindable.

Why founders care: Subjectivities are where deals stall in the final stretch. The broker has a quote, the insured wants to bind, and three subjectivities need to be cleared before coverage attaches. Each subjectivity is its own mini-workflow: get the document, complete the action, send proof to underwriting, wait for sign-off. Insurtech products that compress subjectivity clearance — automated inspection scheduling, security-control attestation, document collection — solve a real bottleneck.

How it shows up: A cyber quote comes back with a $25K premium and four subjectivities: confirm MFA on email, confirm endpoint detection, confirm offline backups, sign the application. The broker has 14 days to clear them or the quote expires.

Appetite

What it is: What a carrier is willing to underwrite, by class of business, geography, size, loss history, and a dozen other dimensions. Appetite is part formal (eligibility rules) and part informal (the underwriter's read of the account). It changes constantly as carriers respond to loss results and market conditions.

Why founders care: Routing submissions to carriers with matching appetite is the single biggest unsolved problem in commercial distribution. Most "AI for insurance" products are, at their core, appetite-matching tools.

How it shows up: "Carrier X is out of appetite for roofing contractors in Texas" means submissions in that class will be declined or non-responded. A good wholesaler knows this without having to ask.

Appointment

What it is: A formal contract authorizing a broker, agent, or MGA to sell a specific carrier's products. Each appointment defines what the appointee can do — quote, bind, issue, service — on which products and in which states.

There are two flavors. Direct appointments are between the carrier and the appointed entity, carrying the deepest authority and the best commission economics. Sub-appointments are where a carrier appoints an MGA or wholesaler, who in turn writes business through retail brokers without those retailers being directly appointed to the carrier. The retailer effectively sits under the wholesaler's paper, the wholesaler's authority, and the wholesaler's economics.

Why founders care: Carrier appointments are one of the hardest things for an insurtech to acquire. Established carriers often require meaningful expected premium production (often in the millions), a multi-year commitment, or a track record in the line before they'll appoint a new MGA. Thresholds vary widely by carrier and class. Without appointments, you have nothing to sell. Sub-appointments through a wholesaler are usually the path of least resistance for new entrants — you can be operational in weeks instead of months — but come with commission haircuts, less control over claims handling, and less long-term capacity stability than direct appointments give you.

How it shows up: A new MGA pitching capacity gets the question: "Direct appointments or sub-appointed?" The answer signals seriousness. Direct appointments take 6–18 months to win and require the carrier to underwrite the MGA itself: financials, leadership, track record, controls. Sub-appointments through a wholesaler can be in place in weeks.

Scratch Agency

What it is: A retail agency built from zero: no acquired book of business, no inherited carrier appointments, no existing producers, no client list. A founder hangs a shingle, gets the P&C licenses, and starts pitching carriers and writing accounts one at a time. Distinct from an agency that's been acquired, inherited, or spun out of an existing operation with carrier relationships already in place. Every digital-native insurtech that decides to be its own retail broker is, structurally, a scratch agency.

Why founders care: Starting scratch is the hardest distribution path in commercial insurance and the most natural one for tech-first founders. The chicken-and-egg problem is brutal: carriers want production history before they'll appoint you; you can't produce without appointments. Most scratch agencies solve this by sub-appointing through a wholesaler or aggregator for the first 18–36 months while building the production track record that earns direct appointments. Networks like ISU, SIAA, Smart Choice, and Renaissance exist specifically to give scratch agencies aggregated market access, pooling their volume across hundreds of agencies to get appointments no individual agency could secure alone.

How it shows up: A founder pitches their insurtech as a "tech-enabled retail agency." That's a scratch agency with a software wrapper. The underwriter's first question isn't about the technology; it's "what's your production?" If the answer is "we just launched," the conversation either ends or pivots to a sub-appointment arrangement.

Market Access

What it is: The set of carriers, products, and capacity an entity can actually quote and bind business through. Market access is a combination of three things: carrier appointments (the legal authority), API integrations (the technical capability to transact), and underwriter relationships (the goodwill that gets your submissions read and prioritized). Without market access you can't write anything. With limited market access you write what you can find appetite for, not what your insured actually needs.

Why founders care: Market access is one of the most underrated moats in commercial insurance distribution. The companies pulling ahead aren't the ones with the slickest UI. They're the ones who can place hard-to-place risks because they have access competitors don't. "How is your market access?" is the question every founder building an MGA gets asked by capacity providers, retail partners, and acquirers.

How it shows up: A retail broker shopping a complex risk lists their "markets": the carriers they can credibly approach. A wholesaler with broader market access wins business that competitors literally cannot quote because they don't have the appointments, integrations, or relationships to even get a submission read.

Program Business

What it is: Insurance written for a specific niche or class — pest control contractors, dental practices, food trucks, ride-share fleets — typically through an MGA with delegated authority and bespoke product terms. The program operates as a book-within-a-book inside a carrier, with its own underwriting guidelines, its own pricing, often its own claims process, and an economic structure that ties the MGA's compensation to the program's loss results.

Why founders care: Vertical insurtech almost always means building program business. The defensibility comes from the program: niche product, niche distribution, niche data. A successful program creates compounding advantages: the loss data improves underwriting, better underwriting attracts better risks, better risks improve loss ratio, lower loss ratio earns more capacity and bigger overrides. Failed programs do the reverse and exit the market within 2–3 years.

How it shows up: "We have a program with Nationwide for dental practices" means there's a delegated underwriting arrangement, a defined class, and likely a profit-share tied to loss ratio. "We're launching a program for [vertical]" is what an insurtech founder says when they've moved past the marketplace stage into actually owning underwriting outcomes.

Class Codes

What it is: The numeric codes that classify a business for insurance purposes outside of Workers' Comp. Two systems dominate. NAICS (North American Industry Classification System, 6 digits) is the modern federal standard maintained by the US Census Bureau and updated every 5 years. SIC (Standard Industrial Classification, 4 digits) is the older system NAICS replaced, but it still appears at carriers running on legacy systems and in older program data. Same business, two codes: a small bakery is NAICS 311811 (Retail Bakeries) or SIC 5461.

Why founders care: Class codes drive carrier appetite and pricing across every commercial line except WC. Underwriting eligibility rules are typically NAICS-keyed: "this carrier writes BOP for NAICS 722XXX (restaurants) and 561720 (janitorial services), declines NAICS 484XXX (trucking)." Translating between SIC and NAICS — and translating natural-language business descriptions into the right code — is foundational for any product doing appetite matching or carrier routing.

How it shows up: A roofing contractor's submission gets declined because the broker entered NAICS 238XXX (specialty contractors) instead of 238160 (roofing contractors) specifically. The carrier writes general specialty trades but not roofers.

NCCI Codes

What it is: A separate classification system, used only for Workers' Comp. The National Council on Compensation Insurance maintains a system of 4-digit class codes used in 38+ states. NCCI assigns a code to every type of work — 8810 for clerical office staff, 5645 for residential carpentry, 0042 for landscape gardening, 7219 for trucking — and publishes a base rate per $100 of payroll for each code in each state. That base rate, multiplied by payroll, multiplied by the insured's experience modification, is essentially the WC premium.

A handful of states don't use NCCI. The four monopolistic states — Ohio, Wyoming, North Dakota, and Washington — run state-administered WC funds with their own classification systems. California, New York, New Jersey, and a few others maintain independent rating bureaus that mirror NCCI but with state-specific modifications. Underwriting WC nationally means handling NCCI plus roughly seven independent state systems.

Experience modification (E-mod or X-mod) is the other major lever. It's a multiplier on the base rate, calculated from the business's loss history versus what would be expected for its class code. 1.0 means "exactly as expected." 0.85 is a 15% discount. 1.25 means paying 25% over base rate. Only businesses above a state-set premium threshold qualify for an experience mod.

Why founders care: WC classification is one of the most data-rich problems in commercial insurance: rates are publicly filed, class definitions are exhaustive, and the system is unusually well-defined compared to other lines. Mis-classification is also one of the most common pricing errors. A general contractor classified as a roofer (5645) can pay several times what they should. A logistics company classified as trucking (7219) instead of warehousing has a wildly different rate. This is one of the most active areas of insurtech tooling.

How it shows up: A small business gets a WC quote that seems inexplicably high. The cause is almost always class code: either misclassified, or correctly classified into an expensive class the business owner doesn't think describes their work. "What's your class code?" is the second question a WC underwriter asks, after "how many employees?"

Premium Audit

What it is: End-of-policy reconciliation of actual exposure against the exposure estimated at bind. Most prominent in WC (where premium is payroll × rate) and GL (where premium is often sales or payroll × rate). At policy inception the insured provides estimated payroll or sales; at policy end (or sometimes mid-term), the carrier audits actual exposure. Underestimated exposure results in additional premium owed; overestimated exposure results in a refund.

Why founders care: Audits are one of the most contentious touchpoints in the entire policy lifecycle. Insureds get audit invoices months after a policy expires and don't understand them. Agencies field dozens of audit disputes per year. Any product touching small-commercial WC or GL hits this wall. Pay-as-you-go WC (carriers like Hourly, AP Intego) was built specifically to eliminate the audit surprise: payroll integration means premium is collected in real time against actual payroll.

How it shows up: A landscaping company estimates $400K payroll at bind. Actual payroll comes in at $550K. The audit produces a $4,200 additional premium bill nine months after the policy started. The owner calls the agency yelling.

AM Best Rating

What it is: A financial strength rating issued by AM Best, the dominant rating agency for insurance carriers. Ratings run from A++ (Superior) down to D (Poor) with intermediate steps. A-rated and above is the practical floor for most commercial business. Anything below is treated as "non-rated" or "below admitted standard" by most sophisticated buyers. AM Best also publishes a "Financial Size Category" (FSC) ranging from I to XV based on policyholder surplus, often quoted together with the letter rating (e.g., "A VIII").

Why founders care: AM Best rating is a gating criterion for distribution. Many large brokers, sophisticated insureds, and contractually-required relationships (lender requirements, lease requirements, vendor compliance) require A- or better. A carrier with a strong product but a B+ rating cannot win business it would otherwise be priced to win. For MGAs picking capacity, the fronting carrier's AM Best rating directly affects which retail partners and which insureds the product can be distributed to.

How it shows up: A landlord requires every tenant to carry insurance from an A-rated carrier. The tenant brings a policy from an A- VIII carrier; it clears. The tenant tries again with a B++ carrier and the landlord rejects the COI.

Direct Bill vs. Agency Bill

What it is: Two ways carriers can collect premium. Direct bill means the carrier sends the bill straight to the insured and collects premium from them directly; the carrier then remits commission to the agency on a periodic statement. Agency bill means the agency bills the insured, collects premium from them, retains the commission, and remits net premium to the carrier. Most small commercial today is direct bill; mid-market and specialty is often agency bill.

Why founders care: The billing model determines who controls the cash, who manages collections, and which back-office workflows the agency has to run. Agency bill puts the agency in the middle of cash flow: they hold premium funds in trust before remitting, which means trust accounting requirements, collections risk, and reconciliation overhead. Direct bill is cleaner operationally but the agency loses visibility into payment status and has less leverage when carriers slow-pay commissions.

How it shows up: An agency switching a book of business from one carrier to another asks early: "Is this direct bill or agency bill?" The answer changes the operational footprint of writing that carrier's product.

Key Documents

ACORD Forms

What it is: Industry-standard forms maintained by ACORD (Association for Cooperative Operations Research and Development). The de facto data interchange standard between brokers and carriers. ACORD 125 is the commercial insurance application. ACORD 25 is the certificate of insurance. ACORD 130 is the WC application. There are hundreds.

Why founders care: Any product touching commercial insurance workflows touches ACORD. Brokers expect to submit ACORD forms; carriers expect to receive them. "ACORD-compatible" is table stakes; "ACORD-native" is a feature.

How it shows up: A retail agent emails a PDF of an ACORD 125 to your MGA inbox and expects you to extract the data. Fast.

Loss Runs

What it is: A carrier-issued report of an insured's claims history, typically going back 3–5 years. Lists each claim, date of loss, amount paid, amount reserved, and claim status (open / closed). Required for underwriting any account with prior coverage. Most underwriters won't quote without them. The insured (or their broker) requests loss runs from the current carrier; the carrier produces them, often after 5–15 business days.

Why founders care: Loss runs are the most common bottleneck in commercial submissions. The submission can't move until the loss runs arrive. Any product that compresses that loop — automated loss run requests, OCR/extraction from PDF loss runs, or carrier-direct claims data feeds — is solving an enormous workflow problem. Several insurtech companies have built their wedge entirely around this one document.

How it shows up: A retail broker can't get a renewal quote until the incumbent carrier produces loss runs. The submission stalls. The renewal slips. The broker calls the incumbent's service team for the fifth time to chase.

COI (Certificate of Insurance)

What it is: A one-page document evidencing that an insured has specific coverage in force. The ACORD 25 is the standard COI for liability coverage. It lists policy numbers, limits, effective dates, and (often) names a specific "certificate holder": the party requesting proof of coverage. A COI is evidence of coverage; it is not coverage itself.

Why founders care: COIs are the highest-volume document in commercial insurance. A general contractor needs one for every job site. A consultant needs one for every client engagement. A landlord requires them from every tenant. Most agencies generate hundreds per week, often as one-off requests with custom additional-insured language. COI issuance, tracking, and compliance verification is one of the most well-trodden wedges in agency tech.

How it shows up: A consultant signing an MSA gets an email at 4pm asking for a COI naming the client as additional insured with $2M limits by EOD. The agency has 30 minutes to issue it.

Endorsement

What it is: A mid-policy change to coverage. Adding a new vehicle to a commercial auto policy, raising a liability limit, adding an additional insured, changing a named insured: all endorsements. Each endorsement generates new policy documents and often a pro-rata premium adjustment. "Endorsement" can also refer to standardized coverage modifications that change the scope of the form itself, like a waiver of subrogation or a primary-and-non-contributory endorsement.

Why founders care: Endorsements are the most frequent transaction type in commercial insurance after COI issuance. A mid-sized retail agency processes endorsements daily across its book. Most carrier APIs handle quote and bind reasonably well and handle endorsements poorly. Many endorsement types still require email or portal-based requests. Endorsement automation is one of the largest unsolved problems in carrier connectivity.

How it shows up: A contractor adds a new truck to the fleet on Tuesday. The agency emails the carrier to request a vehicle-add endorsement. The endorsement issues Friday with a $400 pro-rata premium adjustment. Multiply by every change at every insured every week, and that's the workflow.

Declaration Page

What it is: The summary page of a policy: named insured, policy number, effective dates, coverage limits, premium, scheduled endorsements, and carrier. Usually the first page of the policy document. The "what was actually bought" snapshot. Almost always called "the dec page" in conversation, never the full name.

Why founders care: The declaration page is the canonical record of what coverage exists. AMS systems are largely organized around dec pages. Any product that ingests carrier policy data is parsing dec pages. Any product that validates contract compliance is checking dec page contents against requirements. Dec page OCR / extraction is a foundational capability for retail-facing insurtech.

How it shows up: A lender asks for "the dec page" to verify the borrower's property coverage before closing. Not the whole policy. Just that one summary page that proves what's in force.

Supplementals

What it is: Carrier-specific questionnaires that supplement the ACORD application with additional underwriting questions. Each carrier maintains its own supplementals — usually called just "supps" in conversation — often per class of business. The WC supp for restaurants asks about cooking equipment and after-hours operations. The cyber supp asks about MFA, backups, and incident response. The contractor GL supp asks about subcontractor controls and hot work procedures. Often 5–50 questions per supp.

Why founders care: Supplementals are where carrier-specific underwriting actually happens. ACORD captures the universal basics; the supp captures what makes this carrier different from the carrier next to it. Translating between ACORD data and a dozen different carrier supps — same question, different format, different field name, different position — is a substantial normalization problem and one of the highest-leverage places to add value in submission workflows.

How it shows up: A broker submits the ACORD 125 and gets back: "Need the supp." Twenty-five additional questions, half of them duplicating fields already on the ACORD but in a different format.

Key KPIs

GWP (Gross Written Premium)

What it is: Total premium written in a period, before any deductions for reinsurance ceded, commissions paid, or anything else. The headline top-line number for insurance companies, MGAs, and program administrators.

Why founders care: GWP is the standard way insurtech founders describe scale to investors. "$50M in GWP" tells you the volume of premium flowing through the platform, which — combined with commission rate — implies revenue.

How it shows up: "We did $30M in GWP last year" means $30M of policies were written. If commission was 12%, revenue was roughly $3.6M.

Bind Rate

What it is: The percentage of quotes that result in bound policies. Bind rate = bound policies ÷ quotes issued. Tracked weekly, monthly, by carrier, by product, by producer. A 20% bind rate means 1 in 5 quotes becomes a policy.

Why founders care: Bind rate is one of the cleanest funnel metrics in commercial distribution. It encodes quote quality, pricing competitiveness, and submission targeting all in one number. A sub-10% bind rate signals quotes that aren't competitive, submissions being routed to the wrong carriers, or risks being shopped too widely. A 40%+ bind rate suggests strong appetite-pricing match, but can also signal submissions being filtered too narrowly and revenue being left unwritten. Target ranges vary materially by line: small commercial (BOP, WC) tends to run in higher ranges, often 30%+; specialty and E&S typically run materially lower, often in the teens.

How it shows up: A retail broker reviewing a wholesaler relationship looks at bind rate alongside quote turnaround time. A 35% bind rate with a 4-hour quote turnaround wins more business. A 12% bind rate at a 5-day turnaround does not.

Commission

What it is: The percentage of premium paid by the carrier to the broker (and/or MGA) for placing the business. Rates vary by line and channel. Rough ranges: WC 5–10%, BOP/GL 10–15%, specialty/E&S 15–20%+. Negotiated, often confidential.

Why founders care: Commission is the revenue line for almost every insurtech that touches distribution. Understanding how it splits between MGA, wholesaler, and retail broker is essential to modeling partnership economics.

How it shows up: A retail agency selling a $10K BOP policy at 12% commission earns $1,200. If they bought the business through a wholesaler, $300 of that might go up the chain.

Loss Ratio

What it is: Incurred losses ÷ earned premium. The core measure of underwriting profitability. A loss ratio of 60% means the carrier paid $0.60 in claims for every $1.00 of earned premium. Most carriers target loss ratios in the mid-fifties to mid-sixties, though targets vary meaningfully by line.

Why founders care: Loss ratio is the metric carriers watch when evaluating an MGA program. A program running at 45% loss ratio gets renewed, increased capacity, and override commission. A program running at 75% gets non-renewed.

How it shows up: "The program ran at a 52% loss ratio over three years" is the sentence that makes a carrier commit more capacity.

Override

What it is: Additional commission paid to an MGA or wholesaler on top of base commission, typically structured as a percentage of premium or a profit-share tied to loss ratio. Sometimes called "contingent commission" or "profit commission." The terms differ technically but get used interchangeably.

Why founders care: Overrides are where MGA economics get interesting. Base commission keeps the lights on; overrides drive valuation.

How it shows up: "We get a 5% override plus 25% profit share above a 60% loss ratio." The structure of an MGA's upside.

Key Technology Providers

PAS (Policy Administration System)

What it is: The carrier's system of record for policies: quoting, issuance, endorsements, billing, renewals, claims-feed integration. Examples: Duck Creek, Guidewire PolicyCenter, Majesco. PAS replacements are typically 5–7 year projects costing tens of millions.

Why founders care: PAS is the bottleneck behind every carrier API. The carrier's API is essentially a window into their PAS, with all of the PAS's limitations baked in. If the carrier's PAS doesn't support a feature, no API will give it to you either.

How it shows up: A carrier says "we can't do mid-term endorsements via API because of how our PAS handles them." That's a PAS limitation, not an API limitation.

AMS (Agency Management System)

What it is: The retail agency's system of record. Manages clients, policies, renewals, commissions, customer service workflows. Vertafore AMS360, Applied Epic, EZLynx, HawkSoft are the major players.

Why founders care: If your product is sold to retail agencies, the AMS is where it has to integrate. AMS data ownership and integration depth are existential issues for any retail-facing insurtech.

How it shows up: A retail agency evaluating your product asks: "Does it download to my AMS?" If the answer is no, you're going to lose to a competitor whose answer is yes.

IVANS

What it is: The industry-standard data download network operated by Applied Systems. Carriers push policy data — declarations, endorsements, billing, commissions — to retail AMS systems via nightly IVANS downloads. Functionally, IVANS is the carrier-to-agency data backbone for the entire US retail market.

Why founders care: IVANS is invisible infrastructure that the retail channel depends on. Any product purporting to move data between carriers and agencies will either work with IVANS or get measured against it.

How it shows up: A retail agency's morning ritual: open the AMS, check what downloaded overnight from IVANS: new policies bound, endorsements processed, commission statements issued.

Carrier Connectivity Infrastructure

What it is: The infrastructure layer that gives a platform unified API access to multiple carriers behind a single connection. Underneath, the provider handles per-carrier data model translation, underwriting question mapping, authentication, monitoring, and ongoing maintenance, so the platform built on top connects once and accesses the full network. A category that has emerged over the past several years; CoverForce is one example.

Why founders care: Building carrier connectivity in-house is expensive and ongoing. Each integration takes months, sometimes longer for complex carriers; once shipped, it continues to consume engineering capacity because carriers change their APIs, deprecate endpoints, launch new products, and retire old ones. Platforms that start by building their own connections often reassess the buy-vs-build math 12–18 months in, after the maintenance load has outgrown the original roadmap.

How it shows up: A platform planning to quote across multiple carriers in multiple LOBs faces an early choice: build the integrations in-house, sub-appoint through a wholesaler whose tech and appointments are already in place, or connect through a CCI provider. The choice shapes the engineering org for years afterward.

A Final Note

This list will keep evolving. If there's a term you keep tripping over that isn't here, send it over and we'll add it.

For founders building in commercial insurance, the language is the moat. The faster you can speak it fluently, the faster you can have the conversations that move deals.

And if you're building distribution and want to skip the part where you spend two years building carrier API connections yourself — reach out. It's what we do.