Skip to main content

Risk Management Rules

What is Rules Management?​

Every transaction processed by Jumio is automatically evaluated using Default Risk Scoring, which is designed to assess fraud and compliance risks based on Jumio's built-in intelligence.

The Rules Management section of the Jumio Portal allows you to customize and enhance this default scoring by creating and managing your own rulesets. These rulesets can adjust the risk score based on your specific business needs.

Each ruleset is a collection of rules that analyze one or more data values returned by a capability and assign scores accordingly. When applied, these rules influence the final transaction risk score in addition to the default scoring.

tip

You don’t need to configure rulesets for scoring to occur—Jumio’s default rules apply automatically. Use Rules Management when you want to tailor scoring to your own risk model.

The Rules Management section comprises the following main sections:

  • Global Rulesets: Available to Jumio Solution Engineers to configure workflows according to services contracted.
  • Rules and Rulesets: Provides access to your organization’s rulesets. Users with appropriate permissions can view, create, and edit rulesets.

Velocity Rules​

Velocity rules provide a way to flag transactions that involve a suspicious number of actions taken within a given time period. For example you could create a rule that would raise a flag if the same ID number is submitted in five or more transactions across multiple accounts within a ten-minute time frame. Velocity rules can be created around devices, IPs, and other data points to help prevent high-risk transactions by detecting data anomalies in the user’s transaction history.

tip

Contact your Jumio Account Manager or Technical Support if you are interested in using velocity rules.

Use Cases​

Fraud Detection in Financial Transactions:​

Use Case: Detecting fraudulent activities such as credit card fraud or account takeover.

  • Action: Trigger an alert if the number of transactions or transaction amounts exceed predefined thresholds, indicating potential fraudulent activity.

  • Action: Trigger an alert if the number of times an end user uses multiple IP addresses or the same ID exceeds predefined thresholds, indicating potential fraudulent activity.

Authentication Anomaly Detection:​

Use Case: Identifying abnormal authentication patterns that may indicate an account takeover attempt.

  • Velocity Rule: Monitor the velocity of authentication attempts for each user account within short time intervals (e.g. 5-minute windows).

  • Action: Trigger an alert if the number of login attempts from a single user account exceeds a predefined threshold, indicating potential unauthorized access.

Location-Based Anomaly Detection:​

Use Case: Detecting account creation attempts from unusual or unexpected locations with repeated data.

  • Velocity Rule: Monitor the velocity of account creation attempts from different geographic locations with the same ID, within hourly or daily intervals.

  • Action: Flag login attempts originating from locations that deviate significantly from the user's initial login patterns, indicating potential account compromise.

Device Fingerprinting:​

Use Case: Identifying account creation attempts from unrecognized or suspicious devices.

  • Velocity Rule: Analyze the velocity of account creation attempts associated with unique device identifiers (e.g. device fingerprints) within short time intervals (e.g. 1-hour windows).

  • Action: Raise alerts for account creation attempts from devices with unusual or inconsistent characteristics, indicating potential fraudulent access attempts.

Velocity Rule Examples​

Basic Rule Examples:​

  • when Device ID Alias was seen 5 times in 10 minutes in within network, then risk score =15
  • when Device ID Alias, was seen 20 times in 1 day in assosciated network, then risk score =27
  • when ID Number was seen 5 times in 10 minutes in global network, then risk score =34
  • when ID Number was seen 20 times in 1 day in within network, then risk score =20

Complex Rule Examples:​

  • Same Device ID Alias, 5 times in 1 minute, WITH different IPs. - (Device ID Alias in 1 minute - Device ID Alias in 1 minute with same ip inside network > 5, then risk score =23)

  • Same Device ID Alias, 5 times in 1 minute, WITH different CustomerReferences. (Device ID Alias in 1 minute - Device ID Alias in 1 minute with same Customer Internal References inside network > 5, then risk score =27)

  • Same Device ID Alias, 30 times in 1 day, WITH different ID Numbers. (Device ID Alias in 1 minute - Device ID Alias + ID Number + ID Type + ID Sub Type in 1 day with same Customer Internal References inside network > 30, then risk score =17)

  • Same ID Number, 5 times in 1 minute, WITH different Full Name + DOB.

  • Same ID Number, 5 times in 1 minute, WITH different CustomerReferences.

  • Same ID Number, 30 times in 1 day, WITH different Device IDs.

Custom Fields in Rules​

This feature allows merchants to send pre-defined custom fields via API within the PREPARED_DATA parameter. These custom fields can be utilized to create rules that determine the risk level of a transaction.

Business Value​

  • Enables the ingestion of customer-specific, non-standard data fields for rule evaluation and risk decision-making, expanding beyond the standard Jumio data set.

  • Supports the inclusion of non-standard fields for further risk analysis, including graph-based evaluations.

  • Enhances flexibility for merchants by allowing custom data to be factored into risk calculations, optimizing fraud detection and user verification.

Functionality​

  1. Custom Field Definition in Jumio Portal

  • Merchants can define the custom fields and the formats they plan to use via the Jumio Portal interface.

  • Supported field formats include:

    • String
    • Array
    • Integer
    • Boolean
    • Object

  • The portal provides the ability to:

    • Add new custom fields
    • Delete existing fields
    • Modify (Change) field configurations as needed

  1. Rule Creation using Custom Fields
  • Customers can create custom rules based on the defined custom fields, enabling more granular and specific risk evaluations.
  • Custom rules allow for diverse use cases, including checks on non-standard data.
  1. Inclusion in Prepared Data
  • Once a merchant creates their custom fields, these fields become optional within the PREPARED_DATA sent via API.
  • If the fields are included, they will be used to determine risk scores or trigger custom rules.
      {
      "firstname":"John",
      "lastname":"Doe",
      "dateOfBirth":"1982-08-30",
      "customFields":{
        "customerInternalRiskScore":80,
        "customerStatus":"VIP"
      },
      ...

Benefits​

This feature enhances flexibility by allowing dynamic rule creation and ingestion of custom data fields that are not available as part of Jumio’s standard fields language, further empowering merchants to refine their risk strategies based on unique data inputs.

Table of Contents