Credit Decision Engine Unveiled: Exploring the Architecture Behind Smart Financial Decisions

Credit Decision Engines are a special breed of rule based decisioning system that helps financial services companies to make smarter and quicker decisions. So what gives the rise of credit decision engines and what’s really going on behind the scenes of a robust credit decision engine system? Today we will explore these topics

Credit Decision Engine: Database architecture

With any solid enterprise systems, credit decision engines must come equipped with a solid relational database architecture for speed and accuracy. A relational database is a referential database design that brings together personal information from the applicants as well as third party data such as credit bureau information in one cohesive view which business rules can be executed upon.

For example, an applicant submitted all of her information through an online digital application. The credit decision engine will need to pull in datasets from a variety of data sources such as identity verification bureaus and credit verification bureaus. All of this additional information needs to be fused with the applicant’s data. Once all of these bits of information are gathered, the decision engine will then execute rules based on the data merged together. For instance, if a person’s credit score is of a certain value and her identity score is of a certain value, then the credit decision will approve this applicant and have her move to the next stage of the credit decisioning process.

The credit decisioning database architecture should remain open to merge other datasets in the future. The digital customer journey sometimes is broken up in different stages and additional information may come to light and need to be merged together with datasets uncovered earlier in the customer journey. Once additional information is merged with the previous dataset, additional rules can be applied and move the applicant even further downstream as part of the overall underwriting process.

Credit Decision Engine: Key ingredients 

We talked to many risk management professionals and to them, writing a comprehensive set of underwriting guidelines or rules is akin to cooking with a well thought out recipe. To make a dish, the chef must have all of the ingredients prepared and ready to go. 

We can’t afford to hunt for key ingredients while the rest of the materials are frying in a hot pan. These conventions apply to credit rule management as well. So what are some of these key ingredients?

One of the key elements of a rule engine is the variables themselves. A fantastic example of a variable is the FICO score. FICO score is probably the most recognizable credit score in the United States. Every working adult in America probably knows his or her credit score.

A typical credit underwriting rule is to test whether the applicant’s FICO score falls into a certain range. So where do we get this FICO score from? All of the major credit bureaus are working with Fair Iassac, the author of this fICO score to calculate these scores for just about everyone of age in America. 

A robust credit risk engine should be able to pull this information from any major credit bureaus for each specific credit applicant. The credit decision engine should save this information into his relational database and surface this element or ingredient for the risk manager to write a rule similar to what’s mentioned above.

There are thousands of these elements, ingredients or in other words credit attributes of an applicant that can be pulled and stored into the credit decisioning engine’s backend database. A good decision engine must have the ability to completely store all of the raw ingredients and prepare them for risk management professionals to write rules.

Sometimes, risk management staff might be required to build special attributes or custom attributes by using mathematical operations to manipulate existing variables or combine two or more attributes in some shape of fashion.

Advanced credit decision engines should also have the ability to give risk managers a way to compute additional attributes based on the information retrieved from the applicants and from third party data providers. These custom variables and the ability to make them is a competitive advantage for banks and lenders by making more sophisticated credit decisions.

Credit Decision Engine: Writing business rules

Gone are the days of writing computer programming codes to implement rules. Modern credit decision engines are equipped with visual rule editors that are easy to use and intuitive. Risk management professionals can operate independently of massive engineering teams catering to their needs.

A rules engineer, risk analyst can easily write rules, test them and implement them in real time to influence risk management decisions without having to rely on engineering resources to help them gather necessary information to edit existing rules or write additional rules based on new data assets.

A rules editor should display the decision trees to the risk managers. It should have a view of all of the decision nodes of each tree branch. The end nodes or decision nodes should carry our a certain action. For example, at the end of a if-then-else statement, the final node of a decision path should be an approval, decline or review decisions. An approval decision could trigger a congratulatory email to the applicant and if she is interacting with the bank on a web application, the web page should also be triggered by the credit decision engine to display a congratulatory message to display the product she was approved for.

The rules and the actions or outcomes of the rules should be configurable and displayed accurately to the risk managers; she can visually examine all of the branches of a ruleset.

Credit Decision Engine: Testing the rulesets

One of the most difficult tasks of the older generation of decision engines is that it’s impossible for the rules engineers to conduct testing. Once the rules are programmed into place, it will require a whole other engineering team to send data through the credit decision engine randomly and hoping for a desirable outcome.

Testing becomes a nightmare when the engineering team has little knowledge of risk management concepts and the random datasets jammed through the decision engine makes very little sense and often renders a decline decision. This leads to programmers and risk managers second guessing whether the decision engine is malfunctioning or if the rules are ill written or the testing dataset is not well constructed. This leads to months of delays and causes many product launch failures.

A well written rules editor should also come equipped with visual testing modules where risk managers themselves can enter values and trigger the decision engine to run through all the tests and visually display whether the rule sets were passed, failed and the appropriate actions and outcomes are triggers.

With a robust testing framework, risk management professionals will gain confidence in the rules constructed and implemented in real time without asking another engineering team to test and cause endless delays.

Credit Decision Engine: Essential workflow management

Most of the time, the credit application examined by an automated decision engine has some ambiguities. These ambiguities could be an unverified identity or unusual credit reporting history. These outliers may trigger a manual review by a fraud analyst or a credit underwriter.

The credit decision engine should have a complex workflow system to allow credit underwriters and fraud analysts to login and review these applications that need some manual intervention.

There are several scenarios that we can study here. For instance, a newly arrived immigrant applying for her first credit card and because of her status, most of the identity bureaus contain little or no record of this individual.

The decision engine should have rules built in to flag this application for further review. The outcome or action programmed within the decision engine could put this applicant into a “Review” queue and at the same time, an email should goto the applicant and ask her to upload additional identity verification documents such as her driver's licenses or passport.

And when the applicant has uploaded the needed documents, the back office personnel should be alerted and log into the workflow portal to review and approve or reject the document and therefore the application. If all the documents are verified, the back office personnel should manually approve or move the applicant to the next stage with the credit decision workflow.

This critical interaction between the decision engine, the third party data provider, the applicant and the back office personnel is essential to a modern decision making process and a modern decision engine.

Credit Decision Engine: Connecting to all other aspects of banking system

Credit decision engine is taking on an even more important role in today’s fintech ecosystem. It is no longer a stand alone piece of software where data is force fed into it and the resulting output is interpreted.

We expect our decision engines to utilize APIs and Webhook services to interact with other enterprise systems in a more deep and meaningful way. For instance, when an application is being adjudicated in a credit decision system, application statuses should be communicated to other customer relationship management systems. Certain emails, text messages could be triggered based on these deeper interactions between decision engines and other enterprise systems. 

Most importantly, when an applicant is finally approved, signals should be sent to either a credit card system to retrieve credit card numbers to generate virtual cards before a physical card is mailed to the client or the same signal could be sent to a core banking system to onboard the applicant into a checking or savings account. Lastly, the same integration could be done with loan management systems to disburse loan proceeds and collect loan repayments.

We come to expect the credit decision engine as the heart and soul of a complete financial technical stack and it should be equipped with deep integration with other customer facing systems and should not be isolated from the rest of the organization.