White paper Real Time Transaction Analysis and fraudulent transaction detection for onlinebanking

Real Time

Transaction Analysis

and Fraudulent

Transaction

Detection for Online

Banking

Alan McSweeney

Real Time Transaction Analysis and Fraudulent Transaction Detection for Online Banking

Contents Online Bank Fraud ..........................................................................................2 Online Bank Fraud ..........................................................................................3 Real Time Fraud Detection Solution Architecture............................................4 Internet Banking Logical Transaction Layers...............................................4 Real-Time Fraud Detection Solution Framework .........................................5 Real-Time Fraud Detection Solution Architecture........................................6 Rules Engine and Decision Making Facility..................................................8

Complex Event Processing/Event Driven Application Architecture and Approaches to Fraud Analysis..........................................................................9 Implementing a Real-Time Fraud Detection System ...................................... 10

The behaviour characteristics of online banking fraud are:

• Continuous behaviour changes by criminals

• Very high growth rates

• Sophisticated advanced and changing fraud techniques To effectively detect and stop fraud before it happens, banks will require insight into user activity in real-time. This will be provided by a real-time online banking fraud detection and analysis solution. There are many small software vendors operating in this area and the market is still quite fragmented. There will be consolidation as vendors merge and are taken over or go out of business. There is an emerging technology in the form of Complex Event Processing (CEP) that is suitable for real-time online banking fraud detection. As part of the implementation of any real-time online fraud solution, banks will need to implement new business processes to support any solution. This will be a key element of any overall solution. A complete solution will consist of the following components:

• Continuing customer education

• Possible additional two-factor authentication for customers using some form of key generation tool

• Profiling customer access and maintaining an up-to-date list of fraud sources to determine if a known source of fraudulent activity

• Implementation of real-time fraud detection and handling system or systems

• Checking transactions in real time

• Handling of suspicious transactions

• Processes to link all these elements together


Online Bank Fraud This whitepaper provides an introduction to the end-to-end landscape of online banking fraud and its detection and handling. Online banking fraud can arise in a number of ways: 1. By some form of identity theft where the banking authentication details of

legitimate users are stolen and used for criminal and fraudulent purposes such as phishing and crimeware attacks

2. By some form of security breach that allows criminals access to bank banking systems

3. By fraudulent activity by bank employees 4. By persons closely associated with legitimate users gaining access to their

authentication details and performing fraud The common thread in all this is people who are the weakest link in any security system. Of these sources of fraud, phishing in all its forms will be the one that gives rise to most concern. It will be the mechanism by which criminals get access to account information in order to defraud customers. Phishing typically employs both a social engineering and a technical approach (Crimeware) to steal consumers’ personal identity data and financial account access details. Crimeware is software that performs illegal actions not requested by a user running the software that are typically intended to yield financial benefits to the distributor of the software. Social-engineering schemes use spoofed e-mails purporting to be from legitimate sources to lead consumers to counterfeit websites designed to trick recipients into divulging financial account authentication data. Essentially, crimeware is divided into two broad categories: 1. Social Engineering – this involves an e-mail with an address or an

attachment that directs the user to the fraudulent site or inflects the user’s PC with criminal software

2. Security Exploits – these take advantage of flaws in software such as user’s operating system, browser or elements of the internet infrastructure used to gain access to the bank’s online banking site.

Unfortunately crimeware is a fact of life in the online world. Crimeware is distributed in many ways such as:

• Social engineering attacks convincing users to open a malicious email attachment containing crimeware

• Injection of crimeware into legitimate web sites via content injection attacks such as cross-site scripting

The numbers of crimeware-spreading URLs infecting PCs with password-stealing code rose 93 percent in Q1, 2008 to 6,500 sites, nearly double the previous high of November, 2007 - and an increase of 337% percent from the number detected end of Q1, 2007.

Source: AntiPhishing Working Group http://www.antiphishing.org Q1 2008 Phishing Activity Trends Summary


• Exploiting security vulnerabilities through worms and other attacks on security flaws in operating systems, browsers, and other commonly installed software

• Insertion of crimeware into downloadable software that otherwise performs a desirable function.

Any approach to preventing fraud needs to take account of these mechanisms and to ensure that the bank does not perform any actions that could be mistaken and misused in these contexts, such as:

• Sending mails to customers that could then be confused with phishing mails

• Providing users with separate downloadable software to perform functions such as security checking and PC fingerprint generation

Real Time Fraud Detection Solution Architecture

Internet Banking Logical Transaction Layers In terms of examining the options for real-time fraudulent transaction analysis and determining the architectures and solutions available, there are four relevant logical layers:

These layers are:

Number of Attacks:

Source: AntiPhishing Working Group http://www.antiphishing.org Q1 2008 Phishing Activity Trends Summary

Frequency and Cost of Attack by Type of Attack

Source: US National Consumer League, 2007


1. User Physical Access and Location – this layer consists of the device being used by the user to perform the access, its characteristics, its physical location and other user details such as mobile telephone, mail address.

2. Internet Communication – this refers to the physical internet layer. 3. User Authentication Layer – this layer consists of the authentication

information users must supply and other authentication mechanisms such as physical tokens that users might use during the authentication process.

4. Front-End Internet Banking Application – this is the suite of applications that form the Internet accessible layer of the banking systems.

5. Back-End Banking Systems and Data Warehouse and User History – this consists of the back-end banking systems and the data warehouse storing user access history.

Real-Time Fraud Detection Solution Framework Implementing an effective mechanism for preventing Internet fraud will involve a multi-layer approach with multi-factor authentication and verification. It is important to understand that incidents will occur. Any system involving people will at some stage be compromised. Also, it may not be possible or worthwhile to implement a solution that is 100% secure. This may involve substantial incremental cost over a solution that is close to 100% secure that may not be justified. An integral part of any fraud detection solution is an incident handling system and associated processes. At a minimum, these should:

• Contain the damage

• Preserve/duplicate of the compromised system's state for further analysis

• Contact the Police and the Bank’s legal department if required

• Restore operations of compromised system, if relevant

• Analyse problem and determine incident cause

• Document incident and recovery details

• Update control agents/implementation details based on analysis

• Update incident response plan, if required The illusion of 100% security can be dangerous as it can lead to complacent behaviour and a substitute for sound practices. It can also cause IT users to behave more recklessly. Note that security compliance endorses an overall environment including technology and processes and not just a specific technology. The elements of an overall solution can include some of all of:


Real-Time Fraud Detection Solution Architecture A real-time fraudulent transaction analysis and detection system will operate in parallel to the normal transaction pipeline. The transaction pipeline will consist of the following steps: 1. User will initiate the transaction using a device such as, but not limited to,

work or home PC 2. The user will use an internet connection to access the bank’s internet

banking system 3. The user will authenticate with the bank’s internet banking system 4. The user will performing banking transactions 5. The data warehouse will be updated with information collected during the

transaction


In parallel, the real-time fraudulent transaction analysis and detection system will operate. It should not insert itself into the transaction pipeline as this will delay transaction processing as well as involve higher implementation costs due to the integration effort. Details of transactions should be taken in real-time at two key points: 1. User access to gather details on how the user is accessing the system 2. Transaction to gather details on what transactions the user is performing This real-time information is then compared with user access history and transaction history details to determine if the transaction is likely to be fraudulent. At a high-level, the real-time fraudulent transaction analysis and detection system will consist of a core Collect-Analyse-Decide-Respond cycle. These stages will perform the following tasks:

• Collect – information on the transaction will be collected. This will consist of access information, session information and transaction details. The collection component will gather information from multiple sources at multiple stages both through the transaction life cycle and off-line from other sources such as watchlists of addresses involved in fraud.

• Analyse – the transaction information collected will be analysed both within itself and also be compared with historical information collected. Based on the two sets of data, the transaction will be scored with respect to its probability that it is fraudulent.

• Decide – there will be a decision engine that determines if the transaction is fraudulent.


• Respond – based on the decision taken a response action will be determined. This process needs to happen in real-time as transactions are happening. It needs to be scalable to handle large-volumes of transactions without delaying overall transaction processing. The real-time fraudulent transaction analysis and detection system will also provide additional functions:

• Reporting and Monitoring – the system should provide reporting and monitoring facilities to report on fraud analysis activities, system throughput, performance and other areas

• Offline Analysis – this will provide other non-real-time analysis facilities that allow patterns across multiple transactions to be identified

• Administration – the system can be administered and managed allow actions such as new rules to be defined and the operation system to be tuned and modified.

Rules Engine and Decision Making Facility This is a flexible rules-engine that takes data from multiple sources to identify transactions as potentially fraudulent:

The classification will be based on multiple factors, such as: Current Transaction Details Transaction Amount Transaction Type Transaction History Details Transaction Frequency Transaction Type Frequency

Users Profiles Users Ages Users Locations Users Jobs Session Details IP Address


Account Activity User Profile User Age User Location User Job

Browser Type Session History Details IP Addresses Browser Types Previously Known Sources of Fraud IP Addresses Associated With Fraud

This information will be combined to assess the probability of the transaction being fraudulent:

• Current Transaction Details – this will provide a profile of the transaction being performed

• Transaction History Details – this will allow the current transaction to be compared against previous transactions

• User Profile – this will provide a profile of the user performing the transaction

• Users Profiles – this will provide a profile of all users against which the current user’s profile and the profile of the current transaction against the profile of transactions performed by similar users can be compared

• Session Details – this will provide details on the internet access session

• Session History Details – this will allow the current session details to be compared against previous sessions to allow changes to be identified

• Previously Known Sources of Fraud – this will allow the current session details to be compared known access details associated with fraud

Complex Event Processing/Event Driven Application Architecture and Approaches to Fraud Analysis There is an emerging technology in the form of Complex Event Processing (CEP) that is suitable for real-time online banking fraud detection. The topic of CEP is itself very complex. This section provides some very brief information to support its inclusion as an option for implementing a real-time fraud analysis solution. The high-level architecture of a Complex Event Processing (CEP)/Event Driven Application (EDA) architecture is:


The core logical elements of this approach are:

• Continuous Query Engine - Processes high volumes of streaming data

• SQL-based Event Processing Language (EPL) – extends SQL to handle streaming events

EPL is SQL-based. It provides easier integration to relational data and the data storage facility. The key extension within EPL is the ability to handle streaming data provided by WHEN ... THEN statements rather than conventional IF ... THEN statements.

A CEP application typically comprises of four main component types: 1. Adapters interface directly to the inbound event sources. Adapters

understand the inbound protocol, and are responsible for converting the event data into a normalised data that can be queried by a processor (i.e. event processing agent, or processor). Adapters forward the normalised event data into Streams.

2. Streams are event processing endpoints. Among other things, streams are responsible for queuing event data until the event processing agent can act upon it.

3. The event processing agent removes the event data from the stream, processes it, and may generate new events to an output stream.

4. The Decide step listens to the output stream, The Decide step forward on the generated events to external event sinks such as a case management system.

Implementing a Real-Time Fraud Detection System Any practical approach to real-time anti-fraud will consist of the following activities:

• Continuing customer education

• Possible additional two-factor authentication for customers using some form of key generation tool

• Profiling customer access and maintaining an up-to-date list of fraud sources to determine if a known source of fraudulent activity

• Implementation of real-time fraud detection and handling system or systems

• Checking transactions in real time

Details on the levels of spending by US banks on consumer authentication and fraud detection in 2006, classified by the value of their deposits.

Source: Gartner


• Handling of suspicious transactions

• Processes to link all these elements together Each of these will go some way to preventing fraud. Taken together they will form a comprehensive solution.

In terms of the previous transaction pipeline, the additional steps required will be: 1. Before completing the transaction, the banking system would invoke a

function to check the status of the transaction within the Decision engine. 2. The checking function will interrogate the Decision engine to get the result

of the transaction check. 3. If the Decision engine has reached a decision about the transaction, this

would be provided to the application status check. 4. If the transaction was determined to be suspicious, it would be written to a

suspend queue where it would be held according to defined rules. 5. If the transaction was determined not to be suspicious, it would be

processed as normal. 6. The incident handling component would be notified.

Planned increase in spending intentions in 2007 from 2006 by these banks.

Source: Gartner


For more information, please contact:

[email protected]

White paper Real Time Transaction Analysis and fraudulent transaction detection for onlinebanking

Technology

Transcript of White paper Real Time Transaction Analysis and fraudulent transaction detection for onlinebanking