Online Fraud Detection

Architectural Options for Integrating Fraud Detection

"By 2009, at least 50% of online fraud detection engines will be integrated directly into Web application servers (0.7) probability." Gartner

Enterprises can choose among three architectural options for integrating fraud detection into an online application. The most-appropriate technical option largely depends on whether the enterprise wants to intervene in real time in suspect transactions.

Analysis:

Three options for integrating fraud detection with online banking or other applications are as follows:

• A fraud-detection filter sitting inside the application server (for example, Websphere). Rules maintained by the enterprise are applied by the filter to any HTTP request (for example, login or payment) before the transaction hits the application. Transactions can be stopped and/or redirected to a transaction-verification routine in real time through execution of the filter's fraud rules. Several vendors provide plug-ins to application servers, but one solution, sold by FMT, is directly embedded with a preprocessor. Accordingly, users are locked into a single source solution.
  
  
• "Listener" integration - In this mode, the application listens to or "sniffs" input files or HTTP network traffic (for example, log), or reads data using application server plug-ins installed at each server. Data is read in real-time (network "sniffer" approach) or near-real (application server listener approach) and either fed into another fraud-management application or reconstructed into a format on which fraud rules can be applied. In the latter case, suspect transactions are queued for fraud analyst follow up. Customized application programming interfaces (APIs) can be integrated so that transactions are redirected to a challenge/response verification. The 41st Parameter, Digital Resolve, Entrust, Covelight, VeriSign and RSA, the Security Devision of EMC, provide variations of this options.
  
  
• "Inline" integration - in this case, APIs are used to pass transactions through fraud detection before a transaction is processed. Transaction flow is controlled, so a user can be challenged in real time if a suspect transaction is detected. Changes in business rules require changes to the core application. APIs are mainly based on Web services. Digital Resolve, Entrust, Covelight, VeriSign and RSA provide this option.
  

Things to Know:

Implementing fraud detection for online banking or other online applications can be done using one of three methods:

• Fraud-detection filters built into the Web application server
  
  
• Listening and/or monitoring of the online application
  
  
• Programmatic interfaces into the legacy application

The first option is the easiest to implement and gives enterprises full control over transaction flow, but more readily locks an enterprise into its application server vendor. Fraud managers, who prefer not to intervene real time in user transactions will prefer second approach, which is the easiest to pull out and replace. Using APIs for fraud detection (the third option) gives enterprises direct control over transaction flow, but requires significant integration work, and must be constantly updated when the core application changes. APIs also make it harder to switch vendor solutions.

No matter which option is chosen, technical strategy is just one piece of the puzzle. Business rules and processes are more important determinants of an application's effectiveness.