Ibm Banking: Integrated Fraud Strategy

IBM Global Business Services White Paper

Unlocking the value of an integrated fraud strategy

Strategy & Transformation

IBM Global Business Services

By our estimates, top tier banks in the US on average spend $30-50 million more per year than necessary combating fraud across all channels. Compounding the issue, banks continue to lag behind the technical and organizational advancements of the criminal elements driving the growing number and sophistication of fraud attacks. Some industry estimates are as high as $700 million in average losses per year for a single top tier diversified financial institution. These two factors define an interesting dilemma. On the one hand, banks must add new systems and processes to combat the growing number and sophistication of fraud threats. On the other hand banks need to address existing overlaps and unnecessary complexities in the existing function to rein in costs. If your institution is like most, you are currently closely examining fraud operational budgets in relation to overall program effectiveness; and a significant element of your future plan is integrating operations across various channels like Online, Deposit, ATM, Check, Card and ACH/Wire. We first observed the integrated fraud trend four years ago with several of the large regional banks, where the barriers to such integration are more easily overcome. We are now seeing a move towards integrated operations consistently with the largest and most complex bank and non-bank financial institutions. Some have started to execute on their integrated strategy, many are still in the planning and design stages. Various fraud threats have each seen their day as an industry hot button resulting in solutions that were implemented in a stand-alone fashion, as a time critical response to an emerging threat or regulatory imperative. Economic conditions have shifted focus to the balance between cost and effectiveness of these functions. As a result, integrating these very similar systems and processes has leapt to the top of the agenda to address increasing operation costs, as well as the emergence of more sophisticated cross channel and mass compromise fraud threats that often include insider collusion. Working with both the early adopter regional institutions and now the large diversified financial institutions to plan and execute these integration programs, we’ve identified four critical challenges which must be solved to achieve success:

3

1. Building support across stakeholder groups 2. Developing a holistic data strategy 3. Understanding requirements 4. Value centric implementation

Building support across stakeholder groups The primary function of loss prevention is to stop money from walking out the door. The other side of that coin is the operational costs associated with the systems and processes necessary to achieve this goal. So the first logical question, and one that institutions have for the most part understood and answered is, “How will an integrated fraud strategy help us reduce our losses and save on operation and technology budgets?” While these basic elements are critical in forming a self-funded business case for the required transformation, the problem with this simple approach to building support is that it lives purely on the cost side of the ledger, and therefore will not garner enthusiasm from stakeholders responsible for driving revenue. To be properly supported by the full stakeholder community as a strategic initiative, the question that must be answered is, “How does an integrated fraud approach support the institutions fundamental business strategy and increase shareholder value?” Providing real value to the business is a stated goal of most risk management functions, but as we’ve worked with our clients to begin to identify how this can be accomplished the conversation invariably defaults to “soft” benefits such as protecting reputation, customer perception, and ensuring a clear bill of health with regulating authorities. These benefits are clearly important and valuable, but are also intangible and difficult to quantify, so basing a business case on them is impossible. An integrated approach to fraud operations however, can provide three very tangible benefits that can drive and support strategic business results.

4

Unlocking the value of an integrated fraud strategy

Minimize impact on good revenue: There is an opportunity cost associated with fraud controls, and banks must balance the tradeoff between addressing risks with the lost revenue caused by over reaching controls. An integrated approach increases transparency into these opportunity costs at the customer, entity, or event level, and enables better planning and execution to limit these negative impacts. Improve customer retention: Recent industry studies report that 20-25% of customers touched by a fraud event end their relationship with the bank. An integrated approach and resulting improved prevention abilities will reduce the number of customers that leave the institution. Additionally, with the growing risk of identity theft, fraud events increasingly involve multiple channels (checking account and credit card for example), but loss prevention organizations are not equipped to interact with the customer holistically. The result is that what could be a positive experience for the customer, “my bank is looking out for my safety,” can turn into a frustrating and negative experience. An integrated approach reduces fraud related customer touch points. When customer contact is necessary it is coordinated and intelligent. Enhance credit quality: All managers responsible for credit losses recognize that there is some degree of fraud hidden within the bad debt. This problem erroneously increases credit charge-offs. Collection associates waste time attempting to collect. An integrated approach can uncover bad debt that is in truth fraud. This not only takes it out of the credit loss numbers but allows a more appropriate treatment for investigation and possible recovery. A business case that addresses these three areas, in addition to the more obvious loss prevention and cost take out dimensions can successfully build the consensus and stakeholder support necessary for a successful initiative.

Developing a holistic data strategy At IBM, we’ve seen a strong trend across the banking industry towards strategic data management. The business case is clear for reducing duplicate and redundant data across the complex, integrated financial institutions that most large banks have become over the past generation as a result of continuous expansion and merger activity. Businesses are putting an eye towards improved analytics that can be leveraged for business expansion and improved risk management. The goal of improved analytics necessitates better data management, and in the process can drive substantial infrastructure and operational cost savings. In the fraud domain, these same challenges are exasperated by the silo mentality and highly evolutionary nature of existing systems and processes. The same economic opportunities exist, maybe to a greater extent because of the fraud functions heavy dependency on effective analytics. Silo-based loss prevention functions have duplicated and sometimes inconsistent views of the same data sets. Because the fraud prevention problem evolves quickly as banks layer on additional protections in response to emerging threats, the data architecture supplying the fraud prevention function continues to grow more repetitive, redundant, and inefficient. A holistic data strategy, specific to the fraud domain, will drive three notable benefits: 1. Improved analytics effectiveness 2. More timely and complete view of data to the fraud operator/decision maker 3. Operation and technology cost savings

IBM Global Business Services

Not all data environments are created equal. In fact, based on experience working with many of the large integrated financial institutions in the US and globally, the specific architectures and day to day challenges are not always similar, but the macro level impediments to fraud program effectiveness are quite consistent. Data timing should be constrained by the operations of the business, but in many cases today there are additional constraints introduced by latency of systems downstream from the back-office transaction processing. Not all transactions are real time or even near real time. Many financial transactions still occur in an overnight batch mode, some are real time or near real time. As the data architecture is simplified and streamlined, fraud analytics should function at the speed of business. All fraud systems should share common business definitions. Primary entities central to successful analytics can be standardized, thereby improving the ability to understand linkages and common threats across silos. As many institutions move to improve broad scale analytics at the enterprise level, these improvements can lend dramatic value to the integrated fraud agenda. In some cases, fraud will need to set individual standards and definitions of data, for instance the fraud prevention function is far more dependent on a detailed view of transaction streams than many other functions in the bank. In the end, it is important for the fraud agenda to be well represented as a stakeholder in setting enterprise data and analytic transformation priorities. It is also important for fraud stakeholders to take ownership of their own data agenda outside larger enterprise initiatives and drive the improvements that are necessary to take analytics to the next level of effectiveness and cross channel visibility. Really, can you think of a recent fraud project that wasn’t ultimately constrained by the availability or quality of data?

5

Understanding Requirements Integrated fraud platforms have become a solution class in their own right. Several of the prominent industry analyst groups have recently published papers describing the typical functionality set these software vendors provide including top quadrant analysis identifying the early leaders in the space. We invariably see a consistent short list of the same 2-3 vendors truly being considered, so circumstantial evidence suggests the practical solution class is a bit narrower than what these industry analyst reports suggest. Institutions place a great deal of focus and energy on vendor evaluation and the selection process. While it is clearly a good practice to perform extensive due diligence and make an eyes wide open decision when selecting this strategic component of the go forward fraud architecture, one mistake we often see made is carrying over requirements and expectations from the selection process into the implementation project. It is absolutely critical that once the platform is selected, business requirements and implementation plans be reset. Requirements that are documented for the purpose of conducting a request for proposal tend to be firmly grounded on a cloud in the blue sky. It is important when implementing a packaged solution to define requirements with the end in mind. Requirements should be explored during an open dialogue with experts in implementing the chosen software, sometimes the professional services division of the software vendor can provide this perspective, and oftentimes it is wise to engage an experienced system integrator to provide an independent view. The dialogue should explore what the solution can provide with existing functionality and what will require customization so that intelligent trade-off decisions can be made based on a clear understanding of effort and risks.

6

Unlocking the value of an integrated fraud strategy

All team members (bank, vendor, system integration consultants) must have a common understanding of the requirements, and of the business needs driving the requirements. It is critical that the end user community is at the center of the requirements dialoged, as well as be involved in the build/ configuration phase to mitigate the misunderstanding of requirements. Having the users involved in early solution walkthroughs and allowing for adjustments to requirements and solution design in later phases of the project plan will help ensure the solution matches the true business need. These choices and best practices are difficult to plan at the outset of a project, when the timeline and budget are primarily setting the agenda, but you are likely to go through these steps one way or another. The question is, will they be planned, organized, and accounted for in the timelines and other commitments driving senior management expectations, or will they be an unexpected delay and budget over-run? The industry-leading solutions in this space offer immense flexibility. To deal with this flexibility, a highly structured methodology must be adopted and adhered to for documenting and managing requirements through the full project life cycle. Integrating fraud operations across a large complex organization will likely be a multi-year, multi-phased program. The requirement set for phase one will be complex in its own right. As future phases are layered on, along with enhancements and break fixes for functionality already in production, understanding all requirements and their interdependencies is an enormous task that must be supported by proven methodology, reliable tools, and experienced resources. A recent integrated fraud project at a large global financial institution was delayed by more than a year as the project struggled to exit the requirements and design phase and then was plagued by a high number of defects and functional

deficiencies attributed to poorly defined requirements. This delay resulted in an erosion of more than $50 million to the project’s underlying business case when considering both cost and benefit sides. The primary lessons learned from that experience have already been articulated above, but needless to say a more structured requirements management process and methodology was instrumental in avoiding similar delays on future phases, as well as accelerating the pace of the overall program, and improving the quality of delivered functionality against the true needs of the business.

Implementing to deliver value With IT projects, time is money. The business case for integrated fraud is built on delivering in year benefits, prevented fraud and operational cost savings. Benefit lost to project delays can never be recovered. Based on our experience, the cost of delay when implementing an integrated fraud solution for a top 10 US bank is $12-15million per calendar quarter, which translates to $4-5million per month, or more than $1 million of added cost and eroded benefit per week of delay! To ensure reliable delivery timelines, program management plays a critical role in delivering promised value. Often times, projects get very focused on delivering a list of functional requirements and lose sight of the primary objective which is delivering the economic benefits committed to at the project outset. Fully meeting the functional requirements of phase one becomes a hard dependency to starting phase two regardless of what is really driving the promised business benefit. Managing scope and schedule by value is one way to ensure the promised benefit is realized, but more importantly a coordinated assembly line approach to the system development life cycle ensuring resource continuity and continues forward progress on the overall solution is critical to success.

IBM Global Business Services

In our experience working on these types of projects, there are four primary functional value drivers to the business case: 1. Thin integration: Meaning not biting off too much. A smart approach is to leverage the value that existing systems are providing and concentrating on first integrating at an operational level. This means the first step is achieving a single consolidated case management environment that integrates alerts coming from all the existing systems across channels. 2. Tier two analytics: As alerts flow into a common case management environment, much of the value comes from the ability to consolidate those alerts by entity and perform a second level of rule based, systematic evaluation before the alerts are given to an operator for investigation and action. The ability to correlate alerts from various detection methods for one product and across products will uncover fraud that would otherwise remain hidden. Additional value is provided by reducing the total number of alerts that must be handled, and second having higher quality alerts with a more complete perspective of all risk activity across channels and over time. 3. Integrated data view for the operator: in today’s environment, there are often a large number of systems that an operator must interact with in order to dispose of the alert in question. It’s very normal for fraud operators to have multiple computer monitors, with multiple applications open on each screen. It’s normal to see an operator write down an account number on a piece of paper, then switch over to another application to type it in to find the needed data. We estimate that as much as 80% of the elapsed time working a typical alert is spent on administrative or data entry tasks. By providing a more accurate and complete view of all the necessary data needed for a given alert type, the percentage of time operators spend on true value add, knowledge worker tasks like making decisions and taking action to mitigate risks can be increased dramatically. These gains should also translate into direct operator efficiency gains, typically measured by the average amount of time spent on each alert.

7

4. Automation: for many simple alert types the action taken by the operator is parameter driven and procedural in nature. For example, a high dollar check deposit alert may call for the operator to check available balance on the account first, then consider overall relationship balance, and if available funds are less than the value of the deposit a hold is placed. Processes like this can be automated by the integrated fraud platform, and this automation can lead to significant increases in the throughput of the investigative organization. These primary drivers of value can be mapped directly to efficiency gains, and depending on the metrics your institution uses to track fraud losses, they should align well with the business case behind integrated fraud. Managing the project to metrics centered on delivering value, rather than merely ticking off a list of functional components is an important perspective to maintain as project challenges and potential delays arise.

Conclusion In the face of growing sophistication and frequency of fraud attacks backed by well organized and technologically advanced criminal networks, banks must respond by integrating fraud functions across business lines to achieve a holistic enterprise view of risks. An integrated fraud platform, usually in the form of a single case management system that collects, consolidates, processes, and automates alerts from existing silo based detection systems is the core system change required to support the holistic approach. Some institutions are already working towards implementing an integrated fraud case management system; many are still in the planning phases. IBM’s lessons learned are based on working with the early adopters in this area. Careful consideration and implementation of these best practices will increase the total value delivered from an integrated fraud solution by controlling implementation costs and ensuring a close fit to core value add requirements so that long term benefits emerge as planned.

About the author Jake Jacobson is an Associate Partner in IBM’s Strategy & Transformation practice focused on the Financial Services Industry segment. He specializes in helping banks implement effective systematic controls for Financial Crime related issues. He can be reached at [email protected].

© Copyright IBM Corporation 2009 IBM Global Services Route 100 Somers, NY 10589 U.S.A. Produced in the United States of America September2009 All Rights Reserved IBM, the IBM logo and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at ibm.com/legal/copytrade.shtml Other company, product and service names may be trademarks or service marks of others. References in this publication to IBM products and services do not imply that IBM intends to make them available in all countries in which IBM operates. Please Recycle

GBW03094-USEN-00