Carrier Insurance Telematics Underwriting Data Package: What Underwriters Ask For, Safety Event Exports, Camera and ELD Evidence, and the Renewal Data Room

Why Renewal Is a Data Problem

Every motor carrier renews commercial auto liability, and most also carry physical damage, motor truck cargo, general liability, and workers compensation. The underwriter on the other side of that renewal is trying to answer one question: how likely is this fleet to produce a large loss in the next policy year, and how well does its management understand and control that risk. The underwriter cannot ride along with the drivers, so the answer comes from documents and data the carrier provides, plus the public FMCSA record. A carrier that provides a complete, consistent, well organized package is telling the underwriter that it runs a controlled operation. A carrier that sends a partial driver list from a spreadsheet, a unit list that does not match its MCS-150 power unit count, and loss runs that disagree with its own claims log is telling a different story, whether it means to or not.

The systems architecture point is that almost everything the underwriter wants already exists in the carrier's operating systems. The driver roster is in the TMS or the HR system. The unit list is in the TMS or the maintenance system. The lanes and radius are in the dispatch history. The commodity mix is in the load table. The safety events are in the telematics and camera platforms. The inspections and crashes are in the FMCSA SMS portal. The job is not to create new information but to extract it in a repeatable, documented way, cross check it for consistency, and present it in a form the broker and underwriter can use. That is a data engineering task, and it is far easier to do once and schedule than to reconstruct under deadline every year.

What Commercial Auto and Cargo Underwriters Typically Request

Requests vary by underwriter, broker, line of coverage, and fleet size, but the core list is stable. Loss runs, typically covering the most recent three to five policy years and valued within a recent window, come from the prior carriers' claims systems and show paid and reserved amounts by claim. A driver roster lists each driver with date of birth or age, license state and class, hire date, years of commercial experience, and the date and result of the most recent motor vehicle record review. A unit schedule lists each power unit and often each trailer with year, make, model, VIN, stated value, garaging location, and whether it is owned or leased. A description of operations covers radius of operation, primary lanes or regions, terminal locations, commodity mix with any hazardous materials or high theft commodities identified, and the mix of company drivers and owner operators. Safety program documents cover hiring standards, MVR criteria, training, drug and alcohol testing, hours of service management, maintenance program, accident review, and disciplinary policy. Technology adoption covers ELD provider, camera provider and whether cameras face the road, the driver, or both, speed governor settings, collision mitigation equipment, and telematics based coaching. Finally, underwriters review the public FMCSA data including the carrier's inspection and crash history, out of service rates, and any safety rating.

Cargo underwriters add questions about commodity values, theft controls, trailer tracking, seal procedures, and reefer monitoring. Carriers hauling high value or high theft commodities should expect to describe their drop yard security and their trailer telematics coverage specifically. Carriers should also note that FMCSA generally does not impose a federal cargo insurance minimum on for hire carriers of general freight, so cargo coverage levels are set by customer contract and broker requirements rather than regulation; confirm the current rules with FMCSA for your operation type.

The Financial Responsibility Anchor in 49 CFR Part 387

One number in the package is set by regulation rather than negotiation. Under 49 CFR Part 387, for hire motor carriers of property operating in interstate commerce must maintain minimum levels of financial responsibility for bodily injury and property damage. For non hazardous property transported in vehicles with a gross vehicle weight rating of 10,001 pounds or more, that minimum is generally stated as $750,000. Higher minimums apply to certain hazardous materials, oil, and other categories listed in the regulation, and the carrier's insurer files proof of coverage with FMCSA through the appropriate form and endorsement. Carriers should read the current text of Part 387 and confirm the applicable minimum for their operation with FMCSA, because category definitions matter and because the figures have been the subject of rulemaking discussion over the years.

The minimum is a floor, not a market standard. Most shippers and brokers require higher limits by contract, commonly in the range of $1,000,000 for auto liability, and some require umbrella or excess coverage above that. The TMS should hold the required limits from each customer contract in the customer master, so that the renewal package can show the underwriter the limits the carrier is actually obligated to carry, and so that dispatch does not accept freight that requires limits the carrier does not have. This is a straightforward field addition during TMS implementation and it closes a gap that otherwise shows up only when a claim exceeds coverage.

Building a Repeatable Renewal Data Room

A data room is a controlled folder structure with a manifest. Each document in it has a name, a source system, a query or procedure that produced it, a generation date, and an owner. The manifest is the first page the broker sees and it tells the underwriter that the carrier knows exactly where each figure came from. The structure does not need to be elaborate: one folder per request category, a manifest spreadsheet or page at the root, and a change log noting what was refreshed and when. Store it in document imaging or a controlled shared location with access limited to management, the safety department, and the broker, and log every export, because the package contains personal information about drivers.

The exports should be stored queries, not manual reports. A driver roster query joins the driver master to the trip table to confirm each listed driver actually drove in the period, pulls hire date and license fields, and joins to the MVR review table for the latest review date and result code. A unit schedule query pulls year, make, model, VIN, status, ownership type, and garaging terminal, and flags any unit without a current registration or periodic inspection record. A radius query computes trip miles by origin and destination distance band and expresses the share of trips within 50, 200, and 500 miles and beyond, using actual dispatch history rather than an estimate. A commodity query groups loads by commodity class and expresses share of loads and share of revenue. Our SQL data mining work typically produces these as a small library of saved queries with documented column definitions, so that the package can be refreshed by one person in a morning and the definitions do not drift from year to year.

• Manifest first - List every document, its source, its query, its date, and its owner.
• Queries, not retyping - Every table in the package comes from a stored query against a named system.
• Consistency checks - Run the cross checks in the table above before anything leaves the building.
• Access and logging - Driver personal data requires restricted access and an export log.
• Keep it current - Refresh quarterly so renewal is a review, not a rebuild.

Defining Telematics Safety Event Exports

Telematics platforms generate events such as harsh braking, harsh acceleration, harsh cornering, speeding over a posted limit or over a fleet threshold, following too closely, lane departure, forward collision warning, seat belt, and distraction or drowsiness from driver facing cameras. Every vendor defines these differently. One platform triggers harsh braking at one deceleration threshold, another at a different threshold, and a third lets the carrier set it. Speeding may be measured against posted limits from a map database or against a fixed fleet maximum. If the carrier sends an underwriter a count of events without definitions, the number is meaningless and may be compared unfairly against another fleet on a different platform.

The export therefore needs a definitions sheet. For each event type, record the vendor's trigger definition, the threshold value the carrier has configured, the date that configuration took effect, and whether the event is auto detected or confirmed by video review. Then present events as rates rather than raw counts, typically events per 1,000 miles or per 100 driving hours, computed from the same mileage or hours figures used elsewhere in the package. Separate coached events from uncoached events: a coached event is one where a supervisor reviewed the event with the driver and recorded the coaching session and date, and an uncoached event is one that was detected but not yet reviewed. The ratio of coached to total events tells an underwriter whether the camera program is actively managed or merely installed. Show the trend across the policy year rather than a single snapshot, because a program that is improving looks different from one that is static.

Carriers should also decide, with their broker, how much event level detail to share. Many share summarized rates and trends and keep driver level detail internal. Whatever is shared must be reproducible from the carrier's own data and must not be selectively filtered in a way that could be characterized later as misleading. The definitions sheet protects the carrier here: it states plainly what was counted and how.

Camera Event Retention, Privacy, and Access

Camera programs raise retention and privacy questions that should be answered in writing before the renewal package is built. A retention policy should distinguish between continuous or looped recording, which is typically overwritten quickly on the device, and event clips, which are uploaded and stored. Event clips tied to a crash, an injury, a cargo claim, a complaint, or a coaching record should be retained for a longer defined period and placed on litigation hold when a claim or suit is reasonably anticipated. Routine clips with no claim or coaching connection can be retained for a shorter period consistent with the carrier's policy and storage budget. The policy should name who may view clips, for what purposes, and how access is logged. Driver facing cameras in particular require clear driver notice and, in some states, specific consent or disclosure, so the policy should be reviewed with counsel and communicated to drivers in the handbook.

From a data architecture standpoint, the camera platform is one more source feeding a safety event table in the carrier's database, with the clip stored in the vendor's cloud and referenced by a URL or identifier. The event record carries the driver, unit, timestamp, location, event type, review status, coaching record link, and retention class. When a claim is opened, the claims record links to the relevant event records and the retention class changes to hold. This is the same discipline described in our data protection practice: know what you have, who can see it, how long you keep it, and how you prove it was not altered.

Consistency Between the Package and the DOT File

The underwriter will compare what the carrier says with what FMCSA shows. The power unit count on the unit schedule should match the MCS-150 and the registration list. The driver count should be plausible against the power unit count and the operation type. The crash list in the package should match the crashes FMCSA shows for the same period, with the carrier's own notes on preventability determinations and any DataQs challenges. The inspection history should be consistent with the safety program narrative; a carrier that describes a rigorous pre trip inspection program while showing a high rate of light and brake violations will be asked to explain. The point is not to hide unfavorable records, which is impossible, but to show that the carrier knows its record, has reconciled every entry to a driver, unit, and trip, and has acted on the findings.

That reconciliation is the same monthly discipline a carrier should already run for CSA purposes. Each FMCSA inspection and crash record is matched to internal records, exceptions are investigated, errors are challenged through DataQs, and valid records are routed to coaching or maintenance follow up. The renewal package then includes the reconciliation summary: records in the window, records matched, challenges filed and granted, and the resulting view of the carrier's history. Underwriters are accustomed to carriers who have never looked at their own FMCSA data closely. A carrier who presents a reconciled record with a documented process stands out for the right reasons.

The Renewal Timeline

Renewal works backward from the policy expiration date. The exact lead time depends on fleet size, market conditions, and broker practice, but a workable pattern for a mid size carrier looks like the timeline below, expressed in days before expiration. The important feature is that the data room is refreshed quarterly year round, so the 120 day mark is a review and a final refresh rather than a scramble.

Carriers should treat the timeline as a template and adjust it with their broker. Larger fleets and accounts with difficult loss history generally need more lead time. The archived data room version is valuable the following year, because the underwriter will ask what changed, and the carrier can answer precisely.

How Data Quality Shapes Negotiation Posture

No carrier should expect a specific premium outcome from a better data package, and this monograph makes no such claim. Pricing depends on loss history, market capacity, reinsurance conditions, jurisdiction, commodity, and factors outside any one carrier's control. What a complete and consistent package does change is the carrier's posture in the conversation. A carrier that can answer every underwriter question from a documented source within a day is a carrier the underwriter can evaluate quickly and with confidence. A carrier whose numbers shift between submissions, whose driver count cannot be reconciled, or whose camera program exists only as a line item on an equipment list invites the underwriter to assume the worst and price for uncertainty or decline the account.

Data quality also widens the field of markets a broker can approach. Some underwriters will not quote a fleet without telematics event data and a coaching record; others will quote but will ask more questions. A ready package lets the broker approach more markets within the same window. It also supports conversations about deductibles, retention, and captive or alternative risk structures that require the carrier to demonstrate control of its own loss experience. For carriers evaluating an acquisition, the same package built for the target fleet is a core part of carrier acquisition due diligence, because the buyer inherits the target's insurability along with its trucks.

For example, a 100 truck fleet that refreshes its data room quarterly would spend a few hours each quarter running stored queries and consistency checks, compared to the weeks of effort typical when the package is rebuilt from scratch at renewal. The savings in staff time are real; the effect on premium is for the market to decide.

The Data Model Behind the Package

The package draws on tables most carriers already have, with a few additions. The driver master needs hire date, license fields, and a link to an MVR review table with review date, result code, and reviewer. The unit master needs VIN, year, make, model, ownership type, garaging terminal, status dates, and links to registration and periodic inspection records. The customer master needs required insurance limits and any certificate holder requirements from the contract. A safety event table holds telematics and camera events with the columns described earlier, including coaching and retention class. A claims or incident table holds every reported incident with date, driver, unit, type, status, and links to the FMCSA crash record and to camera events. A configuration table holds the telematics thresholds and their effective dates. A data room manifest table holds each document, its query name, its last generation date, and its owner.

The telematics and camera feeds are the part most carriers have not yet integrated. Vendors expose APIs or scheduled exports for events, mileage, and hours, and a scheduled pull into the safety event table is a standard ELD and EDI integration task. Once the pull runs nightly, the events per 1,000 miles figure, the coached ratio, and the trend charts are queries rather than vendor portal screenshots, and they use the same mileage figure the finance department uses for cost per mile. That consistency across departments is what makes the package credible.

Related practice areas for this work include SQL Data Mining ELD and EDI Integration Data Protection Carrier Acquisition Due Diligence. Each practice page describes scope, deliverables, and how an engagement starts with a short discovery call.

How Strong Tower Consulting Helps

Strong Tower Consulting helps carriers build the renewal data room as a set of stored queries, consistency checks, and a manifest that live in the TMS and reporting database rather than in a folder of retyped spreadsheets. The work starts with a review of what the broker requested last year and where each figure came from, moves to the query library and the telematics feed, and finishes with a documented quarterly refresh procedure that the safety department can run on its own. Strong Tower Consulting, LLC and Exspeedite LLC are separately organized sister companies under common ownership. That separation keeps consulting advice vendor neutral and focused on the carrier operation.

To discuss your fleet, your renewal date, and the systems you already run, call 763-244-1373 and ask for Scott Elliott. A short call is enough to map the current package, the gaps in it, and the first queries to build before the broker goes to market.

Frequently Asked Questions