What is a Do-it-Yourself Decision Engine?

A DIY or Do-it-Yourself decision engine is a software that consists of a graphical interface where anyone with any level of expertise can easily program rules and trigger events based on the results from a rule execution.

Behind the user interface and user interaction, there should be databases, mathematical engines that executes the intent of the rules set by the user.

Lastly, the decision engine must be able to take necessary input from the user to exercise the rules as well as meaningful outputs for users and other enterprise systems to analyze the results from all the rules and their interactions. 

Key Components of a Do-it-Yourself Decision Engine: First Party Information

As part of the preparation before writing your first rule, you must have some data to be staged as decision variables. Most of the time, there is a template, form or a mobile app that takes some information about the applicant.

For instance, the customer's name, address, date of birth, social security number or some sort of identification number might be taken into account from the intake form.

This information is either passed into the decision engine via an API or the decision engine can mimic some of these variables and generate a simple test template for the rules administrator to enter some dummy data to simply write and test the rules.

A simple rule which can be written based on first party information could be “If Age > 18 Years of Age, then (approve/decline)”. A DIY decision engine should provide a graphical user interface for rule administrators to drag and drop variables and define mathematical operations such as “>” without having to write any code. The rules studio will also display the progress of rule building to the rule administrator and show them the progress of their work.

The first party data form the end applicant will also be used to inquire against other third party databases to gather more information.

Key Components of a Do-it-Yourself Decision Engine: Third Party Information

In most cases, when a decision engine is deployed in a financial institution such as a bank, a number of third party data sources need to be called to complete a set of decisions surrounding identity and credit worthiness, and sometimes verifying income and employment.   

There are over 100+ identity bureaus, credit bureaus, income and risk model providers  in North America. To support a true DIY decision engine, the backend of the decision engine must be able or have already connected to all of these third party data providers.

In addition, if this decision engine is connected to all the main third party data providers, the variables from these third parties must be made available into a variable library for rules engineering and rules authors to pick and choose from.

If you are picking a rules engine, you must look at the speed at which these decision engines are able to integrate with third party data providers.

There are some special types of third party data providers such as Plaid, Truv that require a person to log into their bank account or payroll account to extract data from other sources to pipe it back into the decision engine. A DIY decision engine must be able to give the rules engineer a way to launch the end user experience and type in their banking or payroll credentials in a test environment to extract data from test environments to populate the variable library. 

Key Components of a Do-it-Yourself Decision Engine: Variable Derivations, Derived Variables or Enriched Variables.

Sometimes first party and third party variables as they are won’t be enough to do complex rule writing. For example, if you wish to create a debt to income ratio variable, you might need to combine data from the first party as well as from the third party.

You might need to gather income information from your first party API or intake form and use all of the debt repayment data from a variety of credit bureaus to calculate a debt to income ratio variable to be used in your underwriting rule setting or your pricing algorithm.

A true DIY Decision Engine will need to have a Variable Studio of sorts to let rules engineers or authors to create additional variables based on any other variables with ample mathematical operations to create variables such as a Debt to Income ratio variable. 

In addition, sometimes, you might need to create dummy variables just to test out some rules. The DIY decision engine should be able to also allow end users such as rule engineers to create any type of form variables, derived variables or variables that can be used explicitly in pricing strategies.

A robust variable builder is essential to provide the maximum flexibility for the rules engineers to create any number of rules without the need of coding or engineering support.

Key Components of a Do-it-Yourself Decision Engine: Decision Interfaces

There are a few kinds of decision interfaces. When a decision is made through a decision tree, signals must be sent downstream to other enterprise systems as well as the applicants themselves.

The End Node of each decision tree branch must communicate with the result of the said decision to something or someone. A DIY decision engine must be able to let the rule engineers to set Actions or Outcomes that triggers Emails, Text Messages and API/Webhook calls to applicants and other downstream enterprise systems such as Bank Core or Loan Management Systems.

The rules engineer must be able to graphical assign each End Node to an appropriate action. Whether it is to send out an email with Adverse Actions or send the approved loan packet to PortX or FIS or the world, this must be a key component of any DIY decision engine.

PortX, FIS and other Bank Cores such as LoanPro, Thought Machine, Mambu are essential to complete the decision cycle of a DIY decision engine. When an application passes all of the underwriting criteria with a pricing strategy assigned and upon the acceptance of the offer, a signal is then sent to these Card Cores, Loan Cores and Bank Cores.

These “Cores” are essentially taking on the role of servicing loans, credit cards and other forms of financing products. Is the DIY decision engine done its job after passing the application to these core systems? Yes and No, sometimes these core systems will call back to the decision engine and make some secondary decisions such as line increase/decrease strategies for credit cards as well as refinancing on an existing loan that’s still in repayment status.

There’s endless possibilities for a DIY decision engine to operate between the applications and the servicing systems. But most importantly, the decisioning software must be able to connect and transmit key information back and forth with speed.

DIY Decision Engine - Speed Demon

Speed of execution is paramount when it comes to our banking clients that process upward of 1 million applications a day. There are three areas of speed that we want to address.

The first part of speed consideration is pure code level execution. The raw performance of the code is essential, C, C++, Go, Rust and Python are some of the fastest raw performing programming languages in terms of raw speed.

Firms that build high performance decision engines also need to balance available talent with respect to raw speed. Python is one of the most popular languages used today for a variety of applications and it’s one of the many choices of high speed software application performance.

The second part of speed consideration is the speed which the decision engine connects to all third parties. Sometimes the third party data providers don't provide an instant response and the decision engine needs to call a webhook to retrieve data asynchronously. The company behind these decision engines must be familiar with the industry and the use cases of various third party data providers at various stages of the decision process.

Most of the banks need a response within a second or so, so there’s not much room to buffer the round trip payload time waiting for data to come back into the decision engine. The milli-seconds of time allocated for third party calls as well as rule execution need to be optimized to produce the quickest response time.  

DIY Decision Engine - Parallel Processing

A high performance decision engine needs to process hundreds of thousands of applications per seconds. The infrastructure is of paramount importance. Most cloud infrastructure offers infrastructure which scales according to the software’s resource requirements. However, nothing compares to optimized code that can work on any decent infrastructure without operating on expensive hardware. 

Users of these decision engines must be able to stress test the system to process simultaneous applications that access a variety of different third party integration partners with different rules sets and score compositions.

DIY Decision Engine - Cache is King

To further speed up a response from a decision engine, caching of third party data becomes important especially when the bank experiences a high volume of applications. And these leads come from a variety of different sources that may have duplicates.

In other words, a potential client may have been redirected to the bank’s website from a few different marketing channels. These marketing channels could be completely different and under different brands. 

The applicant may think that she is applying for financial products through a few different brands but these applications may all end up at the same place. A decent decision engine with caching capabilities will scan through previous historical records, say within the last 30 days and use the cached data or cached decision to return the same decision. 

The reason is that a person’s credit worthiness may not have changed dramatically over the past few weeks and it’s not important for the bank to re-pull this applicants credit and spend unnecessary data cost as well as hamper the applicant’s credit by inquiring this applicant’s credit report multiple times within a short period of time.

Do-It-Yourself Credit Engine 

DIY and No-Code solutions are becoming increasingly popular and the ability to let credit risk managers to build rules, pricing strategies without any engineering help will save cost and speed up implementation for mission critical credit products.

The ability to quickly build and rebuild rules and test them is a competitive advantage that banks will surely leverage to maximize their approval rates and calibrate their products to generate maximum acceptance rate by their applicants.

The ability to build, test, run rules with third party integrations and the ability to build variables and direct decision actions to communicate with applicants and other enterprise systems is the way of the future. 

About LendAPI

LendAPI is the only digital onboarding platform for banks with a suite of Product, Pricing and Rules Studio working in concert all in one platform. Follow us on Blog, Linkedin, X, YouTube.