Digitizing our credit policy — Product configuration, creating segments

Table of Contents

Digitizing our credit policy — Product configuration, creating segments........................................................................2 How does decisioning/routing/pricing work?.................................................................................................................17 How does your product ensure clean customer/prospect data—both from bank and external data sources .............30 What is the process for initial policy creation?...............................................................................................................30 What does the exception process look like?...................................................................................................................36 How does rolling-out, reviewing, and early tuning of the policy work?.........................................................................41 How do we monitor, track, and implement changes related to all aspects (forms, processes, etc.) of the SBA guaranty programs? ........................................................................................................................................................43 How does our product work with the bank to monitor and manage the credit policy?................................................44 How are the loans funded? .............................................................................................................................................47

What is not automated in your solution? .......................................................................................................................46 Describe the transition from application to business deposit account opening? ..........................................................47 Is your product integrated with JHA Silverlake? Is the account creation fully automated to the core?.......................51 What are the processes/tools for monitoring and supporting the customer interaction?............................................50 What account funding options do you offer?.................................................................................................................50 How do you comply with NACHA’s upcoming web account validation rule for funding purposes?..............................50 What marketing capabilities (internal customer base and prospects) are provided by our product to the bank?.......51 How do we take the friction out of the customer experience?......................................................................................56 What are marketing and digital user experience best practices? ..................................................................................56 What is the timing start to finish for the customer to successfully complete a SBL application? Time to open a business deposit account? ..............................................................................................................................................57 What reporting is given for usage/abandonment rates at each step of the application process? How do we prompt for half-started applications?..........................................................................................................................................61 Describe the digital user experience for transitioning across channels (branch, online, mobile, etc.) .........................63 How are the channels integrated: for the customer/for the banker?............................................................................66 Describe the ongoing digital experience for the banker/back office. ............................................................................72 What training is required in bank channels? How is ongoing support provided?..........................................................87 What are the processes/tools for monitoring the portfolio and individual loans?........................................................88

Digitizing our credit policy — Product configuration, creating segments

Start by looking at our Origination Configuration administrative user interface, then our CL Product configuration screen, and finally how you can configure and manage all your loan products and unique product workflows in Q2 Origination:

Launch one of the CL Product configurations (suggested: “Small Business Non-RE Term”) and proceed through the various parameters Q2 uses to configure loan products in Q2 Origination (such as product details, compliance configuration, pricing configuration and more).

Here’s how we manage stage progression of a loan for each product (from Application through to Booking), along with how we manage Rate Cards, and how we can configure Approval Processes to enforce dual control for any changes made to product configurations.

Now that we have introduced you to product configuration in Q2 Origination, we can pivot to discussing how we manage and enforce credit policy, due diligence policies, compliance policies, and more in our system. To start the discussion, acknowledge that we use two forms of logic to enforce credit policy in Q2 Origination: • Scorecards – which use weighted logic to calculate credit ratings (which are used to determine credit worthiness) • Policy Conditions – policy-based criteria that is used to enforce credit policy, due diligence policies, compliance policies, etc., and drive exception tracking and governance of mandatory policy conditions.

Let’s start by providing an overview of our Scorecard feature and a sample Small Business Scorecard. Navigate back to Origination Configuration and click the Scorecards configuration option. We can configure multiple Scorecard Sets to support the different scoring scenarios that you require. Usually, we associate a Scorecard Set with a single Asset Class – or sometimes with a specific loan product (if the scoring requirements are unique enough).

Each Scorecard Set includes one or more Scorecards (the categorization is to enable you to more easily separate criteria for different contexts, such as legal entity classifications).

Each Scorecard consists of weighted matching criteria, enabling you to weigh quantitative values such as consumer credit report data (like credit score, inquiries, delinquencies, bankruptcies, open accounts, adverse actions, etc.), business credit information (such as third-party risk scores, bankruptcies, judgements, liens, public filings, etc.) and credit analysis indicators such as debt service coverage,

global debt service, total exposure and more. In fact, any field from any object in the Q2 Origination database (whether included in our managed package or added as a customization by you or our implementation teams)

It’s easy to add new Scorecard Criteria by clicking the New Scorecard Criteria button and adding a new piece of weighted scoring criteria:

And if necessary, navigate to the Risk Analysis screen of the digital credit file to see how Scorecards are used to determine an aggregate Total (Risk) Score and, ultimately, a Credit Rating (which we use to determine the

recommended credit approval for the loan). We can auto-decision loans using Scorecards and Policy Conditions, but we can also provide “assisted decision making”, where you have the final say.

Now, let’s pivot to Policy Conditions. Scorecards and Policy Conditions work together to manage and enforce credit policy. While Scorecards determine a weighted credit rating for a specific loan, Policy Conditions enforce mandatory credit policy conditions (as well as due diligence, collateral, and compliance policy conditions). Policy Conditions is the feature we use to track and satisfy policy exceptions during the loan origination process.

Policy Conditions, like Scorecards, evaluate configurable rules; however, unlike Scorecards, Policy Conditions are supported by additional functionality that enables:

• An exception to be triggered (if Exception Criteria is evaluated to be true) • The exception to be satisfied (by meeting configurable Satisfaction Criteria) • The exception to be overridden (only authorized your users AND only if allowed by you)

Start by looking at a simple Credit Policy Condition which enforces that all credit entities associated with the loan have credit scores greater than 600 (i.e. any borrower or guarantor with a credit score lower than 600 will result in a policy exception).

First, let’s look at the Exception Criteria (i.e. Generation Criteria) by clicking the Individual Credit Score Below 600 rule. This criteria determines if a policy exception exists or not. In this scenario, the Policy Condition evaluates the entity’s involvement in the loan (is the entity a borrower? a guarantor?), the entity’s legal classification (is the entity an individual?) and the credit score criteria (i.e. less than 600). If all of these criteria are evaluated to be true for any entity involved with the application, a policy exception will be triggered. And in Q2 Origination, all mandatory exceptions must be satisfied or overridden by an authorized user before an application can be closed and funded.

Let’s say that NHM wants to apply this Policy Condition to a single loan product (or a group of loan products), all we need to do is add the appropriate criteria to the Generation Criteria – Party Application CL Product Name Operator equals “Small Business Non-RE Term” — now this Policy Condition applies only to Small Business NonRE Term loan products.

Look how these exceptions are presented to the loan team.

We have shown you how to configure and trigger a policy exception…but how do you satisfy these exceptions? This is done using Satisfaction Criteria. Policy Conditions can be satisfied in three ways: • Data – Specific Satisfaction Criteria is evaluated to be true (for example, an exception is triggered because certain mandatory information is missing from an application; however, now it has been added and the exception can be satisfied). • Documents – Some exceptions can be satisfied using documentation. For example, we typically use third-party data to automate KYC and KYB; however, if the data is inconclusive (for example, if we are unable to verify the business borrower’s Tax ID number – which is a common automation exception), the Policy Condition enforces secondary verification using documentation (i.e. the Policy Condition’s Satisfaction Criteria specifies documentation which can be captured to satisfy the exception). • Override – Again, certain exceptions can be overridden by an authorized user (this is controlled by the FI and implemented at the FI’s discretion).

To demonstrate an example of Policy Condition Satisfaction Criteria, launch the “Customer Identification Program (CIP) – Primary Identification” Due Diligence Policy Condition. This Policy Condition – which enforces KYC due diligence (this is not a credit policy example, but it helps articulate how our exception tracking feature works) – is satisfied by capturing and approving any 1 of the Documents listed in the Satisfaction Criteria configuration (in this case, the entity’s Driver’s License, Passport, Military ID, Social Security Card, Foreign-Issued Driver’s License, Foreign-Issued Passport, or Foreign Green Card).

This criteria may not specifically match NHM’s CIP compliance rules, so know that configuring Satisfaction Criteria in Q2 Origination is simple (just as it was to configure Exception Criteria and Scoring Criteria). Click “New Resolution Criteria” and see easy it is to add additional criteria.

Again, see how this impacts the user experience and the workflow for the loan team. On the Exceptions screen (for an in-flight loan application), we see a list of exceptions which must be satisfied before the loan can be finalized (i.e. closed and funded). Since this example (as a reminder, we are satisfying a KYC exception) is satisfied using documentation provided by the borrower (this is indicated to the loan team by the Condition Type = “Document”

referenced on the exception…”Data” exceptions are only satisfied once the data criteria configured for the Policy Condition has been met or overridden by an authorized users), we can click the Actions menu next to the KYC exception and click the Documents option.

The resulting screen shows the user which documents can be captured to satisfy the exception.

Users can notify the borrower of required documents by checking the box next to each document and clicking the “Notify” button.

While we see the exception tracking and satisfaction process, check out how borrowers can upload documents online AND how existing NHM customers can upload documents via digital banking. Launch UUX and log on.

Navigate to Account Management and click the “Small Business Loan” tile (these cosmetic items, such as labelling, are 100% configurable).

The borrower is presented with a list of loans (if he/she has multiple active loans in origination – otherwise the borrower will only see their current application). Click “Continue” next to APP-000000041.

The borrower is presented with a list of documents that he/she can upload to satisfy the KYC exception, along with instructions (i.e. “any one of the following documents will help us verify your identity”…), and the current status of the loan (these values are configurable by the FI).

Click “Upload File” next to Personal Tax Return. Locate IRS1040.pdf document on your computer and upload it.

Borrower sees the progress of the file upload…

The document has been uploaded successfully and the borrower can now view his/her file.

When the loan team accesses the loan’s credit file, they will see the status of the Policy Condition has changed (it is now in “In-File” status); however, one additional action is required to fully satisfy the exception.