Solvency II, IFRS 17 and SAP Financial Products Subledger.

Dear,

As you probably know, since January 1st 2016, all the European insurance companies must be compliant with the new Solvency II Directive. Additionally, on January 1st, 2021 becomes effective the new Accounting Standard IFRS 17 for Insurance Contracts.

The European Union Solvency II Directive represents a major change in the insurance industry regulation. The Directive's main priorities are increasing the solvency of the Insurance companies and harmonizing the EU regulation, with the final objective of achieving a solvent and single EU insurance market.

From some perspective, the Solvency II regulation represents to the insurance companies what the Basel III and the EU Bank Recovery and Resolution Directive represents to the European banks.

This is a major challenge on the Information Systems of the Insurance companies, just for giving you an idea of the complexity of implementing these regulations, we must consider that the final implementation date has been delayed 4 years from the initial proposals. Initially, regulators looked at October of 2012 as the implementation date.

Among many other changes, implementing Solvency II has requested the creation of the European Insurance and Occupational Pensions Authority (EIOPA) that, with more competencies, replaces the Committee of European Insurance and Occupational Pensions Supervisors (CEIOPS).

The Solvency II Directive is structured in three main areas or Principles.

- Pillar 1 establishes the quantitative models which must prove that the insurance company has the capacity to fulfill its obligations, like determining the capital requirements.

- Pillar 2 sets out requirements for the governance and risk management framework that identify and measure the risk to which the insurance company is exposed, and the supervision model.

- Pillar 3 focuses on disclosure and reporting of the company risk exposures and capital requirements.

For helping insurance companies to meet with the Solvency II and IFRS 17 regulations, SAP has delivered the SAP Financial Products Subledger and Solvency 2 Ssytems.

Technically the SAP FPSL system is an evolution of the Bank Analyzer system, it's also built following the principles of the Integrated Financial and Risk Architecture, providing the full potentiality of the Financial Database.

As Bank Analyzer, the SAP FPSL System provides two groups of functionalities or modules.

- SAP Accounting for Insurance Contracts, equivalent to the Accounting for Financial Instruments module of Bank Analyzer.

- Solvency Management for Insurers, equivalent to the Credit Risk Analyzer (Basel III) module of Bank Analyzer.

And as in Bank Analyzer, the Insurance Analyzer System is also structured in 4 Layers.

- Source Data Layer.

- Processes and Methods Layer.

- Results Data Layer.

- Analytical Layer

The final objective of this 4 Layer Architecture is providing a single source of truth for Accounting, Risk and Liquidity Information

As it happens with the banks, in which sophisticated reporting tools have to coexist with non-integrated, heterogeneous operational systems, often supported by manual processes and non-integrated spreadsheets, it's going to take years before the insurance companies are fully compliant with the Data Governance requirements of the new regulation.

During this transition, the Data Governance capabilities of the 4 Layers, Integrated Financial and Risk Architecture of Insurance Analyzer will be a great help.

On the Source Data Layer, we can integrate all the data, provided by heterogeneous legacy systems, in an homogeneous Data-model of Master, Operational and Market Data.

For Instance.- Many insurance companies lack on an integrated vision of their customers data. Customers data is spread among legacy systems with very limited integration with each other, which is a root cause for undetectable fraud and inaccurate risk management.

With SAP FPSL, the insurer company can integrate in the Source Data Layer all these divergent versions of their Customer data in a single and integrated repository, building the foundation for customer-centric analysis of profitability and risk management.

Transforming the whole landscape of an Insurance company will represent an enormous effort of systems migration that will require much of the company resources. Without the integrated risk & accounting vision of Insurance Analyzer, it's not possible to align the IT strategy on the direction of the new requirements of Solvency II and IFRS 17, which are going to be the main concern for the IT executives of the industry in the oncoming years.

At the end, the stability of the insurance industry is not just a European issue, the global industry is facing major challenges, as it moves to a model driven by efficient management of Capital, and very sensitive to risk management.

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

Looking forward to read your opinions.

K. Regards,

Ferran.

www.capitency.com

Join the SAP Banking Group at: https://www.linkedin.com/groups/92860

Visit my SAP Banking Blog at: http://sapbank.blogspot.com/

Let's connect on Twitter: @FerranFrancesGi

Ferran.frances@capitency.com

SAP Profitability and Performance Management, Analytical Accounting and Data Governance.

Dear All,

Some months ago, we shared some impressions about the new SAP Profitability and Performance Management (A.k.a FS-PER).

https://www.linkedin.com/pulse/sap-performance-management-financial-services-fs-per-ferran-frances/

Since then, some relevant updates deserve we look again at this very interesting product.

The first one is the new name, the old SAP Financial Services Performance Management Solution now is called SAP Profitability and Performance Management.

Also, with the new name, SAP Profitability and Performance Management comes with a bigger Business Content, covering a wider scope of industries, including Telecom, Public Sector, Oil & Gas, Healthcare, Utilities, Transportation and Logistics Providers, Consumer Products, Automotive, Retail, etc.

Additionally, now SAP Profitability and Performance Management is available in both On-Premise and On-Cloud delivery.

In my opinion, there is some overlapping between the functionalities offered by SAP Profitability and Performance Management and SAP Business Planning & Consolidation for S/4HANA, particularly outside of Financial Services and Insurance industries.

https://blogs.sap.com/2017/03/07/sap-business-planning-consolidation-for-s4hana-short-and-sweet/

On the other hand, since the release of SAP Financial Products Sub-Ledger (SAP-FPSL), the border between SAP Financial Services and Non-Financial Services solutions (other industries) is much narrower and the capacity of integrating Financial Services Business Process and Non-Financial Services Business Processes is much bigger.

Since the release of Smart-AFI and SAP FPSL, we missed an Accounting for Financial Instruments Solution including strong Funds Transfer Pricing and Internal Costs (Standard, Operational and Capital Costs) functionalities. With Classic-AFI we had Profitability Analysis as and Integrated Financial and Management Accounting solution for Financial Instruments, but the solution was not included in Smart-AFI and SAP FPSL.

SAP Profitability and Performance Management covers this gap. The Funds Transfer Pricing Business Content of SAP PaPM gives us the possibility of determining the Funding Costs of Financial Instruments, but it’s open architecture and capacity of connecting agnostically to any SAP and Non-SAP Data Provider and Repository (FI-CO, FPSL-SDL, FPSL-RDL, SAP-BW, HANA-Tables, etc.) also offers the possibility to leverage all its calculation functionalities to practically any Business Process.

Same logic applies to the Calculation of Capital and Operational Costs; SAP PaPM Business Content comes with many scenarios for the management, allocation and distribution of Direct and Indirect Costs.

But this flexibility also brings a challenge, Data Governance is a big opportunity for improvement in most of the banks, and implementing SAP PaPM with a previous redefinition of a centralized data-model can increase the risk of adding complexity to the banks IT landscape.

A very few banks have a robust, reconcilable central repository of Operational and Analytical Data. As we mentioned in a previous blog, SAP Banking data-model offers this capacity, but the reality is that only a few banks have seen already the competitive advantage of the SAP Integrated Financial and Risk Architecture.

https://www.linkedin.com/pulse/central-data-hubs-sap-finance-risk-platform-ferran-frances/

In my opinion, it’s becoming mandatory a very hard exercise of redefinition of the Banks IT Architecture focused on improvement of the Data Governance, and the regulator is going to make it clear very soon.

https://www.bis.org/publ/bcbs239.pdf

Looking forward to read your opinions.

K. Regards,

Ferran.

www.capitency.com

Join the SAP Banking Group at: https://www.linkedin.com/groups/92860

Visit my SAP Banking Blog at: http://sapbank.blogspot.com/

Let's connect on Twitter: @FerranFrancesGi

Ferran.frances@capitency.com

Get ready for the Targeted Review of Internal Models with SAP Bank Analyzer – Credit Risk.

Dear all,
In December 2015 the European Central Bank decided that it would carry out a project to assess whether the internal models currently used by banks comply with regulatory requirements, and whether their results are reliable and comparable.

Since the 2008 Financial Crisis regulators have shown concerns about the use of internal models to determine Risk Weighted Assets and Regulatory Capital Requirements, mainly due to two reasons.

- Complexity of the Models which make difficult to asses whether risks are being mapped correctly and consistently.

- High variability and potential inconsistencies between the Risk Weighted Assets and Regulatory Capital Requirements calculated by different banks with similar portfolios when each one of them used their own internal models.

Basel II agreement trusted in the bank’s capacity for developing their own internal risk models for the calculation of credit, operational and market risk exposures and their correspondent calculation of the Capital Requirements. Unfortunately, in my experience, many banks rely in lightly formalized and difficult to audit risk models, including the use of desktop based spreadsheets.

On January 2013 the Basel Committee on Banking Supervision issued the Document "BCBS 239: Principles for effective risk data aggregation and risk reporting" establishing the 14 Principles for risk data aggregation that banks should follow.
To some extend, these 14 Principles established the generic guidelines that some years later have been formalized in TRIM.
I shared some details about it four years ago.
https://www.linkedin.com/pulse/bcbs-239-principles-sap-bank-analyzer-ferran-frances-gil/

Another alert came from the European Banking Authority, that on March 2015 issued a consultation paper called "Future of the IRB Approach" which concluded that there are significant differences in the application of the IRB requirements in EU banks, and subsequently divergences in the risk estimates and capital requirements, that cannot be explained by the differences in risk profiles.

https://eba.europa.eu/documents/10180/1003460/EBA-DP-2015-01+DP+on+the+future+of+IRB+approach.pdf

TRIM presents important challenges to banks.
Most banks present heterogeneous and very low quality data spread in different silos, lacking on tracking capabilities to the bank’s Operational Systems.

Although banks IT architects are trying to improve the situation with the building of Central Data Hubs, I am pessimistic about the final result.

Central Data Hubs are designed following the add-hoc/on-demand approach. Data architects collect data requirements from the data consumer systems, and design the data repository according to these requirements. And then, define the interfaces for collecting data from the source systems and populating the data in the destination systems.

To some extend, this approach implies reinventing the wheel, according to the bank’s own experience, and limited integration capabilities of the bank’s information architecture.

Additionally, regulation evolves, and new requirements force the data architects to enhance the multiple repository tables and in/out interfaces, compromising the integrity of the initial design.

You can find some details here.
https://www.linkedin.com/pulse/central-data-hubs-sap-finance-risk-platform-ferran-frances/

SAP Bank Analyzer – Credit Risk provides an strong framework of tools for fulfilling the Targeted Review of Internal Models.

- The Source Data Layer provides a Central Repository of homogeneous Operational Data (Master and Transaction Data).

The Primary Data Objects of the Bank Analyzer Source Data Layer have been designed to cover the Analytical and Regulatory requirements, independently of the capacities/limitations of the Operational Banking System. Bank’s architects can take advantage of these standard templates as a basic reference, trusting that the regulatory requirements will be fulfilled, and performing a gap analysis which helps them to identify data inaccuracies and redundancies.

- The Extract, Transformation and Loading capabilities of SAP Smart Data Integration in Premise and in the Cloud, including the high-performing capabilities of SAP HANA for storing and managing very-high volumes of data, reducing intermediate tables and assuring the referential integrity of the database.

- The Historical Database provides the functions for Collecting Data from the Operational Banking Systems, Calculation of the Default Rates, Data Storage for the Calibration of the model and Audit and Historization capabilities.

- The Credit Exposure calculation determines the risk key figures for exposures and their collateral, meeting the requirements of the Basel III Accord.

At the same time that TRIM audits are taking place, other regulatory developments are happening, particularly implementing the IFRS9 accounting framework.

TRIM demands coherency on the result of the Expected Loss Calculations in Basel IV (Solvency) and IFRS 9 (Accounting) which require an effective collaboration between Finance and Risk divisions of the banks. In my experience, bank’s information systems lack on a common architecture and holistic data-model facilitating the reconciliation.

This is the foundation of the Integrated Financial and Risk Architecture of Bank Analyzer. And this integration has improved significantly with version 9 and Smart-Accounting.


This was just a short description, you can find more details about TRIM in the Guide issued by the ECB on February 2017, and we will talk about this topic again in future articles.
https://www.bankingsupervision.europa.eu/ecb/pub/pdf/trim_guide.en.pdf

Looking forward to read your opinions.

K. Regards,

Ferran Frances.

www.capitency.com

Join the SAP Banking Group at: https://www.linkedin.com/groups/92860

Visit my SAP Banking Blog at: http://sapbank.blogspot.com/

Let's connect on Twitter: @FerranFrancesGi

Ferran.frances@capitency.com

Capital Optimization with SAP Financial Products Subledger.

Dear all,

The Financial System is under a big stress, coming from two forces.

1) Excess of Debt ($250 Trillion). Debt consumes Capital and historically high levels of Debt reduce the Bank’s Capital available for Investing and Lending.

https://www.bloomberg.com/graphics/2019-decade-of-debt/

2) Limited Economic Growth. Capital is generated by economic growth and slow economic growth means weak Capital generation.

As we are in an economic environment of Limited Capital Generation and persistent Capital Consumption, Capital has become scarce; and don’t forget that Capital is the most important Resource of the Financial System.

Since 2008 Crisis, Bailouts and Quantitative Easing Cycles have produced the illusion that Capital was available, delaying the effects of the Capital scarcity and the necessary transformation of the Financial System.

https://www.reuters.com/article/us-eurozone-ecb-qe/the-life-and-times-of-ecb-quantitative-easing-2015-18-idUSKBN1OB1SM

I have been an SAP Analytical Banking consultant since 2006 and after 2008 Financial Crisis I thought that the time of the Financial System transformation have arrived; I was wrong.

For a decade, ultra aggressive monetary policies have delayed the problem, pushing down the yields and inflating artificially the value of the assets.

Again, this has delayed the problem of the Capital scarcity but it has not solved anything.

This week IMF urged German banking sector to accelerate restructuring.

https://www.reuters.com/article/us-germany-economy-imf/imf-urges-german-banking-sector-to-accelerate-restructuring-idUSKCN1SN14X

Reducing the Operational Costs by restructuring banks is just the first step of a much deeper transformation; the Financial System must change from a model based in Volume to a model based in Efficient Management of Capital, and this is a much more complicated challenge.

Setting Efficient Management of Capital as the main Priority requires redesigning the Bank’s Information Systems Architecture, 3 objectives need to be fulfilled.

1) Planning the bank Sales (Lending & Investment), maximizing the Profit weighted by Capital consumption.

2) Applying timely and efficiently Risk Hedging strategies.

3) Developing a Capital Allocation model which assures that Actual Sales Operations follow Sales Planning.

Planning the bank sales, maximizing the Profit weighted by Capital Consumption requires a centralized and holistic modeling of the bank’s exposures and collaterals, and an integrated calculation of the Portfolio Valuation, Capital Consumption and Provisioning.

You can find a presentation of the concept in the following Youtube link.https://www.youtube.com/watch?v=GkcVF5CWVrU&t=1s

Applying timely and efficiently Risk Hedging strategies requires detailed (Financial Transaction granularity) and fast reporting and simulation capabilities. Something that can only be achieved with the Integrated Financial and Risk Architecture of Bank Analyzer, in combination with the high-performing computing capabilities of SAP HANA.

Finally, developing a Capital Allocation model which assures that Actual Sales Operations follow Sales Planning requires a bidirectional and seamless integration between the Operational and Analytical banking system. SAP Bank Analyzer 9 offers a more simplified interface with SAP Banking Services than previous releases, and as the simplification effort pays back, the required bidirectional communication will be feasible. I will elaborate more in this topic in future articles.

Looking forward to read your opinions.

K. Regards,

Ferran Frances.

www.capitency.com

Join the SAP Banking Group at: https://www.linkedin.com/groups/92860

Visit my SAP Banking Blog at: http://sapbank.blogspot.com/

Let's connect on Twitter: @FerranFrancesGi

Ferran.frances@capitency.com

Collateral Management with SAP S/4HANA for Financial Products Subledger Data Platform.

Dear,
As you probably know, SAP recently released the new SAP S/4HANA for Financial Products Subledger https://www.youtube.com/watch?v=-veOZgkxllQ

There are many advantages on the SAP S/4HANA for Financial Products Subledger and I would need several articles for describing them, but today I will focus on its capacity for the efficient management of the Bank’s collaterals.

One of the main consequences of the 2008 Financial Crisis was the acknowledgement that the Financial System was severely under-capitalized; the issue was tackled with two complementary approaches.

Governments and Central Banks recapitalized the Financial System with Bail-Outs, Troubled Asset Relief Programs and Quantitative Easing Cycles.
Regulators put the focus on increasing and making visible the Capital Requirements with new Solvency and Accounting regulations (IFRS 9, IFRS 15, IFRS 16, IFRS 17, Basel III, Basel IV, etc.)
Recapitalizing the Financial System has been a temporary measure. Global debt has kept growing and weak economic growth has generated new capitalization tensions; more visible as the end of the Quantitative Easing Cycles has been announced in Europe.

With the normalization of the monetary policy Non Performing Assets will become illiquid, pushing down their value and increasing again the capitalization issues.

In this scenario of capital scarcity all forms of capital need to be managed efficiently, and collaterals are probably the form of capital with the poorest representation in the Bank's Information Systems.

Banking Information Systems are General Ledger centered, and as Collaterals are not represented in the Balance Sheet, Bank’s IT Architects have not paid much attention to their modelization.

As any other bank right or obligation, collaterals management has an Operational and an Analytical component.

The Operational management of collaterals focus in the technical details of the collateral and its contractual relationship with the asset, whose risk is hedging,

The Analytical management of collateral focus in the sustainable value of the collateral and its capacity for reducing the capital consumption, and limiting the impairment provision of the asset whose risk is hedging.

In Bank Analyzer and S/4HANA for Financial Products Subledger collaterals are modelled in two different objects.

As a SDL-Financial Transaction for representing the contractual relationship between the collateral and the asset.
As an RDL-entry representing the effective capacity of the collateral for reducing Credit Risk exposures and limiting impairment provisions.
Although a collateral has a Nominal Value, it can have several different Credit Risk mitigation capacities, according to the Solvency calculation approach that the bank is following; Simplified Standardized, Comprehensive Standardized, Foundation IRB and Advanced IRB.

Many times a group of collaterals is covering a group of exposures; determining the most efficient distribution of the collaterals to the exposures reduces the capital consumed which is the foundation of the Dynamic Management of Collaterals, one of the main Capital Optimization techniques.

High performance in-memory computing capabilities of HANA facilitates building simulation scenarios and stress-testing but before banks can take advantage of them, they must improve the representation of the collaterals in their Information Systems.

SAP Bank Analyzer and S/4HANA for Financial Products Subledger provides a centralized repository of collaterals, facilitating regulatory reporting, Risk Weighted Assets and Impairment provisions calculation, stress-testing of the collateral values and simulation scenarios for Capital Optimization.

This is just a brief description of some of the advantages of the Data Model of the Integrated Financial and Risk Architecture of SAP Bank Analyzer and S/4HANA for Financial Products Subledger. We’ll continue in future blogs.

Looking forward to read your opinions.

K. Regards,

Ferran.

www.capitency.com

Join the SAP Banking Group at: https://www.linkedin.com/groups/92860

Visit my SAP Banking Blog at: http://sapbank.blogspot.com/

Let's connect on Twitter: @FerranFrancesGi

Ferran.frances@capitency.com

Capital Scarcity, IFRS 9, IFRS 15, IFRS 16, IFRS 17 and Capital Optimization.

Dear,

The Financial System, and in fact the whole economy, is in a process of Systemic Transformation, from a model based in Volume to a model based in Efficient Management of Capital.

Today's economy is pulled by two forces, limited growth (due to natural resources scarcity, markets saturation, pollution, etc.) and historically high global debt ($233 Trillion, around 300% of the Gross World Product). As limited growth also limits Capital generation and global debt consumes Capital, the logical conclusion is Capital has become scarcer than ever.



Capital is the most important resource of the Financial System, which is also the most critical element of a Capitalist System (it’s the responsible of transferring and allocating capital and liquidity).



Capital scarcity makes the Financial System unstable, as we have seen since the 2008 Financial Crisis, and transfers this instability to the whole economy and society.



If Capital is scarce and it is the most important resource in a Capitalist System, the logical conclusion is  managing it efficiently; and this is the driver of the paradigm change, from a model based in Volume to a model based in Efficient Management of Capital.



Regulators are very aware of this new environment of Capital scarcity and the necessity of the paradigm change, and their logical proposal has been a new regulatory framework, focused in making visible the Capital consumption.



The Financial System has two main sources of regulation:

- Solvency from the Basel Committee on Banking Supervision of the Bank for International Settlements https://www.bis.org/bcbs/



- Accounting from the International Accounting Standards Board https://www.ifrs.org/groups/international-accounting-standards-board



The Basel Committee has increased significantly the Capital requirements in the last decade (Basel III, Basel IV, etc.), and the transparency in Capital consumption calculation (Principles for effective risk data aggregation and risk reporting) https://www.bis.org/publ/bcbs239.pdf



The International Accounting Standards Board has also brought significant changes in making Capital Consumption visible.



For instance, IFRS 9 – Financial Instruments, has modified the calculation of the Losses for deterioration of Financial Instruments, from the Incurred Losses to the Expected Losses principle In practical terms, the change produces an early recognition of the deterioration Losses and the consequent Capital consumption.



More interesting is the example of IFRS 15 - Revenue from Contracts with Customers, which modifies the process for Revenue Recognition, including a Contract Asset and a Contract Liability in the Accounting Postings.

The contract liability represents the company obligation to deliver goods or services to the customer for which the entity has received consideration (cash or non-cash) from the customer.



It’s also possible that the goods or services are delivered to the customer before the Revenue Recognition, and the correspondent value is represented by a Contract Asset.



The example of IFRS 16 – Leasing, is also very interesting. With IAS 17, the Lessees did not have to recognized the cost of Capital of a Leasing Contract, which was considered off-balance and only recognized at the time of receiving the Invoice. With IFRS 16, the Lesses have to recognized an Asset (Right of Use) and a Liability at the time of the contract activation.



Finally IFRS 17 – Insurance contracts, which increases the transparency requirements, including the recognition of profit over the period that services are provided under the contract, and the consequent Contract Asset and Liability positions.



All the above Accounting Principals have in common that the contract is represented, since the moment of its activation with an Asset and a Liability Position, influencing the Capital Position of the entity.



- The Asset Position represents a Risk Exposure which consumes Capital.

- The Liability Position reduces the ratio Capital/Debt of the entity.



As you can see, Capital requirements and Capital management are at the center of the regulators concerns. Anyway, this is logical as they know that Capital is scarce and they also know it is the main resource in a Capitalist System.



Once again, the logical conclusion is that Capital Optimization has become the main priority.



Looking forward to read your opinions.

K. Regards,

Ferran.

www.capitency.com

Join the SAP Banking Group at: https://www.linkedin.com/groups/92860

Visit my SAP Banking Blog at: http://sapbank.blogspot.com/

Let's connect on Twitter: @FerranFrancesGi

Ferran.frances@capitency.com

Central Data Hubs and the SAP Finance and Risk Data Platform.

Dear,

One of the consequences of the new regulation, emerging from the 2008 Financial Crisis (Basel III, Basel IV, BCBS 239, Dodd-Frank, IFRS 9, etc.) is the pressure for banks Information Systems, on reconciling Analytical and Operational data.

Most Core Banking Information Systems were developed in the 70s-80s, when the computing capacity was much smaller, and regulatory requirements much softer. 

Integration requires processing big data-tables and managing big memory blocks, because every transaction must read and update registers of data from other areas. As computing capabilities were more limited and reconciliation requirements less stringent, Banking Systems were built as separated silos of information with very little integration with each other.

As banking systems grew, this architecture of limited integration produced banking systems with very heterogeneous data, many complex point to point interfaces, and supported by databases whose designs are very distant from the principles of the Referential Integrity.

As mentioned before, the new Financial regulation, particularly BCBS 239 (Principles for effective risk data aggregation and risk reporting), puts the focus on data quality and data reconciliation, and this is increasing the pressure for integrating Financial Data, coming from heterogeneous sources.

https://www.bis.org/publ/bcbs239.pdf

One alternative is implementing an integrated Banking System, with a holistic management of Operational and Analytical Data (like SAP Banking). But the complete replacement of a banking information system is an expensive, challenging process. Performing it in a short-term period is only feasible for small/middle-size banks.

Consequently, many banks are confronting the issue by building a Central Data Hub which receives data from all the operational systems, homogenize the data, and finally stores and delivers it to the other systems of the banking landscape.

I’ve seen several of these initiatives in the last years, and they all present common challenges.

Projects design follow and add-hoc/on-demand approach. Data architects collect data requirements from the data consumer systems, and design the data repository according to these requirements. And then, define the interfaces for collecting data from the source systems and populating the data in the destination systems. 

To some extend, this approach implies reinventing the wheel, according to the bank’s own experience, and limited integration capabilities of the bank’s information architecture.

Additionally, regulation evolves, and new requirements force the data architects to enhance the multiple repository tables and in/out interfaces, compromising the integrity of the initial design. 

SAP has tackled the issue in a completely different way, delivering the Finance and Risk Data Platform, which combines a centralized data-model with an Integrated Financial and Risk Architecture

The Finance and Risk Data Platform has been designed to fulfill present and future Accounting, Risk and Liquidity regulatory requirements, as an alternative to the add-hoc/on-demand approach of the Central Data Hubs.

The Finance and Risk Data Platform combines:

- The accumulated knowledge in the design and development of the Integrated Financial and Risk Architecture of Bank Analyzer during the last 2 decades. The Primary Data Objects of the Bank Analyzer Source Data Layer as an standard template of the Operational Data, and the Result Types of the Results Data Layer as an standard template of Analytical Data.

Data Architects can take advantage of these standard templates as a basic reference, and enhancing them for fulfilling the bank’s specific requirements, without breaking the integrity of the data-model.

- The high-performing capabilities of SAP HANA for storing and managing very-high volumes of data, without intermediate tables and assuring the referential integrity of the database.

- The Extract, Transformation and Loading capabilities of SAP Smart Data Integration in Premise and in the Cloud.

- The Analytical Layers of SAP Bank Analyzer Risk Engines, Liquidity and Risk Management on HANA, Intraday Real-time Liquidity Management, etc.

The main advantage of this approach is the possibility of an incremental implementation, covering first the requirements of a Central Data Hub, interfacing with the current operational and analytical systems of the bank, but capable of growing and fulfilling new regulatory and functional requirements, with the implementation of the multiple analytical layers of the SAP Finance and Risk Data Platform.

Looking forward to read your opinions.

K. Regards,

Ferran.

www.capitency.com

Join the SAP Banking Group at: https://www.linkedin.com/groups/92860

Visit my SAP Banking Blog at: http://sapbank.blogspot.com/

Let's connect on Twitter: @FerranFrancesGi

Ferran.frances@capitency.com