Synthetic-voice impersonation
A caller may imitate an account holder or executive. Verification on the enrolled handset adds evidence beyond the call audio.
← All use cases
Integration pattern · Illustrative scenarios and policy values. Confirm supported signals, processing location, and application enforcement for your deployment.
Why voice and knowledge questions are no longer enough
A convincing voice and familiar account details can be imitated or stolen. A fresh verification request on the enrolled device gives the customer a separate chance to approve the actual action.
What the out-of-band check defends against
All three of these attack patterns end the same way for the agent: the action is held until a verified human attests on their enrolled handset.
Social-engineering scripts
Account details and security-question answers can be exposed. Require a fresh check instead of relying on those details alone.
Insider-assisted release
Configure the receiving system to hold sensitive actions until both staff permissions and the required customer approval are valid.
In-call flow
The same anti-impersonation pattern shipped in our agent demo, applied to a contact-center workflow.
Agent triggers the challenge from the CRM
On account actions over the policy threshold (transfer, beneficiary change, password reset, address change), the CRM calls the BioTone broker with the customer subject id and an action_context describing the request.
Challenge opens on the customer's enrolled handset
The customer sees the action description on their phone — the same one they enrolled on — before any biometric capture starts. They can decline or report the call as suspicious from the same screen.
Multi-signal capture on the phone
The customer's phone captures the signals required by policy, such as periocular, palm, or voice, alongside liveness checks. Processing follows the selected deployment mode; voice capture is separate from the support call.
Signed assertion attaches to the case file
On a successful in-window assertion the action is released and the signed JWT is logged on the case. Failures and timeouts are logged the same way for fraud review.
When to require it
The BioTone step is policy-gated, not on every call. Common starting points:
- Transfers over $X to a non-allowlisted beneficiary.
- Beneficiary, address, or contact change on a high-value account.
- Password / MFA reset requested from a new device or geography.
- Bulk export, data download, or batch action on a workforce account.
- Any action on a flagged account currently under fraud review.
Lower-risk requests can stay on whatever flow you use today. The point is to make the high-risk surface — where most loss concentrates — require fresh verification beyond the call itself.
Anti-impersonation scenario in the agent demo
Bring a representative high-risk action (e.g. a wire, beneficiary change, or credential reset). We will reproduce the impersonation attempt and the BioTone hold in a live walkthrough.