Fraud & Identity Management
--by Andrew Gulledge General configuration issues Question selection- In addition to choosing questions that generally have a high percentage correct and fraud separation, consider any questions that would clearly not be a fit to your consumer population. Don’t get too trigger-happy, however, or you’ll have a spike in your “failure to generate questions” rate. Number of questions- Many people use three or four out-of-wallet questions in a Knowledge Based Authentication session, but some use more or less than that, based on their business needs. In general, more questions will provide a stricter authentication session, but might detract from the customer experience. They may also create longer handling times in a call center environment. Furthermore, it is harder to generate a lot of questions for some consumers, including thin-file types. Fewer Knowledge Based Authentication questions can be less invasive for the consumer, but limits the fraud detection value of the KBA process. Multiple choice- One advantage of this answer format is that it relies on recognition memory rather than recall memory, which is easier for the consumer. Another advantage is that it generally prevents complications associated with minor numerical errors, typos, date formatting errors and text scrubbing requirements. A disadvantage of multiple-choice, however, is that it can make educated guessing (and potentially gaming) easier for fraudsters. Fill in the blank- This is a good fit for some KBA questions, but less so with others. A simple numeric answer works well with fill in the blank (some small variance can be allowed where appropriate), but longer text strings can present complications. While undoubtedly difficult for a fraudster to guess, for example, most consumers would not know the full, official and (correct spelling) of the name to which they pay their monthly auto payment. Numeric fill in the blank questions are also good candidates for KBA in an IVR environment, where consumers can use their phone’s keypad to enter the answers.
--by Andrew Gulledge Where does Knowledge Based Authentication fit into my decisioning strategy? Knowledge Based Authentication can fit into various parts of your authentication process. Some folks choose to put every consumer through KBA, while others only send their riskier transactions through the out-of-wallet questions. Some people use Knowledge Based Authentication to feed a manual review process, while others use a KBA failure as a hard-decline. Uses for KBA are as sundry and varied as the questions themselves. Decision Matrix- As discussed by prior bloggers, a well-engineered fraud score can provide considerable lift to any fraud risk strategy. When possible, it is a good idea to combine both score and questions into the decisioning process. This can be done with a matrixed approach—where you are more lenient on the questions if the applicant has a good fraud score, and more lenient on the score if the applicant did well on the questions. In a decision matrix, a set decision code is placed within various cells, based on fraud risk. Decision Overrides- These provide a nice complement to your standard fraud decisioning strategy. Different fraud solution vendors provide different indicators or flags with which decisioning rules can be created. For example, you might decide to fail a consumer who provides a social security number that is recorded as deceased. These rules can help to provide additional lift to the standard decisioning strategy, whether it is in addition to Knowledge Based Authentication questions alone, questions and score, etc. The overrides can be along the lines of both auto-pass and auto-fail.
In my last post I discussed the problem with confusing what I would call “real” Knowledge Based Authentication (KBA) with secret questions. However, I don’t think that’s where the market focus should be. Instead of looking at Knowledge Based Authentication (KBA) today, we should be looking toward the future, and the future starts with risk-based authentication. If you’re like most people, right about now you are wondering exactly what I mean by risk-based authentication. How does it differ from Knowledge Based Authentication, and how we got from point A to point B? It is actually pretty simple. Knowledge Based Authentication is one factor of a risk-based authentication fraud prevention strategy. A risk- based authentication approach doesn’t rely on question/answers alone, but instead utilizes fraud models that include Knowledge Based Authentication performance as part of the fraud analytics to improve fraud detection performance. With a risk-based authentication approach, decisioning strategies are more robust and should include many factors, including the results from scoring models. That isn’t to say that Knowledge Based Authentication isn’t an important part of a risk-based approach. It is. Knowledge Based Authentication is a necessity because it has gained consumer acceptance. Without some form of Knowledge Based Authentication, consumers question an organization’s commitment to security and data protection. Most importantly, consumers now view Knowledge Based Authentication as a tool for their protection; it has become a bellwether to consumers. As the bellwether, Knowledge Based Authentication has been the perfect vehicle to introduce new and more complex authentication methods to consumers, without them even knowing it. KBA has allowed us to familiarize consumers with out-of-band authentication and IVR, and I have little doubt that it will be one of the tools to play a part in the introduction of voice biometrics to help prevent consumer fraud. Is it always appropriate to present questions to every consumer? No, but that’s where a true risk-based approach comes into play. Is Knowledge Based Authentication always a valuable component of a risk based authentication tool to minimize fraud losses as part of an overall approach to fraud best practices? Absolutely; always. DING!
--by Andrew Gulledge Definition and examples Knowledge Based Authentication (KBA) is when you ask a consumer questions to which only they should know the answer. It is designed to prevent identity theft and other kinds of third-party fraud. Examples of Knowledge Based Authentication (also known as out-of-wallet) questions include “What is your monthly car payment?:" or “What are the last four digits of your cell number?” KBA -- and associated fraud analytics -- are an important part of your fraud best practices strategies. What makes a good KBA question? High percentage correct A good Knowledge Based Authentication question will be easy to answer for the real consumer. Thus we tend to shy away from questions for which a high percentage of consumers give the wrong answer. Using too many of these questions will contribute to false positives in your authentication process (i.e., failing a good consumer). False positives can be costly to a business, either by losing a good customer outright or by overloading your manual review queue (putting pressure on call centers, mailers, etc.). High fraud separation It is appropriate to make an exception, however, if a question with a low percentage correct tends to show good fraud detection. (After all, most people use a handful of KBA questions during an authentication session, so you can leave a little room for error.) Look at the fraudsters who successfully get through your authentication process and see which questions they got right and which they got wrong. The Knowledge Based Authentication questions that are your best fraud detectors will have a lower percentage correct in your fraud population, compared to the overall population. This difference is called fraud separation, and is a measure of the question’s capacity to catch the bad guys. High question generability A good Knowledge Based Authentication question will also be generable for a high percentage of consumers. It’s admirable to beat your chest and say your KBA tool offers 150 different questions. But it’s a much better idea to generate a full (and diverse) question set for over 99 percent of your consumers. Some KBA vendors tout a high number of questions, but some of these can only be generated for one or two percent of the population (if that). And, while it’s nice to be able to ask for a consumer’s SCUBA certification number, this kind of question is not likely to have much effect on your overall production.
Round 1 – Pick your corner There seems to be two viewpoints in the market today about Knowledge Based Authentication (KBA): one positive, one negative. Depending on the corner you choose, you probably view it as either a tool to help reduce identity theft and minimize fraud losses, or a deficiency in the management of risk and the root of all evil. The opinions on both sides are pretty strong, and biases “for” and “against” run pretty deep. One of the biggest challenges in discussing Knowledge Based Authentication as part of an organization’s identity theft prevention program, is the perpetual confusion between dynamic out-of-wallet questions and static “secret” questions. At this point, most people in the industry agree that static secret questions offer little consumer protection. Answers are easily guessed, or easily researched, and if the questions are preference based (like “what is your favorite book?”) there is a good chance the consumer will fail the authentication session because they forgot the answers or the answers changed over time. Dynamic Knowledge Based Authentication, on the other hand, presents questions that were not selected by the consumer. Questions are generated from information known about the consumer – concerning things the true consumer would know and a fraudster most likely wouldn’t know. The questions posed during Knowledge Based Authentication sessions aren’t designed to “trick” anyone but a fraudster, though a best in class product should offer a number of features and options. These may allow for flexible configuration of the product and deployment at multiple points of the consumer life cycle without impacting the consumer experience. The two are as different as night and day. Do those who consider “secret questions” as Knowledge Based Authentication consider the password portion of the user name and password process as KBA, as well? If you want to hold to strict logic and definition, one could argue that a password meets the definition for Knowledge Based Authentication, but common sense and practical use cause us to differentiate it, which is exactly what we should do with secret questions – differentiate them from true KBA. KBA can provide strong authentication or be a part of a multifactor authentication environment without a negative impact on the consumer experience. So, for the record, when we say KBA we mean dynamic, out of wallet questions, the kind that are generated “on the fly” and delivered to a consumer via “pop quiz” in a real-time environment; and we think this kind of KBA does work. As part of a risk management strategy, KBA has a place within the authentication framework as a component of risk- based authentication… and risk-based authentication is what it is really all about.
Many compliance regulations such the Red Flags Rule, USA Patriot Act, and ESIGN require specific identity elements to be verified and specific high risk conditions to be detected. However, there is still much variance in how individual institutions reconcile referrals generated from the detection of high risk conditions and/or the absence of identity element verification. With this in mind, risk-based authentication, (defined in this context as the “holistic assessment of a consumer and transaction with the end goal of applying the right authentication and decisioning treatment at the right time\") offers institutions a viable strategy for balancing the following competing forces and pressures: • Compliance – the need to ensure each transaction is approved only when compliance requirements are met; • Approval rates – the need to meet business goals in the booking of new accounts and the facilitation of existing account transactions; • Risk mitigation – the need to minimize fraud exposure at the account and transaction level. A flexibly-designed risk-based authentication strategy incorporates a robust breadth of data assets, detailed results, granular information, targeted analytics and automated decisioning. This allows an institution to strike a harmonious balance (or at least something close to that) between the needs to remain compliant, while approving the vast majority of applications or customer transactions and, oh yeah, minimizing fraud and credit risk exposure and credit risk modeling. Sole reliance on binary assessment of the presence or absence of high risk conditions and identity element verifications will, more often than not, create an operational process that is overburdened by manual referral queues. There is also an unnecessary proportion of viable consumers unable to be serviced by your business. Use of analytically sound risk assessments and objective and consistent decisioning strategies will provide opportunities to calibrate your process to meet today’s pressures and adjust to tomorrow’s as well.
By: Kennis Wong It\'s true that intent is difficult to prove. It\'s also true that financial situations change. That\'s why financial institutions have not, yet, successfully fought off first-party fraud. However, there are some tell-tale signs of intent when you look at the consumer\'s behavior as a whole, particularly across all his/her financial relationships. For example, in a classic bust out case, you would see that the consumer, with pristine credit history, applies for more and more credit cards while maintaining a relatively low balance and utilization across all issuers. If you graph the number of credit cards and number of credit applications over time, you would see two hockey-stick lines. When the accounts go bad, they do so at almost the same time. This pattern is not always apparent at the time of origination, that\'s why it\'s important to monitor frequently for account review and fraud database alerts. On the other hand, consumers with financial difficulties have different patterns. They might have more credit lines over time, but you would see that some credit lines may go delinquent while others don\'t. You might also see that consumers cure some lines after delinquencies…you can see their struggle of trying to pay. Of course the intent \"pattern\" is not always clear. When dealing with fraudsters in fraud account management, even with the help of the fraud database, fraud trends and fraud alert, change their behaviors and use new techniques.
On Friday, October 30th, the FTC again delayed enforcement of the “Red Flags” Rule – this time until June 1, 2010 – for financial institutions and creditors subject to the FTC’s enforcement. Here’s the official release: http://www.ftc.gov/opa/2009/10/redflags.shtm. But this doesn’t mean, until then, businesses get a free pass. The extension doesn’t apply to other federal agencies that have enforcement responsibilities for institutions under their jurisdiction. And the extension also doesn’t alleviate an institution’s need to detect and respond to address discrepancies on credit reports. Red Flag compliance Implementing best practices to address the identity theft under the Red Flags Rule is not just the law, it’s good business. The damage to reputations and consumer confidence from a problem gone unchecked or worse yet – unidentified – can be catastrophic. I encourage all businesses – if they haven’t already done so – to use this extension as an opportunity to proactively secure a Red Flags Rule to ensure Red Flag compliance. It’s an investment in protecting their most important asset – the customer.
As I wrote in my previous posting, a key Red Flags Rule challenge facing many institutions is one that manages the number of referrals generated from the detection of Red Flags conditions. The big ticket item in referral generation is the address mismatch condition. Identity Theft Prevention Program I’ve blogged previously on the subject of risk-based authentication and risk-based pricing, so I won’t rehash that information. What I will suggest, however, is that those institutions who now have an operational Identity Theft Prevention Program (if you don’t, I’d hurry up) should continue to explore the use of alternate data sources, analytics and additional authentication tools (such as knowledge-based authentication) as a way to detect Red Flags conditions and reconcile them all within the same real-time transaction. Referral rates Referral rates stemming from address mismatches (a key component of the Red Flags Rule high risk conditions) can approach or even surpass 30 percent. That is a lot. The good news is that there are tools which employ additional data sources beyond a credit profile to “find” that positive address match. The use of alternate data sources can often clear the majority of these initial mismatches, leaving the remaining transactions for treatment with analytics and knowledge-based authentication and Identity Theft Prevention Program. Whatever “referral management” process you have in place today, I’d suggest exploring risk-based authentication tools that allow you to keep the vast majority of those referrals out of the hands of live agents, and distanced from the need to put your customers through the authentication wringer. In the current marketplace, there are many services that allow you to avoid high referral costs and risks to customer experience. Of course, we think ours are pretty good.
In my last entry, I talked about the challenges clients face in trying to meet multiple and complex regulatory requirements, such as FACT Act’s Red Flags Rule and the USA Patriot Act. While these regulations serve both different and shared purposes, there are some common threads between the two: 1. You must consider the type of accounts and methods of account opening: The type of account offered - credit or deposit, consumer or business – as well as the method of opening – phone, online, or face-to-face – has a bearing on the steps you need to take and the process that will be established. 2. Use of consumer name, address, and identification number:The USA Patriot Act requires each of these – plus date of birth – to open a new account. Red Flags stops short of “requiring” these for new account openings, but it consistently illustrates the use of these Personally Identifiable Information (PII) elements as examples of reasonable procedures to detect red flags. 3. Establishing identity through non-documentary verification:Third party information providers, such as a credit reporting agency or data broker, can be used to confirm identity, particularly in the case where the verification is not done in person. Knowing what’s in common means you can take a look at where to leverage processes or tools to gain operational and cost efficiencies and reduce negative impact on the customer experience. For example, if you’re using any authentication products today to comply with the USA Patriot Act and/or minimize fraud losses, the information you collect from consumers and authentication steps you are already taking now may suffice for a large portion of your Red Flags Identity Theft Prevention Program. And if you’re considering fraud and compliance products for account opening or account management – it’s clear that you’ll want something flexible that, not only provides identity verification, but scales to the compliance programs you put in place, and those that may be on the horizon.
While the FACT Act’s Red Flags Rule seems to capture all of the headlines these days, it’s just one of a number of compliance challenges that banks, credit unions, and a myriad of other institutions face on a daily basis. And meeting today’s regulatory requirements is more complicated than ever. Risk managers and compliance officers are asked to consider many questions, including: 1. Do FACTA Sections 114 and 315 apply to me? 2. What do I have to do to comply? 3. What impact does this have on the customer’s experience? 4. What is this going to cost me in terms of people and process? Interpretation of the law or guideline – including who it applies to and to whom it does not - varies widely. Which types of businesses are subject to the Red Flags Rule? What is a “covered account?” If you’re not sure, you’re not alone - it’s a primary reason why the Federal Trade Commission (FTC) continues to postpone enforcement of the rule, while this healthy debate continues. And by the way, FTC – it’s almost November 1st…aren’t we about due for another delay? But we’re not talking about just protecting consumers from identity theft and reducing fraud and protecting themselves using the Identity Theft Prevention Program. The USA Patriot Act and “Know Your Customer” requirements have been around much longer, but there are current challenges of interpretation and practical application when it comes to identifying customers and performing due diligence to deter fraud and money laundering. Since Customer Identification Programs require procedures based on the bank’s own “assessment of the relevant risks,” including types of accounts opened, methods of opening, and even the bank’s “size, location, and customer base,” it’s safe to say that each program will differ slightly – or even greatly. So it’s clear there’s a lack of specificity in the regulations of the Red Flags Rule which cause heartburn for those tasked with compliance…but are there some common themes and requirements across the two? The short answer is Yes. In my next post, I’ll talk about the elements in common and how authentication products can play a part in addressing both.
In my previous three postings, I’ve covered basic principles that can define a risk-based authentication process, associated value propositions, and some best-practices to consider. Finally, I’d like to briefly discuss some emerging informational elements and processes that enhance (or have already enhanced) the notion of risk-based authentication in the coming year. For simplicity, I’m boiling these down to three categories: 1. Enterprise Risk Management – As you’d imagine, this concept involves the creation of a real-time, cross channel, enterprise-wide (cross business unit) view of a consumer and/or transaction. That sounds pretty good, right? Well, the challenge has been, and still remains, the cost of developing and implementing a data sharing and aggregation process that can accomplish this task. There is little doubt that operating in a more silo’d environment limits the amount of available high-risk and/or positive authentication data associated with a consumer…and therefore limits the predictive value of tools that utilize such data. It is only a matter of time before we see more widespread implementation of systems designed to look at a single transaction, an initial application profile, previous authentication results, or other relationships a consumer may have within the same organization -- and across all of this information in tandem. It’s simply a matter of the business case to do so, and the resources to carry it out. 2. Additional Intelligence – Beyond some of the data mentioned above, some additional informational elements emerging as useful in isolation (or, even better, as a factor among others in a holistic assessment of a consumer’s identity and risk profile) include these areas: IP address vs. physical address comparisons; device ID or fingerprinting; and biometrics (such as voice verification). While these tools are being used and tested in many organizations and markets, there is still work to be done to strike the right balance as they are incorporated into an overall risk-based authentication process. False positives, cost and implementation challenges still hinder widespread use of these tools from being a reality. That should change over time, and quickly to help with the cost of credit risk. 3. Emerging Verification Techniques – Out-of-band authentication is defined as the use of two separate channels, used simultaneously, to authenticate a customer. For example: using a phone to verify the identity of that person while performing a Web transaction. Similarly, many institutions are finding success in initiating SMS texts as a means of customer notification and/or verification of monetary or non-monetary transactions. The ability to reach out to a consumer in a channel alternate to their transaction channel is a customer friendly and cost effective way to perform additional due diligence.
By: Kennis Wong In Part 1 of Generic fraud score, we emphasized the importance of a risk-based approach when it comes to fraud detection. Here are some further questions you may want to consider. What is the performance window? When a model is built, it has a defined performance window. That means the score is predicting a certain outcome within that time period. For example, a traditional risk score may be predicting accounts that are decreasing in twenty-four months. That score may not perform well if your population typically worsens in two months. This question is particularly important when it relates to scoring your population. For example, if a bust-out score has a performance window of three months, and you score your accounts at the time of acquisition, it would only catch accounts that are busting-out within the next three months. As a result, you should score your accounts during periodic account reviews in addition to the time of acquisition to ensure you catch all bust-outs. Therefore, bust out fraud is an important indicator. Which accounts should I score? While it’s typical for creditors to use a fraud score on every applicant at the time of acquisition, they may not score all their accounts during review. For example, they may exclude inactive accounts or older accounts assuming those with a long history means less likelihood of fraud. This mistake may be expensive. For instance, the typical bust-out behavior is for fraudsters to apply for cards way before they intend to bust out. This may be forty-eight months or more. So when you think they are good and profitable customers, they can strike and leave you with seriously injury. Make sure that your fraud database is updated and accurate. As a result, the recommended approach is to score your entire portfolio during account review. How often do I validate the score? The answer is very often -- this may be monthly or quarterly. You want to understand whether the score is working for you – do your actual results match the volume and risk projections? Shifts of your score distribution will almost certainly occur over time. To meet your objectives over the long run, continue to monitor and adjust cutoffs. Keep your fraud database updated at all times.
By: Kennis Wong In this blog entry, we have repeatedly emphasized the importance of a risk-based approach when it comes to fraud detection. Scoring and analytics are essentially the heart of this approach. However, unlike the rule-based approach, where users can easily understand the results, (i.e. was the S.S.N. reported deceased? Yes/No; Is the application address the same as the best address on the credit bureau? Yes/No), scores are generated in a black box where the reason for the eventual score is not always apparent even in a fraud database. Hence more homework needs to be done when selecting and using a generic fraud score to make sure they satisfy your needs. Here are some basic questions you may want to ask yourself: What do I want the score to predict? This may seem like a very basic question, but it does warrant your consideration. Are you trying to detect these areas in your fraud database? First-party fraud, third-party fraud, bust out fraud, first payment default, never pay, or a combination of these? These questions are particularly important when you are validating a fraud model. For example, if you only have third-party fraud tagged in your test file, a bust out fraud model would not perform well. It would just be a waste of your time. What data was used for model development? Other important questions you may want to ask yourself include: Was the score based on sub-prime credit card data, auto loan data, retail card data or another fraud database? It’s not a definite deal breaker if it was built with credit card data, but, if you have a retail card portfolio, it may still perform well for you. If the scores are too far off, though, you may not have good result. Moreover, you also want to understand the number of different portfolios used for model development. For example, if only one creditor’s data is used, then it may not have the general applicability to other portfolios.
In my previous two blog postings, I’ve tried to briefly articulate some key elements of and value propositions associated with risk-based authentication. In this entry, I’d like to suggest some best-practices to consider as you incorporate and maintain a risk-based authentication program. 1. Analytics – since an authentication score is likely the primary decisioning element in any risk-based authentication strategy, it is critical that a best-in-class scoring model is chosen and validated to establish performance expectations. This initial analysis will allow for decisioning thresholds to be established. This will also allow accept and referral volumes to be planned for operationally. Further more, it will permit benchmarks to be established which follow on performance monitoring that can be compared. 2. Targeted decisioning strategies – applying unique and tailored decisioning strategies (incorporating scores and other high-risk or positive authentication results) to various access channels to your business just simply makes sense. Each access channel (call center, Web, face-to-face, etc.) comes with unique risks, available data, and varied opportunity to apply an authentication strategy that balances these areas; risk management, operational effectiveness, efficiency and cost, improved collections and customer experience. Champion/challenger strategies may also be a great way to test newly devised strategies within a single channel without taking risk to an entire addressable market and your business as a whole. 3. Performance Monitoring – it is critical that key metrics are established early in the risk-based authentication implementation process. Key metrics may include, but should not be limited to these areas: • actual vs. expected score distributions; • actual vs. expected characteristic distributions; • actual vs. expected question performance; • volumes, exclusions; • repeats and mean scores; • actual vs. expected pass rates; • accept vs. referral score distribution; • trends in decision code distributions; and • trends in decision matrix distributions. Performance monitoring provides an opportunity to manage referral volumes, decision threshold changes, strategy configuration changes, auto-decisioning criteria and pricing for risk based authentication. 4. Reporting – it likely goes without saying, but in order to apply the three best practices above, accurate, timely, and detailed reporting must be established around your authentication tools and results. Regardless of frequency, you should work with internal resources and your third-party service provider(s) early in your implementation process to ensure relevant reports are established and delivered. In my next posting, I will be discussing some thoughts about the future state of risk based authentication.
Learn More Image
