Credit systems can be presented as a set of solutions supporting the assessment of customers, transactions and risk when making decisions whether to enter into a contract or its further course. Examples of such solutions are our VSoft Credit and VSoft Rating products. In addition, systems responsible for credit processes can connect to other systems to deepen the analysis or provide added value to the assessment, e.g. using VSoft Connectors. Where is the central system in all this? Were does its name come from? What is it and what tasks does it perform? You will find it all out in the article below
Terminology and scope of activity
The central system is the main application (including its modules) that manages transactions, portfolios, customer data, products, collateral, accounting and settlements in the Bank. Of course, each bank may have a different, dedicated solution tailored to the scale and scope of its operations. However, let us assume for further work that there is currently one application of this type, gathering all the knowledge about the client and the Bank itself. It should be mentioned that this was not always the case. When I started work, the novelty was one central system instead of dispersed applications in each branch/region. Applications were fed information by employees from documents and sometimes from Excel files. Just the keyboard and two-colour screen, stacks of paper and employees to handle it. There was no question of any kind of connectors support. Data was entered only manually. Also, payments, transfers, revaluations, accounting checks, balance reconciliations, customer data and consents were processed in accordance with the adopted standards and signed contracts. Why is this important and why do I mention it?
For the reason that such data on customers, contracts, accounting balances etc. that was transformed as a result of bank mergers, portfolio acquisitions, and was passed from one central system to another. Some of them closed, some changed in terms of the new guidelines, but the scope itself and its logic remained the same. Currently, multi-module central systems manage the entire history of not only their clients, but also the history of the bank. It is this history and multi-modularity that we face when integrating the central system with our modern solutions in order to download customer data, update them, release funds or add a new collateral to the customer’s portfolio.
What are we facing during implementation?
Let us assume that our goal is to conclude a simple loan agreement. The customer signs the contract, and has funds released into their account. The end.
Simple – but what’s hidden underneath?
When creating a credit scoring system for our example, we need to have several hundred pieces of data, the main ones from/to the central system. I will present only some of the elements that we analyse and implement.
- What is the customer type when broken down into segment and sub-segment (if present in the central system)?
- Is the client single, does it require co-applicants, guarantors, collateral givers or spouses? This affects the scope of files created/activated in the central system.
- Is the customer already our bank’s customer or a new one? If new, then we need to call up the required fields to create files in the central system. If they are our current customer, we need to confirm their identity and check whether a John Smith is the John Smith, and provide the file in order to verify the correctness/completeness of the data.
- Will the commission for granting the loan be charged manually (we have to divide it into a non-cash, directly from the account other than the one indicated for transfer/repayment, or from the account indicated for transfer, or as part of the loan, or cash) or automatically, in accordance with the commission table for this type of segment/sub-segment/promotional conditions/product data amount.
- Additionally, required fields from the list of fields available for our loan to the central system should be completed. There are several hundred such fields. All this in order to generate an application, consents, statements, loan agreements, collateral agreements and, for example, to provide data from the CRM system, which also uses data in the central system.
The above list contains only sample elements for starting our loan, which cannot be seen by the Advisor, when processing the application, let alone the Client. The central system may have “overlays” for employees for specific activities, e.g. deposits, withdrawals, transfers, but also an accounting module.
Connecting to the central system can also be done in a modular way. It all depends on what element is currently needed in the process, e.g. updating the corporate client’s file in terms of adding a new business code and a new board member. The employee or the system calls up the file from the external suppliers and receives the current company data. Using the provided services, data are updated in the central system/via the bus by providing the client/system ID and checking the correctness of the data.
Of course, it does/may not always have to work automatically, but we always strive to ensure that the data in the central system is complete, true and controllable in terms of the fields and formats which we provide, because we know that x other systems and applications are working on them.
Perfect combination and recommendations
In my opinion, central systems, in order to keep up with the requirements that are currently set by customers, must be divided into smaller parts, frequently updated and adapted to changing requirements, especially in the cloud, online and robotic world, which will be managed by one mechanism – the orchestrator.
We have recently discussed a lot of robotization of certain activities, which resulted in an article entitled “A process approach to robotization” and certainly this approach to optimizing activities that affect credit processes and are related to the central system will help in the transformation to new solutions.
