How to find a best fitting IT solution for your lending business?

Lending solution selection process flow

The evaluation and selection of an end-to-end lending system follows a standard IT system selection process, with steps illustrated in the following image:

Figure 1: Approach to evaluating and selecting a lending system

Framework creation

To be able to set the right focus for the entire initiative, it is necessary first to understand the bank’s entire business model in terms of its lending business and its underlying IT strategy. At this point of time, questions such as these should be addressed:

• How does the current IT architecture look like?
• How should the IT architecture look like in the future?
• What should be the potential scope of the future lending solution?
• What are the main evaluation criteria and underlying high level requirements?
• Do I need to roll out the solution in more than one entity?
• How should we set up and manage the whole selection approach?

When deciding on the target architectural scenario, it is also necessary to make a clear distinction between what is in scope and what is out of scope of the future lending system, clearly distinguishing between lending and other systems in the targeted architecture, especially the core banking system (in most cases, functional areas like general ledger, accounting, etc. should be out of scope for the future lending system as these are typical CBS functional areas) or related risk systems. At this point, the opportunity should also be taken to redesign the lending-related business processes towards lending best practices and industry standards that also come from the solution providers. Since the high level process models will serve as the main basis for deriving the functional requirements of the target solution later in the process anyway, it makes sense to take this opportunity to redesign them and to introduce some quick improve­ments in the sphere of their execution logic and efficiency. The time invested here will pay off in the future with the implementation of the underlying IT solution(s) that will be used to automate these processes.

An alternate approach can be also considered at this stage. Some solutions found on the global lending IT market come with a specific implementation methodology, different from the standard waterfall implementation approach applied by the majority of the solutions. These solutions provide an agile approach to the implementation itself (e.g. by providing process templates), with specific set of risks and opportunities, therefore the evaluation of these solutions should be treated separately from the others. In any case, these alternatives need to be considered and based on the clear set of pros and cons, a decision about which direction to pursue needs to be taken, the earlier in the selection initiative, the better.

Evaluation criteria as well as high level requirements for the solution need to be defined at this stage of the process. In this context, a focus only on the functional aspects of the system (i.e. meeting lending business, regulatory and risk requirements) would not be sufficient; it is also necessary to expand the view to include additional, non-functional, “practicability” dimensions that indicate implementation and ease of maintenance aspects of the solution such as underlying technology, ease of integration, performance, data integrity, IT security aspects, references, implementation best practice, implementation history of the vendor, product strategy and future roadmap, among others. Neglecting these aspects when defining the evaluation criteria and solution requirements increases the risk immensely and could result in serious operational issues and additional costs during a potential implementation project.

Figure 2: Extension of the functional evaluation criteria with additional practicability view

When browsing for potential long list candidates, besides different internal and external sources of information within the bank itself, relevant global sources of information such as Gartner, iBS’ Sales League and similar should be considered as useful sources of information. zeb project experience can also provide valuable input when finalizing the long list of candidates.

Alternatively, to speed up the process, the bank can apply “knock out” (KO) criteria in this phase of the process if proper knowledge within the bank or by external support is available. This is achieved by filtering out lending solutions which clearly do not fit into the most important and obvious evaluation criteria set by the bank (e.g. multi country set-up, integration capabilities, certain support for dedicated products etc.) early in the evaluation/selection process, and focusing on the solutions that do. The KO criteria need to be defined in a precise and brief manner, and communicated formally to the vendors in the form of a structured questionnaire containing a set of not more than ten to twenty closed-end questions. This approach should assure the transparency and effectiveness of the process and should avoid any misunderstanding and pitfalls that may arise in any other case.

Due to its complexity and related underlying risks, the evaluation/selection process of an IT solution for the lending business needs to be properly structured and managed during its entire lifecycle in order to assure its goals and objectives are achieved. Therefore, these initiatives should be (or even more must be) treated as medium-complexity projects, where all standard elements of such projects are properly defined and managed during the entire lifecycle of the initiative, from establishing to closure (e.g. project organization, budget, governance processes, etc.). The project must ensure proper business and IT content is available and the project approach is properly defined and aligned with the stakeholders.

Request for information (RFI)

The RFI phase is when the high level requirements for the new lending IT solution should be formally communicated to the long listed vendors, in the form of a structured questionnaire. The answers received from the vendors are considered non-binding and are as such clarified and evaluated by the bank by adhering to the previously defined evaluation criteria. At the end of the RFI phase, a short list of solutions is compiled and will be subject to the Request for Proposal (RFP) phase, as well as the initial gap list. As the last step of the RFI phase, and in order to prepare for the next phase, RFP, the detailed requirements for the solution need to be defined.

When defining the detailed functional requirements for the end-to-end lending solution, the bank should take into consideration the complete lending value chain, starting from loan origination, contracting, disbursement, maintenance to monitoring and servicing. The typical lending products to be considered would be standard loans, overdrafts, forfeiting, guarantees, export finance, project finance, syndication and securitization for corporate clients as well as mortgages, overdrafts and some other typical lending products for retail and SME clients. The differences between requirements for retail/SME and corporate systems are most visible in the need for in-depth functional coverage for corporate systems (due to the relatively high complexity of corporate products, especially for some non-standard products like project finance), while for retail/SME systems the focus is more shifted towards workflow capabilities due to the need for standardization and high processing speed, i.e. “time to approval” and “time to cash”. Practical experience shows that often up to a thousand individual requirements covering these functional areas for all client segments are needed in order to provide a solid basis for evaluating the individual solutions during the RFP phase. In addition to the standard value chain, banks should additionally define up to a few hundred requirements for regulatory and credit risk topics, depending on the required scope of the solutions. The input for these requirements should be current bank policies, as well as any specific regulatory and risk regulations in the lending area (e.g. IFRS 9, AnaCredit, Forbearance, EU-FACTA, etc.).

A further emphasis should be put on requirements for limit and exposure management, especially when a bank has to build global limit building blocks. Emphasis must be put on sufficient support for limit definition on multiple dimensions and hierarchies, flexible exposure calculation, ad hoc pre-deal check support, as well as multi-source system support.

With regards to the non-functional requirements, we usually define around 500 requirements distributed among different technical/non-functional areas (e.g. security, vendor, performance, multi-entity, technology, technical integration, etc.). This area should have a clear focus on integration capabilities with the underlying CBS solution and other lending-related satellite applications (e.g. credit risk management, collateral management, etc.). Here, the focus needs to remain on data integrity. As a general rule, doing more than less is a good approach when defining the requirements, because it is always possible to organize additional selection processes to cover the remaining, not covered functionalities if necessary.

If you deal with several banks and/or entities—which is usually the case—we highly recommend having a close look at the multi-entity capabilities of the package. High flexibility in that area proved to be very valuable during implementation and later during the run phase. The packages currently on the market differ greatly regarding that functionality.

It is also worth noting that the RFI phase for selecting the lending solution might be skipped in cases of: a) strong definition of KO criteria in the framework creation phase, leading to immediate short list of candidates, and/or b) strong knowledge of available lending packages on the market which allows the bank to go directly to the RFP phase.

Request for proposal (RFP) phase

RFP is a phase during which the detailed requirements defined during the RFI phase should be formally communicated and clarified to the short-listed vendors. Vendor answers are then evaluated according to previously-defined evaluation criteria. In this case, the answers from the vendors do present an obligation from their side.

In practice, it is to be expected that the evaluation of the responses from all major IT vendors will very likely reveal that no single vendor is capable of providing all needs in terms of lending, credit risk and regulatory areas and that with substantial customizations, and with support from a few satellite systems, one or a few vendor platforms can be selected and implemented in order to reach the required coverage. The main drivers of underperformance of these solutions are usually found in risk management capabilities, meaning that no vendor is able to cover all risk areas, e.g. rating/scoring engines, balance sheet analysis, early warning and credit monitoring, etc. In addition, packages also differ in their flexibility regarding corporate lending abilities and respective product coverage. It is also possible that for some (again mostly in risk and/or regulatory areas) vendors did not provide sufficient or clear/transparent answers. For that reason, and due to the fact that in the final phases of the evaluation in general, the short-listed solutions/vendors are usually only slightly different in terms of meeting the stated functional and non-functional requirements, vendor workshops should be organized. These workshops are held in a simulated bank environment and involve testing the solutions and vendors capabilities by executing real scenarios in critical functional areas. In this way, both “hard facts” and “soft facts” about the vendor can be measured and added to the final evaluation. Practical experience proves that the vendor workshops are a critical tool in the successful finalization of the evaluation and as such serve a very important role in the overall selection process. Our experience shows that vendor workshops can very much change the initial picture, for good or for bad.

Finalization phase

In the final phase of the process, when the solution(s) have already been pre-selected based on their performance in the previous phases of the selection process, it is important to identify the main risks that are associated with their implementation into the bank environment. Following the risk assessment activities, a clear focus should be set on proper contract management and negotiations with the vendors in order to ensure that all major risks are mitigated. Naturally, all risks cannot be contractually mitigated and additional mitigation measures need to be defined for the remaining risks. Further, a high level IT and business gap analysis of the selected solution(s) needs to be carried out, while the measures for closing the identified gaps should be defined and agreed with the vendor. This is also the time to finalize the target IT architecture, as well as to develop and align the overall solution(s) implementation plan. Finally all legal actions (e.g. contract creation, contract signing, etc.) should be undertaken as a final step of this phase. We propose to run a 1+1 approach, i.e. having one favorite but also a backup in case negotiations fail with the preferred candidate.

Conclusion

Structuring and carrying out the selection project is one of the major critical success factors for the overall change initiative of selecting and implementing a new IT support for lending business. When done properly, it minimizes the risk of selecting inappropriate solution(s) and sets up the footprint for a successful implementation. In addition, guidelines such as the general implementation approach, the overall engagement model and the governance structure are fixed before the implementation. After that, and with a strong team on boarded, the basis is set for the implementation endeavor.