Finding the right ATO vendor depends on a number of factors. First off, some ATO solutions can get it wrong, leaning too hard into blocking suspicious activity to the point where legitimate users are being affected. Some also introduce latency, adding unnecessary delays in a way that disrupts your operations and, again, makes the customer experience far more frustrating.
You also want to know how much manual work it will create, how sophisticated the protection is, and how quickly you will benefit. That’s five factors that CISOs, fraud ops, and engineering leaders should be aware of when evaluating bot management and ATO vendor solutions, and therefore five metrics that must be considered. Before we get into the details of the best solution, then, let’s look more closely at those five metrics to understand why they’re so important.
The first metric to look at is FPR – false-positive rate – which can occur when a security solution consistently identifies legitimate activity as malicious. For an ATO protection solution, that distinction is particularly critical, as the system needs to be capable of stopping attackers without turning ordinary customers into suspects every time they behave slightly differently from usual.
That’s something you’ve got to ask, then: will the vendor stand behind their figure with an SLA? Sure, a vendor might advertise an impressively low FPR, but if there’s no contractual commitment attached to it, there’s little stopping that performance from varying once the solution is deployed in your environment. At the moment, the industry standard is around 0.1%, but the industry-leading performance – demonstrated by companies like Datadome – sits below 0.001%, and at that level, false positives are going to represent a tiny proportion of legitimate activity.
Next, it’s important to look at how quickly the solution can assess and respond to incoming requests. Even a highly accurate ATO solution can introduce noticeable delays, so the key question here is where that decision is being made.
Solutions deployed at the edge can assess traffic before it reaches the application, allowing a risk decision to be made with minimal additional latency, but by contrast, solutions that rely on an API hop might need to send information to a separate service, wait for a response, and then determine whether the request should be allowed or blocked. Those additional round trips can easily add latency at exactly the points where speed matters most, such as login and checkout, so when evaluating vendors, make sure to look beyond the headline latency figure and really get the details on how the solution is deployed.
After you know what the solution looks like in regard to false positives and latency, it then becomes important to understand how much ongoing work it’s going to create for your team. Detecting an ATO attack is one thing, but being able to respond to it without requiring your security or fraud teams to constantly monitor traffic is another. Indeed, some solutions rely heavily on manually configured rules, meaning that when attackers change their behavior – or find new ways to bypass existing protections – your team might need to identify the new pattern, create a rule to address it, test that rule, and then deploy it.
And that can all add up considering attacks are evolving faster than ever, with the future of cybersecurity bound to become even more complex and unpredictable. An effective ATO solution should therefore do more than simply flag suspicious activity, it should be capable of automatically adapting its response and mitigating threats, reducing the need for manual intervention and ensuring you don’t have to constantly tune the system just to keep up.
You also want to know how sophisticated the solution really is. In the same way that a good ATO solution should prevent false positives, it should also recognize attackers across a range of attack surfaces, including web, mobile apps, and APIs. Not only this, the detection should be intent-aware, meaning it looks at the context and behavior surrounding a request rather than focusing solely on individual signals.
This is important because attackers can deliberately mimic legitimate users, rotating devices and IP addresses to blend into legitimate traffic, and changing their behavior to avoid detection. Effective IP tracking can help identify patterns across those addresses, but on its own, it doesn’t provide enough context to determine intent. An intent-aware detection that considers multiple signals can, building a clear, complete picture of the activity and make a far more informed risk decision.
Last but not least, your RFP checklist should end with how quickly you can start benefiting. A vendor might offer highly sophisticated protection, for instance, but if it takes months to deploy – or requires significant engineering resources – it’s not really a great option in terms of the value of your investment.
With this in mind, you should look beyond the headline implementation timeline and ask how quickly it can be deployed, and when you can realistically expect to see meaningful protection. If the control and visibility you get when it’s live is strong, ultimately, that’s going to make it a far better investment than something that takes months to get up and running.
As we mentioned before, Datadome follows the best practices to mitigate account takeover risks, and therefore is one of the best solutions for ticking all these metrics, but the decision you make should ultimately be down to your own research. Look around, think about what you need, and compare.
The point of an RFP is to make vendors prove they can deliver on those requirements, so by asking the right questions and comparing answers, you can make sure you make a far more informed decision than if you were simply going to trust the first vendor you come across.