Truthring
For security, fraud and incident response

The callback stops the fraud. Analysis only explains it afterwards.

Nothing here is a preventive control. A synthetic-speech analysis runs on a file, minutes or days after the call that mattered, and its value sits in the investigation and the lessons-learned write-up rather than in the moment the money moves.


Put it in the right phase of the runbook

Map it against whichever lifecycle your programme uses and it lands in the same two places. Not detection, because nothing about it watches a channel or raises an alert. Not containment, because by the time a file reaches an analyst the call has ended. It belongs in investigation and in post-incident review.

That distinction survives contact with an executive who has read a headline and wants to know whether the company can now spot deepfake callers. You cannot spot them on the line with this. The control that does work involves no model at all: any instruction that moves money, changes bank details or resets credentials is verified by calling back on a number your directory already holds, with no exception for urgency and none for seniority, because those are the two levers the attack pulls. Analysis earns its place after that control has held or failed, telling you whether synthesis was involved and sometimes which family produced it — the difference between a capable adversary and an opportunist with a free tool.


Preserve the audio before anyone helps

This is where internal investigations lose the evidence, and they lose it to colleagues trying to be useful. Someone forwards the voice note into a group chat so the team can hear it. Someone else plays it on speaker and records that on a phone. A third converts it to MP3 for a ticket. Each of those re-encodes the audio, and re-encoding is lossy in exactly the frequency detail an analysis reads. The rule is short enough for a runbook: move files, do not replay them.

Do

Export from the source system in its original container. Move it over a transfer that does not transcode. Hash it immediately and record the hash, where it came from, who handled it and when. Keep the first copy untouched and work on a duplicate.

Do not

Forward through messaging apps, which re-compress on every hop. Screen-record a player. Trim, normalise or noise-reduce. Convert format “so it opens”. Leave the only copy in a chat thread whose retention policy nobody has checked.

Voicemail platforms often re-encode when a message is emailed as an attachment, so pull from the platform. Conferencing tools usually keep a better recording than the copy shared to a channel. If a forwarded voice note is all you have, run it anyway but read the result as a statement about that copy: an unclear verdict on a file that has been through three apps is a fact about the distribution chain.


Triaging a suspected voice-fraud report

The report arrives as someone saying they were called by a person who sounded like a colleague. Before anything technical, three questions shape the response.

01

Did anything move?

Payment, credential reset, MFA enrolment, access granted. If so, finance and identity workstreams start now and run ahead of any analysis. Recall windows are measured in hours.

02

Does audio exist at all?

Most vishing calls are never recorded, which quietly ends the forensic question. Voice notes, voicemail and conference recordings are where a file will be. Establish this before promising anyone an answer.

03

One report or a pattern?

Check whether other staff were contacted the same way. A shared generator signature across cases is a linking signal the call logs will not give you.

Only then is analysis worth queueing. It will not name the caller. What it can do is end the argument about whether the voice was obviously fake — otherwise settled by ear, and settled badly, because human listeners are poor at this and confident about it. Record the reference code and engine version in the case, not the verdict alone. The incident checklist has the sequencing in copyable form, and what to do after a voice scam covers the same ground for the affected individual.


The internal-comms problem nobody plans for

At some point the tool will flag a recording of an employee who did nothing wrong. Genuine speech is flagged at a rate that is not zero, and the rate is worst on exactly the material you hold most of: compressed call recordings, short voice notes, cheap microphones in noisy rooms. A verdict lands in a security channel, someone screenshots it, and within an hour a dozen people believe a colleague faked a recording. The colleague cannot prove otherwise, because no evidence exists that shows a person’s own voice was real. The accusation is unanswerable, which is what makes it corrosive.

Three rules contain it. A verdict is investigation material, not a broadcast — it goes in the case, not in a channel, and screenshots of scores do not circulate. The person hears it from a named human first, with the confidence, the audio conditions and the error rate explained. Withdrawal is as loud as the flag was: if the finding does not hold, the correction reaches everyone who saw the original and says the analysis was inconclusive, not that someone was cleared on a technicality. Write these in before deployment; after the first incident, the team that got it wrong is the team drafting the apology.


What this cannot do for your team

It cannot prevent an incident. No inline monitoring, no alerting, no blocking, no prompt mid-call. If your requirement is a preventive control, this is not one.

It cannot identify the attacker. No speaker comparison, no voiceprint matching, no attribution to a person, device or location. Generator-family attribution names a class of tool, and it decays within weeks of a vendor shipping a new model.

It cannot clear a call. A likely human verdict means no generation signature was found, which on compressed telephone audio is weak evidence and often just means the channel destroyed the signal. Read it as an absence of finding, never as verification.

It cannot tell you what was said or whether it was true. The analysis does not read language, and social engineering delivered in an entirely genuine voice remains the commonest version of this attack.

It cannot justify action against a member of staff. Suspension, dismissal or removal of access on the strength of a score is the failure mode that causes real harm. A named human weighs the analysis against the access logs, the payment trail and the device evidence, and owns the decision in terms they could defend at a tribunal.


Questions from incident responders

Can we integrate this with the SIEM or the case management tool?

Through the API, submitting a file and storing the verdict, confidence, conditions and reference code against the case. Design for the three-state output: unclear is a genuine result, and mapping it onto human or synthetic invents a decision your process never made. Route unclear results to an analyst rather than a default.

What do you keep from a submitted file?

Audio will be deleted after analysis and a one-way hash retained [VERIFY: retention not yet set] so a report can be tied to the exact file. Before uploading evidence from a live investigation, check data retention and security against your own evidence-handling policy.

Will an analysis stand up if the matter goes legal?

It is a screening document, not an expert opinion, and it does not establish chain of custody for you — that is your handling record. If proceedings are realistic, preserve the original, log every handling step and instruct a forensic examiner. The page for lawyers sets out the distinction.


Fix the runbook before you buy the tool

The preservation rule and the callback rule are free and decide whether any later analysis has anything to work with. After those, a tabletop rehearsing a cloned executive rather than the ransomware scenario everyone has run twice, and a reporting path an employee will use after being fooled — one that does not open with blame. How these scams are run covers the pretexts.

Recording, retaining and analysing calls involving staff or customers carries obligations that differ by jurisdiction. [VERIFY: confirm the position with your own legal and privacy functions in each market you operate in] Nothing here is legal advice.

Reviewed