Search the challenges of the insurance loss run process and you will find broad agreement on the diagnosis. Carriers are slow. Formats are inconsistent. Manual work is error-prone. Requests get lost. Data is sensitive.
That list is roughly correct. The trouble is what surrounds it — the factual claims used to justify it, and the conclusion it’s engineered to reach.
Two of the claims that appear most often in this literature are simply wrong. A third is a half-truth that gets sold as a solution. And the conclusion — that you cannot afford to own this function — is the one claim that benefits the party making it.
This article works through all four, with the corrections. If you want the underlying operational breakdown of where loss run hours actually go, that’s covered in our pillar piece on insurance loss run reporting.
Correction 1: There is a legal deadline. Usually around ten business days.
You will frequently read that insurers are obligated to furnish loss run reports but that no law compels them to do so within a set time, and that carriers therefore take as long as they like.
That is not the position in most of the United States. Insurance is state-regulated, and a large number of states impose a statutory window on delivery of loss information following a valid request. The common benchmark is in the region of ten business days, with variation by state.
| Jurisdiction | Requirement | Statutory reference |
|---|---|---|
| Most states (general benchmark) | Loss run delivered within a set statutory window following a valid written request; approximately ten business days is the most common deadline | State insurance code; verify per state |
| Florida | Insurer must provide the loss run statement within 15 calendar days of receipt of the insured’s written request; may not charge a fee for one annual statement; not required to provide loss reserve information | Fla. Stat. § 626.9202 |
| New York | On written request by the first named insured or their authorised agent or broker, the insurer must mail or deliver loss information — closed claims, open claims, and notices of occurrence | N.Y. Ins. Law § 3426(g)(2) |
Illustrative, not exhaustive. Confirm the current requirement for each state you write in.
Why the correction matters operationally: a deadline you know about is leverage; a deadline you don’t know about is an excuse. If your team treats carrier turnaround as unknowable, follow-up becomes arbitrary — a polite email whenever someone remembers. If your team knows the statutory window and the escalation path to the state insurance department, follow-up becomes a scheduled, evidenced process with a real backstop.
The practical caveat is that statutory floors are not service levels. Carriers miss them, particularly on incomplete requests, multi-year histories, and during peak renewal periods. Plan your renewal calendar around realistic turnaround plus buffer. Use the statute when the buffer runs out.
Correction 2: GDPR and HIPAA are not your loss run compliance frame
A surprising number of articles on the insurance loss run process cite GDPR and HIPAA as the governing privacy regimes. For US commercial property and casualty work, this is close to backwards.
| Regime | Does it govern your loss run data? |
|---|---|
| Gramm-Leach-Bliley Act + FTC Safeguards Rule | Yes — the core frame. Insurance entities are financial institutions handling nonpublic personal information, and the Safeguards Rule requires a written information security program with administrative, technical and physical controls. |
| NAIC Insurance Data Security Model Law (#668) | Yes, in adopting states. Applies to insurers, agents and other licensees of the state insurance department; requires an information security program, risk assessments, incident response planning and commissioner notification of cybersecurity events. Adopted in a large and growing number of jurisdictions. |
| NYDFS 23 NYCRR Part 500 | Yes, if you are DFS-licensed. It was the framework the NAIC model was built from and remains the stricter benchmark. |
| HIPAA | Only where protected health information is genuinely in scope — health lines, certain group benefits work. Not the default frame for commercial P&C loss runs. |
| GDPR | Only if you process personal data of individuals in the EU/UK. For a US retail agency writing US risks, generally not applicable. |
This is not pedantry. If your data security programme is designed against the wrong regime, you will over-invest in irrelevant controls and under-invest in the ones a state insurance examiner will actually ask about. Notification timelines under the NAIC model run to a few days in most adopting states — that is an incident response design constraint, and it is not what GDPR or HIPAA would have told you to build.
It also changes the question you should ask any offshore partner. Not “are you GDPR compliant?” but: can you evidence controls that satisfy the Safeguards Rule and my state’s insurance data security law, and will they survive an examination?
Correction 3: Automation handles the easy half and concentrates the hard half
The standard solution narrative goes: manual loss run processing is slow and error-prone, therefore intelligent process automation reads the documents and extracts the data.
The first half is true. The second half describes what happens to the clean portion of your volume, and quietly ignores the rest.
| Stage of the loss run process | What it involves | Realistically automatable? |
|---|---|---|
| Request generation | Identifying carriers, preparing LOAs, submitting via portal or service desk | Largely — templated and rules-based |
| Follow-up and escalation | Tracking against statutory windows, chasing, escalating | Partly — tracking automates, judgment on escalation doesn’t |
| Extraction from clean reports | Machine-readable PDFs and data extracts with consistent structure | Yes — this is where tooling earns its keep |
| Extraction from poor-quality sources | Scans, image printouts, legacy formats, partial pages | Unreliable — requires human verification |
| Coverage-line mapping | Reconciling different carriers’ taxonomies into one schema | No — requires understanding of what the lines mean |
| Deduplication across policy terms | Same occurrence appearing in overlapping periods | No — requires judgment on occurrence dating |
| Reserve and valuation reconciliation | Movement between valuation date and submission date | No — requires interpretation |
| Gap identification | Distinguishing a genuinely clean year from a missing one | No — and this is the most dangerous failure |
| Loss analysis and narrative | Frequency and severity trends, development, large-loss context, mod verification | No — this is the value-adding work |
Read the right-hand column downward. Automation resolves the top of the funnel and leaves you with a residue that is entirely judgment work. Your team’s mix doesn’t get easier — it gets harder per file, because the easy files stopped reaching them.
That is a good outcome. It is also the opposite of “automation means you need fewer skilled people.” You need fewer people doing data entry and more people capable of interpretation. Any proposal that presents automation as a headcount story rather than a skill-mix story hasn’t thought it through.
Correction 4: “You can’t afford an in-house team” is a pricing claim, not a structural one
Here is the conclusion almost every article on this subject arrives at: it isn’t economical for an agency, MGA or carrier to maintain a dedicated in-house team for loss run processing, so you should outsource it to a BPO.
Notice who benefits from that conclusion.
The underlying observation is sound. Maintaining a dedicated US-based team for loss run retrieval and normalisation genuinely is hard to justify — the work is seasonal, the skill floor is real, and domestic salary levels don’t match the value of any individual transaction.
But that is an argument about cost, and it gets presented as an argument about ownership. Those are separable. The reason it gets conflated is that the party making the argument only sells one of the two options.
What the two models actually optimise for
| Third-party BPO | Captive team via Build-Operate-Transfer | |
|---|---|---|
| Who employs the team | Vendor | You (post-transfer) |
| Pricing basis | Per request, per report, or per FTE at a blended rate | Actual cost, itemised and visible |
| Incentive on follow-ups and re-requests | More touches means more revenue | Fewer touches means more margin for you |
| Where carrier-specific knowledge accumulates | With the vendor; staff rotate across clients | With your team, permanently |
| Typical contracted scope | Retrieval and basic data entry — the specifiable part | Full workflow including normalisation and analysis |
| Visibility of true cost | Obscured by the spread inside the rate card | Itemised by design |
| Seasonal flexibility | Genuinely good — this is the real BPO advantage | Requires planning; cross-training absorbs peaks |
| End state after three years | Renewal negotiation | An operating asset you own |
| Switching cost | Rises over time as knowledge leaves with the vendor | You keep the entity and the people |
The BPO column is not a caricature and it is not worthless. For genuinely commoditised, spiky, low-judgment volume, a per-transaction vendor is often the right answer, and the seasonal flexibility line is a real advantage that a captive has to work harder to match.
The problem is when the same model is applied to the parts of the insurance loss run process that carry risk — coverage-line mapping, gap identification, reserve reconciliation, loss analysis. Those are exactly the parts where you need knowledge to compound, and exactly the parts a rotating shared-resource pool cannot compound.
There’s a further wrinkle worth naming. In a per-transaction model, your inefficiency is the vendor’s revenue line. Every avoidable re-request caused by a stale valuation date, every duplicate follow-up caused by poor tracking, bills. Nobody has to behave badly for this to shape outcomes over three years. Structures drift toward what they reward.
What the corrected picture implies
Put the four corrections together and a different operating model falls out.
| Standard advice | Corrected position |
|---|---|
| Carriers have no deadline, so chase harder | Most states impose a statutory window — build follow-up and escalation around it |
| Comply with GDPR and HIPAA | Build against GLBA/Safeguards and your state’s insurance data security law |
| Automate to reduce headcount | Automate to change the skill mix — fewer clerks, more interpreters |
| You can’t afford to own this team | You can’t afford to own it at US cost — which is a different sentence entirely |
That last line is the whole argument for a Global Capability Center. A captive team in India is an in-house team. It’s your entity, your payroll, your management chain, your escalation path into your onshore leadership — at a cost base that makes owning the function viable in a way a domestic build never would.
For loss run work specifically, the ownership question matters more than in most back-office functions, because the work is cumulative rather than repetitive. A reviewer in month two is guessing at carrier quirks. A reviewer in year two knows which of your markets values quarterly, which portals reject multi-year requests, which carrier nets subrogation recoveries and which reports them separately, and how your three largest underwriters like a loss summary laid out. None of that is in a process document. All of it is worth money at renewal. It only accrues to you if the reviewer is yours.
What a captive team typically runs
- Loss run retrieval across carrier portals, service desks and prior markets, tracked against per-state statutory windows
- LOA and authorisation preparation, including entity-history reconciliation for acquired or renamed insureds
- Valuation-date scheduling mapped to the renewal calendar so reports are current at submission
- Normalisation of multi-carrier, multi-year reports into one comparable loss summary
- Data-integrity review — deduplication, coverage-line mapping, gap flags, reserve-movement checks
- Loss analysis: frequency and severity by line, development trends, large-loss narrative, experience mod verification
- Submission assembly including ACORD forms, supplementals and carrier-specific packaging
- Adjacent workflows — renewals, endorsements, certificates, policy checking
The build has to be done properly for any of this to hold. A generalist pool with a checklist will hand you a tidy summary with a duplicated claim in it. A dedicated team hired against insurance-specific criteria, trained on your carriers and your book, working inside an ISO 27001:2022 information security framework with process discipline applied through structured Lean Six Sigma methods, performs the way a good domestic team performs — because it is one.
The Build-Operate-Transfer model exists to make that contractual rather than aspirational: OwnGCC builds the entity and team, operates it to a defined standard, and transfers ownership on an agreed timeline at transparent, itemised pricing. A partner whose revenue depends on you paying per seat indefinitely has no reason to hand the keys over. Ours is structured to end.
Frequently asked questions
Do insurers legally have to provide a loss run report within a set time? In most states, yes. The common benchmark is around ten business days from a valid written request, though specifics vary — Florida sets 15 calendar days under § 626.9202 and bars a fee for one annual statement, while New York’s § 3426(g)(2) governs delivery of closed claims, open claims and notices of occurrence to the first named insured or their authorised agent or broker. Carriers do not always meet the window. The statute is your backstop and your escalation basis, not your planning assumption.
Which privacy laws actually apply to loss run data? For US commercial P&C: the Gramm-Leach-Bliley Act and the FTC Safeguards Rule, plus your state’s version of the NAIC Insurance Data Security Model Law, and NYDFS Part 500 if you’re DFS-licensed. HIPAA applies only where protected health information is genuinely in scope. GDPR applies only if you’re handling EU or UK personal data. Building your programme against the wrong regime is a common and expensive mistake.
Can automation replace a loss run processing team? It can replace the data-entry portion and should. It does not resolve coverage-line mapping, deduplication across overlapping policy terms, reserve movement between valuation dates, missing-year identification, or loss analysis. What automation actually does is raise the average difficulty of the files that reach a human — which argues for a more capable team, not a smaller one.
Is a captive team viable at our size, or is this only for large carriers? It depends on sustained volume rather than company size. The honest test is whether you have enough recurring work to keep a small dedicated team occupied across the renewal cycle rather than only at peaks. Below that threshold a per-transaction vendor is a reasonable answer. Above it, you’re paying a vendor to accumulate knowledge you’ll never own.
How do we protect claimant data if this moves offshore? With the same controls a domestic operation requires, formalised rather than assumed: an ISO 27001:2022-certified environment, role-based access, restricted-egress workstations, audited access logs, and contractual alignment with the Safeguards Rule and applicable state insurance data security obligations. A captive entity means you control those controls directly rather than depending on a shared vendor environment.
What’s the difference between this and just hiring an offshore BPO? Ownership and incentive. In BPO, the vendor owns the entity, the employment relationship and the accumulated carrier knowledge, and bills you for access indefinitely. In Build-Operate-Transfer, those assets are built explicitly to become yours on a defined timeline at a defined cost. Month three looks similar. Year three does not.
The takeaway
The challenges in the insurance loss run process are real and well-documented. The trouble is that the documentation is largely written by people selling one specific answer to them, which is why it consistently overstates carrier lawlessness, misidentifies the compliance regime, oversells automation, and concludes that ownership is out of reach.
Correct those four points and the question changes. It stops being should we outsource loss run processing and becomes at what cost base can we afford to own it — which is a much better question, and one with an answer.
