Tag: KBA

Loading...

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.  

Published: March 5, 2010 by Guest Contributor

When a client is selecting questions to use, Knowledge Based Authentication is always about the underlying data – or at least it should be.  The strength of Knowledge Based Authentication questions will depend, in large part, on the strength of the data and how reliable it is.  After all, if you are going to depend on Knowledge Based Authentication for part of your risk management and decisioning strategy the data better be accurate.  I’ve heard it said within the industry that clients only want a system that works and they have no interest where the data originates.  Personally, I think that opinion is wrong. I think it is closer to the truth to say there are those who would prefer if clients didn’t know where the data that supports their fraud models and Knowledge Based Authentication questions originates; and I think those people “encourage” clients not to ask.  It isn’t a secret that many within the industry use public record data as the primary source for their Knowledge Based Authentication products, but what’s important to consider is just how accessible that public record information is.  Think about that for a minute.  If a vendor can build questions on public record data, can a fraudster find the answers in public record data via an online search? Using Knowledge Based Authentication for fraud account management is a delicate balance between customer experience/relationship management and risk management.  Because it is so important, we believe in research – reading the research of well-known and respected groups like Pew, Tower, Javelin, etc. and doing our own research.  Based on our research, I know consumers prefer questions that are appropriate and relative to their activity.  In other words, if the consumer is engaged in a credit-granting activity, it may be less appropriate to ask questions centered on personal associations and relatives.  Questions should be difficult for the fraudster, but not difficult or perceived as inappropriate or intrusive by the true consumer.  Additionally, I think questions should be applicable to many clients and many consumers.  The question set should use a mix of data sources: public, proprietary, non-credit, credit (if permissible purpose exists) and innovative. Is it appropriate to have in-depth data discussions with clients about each data source?  Debatable.  Is it appropriate to ensure that each client has an understanding of the questions they ask as part of Knowledge Based Authentication and where the data that supports those questions originates?  Absolutely.    

Published: March 2, 2010 by Guest Contributor

By: Ken Pruett The use of Knowledge Based Authentication (KBA) or out of wallet questions continues to grow. For many companies, this solution is used as one of its primary means for fraud prevention.  The selection of the proper tool often involves a fairly significant due diligence process to evaluate various offerings before choosing the right partner and solution.  They just want to make sure they make the right choice. I am often surprised that a large percentage of customers just turn these tools on and never evaluate or even validate ongoing performance.  The use of performance monitoring is a way to make sure you are getting the most out of the product you are using for fraud prevention.  This exercise is really designed to take an analytical look at what you are doing today when it comes to Knowledge Based Authentication. There are a variety of benefits that most customers experience after undergoing this fraud analytics exercise.  The first is just to validate that the tool is working properly.  Some questions to ponder include: Are enough frauds being identified? Is the manual review rate in-line with what was expected?  In almost every case I have worked on as it relates to these engagements, there were areas that were not in-line with what the customer was hoping to achieve.  Many had no idea that they were not getting the expected results. Taking this one step further, changes can also be made to improve upon what is already in place.  For example, you can evaluate how well each question is performing.  The analysis can show you which questions are doing the best job at predicting fraud.  The use of better performing questions can allow you the ability to find more fraud while referring fewer applications for manual review.  This is a great way to optimize how you use the tool. In most organizations there is increased pressure to make sure that every dollar spent is bringing value to the organization.  Performance monitoring is a great way to show the value that your KBA tool is bringing to the organization.  The exercise can also be used to show how you are proactively managing your fraud prevention process.   You accomplish this by showing how well you are optimizing how you use the tool today while addressing emerging fraud trends. The key message is to continuously measure the performance of the KBA tool you are using.  An exercise like performance monitoring could provide you with great insight on a quarterly basis.  This will allow you to get the most out of your product and help you keep up with a variety of emerging fraud trends. Doing nothing is really not an option in today’s even changing environment.  

Published: January 18, 2010 by Guest Contributor

The definition of account management authentication is:  Keep your customers happy, but don’t lose sight of fraud risks and effective tools to combat those risks. In my previous posting, I discussed some unique fraud risks facing institutions during the account management phase of their customer lifecycles.  As a follow up, I want to review a couple of effective tools that allow you to efficiently minimize fraud losses during post-application: Knowledge Based Authentication (KBA) — this process involves the use of challenge/response questions beyond "secret" or "traditional" internally derived questions (such as mother's maiden name or last transaction amount). This tool allows for measurably effective use of questions based on more broad-reaching data (credit and noncredit) and consistent delivery of those questions without subjective question creation and grading by call center agents. KBA questions sourced from information not easily accessible by call center agents or fraudsters provide an additional layer of security that is more impenetrable by social engineering. From a process efficiency standpoint, the use of automated KBA also can reduce online sessions for consumers, and call times as agents spend less time self-selecting questions, self-grading responses and subjectively determining next steps. Delivery of KBA questions via consumer-facing online platforms or via interactive voice response (IVR) systems can further reduce operational costs since the entire KBA process can be accommodated without call center agent involvement. Negative file and fraud database – performing checks against known fraudulent and abuse records affords institutions an opportunity to, in batch or real time, check elements such as address, phone, and SSN for prior fraudulent use or victimization.  These checks are a critical element in supplementing traditional consumer authentication processes, particularly in an account management procedure in which consumer and/or account information may have been compromised.  Transaction requests such as address or phone changes to an account are particularly low-hanging fruit as far as running negative file checks are concerned.    

Published: December 28, 2009 by Keir Breitenfeld

--by Andrew Gulledge Intelligent use of features Question ordering: You want some degree of randomization in the questions that are included for each session. If a fraudster (posing as you) comes through Knowledge Based Authentication, for two or three sessions, wouldn’t you want them to answer new questions each time? At the same time, you want to try to use those questions that perform better more often. One way to achieve both is to group the questions into categories, and use a fixed category ordering (with the better-performing categories being higher up in the batting line up)—then, within each category, the question selection is randomized. This way, you can generally use the better questions more, but at the same time, make it difficult to come through Knowledge Based Authentication twice and get the same questions presented back to you. (You can also force all new questions in subsequent sessions, with a question exclusion strategy, but this can be restrictive and make the “failure to generate questions” rate spike.) Question weighting: Since we know some questions outperform others, both in terms of percentage correct and in terms of fraud separation, it is generally a good idea to weight the questions with points based on these performance metrics. Weighting can help to squeeze out some additional fraud detection from your Knowledge Based Authentication tool.  It also provides considerable flexibility in your decisioning (since it is no longer just “how many questions were answered correctly” but it is “what percentage of points were obtained”). Usage Limits: You should only allow a consumer to come through the Knowledge Based Authentication process a certain number of times before getting an auto-fail decision. This can take the form of x number of uses allowable within y number of hours/days/etc. Time out Limit: You should not allow fraudsters to research the questions in the middle of a Knowledge Based Authentication session. The real consumer should know the answers off the top of their heads. In a web environment, five minutes should be plenty of time to answer three to five questions. A call center environment should allow for more time since some people can be a bit chatty on the phone.  

Published: December 22, 2009 by Guest Contributor

--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.  

Published: December 14, 2009 by Guest Contributor

I have already commented on “secret questions” as the root of all evil when considering tools to reduce identity theft and minimize fraud losses.  No, I’m not quite ready to jump off  that soapbox….not just yet, not when we’re deep into the season of holiday deals, steals and fraud.  The answers to secret questions are easily guessed, easily researched, or easily forgotten.  Is this the kind of security you want standing between your account and a fraudster during the busiest shopping time of the year? There is plenty of research demonstrating that fraud rates spike during the holiday season.  There is also plenty of research to demonstrate that fraudsters perpetrate account takeover by changing the pin, address, or e-mail address of an account – activities that could be considered risky behavior in decisioning strategies.  So, what is the best approach to identity theft red flags and fraud account management?  A risk based authentication approach, of course! Knowledge Based Authentication (KBA) provides strong authentication and can be a part of a multifactor authentication environment without a negative impact on the consumer experience, if the purpose is explained to the consumer.  Let’s say a fraudster is trying to change the pin or e-mail address of an account.  When one of these risky behaviors is initiated, a Knowledge Based Authentication session begins. To help minimize fraud, the action is prevented if the KBA session is failed.  Using this same logic, it is possible to apply a risk based authentication approach to overall account management at many points of the lifecycle: • Account funding • Account information change (pin, e-mail, address, etc.) • Transfers or wires • Requests for line/limit increase • Payments • Unusual account activity • Authentication before engaging with a fraud alert representative Depending on the risk management strategy, additional methods may be combined with KBA; such as IVR or out-of-band authentication, and follow-up contact via e-mail, telephone or postal mail.  Of course, all of this ties in with what we would consider to be a comprehensive Red Flag Rules program. Risk based authentication, as part of a fraud account management strategy, is one of the best ways we know to ensure that customers aren’t left singing, “On the first day of Christmas, the fraudster stole from me…”  

Published: December 7, 2009 by Guest Contributor

--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.  

Published: December 7, 2009 by Guest Contributor

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!  

Published: November 23, 2009 by Guest Contributor

--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.    

Published: November 23, 2009 by Guest Contributor

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.    

Published: November 16, 2009 by Guest Contributor

Subscribe to our blog

Enter your name and email for the latest updates.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Subscribe to our Experian Insights blog

Don't miss out on the latest industry trends and insights!
Subscribe