The next few years are going to see many transformation and modernization programs for core banking systems. Core banking systems support the bank’s critical banking processes and products, such as personal accounts, cards, loans, etc. and process billions of dollars in financial transactions every single day. These transformations programs will aim to provide financial institutions with the necessary business agility to compete in an increasingly complex market, and a reduction in their high operating costs, using cloud infrastructures and new technologies.
Loan origination is one of the priority areas of focus in most bank transformations. The rationale is that this process has a profound impact on cost efficiency and customer experience. On the one hand, the improvements in the process will reduce the number of hours, with its impact on the costs, that the entity’s employees dedicate to this process, both in the front office (sales representatives in the offices or call center agents) as in back office (risk analysts, compliance, document verification, etc.). On the other hand, loan origination has a huge impact on the customer’s experience with the entity, since they are usually long processes, in which the customer must provide extensive information, in which transparency is usually lacking and the result of which may have a major impact on the life and business of the client. The transformation of the process can greatly benefit this experience and decisively contribute to customer loyalty and increase their degree of satisfaction with the Entity.
It’s expected that the Financial Institutions will assume new roles in the future, adopting new business model to cope with changes in the market and customers caused by the digital era, as very well described by Euro Banking Association & Innopay. While nowadays most of Financial Institutions play both distribution and product processing riles, this will change in the future with banks specializes in the distribution of banking products by selling both their own and other’s products and other institutions specialized in the processing of products because they do it efficiently and selling them through any combination of their own and external channels, including other financial institutions, but also through partners and participation in digital ecosystems.
These separation of roles is not possible with existing strongly coupled, e2e processes.
This publication describes an approach to loan origination re-invention used for several of our customers. The re-design or re-invention is based on the use of BIAN (bian.org) as the reference model, and Domain Driven Design as the design method.
The result of the redesign introduced important changes from the current situation. In particular:
- Transformation from a single complex process orchestrated by the product applications (credits) and responsibility of a single business unit (i.e Credits), to a choreographed process, composed of several independent processes that are responsibility of the different business areas (commercial, risk, product, compliance, legal …) This change would have a significant impact in the efficiency and e2e duration of the process.
- Leverage of hybrid multi-cloud and exponential technologies. The solution is structured in flows and capabilities supported by independent domains. The dependencies between domains are mostly event-driven and favors patterns that minimize real-time interactions to enable the deployment of the different components on different cloud platforms and technologies.
- Evolution from a mono-provider model, where a single provider maintains the ecosystem of applications due to the high degree of coupling between them, to a multi-provider model where different providers maintain or provide the different components grouped by subdomains and with very low coupling between them.
- Move away from sequential processes, where the risk analysis must wait for the commercial offer to be finalized and the commercial offer itself must wait for the client’s on-boarding to be completed, to a process of high parallelization, using mechanisms of intelligent workflows to optimizes the customer experience. The customer sees a single process but, actually, several independent and parallel processes (on-boarding, commercial process, risk assessment) are managed independently in the background.
- The design allows a progressive transformation through Minium Vaible products (MVP) of 3–6 months, with low impact on current applications and minimal coexistence requirements.
- Very flexible transformation roadmap, where each MVP enables new independent projects focused on the domains that constitute the solution. The roadmap can also be always adapted to the business priorities of each moment.
Above and Below the Glass.
A key principle on the process design is the strict separation between User Experience and Underlying Business Processes. This principle is well reflected in the “Above the Glass / Below the Glass” idea. In an omni-channel experience the customer or user will interact through different channels and each channel must leverage their value characteristics and provide the best possible experience. In consequence, presentation flows will vary across channels while the underlying business process will be the same.
This is very different to most of existing origination processes where there´s a strong coupling between interaction logic and process logic, constraining the omni-channel characteristics. For example, in this case, the process in the branch channel application was directly orchestrated by a Cobol application in mainframe which also was providing data and services to other applications, creating a strong coupling between the channel and the backend.
Reference Domain Model
The design of the loan origination process is based on a reference domain model provided by BIAN Service Landscape.
A Domain Model structures the business capabilities in an Organization into Domains. Each domain is made of teams, which are responsible of the applications that support the business capabilities of the domain. All teams in the domain share a common business language and share Domain Experts, both from Business and IT. Domains are very independent from each other. A Domain is completely unaware of the internal details of other domains and relates to them also through standard interfaces such as API or Business Events. A domain contains one of several applications, but an application never comprises more than one domain. The applications can be of several kind, such as commercial solutions, SaaS, custom developments, etc. but never exceed the boundaries of the domain and never interact with other domains’ applications with other than APIs or Events.
The key building block in the domain model is the Service Domain. The Service Domains provides concrete business capabilities and is the government unit for the purposes of design, implementation, or integration of applications. A subdomain is a black box for the rest that only see the APIs that it exposes. Internally, a service domain can be implemented by one or more components (for example microservices) but a component must not span more than one subdomain.
High Level Business Process.
Loan origination processes are generally sequential processes of choreographed end2end activities. The sequencing of activities has a high impact on the duration of the process.
The following image describes a typical origination process. In many cases the choreography of the existing process is implemented in a COBOL application on the Mainframe:
The characteristics of these processes are:
- Based on successive tasks. When the task is done, start the next task
- Non-personalized offer, based on standard products
- No treatment of non-clients: if you are not a client, nothing can be done, all systems work according to the client’s code
- Reactive flow, the flow is driven by the user: The client requests the product; the bank offers the conditions …
- Different flow for each product, for each channel
- Does not treat product packages, associated products, lacks comprehensive treatment
- Flows are orchestrated by BPM or similar tools with built-in business logic.
- High coupling between systems
- There is no clear separation of responsibilities per business actors or business area.
The target business process will have very different characteristics. The sequencing of activity is replaced with high parallelization and the choreography is replaced with orchestration of independent workflows.
The target solution would have the following characteristics:
- The E2E process is broken down into several flows around the different actors involved.
- Separation of responsibilities by business roles and business areas. Several tasks in parallel. The process duration is reduced
- Possibility of on-boarding of non-clients in parallel with the loans origination.
- Separation of Risk Analysis and Commercial Offer.
- Separation of contracting (this is a commodity process, with no business value)
- Customization of offers. Use of AI, Machine Learning on request, risk analysis, on-boarding, customer profiling…
- Proactive, personalized flow (intelligent workflow): The flow is managed by the system and human actors only involved as required.
- Single process for all products and channels. The process adapts to the specificity of the different products. The presentation flow change across channels to allow the process to leverage the differentiating characteristics of each channel.
- Possible use of commercial solutions and SaaS for some of the processes
- Event Driven
- No system coupling. Each process is independent of the others. The E2E process is accomplished through choreography across the different processes
In this model, there´s no e2e orchestration, but some of the flows may be orchestrated using BPMs or similar, but the principle is that the scope of a follow orchestrated will never expand beyond the scope of the activity. For example, the contract signing flow could be implemented using a BPM, but his flow would never control activities outside the contract signing activity.
Solution Domain Model
Each of the flows or activities in the e2e process are responsibility of the different service domains as described in the reference models. As a result, the following diagrams shows the service domain involved in the process and the relationships between them:
This process is radically different from existing traditional origination processes, based on sequential tasks, and in which the process of each product is considered from the point of view of each product, with almost no shared capabilities across them.
In this case, most of the Service Domains involved in this process correspond to the Distribution Area, with its own vision of Cross-Sales, assigning the Risks and Loan Products Area the tasks that really belong to its scope of application.
Customer Request
The Request Aggregate manages the requests made by clients through different channels, whether they are the bank’s own channels (Offices, web, cell phone, ATMs), by a prescriber from an external entity, or by the Commercial Area (Campaigns).
The Request, as it has been defined, allows a separation with the rest of the processes and their omni-channel use, and in the future, with other types of external providers that will be very important in the composition of the future business (Comparators, Fintech and others through BaaS Agreements, etc.)
Another important feature is its possible future integration with requests from non-clients and the possibility of executing the onboarding process for new clients in parallel with the rest of the origination processes. Currently, in most existing loans origination processes, it is necessary to perform the onboarding process first, given the coupling of customer systems and product systems. This will allow for significant improvements in time to market.
The application process starts from a series of minimum data that reflects the financing needs of the applicant and the minimum data of the person requesting it.
It will give way to different key activities in the process, such as the generation of the offer, the analysis of the financing or the signing of the contract or associated contracts.
Product Matching Assessment
Product Matching is the capacity that will allow the realization of a personalized offer of products to the applicant, especially differentiated and designed at the moment by the system, which can include one or more products, not just loans. It will offer a menu of products and services specific to that applicant.
To carry out this menu of products, multiple parameters will be considered (Applicant, purpose of the application, need for financing, previous interactions with the entity, ongoing campaigns, existing product directories, etc.)
Once the service is created, it will evolve from basic rule-based models to more complex AI-based models.
This function is fundamental in the origination model that is proposed, for all types of applicants and can help improve the conversion ratios of the origination process, by generating a unique and specific offer, improving in each interaction.
Customer Profile
Advanced Product Matching is possible once you have an adequate Customer Profiling, both commercial and risk.
Currently, since there is no functionality that profiles the applicant at the beginning of the origination process, there are many dismissals and rejections, both by the applicant and by the entity itself, when the process is advanced
The profiling of the current client is mainly based on risk analysis. As such, there is no eligibility analysis, which may take other characteristics into account.
What we propose with the inclusion of this addition is the performance of a profiling of the applicant at the beginning of the process, with the data available at that time from various sources, which will allow us to understand if the applicant type is adequate, if he has had previous experiences with the entity and how these have ended, and other policies.
It will allow us to make a personalized offer at first (key in this process as we have commented previously) or even to desist from making an offer based on this profiling.
Like product matching, once the service is created, it will evolve from basic rule-based models to more complex AI-based models.
Customer Offer
One of the main changes of the new Origination model is the separation of the aggregates that belong to the commercial sphere (Distribution Area) from the aggregates that belong to the Risk Areas and Asset Products.
It incorporates the services related to the administration of the commercial part of the asset loans origination process (terms and conditions, documents requested / provided, etc.). Its status will evolve as the data is completed and will be related to the aggregates that make up the loans origination process: Credit management (where the financing risk analysis is done), approvals, etc.
The commercial offer may contain one or more commercial products, to cover the request of the applicant and the analysis carried out initially (eligibility and product matching).
The commercial offer may be changed and evolve as it is completed, at the request of the client, of the policies that are applied, of the commercial negotiation and of the risk analysis that is carried out.
One of the main changes in the proposed origination model is the possibility of carrying out and evolving the commercial offer in parallel with the Risk Analysis, which we believe will lead to significant reductions in the time to market of this process, especially in complex operations. If changes occur during the process of negotiating the offer that affect the parameters evaluated in the risk analysis, these should be reported to the Credit Management aggregate, but this process should not wait, as in most current processes, for the offer is closed.
Credit Management
Aggregate that manages the Risk Analysis process for a specific loan application. Basically is used to assess the risk based price to be offered to the customer.
The risk analysis includes the different validations and calculations that are made on a risk request to verify compliance with the entity’s risk policies by the offer that is being made.
The risk analysis incorporates automatic and manual services to carry out this analysis:
- Automatic services. Scoring, Rating, RAR Analysis, Analysis of the client’s position in the entity and in the system, analysis of external positions, analysis of negative databases, analysis of pre-approved, analysis of financial ratios, etc.
- Manual services. Risk analyst review, expert analysis, collateral appraisals, etc.
Based on this analysis, it will be reviewed whether the requested risk can be approved based on the characteristics of the parties and operations, and changes to this request may be proposed.
Additionally, the minimum price will be calculated based on the risk, below which it cannot be negotiated.
The risk report will include a series of automated data (quantitative analysis) and a report made by the risk analyst with conclusions about the suitability or not of approving the purpose (qualitative analysis). In some cases, depending on the Risk policies, this report may be made completely automatically, for example, if the client has assigned pre-approved limits.
In this aggregate, it is very important to foresee the rapid evolution of these models in the current situation from basic models based on rules to increasingly complex models based on AI.
Agreement Fulfillment
The separation of the process into domains based on the main participants on each part of the end-to-end process will allow a more agile maintenance and multi-vendor approach.
This translates into the complete separation of the activities of management of requests, preparation of offers, formalization of contracts (sign off) and constitution (loan opening and disbursement), which nowadays are tightly integrated into the same processes. The change enables the maintenance and evolution of each of the parts to be done unconstrained by any of the other processes. It would also facilitate the outsourcing of processes that are not of value to the business, to external agencies or providers, such as the signing and registration of contracts.
The Agreement Fulfillment aggregate is responsible for the generation and signing of contracts for any type of product, through any channel and including the necessary human activities such as signature at notary, contract registration, etc. Agreement Fulfillment will use services provided by other domains such as document management, third parties operations management (notary, registry), etc.
Value Proposition
The new Loans Origination process has very differentiating characteristics compare with the existing one, specially:
- Omni-channel support, including third party and open banking
- Hyper-personalization of customer offers
- Omni-Product sales, with commercial focus and inspired in digital retailers.
- Process Optimization. Non-value processes are decoupled
- Designed for Hybrid Cloud. Extensive use of Event Driven Designs and hyper-modularity of components
Omni-channel
The new process has advanced multi-channel characteristics, achieved through the separation of “request” and “offer” management and including the ability to manage requests from third parties, such as brokers or business partners, etc.
This is a fundamental characteristic to support the entity’s business strategy of opening its business model to collaboration with third parties through Open Banking capabilities.
To provide the desired characteristics, different Service Domains specialize in supporting channels with require special treatments. For example, to support credit requests from external prescribers o third-parties, point-of-service sub-domains were included that provided access and support to those prescribers o third-parties, while requests from internal channels were managed directly in the CRM Service Domain.
The rest of the service domains, such as the one for preparing offers or analyzing the risk, are channel agnostic and support all channels without any specific logic for each of them (it is omni-channel).
The advantage of the model is the ease of including new channels, especially external ones, without impact on the e2e process.
Hyper-personalization
The ability to provide the customer with the ideal product and conditions based on their needs, characteristics and preferences is achieved through several domains such product matching and customer profile where IA can be applied.
Product matching determines the product, or combination of products that can best meet the customer’s needs. This domain may evolve from basic matching rules to the use of machine learning algorithms, to determine historical decision patterns and customer satisfaction with similar profiles in similar characteristics.
The profiling of the client allows us to know their characteristics and classify them adequately so that the product matching algorithms can propose the appropriate products by comparing the client and their need with similar clients in similar situations.
Product eligibility will be used to enforce the Bank´s commercial, risk or compliance policies.
Omni-Product Sales
The process is designed as a multi-product approach, looking for a commercial experience and not one inspired by large commercial retailers. In this sense, the response to a request is an offer that can include one or more products, internal or intermediated, and from any line of business. The objective is that the initial use for loans products is extended to the rest of the products.
We stop talking about the “loan origination process” anymore and talk about the “sale process”.
The specificity of credit products are concentrated in the domains of credit risk analysis, underwriting and collateral management. In fact, these domains will also manage the differences between the types of loan products (personal, SME, corporate, mortgage …) that will only vary in the type of customer profiling and in the type of collateral involved)
The following diagram describes how the process is structured in components that are cross-product and designed from a commercial and customer-centric point of view, while other components are only involved as required to support specific products, such as Loans.
It is very significant to remember that we don’t have any orchestration managing the e2e process. Otherwise, it would be too complex and impractical to address all scenarios. The involvement of credit or credit risk specific domains are choreographed are requested and engaged through proper APIs and event subscriptions.
Process Optimization. Non-value processes are decoupled
The process clearly separates and isolates those workflows that are necessary but do not add business value. For example, having good digital capabilities for negotiation and interaction with the client are differential and a priority for the client manager, but signing the contract once the offer is approved is an activity to be carried out, but it does not really add value for the business. In this example, the signing of the contract could even be outsourced to an external provider that could even accompany the client to the notary signatures.
For this reason, these “commodity” flows are in specific and separate domains from the value processes so that in each one different imperative can be prioritized in each case: customer experience, efficiency, etc.
Designed for Hybrid Cloud
The process is designed to be deployed in hybrid cloud environments. For this, it is necessary that the components of the solution have loose coupling between them, to avoid latency and availability problems.
This is one of the most important problems in functions such as credit risk analysis. Most legacy systems that implement credit risk analysis must obtain information from multiple data sources, such as customers, accounts, products, investments, defaults, cards, collaterals, and so on. This implies hundreds of real time access to data from other applications. If this type of design is applied to applications to be deployed in a cloud environment, the latencies in each access through APIs would produce unacceptable response times.
To avoid such risks, the process designs follow event-oriented architecture patterns, aggregating and preparing information in advance rather than solving it in real time.
Transformation Roadmap
“Few Banks in the world would nowadays accept transformation programs without incremental and progressive value delivery”
The transformation Roadmap to implement the new processes and decommission the existing one should be designed based on the following principles:
- Progressive implementation, through incremental delivery projects that provide business value every 3–4 months
- Low impact on the current applications. Current systems can only release changes 3–4 times a year because, due to their criticality and complexity, each deployment has a significant risk of impacting the bank’s operations.
- Flexibility and adaptability of the Roadmap to always adapt to business priorities
- Enabling of the change from organizational model to the domain model. The process change implies important organizational changes since all the systems that support the current process are responsibility of the credit area, but most of the components that support the new process will be the responsibility of the sales and customer service area.
Co-auhors:
References:
