The agent asks the questions; your verification system decides. It collects what the customer provides, passes it to the system that holds the answers, and acts only on the pass or fail that comes back. It never sees the stored answers, never offers hints, and never upgrades a failed check because the caller sounds convincing. Third parties and failed checks go to a person.
What is the process, and who owns it?
Verification confirms that the person in the conversation is the account holder, or someone with authority over the account, before anything about the account is disclosed or changed. It is the gate in front of every other support capability. If it is weak, everything behind it is exposed.
The fraud or security lead owns the verification methods and the levels. The support lead owns the scripts and the handover for failures. Each level should be tied to what it opens up: general questions need none; account status needs a basic check; changes to contact details or payments need a strong one. The script structure is in the identity verification script template for support agents. The wider support position is in the AI support agent that knows when to say no.
How does the agent verify, step by step?
- Agent, depth 1: works out what level the request needs. From the request, using the level table the fraud lead approved. Evidence: the level chosen and why.
- Agent, depth 1: checks for an existing authenticated session. A customer already signed in to your app or website may already be verified to the right level. Evidence: the session result from your systems.
- Agent, depth 1: asks for the verification inputs. The ones the method requires, such as a one-time passcode sent to the registered device. It asks open questions and never includes account data in the question.
- Agent, depth 1: passes the inputs to the verification system. It does not compare them itself. Evidence: the request sent.
- Platform: receives the result. Pass, fail, or locked, with the level achieved. This is a sealed fact. Evidence: the result and its source.
- Agent, depth 1: proceeds at the level achieved, and no further. If the conversation moves to something that needs a higher level, it steps up verification before continuing.
- Person, support team: takes failed, locked and third-party cases. Evidence: the handover verdict and the reason.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Choose level | Maps the request to a level | 1 | Setting the levels |
| Session | Checks existing authentication | 1 | Nothing |
| Ask | Collects inputs without hints | 1 | Nothing |
| Submit | Sends inputs to the verification system | 1 | Nothing |
| Result | Acts on pass, fail or locked | 1 | Failed and locked cases |
| Step up | Re-verifies before sensitive requests | 1 | Nothing |
| Third parties | Nothing | None | Authority checks |
Every verification step is depth 1 because the agent decides nothing. That is the point. The decision belongs to a system built for it, and the agent's job is to run the process cleanly.
What stays with a person, and why?
Failed and locked checks. A customer who fails is either the account holder having a bad day or someone else trying their luck, and the agent cannot tell which. A person can use other methods and judgement, and is also harder to wear down with repeated attempts.
Third parties: a relative with power of attorney, an executor after a death, an accountant for a business account. Authority documents need to be checked and recorded, and the conversation is often sensitive. Document checks are a separate capability, discussed in can an AI agent verify a customer's identity documents.
The highest-risk requests sit with people too, even after a pass. Regaining access to a lost account is the usual route to takeover; see handling account recovery requests. Closing an account cannot be undone; see handling requests to delete an account.
Which controls matter, and what evidence do they leave?
The agent never holds the answers. It cannot leak what it never sees. Evidence: the agent's sources exclude stored credentials and verification data.
Only the system's result counts. Anything the customer claims, however detailed, is declared and cannot pass verification. Evidence: the result source on every verdict that depended on it.
No hints. Questions never contain account data, such as "is your postcode the one starting with M?". Evidence: the question text, sampled by the fraud lead.
Attempt limits. After the number of failures the fraud lead sets, the agent stops trying and hands over. Evidence: attempt count and lock status.
Level enforced per request. A pass at basic level does not open a payment change. Evidence: the level required and achieved, on every verdict.
Where does it usually go wrong?
Voice calls rely on what the caller knows. Date of birth and address are easy to find. Prefer methods that rely on something the customer has, such as a registered device. The particular weaknesses of phone verification are covered in can an AI agent verify a caller's identity.
The agent confirms a detail to be helpful. "That's not quite the address we have" tells a fraudster they are close. A failed check gets the same response every time, whatever was wrong.
Verification is done once and assumed. A customer verified at the start of a long chat asks, near the end, to change their phone number. Step up.
Urgency works on the agent. "I'm at the airport and my card's blocked" is a classic pressure script. The bound is the result, and the result does not change with urgency.
What should you measure?
- Pass, fail and lock rates by method and channel.
- Account takeovers that passed verification, investigated one by one.
- Step-up checks performed against requests that needed them.
- Hint leaks found in sampled transcripts. Should be zero.
- Time for failed customers to reach a person.
Where Pryme fits
In Pryme, the verification result from your own system arrives as sealed, and every account capability checks for the level it needs at the moment of action. Anything the caller says arrives as declared and cannot open an account. Each verdict records the level required and the level reached.
Questions people ask
Can the agent tell the customer which question they got wrong?
No. Saying which answer failed helps an impostor and rarely helps the real customer, who is better served by a person with other ways to verify.
Should verification happen before the customer says why they are calling?
Ask the reason first, so the agent knows what level is needed. Do not disclose anything about the account until the right level is reached.
What if the verification system is down?
The agent cannot verify, so it answers only general questions and offers a callback or a person. It does not fall back to its own checks.