There are only a few complex event processing (CEP) fraud engines that support all of the varieties of uncertainty that reside in financial environments. Here, RTInsights contributor Ivo Correia discusses the need to support uncertainty—which may constitute a significant line of research and development for CEP engines.
As data scientists, we like to think that all of our data is certain—it is data and what can be more certain than data, right? Fraud analysts may be reading that line and shaking their heads as they know very well that it’s not always the case. And it’s not because the data hasn’t been cleansed yet. In many real-time, event-driven applications such as credit card fraud detection apps, uncertainty is inherent. This is why most fraud prevention systems in the financial world consist of CEP systems.
In most CEP environments, there is another underlying assumption: that the event rules or patterns are always deterministic. But, in many apps in the financial industry, those assumptions don’t hold and those patterns are often uncertain. For example, think about how you use your credit card; an event such as purchasing an item outside of your country could be a flag for fraudulent transactions if you don’t often travel abroad. Using your credit card to obtain cash in a pinch is also likely a one-time event. It’s these kinds of events that can flag issues to analysts as they illustrate uncertainty in typical patterns.
Events such as those just mentioned can indicate credit card fraud but they can also indicate a one-time behavior. Fraud risk management—including the real-time detection of patterns across multiple locations or cards—has been recognized as one of the main reasons banks are in favor of embedding real-time intelligence (i.e., machine learning) into their operations.
Fraud detection in banking and credit card processing depends upon correlating events across channels and accounts; this must be conducted in real-time to prevent losses before they occur. Credit card fraud can be divided into two main types: offline or card present (CP), which is committed by using a stolen card in a physical location, and online or card not present (CNP) fraud, which is committed in an online, phone or mobile transaction.
Other important aspects of bank and credit card processing are the fraud detection time/time to alarm, how many types of fraud are detected, and whether the fraud was detected in real-time or in batch. In real-time processing, transactions are analyzed as they come, so the process of tagging fraud happens before the transaction is accepted or denied. With fraud detection systems today, the “suspicious” transaction is marked and manually reviewed by humans, which takes time and stalls the completion of the transaction. Often, the fraud prevention systems offer reasoning that helps to make that “fraudulent or not” call. If the transaction is marked as accepted, nothing can be done afterward if the transaction does, in fact, turn out to be fraudulent.
These considerations lead to a demanding environment in which speed and accuracy in the decision making process are of the utmost importance. Context is one of the most important aspects in fraud detection as different patterns arise in different contexts. For example, in a CP scenario, two consecutive transactions with the same card made in different countries would be the first sign of fraud. However, in the CNP case, that situation happens quite often as online purchases from merchants in different countries can be easily made in a few minutes.
To understand the complexities of the CEP required for financial environments, one must start with the transaction flow. This flow starts when the cardholder makes a purchase from a merchant. The merchant’s terminal then sends the transaction to the acquirer (i.e., the bank responsible for holding the merchants’ accounts), which relays the request to the issuer (i.e., the bank that issued the credit card) through the processor (i.e., the entity that serves as the bridge between the acquirer and the issuer). Once the issuer accepts the transaction, it goes through the reverse path. Note that fraud can happen at any of the stakeholder levels but it’s most common at the cardholder or merchant level.
The overarching aim of the CEP in the case just mentioned is to detect potential fraudulent transactions in real-time so corrective actions can be taken. The two types of cases, CP and CNP, basically have the same pattern logic. For those common patterns, the difference in processing resides in the length of temporal windows (which, for example, can be either two or five minutes for CP and shorter for the CNP case). But fraud prevention experts should consider other thresholds in conjunction with timing.
Currently, there are only a few CEP fraud engines that support all of the varieties of uncertainty (and I have only touched on a few examples here) that reside in financial environments. The need to support uncertainty is gradually being acknowledged and it may constitute a significant line of research and development for CEP engines. The inclusion of uncertainty aspects, mainly manifested in the runtime modules, impacts all of the levels of architecture and logic of a CEP engine. The extensions that must be made in CEP engines include the addition of new, built-in attributes and functions, the support of new types of operands, and the support of CEP patterns to cope with all of these.
In most cases, defining parameters (such as event patterns, thresholds and sizes of time windows) is complicated, and that complication is evident in the financial industry. Often, users have to try several configurations until they find a setting that works well. Once found, the parameters should be regularly revised as fraudsters often change their modus operandi, so the system must be updated with new definitions whenever conditions change.
So many articles, so little time. Luckily, our content is edited for easy web reading! Read more:
Research from Gartner: Real-Time Analytics with the Internet of Things
From the Center to the Edge: The IoT Decentralizes Computing
Becoming an ‘Always On’ Smart Business
Urgency of Present and Past in IoT Analytics
Liked this article? Share it with your colleagues using the links below!
