Working with clients in the financial sector means keeping an eye toward compliance and regulations like the Gramm-Leach-Bliley Act (GLB), the Fair Credit Reporting Act (FCRA) or Fair and Accurate Credit Transactions Act (FACTA). It doesn’t really matter what kind of product it is, if a client is a financial institution (FI) of some kind, one of these three pieces of legislation is probably going to apply. The good part is, these clients know it and typically have staff dedicated to these functions.
In my experience, where most clients need help is in understanding which regulations apply or what might be allowed under each. The truth is, a product designed to minimize fraud, like knowledge based authentication, will function the same whether using FCRA regulated or non-FCRA regulated data. The differences will be in the fraud models used with the product, the decisioning strategies set-up, the questions asked and the data sources of those questions. Under GLB it is acceptable to use fraud analytics for detection purposes, as fraud detection is an approved GLB exception. However, under FCRA rules, fraud detection is not a recognized permissible purpose (for accessing a consumer’s data). Instead, written instructions (of the consumer) may be used as the permissible purpose, or another permissible purpose permitted under FCRA; such as legitimate business need due to risk of financial loss.
Fraud best practices dictate engaging with clients, and their compliance teams, to ensure the correct product has been selected based on client fraud trends and client needs. A risk based authentication approach, using all available data and appropriately decisioning on that data, whether or not it includes out of wallet questions, provides the most efficient management of risk for clients and best experience for consumers.
