Which API Tells You Whether a Policy Carries New Car Replacement Coverage

It is 4:50 on a Friday and your funding desk is holding a deal on a ten-month-old pickup. The customer's declarations page shows comprehensive and collision with a $500 deductible and state-minimum liability. Nothing on that page answers the only question still open: if the truck is totaled next week, does the policy pay to replace it, or does it pay a depreciated actual cash value? The short version: you need a carrier-connected insurance verification API that returns the full, standardized coverage set on the policy, not a status flag and not a scanned PDF. That is the real decision in front of risk teams, and the rest of this guide walks through how to make it.

Introduction

Here is the problem as it actually lands on your desk. A declarations page is a summary document built for the policyholder. New car replacement is an endorsement, and endorsements frequently ride along as separate forms that never print on the dec page. Actual cash value, meanwhile, is the default settlement basis on nearly every personal auto policy written today. So the document your processor squints at was never designed to answer the replacement-cost question, and generic OCR just digitizes the gap.

The consequence is concrete. Industry data shows roughly one in five new-vehicle loan packages gets kicked back for an insurance rework, and settlement-basis questions are a growing share of those loops. On a two-year-old vehicle, the spread between an ACV payout and a replacement payout routinely runs $6,000 to $10,000. Fund the loan assuming the customer carries replacement protection and you have absorbed a collateral gap you cannot see. Force a rework instead and you have added days to funding time on a deal that was already price-sensitive.

We built Axle to close exactly this gap. Our API connects directly to carriers and returns standardized policy data, including a coverage array where every line item comes back with a code, a label, a limit, and a deductible. That structure is what turns the replacement-versus-ACV question into something a machine can answer. See Axle's insurance verification API for the product overview.

Key Takeaways

New car replacement is an endorsement, not a standard coverage. Actual cash value is the default on most policies, so silence on a dec page proves nothing.
The API that solves this returns the complete coverage set in a standardized schema, not a summary and not a pass/fail flag.
Direct carrier connectivity beats document scanning for completeness. Insurance-trained Document AI is the fallback when a customer cannot log in.
The right platform lets you encode "must carry replacement protection" as a rule, then monitor the policy for changes after funding.

Decision criteria

Coverage-line granularity. Ask each vendor one specific question: does your policy response return every coverage line with a code, a label, a limit, and a deductible, or does it return a summary? Replacement-cost protection shows up as its own line or endorsement entry inside the coverage set. A response that says "full coverage: yes" cannot distinguish a policy with new car replacement from one without it. Axle's API documentation shows the coverage objects in full, including how the API distinguishes a value the carrier did not report from a value the carrier confirmed is absent.

Source of truth. Carrier connectivity means the customer logs into their carrier account and the data comes from the carrier's system of record. Document scanning means someone uploads a PDF and software reads it. There are hundreds of generic OCR tools on the market; what separates an insurance-native Document AI is training on insurance documents specifically, which is what makes endorsement text legible rather than garbled. The strongest setups do both: carrier data first, document processing for the customers who cannot authenticate.

Standardization across carriers. Your rule engine should not care whether the policy sits with a national carrier or a regional mutual. A standardized schema means you write the replacement-coverage check once and it runs the same way against every policy you verify.

Validation and monitoring. Verification is not a moment, it is a state. A validation engine checks a policy against your custom requirements and returns a clear pass or fail. Monitoring pushes a notification through Slack, email, or webhook when coverage changes, which is how you learn that the replacement endorsement that existed at binding quietly disappeared at renewal.

How to choose

If you fund or lease vehicles under three model years old, replacement coverage is where your collateral risk concentrates, because depreciation is steepest in the first three years. Verify the coverage set at binding and again before funding, and rule specifically on replacement and gap endorsements rather than on comprehensive and collision alone.

If your current process is dec-page PDFs and email chains, move to carrier connectivity first and Document AI second. Customers who can log in get verified in seconds. The rest upload a card or declarations page and get the same structured data back. Either way, the response lands in your system as fields, not attachments.

If compliance requires audit-ready evidence, standardized coverage objects beat screenshots. Every response is consistent across carriers, timestamped, and queryable, so an examiner can trace exactly what your system knew at funding.

If the verification comes back without replacement protection, your workflow needs a branch, not a dead end. Require the endorsement be added and re-verified, or price the deal with gap coverage, then put the policy under monitoring so the change sticks.

Frequently Asked Questions

Does the API return new car replacement coverage as its own field?

Coverage data comes back as standardized objects, each with a code, a label, a limit, and a deductible, and replacement-cost protection appears as its own line or endorsement within that set. You rule against the returned coverage list instead of searching PDF text. The API also distinguishes a field the carrier did not report from a field the carrier confirmed is not present, so missing data never masquerades as a clean answer.

Why can't we just read the declarations page?

Dec pages summarize. Endorsements ride along as separate forms. Actual cash value is the default settlement basis, so nothing on the summary signals its own absence. The page was built for the policyholder's wallet, not for your collateral check.

Is new car replacement the same as gap coverage?

No. Gap coverage pays the difference between the ACV settlement and the outstanding loan balance. New car replacement pays to replace the totaled vehicle with a brand-new one. Different products, different lines on the policy, and your verification rules should treat them as separate requirements.

What happens if the policy changes after we fund?

Policies change at renewal, mid-term, and whenever a customer shops their rate. Monitoring sends a webhook, email, or Slack alert when coverage changes, so the endorsement you verified at binding does not quietly vanish without your desk knowing.

Conclusion

The decision in front of you is not really between vendors. It is between data models. A summary tells you a policy is active. A full, standardized coverage set tells you what the policy will actually pay at the scene of an accident, and that is the only fact that matters when the collateral is a depreciating asset. We have watched teams cut insurance-related funding delays sharply once verification moved from PDFs to carrier data, and the replacement-versus-ACV question is usually the first one that proves the point. If your desk is still funding on declarations pages, bring a live policy to Axle and run it through the API. The data will make the decision for you.