Fraud Prevention Engine

The core of the Singular Fraud Prevention Engine consists of two parts:

  1. Singular Protection Methods: Singular detection and preventions methods can be activated at the click of a button (see Managing the Singular Protection Methods). These methods are built and refined by our fraud experts to protect against the most common types of fraud.
  2. User Defined Rules: Singular supports the creation of user defined custom rules that can be leveraged by users to address their specific needs.

The Engine checks each end-user touchpoint against all of the Singular protection methods and any existing user-defined rules and marks the touchpoint as:

  • Whitelisted: Any touchpoint that matches a whitelisting rule is considered valid and no other rule is applied to it.
  • Rejected: Any touchpoint matching this rule/method is rejected.
  • Suspicious: Any touchpoint matching this rule/method is still considered valid for attribution but also marked as suspicious.

Decision is based on the first matching rule and so the order of evaluation is important. Whitelisting rules are evaluated first to make sure any whitelisted touchpoint is not rejected. Then come rejection rules and finally suspicion rules.

Singular Protection Methods

Singular has conducted extensive research into attribution fraud to detect and implement the most useful and actionable fraud prevention methods in the market.

One of the results of that research is the calculated effectiveness of each of the different methods in the market today:

Taken from Singular’s 2017 Fraud Index

Based on these results, we have chosen and tuned the most effective methods and have made them easily accessible in the UI. We fine-tuned the methods based on the collective information from Singular’s clients to achieve the best results while minimizing the false-positive rate.

The pre-defined methods Singular employs are:

Blacklisted IPs

The method is triggered when a touchpoint’s IP address matches a blacklisted IP range.
Singular maintains a list of blacklisted IPs that updates continuously, the list contains IP addresses of:

  1. Cloud Service Providers and Data Centers
  2. Proxy and IP anonymization services
  3. TOR exit points
  4. High risk IPs: IPs thats have been spotted doing fraudulent or other abusive activity on the internet.


This method triggers in the case of impossible travel - i.e if an end-user moved at impossible speeds from the click location to the install location.
For example, if an end-user clicks an Ad and two hours afterwards Singular receives an install-event from 10K kilometers away.


In many cases click spamming and click injection creates an influx of clicks from the same source. The Hyper-Engagement method detects this influx and takes action to reject clicks coming from the same source.

TTI Outliers

Click Injection attacks are performed by detecting an installation and firing a fake-click. Since the click is fired as the app finished installing - it will often result in an abnormally short Time-to-Install (TTI).
This methods detects the cases of abnormally short TTIs.

iOS Install Receipt Validation

Apple provides a receipt for each app installed on an iOS device through iTunes.
The receipt can be used to verify that the app has been installed by a real user on a real device.
Receipt verification is a multi step process:

  1. Making sure that a receipt exists.
  2. Verifying the authenticity of the receipt by checking Apple’s digital signature.
  3. Validating the receipt by matching the receipt’s details to the current installation (for example comparing the app’s longname).
  4. Ensuring that the receipt hasn’t been used for another install (so that fraudsters wouldn’t re-use the same receipt on multiple installations / devices).

Note: Singular preforms receipt validation only on devices with iOS 7.0 or higher and only when the app includes a Singular SDK of version 8.2 or higher.

Configuring the Singular Protection Methods

To manage the Protection Methods used in your account, go to Fraud Prevention > Settings.

The Settings page displays all the methods along with their associated actions. The actions dictate what happens when the protection method is triggered. Change the action and save the settings to change the behavior of the Fraud Engine immediately.

The possible actions are:

  • Do Nothing: If this action is chosen, the method is disabled and will not affect the attribution decision or reporting.
  • Mark as Suspicious: The method flags touchpoints as suspicious but doesn’t affect attribution decision.
  • Reject: The method rejects touchpoints and prevents CPI and CPA billing postbacks.

Configuring User-Defined Rules

Sometimes you may require more granular control over fraud decision-making. For that purpose, Singular provides User-Defined Rules which you can define to prevent types of fraud that are specific to your apps.

To configure User-Defined Rules:

  1. Go to Fraud Prevention > Rules.
  2. Select Create New Rule and fill out the rule form.

Rule Form Fields

Rule Name

Identifies the rule and also shows up in the Reason dimension in the fraud report if it is triggered.

Rule Conditions


Conditions define the cases in which a rule will be triggered. Multiple conditions can be set for each rule and all of them need to apply for the rule to trigger on a touchpoint.

Each condition is built from three parts:

  1. Field: the field that is being evaluated based on the touchpoint and install. For example if the field is Source - the condition will be based on the source (Ad Network) of the touchpoint.
  2. Operator: the operator defines the relation between the field and the values.
  3. Values: the values used on the right side of the operator for the condition.

The possible fields are:

  • Source: The touchpoint’s source name.
  • App: The installed app.
  • Publisher: The touchpoint’s publisher ID.
  • Time to Install: The time from click to install, can be set to get less than number of seconds or greater than number of days.
  • Duplicate Clicks: The number from clicks from the same Ad Network.
  • Click Country: Originating country of the touchpoint (based of IP address)
  • Install Country: Originating country of the install (based of IP address)
  • Campaign Name: The name of the touchpoint’s campaign.
  • Attribution Method: The method used for attribution: strong identifier or fingerprint.
  • Receipt Validation: Is the supplied install receipt for iOS valid (see iOS Install Receipt Validation).
  • Click to Install Distance: The distance (based on IP geolocation) in kilometers the device has moved from the click event to the install event.
  • Click to Install Speed: The speed (based on IP geolocation) in kilometer per hour in which the device has moved from the click event to the install event.
  • Install Source: Android apps can query the package name that initiated their installation, this package name would be different if the app was installed by different stores or sideloaded as an APK.
  • App version: The version of the App (see versions comparison for more details).
  • OS version: The version of the OS (see versions comparison for more details).
  • OS: The device's OS (Android/iOS).
  • Touchpoint type: The touchpoint's type (Click/Impression).

Rule Action & Status

Actions dictate what happens when the rule’s conditions match a touchpoint. The different possible actions are:

  1. Whitelist: any touchpoint that matches a whitelisting rule will be considered valid and no other rule will be evaluated on it.
  2. Reject: any touchpoint matching this rule will be rejected.
  3. Mark as Suspicious: any touchpoint matching this rule will still be considered valid for attribution but will also be marked as suspicious.

The rule status can be used to quickly turn rules on or off.

Versions Comparison

Generally, version names have a structure to them. We check to see that the versions that are entered adhere to that structure.

  • The structure is as follows:Positive numbers separated by dots.
  • After the digits, a “-” followed by one the 4 types of suffixes:
    • alpha
    • beta
    • rc-x
    • dev

Valid Examples:

  • 2.3.5
  • 3.4-alpha
  • 4.5-rc3

Invalid Examples:

  • 2.3-master
  • 3.4Alpha
  • Alpha
Was this article helpful?
0 out of 0 found this helpful