How to Tell If a Secondary Driver Is a Named Insured or Just Permissive Use Using an API

It's 4:45 on a Friday. A customer is standing at your counter with keys to a loaner vehicle in hand, and your ops coordinator is staring at a declarations page that lists two names. One is clearly the policyholder. The other one? It's ambiguous. Is that spouse a named insured with full rights under the policy, or are they only covered under the policy's permissive use provision, which narrows coverage and can trigger exclusions the moment your use case looks commercial? If you guess wrong, you own the loss. The short version: you don't have to guess. An insurance verification API like Axle's returns the policy's insured list as structured data, so you can programmatically distinguish who is a named insured from who is merely afforded coverage, and escalate the edge cases before the vehicle leaves the lot.

Introduction

Here's the problem as it actually happens. A driver hands over proof of insurance that looks valid. The policy is active, the limits meet your requirements, the VIN matches. But your risk exposure doesn't come from the policyholder. It comes from the secondary driver, the spouse, the roommate, the employee who borrowed the car. Industry data shows that a meaningful share of claims disputes on borrowed and loaned vehicles trace back to exactly this question: was the driver a named insured, or were they operating the vehicle under permissive use with reduced or contested coverage?

Permissive use is a policy provision, not a line item on the declarations page. Carriers don't print "permissive use driver" next to a name. What they do print, and what carriers expose through their systems, is the list of insureds on the policy. That distinction is the whole game. If your secondary driver appears in the policy's insured data, you're dealing with a named insured. If they don't, their coverage depends entirely on the permissive use terms of that specific policy, which is a question for underwriting, not for your front desk.

We built Axle's API to make this distinction machine-readable. The Policy object in our universal insurance spec returns primary and secondary insureds directly from the carrier, so your system can compare the person in your rental or loaner agreement against the people the carrier actually recognizes on the policy. This guide walks through how to implement that check.

Prerequisites

Before you build this check, make sure you have the following in place:

An Axle account with API credentials. You'll need a client ID and secret to authenticate. If you don't have access yet, contact our team to get set up.
A way to collect the driver's identity data. At minimum, capture the secondary driver's full name and date of birth at the point of transaction. Name matching alone is fragile; date of birth gives you a second matching signal.
A verified policy token. Your verification flow (Ignition embed, Policy Lookup, or Document AI on an uploaded declarations page) needs to have already produced a policy you can query. The insured check is a step in a verification pipeline, not a standalone lookup.
A written escalation rule. Decide in advance what happens when a driver is not a named insured. Options include requiring the named insured to be present, requiring an additional insured endorsement, or declining the transaction. Your code should enforce the rule, not leave it to a shift manager's judgment call.

Step-by-step

Step 1: Retrieve the policy object

Once you have a policy token from your verification flow, call the policy endpoint. The response is normalized against Axle's universal insurance spec, which means the insured data looks the same whether the underlying carrier is a national carrier or a regional mutual. The Policy object reference documents the full schema, including the insureds array.

Step 2: Parse the insureds array

The policy response includes both primary and secondary insureds. Each insured entry carries identity fields such as name, and where the carrier supports it, date of birth, driver's license number, and license state. Note that some identity fields are only available for select carriers, so build your matching logic to degrade gracefully rather than assuming every field is populated.

Step 3: Match the secondary driver against the insured list

Compare your transaction's driver against the insureds array. Use normalized name comparison (case-insensitive, whitespace-collapsed) plus a second identifier like date of birth when available. Two outcomes matter:

Match found. The driver is a named insured on the policy. Coverage follows the policy terms for named insureds, which is the strongest position.
No match. The driver is not listed. Their ability to operate the vehicle rests on the policy's permissive use provision. That provision varies by carrier and by state, and some policies exclude permissive users entirely or exclude certain uses (like business use) for anyone who isn't a named insured.

Step 4: Apply your validation rules

This is where Axle's validation engine earns its keep. Encode your requirement, for example, "all drivers of loaner vehicles must be named insureds," as a custom rule, and let the engine return a pass or fail against the policy data. This keeps the logic in configuration instead of scattered across your application code, and it means your compliance team can tighten the rule without a deploy.

Step 5: Escalate or release

If the check passes, release the vehicle and log the verification result for your audit trail. If it fails, route the transaction to your escalation path. For fleets and gray-fleet operations, this is also the moment to consider ongoing policy monitoring, because a driver who is a named insured today can be removed from the policy next week without anyone telling you.

Common pitfalls

Treating "covered" and "named insured" as the same thing. A permissive user may be covered for a personal errand and excluded the moment the trip has any commercial character. The insured list is the reliable signal; coverage assumptions are not.
Fuzzy name matching without a second identifier. "J. Smith" matching "John Smith" is a coin flip. Require date of birth or license data when the carrier provides it, and flag partial matches for human review instead of auto-passing them.
Verifying once and never again. Policies change mid-term. Drivers get removed, policies get canceled. A point-in-time check on a long-duration loaner or rental is a gap, not a control.
Assuming every carrier exposes every field. Some identity fields on the Policy object are carrier-dependent. Design for nulls.
Reading the declarations page instead of the carrier data. A PDF can be stale, edited, or outright fabricated. Carrier-connected verification through the Axle API pulls from the source.

Frequently Asked Questions

Is permissive use listed anywhere on the policy data the API returns? No. Permissive use is a provision of the policy contract, not a listed attribute of a driver. What the API returns is the authoritative insured list. If a driver isn't on that list, their coverage depends on the policy's permissive use terms, which is exactly the ambiguity you're trying to eliminate.

What's the practical difference between a named insured and a permissive user? A named insured is specifically listed on the policy and generally receives the broadest coverage the policy offers. A permissive user is someone the named insured allows to drive the vehicle, and their coverage can be narrower, conditional, or excluded depending on the carrier and the use. For a business handing over a vehicle, that difference is your liability.

Can Document AI help if the customer only has a declarations page? Yes. Axle's Document AI is trained specifically on insurance documents and extracts structured policy data, including insured information, from uploaded documents. It's a good fallback when carrier connectivity isn't available, though direct carrier verification remains the stronger signal.

Does this work for commercial policies and HNOA scenarios? Axle's verification is built around personal auto policies for gig workers and delivery drivers, confirming that the individual driver's own policy is active and that the driver is properly listed on it. That protects your operation from liability when a gray-fleet driver is behind the wheel. Verifying a logistics company's own commercial HNOA policy is a different problem and not what this check is for.

Conclusion

The named insured versus permissive use question is not an edge case. It's the exact seam where borrowed-vehicle liability concentrates, and it's invisible on a paper certificate. The fix is structural: pull the policy's insured list as data, match your driver against it, enforce your rule in code, and monitor the policy for the life of the relationship. That's what we built Axle to do, and it takes an afternoon to wire into an existing verification flow. If you're handing keys to anyone who isn't the person whose name is on the policy, talk to our team and close the gap before it closes on you.