The credit decision process is quite complex and usually varies significantly from one company to another. There are a number of barriers set by the regulatory environment and they can appear everywhere. The concrete workflow is influenced by the particular requirements and is never 1:1 transferable between customers.
The core workflow can be sketched out as follows:
This is still relatively simple to present and easily modelled in a software application. But as you add other mandatory conditions and other stakeholders who need to be involved in the process, even if indirectly, it becomes much more complicated. Here are a few striking examples:
- There are often multiple loan sales channels with different requirements for speed and precision affecting the decision
- It is quite a demanding task to set the rules for consideration of rights and responsibilities, depending on the volume of decisions to be taken and how applications are set up
- Mass-market decisions should be possible within seconds and without human intervention
- The decision system should be independently accessible by several clients and be able to apply the correct rules in each instance
- The data about decisions is of interest to many parties further down the flow. Examples include bank regulatory auditors and those working on internal rating validation and calibration. The data is then used to question, improve or change internal policies. The system has to save and make all this data available, even if not needed for the credit decision itself
- The system should be flexible and adaptable to new requirements
In CAS, worked intensively on finding the best way to meet these requirements from both practical and technical perspectives.
Realization of the Workflow
Several organisational and technical ways to model flexible work flows have come to light in the course of developing and using CAS for several years. What has resulted is a "best practices" approach that is quite different from the approaches often advocated in the IT literature.
CAS uses an extended portal approach as its surface concept. As a web application, CAS offers a process-oriented portal with significant enhancements to support workflow-based applications and modules. CAS itself is also an application that has been developed on a set of modules based on this platform.
Common to all these modules is that they present their surface in the form of individual windows ("portlets") within the workspace. A workflow in the context of this portal is called a process and supports a number of workflow-specific properties.
Here is a selection:
- Processing statuses
- Tracking/timing of processing steps
- Generating task lists for the process
The user is guided through the work flow by a highly flexible task list. Each process and each subordinate process comes with its own task list. The task list shows the steps necessary to complete this particular step in the workflow and the degree of overall completion. In this way, the user is given optimal guidance and can see in one glance what has to be done. This is particularly advantageous in case of complex application and authorisation structures.
This raises the question of how the necessary flexibility for such a structure can be best achieved. A key point here is a very clean delineation of the components and keeping interfaces to internal and external systems related to the credit decision system (the latter being much more important) as distinct as possible. CAS uses either EJB technology or web services for its interfaces. An adapter for external systems accessed over web services is always used to adapt external customer data to internal CAS structures. In this way, for example, different master customer databases can easily and simultaneously communicate with CAS, because they have their own adapter, but their information is treated identically within CAS. This principle is implemented throughout CAS.
Another aspect to realisation of the workflow is modelling the individual rules and the different paths the workflow can take in response. To be as flexible as possible in this regard, these rules are stored by CAS in sets of internal and client-specific rules. A rule engine then evaluates each client-specific rule and determines the results that will control the workflow. This technique means that the core CAS program can remain the same for different workflow requirements since rules are stored kept in external rule files where they can be separately modified. They can then be viewed with external tools and modified as needed without any programming knowledge.
Realising Workflow in CAS
As part of the development of CAS, we have worked on intensively on implementing flexible workflow management for the credit decision process. We first investigated BPEL and BPMN tools available at the time. Both modelling languages allowed processes to be modelled and then used to control the processes with the software solution developed. BPEL is more technically oriented and primarily designed to control technical web services. BPMN is geared more to business and explicitly aims to create a common ground between business and IT. An implementation would therefore be beneficial.
However, a deeper analysis revealed two problems: the engines we evaluated at the time only covered a part of the defined BPMN standards. The restrictions would made deployment quite difficult.
Far more serious, and ultimately decisive, however, was the recognition that a rule-based modelling of processes in the credit decision is far more appropriate to the requirements. Firstly, in surprisingly many cases, the order in which tasks are executed is not all that relevant. Secondly, there are complex relationships between the various steps which are difficult to model. Thus, for example, the assessment of the collateral of an unsecured portion of a business can lead to a different credit rating.
In addition, many critical decisions are already formulated as rules (competence rules for votes, rating rules for the selection of an allowable rating, rules for the 4-eyes principle, etc.). These rules apply across products and processes. In modelling processes, if one rule was changed, it would require changes in a multitude of other processes. In addition, the actual business rules would not only be defined in several different processes, with all the risks of errors and inconsistencies, the rules would then be seen as an explanation of the most uninformative process diagram.
For implementation, we therefore decided not to use a process engine and instead mapped the processes on the basis of business rules with the rule engine using the JBoss Application Server.
Perspective: Credit Decision as a service
With flexible architecture, CAS makes it possible to offer credit decisions as a centralised service that can take into account individual rules.
Acquiring and running an in-house solution is often not economically feasible if a company only has to take a minimal number of credit decisions in a year. CAS lets us offer the service externally on a piece basis without sacrificing the necessary connections to in-house systems such as the customer database, rights management and process customisation.
This way, even companies with small credit decision loads can shift away from elaborate paper-based processes to a highly automated and cost-effective solution.