The Bank of Slovenia has recently implemented a second package of integrated data requirements for monetary financial institutions (see Kranjec, 2010). The requirements for supervision and statistics are highly integrated into the matrix system. In addition to the balance sheet requirements, income statement guidelines are also being devel- oped (Peeraer et al., 2008). In the gradual development thus far, the National Central Bank and the banking community have been looking for the balance sheet items that best fit together, both for supervisory (financial stability) and for statistical needs. In fact, the new chart of accounts or general ledger has been defined as the final result, namely, the backbone of the matrix reporting system. The legally prescribed chart of accounts has worked like an anchor in the development phase and leaves no doubts about the quality of information provided. Com- piling relatively different requirements from an information system perspective requires high granulation of data. The usefulness of data
records received in this manner might be universal, but is highly depen- dent on the level of quality. The system requires banks to focus in a standardised manner on clients and financial instruments. Therefore, fully integrated accounting information systems (enterprise resource planning systems) at banks represent a precondition for the success of the project, which is already expanding to other financial intermedi- aries and their supervisory authorities. We see many advantages, not only for an improved supervisory function, but also in the area of statis- tics and analysis in the decision support system at various levels. Let us describe the matrix system, as the core of the concept, in a bit more detail.
Accounting, with its double-entry treatment of business events, rep- resents the language of economics. During the time of the National Bank of Slovenia, which operated within the framework of the mon- etary authorities of the National Bank of Yugoslavia, the collection of balance sheet data for supervisory needs was based on a prescribed chart of accounts for banks and savings banks. Instructions concerning the recording of business events at banks represented an integral part of this system. In Slovenia, an economic category of the basic financial state- ments was sequentially numbered applying a decimal principle, which facilitated the creation of a simple hierarchy: category, group and basic account.
Following monetary independence in October 1991, in particular with publications in the first half of 1992, Bank of Slovenia experts com- piled the first macroeconomic accounts for Slovenia as an independent state. With regard to banking and monetary statistics, they used book figures from banks, which were also used for supervisory purposes, and compiled the banking system’s consolidated balance sheet. Combining this with the Bank of Slovenia’s balance sheet determines the consoli- dated balance sheet of the monetary system, and thus all basic monetary aggregates: M1–M3 (from narrower, more liquid monetary categories to broader, less liquid monetary categories). At that time, the manuals of the International Monetary Fund (IMF) represented the methodologi- cal basis. A double-entry technique was also used to compile Slovenia’s first balance of payments, where the primary source of data was based on codes for payment transactions with the rest of the world (pay- ment purpose) via Slovenian banks. In subsequent years, an attempt was made to supplement macroeconomic financial statistics with domestic payment transaction figures and to compile a table of flows of funds.
With the gradual shift from statistics derived from payment transactions due to a single payment system under conditions of a single monetary
unit, namely the euro, the collection of data from accounting records is also being applied to sector account statistics, where the basic account- ing principle set out in the methodology of the European System of Accounts (ESA 95) is followed.
With its essence in the double-entry treatment of business events, accounting is important not only at the micro level, but also at the macro level of economic study, where entries are doubled and reflected through different sides of the balance sheets of the (typically) two par- ties to a transaction. In the broadest sense, at the macroeconomic level, we therefore talk about sector accounts, where economic agents are also grouped by sectors of the economy. The economic process itself is basically separated into a sequence of accounts comprising non- financial (accounts for generating and distributing income, savings, consumption and investment) and financial (all financial instruments) parts.
Slovenia was quick on its way to European integration. In terms of data sources and methodological solutions, the Bank of Slovenia was faced with the demanding tasks of harmonising macroeconomic statis- tics and the need to ensure complete methodological comparison of economic aggregates measured for Slovenia with other developed Euro- pean countries, taking into account the desired integrations. At the end of 2001, the need to reform the existing reporting system for banks and savings banks was recognised. The chart of accounts only facil- itated the four-dimensional treatment of a transaction (for example, currency, sector, instrument and maturity), and did not permit sys- tematic expansion (the decimal system itself represents a mathematical limitation at the hierarchical level). The multidimensionality of the sys- tematic study of events was possible due to the rapid technological development of database management (relational databases and data warehouses) and the development of electronic communications. The need for the increased flexibility of the reporting system arose simply due to the expansion of requirements, but also on account of the sys- temisation of these requirements in a multidimensional space and the related standardised treatment of events. The example of others (Banca d’Italia, 1992) led to the idea of the integration of various reports in the scope of a ‘balance-sheet backbone’ of the reporting system, which in principle will always be based on the double-entry measurement or treatment of economic events.
Following Slovenia’s inclusion in the euro area, active cooperation with monetary financial institutions (MFIs) began during the second half of 2007 with regard to the development of the new reporting
Code of the report Reporting date Type of the record Successive number of the recordReporter Sector Country Currency Original maturity Type of loans Client’s rating Existing/new business Type of colleteral Code of the counterparty Amount All-In Cost (interest rate + ...)
1 2 3 4 5 6 9 11 13 14 16 18 19 25 26 28 33
REPORTING ITEMS
CODE LISTS CODE LISTS CODE LISTS
Cash
Accounts at the central bank Claims to the central bank Loans
Debt securities
i.e. S.11,S.121...(ESA95) i.e. 044,008...(ISO4207)
Figure 5.2 Matrix of integrated reporting requirements
Note: Theoretically the maximum number of submitted records for a particular item depends on the number of codes requested and the number of attributes on each code list.
Source: Bank of Slovenia, comprehensive matrix, January 2009, extract of selected items.
concept, which is valid today. The second phase represents the expan- sion of the basic elements of the matrix, namely, report items, with the inclusion of concepts related to the supervision of banking operations.
In the described development process of the new reporting concept, a critical evaluation of the comparability with the previous reporting sys- tem (for example, the chart of accounts and the number of separate reports with aggregate information) was urgent.
The solution for integrated reporting requirement for banks and savings banks may be shown in the form of a matrix (see Figure 5.2).
Defined reporting requirements in the form of a matrix with their sys- tematic organisation of a multidimensional space facilitate the increased flexibility of reporting in terms of including new requirements at a given moment in time. Minor changes generally mean supplementing exist- ing codes with additional attribute values. Theoretically, the difficulty is linked to changes arising with the introduction of new codes, new items and, in particular, with requests to break down existing items or codes. The Bank of Slovenia is, therefore, avoiding the latter in the second phase of the transition to the comprehensive matrix. Of course, the complexity of amendments depends on the combination of changes in the multidimensional space of a report or attribute item, with
respect to the informational organisation of a specific work process at banks.
The combination of items and codes frequently facilitates the break- down (granulation, in terms of data warehouses) of requests at the level of an individual transaction. This increases the level of detail and pro- vides for the improved quality of input data, in terms of their identity with regard to a business event. This offers the possibility of using the data for a variety of purposes.
The requirements of various expert departments in the study of bank- ing activities are defined in standard codes, where a list of code is unified (for example, ‘type of insurance’), which generally reflects a less than optimal, but sufficient, solution to a problem in terms of the level of quality. Merging, therefore, facilitates material rationalisation and does not permit duplication in terms of arriving at the same results from different definitions. The latter also results in increased misunderstand- ing by reporting entities. Such a material organisation also requires logistical centralisation by reporting entities and data recipients, and thus dictates organisational rationalisation. Achieving the aforemen- tioned advantages in technical and technological terms is conditional on the development of relational databases and data warehouses (see Box 5.1).
Box 5.1 The data warehouse technology
Hierarchical flow Child–parent dimension
Figure 5B.1 Flow of the hierarchical dimension: sector
Note: A bank client who receives a loan (item ‘loans, excluding syndicated loans’ in Figure 5.2) belongs to a specific sector of the economy. The code in question may also be organised in a hierarchical dimension of the data warehouse, as seen in Figure B5.1.
Source: MS SQL 2000 – data warehouse model, 2007.
sector
sector/country sector/country
sector/country country/loan
type country/loan type country/loan type
country/currency country/currency country/currency loan type
loan type loan type all
currency
loan type/currency country
country country
sector/country/
loan type sector/country/
loan type sector/country/
loan type sector/country/
currency sector/country/
currency sector/country/
currency
sector/loan type/currency sector/loan type/currency sector/loan type/currency
country/loan type/currency
sector/country/loan type/currency
0 - D (apex) cuboid
1 - D
2 - D
3 - D
4 - D (base) cuboid sector/
currency sector/
currency sector/
currency sector/loan type sector/loan type sector/loan type
Figure 5B.2 Level of possible aggregation of the four-dimensional value of a variable: report item ‘loans, excluding syndicated loans’
Notes: We consider four codes, the values (facts) of which are reported by report item
‘loans, excluding syndicated loans’ from the matrix in Figure 5.2. These are: sector, country, currency and loan type. Figure 5B.2 illustrates all possible levels of aggregation of the four-dimensional treatment of an event. An individual level of aggregation has multiple calculations with regard to the hierarchical level of a specific dimension and to the individual value of a variable at a specific level (the value of a set of codes at a specific hierarchical level).
Source: Lattice of cuboids, making up a 4-D data cube for the dimensions (Han and Kamber, 2001, p. 48).
Type of loan
Type of interest rate Maturity
Purpose
Up to/
more than 2 years
Registration number
Client Credit rating
Client sector Economy
Residence
Sub-sector Sector
Interest rate (%) Loan value (EUR) Reference interest rate
Fixed interest rate
Currency clause
Elements
Figure 5B.3 Continued
Figure 5B.3 Multidimensional space of the study of banks’ credit activity:
data warehouse model
Notes: Figure 5B.3 illustrates an example of the systematic analysis of a
multidimensional space based on a matrix report and data regarding bank interest rates.
In analytical terms, codes organised in dimensions facilitate the more flexible and rapid treatment of events, namely the use of OLAP (Online analytical processing, i.e. direct analytical treatment of events) technologies in data warehouses. Theoretically, we can say that the simultaneous use of three or four different, hierarchically organised codes permits us to move in various desired hyper-planes in a multidimensional space.
Source: Bohanec (2002).
The comprehensive matrix represents the actual material integration of the supervisory, statistical and other functions of the central bank in terms of data requirements from MFI in the manner of the concept presented in Figure 5.1. The merging of balances and flows in terms of fact tables (for example, amounts and interest rate levels) from a data point of view requires the further strengthening of input controls of the quality of data at the Bank of Slovenia, as well as an improvement in the level of integration of accounting information systems at banks. In a business sense, this is consistent with the need to focus on the client by standardising the measurement of operations by banks and savings banks with the aim of managing risks and improving operating results.
The analytical evidence required by combining report items (instru- ments) and codes (attributes of clients and transactions) must be derived from a focus on the customer during a banking transaction. This evi- dence must be integrated in the general ledgers of banks via ‘settlement accounts’. Only in this way will detailed (granulated) data in banks’ data warehouses, as a result of systematic analytical evidence, be a logical and integral part of the prescribed general ledger of banks (for example, the chart of accounts). Enterprise Resource Planning (ERP) business informa- tion systems provide the appropriate parametric solutions by automated recording. All that is required is an appropriate link (programme inter- faces) with accounting modules, which ensure the direct execution and recording of transactions with clients by banks.
A two-tier reporting system with a summarised general ledger is always the logical first phase, both to verify the level of integration of banks’
accounting information systems and due to the rapid access to aggre- gate information for decision-making (Figure 5.3). This two-tier concept in computer-supported solutions does represent an additional burden on reporting entities. With the updating of the ‘KNB’ report (report- ing in accordance with the prescribed chart of accounts), which will be
Data capture – summarisation
Double-entry in the general ledger (recommendation for booking) Opposing account Settlement account
Report item
Loan
Modular solutions
Code content
Client
Data capture – matrix report
Sector Country Currency Loan type ... Amount
Transaction (instrument)
A code attribute value in combination with a report item define the booking
in the ERP system
Figure 5.3 Modular connectivity of analytics in the general ledger with the double-entry treatment of business events via ‘settlement accounts’ and a system of matrix reporting
Source: Instructions on the Reporting by Monetary Financial Institutions, Bank of Slovenia (2007a,b), and the Monitoring of Business Events in Accordance with the IFRS, BAS, 2008.
directly comparable with the report items of the comprehensive matrix, it will also be easier to compile recommendations for the accounting of business events at banks.
New report items reflect the basic economic categories and the nature of today’s operations of credit institutions, and are therefore more removed from the ‘old’ chart of accounts to which the select reporting matrix was linked. Reporting systems must ensure full integration.
A ‘comprehensive’ matrix nowadays also includes the European Bank- ing Authority (EBA) data requirements from Financial Reporting (FIN- REP) templates, balance sheet and income statement schemes on an individual basis, and all latest amendments to ECB regulations (balance sheet, interest rates and other requirements) as well as requirements for financial accounts statistics.