Attributes: The Cornerstone of Sound Credit Policy

You’ve heard the term cornerstone before, right? The word comes from the concept of setting the first stone in the construction of a masonry foundation. It is the most important “brick” since it is the reference by which all other bricks will be set for the entire building. Many precautions are taken to ensure that the cornerstone is set correctly. Similarly, credit attributes are the foundation of any credit policy in the financial industry. As such, the same care and consideration taken in setting cornerstones should be taken in the creation, deployment, and use of credit attributes. Unfortunately, this level of consideration is frequently missing in financial institutions. Let me explain.

Credit attributes (a.k.a. characteristics, elements, or variables) are generally created by financial institutions (FIs) (or on their behalf by the credit bureaus) to define the specific behavior of a consumer as it relates to credit. For example, a common attribute is “30 days past due”. When an FI pulls a consumer’s credit file to decide if they want to issue them credit, the FI calculates the “30 days past due” attribute by analyzing the credit file and counting up the number of times the consumer has been more than 30 days late in meeting their credit obligations. This attribute, along with many others, is then used to help the financial institution make their credit decision. At larger FIs, credit attributes are calculated automatically by their decisioning system, so that more complex business rules and decisioning logic that require those attribute calculations can be executed.

The problem with attributes is that they are costly and time-consuming to build. Making credit decisions is complex. Thus, the credit policy and business logic used to make those decisions in an automated process is also complex. Attributes are the foundation for all of these complex structures and as a result, FIs need a lot of them. They need different attributes for each data source that is used in the credit decisioning process (whether it is the credit bureaus or alternative data providers). They need unique attributes for their different credit products (credit card, home equity loans, etc.) and banking channels (branches, online, etc.)

In order to handle the burden of creating and managing so many attributes, financial institutions tend to decentralize the process. Each line of business and channel create their own set of attributes and update them periodically, as they add new data sources or create new decisioning logic.

The problem with this decentralized approach to attribute development and management is twofold.

First, this approach creates inconsistencies across the institution. Because attributes are the foundation of all credit decisioning logic, subtle differences in the way that FIs define and calculate them can have big impacts on the final outcome. For example, with the “30 days past due” attribute, FIs could calculate it based on the last 3 months, or the last 12 months, or the last 36 months. Imagine a consumer—someone who had some defaults during the height of the recession 3 years ago, but has been a model borrower since then. This consumer would look wildly different, from a credit risk perspective, depending on the way the financial institution defined their “past due” attributes. No single way is more correct necessarily, but the inconsistency that this hypothetical consumer would experience applying for credit based on 3 months versus 3 years of credit history would be staggering. When different parts of the organization define and calculate attributes independently, damaging inconsistencies in credit risk policy and customers’ experiences can result.

Second, a decentralized approach to building and maintaining attributes—while easier in the short-term—can be extremely expensive in the long-run. This is due to the fact that many of the credit attributes used across a financial institution’s products and channels are the same. In any credit decision, you are going to calculate the number of defaults. You are going to calculate the length of the consumer’s credit history. You are going to calculate the number of inquiries. Because so many attributes are common across the institution, it makes very little sense, monetarily, to build and maintain redundant (and possibly inconsistent) copies of these attributes within each of the FI’s lines of business and channels.

Since attributes are the cornerstone of credit policy, there can really only be one answer to solving these problems: define the attributes one time and build all other credit policy, decisioning logic, and data pulls around them. Centralizing attribute development, testing, and deployment will enable consistency and good customer experiences across the enterprise.

It is surprising to me that so few FI’s require their attributes to be consistent and accurate across every channel, market, and product. Granted, legacy systems and their inflexibility have much to do with this. However if ripping and replacing a legacy system is not a feasible solution, there are ways to make legacy systems more nimble by incorporating flexible technology around them. Investigating these options at the attribute level before changing all other decisions/processes is prudent. Don’t be caught with a faulty foundation.