Dear,
Last week I was talking to a customer who is considering implementing Source Data Aggregation in its Bank Analyzer - Accounting for Financial Instruments System.
For those of you who are not familiar with Source Data Aggregation, let me give you a brief description of the functionality.
Source Data Aggregation is a standard functionality of Bank Analyzer, fully available from release 7 which has the objective of reducing the size of the database in accounting calculations with no information lost. For doing that the system stores RDL related data aggregating the information of homogenous contracts.
But reducing the size of a database with no information lost requires to follow some rules.
1) We must identify the components which offer a better opportunity for reducing the database size.
Simplifying, Bank Analyzer stores data in the Source Data Layer and the Results Data Layer.
The Source Data Layer stores the Primary Objects (Master Data, Transactional Data and Market Data), while the Results Data Layer stores the interpretation of the Transactional Data from Accounting Principles (AFI calculations) and Basel III Credit-Risk Calculations.
If you check the size of the Bank Analyzer database, you will see that the size of the tables storing Results Data Layer data is much bigger than Source Data Layer data. Consequently, we have a much better opportunity of reducing the database size by looking at the RDL instead of the SDL.
2) We need to understand how can we reduce the size of the database and not loosing information in the process.
The valuation of Financial Contracts follows two basic approaches; Nominal and Fair Value. Bank Analyzer supports both approaches. For some products, like Customer Accounts (Saving or Checking) the difference between both valuations is immaterial, for others like Mortgage Loans the difference between Nominal Accounting and Fair Value Accounting is very significant.
On the other hand, calculations for determining the components of the Nominal Valuation of Financial Transactions are contained in the Transactional Banking System and consequently they´re also available in the Source Data Layer.
Simplifying; we have an opportunity of reducing the size of the database by reducing the Results Data Layer related data, and not loosing information in the process by aggregating Nominal Accounting based products (like current or savings accounts).
My customer was explained the above, but as my customer is an smart person he asked; how can I get the nominal accounting data by contract level (Current and Savings Accounts) if that data is not available by contract in the Results Data Layer?
Unfortunately whoever explained him the Source Data Layer Aggregation functionality forgot to mention that this data can be obtained very easily from the Source Data Layer, that has not been aggregated, so he thought he was losing information by using Source Data Aggregation.
This post is a simplification and it can never replace the proper analysis that must be performed before a Source Data Aggregation project is implemented.
I just tried to make a point with it, SAP Bank Analyzer is an amazing product, but implementing it requires to follow some rules, and it´s important we explain those rules properly.
Looking forward to read your opinions.
K. Regards,
Ferran.
Last week I was talking to a customer who is considering implementing Source Data Aggregation in its Bank Analyzer - Accounting for Financial Instruments System.
For those of you who are not familiar with Source Data Aggregation, let me give you a brief description of the functionality.
Source Data Aggregation is a standard functionality of Bank Analyzer, fully available from release 7 which has the objective of reducing the size of the database in accounting calculations with no information lost. For doing that the system stores RDL related data aggregating the information of homogenous contracts.
But reducing the size of a database with no information lost requires to follow some rules.
1) We must identify the components which offer a better opportunity for reducing the database size.
Simplifying, Bank Analyzer stores data in the Source Data Layer and the Results Data Layer.
The Source Data Layer stores the Primary Objects (Master Data, Transactional Data and Market Data), while the Results Data Layer stores the interpretation of the Transactional Data from Accounting Principles (AFI calculations) and Basel III Credit-Risk Calculations.
If you check the size of the Bank Analyzer database, you will see that the size of the tables storing Results Data Layer data is much bigger than Source Data Layer data. Consequently, we have a much better opportunity of reducing the database size by looking at the RDL instead of the SDL.
2) We need to understand how can we reduce the size of the database and not loosing information in the process.
The valuation of Financial Contracts follows two basic approaches; Nominal and Fair Value. Bank Analyzer supports both approaches. For some products, like Customer Accounts (Saving or Checking) the difference between both valuations is immaterial, for others like Mortgage Loans the difference between Nominal Accounting and Fair Value Accounting is very significant.
On the other hand, calculations for determining the components of the Nominal Valuation of Financial Transactions are contained in the Transactional Banking System and consequently they´re also available in the Source Data Layer.
Simplifying; we have an opportunity of reducing the size of the database by reducing the Results Data Layer related data, and not loosing information in the process by aggregating Nominal Accounting based products (like current or savings accounts).
My customer was explained the above, but as my customer is an smart person he asked; how can I get the nominal accounting data by contract level (Current and Savings Accounts) if that data is not available by contract in the Results Data Layer?
Unfortunately whoever explained him the Source Data Layer Aggregation functionality forgot to mention that this data can be obtained very easily from the Source Data Layer, that has not been aggregated, so he thought he was losing information by using Source Data Aggregation.
This post is a simplification and it can never replace the proper analysis that must be performed before a Source Data Aggregation project is implemented.
I just tried to make a point with it, SAP Bank Analyzer is an amazing product, but implementing it requires to follow some rules, and it´s important we explain those rules properly.
Looking forward to read your opinions.
K. Regards,
Ferran.
No comments:
Post a Comment