Proof of insurance and ID cards

How do we deliver proof of insurance and ID cards to a policyholder, a lender or a dealer with the coverage confirmed and the delivery logged?

Generate the document from the policy system and deliver it to the party that asked. Callvu identifies the requester (the policyholder in the app, a lender or dealer through a link or an API, a state's electronic verification), prefills the policy and confirms the coverage is in force for the vehicle or the property and the date requested, classifies the document needed (the state's ID card format, a lender's evidence with the mortgagee or loss payee clause, a certificate with the holder's wording, a verification response), generates it from the policy system with the exact coverage and dates, delivers it in the channel asked (the app's wallet, an email, the lender's portal, a fax where a dealer still needs one), and logs the delivery against the policy with who received what and when. Live at Phoenix Insurance, under national rules outside the US.

Live at PhoenixSimpleCallvu moves: prefill, write back

Talk to an expert Try it in the sandbox

Last updated November 7, 2026.

The problem today

The dealer needed the binder before releasing the car; the policyholder needed the agent; the agent needed the policy system; it was Saturday.

Today, without Callvu

Proof of insurance is asked for constantly: by the policyholder at a traffic stop or a registration renewal, by a lender at closing or when their records show a lapse, by a dealer before a car leaves the lot, by a landlord, by a state's verification system. Each request lands on an agent who looks up the policy, finds the right form, types the holder's wording, and sends it. The volume is large and the work is identical.

The document is a rule: the state's ID card format and the data it must show, the mortgagee or loss payee clause as the lender requires it, the certificate wording that confirms coverage without extending it, the verification response the state's system expects. The coverage must be confirmed in force for the date. The delivery must be logged because a lender's claim that it never arrived leads to force-placed coverage and a complaint.

The right document from the system of record, to the right party, with a log, is a process, not a task.

How it runs

From the requestto the system of record.

A policyholder, a lender, a dealer or a state verification system requests proof of insurance in any channel. Callvu identifies the requester and opens the request.

Policyholder: Requests their card or evidence in the app or by phone and receives it in their wallet or email.
Lender, dealer or holder: Requests evidence through a link or an API with their wording and receives it in their channel.
Service desk: Decides exceptions in the Decision Desk.
Callvu: Identifies, confirms coverage, classifies the document, generates, delivers and logs.

Identify and prefill
The requester is identified (the policyholder with authentication; a lender or dealer with the policy number, the insured's name and the vehicle or property, through a link or the insurer's API; a state system by its verification protocol), and the policy, the coverages, the vehicles or the property and the existing lienholders or mortgagees are prefilled.
Confirm coverage and classify the document
The coverage is confirmed in force for the vehicle or property and the date requested (including a pending endorsement that adds the vehicle), and the document is classified: the state's ID card, a lender's evidence of insurance with the mortgagee or loss payee clause, a certificate with the holder's wording and the standard disclaimer, or a verification response; a request that would add a lienholder or mortgagee not on the policy routes to the lienholder change process first.
Decide exceptions
A request inside the rules generates by rule; a request for a policy not in force, for a vehicle not on the policy, with holder wording that would extend coverage, or from a requester who cannot be matched goes to the service desk in the Decision Desk with the request and only the allowed outcomes.
Generate, deliver and write back
The document is generated from the policy system with the exact coverage, limits, dates and the holder's wording, delivered in the channel asked (the app wallet, email, the lender's portal or API, a fax), and the delivery is logged against the policy with the requester, the document, the channel and the time, so a later dispute about receipt has a record.

Where it ends: Every proof of insurance came from the policy system with the coverage confirmed for the date, in the format the party needed, delivered in their channel and logged. The Decision Trace shows the coverage confirmation and the classification; the Audit Trace shows the request, the generation and the delivery with time.

Runtime enforcement

What is enforcedwhile the work runs.

The regulations preloaded in Callvu Studio and the bank's own policies, applied as steps that run, not lines in a binder. A step that breaks a rule does not run, so a completed run was compliant.

Regulations

US requirements shown. Phoenix runs this process under national rules outside the US; Callvu loads each market's rules as policies the same way.

State financial responsibility laws and electronic proof of insurance rules: Each state sets the content of the insurance ID card (the insurer, the policy number, the effective and expiration dates, the vehicles, the NAIC company code) and nearly all states accept electronic proof on a phone; the card must reflect the policy in force, and a card issued for a vehicle not covered is a misrepresentation.
State online insurance verification systems (for example the IICMVA model and the state programs): States verify coverage electronically with insurers through a web service or a book of business file; the verification response must match the policy system, and a mismatch triggers a registration suspension for the policyholder.
Mortgagee and loss payee clauses and the certificate of insurance standards (ACORD forms and the state certificate laws): A lender's evidence of insurance shows the mortgagee or loss payee clause as on the policy with notice of cancellation rights; a certificate of insurance confers no rights beyond the policy and many states prohibit certificate wording that purports to extend coverage, so the holder's wording is checked before generation.

Company policies

Every document is generated from the policy system with the coverage confirmed for the date; nothing is typed.
A lienholder or mortgagee not on the policy is added through its own process before evidence is issued to them.
Holder wording that would extend coverage is refused by rule.
The delivery log is on the policy, the system of record.

Controls

Requester identification by type.
Coverage confirmation for the vehicle or property and date.
Document classification with wording checks.
Decision Desk for exceptions.
Generation from the policy system.
Delivery in channel and logging.

Clocks and deadlines

Delivery: Immediate for the app and email; the lender's portal or API on its schedule; a dealer's request while the customer waits.
State verification: The state system's response window and the book of business file schedule.

Documents and checks

The request and the requester
The coverage confirmation
The document as generated
The delivery log

In the Decision Trace

The coverage confirmation.
The classification and any wording refusal.
Any decision and the person.

In the Audit Trace

The request with channel and time.
The generation.
The delivery with recipient and time.

The handoff

Between the front doorand the back office.

The front door

The app, the website, a call, a lender's or dealer's link or API, or the state's verification system.

The back office

The service desk sees only exceptions; the agent queue loses the proof-of-insurance calls.

The Decision Desk

A policy not in force, a vehicle not on the policy, holder wording that would extend coverage, or an unmatched requester goes to the service desk in the Decision Desk with the request and only the allowed outcomes.

Proof

Live at Phoenix.Published results only.

Each result is a published claim, with its code on agents.callvu.com, where its status, source and last verified date are kept.

Phoenix Insurance has 40% fewer agent-led calls.

INS-02 · Self-asserted · verified 2026-11-05

Phoenix Insurance reaches more than 90% completion without human help.

INS-06 · Self-asserted · verified 2026-11-05

Phoenix Insurance integrated all core systems with Callvu in 4 weeks.

INS-05 · Self-asserted · verified 2026-11-02

Questions

What buyers ask next,answered plainly.

Can a dealer get the binder on a weekend?

Yes. The dealer requests through a link with the policy and the vehicle, the coverage is confirmed from the policy system, and the evidence is generated and delivered while the customer waits, with the delivery logged.

What if the lender is not on the policy?

The request routes to the lienholder and mortgagee change process first; evidence is issued only for a party on the policy.

Why log the delivery?

Because a lender's claim that it never received evidence leads to force-placed coverage and a complaint; the log on the policy shows who received what and when.

Related processes

Add or remove a vehicle or driver Lienholder and mortgagee changes Certificate of insurance request Policy service requests completed by the customer Try it in the sandbox All insurance processes

Bring this process, or the one that costs you most.

We build it against your policies and your systems, train your team and stay with you through launch. You are live in weeks.