SMS Pumping Risk allows you to get real-time risk assessment on a phone number's involvement in SMS pumping fraud. It uses a proprietary risk assessment model that leverages data across our network including signals from Verify Fraud Guard as well as other signals associated with risky carriers, anomalous SMS traffic patterns, and low conversion rates.
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: Public Beta. To request access, submit this form.
To make a SMS Pumping Risk request, add sms_pumping_risk to the optional query parameter Fields when making a standard Lookup request.
The following additional properties are returned for a SMS Pumping Risk 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. |
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:
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.
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).
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.
If you're having an issue running a POC or testing the product effectively, please feel free to reach out to us - we can run backtests on your behalf.
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.
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:
Yes!
Recommended: Given that SMS Pumping has become such a large problem, we'd recommend using the Pumping Risk Score in every country outside the US and Canada, including the small Caribbean islands that use a +1 country code.
Not Recommended: There currently isn't much of a need to check SMS Pumping Risk for US and Canada numbers because the incentives for this type of fraud isn't present in these markets. The algorithm was also not designed for US or Canadian traffic, so aside from the problem not being present in those countries, the algorithm won't work as effectively.