Authentication and Fraud Detection

Note: This topic is relevant for FreeSpeech, FraudMiner, and VocalPassword.

To confirm the identity of customers, your application uses layers of authentication techniques to achieve any level of desired security. For example, you would allow lower security for a banking customer to confirm a payment and higher security to transfer funds to an external account. Because application use more than one technique, this is known as multi-factor authentication .

Multi-factor authentication is not a single feature but instead is an approach that combines mechanisms to confirm identities. Your application defines the needed security level (low, medium, high), and then executes authentication factors one at a time until that level is reached. Security Suite returns scores for each factor and presents an overall assessment of all executed factors in the form of session-level authentication decisions (match, mismatch, or inconclusive for voiceprints) and risk levels (low, medium, high). Security Suite presents for investigation by fraud analysts in the web applications (see Using the Sessions and Risky Sessions View ). In addition, your application can consult the results programmatically during a session after each factor. For example, when the executed factors suggest fraudulent activity, your application can elevate the required security threshold before executing the next factor.

The platform supplies numerous authentication factors across a spectrum of mechanisms: analyzing biometric data, reviewing behavior patterns, focusing on the audio signal, and so on. Some factors are simpler to execute than others, and some require custom agreements and licenses. For a detailed description of factors, see Tables of Authentication and Risk Factors.

The following figure shows the inputs and output of the risk engine. (Technically, the engine is a module within the processing server. It is drawn here as a separate component for clarity.)

The calling application sends the risk engine the required authentication level. The calling application invokes factors in the processing server, and the processing server sends scores and decisions to the risk engine. The risk engine considers all factors, saves alerts to the database and returns a session decision.

  1. At the start of a session, your application configures a desired level of security for the type of transaction (a required authentication level), and begins invoking authentication and fraud factors.
  2. The risk engine returns results for each factor along with accumulated results for session decisions and risk levels.
    • Security Suite uses your required authentication level to calculate the session decision. Authentication is most useful for real-time processing while the customer is connected to the session.
    • Security Suite uses the risk level as an indicator of fraudulent activity in the session. Risk assessment is most useful for offline processing by a fraud analyst.
  3. Your application checks results after each factor, assesses progress towards a conclusive decision, and takes the necessary business decisions. Your application can manage results at any level of detail: you can rely on the accumulated session decision and risk assessment, you can review the result of each factor individually, and you can get raw scores and make your own calculations.
  4. The application can adjust the required authentication level during the session depending on the transaction involved. In other words, you can have different authentication levels for different transactions during the same session. For example, a low level for the customer logon, a higher level when the customer requests private information, and a very high level for a monetary transaction. When you change the level, no previous factor results are lost.

Factors need to be enabled and enrolled

To use a factor, your application must enable it in a factor configuration profile (see FactorConfiguration). For example, you can define different configurations for different usage scenarios, and some profiles might enable a given factor, and others might disable it.

Note: Factors can require explicit licensing. If a license is missing, you can enable the factor but your application gets a licensing error when executing the factor.

Many factors require a previously enrolled print (for example, a deviceprint or voiceprint). When your application uses a factor, Security Suite indicates whether the prerequisite enrollment was performed. (If a factor does not require an enrolled print, Security Suite indicates the value Unknown.)

Some factors are more conclusive than others

Different factors have different weights in the engine's calculations. Some factors strongly detect fraud, and others are less strong. Some help with authentication but not fraud, and others help with fraud but not authentication. For example:

  • Some factors return strong confidence for authentication. Success is the most influential result, and failure can indicate a degree of fraud.
  • Some factors can support your confidence for authentication. Success is not definitive, and failure doesn’t indicate any degree of fraud.
  • Some factors are entirely for fraud detection. Success is a strong indication of fraud, but passing it does not contribute to the level of trust in the user’s authenticity.

When testing and initially deploying applications, you can configure factor weights to tune results. Most applications use the default values initially, or they decide the relative importance of the factors and remove weights from secondary factors. (A factor with weight=0 is neutral in terms of risk calculations.)

Note: Use fewer authentication factors for low security needs, and use more factors for high security.

Some factors affect the results of other factors

The results of one authentication factor can inform the results of another. The risk engine handles this internally, but it's helpful to understand some obvious interactions:

Your application invokes one factor at a time

Session decisions and risk levels are the result of accumulated scores. Each factor can affect the scores upward or downward.

Consider the following sequence where each step is a single factor:

  1. Voiceprint Match → the authentication score increases
  2. Playback detection yields a Playback result → the risk engine annuls the previous voiceprint match
  3. Liveness detection yields a Match → this contradicts the playback result and resurrects the voiceprint match

How audio quality affects decisions

The system automatically examines audio quality, and returns one of the following decisions when poor quality is detected:

Poor quality decisions

Reason for mismatch


Audio Too Short

The audio was shorter than required to perform speaker verification.

Audio Too Long

The audio was unexpectedly longer than required to perform speaker verification.

Audio Too Noisy

The energy difference (active-silent) of the audio surpasses the Audio Too Noisy threshold.

Audio Too Loud

The number of samples that are too loud surpasses the configured threshold.

Audio Too Soft

The audio was quieter than required.

Tone Detected

The audio included tones such as DTMF, fax, and so on. When configured, the system can ignore the tones and continue processing.

Multi-Speakers Detected

The system detected that more than one person speaking in the verification audio.

For more information, see How the system computes audio quality.

Note: By default, the system does not block enrollment or verification due to noisy audio, short audio segments and so on. To modify the configuration, see AudioTooLoudThreshold.