What is our primary use case?
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.
How has it helped my organization?
The effect it had on the company was the fact that we were able to much more easily detect if people were using VPN for travels, which country they were accessing the platform from, and we had access to a large amount of new data points that we previously didn't have. That was really useful for us, as well as the fact that it was easily customizable and there were dashboards that showed the threat model and where they were potentially coming from. Especially in instances of fraud, we could actually go back and retroactively look at the data, and see if there was anything that we could potentially use to pick up and feed into future models.
What is most valuable?
I liked the rules engine, the fact that there were custom rules that were accessible, that we then got an update every month in terms of how it was performing. It meant we could keep updating our rules and tweaking them to suit. Sometimes they gave false positives and sometimes we made them a bit too lax. It was quite easy to use and customize as we went through that journey. The other thing was that we had our own proprietary admin console, so we could easily consume the API and bring the data onto our custom application. It was easy to use and implementation was fairly quick.
What needs improvement?
As much as I liked the rule engine, I would say that I didn't find it particularly intuitive. Thankfully, we had good engagement managers who walked us through what the fields meant, as it wasn't immediately obvious. There wasn't a clear mapping or description of these fields so that could be improved. We had to create an internal dictionary for distribution to users of the platform.
While there were lots of data points, which was a positive, it was also somewhat of a negative. When you have 125 fields, it can be an overload of data that makes it difficult to know which are valid and useful. ThreatMetrix relied on us to understand some of that intelligence, but that's not our expertise. More understanding of which fields would be applicable for our use case, and that kind of collaboration, would have been helpful. You learn it over time anyway, but it creates challenges when setting up.
I think the solution has some way to go in terms of its user-friendly nature, and in terms of some of the dashboards and metrics that it provides. In terms of some of the out of the box functionality, it would be good if there were some out of the box rules set up. We worked with the engagement manager to set it up, but having options would have been better.
What do I think about the scalability of the solution?
This is definitely a scalable solution. It took time to get people on board, primarily because of the lack of understanding of the data point.
How was the initial setup?
The initial setup was quite straightforward. There's maintenance involved in terms of updating the rules, doing some end-of-month checks, and that was primarily carried out by me as the business analyst. Credit analysts were also involved, interpreting any instances of fraud, but nothing got back to the ThreatMetrix system.
What's my experience with pricing, setup cost, and licensing?
I think the solution was reasonably priced. I think our licensing was through a partnership with Equifax, which complicated the procurement, to be honest. It's something to be mindful of, and I would suggest going directly with ThreatMetrix, as opposed to these convoluted license agreements through a third party, that make it more difficult to get support.
What other advice do I have?
ThreatMetrix seems like a fairly complete solution. Because of the rise of mobile, we were moving to a mobile based lending product. Given that fact there was a concern that there was a new vector for attack and that's what we wanted to protect ourselves against.
It's important to understand your use case very clearly. I think the challenge we had was the understanding that this was a capability that we needed, but we were not particularly clear as to how extensively we would use it. That's worth figuring out in advance. You can access the admin console and view performance once it's been implemented. That's worth doing as well as making use of the ThreatMetrix dashboard.
One of the things that I learned was just the sheer number of vectors that a potential attacker could use when they access your service, or your platform. That was a whole journey, discovering the many ways attackers can access the system, try to create multiple accounts, and do lots of accessing on servers in hidden locations. The fact that it's actually possible to track that information based on the browser, and based on the user ID, and being able to link that through different devices was interesting.
I think device intelligence is still relatively new, and not everyone in the risk team fully understood it. We had a few people who didn't think that it provided much value from the outset, and getting them on board was more challenging. It slowly improved over time, as we became more embedded in part of the credit check, primarily by the credit risk team. It was used more to identify, to ensure that people are who they say they are, and they're contacting from devices that we know to be safe and secure.
I would rate this solution a seven out of 10.