Applying Reference Models – From Bank Model to Core Banking Radar
Who has encountered the bank model before?
The bank model is a reference model which, as the name implies, can be used as a reference when creating a company-specific model.
When it was created in 2004, the aim of developing the bank model was to support banks in developing strategy and processes. This was done by systematically depicting the components in the bank’s value chain and their interrelationships, which is helpful, for example, when selecting processes for in- and outsourcing.
The bank model is based on the typical division in process management into customer processes, management processes, service processes (sales to cross-transaction processes), and support processes.
The three most important customer processes in banking are payment, investment and financing. Along the value chain of a bank (from planning to controlling) and the associated processes, the bank model lists the tasks that must be performed at the respective value creation stage in the three customer processes. In the case of the transaction/settlement processes, it also lists examples of products (e.g., cards in the payment customer process, funds in the investment customer process, leasing in the financing customer process).
In order to show a concrete example of what the use of a reference model can look like, this article describes how the so-called functional model specific to the Core Banking Radar was derived from the bank model, which queries the coverage of functionalities in core banking systems.
The Core Banking Radar was launched in 2017 by Swisscom and the Business Engineering Institute, in the knowledge that Swiss banks will sooner or later have to address the question of how their core banking systems can meet their needs in the future. In the Core Banking Radar, we interview core banking systems relevant to Switzerland at regular intervals based on a comprehensive evaluation methodology with the goal of providing a neutral view of each system’s characteristics. The selection process as well as an overview of the assessment model used in the interviews with core banking systems are described in a previous blog article.
In the Core Banking Radar, we want to develop as complete a picture as possible of which core banking systems support which processes of a bank through which functionalities. Since we take a bank perspective, it made a lot of sense to base the functional model on the bank model in order to query the coverage of as many banking functionalities as possible.
In developing the functional model, we went through the processes of the bank model step by step, decided for which bank processes support by the core banking system could be relevant, and defined fine-granular functionalities with different degrees of design within the processes (a 5-point scale, described in more detail in the earlier article). The result was the functional model, which is derived directly from the service processes of the bank model and breaks them down into the following four categories
- Advisory and Sales (in the bank model: distribution processes)
- Processing / Execution (in the bank model: transaction / settlement processes)
- Management, Monitoring and Exception handling of transactions (in the bank model: transaction-related processes)
- Position and account keeping, risk management, reporting, product development (in the banking model: cross-transactional processes)
As a fifth category, the Core Banking Radar functional model also integrates the
- Support services (in the bank model: support processes)
These five functional categories can each be seen in the evaluation graphs (see the red dots in Figure 2).
The support of management processes such as partner or architecture management is partly elicited under the non-functional criteria (green dots).
The customer processes of payment, investment, and financing were also derived from the banking model in the Core Banking Radar and supplemented by the customer processes of “financial security” and “overarching”, which are also relevant from the bank’s perspective.
At the intersection with the functional categories, the services derived from the customer processes allow a relatively accurate picture of the characteristics of a system (see Figure 3).
The final evaluation of each of the five categories in the functional model is calculated from several subcategories and underlying criteria, which are shown below as examples (there are a total of 115 criteria in the functional model alone, which is why a listing of all criteria would go beyond the scope of this article).
Of the five topics in the functional section of the Core Banking Radar, the first, Advisory and Sales, examines theextent to which a core banking system supports functionalities in the area of customer acquisition and support. Functionalities are queried in areas ranging from customer/market analysis and marketing campaigns to consulting as well as quotation and contract conclusion. This includes processes that are often covered by a CRM system, so some core banking systems deliberately outsource this.
Examples of criteria queried with 5-point scale: Determination of needs and wishes of the clientele, complaint handling, campaign management, liquidity check, simulation of solution scenarios, commitment and signing.
According to the banking model, the processing / execution oftransactions follows five basic steps:
Their design varies somewhat depending on the customer process (payment, investment, financing). For example, amortization only appears as part of the processing in financing. The Core Banking Radar questionnaire is designed to reflect these differences accordingly.
Examples of criteria queried with 5-point scale: Order preparation, condition calculation, limit check, posting, clearing execution, share delivery (only investment), amortization (only financing).
The category Management, Monitoring and Exception handling of transactions inthe Core Banking Radar is derived from the transaction-related service processes of the banking model. Accordingly, this category deals with the extent to which individual transactions are managed.
Examples of criteria queried with 5-point scale: Exception handling, investigation, corporate action execution, identity verification, liquidity calculation, tax calculation, viability calculation, event notification.
Position and account keeping, risk management, reporting, product development correspond to the cross-transaction service processes of the banking model, which form the basis of transaction processing and sales. However, they are not part of individual transactions. This category includes, for example, customer/account/deposit management, internal monitoring or “competence centers” which support balance sheet analysis and credit rating determination.
In addition, this category also evaluates, in line with the banking model, how the respective system supports distribution, for example in the form of functionalities such as benchmarking, rebalancing, or management of synthetic positions by external investment advisors in the area of portfolio management.
Examples of criteria queried with 5-point scale: Customer profile management, partner management, fraud detection, compliance monitoring, product development.
The Support services category in the Core Banking Radar examines the coverage of functionalities in areas such as accounting, document management, business process management or legal reporting. Contrary to the bank model, the Core Banking Radar does not examine human resources, as this extensive topic is typically covered by corresponding specialized systems.
Examples of criteria queried with 5-point scale: Data Warehouse, workflow engine, archiving and scanning, operational accounting and financial accounting.
As both the bank model and the functional model of the Core Banking Radar end with the category support, the application example of a reference model hereby comes to its conclusion. The banking model, which is already almost 20 years old, would need to be supplemented in today’s world with banking services and functionalities in the area of integration (e.g. API interface management) to reflect the importance of embedded banking. The Core Banking Radar model already takes these issues into account.
Within the framework of the Competence Center Ecosystems, the lively exchange between the participating companies (banks, system manufacturers, fintechs, insurance companies, …) and PhD students constantly produces new reference models with a high level of practical relevance, which partners can use relatively quickly after appropriate adaptation, as in this example.
 Bankmodell Definition (Gabler Banklexikon 2022); Retrieved 12/28/2022 from https://www.gabler-banklexikon.de/definition/bankmodell-70673
 As of now, this article is only available in German.