Credit Decision Engine
Credit Decision Engine
Credit Decision Engine
The Power of Credit Decision Engine: A Comprehensive Guide
The Power of Credit Decision Engine: A Comprehensive Guide
Jan 29, 2024
Jan 29, 2024
Jan 29, 2024
Credit decision engine emerged in the past 20 years as a fundamental piece in the overall tech stack within banks, credit unions and financial institutions. With faster computing power and cloud services, calculating complex mathematical models becomes easier and more efficient. Today, FinTechs, Neo-Banks, tech enabled traditional banks are all embracing the need for fast and accurate decision engines. And credit decision engines are a specific breed of decision engine that have a few unique characteristics that we will talk about in this article.
The Power of Credit Decision Engines: A Comprehensive Guide
Credit decision engine emerged in the past 20 years as a fundamental piece in the overall tech stack within banks, credit unions and financial institutions. With faster computing power and cloud services, calculating complex mathematical models becomes easier and more efficient.
Today, FinTechs, Neo-Banks, tech enabled traditional banks are all embracing the need for fast and accurate decision engines. And credit decision engines are a specific breed of decision engine that have a few unique characteristics that we will talk about in this article.
Credit Decision: What is a credit decision engine?
There are several differences between a credit decision engine and other rules based decision engines. Credit decision engines are used to make financial decisions. It needs to run in real time and react to user interactions and connect to a variety of different datasets to make an accurate decision.
Banks and financial services institutions uses credit decisions engines frequently to make quick but important credit underwriting decisions.
Credit Decision Engine: Speed of execution.
The first unique characteristic of a credit decision engine is that of speed. Often, this special breed of decision engine needs to make millisecond decisions that comprehends hundreds of variables all at once. A not so time sensitive decision engine can run in batch mode and could return a decision within hours or days. The requirement of a credit decision engine is its speed. Consumers expect immediate approval decisions while shopping for certain things online and won’t wait for hours or days for a quick decision. The speed of a credit decision must be fast and also accurate.
Credit Decision Engine: First and third party data connectivity.
The second unique characteristic of a credit decision engine is that it needs to make a decision with first party data and third party data all at once.
First party data is data collected during an application process. For example, the end user's personal information such as social security number, phone number, email address, physical address.
Third party data is data sets typically coming from identity verification databases. These databases store millions of identity records and can match to the applicant's records within seconds. There are specific third party databases that verifies an applicant’s email and there are specialized third party databases that focus on mobile phone numbers.
There is no silver bullet or a one stop shop where banks and fintechs can connect to verify all aspects of a person’s identity all at once. A typical strategy is to verify different parts of a person’s identity with a few different third party data providers. To summarize the second unique nature of a credit decision engine is its ability to connect to all different types of third party data providers. A regular rules engine may only act on data supplied by the first party and nothing more. This is what makes credit decision engines special.
Credit Decision Engine: Variables, rules, models and more
Another unique feature of a credit decision engine is its ability to to execute econometric models that calculates the probability of fraud, or probability of repayment or most often probability of default.
These economic models are typically built by econometricians and statisticians that are trained to seek patterns within first and third party data to produce a probability model based on statistics. These models come in a variety of different flavors.
Some of these models are called scorecard models. The essence of these models are to collect points. For example, if a certain condition is detected from a person’s credit history, say a bankruptcy record, the scorecard model will add a weight or points to the person's overall score. And if the person’s overall score is higher than or lower than a certain threshold, the credit is then granted or declined. The scorecard model was widely used in the 1990s and 2000s but it lost its appeal to logistic regression models where more statistical rigor is applied.
Logistic regression came into prominence in the early 2000s when OCC or Office of Currency and Comptroller published underwriting model development guidelines for banks and large financial institutions to follow.
Banks proceed to hire a large group of mathematicians and statisticians to develop more sophisticated forecasting models, loss reserve models and account origination models. These models are statistically driven and trained on hundreds of variables and thousands of observations. Large relational databases are also becoming very popular and financial institutions were the first to collect and adopt massive databases that capture all aspects of their client’s transaction history and behavior.
This led to an explosive growth period of statistical financial modeling that became the norm of credit risk underwriting. Credit bureaus have caught on as well, some may argue that they have an even larger database of financial behavioral data.
Fair Isaac or the developer of FICO Score came into popularity as the gold standard of credit underwriting. Their models predict the likelihood of default after credit has been extended to an individual. Credit card companies, mortgage originators finally have a standard of measurement of all applicants applying for credit and no longer rely upon a human underwriter to adjudicate each and every application.
With probabilities scores, credit attributes being calculated, the usage of these scores give rise to credit decisions engine where credit scores and attributes are being ingested into the decision engine and credit underwriting rules are executed to perform critical underwriting decisions.
More sophisticated credit decision engines can compute these scores on the fly when given enough information. The golden age of credit decision engines finally began with high computing power, low computing cost, availability of data and computer programming languages that can calculate statistical probabilities in real time.
Credit Decision Engine: Enterprise ecosystem.
The last unique nature of a credit decision engine is its ability to connect with all parts of the customer experience and customer online journey. By the mid 2000s and early 2010s, mobile phone, internet connectivity and cloud computing has matured to a point where decision making and credit decision making are all made from a mobile device.
Consumers expect and demand credit decisions are made where they need them the most. Gone are the days of walking into a bank and speaking to a banker to request a personal loan or a line of credit. Consumers expect these credit decisions are made swiftly and therefore credit decisions engines must interact with all aspects of the customer journey.
If and when the credit decision is made, it’s up to the credit decision engine to extend the signal through API calls or Webhooks (common language amongst enterprise systems) to let the downstream enterprise system such as CRMs, Loan Management Systems, Credit Card systems and bank core systems such as Mambu, Jack Henry and various Fiserv offerings that powers banks.
Credit decision engine at its peak maturity should also communicate with end customers and users on various stages of an application journey. If an end user is being declined, a declination letter should be generated either through the decision engine itself or fire off a signal for the downstream enterprise systems to generate such as notification.
If an application is stuck and requires human intervention, the system should alert back office staff to log into an backend administrative portal and resolve the issue, rerun the application through the same decision tree or a different decision tree if possible.
These are just some examples of how a credit decision engine influences the applicant, back off staff, verification agents, fraud analysts and underwriting staff. A decent decision engine has the ability to pass signals to a variety of systems and has the ability to take in data and make further decisions.
Credit Decision Engine: Product assignment and pricing engine
One of the biggest differences between a credit decision engine and a regular decision engine or rules engine is that it must have a product decision engine. A product decision engine responsibility to set the term of the financial product being offered to the customer.
With respect to a bank account or DDA account opening process, depending on the need of the customer or the amount of deposit forecasted to go into the account, the decision engine’s product engine may offer different types of checking and savings accounts with different features. One may have higher interest payout than the other depending on the relationship the applicant is planning to have with the bank. These products are all programmed within the product engine and rules are also written to display a variety of different products being offered by the bank.
Lenders and financial institutions also need a product decision engine to set terms of the credit they are offering. Often, these terms of credit or a loan depended on the creditworthiness of the applicant based on their credit history and the ability to pay.
The credit decision engine will feed certain information into the product decision engine for further processing. For example, a product pricing matrix could be based on the applicant’s credit score and their debt to income ratio.
In a simplistic example, if the applicant’s credit score is high and their debt to income (DTI) ratio is low (good sign), then this particular applicant may get the best offer such as higher loan or credit amount and lower interest rate. Conversely, if the applicant has a low credit score and a high debt to income ratio, the system may offer a shorter term, lower loan amount and high interest rate to hedge against a higher probability of default.
The aforementioned decisions are always managed in a product decision engine. These decisions require multiple dimensions of consideration and it’s often after an approval decision is rendered in the credit decision engine.
If you are shopping for a credit decision engine, we recommend that you also take a look at its availability to further process the approval decision with a product decision engine. The decision engine platform should give you the ability to set product terms based on credit and income attributes. Say it differently, the decision engine must have a risk based pricing function attached to it, otherwise everyone that gets approved will essentially receive the same product, which could cause unnecessary credit defaults.
Credit Decision Engine: Historicals, versioning and A/B testing of decision sets.
Credit decision paths change from time to time. Banks and financial institutions study their customer behavior and adapt their underwriting criteria over time. The ability to make changes to underwriting rules, scoring models and product offerings becomes a competitive advantage for banks and lenders.
To make these changes, the credit decision engine must memorize all of the previous version of the rules and product assignments. In other words, each application should have the decision tree, product offering settings attached and permanently stored. And applications being passed through the newly modified decision trees will have the modified rules saved as part of the application.
In other words, each application should be linked to a version of the decision tree and product offerings at the time of application. A decision engine should not override the decision tree used in the past with the newly edited decision tree. It will cause a compliance nightmare.
The ability to version all of the previous decision trees is an absolutely must for a matured decision engine combined with a product engine. If your decision engine does not have this ability, we encourage you to work with your vendor to quickly implement a versioning process.
One of the best ways to test various strategies with your decision engine is to conduct A/B testing. A typical A/B testing will hold 90% of the population through the existing decision path, allowing a random 10% of the applicants to experience a different user journey and decision path. Risk and Product management professionals use this technique to test conversion rates, default rates and other customer behaviors.
The ability to conduct A/B testing within your decision tree is a significant feature that will allow your bank or financial institution to test into new territories and grow your business. For the decision tree to be able to conduct A/B testing, the system must be able to track history, versioning of your decision path and product assignment strategy.
Credit Decision Engine: The team behind it all.
We can’t emphasize more on the critical nature of a credit decision engine. Banking and financing is one of the most regulated industries and having a strong team behind one of the critical components of your business will give you a competitive advantage.
The decision engine itself should be clear, clean and intuitive. A messy interface or a convoluted variable library will cause confusion. A credit decision path should also be tested and double check the author’s work without having to bug engineers to run scripts and data through it.
The team behind a decision engine should have worked in the banking and financial services industry before and should be able to speak to regulatory nuances such as Adverse Action Notification Codes or a Fair Credit Reporting Act, if you are located in the United States.
The credit decision engine’s product decision engine should also have functionalities that stratify each State, if you operate within the United States and are regulated by your local state regulators.
Each State may have their own regulatory requirements when it comes to offering financial products and services. Some states may have restrictions on the amount of credit to be offered to their residents and interest rate caps that you must follow.
These regulations must be programmed into the product decision engine so customers arriving from their home State will be offered a regulated product to avoid any compliance penalties. A matured decision engine and a good team behind it should have all of these features laid out and carefully designed for users to input their regulatory requirements and state by state compliance documents and offer agreements.
Credit Decision Engine: Price vs. Value.
Pricing is one of the most important decision factors when choosing a decision engine vendor. In today’s cloud computing environment, computational costs are extremely efficient. Your decision engine should run in the cloud with multiple redundancy.
A well architected decision engine should be cost efficient. Typically there is a small baseline cost to maintain the servers and databases and a per transaction cost. These transaction costs could hamper your ability to grow into the outer years but we encourage you to shop around for cost but most importantly for value. Do these decision engines have all the basic features such as rule editor, third party integration, variable library, testing environment and compliance built in? Do they speak the same technical language as you and does the system have a wide range of API and Webhooks for connectivity and can their team help you to quickly launch your product?
Thank you for visiting us and if you have any questions or comments, please email us at info@lendapi.com and try our decision engine, free for 30 days at www.lendapi.com
Credit decision engine emerged in the past 20 years as a fundamental piece in the overall tech stack within banks, credit unions and financial institutions. With faster computing power and cloud services, calculating complex mathematical models becomes easier and more efficient. Today, FinTechs, Neo-Banks, tech enabled traditional banks are all embracing the need for fast and accurate decision engines. And credit decision engines are a specific breed of decision engine that have a few unique characteristics that we will talk about in this article.
The Power of Credit Decision Engines: A Comprehensive Guide
Credit decision engine emerged in the past 20 years as a fundamental piece in the overall tech stack within banks, credit unions and financial institutions. With faster computing power and cloud services, calculating complex mathematical models becomes easier and more efficient.
Today, FinTechs, Neo-Banks, tech enabled traditional banks are all embracing the need for fast and accurate decision engines. And credit decision engines are a specific breed of decision engine that have a few unique characteristics that we will talk about in this article.
Credit Decision: What is a credit decision engine?
There are several differences between a credit decision engine and other rules based decision engines. Credit decision engines are used to make financial decisions. It needs to run in real time and react to user interactions and connect to a variety of different datasets to make an accurate decision.
Banks and financial services institutions uses credit decisions engines frequently to make quick but important credit underwriting decisions.
Credit Decision Engine: Speed of execution.
The first unique characteristic of a credit decision engine is that of speed. Often, this special breed of decision engine needs to make millisecond decisions that comprehends hundreds of variables all at once. A not so time sensitive decision engine can run in batch mode and could return a decision within hours or days. The requirement of a credit decision engine is its speed. Consumers expect immediate approval decisions while shopping for certain things online and won’t wait for hours or days for a quick decision. The speed of a credit decision must be fast and also accurate.
Credit Decision Engine: First and third party data connectivity.
The second unique characteristic of a credit decision engine is that it needs to make a decision with first party data and third party data all at once.
First party data is data collected during an application process. For example, the end user's personal information such as social security number, phone number, email address, physical address.
Third party data is data sets typically coming from identity verification databases. These databases store millions of identity records and can match to the applicant's records within seconds. There are specific third party databases that verifies an applicant’s email and there are specialized third party databases that focus on mobile phone numbers.
There is no silver bullet or a one stop shop where banks and fintechs can connect to verify all aspects of a person’s identity all at once. A typical strategy is to verify different parts of a person’s identity with a few different third party data providers. To summarize the second unique nature of a credit decision engine is its ability to connect to all different types of third party data providers. A regular rules engine may only act on data supplied by the first party and nothing more. This is what makes credit decision engines special.
Credit Decision Engine: Variables, rules, models and more
Another unique feature of a credit decision engine is its ability to to execute econometric models that calculates the probability of fraud, or probability of repayment or most often probability of default.
These economic models are typically built by econometricians and statisticians that are trained to seek patterns within first and third party data to produce a probability model based on statistics. These models come in a variety of different flavors.
Some of these models are called scorecard models. The essence of these models are to collect points. For example, if a certain condition is detected from a person’s credit history, say a bankruptcy record, the scorecard model will add a weight or points to the person's overall score. And if the person’s overall score is higher than or lower than a certain threshold, the credit is then granted or declined. The scorecard model was widely used in the 1990s and 2000s but it lost its appeal to logistic regression models where more statistical rigor is applied.
Logistic regression came into prominence in the early 2000s when OCC or Office of Currency and Comptroller published underwriting model development guidelines for banks and large financial institutions to follow.
Banks proceed to hire a large group of mathematicians and statisticians to develop more sophisticated forecasting models, loss reserve models and account origination models. These models are statistically driven and trained on hundreds of variables and thousands of observations. Large relational databases are also becoming very popular and financial institutions were the first to collect and adopt massive databases that capture all aspects of their client’s transaction history and behavior.
This led to an explosive growth period of statistical financial modeling that became the norm of credit risk underwriting. Credit bureaus have caught on as well, some may argue that they have an even larger database of financial behavioral data.
Fair Isaac or the developer of FICO Score came into popularity as the gold standard of credit underwriting. Their models predict the likelihood of default after credit has been extended to an individual. Credit card companies, mortgage originators finally have a standard of measurement of all applicants applying for credit and no longer rely upon a human underwriter to adjudicate each and every application.
With probabilities scores, credit attributes being calculated, the usage of these scores give rise to credit decisions engine where credit scores and attributes are being ingested into the decision engine and credit underwriting rules are executed to perform critical underwriting decisions.
More sophisticated credit decision engines can compute these scores on the fly when given enough information. The golden age of credit decision engines finally began with high computing power, low computing cost, availability of data and computer programming languages that can calculate statistical probabilities in real time.
Credit Decision Engine: Enterprise ecosystem.
The last unique nature of a credit decision engine is its ability to connect with all parts of the customer experience and customer online journey. By the mid 2000s and early 2010s, mobile phone, internet connectivity and cloud computing has matured to a point where decision making and credit decision making are all made from a mobile device.
Consumers expect and demand credit decisions are made where they need them the most. Gone are the days of walking into a bank and speaking to a banker to request a personal loan or a line of credit. Consumers expect these credit decisions are made swiftly and therefore credit decisions engines must interact with all aspects of the customer journey.
If and when the credit decision is made, it’s up to the credit decision engine to extend the signal through API calls or Webhooks (common language amongst enterprise systems) to let the downstream enterprise system such as CRMs, Loan Management Systems, Credit Card systems and bank core systems such as Mambu, Jack Henry and various Fiserv offerings that powers banks.
Credit decision engine at its peak maturity should also communicate with end customers and users on various stages of an application journey. If an end user is being declined, a declination letter should be generated either through the decision engine itself or fire off a signal for the downstream enterprise systems to generate such as notification.
If an application is stuck and requires human intervention, the system should alert back office staff to log into an backend administrative portal and resolve the issue, rerun the application through the same decision tree or a different decision tree if possible.
These are just some examples of how a credit decision engine influences the applicant, back off staff, verification agents, fraud analysts and underwriting staff. A decent decision engine has the ability to pass signals to a variety of systems and has the ability to take in data and make further decisions.
Credit Decision Engine: Product assignment and pricing engine
One of the biggest differences between a credit decision engine and a regular decision engine or rules engine is that it must have a product decision engine. A product decision engine responsibility to set the term of the financial product being offered to the customer.
With respect to a bank account or DDA account opening process, depending on the need of the customer or the amount of deposit forecasted to go into the account, the decision engine’s product engine may offer different types of checking and savings accounts with different features. One may have higher interest payout than the other depending on the relationship the applicant is planning to have with the bank. These products are all programmed within the product engine and rules are also written to display a variety of different products being offered by the bank.
Lenders and financial institutions also need a product decision engine to set terms of the credit they are offering. Often, these terms of credit or a loan depended on the creditworthiness of the applicant based on their credit history and the ability to pay.
The credit decision engine will feed certain information into the product decision engine for further processing. For example, a product pricing matrix could be based on the applicant’s credit score and their debt to income ratio.
In a simplistic example, if the applicant’s credit score is high and their debt to income (DTI) ratio is low (good sign), then this particular applicant may get the best offer such as higher loan or credit amount and lower interest rate. Conversely, if the applicant has a low credit score and a high debt to income ratio, the system may offer a shorter term, lower loan amount and high interest rate to hedge against a higher probability of default.
The aforementioned decisions are always managed in a product decision engine. These decisions require multiple dimensions of consideration and it’s often after an approval decision is rendered in the credit decision engine.
If you are shopping for a credit decision engine, we recommend that you also take a look at its availability to further process the approval decision with a product decision engine. The decision engine platform should give you the ability to set product terms based on credit and income attributes. Say it differently, the decision engine must have a risk based pricing function attached to it, otherwise everyone that gets approved will essentially receive the same product, which could cause unnecessary credit defaults.
Credit Decision Engine: Historicals, versioning and A/B testing of decision sets.
Credit decision paths change from time to time. Banks and financial institutions study their customer behavior and adapt their underwriting criteria over time. The ability to make changes to underwriting rules, scoring models and product offerings becomes a competitive advantage for banks and lenders.
To make these changes, the credit decision engine must memorize all of the previous version of the rules and product assignments. In other words, each application should have the decision tree, product offering settings attached and permanently stored. And applications being passed through the newly modified decision trees will have the modified rules saved as part of the application.
In other words, each application should be linked to a version of the decision tree and product offerings at the time of application. A decision engine should not override the decision tree used in the past with the newly edited decision tree. It will cause a compliance nightmare.
The ability to version all of the previous decision trees is an absolutely must for a matured decision engine combined with a product engine. If your decision engine does not have this ability, we encourage you to work with your vendor to quickly implement a versioning process.
One of the best ways to test various strategies with your decision engine is to conduct A/B testing. A typical A/B testing will hold 90% of the population through the existing decision path, allowing a random 10% of the applicants to experience a different user journey and decision path. Risk and Product management professionals use this technique to test conversion rates, default rates and other customer behaviors.
The ability to conduct A/B testing within your decision tree is a significant feature that will allow your bank or financial institution to test into new territories and grow your business. For the decision tree to be able to conduct A/B testing, the system must be able to track history, versioning of your decision path and product assignment strategy.
Credit Decision Engine: The team behind it all.
We can’t emphasize more on the critical nature of a credit decision engine. Banking and financing is one of the most regulated industries and having a strong team behind one of the critical components of your business will give you a competitive advantage.
The decision engine itself should be clear, clean and intuitive. A messy interface or a convoluted variable library will cause confusion. A credit decision path should also be tested and double check the author’s work without having to bug engineers to run scripts and data through it.
The team behind a decision engine should have worked in the banking and financial services industry before and should be able to speak to regulatory nuances such as Adverse Action Notification Codes or a Fair Credit Reporting Act, if you are located in the United States.
The credit decision engine’s product decision engine should also have functionalities that stratify each State, if you operate within the United States and are regulated by your local state regulators.
Each State may have their own regulatory requirements when it comes to offering financial products and services. Some states may have restrictions on the amount of credit to be offered to their residents and interest rate caps that you must follow.
These regulations must be programmed into the product decision engine so customers arriving from their home State will be offered a regulated product to avoid any compliance penalties. A matured decision engine and a good team behind it should have all of these features laid out and carefully designed for users to input their regulatory requirements and state by state compliance documents and offer agreements.
Credit Decision Engine: Price vs. Value.
Pricing is one of the most important decision factors when choosing a decision engine vendor. In today’s cloud computing environment, computational costs are extremely efficient. Your decision engine should run in the cloud with multiple redundancy.
A well architected decision engine should be cost efficient. Typically there is a small baseline cost to maintain the servers and databases and a per transaction cost. These transaction costs could hamper your ability to grow into the outer years but we encourage you to shop around for cost but most importantly for value. Do these decision engines have all the basic features such as rule editor, third party integration, variable library, testing environment and compliance built in? Do they speak the same technical language as you and does the system have a wide range of API and Webhooks for connectivity and can their team help you to quickly launch your product?
Thank you for visiting us and if you have any questions or comments, please email us at info@lendapi.com and try our decision engine, free for 30 days at www.lendapi.com
Credit decision engine emerged in the past 20 years as a fundamental piece in the overall tech stack within banks, credit unions and financial institutions. With faster computing power and cloud services, calculating complex mathematical models becomes easier and more efficient. Today, FinTechs, Neo-Banks, tech enabled traditional banks are all embracing the need for fast and accurate decision engines. And credit decision engines are a specific breed of decision engine that have a few unique characteristics that we will talk about in this article.
The Power of Credit Decision Engines: A Comprehensive Guide
Credit decision engine emerged in the past 20 years as a fundamental piece in the overall tech stack within banks, credit unions and financial institutions. With faster computing power and cloud services, calculating complex mathematical models becomes easier and more efficient.
Today, FinTechs, Neo-Banks, tech enabled traditional banks are all embracing the need for fast and accurate decision engines. And credit decision engines are a specific breed of decision engine that have a few unique characteristics that we will talk about in this article.
Credit Decision: What is a credit decision engine?
There are several differences between a credit decision engine and other rules based decision engines. Credit decision engines are used to make financial decisions. It needs to run in real time and react to user interactions and connect to a variety of different datasets to make an accurate decision.
Banks and financial services institutions uses credit decisions engines frequently to make quick but important credit underwriting decisions.
Credit Decision Engine: Speed of execution.
The first unique characteristic of a credit decision engine is that of speed. Often, this special breed of decision engine needs to make millisecond decisions that comprehends hundreds of variables all at once. A not so time sensitive decision engine can run in batch mode and could return a decision within hours or days. The requirement of a credit decision engine is its speed. Consumers expect immediate approval decisions while shopping for certain things online and won’t wait for hours or days for a quick decision. The speed of a credit decision must be fast and also accurate.
Credit Decision Engine: First and third party data connectivity.
The second unique characteristic of a credit decision engine is that it needs to make a decision with first party data and third party data all at once.
First party data is data collected during an application process. For example, the end user's personal information such as social security number, phone number, email address, physical address.
Third party data is data sets typically coming from identity verification databases. These databases store millions of identity records and can match to the applicant's records within seconds. There are specific third party databases that verifies an applicant’s email and there are specialized third party databases that focus on mobile phone numbers.
There is no silver bullet or a one stop shop where banks and fintechs can connect to verify all aspects of a person’s identity all at once. A typical strategy is to verify different parts of a person’s identity with a few different third party data providers. To summarize the second unique nature of a credit decision engine is its ability to connect to all different types of third party data providers. A regular rules engine may only act on data supplied by the first party and nothing more. This is what makes credit decision engines special.
Credit Decision Engine: Variables, rules, models and more
Another unique feature of a credit decision engine is its ability to to execute econometric models that calculates the probability of fraud, or probability of repayment or most often probability of default.
These economic models are typically built by econometricians and statisticians that are trained to seek patterns within first and third party data to produce a probability model based on statistics. These models come in a variety of different flavors.
Some of these models are called scorecard models. The essence of these models are to collect points. For example, if a certain condition is detected from a person’s credit history, say a bankruptcy record, the scorecard model will add a weight or points to the person's overall score. And if the person’s overall score is higher than or lower than a certain threshold, the credit is then granted or declined. The scorecard model was widely used in the 1990s and 2000s but it lost its appeal to logistic regression models where more statistical rigor is applied.
Logistic regression came into prominence in the early 2000s when OCC or Office of Currency and Comptroller published underwriting model development guidelines for banks and large financial institutions to follow.
Banks proceed to hire a large group of mathematicians and statisticians to develop more sophisticated forecasting models, loss reserve models and account origination models. These models are statistically driven and trained on hundreds of variables and thousands of observations. Large relational databases are also becoming very popular and financial institutions were the first to collect and adopt massive databases that capture all aspects of their client’s transaction history and behavior.
This led to an explosive growth period of statistical financial modeling that became the norm of credit risk underwriting. Credit bureaus have caught on as well, some may argue that they have an even larger database of financial behavioral data.
Fair Isaac or the developer of FICO Score came into popularity as the gold standard of credit underwriting. Their models predict the likelihood of default after credit has been extended to an individual. Credit card companies, mortgage originators finally have a standard of measurement of all applicants applying for credit and no longer rely upon a human underwriter to adjudicate each and every application.
With probabilities scores, credit attributes being calculated, the usage of these scores give rise to credit decisions engine where credit scores and attributes are being ingested into the decision engine and credit underwriting rules are executed to perform critical underwriting decisions.
More sophisticated credit decision engines can compute these scores on the fly when given enough information. The golden age of credit decision engines finally began with high computing power, low computing cost, availability of data and computer programming languages that can calculate statistical probabilities in real time.
Credit Decision Engine: Enterprise ecosystem.
The last unique nature of a credit decision engine is its ability to connect with all parts of the customer experience and customer online journey. By the mid 2000s and early 2010s, mobile phone, internet connectivity and cloud computing has matured to a point where decision making and credit decision making are all made from a mobile device.
Consumers expect and demand credit decisions are made where they need them the most. Gone are the days of walking into a bank and speaking to a banker to request a personal loan or a line of credit. Consumers expect these credit decisions are made swiftly and therefore credit decisions engines must interact with all aspects of the customer journey.
If and when the credit decision is made, it’s up to the credit decision engine to extend the signal through API calls or Webhooks (common language amongst enterprise systems) to let the downstream enterprise system such as CRMs, Loan Management Systems, Credit Card systems and bank core systems such as Mambu, Jack Henry and various Fiserv offerings that powers banks.
Credit decision engine at its peak maturity should also communicate with end customers and users on various stages of an application journey. If an end user is being declined, a declination letter should be generated either through the decision engine itself or fire off a signal for the downstream enterprise systems to generate such as notification.
If an application is stuck and requires human intervention, the system should alert back office staff to log into an backend administrative portal and resolve the issue, rerun the application through the same decision tree or a different decision tree if possible.
These are just some examples of how a credit decision engine influences the applicant, back off staff, verification agents, fraud analysts and underwriting staff. A decent decision engine has the ability to pass signals to a variety of systems and has the ability to take in data and make further decisions.
Credit Decision Engine: Product assignment and pricing engine
One of the biggest differences between a credit decision engine and a regular decision engine or rules engine is that it must have a product decision engine. A product decision engine responsibility to set the term of the financial product being offered to the customer.
With respect to a bank account or DDA account opening process, depending on the need of the customer or the amount of deposit forecasted to go into the account, the decision engine’s product engine may offer different types of checking and savings accounts with different features. One may have higher interest payout than the other depending on the relationship the applicant is planning to have with the bank. These products are all programmed within the product engine and rules are also written to display a variety of different products being offered by the bank.
Lenders and financial institutions also need a product decision engine to set terms of the credit they are offering. Often, these terms of credit or a loan depended on the creditworthiness of the applicant based on their credit history and the ability to pay.
The credit decision engine will feed certain information into the product decision engine for further processing. For example, a product pricing matrix could be based on the applicant’s credit score and their debt to income ratio.
In a simplistic example, if the applicant’s credit score is high and their debt to income (DTI) ratio is low (good sign), then this particular applicant may get the best offer such as higher loan or credit amount and lower interest rate. Conversely, if the applicant has a low credit score and a high debt to income ratio, the system may offer a shorter term, lower loan amount and high interest rate to hedge against a higher probability of default.
The aforementioned decisions are always managed in a product decision engine. These decisions require multiple dimensions of consideration and it’s often after an approval decision is rendered in the credit decision engine.
If you are shopping for a credit decision engine, we recommend that you also take a look at its availability to further process the approval decision with a product decision engine. The decision engine platform should give you the ability to set product terms based on credit and income attributes. Say it differently, the decision engine must have a risk based pricing function attached to it, otherwise everyone that gets approved will essentially receive the same product, which could cause unnecessary credit defaults.
Credit Decision Engine: Historicals, versioning and A/B testing of decision sets.
Credit decision paths change from time to time. Banks and financial institutions study their customer behavior and adapt their underwriting criteria over time. The ability to make changes to underwriting rules, scoring models and product offerings becomes a competitive advantage for banks and lenders.
To make these changes, the credit decision engine must memorize all of the previous version of the rules and product assignments. In other words, each application should have the decision tree, product offering settings attached and permanently stored. And applications being passed through the newly modified decision trees will have the modified rules saved as part of the application.
In other words, each application should be linked to a version of the decision tree and product offerings at the time of application. A decision engine should not override the decision tree used in the past with the newly edited decision tree. It will cause a compliance nightmare.
The ability to version all of the previous decision trees is an absolutely must for a matured decision engine combined with a product engine. If your decision engine does not have this ability, we encourage you to work with your vendor to quickly implement a versioning process.
One of the best ways to test various strategies with your decision engine is to conduct A/B testing. A typical A/B testing will hold 90% of the population through the existing decision path, allowing a random 10% of the applicants to experience a different user journey and decision path. Risk and Product management professionals use this technique to test conversion rates, default rates and other customer behaviors.
The ability to conduct A/B testing within your decision tree is a significant feature that will allow your bank or financial institution to test into new territories and grow your business. For the decision tree to be able to conduct A/B testing, the system must be able to track history, versioning of your decision path and product assignment strategy.
Credit Decision Engine: The team behind it all.
We can’t emphasize more on the critical nature of a credit decision engine. Banking and financing is one of the most regulated industries and having a strong team behind one of the critical components of your business will give you a competitive advantage.
The decision engine itself should be clear, clean and intuitive. A messy interface or a convoluted variable library will cause confusion. A credit decision path should also be tested and double check the author’s work without having to bug engineers to run scripts and data through it.
The team behind a decision engine should have worked in the banking and financial services industry before and should be able to speak to regulatory nuances such as Adverse Action Notification Codes or a Fair Credit Reporting Act, if you are located in the United States.
The credit decision engine’s product decision engine should also have functionalities that stratify each State, if you operate within the United States and are regulated by your local state regulators.
Each State may have their own regulatory requirements when it comes to offering financial products and services. Some states may have restrictions on the amount of credit to be offered to their residents and interest rate caps that you must follow.
These regulations must be programmed into the product decision engine so customers arriving from their home State will be offered a regulated product to avoid any compliance penalties. A matured decision engine and a good team behind it should have all of these features laid out and carefully designed for users to input their regulatory requirements and state by state compliance documents and offer agreements.
Credit Decision Engine: Price vs. Value.
Pricing is one of the most important decision factors when choosing a decision engine vendor. In today’s cloud computing environment, computational costs are extremely efficient. Your decision engine should run in the cloud with multiple redundancy.
A well architected decision engine should be cost efficient. Typically there is a small baseline cost to maintain the servers and databases and a per transaction cost. These transaction costs could hamper your ability to grow into the outer years but we encourage you to shop around for cost but most importantly for value. Do these decision engines have all the basic features such as rule editor, third party integration, variable library, testing environment and compliance built in? Do they speak the same technical language as you and does the system have a wide range of API and Webhooks for connectivity and can their team help you to quickly launch your product?
Thank you for visiting us and if you have any questions or comments, please email us at info@lendapi.com and try our decision engine, free for 30 days at www.lendapi.com