Fraud detection
Fraud is an attempt to misrepresent a speaker’s identity. A fraudster is a person who commits fraud attacks.
Fraud is an attempt to misrepresent an identity. A fraudster is someone who commits fraud attacks. Following are the examples of attacks:
- Attacks by known fraudsters: When your application enrolls newly detected or known fraudsters, Gatekeeper analyzes audio in realtime (during enrollment and verification) and detects when a known fraudster attempts to access the system. A known fraudster is someone under observation, and who is pre-enrolled in the system. The biometrics system keeps track of known fraudsters by adding them to a watchlist.
- Imposters who mimic legitimate customers: Fraudsters employ skilled voice talents who impersonate the voices of legitimate people. Gatekeeper detects that someone is not who he claims to be, but not a known fraudster.
- Playback of a recording: Fraudsters use voice recordings of legitimate people in order to gain unprivileged access to your system. Gatekeeper determines if the audio represents live speech or if it fraudulently uses a recording of an authorized individual.
- Use of synthesized speech with a fixed passphrase: Fraudsters learn the text of a common (shared) passphrase and employ various signaling techniques to mimic legitimate people. Gatekeeper detects when speech is electronically modified to sound like a legitimate speaker, and raises risk levels to warn applications about possible fraud attacks during enrollment, verification, and identification operations.
When Gatekeeper detects any type of fraud (when the risk scores exceed the configured thresholds), it flags engagements and Sessions as risky. In these cases, operators can prevent access to the Gatekeeper services. Below, see the methods that Gatekeeper uses to detect fraud.
Protect against playback fraud
Applications can test incoming audio to see if it represents live speech or if it fraudulently uses a recording that impersonates an authorized individual. For example, fraudsters can acquire such recordings by interception or “Vishing” (Voice Phishing). As a group, all these fraud attempts are known as playback attacks, and they are one of the main risks faced by biometrics systems.
For an overview of fraud detection (including additional mechanisms such as Synthetic Speech Detection) see Detecting Fraud.
To diminish this threat, the system has the following:
- Channel Playback Detection: Detects the presence of signal artifacts that are introduced by the recording and playback process, and isolates playback attacks based on a user-defined threshold.
- Footprint Playback Detection: Detects if a fraudster attempts to play a surreptitiously recorded audio. The operation determines if two audio buffers correspond to the same utterance by comparing the current audio with a saved “footprint” of a previously collected verification passphrase. If they match too closely, the current audio is marked as a recording.
- Liveness Detection: Detects intra-session voice variation by using an additional, random prompt to confirm that there is an active speaker seeking access, rather than a recording.
Application design is an additional factor in playback detection. For example, applications can use prompted verification, which requires people to repeat a random phrase. (Thus, a fraudster cannot pre-record the phrase.)
Applications can combine playback detection mechanisms to minimize the effect of small error rates associated with each mechanism. For example when the application uses both Channel and Footprint Playback Detection, the system inspects the audio with two different analyses. (If the system detects a channel playback attack, it does not perform the additional and unnecessary footprint analysis.)
Channel playback detection
This technique detects playbacks by detecting signal artifacts that are introduced by the recording and playback process. The system automatically estimates the risk level associated with each possible playback score and makes decisions (whether to reject an audio or not) by comparing the risk level to a factor threshold. Advantages of the channel playback mechanism as opposed to the footprint playback mechanism:
- Accuracy does not depend on previous, successful verifications.
- Detection does not require an existing print profile. (The mechanism analyzes any newly acquired audio.)
Footprint playback detection
Footprint Playback Detection relies on the principle that an individual never speaks the same phrase twice in exactly the same way, and utterances that are too similar should be treated with suspicion.
Footprint Playback Detection is part of the verification process. The system identifies audio segments that unnaturally match audio segments previously used for verification or enrollment, as follows:
- When audio is added, the system simultaneously creates and stores a footprint (a miniature representation of the audio file). Footprints are stored on a per-user basis.
- The next time audio is received for verification, the footprint is compared with all previous footprints. (Use MaxFootprints to control the total number.)
- A result is returned for each comparison between the newest footprint and a stored footprint.
Regarding performance, the error rate is the chance of incorrectly identifying an audio as too similar. As the number of footprints increase, the error rate increases. Recommended: have a maximum of 5-10 footprints (preferably footprints created from recently collected utterances).
Liveness detection
Liveness Detection mitigates the risk of fraudsters using voice recordings of legitimate people. Liveness Detection compares the voice sample captured during text-dependent verification with an additional sample that is the speaker’s repetition of a random or semi-random sentence. It generates a Liveness Detection score by combining the obtained biometrics score and a score that is extracted by validating the content of the repeated sentence (using Nuance ASR service).
Recommended: To improve detection accuracy, perform a data collection of people speaking liveness prompts.
Applications can implement Liveness Detection as follows:
- Prompt to repeat a text-dependent passphrase. (The speaker must already be enrolled with that passphrase.) For example, “My voice is my password.”
- Call the Verify method. The system compares the collected audio to the person’s print profile and generates a similarity score (similarity to the passphrase text) and a decision (Match or Mismatch).
- If the verification decision was Match, prompt the speaker to repeat a random sentence.
- Use GetLivenessPrompt to retrieve random prompts.
- Prompting the user to speak more than one random sentence increases accuracy, but is less convenient for the user.
- Validate the text in the audio recorded for the verification decision by calling ValidateText. Text validation checks whether the individual indeed repeated the requested sentence. As a recommended best practice, perform validation implicitly during Liveness Detection .
- Finally, call DetectLiveness, which compares the passphrase and verification audio and produces a similarity score and decision.
Note:
You can validate more than one random sentence. The final Liveness Detection score is the average of the scores produced by each repetition.When planning fraud detection, consider that the accuracy of Liveness Detection is greatly affected by the amount of audio collected. While a rough indication can be obtained using a single sentence, you can enhance accuracy with additional prompts when necessary. (Because the call duration is longer, consider using this method for high-risk transactions only.) The Liveness Detection score is provided in addition to the text-dependent verification score and can be used as an additional factor in the overall decision.
Validate the text of user speech
Use text validation to confirm that people are saying specific words and phrases in a collected audio segment. Use this feature in the following situations:
- Text-dependent enrollment and verification: As a recommended best practice, use text validation during the enrollment process as a condition for adding audio segments to enrollment audio collections. Later, use validation for passphrases during the verification process. In enrollment validation ensures the print profile quality, and in verification it is an additional layer of security (especially for unique passphrases).
- Liveness prompts: As part of Liveness Detection (to confirm that the individual repeats the prompted text).
- As a standalone procedure (executed by ValidateText) to add a non-biometric layer of security.
Text validation is performed by Nuance ASR service using two grammars. The main grammar that contains the sentences that we want to validate, and an optional decoy grammar that contains all possible sentences that we do not want to recognize.
- If the ASR result matches the first (main) grammar, then the spoken text was accepted.
- If the ASR result does not match the main grammar or matches the second (decoy) grammar, the spoken text was rejected.
The main grammar is dynamically created by Gatekeeper from a predefined template and the expected text that is passed in the APIs Enroll, Verify, Identify, DetectLiveness, and ValidateText.
Validate origination phone numbers
Use the ANI validation feature to check the authenticity of telephone numbers that call your application. The feature tests the ANI (also known as CallerID or CLI) or the SIP signaling info provided with a call’s telephony data, returns scores, and automatically adjusts risk levels. This is also an anti-spoofing feature because it detects fraudsters who spoof the telephone numbers of authentic users. No single authentication factor is definitive. To make security decisions, your application must combine the results of as many authentication and risk factors as needed depending on the acceptable risk-level. In addition, you configure a threshold for acceptable risks, which enables automatic processing for fraud detection, risk assessments, and decision-making.
Note:
When the CallerID API returns a valid score, it consumes the Gatekeeper license. If the API returns an error, Gatekeeper does not charge for the transaction.Authenticate with convoprints
Use convoprints to enhance Gatekeeper authentication. People speak with unique conversational patterns such as different lexicons, specific phrases, or frequency of certain words. Gatekeeper detects inconsistent patterns using the Nuance Text Security Library (NTSL).
The system creates convoprints from text. When accepting audio, Gatekeeper seamlessly transcribes the audio using the Nuance Transcription Engine (NTE), and then uses the text to create a convoprint for a specific person.
The workflow for convoprints is very similar to voiceprints: processText, enroll, train, verify, identify, detect known fraudster to get scores, get decisions, and so on. After processing an audio (or text), enroll the resulted text segment, train a convoprint, and use it to improve speaker authentication.
You can do the following possible tasks using convoprints:
- Create a new convoprint from audio or from text directly in the event of a digital live chats.
- Compare previously enrolled convoprints with new phone calls to detect consistent or inconsistent speech patterns.
- Manage and use convoprints through the API.
- Review historical comparisons using the web application.
- Delete convoprints using an API or using the web application.