We're using the solution to help us identify scenarios where the same device is appearing to purchase multiple policies from us. There are two scenarios of what that entails. Number one is ghost brokering. The second is identity theft. The scenario would be, I steal your identity, and I come to our website, where I purchase a policy in your name. What doesn't make sense is why would two different people, looking at two different addresses, be using the same device? That's the scenario we're concerned about.

We use the solution for a banking domain to maintain device identity and vendor recognition. It prevents fraudulent activities. We also use it to perform device checks and obtain tokens for verified devices for secure transactions.

We have a mobile application for Android and iOS. We just want to know that the application installed on the mobile device is good or not. If some hacker is installing the application or the application is installed on compromised device, we should know this so we can block it.

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.

Our primary use case for ThreatMetrix was for our device intelligence, to help us with our fraud detection and monitoring capabilities. This is primarily for our lending products, so a supplier driven lending product. We were customers of ThreatMetrix. 

The solution is used for fraud assessment of credit card transaction processing in a retail environment. That's the main thrust of it. Basically, it's a fraud assessment tool.