Copyright held by The John Cooke Fraud Report. Reprint rights are granted with attribution to The John Cooke Fraud Report with a link to this website.
By Robert K. Cofod
At a recent BAI conference on fraud prevention, a senior representative from a megabank related that his bank’s success in fraud loss recovery was currently about 1%. This, and an increasing array of similar details about the state of bank fraud, strongly suggests that business as usual (ie., investigation and recovery) is no longer adequate.
Why? Dwindling government funding makes support from law enforcement less available except in major fraud cases. The judicial system increasingly deals only with losses that are far above our average per-case fraud loss. The abilities of fraud criminals (eg., use of computers and the Internet, gang expansion, etc.) and the vulnerability of banks (eg., competition-driven risk taking, electronic banking, etc.) are both increasing. In short, the fraud loss management problem has changed significantly both in the magnitude of losses and in the complexity of producing cost effective solutions.
Many banks, believing that recovery is no longer cost-effective, have already made significant cuts in their investigative staffs. While such cuts can produce a near-term offset to current fraud losses, the losses continue to grow and the long-term problem remains.
Real time transaction pattern analysis for fraud prevention has been an essential element of the credit card business for several years. On the debit side, we are only now learning that prevention is a necessity in reducing fraud losses.
But implementing a prevention program is an evolutionary process, and the industry is beginning to learn that looking at fraud before the event rather than after the event involves new considerations. Not the least of these concerns is the growing need to recognize that those systems that are integral to prevention analysis must eventually become elements in an integrated process rather than separate, stand-alone, unique components. Fraud prevention involves a variety of measures, including training, deterrents such as safety paper and inkless fingerprinting, and active customer and account behavior monitoring. This article focuses on the use of automated tools for the analysis, prediction and prevention of fraud. So, let’s take a closer look at this problem, why it exists, what happens if we don’t consider integration, and how we might proceed from here toward the future.
What does “integration” mean?When we use the term integration in the context of fraud prevention, we should consider three principal areas where the concept applies. First, whenever we deal with the use of multiple automated tools to perform a related set of functions, the need for systems integration should be considered. The issues normally involved with systems integration include combining data extracts (ie., data files input to the prevention process), determining the potential for standard interfaces, eliminating duplicate tasks, standardizing reports and output displays, and using common maintenance and training approaches.
The second form of integration we need to consider is operational integration – the degree of cooperation and interaction that occurs between any separate but related functions within the organization. We often see fraud prevention tools bought, operated, and maintained by several different elements of a bank (eg., deposit operations, retail, security, etc.). Often, the lessons learned and the common techniques developed aren’t shared, and the bank is deprived of valuable common knowledge about its fraud threat. The issues involved with organizational integration include centralization vs. decentralization; standardization of policies, functions and tasks; assignment of responsibilities (eg., reporting fraud indications vs. making decisions and taking action); and determination of authority (ie., who’s in charge?). The issues related to operational integration are similar to those that are typically addressed in any corporate re-engineering project.
Finally, information integration needs to be considered. Here we need to look at how the information from the separate and integrated operation of the fraud prevention function is used to perform analysis, make decisions, and support the planning and operation of other bank functions. These uses might include definition of key fraud data elements for the bank system, use of standard methods for measuring savings vs. losses, estimation of fraud losses and protective measures for new products, and identification of fraud risk to varied marketing methods and projects.
Why is integration a problem? There are at least a dozen major types of fraud conducted against banks, and within each type there are numerous variations. Each type of fraud has the potential for creating losses for a different part of the bank. Typically, the investigation staff is the only segment that sees all variants of fraud; but traditionally, the orientation of the investigators has been after-the-fact recovery and compliance rather than prevention analysis. As fraud losses have risen in different parts of the bank, managers have begun to seek their own local solutions to the problem. So we see fraud prevention systems cropping up in different parts of the bank, each separately purchased, operated and maintained. Some banks attempt to overcome this problem by forming a Fraud Prevention Task Force to provide a common viewpoint for procurement evaluation; but rarely is this group involved in the subsequent operation of the purchased systems.
Since successful fraud prevention hinges on the authority to evaluate, decide and act in time to prevent a loss, the need to have the information available to the operational entity responsible for the potential loss is critical. A few banks are now creating a single organization with specific responsibility for fraud prevention. The number of such organizations is still small and the ways in which they will operate is still evolving. Occasionally, a particular personality in a bank may gain enough authority to serve as the focal point for fraud prevention, but this is the exception. The bottom line is that there is usually no single focus for the prevention function, and therefore, there is little appreciation of the potentials of integration to the entire bank.
Most vendors of fraud prevention systems typically focus on only one or two of the varied fraud types. This is because it is difficult to capture the extent of knowledge required to build even one prevention system, and each product requires substantial investment. So the present array of suppliers, in general, also add to the problem by having a limited view of the overall problem.
Finally, we are experiencing a natural evolution of applying technology to the solution of a problem. The normal course of events is to build the separate pieces first, implement them, learn about their operation, and then begin the integration process.
What will happen if we don’t plan for integration? Can you hear the train a-comin’ yet? Unless we think ahead about the problem of how to integrate the array of fraud prevention systems, we will eventually collapse under the costs associated with supporting all of the different tools that are needed.
Specifically, why should we care about integration? For two very good reasons. First, we’ve already suggested that the cost of not integrating the process will be high and potentially unacceptable. Typically, we should expect that, at some point, the ability to invest in improvements to the fraud prevention process will be canceled out by the cost of maintaining what has already been implemented. Since fraud will continually change and evolve with the banking industry, we cannot be put into a situation where our own prevention capabilities cannot evolve.
The second reason for concern is possibly more important. While fraud processes are different and require different analysis, the overall fraud threat to a bank and its products, or to the banking industry in general, is not separate and uncoordinated. Fraud criminals are not singularly dedicated to one type of fraud. They easily slide from credit cards to counterfeit checks to transit fraud and back again, depending upon the opportunities. And these opportunities occur across such varied dimensions as time, geography, products, organization, and personnel training. Without a common view of the way the fraud threat attacks banking processes, we cannot fully understand how it operates and how to predict its impact on the bank’s operations. The need for separate systems to analyze the different fraud processes works against us in our need to develop a common view of the overall fraud threat. Thus, we need to integrate the information output developed by the separate systems.
If we don’t include the idea of integrating our fraud prevention processes, we stand the risk of spending so much on support and maintenance that we won’t be able to evolve efficiently. And we will not be able to bring valuable information about the different types of fraud together to gain a common viewpoint of the overall fraud threat.
What should we do about the integration problem now? OK, now we can hear the train, but what are we supposed to do? One of the first steps we must take is to understand that the implementation of fraud prevention will require a variety of new concepts, processes, skills, and organizations within the bank – it’s not just the purchase or development of one or more fraud prevention applications. Each bank will be different, but having an integrated concept for how a fraud prevention capability should evolve will be essential.
While we are all hoping for a single fraud prevention solution, none exists today. Consequently, we need to communicate effectively, sharing experiences about what does and does not work – no one has all the answers, and just maybe no one ever will. While there are definitely limits to the details that we can share in the competitive environment of banking, there is certainly potential for a common body of knowledge that deters only fraud criminals.
Growth in this knowledge is a critical part of the process of defining, implementing, and integrating fraud prevention, regardless of whether you’re part of bank operations, fraud analysis, or systems development. Training programs that deal specifically with prevention, analysis, systems and integration need to be developed.
We need to improve our understanding of fraud analysis and how automated tools can really help. This means increasing our understanding of technology and its potentials, as well as our understanding of what makes sense analytically. For instance, when do we need to look at all of a certain type of activity on all accounts and when can we focus in and look only at selected subsets of data? What are the trade-offs? When can we effectively operate an analysis process on a PC, and when does it really require mainframe capacity? What are the strengths and weaknesses of pertinent technologies such as neural nets, expert systems, object-oriented structures, etc.? When does it make sense to operate the process internally on-site and when is it better to outsource? What are the analytical methods appropriate to each type of fraud, and where are there overlaps? What are the data elements involved for each type of fraud, and where are there overlaps? What are the skills required for analysis and prediction, and where should they come from?
We need to consider how prevention fits into the overall bank operations for each of the fraud types and products involved. Recovery operations are normally separate from primary bank operations. Yet prevention involves a far greater degree of integrating timely information into daily operations so that stop loss decisions can be made and acted upon. This factor raises new questions about where in the organization the prevention function should reside.
With an idea of how prevention should be implemented in the bank, we should look carefully at new systems to ensure that they possess the potential to be integrated. Vendors need to learn that they must be able to operate their products in an integrated environment.
Eventually, we need to develop standards for data input, common reports and displays, and database content. This will take time and a greater understanding of requirements than we have today, but the payoff will be enormous. Imagine being able to view all of today’s fraud threat indications for your bank on a single integrated display according to priority and regardless of fraud type.
What about the train? Fraud prevention has a tremendous payoff potential for the banking industry, but we have to think ahead and consider a variety of complex factors. We need to get started now to learn how to answer the kinds of questions introduced above. Right now we are sitting on the tracks, and if we don’t work hard at issues such as integration, we’ll have a mess to deal with. By recognizing the problems and beginning to work now, we can ride in the train – someday!
Bob Cofod, president of FRAUDDetect and its subsidiaries BANKDetect and MEDetect, spent 25 years developing and operating military and national intelligence systems. He can be reached at (703) 359-0996.
© Copyright 1997 Alikim Media