Identity verification before account changes

How do we verify identity the same way on every phone, web and IVR request before any account change, with the result recorded on the request?

Make verification one step every channel calls. Before any account change, Callvu classifies the request's risk under the identity theft program (a balance inquiry, a contact change, a change that redirects bills or money, a transfer of responsibility), applies the verification the risk level requires (a one-time code to the contact on file, knowledge checks against the account, an identity document read on a secure screen, a database check), runs it on the customer's own device whether the request started on the web, in the IVR or on a call with an agent, chases a failed step with the next allowed method, routes a repeated failure or a red flag to the verification team in the Decision Desk, and records the method, the result and the time on the request so the account change that follows carries its evidence.

In scopeSimpleCallvu moves: chase and verify, decide

Talk to an expert Try it in the sandbox

Last updated November 7, 2026.

The problem today

The caller knew the account number and the address, and that was enough for the agent to change where the bills went.

Today, without Callvu

Identity verification at a utility is usually whatever the agent remembers to ask: the account number, the address, the last four digits of something. The web asks for a password; the IVR asks for a code; the call asks for a story. Fraudsters know which channel asks the least, and the account changes that matter most (the bill redirect, the autopay change, the transfer) are the ones taken on the call.

The Red Flags Rule requires the program to verify identity at the level the transaction's risk warrants and to detect the warning signs; the commission's rules protect the customer's account information; the utility's policy should set one verification standard per risk level and apply it everywhere. The customer's own phone can run the step from any channel, and the result belongs on the request as evidence.

One standard, in every channel, recorded every time.

How it runs

From the requestto the system of record.

A request that will change an account starts on the web, in the Visual IVR, with an AI assistant or on a call with an agent. Callvu classifies its risk and runs the verification before the change.

Customer: Completes the verification step on their own device: a code, a knowledge check, or a document and selfie where the risk requires.
Agent: Sends the verification link on a call and sees only the result, never the answers.
Verification team: Decides repeated failures and red flags in the Decision Desk.
Callvu: Classifies the risk, runs the method, chases, routes and records.

Classify the request's risk
The request type sets the risk level under the program: low (an inquiry, a payment to the account), medium (a contact or preference change, a payment arrangement), high (a change that redirects bills or money, an authorized user, a transfer of responsibility, a payment method change); the level sets the verification methods allowed and the order.
Chase and verify
The verification runs on the customer's own device in whichever channel they are in (the web session, a link texted from the IVR, a link the agent sends): a one-time code to the contact on file, knowledge checks against account data the program allows, and for high-risk changes an identity document read on a secure screen with a liveness check, or a database check; a failed step is chased with the next allowed method, and the agent sees only pass or fail.
Decide
A pass records and releases the account change; a repeated failure, a red flag (a mismatch between the document and the account, an address or phone associated with fraud, a contact on file changed in the last period, a prior identity theft claim) or a customer who cannot complete any method goes to the verification team in the Decision Desk with the attempts and only the allowed outcomes (pass with a further check, require an in-person or documented verification, or decline the change and flag the account).
Record
The method used, the result, the time, the channel and the device are recorded on the request in CIS, the system of record, so the account change carries its verification evidence, the red flags are reported to the program's monitoring, and a pattern of failures on an account raises its risk level.

Where it ends: Every account change was preceded by the same verification for its risk level, in every channel, on the customer's device, with the method and the result on the request. The Decision Trace shows the risk classification, the method and any decision; the Audit Trace shows each attempt and the result with time and channel.

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

FTC Red Flags Rule identity theft program: Under 16 CFR 681 a utility must maintain a written identity theft prevention program that identifies the red flags relevant to its covered accounts (suspicious documents, suspicious identifying information, unusual use of an account, alerts and notifications), detects them in connection with opening and existing accounts including authentication of customers and verification of change of address requests, responds appropriately, and is updated and overseen by the board or senior management; the verification step and its record implement the detection and response elements.
State commission rules on customer account information and privacy: The commission's rules and the utility's tariff require customer account information to be protected and released only to the customer or an authorized person; verification before any disclosure or change is how the utility meets the obligation, and the record shows it.
Identity proofing standards (NIST SP 800-63A and 800-63B as adopted by the utility's policy): The policy maps risk levels to identity assurance methods (possession of the contact on file, knowledge checks, document and liveness verification, database checks), with the methods allowed at each level set by the standard the utility adopts.

Company policies

One verification standard per risk level, applied in every channel; the agent cannot choose a weaker one.
The customer completes the step on their own device; the agent sees only the result.
Repeated failures and red flags are decided by the verification team, never waved through.
The result is recorded on the request in CIS as the account change's evidence.

Controls

Risk classification by request type.
Channel-independent verification on the customer's device.
Method ordering with chases on failure.
Red flag detection.
Decision Desk for failures and flags.
Result recording on the request and program reporting.

Clocks and deadlines

Verification before the change: Always; the change does not write without a recorded pass.
Recent contact change: A contact on file changed within the policy's period is not used for a code on a high-risk change.

Documents and checks

The risk classification
The attempts and the result
Any decision
The record on the request in CIS

In the Decision Trace

The risk level and the methods allowed.
The result and any decision with the person.

In the Audit Trace

Each attempt with channel, device and time.
The record on the request.

The handoff

Between the front doorand the back office.

The front door

The web, the Visual IVR, an AI assistant or an agent's link; the step runs on the customer's own device.

The back office

Agents see pass or fail; the verification team decides failures and flags; every change carries its evidence.

The Decision Desk

A repeated failure, a red flag or a customer who cannot complete any method goes to the verification team in the Decision Desk with the attempts and only pass with a further check, require documented verification, or decline and flag.

Proof

In scope.Proof at scale, not one process at a time.

The kind of process Callvu runs in production for customers in this industry. Ask for a reference on this exact process. The results below are the industry's published proof; each claim code links to its record on agents.callvu.com.

More than 1,000 processes are live across Callvu customers.

Across Callvu customers

PSEG Long Island runs start, stop and move service on Callvu, live in 4 weeks.

Across Callvu customers

Questions

What buyers ask next,answered plainly.

Is the verification the same on a call as on the web?

Yes. The request's risk level sets the method, and the customer completes it on their own device from a link the agent sends; the agent sees only pass or fail.

What is required for a high-risk change?

A change that redirects bills or money, adds an authorized user or transfers responsibility requires the stronger methods the program sets, such as a document read with a liveness check or a database check.

Where is the result kept?

On the request in CIS, with the method, the result, the time and the channel, so the account change carries its verification evidence.

Related processes

Identity theft and fraudulent account claims Start service for a new customer Contact details and paperless billing changes Add or remove an authorized contact Try it in the sandbox All utilities 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.