Grant the request capability against a written list of triggers, and nothing else. When a listed event occurs, such as a contact-detail change before a payment, the agent may send the customer a verification request at depth 3. Repeat requests after a failure are held for a person, and the agent never decides what a failed check means.
Why would an agent request identity checks, and who owns the decision?
Identity checks happen at onboarding, but also later: when a customer changes their phone number and then asks to move money, when someone calls claiming to be the account holder, when a dormant account wakes up. Agents that handle customer requests are often the first to see these moments. If they cannot ask for verification, they either refuse the request outright or carry on without assurance.
The KYC or fraud operations lead owns the trigger list and the identity verification service. Compliance approves the capability. Customer service owns the experience. The connection to the service itself, including what data the agent receives back, is covered in connecting an agent to your identity verification service.
Which permissions should the agent hold, and at what depth?
- Person, fraud or KYC lead: writes the trigger list. Each trigger with a precise definition, the check type to request, and what the agent may do while the check is pending.
- Person, compliance: approves the capability at depth 3 for listed triggers, with spend and frequency limits per customer and per day.
- Agent, depth 1: detects a trigger in the conversation or the account data.
- Agent, depth 3, within bounds: sends the verification request through the customer's verified channel, using approved wording, and pauses the triggering request.
- Agent, depth 1: reads the result when it returns.
- Agent, depth 3, within bounds: resumes the paused request if the check passed and the request is otherwise within its bounds.
- Agent, depth 2: drafts a referral if the check failed, timed out or returned a result needing review. A person decides what happens next.
- Person, fraud or KYC analyst: handles failures, including any repeat check, which is a held action.
| Capability | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Detect trigger | Recognises a listed event | 1 | Writing the list |
| Request check | Sends approved request | 3 | Approving triggers and limits |
| Read result | Reads outcome and reasons | 1 | None |
| Resume on pass | Continues the paused request | 3 | None, within bounds |
| Refer on fail | Drafts a referral with context | 2 | Deciding the outcome |
| Repeat check | Proposes, held | 2 | Approving a retry |
What is recorded, and which controls apply?
Trigger named on every request. A request without a listed trigger is refused. Evidence: each check in the service's records links to a trigger and a conversation or event.
Limits enforced outside the agent. Spend per day and checks per customer are set at the connection, not in the agent's instructions. Evidence: configured limits and any refusals they caused.
Independence from the request it protects. The agent requesting the check should not be able to waive it. If the customer argues or the check is slow, the agent cannot decide to proceed anyway. This is the same principle as in whether a compliance agent should be separate from the agents it checks: the control and the thing it controls should not share a switch.
Failures handled by people. Evidence: each failed check has a named reviewer and an outcome.
Customer told why. The verification request explains in plain words why it is being asked for. Evidence: the approved wording, versioned.
What should you measure?
- Checks requested per trigger over time, to spot drift.
- Pass, fail and abandon rates, by trigger. High abandonment may mean the check is too heavy for the moment.
- Fraud caught at triggered checks, from the analysts' outcomes.
- Requests refused for lack of a trigger.
- Customer complaints about verification.
Where does it usually go wrong?
Checks as a default. An agent unsure what to do asks for verification, again and again. Customers face repeated friction and costs rise. The trigger list exists to prevent this.
Staff and connected customers. A request to check a customer who is also an employee, or who is connected to a staff member, may need different handling. Where your conflicts procedure applies, see whether an agent can do conflict of interest checks.
Fraudsters controlling the channel. If the trigger is a change of contact details, sending the check to the new details defeats the purpose. Send it to the channel verified before the change.
Retries until a pass. Unlimited retries let a fraudster try several documents. Repeats are held.
No evidence for later questions. When a regulator asks how the firm protected customers from account takeover, you need the trigger, the check and the outcome for each case. Assembling evidence for a regulator information request is far easier when this record already exists.
The stance on compliance agents overall is in AI compliance agents.
Where Pryme fits
In Pryme, requesting a check is one capability with its own depth, certified on the customer's own cases before it runs at depth 3, and the certificate lapses after 90 days. The minimum chain applies at the moment of each request: role scope, certificate, sources, the customer's limits and the platform guardrails. A request outside the trigger list is refused, and the verdict names the bound that decided.
Questions people ask
Can the agent choose which type of check to request?
Only from the type the trigger list specifies. Choosing a lighter check because the customer is in a hurry is a judgement the agent should not make.
What does the agent tell the customer while the check is pending?
That the request is paused until verification completes, how to complete it, and how long it usually takes. It should not hint at fraud suspicion.
Should passed checks be reused?
For a short, defined period and for the same kind of request, if your policy allows. The reuse window is part of the trigger list, set by the fraud lead.