SMS Pumping Risk Score

SMS Pumping Risk Score allows you to get real-time risk assessment on a phone number's involvement in SMS pumping fraud. It uses a proprietary risk model that was built leveraging data across Twilio's network including signals from Verify Fraud Guard as well as other signals associated with risky carriers, anomalous SMS traffic patterns, and low conversion rates.

The SMS Pumping Risk Score was developed to be or complement your in-house SMS Pumping fraud detection service. Its patented design allows you to receive a real-time risk assessment of your SMS traffic no matter which messaging provider you choose to send traffic.

Coverage and Limitations: Worldwide support; no carrier information will be returned for Canadian phone numbers. We do not recommend using this product for US or Canadian numbers as they are generally not susceptible to this type of fraud.

Release Stage and Access: General access (GA), available via self-service.

To make a SMS Pumping Risk Score request, add sms_pumping_risk to the optional query parameter Fields when making a standard Lookup request.

SMS Pumping Risk Score Lookup

1// Download the helper library from https://www.twilio.com/docs/node/install
2const twilio = require("twilio"); // Or, for ESM: import twilio from "twilio";
3
4// Find your Account SID and Auth Token at twilio.com/console
5// and set the environment variables. See http://twil.io/secure
6const accountSid = process.env.TWILIO_ACCOUNT_SID;
7const authToken = process.env.TWILIO_AUTH_TOKEN;
8const client = twilio(accountSid, authToken);
9
10async function fetchPhoneNumber() {
11  const phoneNumber = await client.lookups.v2
12    .phoneNumbers("+447772000001")
13    .fetch({ fields: "sms_pumping_risk" });
14
15  console.log(phoneNumber.smsPumpingRisk);
16}
17
18fetchPhoneNumber();

Output

1{
2  "calling_country_code": "1",
3  "country_code": "US",
4  "phone_number": "+447772000001",
5  "national_format": "(415) 992-9960",
6  "valid": true,
7  "validation_errors": [],
8  "caller_name": null,
9  "sim_swap": null,
10  "call_forwarding": null,
11  "line_status": null,
12  "line_type_intelligence": null,
13  "identity_match": null,
14  "reassigned_number": null,
15  "sms_pumping_risk": {
16    "carrier_risk_category": "moderate",
17    "number_blocked": false,
18    "number_blocked_date": null,
19    "number_blocked_last_3_months": null,
20    "sms_pumping_risk_score": 61,
21    "error_code": null
22  },
23  "phone_number_quality_score": null,
24  "pre_fill": null,
25  "url": "https://lookups.twilio.com/v2/PhoneNumbers/+14159929960"
26}

Response properties

The following additional properties are returned for a SMS Pumping Risk Score request.

Property	Description
`CarrierRiskCategory`	The risk category of a carrier based on its risk score. One of: `high`, `moderate`, `mild` , `low`.
`NumberBlocked`	A Boolean that indicates if the phone number is currently blocked by Verify Fraud Guard for receiving malicious SMS pumping traffic.
`NumberBlockedDate`	The date that a phone number was most recently blocked by Verify Fraud Guard, or `null` if it has never been blocked or processed by Fraud Guard.
`NumberBlockedLast3Months`	A Boolean that indicates if the phone number has been blocked by Verify Fraud Guard in the last three months. Returns `null` if the number has never been processed by Fraud Guard.
`SmsPumpingRiskScore`	The risk score of a phone number being associated with SMS pumping based on patterns in messaging traffic ranging from 0 (no risk) to 100 (risk).
`ErrorCode`	The error code, if any, associated with your request.

Suggested implementation logic

How you implement this feature will depend on your own application structure and risk tolerance, however we can provide some general suggestions. When a user enters their phone number to receive an OTP or other message from your system, you can query the SMS Pumping Risk Score feature to determine whether or not you should send that message.

The primary response property you should queue your integration off of is the SmsPumpingRiskScore. You can use the following as general guidelines for how risky a phone number might be:

Low Risk: 0 - 60
Mild Risk: 60 - 75
Moderate Risk: 75 - 90
High Risk: 90 - 100

As the risk scores increase we recommend introducing additional friction, and finally at a certain point we would recommend not sending the message at all. For Risk Scores less than 60 you could generally consider the phone number to be safe enough to send as requested. If the Risk Score is between 60 and 75, you may want to ask the requester to re-submit the request, or add some other form of friction to validate the request prior to sending the message. For Scores greater than 75 we suggest you treat the request as suspicious, and for Risk Scores between 90 and 100 we would not recommend sending the message.

If you would like to also include blocks that are currently being applied on other customer accounts by our Fraud Guard solution on Verify, you can leverage the NumberBlocked parameter and block any messages which return True. Please note that this may result in higher false positive rates in high risk countries.

You can also use any combination of the response parameters to build out a fully customized set of conditions to trigger various workflows in your system based on your own risk tolerance levels.

FAQs

How is the SMS Pumping Risk Score calculated?

We use several risk signals about the phone number that is being requested through the API and feed those signals into our proprietary algorithm. The algorithm also leverages your API call into the product as a signal that a message is being requested, therefore it's important for the algorithm to see all your traffic for a given user-generated OTP request flow for a given country.

We leverage the API call into Lookup as a signal because the product was initially developed so that even customers who do not use Twilio as their CPaaS provider for all their traffic would only need to use one fraud detection product to protect them against SMS Pumping fraud.

It's also important to note that the Pumping Risk Score you're seeing is specific to your Account SID. This means that 1) no other customer's traffic influences your Pumping Risk Scores, and 2) if you plan on calling the API from multiple Account SIDs, the Pumping Risk Scores on one Account SID will be independent of the other(s).

How should I design our POC or test the product?

The ideal design would be to query the Lookup API in a shadow mode on your production traffic.

Second best to that would be to run all of your traffic for a given country for a specific period of time through the API, in the time it was requested. What does this mean exactly?

This means that the time, or when, a message was requested is important. So if you take 30 days of traffic for a given country and feed that through the API in 3 minutes, the algorithm will assume all that traffic is being requested in 3 minutes. If you do this there is a (significant) risk that the scores will be artificially inflated and not reflect what they would be if you had been using the product on your production traffic.

Do I really need to send all my traffic for a country to the API?

Yes. In order for the solution to be effective you should make an API call for SMS Pumping Risk Score prior to every user-generated OTP request for a given country.

Can I cache the scores?

This is not recommended for this product, as the scores are highly dynamic and can change drastically in seconds, depending on the traffic the API is seeing on your account. Caching scores can negatively impact the efficacy of this product in two ways:

If there was a false positive, you've now cached that false positive. These scores are very dynamic, so it's possible for the score to be high risk one day (eg, if you were experiencing a fraud event) but low risk tomorrow (if that fraudster then stopped).
When you cache scores it means you won't hit the API when you receive another request for that same number. Fraudsters typically recycle phone numbers, but if the fraudster started very slowly ramping up traffic, and the algorithm hadn't caught onto their traffic pattern yet, you've now potentially given a free pass for thousands of phone numbers to continue to receive messages. This means the algorithm will not see that traffic, therefore it won't know you're receiving additional requests, thereby reducing the precision of the algorithm.