The bigger your application, the more likely it is to be targeted by fraudsters. Fraudsters inspect and copy your app’s backend API requests and modify them to send verification codes to themselves to retrieve the SMS charges. This is called SMS pumping or IRSF fraud (read more about it here).

Signals

Prelude’s machine learning models use a number of signals to distinguish fraudulent users from legitimate users. We infer some of these signals, but many depend on the information provided by your integration. The more data you provide, the more effective fraud prevention will be and the higher your conversion rate will be.

Important signals to send to Prelude

To increase the effectiveness of fraud prevention, we recommend that you send the following signals to Prelude:

Data	Estimated improvement	Description
IP address	50%	The public IP v4 or v6 address of the end-user’s device. You should collect this from your backend. If your backend is behind a proxy, use the `X-Forwarded-For`, `Forwarded`, `True-Client-IP`, `CF-Connecting-IP` or an equivalent header to get the true public IP of the end-user’s device.
Device ID	40%	A unique ID for the user’s device. You should ensure that each user device has a unique device_id. Ideally, for Android, this corresponds to the `ANDROID_ID` and for iOS, this corresponds to the `identifierForVendor`.
Platform	35%	The platform of the user’s device (iOS or Android).
JA4 fingerprint	30%	The JA4 TLS fingerprint observed for the user’s connection. Prelude will infer it automatically when you use our Frontend SDKs (which use Prelude’s edge network), but you can also forward the value if you terminate TLS yourself.
Device model	20%	The model of the user’s device.
OS Version	20%	The version of the user’s device operating system.
App version	10%	The version of your application.

Inferring signals from the User-Agent

Some signals can be inferred from the User-Agent string if you provide it to us:

Platform
Device model
OS version

If the individual fields (os_version, device_platform, device_model) are provided, they will take precedence over those values instead of parsing them from the user agent string.

Adding more signals using our Frontend SDKs

You can add more signals that are collected directly from the user’s device using our Frontend SDKs.

Web SDK

Learn how to integrate the Web SDK into your application.

Android SDK

Learn how to integrate the Android SDK into your application.

iOS SDK

Learn how to integrate the iOS SDK into your application.

React Native SDK

Learn how to integrate the React Native SDK into your application.

Flutter SDK

Learn how to integrate the Flutter SDK into your application.

Selectively bypassing the anti-fraud system

This feature, if implemented incorrectly, could substantially increase the risk of fraud attacks. If you need this feature, contact our support team to validate your implementation, and to enable it on your account free of charge.

You can use the is_trusted_user signal to completely bypass the antifraud system for a specific verification request. This field should indicate the trustworthiness of the user on your app, beyond just a basic validity check. It should ensure trust by confirming that the user is genuine within the context of your application. Examples of validation criteria include whether the user has completed onboarding steps, performed valid transactions, or completed a purchase. When set to true, this will bypass fraud checks for that user.

Forcing a verification into challenge mode

This feature is disabled by default. Contact our support team to enable it on your account.

Set options.force_challenge to true on the create-verification request when you have your own signal that a request is suspicious and want stricter routing — for example, when your application has detected automated behavior, an unusual sign-in pattern, or a velocity anomaly that Prelude’s signals alone wouldn’t see. When set:

The verification is routed through challenge-safe channels (non-SMS and non-voice) regardless of country or any antispam outcome.
The response status is challenged. If no challenge-safe channel is available for the destination, the verification is returned as blocked.
The verification is not classified as fraud — it does not contribute to anti-fraud counters or risk factors, and it is not surfaced as suspicious traffic in the dashboard.

POST /v2/verification
{
  "target": { "type": "phone_number", "value": "+40123456789" },
  "options": { "force_challenge": true }
}

Allow and block lists

You can configure your integration to allow or block specific users from signing in. This can be useful if you want to manually block users you have identified as fraudulent or to disable anti-fraud algorithms for specific users. To edit the allow or block lists, go to the Dashboard and navigate to the Verify API > Configure > Numbers tab.

Documentation

API Reference

Prevent Fraud

Signals

Important signals to send to Prelude

Inferring signals from the User-Agent

Adding more signals using our Frontend SDKs

Web SDK

Android SDK

iOS SDK

React Native SDK

Flutter SDK

Selectively bypassing the anti-fraud system

Forcing a verification into challenge mode

Allow and block lists

​Signals

​Important signals to send to Prelude

​Inferring signals from the User-Agent

​Adding more signals using our Frontend SDKs

Web SDK

Android SDK

iOS SDK

React Native SDK

Flutter SDK

​Selectively bypassing the anti-fraud system

​Forcing a verification into challenge mode

​Allow and block lists

Signals

Important signals to send to Prelude

Inferring signals from the User-Agent

Adding more signals using our Frontend SDKs

Selectively bypassing the anti-fraud system

Forcing a verification into challenge mode

Allow and block lists