What is a Credit Decision Engine?

Credit decision engine consists of three major components. Third party data intake engine, core decision and scoring engine and lastly enterprise system integration. These three major components are what makes a credit decision engine an integral part of an overall account origination system. 

We will dive in each of these components separately and provide examples of each of these sections. We hope that through these examples, you will get a complete understanding of how decision engines work and set up your own decision engine in the near future.

Credit Decision Engine Core Components - Data Intake Engine

Data is what ultimately determines the outcome and the quality of a credit decision engine. There are a variety of different types of data. Let’s focus on the most common data types that should be considered as part of your decision making process.

First party data

First party data is data you collect from your application form. This type of data contains the basic personal identifiable information that you will need to pull other types of information from other data sources, such as a credit bureau.

Sometimes, the banks capture this information through their website, and other times the bank receives this information from data aggregators and most frequently, the bank tellers capture this information and input it during a face to face interaction with their clients in the bank branch.

Neobanks and other online banking firms take first party data from their website, apps or online brokers that send this data to them via APIs or Application Programming Interfaces.

No matter how this information is captured, there is a set of requirements from the decision engine to make further decisions and advance the application further.

Second party data

This is an often ignored set of information that might come in handy for banks to make a more accurate decision. Banks often work with a lot of lead aggregators to send them online applications or online traffic.

These leads are often not as vetted as they should be. These lead generators will use whatever method to generate clicks. Some are honest and most of them probably use, shall we say, unconventional means to generate traffic.

Second party information is related to the non-applicant data that comes through a lead generated by a third party application broker. This metadata that describes the lead such as which broker and which marketing campaign this lead came from. Sometimes, the timestamp of the application is also important for banks to figure out whether these applications or leads are in fact real.

Third party data

Third party data that feeds into a decision engine is perhaps the most well understood or talked about dataset. This third party data plays a major role in identity verification and credit underwriting.

If you want to explore more third party data, there’s no place to start by looking through LendAPI’s marketplace for identity data as well as credit data.

Often banks will need to pay to access third party datasets. In a typical underwriting decision path, the banks will first verify the applicant's identity by using the first party it has collected to ping a third party data provider.

A typical identity service provider will provide a some sort of response to let the bank know that these parts of identities from the applicant have been seen before by the provider. Sometimes these third party data providers will also use datasets from mobile carriers and other financial institutions to positively link the applicant’s provided identities.

Third party data with first party consent

There is a new breed of third party data providers that provides first party data but through a series of user consents. There are a handful of bank and payroll identity verification providers in LendAPI’s marketplace that let’s users log into their bank accounts as well as their payroll providers to retrieve banking and payroll data.

These banks and payroll providers inadvertently also provide other critical pieces of information relating to identity the banks and lenders can use in their identity verification process. To find more information on these third party data providers in the bank and payroll sector, please take a look at the list at LendAPI’s marketplace under Banking and Payroll Verification.

Third party data from credit bureaus

Credit bureaus in the United States carries a lot of weight in terms of measuring a person or a business's creditworthiness. These credit bureaus have been in existence for over 100 years and they collect information from banks and financial institutions that profiles a person’s ability to repay their debt.

Most of the credit bureaus around the world only records negative information. However, in the United States, credit bureaus collect both positive and negative information. For the consumers and small businesses owners, the ability to getting their repayment behavior reported to these third party credit bureaus will help them to build credit and increase the likelihood of getting approved for additional credit.

It is important to any credit decision engine to ingest this information to help banks and financial services firms to make a critical credit decision after the applicant’s identity has been verified by identity verification bureaus.

In order for the credit bureau to integrate with a credit decision engine, the credit decision engine providers will need to pass a series of security checks including SOC2 compliance audit with a reputable audit firm.

Credit Decision Engine Core Components - Rules engine and Scoring Engine

Now that first, second and third party data is injected into the data intake engine, the other core components of the decision engine take over.

The mathematical part of the decision engine is the soul of the decision engine. The ability to write simple if-then statements is table stakes. The credit decision engine should also have the ability to entertain complex or conditions as well to make your decision trees compact and easy to understand.

A visual decision tree builder like the ones supplied by LendAPI is a beautiful example of how a decision engine aids the rules engineers to build complex but clear decision trees to route an applicant to an approve or decline decision. 

Banks and lenders have grown increasingly more sophisticated over the years and their data science teams have developed scores and other types of scoring techniques that goes beyond the rules but can execute scores that calculate the probability of default or probability of repayment.

These scores are often in the forms of a mathematical formula that takes hundreds or thousands of variables and gives them weights individually or interactions between variables in relation to whether the applicant will pay back their debt.

These probabilistic based scores can no longer be represented by if-the-else statements but with a more complex scoring module that transformers the attributes and leverage statistical transformation to calculate a composite score.

The resulting custom score can then be expressed as a variable and used in an final if-then statement to leverage the power of these scores. And of course, these scores leverages first, second and third party data that’s being read in and stored by the decision engine’s data intake engine.

This part of the Credit Decision Engine is perhaps the most complex piece of software that can handle every possible decision tree outcome, calculate scores in real time as well as render a decision at each decision tree’s end node.

The resulting end node of each branch of the decision tree could lead to different actions from the system as well as actions for the end applicants to perform. We will summarize how these decisions are carried out in the next section of this document.

Credit Decision Core Components - Enterprise System Integration

The outcome of the decision engine trees triggers a variety of different actions for the applicant as well as other enterprise systems to further advance the application to the next stage. 

Let’s examine some of the more popular outcomes of these decision trees. We can start with identity verification trees and how to resolve these outcomes.

Identity Verification Decisions - Approval

If a third party identity verification agency verifies the first party identity data, then this applicant can move forward to the credit underwriting decision tree automatically. You can elect to send an email letting them know that their identity has been verified and if you want to manually start the credit underwriting portion of the application, you can include a link for the applicant to continue their process.

Otherwise, in most cases, once the applicant has received an identity verification approval, they should continue with the application and start the credit approval process. 

Identity Verification Decisions - Review

Sometimes up to 20% of the applicants need some sort of manual review. Depending on the industry and the type of product, the third party data provider is unable to give the application an automatic thumbs up.

In these situations, the credit decision engine should route this application to a built in workflow management system for a fraud analyst to review the application and make a manual decision. These decisions may include a manual approval, asking for additional information to be uploaded or mailed in and a straight manual decline if the underwriter believes that this application is fraudulently submitted.

Identity Verification Decisions - Decline

Sometimes, up to 50+% of the applications are automatically rejected. This also depends on the type of financial services product being offered and via which marketing channel these products are being advertised.

The application might receive a straight decline if the identity failed various identity verification rules. Some of these rules can scan through first party data and determine that the application is fraudulent without calling a third party. For example, if someone puts 123456789 as their Social Security Number, the banks might not need a sophisticated and expensive third party data provider to tell them that this application is fraudulent.

The credit decision engine should be able to integrate to an enterprise system to let the applicant know that their application has been declined. Some credit decision engines have a built in customer communication system that sends email and SMS to let applicants know that their application has been declined.

Once the decision engine has rendered all of the possible outcomes of the identity verification portion of the decision process. It should move onto the next stage, which is credit underwriting.

Let’s take a look at a few common credit underwriting rule outcomes and see how credit decision engines play a role in these decision outcomes.

Credit Underwriting Decisions - Approval 

Everyone likes approval decisions, but what happens when the applicant passes all of the credit underwriting rules supplied by third party data providers? It depends on the product the bank is offering.

If they are offering a checking and savings account, the credit decision engine can show to the applicant that they have been approved and integrated into the bank’s bank core systems. There is a list of bank core systems in LendAPI’s marketplace under Bank and Card Cores.

LendAPI works with a variety of bank cores and through bank core middleware to inject this approval signature into the bank cores and retrieve account numbers or credit card numbers instantly back to the consumer facing systems.

Credit Underwriting Decisions - Review or Conditional Approval

Often, the credit underwriting decision tree can’t render an outright approval decision. It’s lacking pieces of information that can’t be supplied by any third party data provider. Most frequently, employment and income is what the credit underwriting engine needs additional information. 

The credit decision engine should signal to other enterprise systems to pause this application until all of the necessary information has been collected from the applicant. This can be done through email, customer portal and physical evidence of payroll and income information.

Some credit decision engines come with a built in workflow management system that can collect additional documentation with the customers through emails and customer portals. This greatly increases the conversion rate and reduces the amount of complexity and technology burden put upon the banks.

Credit Underwriting Decisions - Decline

Some applicants get declined because their credit score is low or their credit history has some blemishes. Sometimes the applicant's income is too low or their debt load is already too high and it will be detrimental for them to take on additional credit.

When a decline reason is reached and by law and regulation, the bank must send out a Notice of Adverse Action letter. Some banks chose to send a piece of physical mail and some opt to send an email instead. 

No matter the case, the bank must communicate with their customers about their decline decision. There are a few compliance nuances we want to explore here. In the United States, there are a few regulations banks and lenders must follow when it comes to offering credit.

The first piece of law is called FCRA or Fair Credit Reporting Act, as part of this regulation, lenders and banks must tell the consumer that their credit has been requested and reviewed. If a decline in reason is rendered, the banks and lenders must tell the consumers not only they have been declined for credit, but they must tell the consumers the exact reasons why their credit has been declined.

It is up to the banks and lenders to provide the most important 3 or 4 reasons why this particular applicant’s request for credit has been declined. The decision engine and the scoring engine must determine the top reasons or attributes that let to the decline decision and properly communicate that back to the applicant.

The other piece of regulation is called ECOA or Equal Credit Opportunity Act. This act prohibits banks and lending institutions to discriminate against applicants based on a series of protected classes such as race, gender, agel, religion and national origin.

The bank and lenders must examine their identity and credit underwriting rules to make sure it's free of prejudice, intentionally introduced or inadvertently introduced.

The decision engine technically follows rules of its users but the company that offers credit decisioning services such as a decision engine and strategies should make these regulatory constraints known to their clients to prevent regulatory actions.

Credit Decision Engine 101

We hope you enjoyed another crash course from LendAPI on what a credit decision engine should be and what it can do to help you make accurate and timely decisions in the most efficient way. 

If you want to take a look at a visual decision engine tree builder. Feel free to cruise on over to our website at www.lendapi.com and click on sign up on the upper right hand coroner. It’s completely free and we are looking forward to your feedback as usual.

About LendAPI

LendAPI is a plug and play digital onboarding platform with a fully featured product designer, rules builder and a workflow orchestration platform that helps banks to launch their products within hours. For demos please visit www.lendapi.com and our youtube channel. Follow us on Linkedin and X.

Contact at LendAPI

Timothy Li, CEO, Co-Founder | Email: timothy.li@lendapi.com | Book a demo