Thursday, April 14, 2016

Reducing Operational costs in SAP Banking with Standard Integration of Operational and Analytics.



Dear,

One of the main concerns of bank's CIO's is reducing operational costs, in times of limited growth or recession it's critical to eliminate processes which are not giving value to the organization.

Legacy banking systems lack in strong integration capabilities between the Operational and Analytical Banking Systems, forcing the bank's CIO's to spend an important part of the IT department's budget in maintaining interfaces with different data-models.

This was not different in the first versions of the SAP Banking platform; in fact the first versions of Bank Analyzer didn't offer standard interfaces between the Operational and Analytical components of the SAP Banking suite.

This started was to change with versions 6 and 7 of SAP Banking Services which started to provide a standard integration for Loans and Deposits between Operational Banking and Bank Analyzer – AFI.

Current versions of Banking Services offer standard integration of Bank Accounts (Loans and Deposits) as Financial Transactions in Bank Analyzer, and Payment Items as Business Transactions (including Payment Distribution logic for Loans).

The advantages of the standard integration are multiple:

- Total Cost of Ownership Reduction.

- Reduction of Operational Errors.

- Simple reconciliation between Operational Banking events and Accounting entries.

- Improved Systems performance.

But overall, the standard integration of Operational and Analytical Banking incentivise looking at the Financial Assets and Liabilities in a holistic way. We're in the middle of a Systemic Transformation of the Banking System from a model based in Volume to a model based in efficient management of the Capital and Liquidity.

Efficient management and Liquidity requires a bi-directional communication between the Operational and Analytical Banking System; the Analytical Banking System will identify the Gaps and Opportunities of Investment (Gap Analysis, NPV Analysis, etc.) that will define the business objectives. And the business objectives will be executed by the Operational System.

On the other hand, the Analytical Banking system requires accurate Operational data for running the Liquidity and Capital Analysis and managing efficiently the Bank's portfolio.

With the deployment of SAP Hana initiatives in the Banking Industry, someday we'll have “Simple Banking” system with very deep integration between the Operational and the Analytical Banking components. In the meantime, as in preparation for this scenario, there are important advantages in considering standard IOA (services oriented) interfaces, compared to the traditional ETL based interfaces.

ETL interfaces are too malleable, and don't limit the interface its natural capabilities; for instance I've seen customers implementing very complex accounting logics in the ETL interface.

This approach is not only wrong, it also damages other elements of the Analytical Banking system.

The objective of an interface is transferring data, and in the worst case, cleaning, and transforming data provided by the source system, so it can be used by the destination system.


By adding business logic to the interface, we break the consistency rule; the Source Data Layer is no longer mirroring the Operational Data. Additionally the accounting rules implemented in the ETL collide with the responsibilities of the Process and Methods Layer.

As the Source Data Layer has some kind of “accounting influenced” data, the PML does not receive the Operational Data that expects, so the PML has to be modified for processing it, making the Snowball bigger and bigger, and moving the system away from the standard.

Clients who have followed this approach are suffering from under-performing processes and higher rates of Operational errors and costs.

Additionally, moving away from the standard delivery of the bank analyzer system, will make it more difficult for them to take advantage of a future functionalities of the SAP Bank Analyzer system.

For instance, I recently worked in a Proof of Concept for implementing the Basel III – Credit Risk module of SAP Bank Analyzer, in a bank which has already implemented the Accounting for Financial Instruments functionalities.

Theoretically, and taking advantage of the Integrated Financial and Risk Architecture, once you have implemented the AFI module, you have most, if not all, the data necessary for implementing the Basel III – Credit Risk functionalities in the Source Data Layer.

- Business Partners are already available in Bank Analyzer.

- Financial Transactions.

- Yield Curves.

- Foreign Exchange rates.

- Ratings.

Additionally, you can get the necessary data for updating the Positions and Position Master Data from the Bank Analyzer positions; reading the Results Data Layer – Financial Position Objects, with a CVPM process, and delivering the data to the SDL, or directly to the Credit Risk Analyzer.

This integration requires accurate Operational Data, and standard interfaces are the best option to collect and process them.


Join the SAP Banking Group at: http://www.linkedin.com/e/gis/92860

Looking forward to read your opinions.
K. Regards,
Ferran.

No comments: