What are the building blocks of a stellar credit underwriting project?

Credit underwriters are tasked with designing workflows to reflect their underwriting methodology - with the ultimate goal of identifying and hedging any risk. But the transition from a concept to a fully functioning credit underwriting system is not always simple nor smooth. 

A platform needs to accommodate a wide range of processes, from onboarding, through KYB/KYC and fraud, credit underwriting, decisioning and customer management. It needs to consider a wide range of underwriting flows, to suit multiple credit products across customer segments. 

As a Product Manager, I get asked about the hurdles of managing such a complex operation. So, I decided to write an article on overcoming the complexities of building, managing and scaling credit products on a single platform - focusing on architecture.

The building blocks of credit underwriting

Data is the basic building block of any credit product. It can be pulled from 3rd party providers or from internal systems, it can be used in its raw form (as it is imported,) but it can also be customized and normalized through calculations, functions and logic added on top of it. At the end of the day, it needs to be compared and benchmarked to classify risk.

Rules take data and compare it with benchmarks, ranges or limits, to provide context. A rule can check whether a credit score is above or below a threshold, or it can verify the existence of a Tax Identification Number.

Rules can be configured to meet any underwriting requirements. They can:

• Verify data to deem a customer eligible
• Assess financial signals to determine risk 
• Segment customers into various flows (i.e. private vs public, big-line vs. micro-loans)

‍Actions are the end result of a rule. They can be a status change,a change in terms, a knock out, or a flag that will impact the rest of the applications’ flow (i.e. reroute to manual review.) 

Policies combine the above listed building blocks and wrap them up with business context. They can calculate multiple parameters to determine a credit worthiness score, they can assign a risk level or return an “approve” or “decline” credit decision.

Designing policies to support use cases

An effective credit underwriting solution should support the creation of policies tailored to industry, business, geography, customer type (consumer or business) and risk appetite. Noble achieves this through architecture, where rules are grouped into policies - to support a specific use case. 

Noble’s platform classifies two types of policies: 

• Evaluation policies (including the monitoring use case)
• Scoring policies

Evaluation policies

As their name suggests, these policies evaluate a credit application. They consist of rule sets that check an applicant’s status and financial resilience. The outcome can trigger an action or reach a decision.

Policies can determine:

• Is there enough data to reach a decision?
• Are KYB/KYC requirements met?
• Does the supplied bank account type qualify?
• Have there been any liens on the business?
• Is the FICO score below or above a benchmark?
• What is the risk level of an application?

The action at the end can be:

• A status update
• An update to credit terms 
• Knockout (auto-decline)
• Trigger of another policy
• Reroute to manual review
• Flag customers to specific underwriting flows

Evaluation policies assess the resilience of any business, based on all available data. They also support ongoing account management by monitoring applications after a decision has been made. Furthermore, they can categorize and layer customers and decisions - a decline can be a hard decline or a soft decline, and a line assessment can decide on 100%, 75% or 50% of the requested line.

Scoring policies

Scoring Policies are unique, in that they emulate scorecards. They let you overcome the limitation of boolean rules - to show creditworthiness in a more layered, nuanced format. These policies are made up of rules which can be normalized (to fit a certain scale) and weighted (to reflect each rule’s importance in the scorecard.) 

They let risk officers better compare applicants against a uniform scale, to see how risk is spread. Different scorecards can gauge risk based on  industry, geography, business age, dynamic market conditions and financial indicators. 

For example, a scorecard can attribute points based on the number of years in operation, or to categorize risk based on financial signals like cash flows, average cash balances or revenues.

Use case: monitoring 

Companies need to monitor and detect changes in a customer’s ability to repay debt. This is critical for customer management and to set the groundwork for revolving credit products, where new credit is extended on an ongoing basis.

Policies designed to monitor customers can leverage both scoring policies - to detect changes, and evaluation policies - to evaluate and perform an action. For example, a scoring policy can recalculate a customer score using the latest financial signals. An ensuing evaluation policy can then compare the new and previous scores. If the customer’s financial state deteriorates, the policy can reset the risk band and raise a flag within the system.

‍Scheduled monitoring

Policies designed to monitor can be scheduled to periodically compare current performance signals to previous ones. It can flag accounts when there’s a significant drop in financial performance (i.e., more than 30% in aggregated deposits.)

These policies can be configured to run periodically (monthly, quarterly, annually) to flag customers whose financial resilience has deteriorated

Triggered monitoring 

Many data providers let you subscribe to tailored push notifications. You can set a policy to flag an account if a customer’s FICO score dropped by 40%, or if a bankruptcy event was registered, or if a company’s registration was blocked. These policies can help uncover sloppy payers, and the input can be used to devise rules and policies for future line assignment decisions

Aside from re-evaluating customers, monitoring policies contribute to ongoing, mandated regulatory requirements. KYB and KYC compliance is dynamic, and the regulator may mandate periodic review to ensure applicants are still legitimate business partners. 

The value of monitoring policies is obvious - it automates a resource intensive task, supports compliance processes and minimizes the risk of default by detecting changes to customer risk profiles early. 

One platform to rule them all

How can a single platform cater to many different business workflows? It’s all about the ability to take the policies you need, to build them with ease, and then use those to create actual business workflows.

You can support onboarding with a policy that validates the company exists and has enough data. Once this policy returns a positive indicator, it can trigger ensuing policies for KYB, fraud and underwriting - until a decision is reached, and a line is assigned. Your business flow can include knock out rules to disqualify an application or to route it for manual review.

It’s rewarding to see our customers, who come from different industries and geographies, and who cater to different market segments, building and maintaining their own decisioning mechanisms. Each uses their own methodology to ensure they reach their goals: offering reliable credit products and gaining access to all the data required to automate and manage the risk.