Account recovery and takeover
How do we recover a customer's account after a lockout or a takeover with identity verified, access restored, and the changes an attacker made reviewed and reversed?
Run recovery as a verified restoration with a review of what changed. When a customer is locked out or reports a takeover (an email changed, orders they did not place, a password that no longer works), Callvu classifies the case (a simple lockout, a suspected takeover, a confirmed takeover from the fraud signals) and the verification it warrants (a code to a contact on file from before the suspicious change, knowledge of recent orders only the customer has, a document check for a confirmed takeover), chases the verification on a secure screen, locks the account and holds pending orders and payouts while the review runs, lists every change since the last trusted login (the contacts, the addresses, the payment methods, the orders, the loyalty redemptions) for the customer to confirm or reject, routes a confirmed takeover and the reversals to the fraud desk in the Decision Desk, restores access with a new credential and the security settings reset, and writes the case and the reversals to the order management system.
In scopeComplex: multi-party handoffsCallvu moves: chase and verify, decide, write back
Last updated November 7, 2026.
The problem today
The account was recovered by resetting the password to the email the attacker had added, and the attacker recovered it again that night.
Account takeover is quiet: a reused password, a changed email, a new address, an order to it, a loyalty balance drained. The customer notices and calls. The agent resets the password, often through the very contact the attacker changed, and closes the ticket. The orders the attacker placed ship; the real customer is charged; the attacker returns.
Recovery has to verify the person through something the attacker did not control (a contact on file before the suspicious change, knowledge only the customer has, a document), lock everything while the review runs, show the customer every change since the last trusted login so they can reject the attacker's, reverse the orders and the redemptions that were not theirs, and reset the security settings so the door closes. The order and account records hold all of it; the process only has to use them in the right order.
A recovery that reviews what changed is a recovery that holds.
How it runs
From the requestto the system of record.
A customer reports a lockout or a takeover in any channel, or the fraud signals flag an account. Callvu opens the recovery case.
- Customer
- Verifies identity on a secure screen, reviews the changes and confirms or rejects each, and sets a new credential.
- Fraud desk
- Decides confirmed takeovers and the reversals in the Decision Desk.
- Callvu
- Classifies, verifies, locks, lists the changes, routes, restores and writes.
Classify and verify
The case is classified from the report and the signals (a lockout with no suspicious change, a suspected takeover with a recent contact or address change or an unusual login, a confirmed takeover with orders or redemptions the customer disputes), and the verification is chosen: a one-time code to a contact on file from before the earliest suspicious change, knowledge of recent orders and payment details only the customer has (never the full card), or a document and selfie check for a confirmed takeover; the customer completes it on a secure screen from a link, never through the changed contact.
Lock and list the changes
The account is locked for login, pending orders not yet shipped are held, payouts and loyalty redemptions are frozen, and every change since the last trusted login is listed from the account and order records: the contacts, the addresses, the payment methods added, the orders placed with their destinations, the loyalty redemptions, the linked devices; the customer confirms or rejects each on the secure screen.
Chase and verify, and decide
A rejected change is chased for the detail the reversal needs (which orders, which address); a simple lockout with a passed verification and no rejected changes restores by rule; a confirmed takeover (any rejected change) goes to the fraud desk in the Decision Desk with the list, the verification and the signals and only the allowed outcomes (restore with the reversals, restore with partial reversals and a dispute path for the rest, hold for investigation, or close the account at the customer's request with the data handled under the privacy rules).
Restore and write back
The rejected changes are reversed (the contacts restored, the attacker's addresses and payment methods removed, the held orders cancelled and refunded, the redemptions restored, the devices unlinked), the customer sets a new credential with the security settings reset (two-step verification required, the sessions ended), access is restored, the confirmation goes to the restored contacts, and the case with the verification, the changes, the decision and the reversals is written to the order management system, the system of record, against the account, feeding the fraud rules.
Where it ends: The customer was verified through something the attacker did not control, every change since the last trusted login was reviewed and the attacker's reversed, the security settings were reset, and the account was restored with the case on the record. The Decision Trace shows the classification, the verification and any decision; the Audit Trace shows the lock, each confirmation or rejection, each reversal and the restoration 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.
The handoff
Between the front doorand the back office.
The front door
Any channel for the report; the verification and the review on a secure screen from a link to a pre-change contact.
The back office
The fraud desk decides only confirmed takeovers; the reversals and the reset run from the decision.
The Decision Desk
- A confirmed takeover goes to the fraud desk in the Decision Desk with the change list, the verification and the signals and only restore with reversals, restore with partial reversals and a dispute path, hold for investigation, or close at the customer's request.
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
Questions
What buyers ask next,answered plainly.
How is the customer verified after a takeover?
Through something the attacker did not control: a code to a contact on file from before the suspicious change, knowledge only the customer has, or a document check for a confirmed takeover, on a secure screen; never through the changed email.
What is reviewed?
Every change since the last trusted login (contacts, addresses, payment methods, orders, redemptions, devices), which the customer confirms or rejects, with the rejected ones reversed.
What happens to orders the attacker placed?
Pending ones are held and cancelled with the refund to the original method; shipped ones go to the fraud desk with a dispute path, and the customer is advised to report to their bank inside the periods.
Related 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.