Dear,
One of the last components in joining the Layers architecture of Bank Analyzer has been the Results Data Layer (RDL), which is available since the Version 5.
When 7 years ago I was working in my first Bank Analyzer project, the system didn't have a Results Data Layer. The functions of storing results data coming from the Process and Methods Layer, was performed by the Results Data Base, which was an evolution of the component with the same name in SEM Banking.
At the time, we heard that with the new Bank Analyzer 5.0, the RDB was going to be replaced by a new component called RDL, whose main difference with the RDB is that the RDL supports the storage of non-Bank Analyzer originated data.
My first Bank Analyzer project was a Credit Risk/Basel II implementation in Bank Analyzer 4.2. When the project team heard about the RDL we saw it could be very useful for storing risk parameters (Loss Given Default, Exposure at Default, etc.) of risk exposures not-included in the scope of the project, and whose risk parameters, were not calculated by Bank Analyzer.
As the RDL was not available at the time we follow the work around of storing the data directly in the Operational Data Stores and Infocubes for the Basel II regulatory reporting of BIW; obviously with a much weaker level of integration.
The main priority for the Bank’s executives at the time was to get the approval by the audit authorities of the central bank. For the audit authorities there was no much difference in using the RDL or not, as they did not have the capacity of checking the source of the data provided in the reporting results.
Integrated systems, capable of offering reconciling functionalities between the Transactional and Analytical Banking systems, were not available at the time, and the capacity of the auditors for requesting these reconcilable reports was very limited.
This is one of the reasons while the Financial Situation is what it is, reconciliation capabilities between Analytical and Transactional Banking information are “control oriented” functionalities. We come from a Banking system driven by volume, in which capital consumption control was not the priority, with the catastrophic consequences we witnessed in 2008 and we’re still suffering 5 years later.
By the way, if we want make SAP Banking a successful business, we should educate the audit authorities about its reconciliation and reporting capabilities.
Remember; solvency is not only what it is, it is also what it looks like.
http://sapbank.blogspot.com.es/2010/07/stress-testing-what-solvency-is-and.html
After this first Bank Analyzer project I always have had the Results Data Layer available for the integration of accounting or credit risk data that for some reasons (project scope, technical limitations, etc.) could not be managed by the standard Bank Analyzer flow (Source Data Layer -> Process and Methods Layer -> Results Data Layer).
A typical example is the uploading Provision postings for Impaired Loans in the Bank Analyzer RDL. As previous versions of Bank Analyzer couldn't calculate provisions for impaired loans, we would calculate those provisions in the Reserves for Bad Debts module of IS-Banking, and upload the accounting postings of those provisions directly in the RDL. Consequently, the Bank enjoyed in the AFI sub-ledger the full vision of the Loans valuation, including impairment provisions.
Another example is the calculation of Hedge Accounting adjustments; valuation of Derivatives products and Hedge Accounting adjustments are initially calculated outside of Bank Analyzer and uploaded to the RDL; from there they enjoy the standard integration with the Financial Statements and the General Ledger.
But the open architecture of the RDL opens the gate for more challenging integration scenarios; we’ll talk about some of them next week.
K. Regards,
Ferran.
One of the last components in joining the Layers architecture of Bank Analyzer has been the Results Data Layer (RDL), which is available since the Version 5.
When 7 years ago I was working in my first Bank Analyzer project, the system didn't have a Results Data Layer. The functions of storing results data coming from the Process and Methods Layer, was performed by the Results Data Base, which was an evolution of the component with the same name in SEM Banking.
At the time, we heard that with the new Bank Analyzer 5.0, the RDB was going to be replaced by a new component called RDL, whose main difference with the RDB is that the RDL supports the storage of non-Bank Analyzer originated data.
My first Bank Analyzer project was a Credit Risk/Basel II implementation in Bank Analyzer 4.2. When the project team heard about the RDL we saw it could be very useful for storing risk parameters (Loss Given Default, Exposure at Default, etc.) of risk exposures not-included in the scope of the project, and whose risk parameters, were not calculated by Bank Analyzer.
As the RDL was not available at the time we follow the work around of storing the data directly in the Operational Data Stores and Infocubes for the Basel II regulatory reporting of BIW; obviously with a much weaker level of integration.
The main priority for the Bank’s executives at the time was to get the approval by the audit authorities of the central bank. For the audit authorities there was no much difference in using the RDL or not, as they did not have the capacity of checking the source of the data provided in the reporting results.
Integrated systems, capable of offering reconciling functionalities between the Transactional and Analytical Banking systems, were not available at the time, and the capacity of the auditors for requesting these reconcilable reports was very limited.
This is one of the reasons while the Financial Situation is what it is, reconciliation capabilities between Analytical and Transactional Banking information are “control oriented” functionalities. We come from a Banking system driven by volume, in which capital consumption control was not the priority, with the catastrophic consequences we witnessed in 2008 and we’re still suffering 5 years later.
By the way, if we want make SAP Banking a successful business, we should educate the audit authorities about its reconciliation and reporting capabilities.
Remember; solvency is not only what it is, it is also what it looks like.
http://sapbank.blogspot.com.es/2010/07/stress-testing-what-solvency-is-and.html
After this first Bank Analyzer project I always have had the Results Data Layer available for the integration of accounting or credit risk data that for some reasons (project scope, technical limitations, etc.) could not be managed by the standard Bank Analyzer flow (Source Data Layer -> Process and Methods Layer -> Results Data Layer).
A typical example is the uploading Provision postings for Impaired Loans in the Bank Analyzer RDL. As previous versions of Bank Analyzer couldn't calculate provisions for impaired loans, we would calculate those provisions in the Reserves for Bad Debts module of IS-Banking, and upload the accounting postings of those provisions directly in the RDL. Consequently, the Bank enjoyed in the AFI sub-ledger the full vision of the Loans valuation, including impairment provisions.
Another example is the calculation of Hedge Accounting adjustments; valuation of Derivatives products and Hedge Accounting adjustments are initially calculated outside of Bank Analyzer and uploaded to the RDL; from there they enjoy the standard integration with the Financial Statements and the General Ledger.
But the open architecture of the RDL opens the gate for more challenging integration scenarios; we’ll talk about some of them next week.
K. Regards,
Ferran.
No comments:
Post a Comment