The policy identifier connected records that arrived in different forms.
The firm's systems used different identifiers and levels of detail for the same business. A carrier policy number alone couldn't reliably join a policy-system export, a pricing worksheet, and a claims administrator's file.
We built a shared model covering programs, carrier contracts, policies, exposures, transactions, claims, and submissions. The firm's policy identifier connected the records, while carrier policy numbers remained available as attributes. Records that couldn't be matched confidently went into a queue for the data steward to resolve.
The pipeline preserved incoming files, applied approved mappings to the shared model, and produced carrier-specific outputs. Keeping each carrier's layout as a versioned configuration let the team change a report format without rebuilding the underlying policy history.
AI proposed mappings, and the team approved what changed.
The mapping service took a new source field or carrier template and proposed a match to the shared model, with supporting evidence. The data steward accepted or rejected the proposal, and the system recorded that decision as a versioned rule.
AI also helped explain reconciliation exceptions and draft report narratives. It didn't decide which risks to accept, set prices, make claims decisions, or submit reports. A person signed every carrier report.
We compared candidate models on held-out mappings, report narratives, and reconciliation exceptions. That test informed model selection, while the report-level checks below assessed whether the complete workflow met the agreed standard. Mapping quality and financial reconciliation were separate measures.
A report had to reconcile before someone could release it.
We preserved a history of carrier-accepted premium reports, claims reports, and report packs as a reference set. The reconciliation process compared new outputs with that history and checked premiums against accounting and carrier statements, and claims against the administrator's totals.
The agreed standard required at least 99.5% agreement on premium dollars, complete policy counts, and 99.0% agreement on paid claims and reserves, with every open claim present. No more than 5% of rows could be sent for human resolution, and material differences had to be explained by a recorded rule or a person's decision.
The pilot achieved 99.8% agreement on premium dollars and 99.4% on claims totals, with complete policy counts and 3.1% of rows sent for human resolution. Those results include the steward's work resolving unmatched policies. They measure reconciliation against the reference records, not autonomous underwriting accuracy.
Some differences revealed errors in reports the carriers had previously accepted. The firm corrected those records with the carriers, so historical agreement never became a reason to preserve a known error.
Changes in incoming data needed their own checks.
During rollout, the claims administrator changed status codes and reused an existing code. Our mapping assigned affected claims a closed status with no reserves. The report owner's review and the automated comparison caught the error before submission.
We disclosed the issue, corrected the mapping, reran the report, and added checks that stopped processing when unfamiliar codes appeared. Those checks were extended across the connected sources. Carrier-template changes were versioned and tested against prior data before the first report on the new layout was signed.
The code-change checks, recurring comparisons, and human review served different purposes. Detecting an unfamiliar code could stop new input, while reconciliation and review could expose a wrong result even when a code already existed.
The firm controlled access, submissions, and ongoing operation.
The solution ran in the firm's cloud environment, using its identity controls and multifactor authentication. Access was divided by carrier and program. The submission record retained the source inputs, mapping and template versions, explanations for differences, signer, and delivery receipt.
The firm's technology team took ownership of the pipelines. The reporting team owned mappings, templates, exceptions, and sign-off, with a second owner assigned to each carrier template.
The operating results and financial estimate measured different things.
The reporting comparison used staff time logs and system records at baseline and follow-up. Median monthly work fell from 27 to 6 staff-hours per carrier-program relationship, a reduction of 21 staff-hours. Dividing that difference by an eight-hour workday gives 2.625 staff workdays of reporting capacity freed at the median. A relationship is one program reporting to one carrier, so the measure isn't hours for an entire program or for one individual document.
Onboarding ran from signing a team to a clean monthly close: every required report submitted by day 15, no rejections for two consecutive months, and a reconciled loss ratio available within 10 days. Median time fell from 11 months across six earlier completed launches to 3.1 months across three later launches. The 7.9-month difference is expressed as almost eight months sooner in the main story. It measures a clean close, not the date a program first wrote business or became profitable. Teams already waiting when the project began were tracked separately because their total elapsed time included the earlier queue.
The CFO's estimated ~$5.1M annual adjusted EBITDA contribution compared the outcome with the forecast without the intervention. It combined modeled reductions in start-up losses, avoided budgeted hiring, earlier carrier authority, and resolved disputes. The earlier authority was partly a timing benefit, and the largest component depended on the CFO's launch forecasts. Freed staff time wasn't also priced and added to that financial estimate.
Handover was tested through a change the team made themselves.
We supplied a source-registration form, template and rules libraries, operating instructions, and an onboarding kit. The reporting lead and analysts added a new carrier template and source without us in the room, then ran the recurring comparison to verify their change. The technology team also redeployed a pipeline from the repository.
Their team subsequently used the kit to onboard a program and continued adding templates and sources. That demonstrated both operation of the workflow and the ability to extend it.
For a team evaluating a similar design, the practical question is whether internal owners can make the next change and check its effect. Ask the operator to add a representative source or template, explain any differences the checks find, and show who approves the result before it reaches a carrier.