Matching Signer Verification to the Insurance Transaction
Verdocs Team
An insurance platform sends many kinds of documents for signature: acknowledgments, applications, endorsements, producer agreements, claim releases, payee changes. Using one verification setting for all of them creates two problems. A light check is too weak where money or authority changes hands. A heavy check adds friction to routine paperwork that carries little risk.
A better approach is to decide verification per document and per signer, and to raise the check when specific risk signals appear. This post offers a starting matrix for insurance workflows, the escalation triggers that should override it, and the parts of the process that identity checks cannot cover on their own.
The matrix is a product recommendation, not a regulatory standard. Carrier procedures, state requirements, and counsel decide what a given transaction needs.
What each check shows
Each signer check answers a different question. They are not rungs on a single ladder of assurance, and the useful question is which combination fits the transaction.
| Check | What it can show | What it does not show |
|---|---|---|
| Passcode | The signer has a code agreed with them in advance | Who is holding the code; its value depends on how it was set up and shared |
| Email one-time code | The person signing can read the inbox the code went to, which helps if a signing link is forwarded or exposed | Identity; and if the link went to the same inbox, no protection against someone who controls that inbox |
| SMS one-time code | The signer controls a phone number | Who holds the phone, or whether the number was verified when it was added |
| KBA | The signer can answer questions drawn from identity records | That the person answering is the person in the records |
| ID verification | Depends on which steps are performed (see below) | Whether the signer has authority to sign |
One point is easy to miss. An emailed code sent to the same inbox as the signing link is not an independent channel, because whoever controls that inbox receives both. It still helps if the link itself is forwarded or exposed. An SMS code to a phone number verified earlier reaches a separate channel. A passcode agreed during onboarding is an additional check, and how much it adds depends on how it was established and shared.
ID verification also comes in parts that are often bundled under one name:
- ID capture: the signer photographs a government-issued ID and takes a photo of themselves.
- Document validation: the ID is checked for signs that it is genuine and unaltered.
- Face comparison: checks whether the photo of the signer matches the photo on the ID.
- Liveness: checks whether a live person is in front of the camera, rather than a photo or recording.
These steps answer different questions. Face comparison and liveness help establish that a live person matches the photo on the ID they presented. Document validation asks whether the ID itself is genuine and unaltered. The ID verification embedded in Verdocs, provided through GBG, performs face comparison and liveness detection on driver's licenses, other government-issued IDs, and passports. It does not check whether the document is authentic, so it helps establish a match to the ID presented, not that the ID is real.
For more on what knowledge-based authentication (KBA) can and cannot establish, see Is Knowledge-Based Authentication Enough for Remote Signing?
Identity is not authority
Verifying that a signer is Jane Smith does not show that Jane Smith can sign for Smith Logistics LLC, bind coverage for a fleet, or accept a settlement on behalf of a claimant's estate. Identity checks answer who is signing. Authority comes from records: the agency's list of authorized contacts, an officer listing or resolution, a power of attorney, a letter of representation.
Platforms should check authority as its own step, against those records, before the document is sent. A verified signer without authority is still the wrong signer.
A starting matrix for insurance documents
| Document | Signer | Starting check | Escalation triggers and additional controls |
|---|---|---|---|
| Routine acknowledgment with no change to coverage, payees, payment instructions, or signing authority (for example, receipt of policy documents) | Existing insured | One-time code to contact details already on file | Contact details changed recently; signer differs from the named insured; the packet includes any change |
| Endorsement or renewal that changes coverage, limits, insured property, drivers, or lienholders | Named insured or authorized signer | One-time code to a channel on file, plus KBA if the signer is new to the agency | Coverage reduced; lienholder or additional insured added or removed; request initiated by someone other than the insured |
| Personal lines application through an agent | Applicant | SMS one-time code | No agent contact (online only), so add KBA; application details that do not match records |
| Commercial application and supplementals | Authorized signer for the named insured | One-time code, plus confirmation that the signer is listed as authorized | Signer not on file as authorized; new business with no prior contact, so add KBA |
| Producer appointment or agency agreement | Producer | Passcode agreed during onboarding | Any change to commission payee or bank details (see below) |
| Claim settlement release | Claimant or authorized representative | KBA | Payment above a carrier-set threshold, so add ID verification with face comparison and liveness; payee differs from the claimant; representative signing, so confirm authority for this release |
| Payee, loss payee, or bank detail change | Insured or authorized signer | ID verification with face comparison and liveness, as one control among several | Always: confirm through previously verified contact details and follow the carrier's approval procedure |
Read the table as defaults that the escalation column overrides. The document type sets a starting point. The signer, the requested action, and the money involved decide the final check. Where the table calls for ID verification, the organization should define which capabilities its risk policy requires for that transaction. Capturing an image of an ID, on its own, is a weak control for high-risk transactions.
Payee and bank detail changes need more than a signature
A request to change where money goes is a direct route to redirecting a payment. Identity verification is one part of handling it, not the whole control. Face comparison helps establish that the person requesting the change matches the photograph on the ID presented. It does not establish ownership of the new bank account.
A sound process also confirms the request through contact details the carrier or agency already had before the request arrived, never through a phone number or email address supplied in the request itself. It routes the change through the approval procedure the carrier uses for payment changes, and it notifies the insured through the original channel once the change is made. The signed form records the request. It does not make the request legitimate.
A claims example
Consider a P&C carrier settling a water damage claim on a homeowners policy. The adjuster has authority for the amount, and the platform is about to send the release. Three versions of the same claim lead to three different decisions.
The named insured signs, and payment goes jointly to the insured and the mortgagee on file. The signer is known, and the payees come from the policy. KBA is a reasonable check.
The named insured signs, but the release asks for payment to a new bank account. The requested action has changed the risk. The platform adds ID verification with face comparison and liveness, which helps establish that the signer matches the photo on the ID they presented. That does not settle the account change, so the carrier also confirms it by calling the phone number on file, and a supervisor approves it before payment is issued.
A public adjuster signs on the insured's behalf. Verifying the public adjuster's identity is not enough, and neither is a general authorization to represent the insured. The platform confirms that the authorization on file specifically covers signing this settlement release, and that the payment instructions match it.
When verification fails
KBA can fail for legitimate signers, and ID verification can fail on a poor photo. A phone call followed by a fresh request does not resolve a failed check. The person has still not been verified.
The responsible organization, usually the carrier, should define a documented alternative in advance: ID verification in place of KBA, a manual review by a designated team that records its decision, or another approved method. The platform's job is to route the failure into that process, keep the document from being treated as signed, and record how the signer was eventually verified.
Who sets the rules: a suggested model
Agency management systems, carrier portals, and MGA platforms serve organizations with their own rules. One workable model, which the platform would build in its own configuration:
- The platform sets a default check for each document type.
- A carrier or agency can raise the default for its own transactions.
- An adjuster or underwriter can raise it further on a single file.
- No one can lower it below the minimum the carrier sets.
The platform resolves those rules when it creates the signing request and sets the required checks for each signer at that point. It should also store which checks were required and how each one ended, so the answer is available if the transaction is questioned later. The multi-tenant guide for insurance platforms covers how the same platform can serve each carrier and agency under its own brand.
What Verdocs provides, and what your platform builds
Verdocs provides embedded, white-label eSignature with authentication set per recipient when an envelope is created:
- Passcode, email and SMS one-time codes, KBA, and ID verification with face comparison and liveness detection for driver's licenses, other government-issued IDs, and passports. SMS and KBA are activated per account.
- KBA and ID verification through our partnership with GBG, embedded in the Verdocs signing experience and presented under the platform's brand.
- KBA limited to three attempts.
- A
recipient_auth_failwebhook when a configured check fails, and an endpoint the platform can call to retrieve authentication failure status.
Your platform builds the decision logic: the matrix and escalation rules, which verification capabilities each transaction requires, authority checks, payee change confirmation and approvals, the failure review process, and the record of what was required for each signer.
See how this fits insurance platforms, or schedule a demo to walk through your document types with us.
