Another ways that we have handled the above problem is by
- We monitored and analyzed network traffic for unusual patterns, such as spikes in SMS requests, which could indicate a coordinated attack. This we then combined with IP reputation databases.
- We have also built APIs that specialize in real-time fraud detection to monitor and analyze each SMS request's risk level. These APIs use libphonenumber and global fraud data to evaluate the risk associated with an incoming request.
- Using machine learning algorithms to analyze user behavior patterns we help detect anomalies that signify fraudulent activities. If a user's current activity deviates significantly from their usual pattern, the system require additional authentication or temporarily block the user.
- We have implemented status based failover systems (delivery, read or open receipts). For instance customer can decide to send the OTP on WhatsApp and then if it is failed to deliver in 10s; send an OTPs on SMS or EMAIL.
Regarding the tech; redis has worked out beautifully for us at scale (using data structures as sorted set to implement a rolling window based ratelimiting, etc.)
At fyno.io, tackling SMS fraud is what we do best. We've successfully integrated advanced monitoring systems, real-time APIs, machine learning, all because this is our bread and butter and as a company you don't have to build this non core service.
All those strategies are a great first layer of protection, we see however of tool fraud attacks in which these protections don’t suffice, it could be part of those fraudsters business model to even by-pass capcha.
Seams like now twilio is now offering some kind of protection but it doesn’t comes free.
We built ding.live for that reason, a different pricing in which we don’t rely on overselling the sms price so we don’t have to look for extra margin when less are sent due to better fraud protection.
ahh yeah - I saw that. Twilio Verify is v expensive, sadly, and I don't think it'd be economical to use it at scale. The perverse incentive is that Twilio get **paid** everytime a web service is attacked via SMS fraud -- something I could have made clearer in my post. If they made fraud prevention cheaper, then they might earn less in the short-term.
Excellent Article!
Another ways that we have handled the above problem is by
- We monitored and analyzed network traffic for unusual patterns, such as spikes in SMS requests, which could indicate a coordinated attack. This we then combined with IP reputation databases.
- We have also built APIs that specialize in real-time fraud detection to monitor and analyze each SMS request's risk level. These APIs use libphonenumber and global fraud data to evaluate the risk associated with an incoming request.
- Using machine learning algorithms to analyze user behavior patterns we help detect anomalies that signify fraudulent activities. If a user's current activity deviates significantly from their usual pattern, the system require additional authentication or temporarily block the user.
- We have implemented status based failover systems (delivery, read or open receipts). For instance customer can decide to send the OTP on WhatsApp and then if it is failed to deliver in 10s; send an OTPs on SMS or EMAIL.
Regarding the tech; redis has worked out beautifully for us at scale (using data structures as sorted set to implement a rolling window based ratelimiting, etc.)
At fyno.io, tackling SMS fraud is what we do best. We've successfully integrated advanced monitoring systems, real-time APIs, machine learning, all because this is our bread and butter and as a company you don't have to build this non core service.
Great article!
All those strategies are a great first layer of protection, we see however of tool fraud attacks in which these protections don’t suffice, it could be part of those fraudsters business model to even by-pass capcha.
Seams like now twilio is now offering some kind of protection but it doesn’t comes free.
We built ding.live for that reason, a different pricing in which we don’t rely on overselling the sms price so we don’t have to look for extra margin when less are sent due to better fraud protection.
Nicely done, enjoyed reading it. As far as I know Twilio does offer some free fraud protection against these attacks but I think it’s only available on Verify APIs. https://www.twilio.com/docs/verify/preventing-toll-fraud/sms-fraud-guard
thanks for the kind words! :D
ahh yeah - I saw that. Twilio Verify is v expensive, sadly, and I don't think it'd be economical to use it at scale. The perverse incentive is that Twilio get **paid** everytime a web service is attacked via SMS fraud -- something I could have made clearer in my post. If they made fraud prevention cheaper, then they might earn less in the short-term.
Hi, the link in this sentence leads to a login page
"The key to understanding SMS fraud is understanding that some numbers are premium."
thanks for pointing out my error -- I've fixed the link!