Featured Blog Post:
The holiday season, once marked by bustling malls, has transformed into an online frenzy of clicks and carts. But while shoppers hunt for deals, fraudsters are hunting for profits...
The job of a fraud analyst is not an easy one. As professionals responsible for identifying, investigating and preventing fraud, it’s crucial that they can quickly analyze data to stop fraud as it’s happening and investigate claims after they’ve been detected or reported.
Often this requires not only the use of fraud detection software — which may require multiple solutions — but risk management and statistical analysis. In the process, they typically work with other departments such as security teams, legal and compliance. However, this kind of collaboration is often complicated when the rules that govern fraud detection and mitigation are too complex or opaque to effectively update or even understand.
To solve this problem, Transmit Security has designed a rules engine for our Detection and Response Services that provides actionable recommendations along with transparency into the reasons behind them. This blog will dive into how our rules engine calculates these risk signals, how we improve visibility into its decisioning logic and how it can help analysts and security teams investigate and mitigate fraud in their applications.
Distinguishing between legitimate and fraudulent behavior first requires gathering data on an application’s users and how they are interacting with the application. Some examples include:
However, a single data point is not enough to accurately assess risk, as even a seemingly simple task like determining a user’s location may require multiple data points. For example, an IP address could be used to estimate a user’s location, but fraudsters can cloak the geolocation of their requests via IP spoofing or proxies. Adding to the challenge, some ISPs use shared or dynamic IP addresses that make it harder to discern where a specific user is located.
For more reliable assessment of a user’s location, this raw data must be enriched with other information, such as GPS data from mobile devices, the strength of nearby Wi-Fi access points or the use of proxies. Because different solutions may use more or fewer data points or combine them in different ways, the accuracy and value of these signals will vary based on the solution.
While more valuable than raw telemetry, enriched telemetry is still not enough to make a ruling on whether a user’s behavior is suspicious — even when compared against a user’s known behavioral patterns. Users may travel to new locations, switch devices and vary their behavior in a variety of ways. Challenging them with step-ups in each of these scenarios would make for a poor user experience.
To avoid adding too much friction, signals must be contextualized and aggregated by tools that often specialize in different methods of detection, requiring one solution for bot detection, another for threat intelligence and another for behavioral biometrics — just to name a few. This makes gaining a complete picture of all the information needed for effective decisioning a difficult task.
To gain a full picture of all the information that could be used to detect fraud and determine how to respond to requests, teams must often decide for themselves how to integrate different solutions and combine their risk assessments. Creating these heuristic rules can be a long and complex task, and rules can quickly become outdated as fraudsters develop new workarounds to evade detection.
And while machine learning (ML) can be used to efficiently build decisioning logic, find more complex patterns in behavioral anomalies and provide more clear-cut analysis of suspicious behavior, ML algorithms are often black boxes that don’t provide insight into the reasoning behind their decisions. This makes it difficult to spot false positives and false negatives until long after fraud has already occurred and impedes investigations into claims of fraud or identity theft.
Whether dealing with rules spaghetti across a variety of siloed tools or opaque ML algorithms, the result is the same: the decisioning logic used to detect and mitigate fraud is often hard to understand and explain, and even harder to update in the face of changing threats.
The decisioning logic for our Detection and Response service can be thought of as a funnel that aggregates telemetry from a variety of sources and distills numerous risk signals and multiple detection methods into recommendations on how to handle each request.
Throughout this process:
All raw data, signals, reasons and recommendations are externalized using our UI or APIs and delivered in real time. The top reasons for each recommendation are determined using methods from a field of machine learning known as model explainability and may include challenging a request due to impossible travel or allowing a request made with a trusted user device.
Within the Detection and Response UI, administrators can access analytics to easily:
With this contextualized information, businesses can more easily understand decisioning logic. They can also quickly tune decisioning using our Labels API to provide feedback on their recommendations or use our Identity Decisioning Services to quickly create, update, test and safely deploy no-code custom rules.
Through sophisticated ML analysis of multiple detection methods and robust telemetry, Detection and Response Services enable businesses to consolidate the numerous fraud detection tools that complicate and obscure decisioning logic. In addition, Transmit Security simplifies the work of fraud analysts by providing better visibility into the reasoning behind its recommendations and the ability to quickly tune and update rules to respond to emerging threats.
To find out more about how Detection and Response can benefit your business, read our case study on how a leading bank was able to save millions of dollars in fraud losses, or contact an expert for a personalized demo.
