Identifying the customer needs before traditional credit origination

14 March 2021

In a world of hyper-personalization and customer-centricity, customers are expecting their banks to provide solutions to their needs, rather than having to find, buy and compose different products and services themselves.

This results in embedded user journeys, where different products and services (often of different companies partnering together to fulfill the user journey) are aggregated and integrated (via Open APIs). A very common element in the journey of acquiring a product or service is the financing of it. Often people don’t have the necessary cash (or more general liquidity) available to acquire the intended product or service. This is where a bank comes in to provide a financing solution.

Many banks today are still organized in a very product-centric way. Most websites of banks are setup around product silos, like daily banking, investments and credits. When selecting the credits domain, you will first get an overview of the different credit products (like consumption credits, mortgages, bridge loans, fiscal credits, overdrafts…​). Afterwards when you select a specific credit product, the typical credit origination flow starts and sometimes a simulator allows you to calculate the project cost, the financing need, your reimbursement capacity, and the interest rate.

However there is little to no guidance on which credit product should be selected and it is very difficult to compare different credit products or even different formulas of the same credit product (e.g. comparing a 20 year with a 30 year fixed rate mortgage, or with a 20 year variable rate mortgage). Furthermore the origination process and linked simulators are usually not exposed to the outside world, meaning it’s very difficult (or even impossible) to integrate them in an embedded user journey on a 3^rd party platform.

As such there is a need for a “Financial Needs” module (cfr. Capilever FINE), which allows analyzing the customer’s project (for example buying and renovating a house) and analyzing how it should best be financed. By starting from the customer’s intent (i.e. which project do they want to pursue or which products/services do they want to acquire), the bank is able to service the customer in a much more user-friendly, customer-centric and optimized way. The customer gets the feeling he’s being heard (“It’s all about me“), while the bank collects valuable customer information that can be used to cross-sell other products like insurances. As a result,  the bank can optimally propose different financing solutions allowing to compare the pros and cons of the different options (cfr. Capilever IRCT).

This “Financial Needs” module works in 5 steps:

• Step 1: Determine via user-friendly questionnaires, the project of the customer. By project, we mean a very general intent of the customer to spend money, for example buying a car, planning a holiday or renovating a house.
• Step 2: Determine the total cost of the project via a simulator, assisting the customer to get a well-founded estimate of the total project cost. Of great interest here is to integrate with external APIs, which are specialized in estimating and calculating certain costs. For example APIs to estimate the price of a house (based on certain characteristics), the price of a 2^nd hand car, the cost of a home renovation, or an API exposed by the notary federation to calculate notary and registration costs when buying a house. The use of external APIs for these calculations avoids having to implement (and more importantly to maintain) these calculations and will typically provide a much more accurate calculation.
• Step 3: Determine the financing need = how much money does the customer need to borrow. This results from the total cost of the project and the available assets the customer has.
• Step 4: Determine the customer’s reimbursement capacity. This can be estimated based on income and expenses. Obviously no loans with a monthly reimbursement higher than this reimbursement capacity should be proposed.
• Step 5: Propose credit products and allow to compare them.
  For these credit propositions it is important that the bank supports different types of optimizations. We distinguish between an optimization for cost (focusing on lowest interest rate, while considering associated credit costs and fiscal optimizations), an optimization for flexibility, and an optimization for risk (risk for the bank or risk for the customer in case of reimbursement issues).
  Once the propositions are shown, customers can easily compare the pros and cons of each proposition. They can execute What-If analyses for each proposition, for example “What if I lose my job?”, “What if I die?”, “What in case of divorce?”, “What if interest rate increases/decreases considerably?”…​ These What-If analyses reveal in a clear and transparent way the risk the customer takes when signing up for the proposed credit.

Ultimately the “Financial Needs” module aims to guide customers towards the best products or product bundles, including products they maybe hadn’t thought about yet. It can also propose to liquidate certain customer assets. For example in Belgium a lot of interesting financial solutions exist, which are often not considered by customers as they simply don’t know the product, like (i) Credit Lombard (cfr. Capilever LABL), (ii) redrawing on an existing mortgage, (iii) using your second pillar pension plan as collateral for a mortgage or (iv) taking an advance on this pension plan for the acquisition of a house.

The most important differentiator of such a module is its user-experience. It should guide the customer in a very fluid and simple way, while still ensuring that the best possible proposition is made. This can be achieved through dynamic and adaptive questionnaires (in the form of wizards or conversational style like chatbots), a maximum of pre-filling, visual simulators, contextual help, etc.

Furthermore the “Financial Needs” module needs to be very open and very integrated. “Very open” means it exposes well-documented APIs and widgets, which can be integrated by third-parties for embedded user journeys. “Very integrated” means it is well-integrated with other bank systems, allowing to maximally collect customer data (for maximum pre-filling and personalizing the questionnaires, based on the customer’s profile), but also to pass along any data collected in the module to the subsequent origination process.

Such a “Financial Needs” module can become a cornerstone for the user journey of a customer in need of financing and should therefore not be excluded from any bank’s application landscape.