Detecting Synthetic Voices on Calls
Cloned and converted voices now reach call centers and finance teams. A score that says a voice may be synthetic is useful when it triggers one more verification step, and harmful when it is treated as a verdict. This guide covers how to use it as the first, and what not to do.
A caller sounds like the finance director and asks for an urgent transfer. A customer calls the bank to raise a daily limit. Both used to be checked by recognising the voice, or by asking a few security questions the caller could answer from memory. Voice cloning and voice conversion tools have made the first check weak, and social media has made many of the second kind guessable.
A synthetic-voice score, a probability that the speech was generated or converted by a computer, can help. It helps only if it is wired in the right place: as a reason to ask for more proof of identity, never as proof of fraud on its own. This post covers what such a score can and cannot tell you, how to connect it to step-up verification, and the mistakes to avoid. It uses Saina Helm 2 Omni for the examples; the design applies to any spoof detector.
What a spoof score measures
A spoof detector listens to a short stretch of speech and estimates whether it came from a human voice or from a text-to-speech or voice conversion system. It says nothing about who is speaking. A real human can still be a fraudster, and a synthetic voice can be legitimate (an accessibility tool, a company's own voice bot calling back).
Omni's model card is explicit on this: identifying people, faces or the voices of specific individuals is out of scope, and a synthetic-voice score is a signal for extra verification, not proof of fraud. Speaker verification ("is this the account holder's voice?") is a different problem with different tools, and Omni does not do it.
What the published number means
The Omni card reports a held-out audio evaluation across 21 public sources. On ASVspoof 2019 LA, synthetic or converted voice against real speech, it answers 93% of 392 questions correctly.
Read that number with its context:
- It is a lab benchmark. ASVspoof 2019 LA is a public research dataset built from a fixed set of speech synthesis and voice conversion systems of that period. It measures how well a detector separates those attacks from real speech in that data.
- Newer generators are not in it. Voice cloning tools have changed a great deal since 2019. A model that does well on known attack types can do worse on a generator it has never heard.
- It is not phone audio. Calls pass through codecs, compression and line noise that change the sound. Test on recordings from your own phone system before you rely on the score.
- It is the card's held-out evaluation, not a guarantee on your calls. The overall audio figure across all 21 sources is 70.7%, and chance differs by source because questions have 2 to 8 options.
The card also lists non-English speech as largely untested. If your callers speak other languages, measure on those calls separately.
Use the score to step up verification
The safe pattern is a gate that can only add friction, never remove it:
- Score a short clip from the start of the call. Omni accepts clips of up to 10 seconds; a longer clip is refused, never cut. A few seconds of the caller speaking fits well inside that limit; see the windowing notes in sound event detection if you score more than one window.
- Run in decision mode. With a
threshold, ayes_noanswer comes back as yes, no, or no selection with a reason (below_threshold,below_margin,tie). - Route on three outcomes. If the spoof answer is yes, or the model is unsure, ask for a stronger check before the risky action: a callback to the number on file, a one-time code to the registered device, a question from the account history, or a second person approving a payment. If the answer is no, run your normal checks. Never skip them because the score was low.
- Tie it to the action, not the call. A balance enquiry and a request to change the payout account do not deserve the same response. Put the requested action in the state, and only gate the actions that move money or change credentials.
- Log the score with the outcome. Over time that gives you your own labelled set from your own channel, which is worth more than any public benchmark.
Treating an unsure answer like a yes is what makes this safe: a strict threshold sends more calls to extra verification, never fewer.
A request
Illustrative; the request shape follows the API docs, and the base64 string is cut short.
curl https://api.saina.run/v1/ask \
-H "Authorization: Bearer $SAINA_API_KEY" \
-H 'Content-Type: application/json' \
-d '{
"model": "saina-helm-2-omni-0.8b",
"mode": "decision",
"threshold": 0.8,
"state": "Inbound call to the bank: a short recording of English speech. The caller asks to raise their daily transfer limit.",
"audios": ["data:audio/wav;base64,UklGRi..."],
"questions": {
"spoof": {"type": "yes_no",
"question": "Is this speech synthesized or voice-converted by a computer (a spoof)?"}
}
}'
In your code, the rule is a single line: if answers.spoof.selected is anything other than false, require the stronger check. That covers both a yes and a rejected answer.
The state follows the card's advice for audio: say what the clip is ("a short recording of English speech") and keep the question short and literal about what is audible.
What not to do
- Don't block or accuse on the score. Ending a call or flagging an account because a model said "synthetic" will hit real customers, including people who use speech devices. Use the score to ask for more proof.
- Don't treat a low score as clearance. A "no" means the model did not hear signs of synthesis in that clip. It does not mean the caller is who they claim to be. Keep the normal checks.
- Don't use it to identify or profile people. Matching a voice to a person, or inferring traits about the speaker, is out of scope for this model.
- Don't feed it the whole call. Clips over 10 seconds are refused, and the model hears short clips as spectrograms. It can recognise short words; it does not follow long speech.
- Don't let the call's content steer the decision. Audio can carry spoken instructions just like text can. The output should only be able to add a verification step, which limits the damage if someone tries.
- Don't skip the legal check. Recording and analysing calls is regulated in many places. Make sure your call recording notices and data handling cover it.
When a dedicated vendor is the better choice
Voice-security companies such as Pindrop and Reality Defender work on this problem full time. If phone fraud is a large part of your losses, if you need someone else to own detection quality as attack tools change, or if you need it integrated with your telephony platform and fraud case management, a dedicated vendor is likely the better choice. Ask them for results on audio like yours, from your channel, rather than for a single benchmark figure.
A general audio decision model fits when you want a self-hostable signal you can run on your own servers (the weights are open under Apache 2.0, so call audio need not leave your infrastructure), when the spoof check is one question among several in the same request, or when you are prototyping the verification flow before choosing a vendor. Either way, the step-up design above stays the same.
Try it
With a free account, the Voice fraud check preset in the Studio playground lets you try your own recordings and change the question. Runs are charged in credits, and the cost is shown first. The card, with its full out-of-scope list, is at run-saina/saina-helm-2-omni-0.8b.