What is our primary use case?
I was initially responsible for deploying this solution, and after that, I have done development for three major clients. I initially started using ThreatMetrix in an anti-fraud mobile application for detecting fraud. It was a mobile wallet, and I was responsible for the API in the mobile team, which was responsible for deploying it out in the field. The way ThreatMetrix works is that it has a corresponding mobile SDK and web service in the backend. My team was responsible for deploying it to effectively integrate it into the platform for the client.
We started using this solution because the company was given a ransom or DDoS threat. A malicious group targeted the company and said that because they are a huge mobile wallet company, being used a lot for international money transfers, if the company doesn't give a payment, they are going to DDoS the company's service. Effectively, we decided to use ThreatMetrix to understand what our clients were using and which device they were using so that we can block and whitelist IPs which were coming in, and basically, giving us DDoS. That was the first time I was introduced to ThreatMetrix.
Since then, I have deployed it in a few places. We have deployed it in a bank as well as in one of the new digital-only or mobile-only banks. It was again deployed for detection to whitelist IPs and manage the devices that were trying to steal your account. In the most recent use case, which was about three years ago, I created an open-source library that effectively allows you to easily integrate ThreatMetrix. I haven't actually maintained this library, but I am in the midst of talking to ThreatMetrix to see if I can revive that project.
We initially deployed ThreatMetrix on-premises, but this was before the cloud became available. My last solution was on AWS, but ThreatMetrix is a SAS service. You don't deploy ThreatMetrix, you effectively call the API. They have their own SAS network, so you can call out to ThreatMetrix. They don't really care where you deploy your solution. They don't install anything on your network basically because you're going out and pushing information back to ThreatMetrix, and they are giving the response back to you. All you use is an SDK. You configure the SDK, and the configuration file lives on their server. You make a call out to their server. It gives you back the configuration details, and then from there, you configure the system and talk back to them effectively.
What is most valuable?
The most valuable thing is about the IP. They have a database of malicious IP addresses against which they check. They have a huge database for routed devices and the devices that have been used in the past to commit fraud. They have extensive historical records of all of that information, and that's probably the most valuable thing about ThreatMetrix. Over the years, they have been collecting and persisting globally across all the banking and financial services. They have been storing all this information.
It is this stored information that I and my team find valuable; it is not so much their technology. If you are running it on a simulator and trying to maliciously clone and copy IP addresses and stuff like that, they have a bunch of technologies, like routes section and all the other stuff. It is just that they have something that no one else can deal with, that is, massive amounts of big data about the malicious IP addresses, malicious device fingerprinting, the fingerprinting router devices, and the fingerprints.
You can query against this stored information to find out whether your app is in a good, nice environment. If yes, you get a green light. The last time I checked, there were about 400 or 500 features that they can stack against, which is pretty extensive. They give you a score against all those features for every application that you installed on it. It is pretty good in that sense.
What needs improvement?
SDK is probably where the biggest issue is. The SDK configuration is a bit lacking. If you are integrating it into your workflow, it is very cumbersome and very difficult to integrate. You have to understand and be an expert in low-level mobile applications to integrate this stuff. Integration should be easy based on what they are providing, but unfortunately, it is not. It is very difficult.
My work has been trying to simplify the integration process because integrations bring a lot of value. Most companies don't see their value because it is such a difficult process. For integration, you have to get it right as well, but it is very difficult to get it right because they don't help you in tuning your future parameters. Because of this, it is very difficult to tune your future parameters and your risk score. If you are Uber, your risk score will be very different from a banking client that is pushing funds. These two things need to be improved for me. The rest is pretty good.
For how long have I used the solution?
I have been using this solution since 2010 or 2011.
What do I think about the stability of the solution?
It is pretty stable. The biggest issue is false positives. For poorly configured applications, ThreatMetrix may end up kicking customers out of your platform because it would flag them as fraudulent when they are not.
When a user is about to log in to an application, such as a banking application, if you base your login credentials based on the information from ThreatMetrix, it would basically log the user out of the application. So, people who are legitimate users of your service will get kicked out of the service because ThreatMetrix will think that they are up to no good. For me, that's the biggest complaint and issues you get from customers on the field because basically, they can't log into your service.
ThreatMetrix itself has gone down. ThreatMetrix is based on five-year-old data. It is the biggest information data. If you have a high-volume application, ThreatMetrix may end up going down, which will impact service delivery to your client and customers. Apart from that, it is pretty stable. There are false positives, which, if you design the application properly, shouldn't really be kicking people out of the application.
What do I think about the scalability of the solution?
It is scalable, but I haven't tested it to the point. It is a SAS solution, and it is global. What we have used in the past is very scalable. We had 3,000 or 4,000 requests per second, and it easily handled them. It sometimes might end up going down. They might have improved since then, but it is actually pretty scalable.
How are customer service and technical support?
Technical support is probably the most lacking thing in my opinion. They are very responsive, but it would be great to have highly technical people on their support team, rather than just sales engineers. It would be good to speak to actual engineers who are configuring the product.
I understand that it is going to be difficult because they are global and have clients across the world, but most of the time, every client has very specific needs. Understanding the client domain is important. The sales engineers or the engineers that are sent out to the floor may not necessarily have that expertise in the client domain, which is a problem because the client is an expert in its own domain and ThreatMetrix is an expert in its own domain. It is marrying these two and making sure that you are solving a client's problem effectively. If you hire a technical engineer, you will be able to have someone with domain knowledge.
As far as we are concerned, ThreatMetrix is fine, but most of the time, it is an integration issue. That's really what it comes down to, but they are highly responsive. They do send engineers out to the client's site.
How was the initial setup?
It is very complex, which is a problem. There are a few issues. Because of what it does, it needs low-level access to where it is used as an SDK. The problem with that is that most mobile developers don't have that knowledge. Therefore, if you are an advanced developer or an expert developer, then it is fine, but if you are just a junior and mid-level developer, you would find it difficult. That is because they make reference to things that as a developer, you don't really use much on a day to day basis. That's why it is a problem. There are ways to make it easier. There are various ways to make integrations very easy, but last time I did it, it wasn't the best, but it could be improved. It is usable, but there is definitely room for improvement.
Because it is a SAS solution, you just integrate it into your build flow and your product. It shouldn't take you more than a week or two. It should take a week or two for integration to work. The difficult part is tuning the deployment, which takes time because you need data to include in your workflow. The actual deployment and implementation would probably take about a week or two and probably less if you know what you are doing.
The implementation strategy depends on the client. It has an extensive knowledge base, which unfortunately is hidden behind and is not easily available. You have to be using their product to be able to see the knowledge base. This is a huge and massive knowledge base, which in itself is a problem because people just get lost. I found myself getting lost a few times trying to use the knowledge base.
Most of the time, they give you an engineer, but it is normally a sales engineer, which is not the best. You prefer to have a real engineer who will help you, but you normally get a sales engineer to assist you. It would be better to get a real engineer who comes out and assists you with the integration. I have spoken to ThreatMetrix engineers, but I have never actually had them come out on the client-side to assist me. The appointed sales engineer helps you with the integration, especially into your backend because you need to explore all the feature sets.
The actual deployment should not take more than a week or two, but you see it stretching out to a month because of the issues and the lack of knowledge and expertise within the development team to do this integration. If your application is not flexible enough to store these feature parameters, you will run into issues. Badly assisted applications have difficulty integrating with ThreatMetrix, mainly because these feature sets are set in stone. ThreatMetrix has got this massive feature set, but most platforms are not designed to ingest this much information, tune it, and then just make a decision based on these parameters. This is effectively where the issue lies.
Integration is where most people have issues. That's why it takes such a long time because you have to develop your application according to the API from ThreatMetrix. It is not the other way around, which makes things a little bit difficult. If you are just starting, it is excellent, but if you have an application that has been used for a long time, it makes the integration a little bit tricky. This is mainly because you need to go back and re-engineer and re-integrate it.
What's my experience with pricing, setup cost, and licensing?
I am not aware of the price. I have always come in after it has been negotiated.
The clients do get a return on their investment. It mitigated a massive DDoS, and it definitely detects fraudulent activities on banking platforms. They have definitely got their ROI back because there is continued investment in ThreatMetrix over time.
Which other solutions did I evaluate?
I have assessed some solutions that deal with detection. They are not exactly in the same area as ThreatMetrix. They were not as extensive as ThreatMetrix, especially with threat detection. ThreatMetrix has a massive database of blacklist IPs, which I think is more valuable than those we assessed.
What other advice do I have?
I would say to definitely consider it at a design stage, or at least to have an extensive sandbox where you can set it out. The major thing is integration into your current system and also false positives from poorly configured systems. If you actually do have a system that is already running, then definitely look at the integration and look at the knowledge base to understand exactly what it takes and how do they integrate.
It is not just integrating the SDK or the API in the product; it is understanding the massive parameters that you can tune. ThreatMetrix helps you with that aspect, but it is really up to you to tune them for your application on your platform. If they are not tuned properly, you would definitely get into trouble because you have started flagging up false positives, which you don't want to do.
I would rate ThreatMetrix an eight out of ten. It needs a few improvements, but it is definitely good.