Integrated Management of Risk Exposures and Hedging Strategies with SAP Bank Analyzer.

Dear,
In a Financial System driven by Capital Optimization, reducing the Capital consumption is a priority, and one of the main activities for reducing the Capital consumption is the efficient application of risk hedging techniques.

A common mistake is confusing Hedge Management with Hedge Accounting.

Hedge Management is a Risk mitigation technique, whose foundation is mitigating the capital consumed in risk positions by using counteracting hedging transactions.

On the other hand, Hedge Accounting is an accounting concept, whose objective is reducing the volatility in the profit and loss account, of a company which is using derivatives, for hedging its risk exposures.

Effective Hedge Management requires 3 steps.

1) Accurate identification of the Gross Risk Exposures and Net Risk Exposures.

2) Selection of the Financial Instruments with capacity of Hedging the Risk Exposure.

3) Matching the Risk Exposures (Hedged Transactions) with the correspondent Hedging Transactions.

The Bank Analyzer Source Data Layer and the Reporting Capabilities of SAP HANA offer us an excellent technology framework for the efficient execution of the above steps.

In the standard scenario of the Credit Risk Module of Bank Analyzer, we use the Source Data Layer-Positions for Representing the Credit Risk Exposures, the SDL-Position must also be linked to the Financial Transaction (or Financial Instrument) which represents the Root Cause of the Risk Exposure (Normally the Commitment and Disbursement of a Financial Transaction/Instrument).

The Process and Methods Layer of Bank Analyzer will read the information provided by the Source Data Layer and it will calculate the Risk Weighted Assets, which is the foundation for determining the Capital Requirements.

But SDL-Positons can also represent other types of Risk Exposures, we just need to enhance them with additional Characteristics and Key Figures for storing the necessary data.

For Instance, a “Risk Type Characteristic” will facilitate the representation of Interest Risk exposures, and a “Nominal Value Key Figure” of the SDL-Position can represent the Nominal Value of the Interest Risk Exposure.

We still don’t have Value-at-Risk Calculation Processes in the Bank Analyzer-PML which would provide a commonly accepted estimation of the Potential Losses, but we can use the data for defining Hedging Strategies and identify the proper Hedging Transactions. The reporting capabilities of SAP HANA are the best option for this.

Traditionally, the management of Risk Exposures have been limited to Financial Investments, Financial Assets (Accounts Payable and Receivable), Financial Transactions (Commercial Paper), etc.

This is a limited vision of what Risk Exposures are; Risk Exposures belong to the World of the Facts, and they can be originated by Business Process belonging to the main company activities, strategic investments, speculative investments, etc.

Hedging Financial Instruments also belong to the world of the Facts, they’re Financial Instruments whose behavior counteracts the behavior of the Transactions that have generated the Risk Exposure.

For instance, as an Oil company refines and stores 10 Million Barrels of Oil, it gets exposed to the Volatility of the Oil Prices (Market Risk Exposure). The company, will Hedge the Market Risk with   a Sales Order of 10 Million Barrels of Oil. But as it’s Hedging the Market Risk Exposure, it will get exposed to the Default Risk of the “Sales Order Bill-To” (Counter-party). Additionally, if the Currency of the Sales Order is not the Currency of the Oil Company, it will also get exposed to the Volatility of Foreign Exchange Rate between the Company Currency and the Sales Order Currency.

But again, this is a limited vision of the reality. As the Oil company is refining and storing the  10 Million Barrels of Oil, it’s also getting exposed to the Risk that an accident destroys the facilities and pollutes the environment (Operational Risk). As a consequence, the company will suffer the losses of the destroyed facilities and the potential environmental fines.

The Oil company has two alternatives to hedge the risk;
- Signing an insurance policy with an insurance company.
- Investing in safer facilities and processes.

Deciding what’s the most efficient strategy requires estimating the expected cost of both alternatives. The first one requires Financial Capital (insurance policy fees), the second one requires Financial Capital (investing in improving the facilities and processes), and also Know-How (Intellectual Capital).

With Bank Analyzer we can manage the first alternative (traditional scenario), but we also can take advantage of  integrating Bank Analyzer with other SAP Enterprise Core Components for making possible the estimation of the expected costs of the second alternative. In my opinion this is something that other Hedge Management products can not provide.

I’m convinced that the Capital Optimization opportunities offered by SAP Bank Analyzer, combined with its integration capabilities with other SAP Products, makes it the best option.

I’ll try to give more examples in future blogs.

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

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

Let's connect on Twitter: @FerranFrancesGi

Looking forward to read your opinions.

Kind Regards,
Ferran.

Capital Optimization for Clearing Houses with Blockchain and SAP Bank Analyzer.

Dear,
The more the Systemic Crisis evolves, the more clear is that the new model of the Financial System will be based in the efficient Management of Capital.

Recently, the EU Regulatory body has announced that Central Counterparty Clearing Houses (CCPs) should be subject to  Recovery and Resolution proposals.

http://www.bloomberg.com/news/articles/2016-10-05/eu-readies-plans-for-clearing-crisis-the-next-too-big-to-fail

More or less at the same time, the Bank of England has announced that Clearing Houses should be subject to Stress Testing and Capital Requirements Calculations, in order of keeping a Capital buffer to cover potential losses during the Financial Instruments settlement.

http://www.reuters.com/article/boe-derivatives-clearing-idUSL5N188411

Remember that as a consequence of the 2008 Financial Crisis, it was decided that Derivatives should be traded in centralized Clearing Houses. This decision was translated to the regulatory body by the Title VII of the Dodd-Frank Wall Street Reform and Consumer Protection Act in the US, and by the European Market Infrastructure Regulation in Europe. Similar regulations have been also implemented in other jurisdictions.

https://www.sec.gov/spotlight/dodd-frank/derivatives.shtml

http://ec.europa.eu/finance/financial-markets/derivatives/index_en.htm

Now, we’re entering in a new phase of the transformation, as the regulator forces the Clearing houses to give more transparency to their Risk Exposures and holding higher Capital levels, as a buffer for potential losses on the Derivatives trading.

As Capital requirements and costs increase for the Clearing Houses, they will have to pass this cost to its counter-parties (Financial Instruments traders), and they will have to pass the costs to their counter-parties, and so on. At the end of the chain, the Capital costs will be higher to all the market participants.

The more expensive Capital is, the more incentives the market participants will have to optimize Capital and reducing its associated cost.

In the case of the Clearing Houses, we can easily identify two opportunities for Capital Optimization.

1) Reducing the settlement time. New distributed Ledger Technologies like Blockchain represent a big improvement on this. Blockchain offers Near Real Time Settlement between counter-parties; with this technology the Clearing House can reduce the time that the House is the counter-party for the market participants, and consequently reducing the Risk Exposures and the Capital cost.

The Risk for the Clearing Houses is that, the more the settlement times are reduced, the more chances are that the counter-parties settle their trades directly, killing the Clearing House business model. Anyway, this is a different matter and we’ll talk about it in a future blog.


2) With detailed and preemptive analysis of the Risk Exposures, which facilitates the efficient measurement and request of Collaterals to the market participants, and supporting the implementation of pricing strategies, escalated according to the expected Capital costs.

For supporting the analysis of the Risk Exposures, reporting the Capital Requirements and Risk Weighted Assets calculations, and Stress Testing Requirements, Clearing Houses can use the Credit Risk Module of Bank Analyzer.

Recently I had an interesting conversation with a colleague, very experienced in Bank Analyzer implementations. He mentioned that, although he agrees that Bank Analyzer can be used in non-banking organizations, the common opinion is that Bank Analyzer target should be only Banks.

I disagree, Banking regulation requesting higher Capital levels and more transparency in the reporting of the Risk exposures is a driver, which increases the Capital costs in the whole Financial System.

The Capital costs are transferred from the Banks to the other market participants, and make them look at the capital consumed in their business processes, in order of optimizing their Capital consumption.

At the same time, the regulator increases the number of companies and market participants, which must improve their Risk exposures reporting and increase their Capital levels.

Consequently, focus in Capital consumption is spreading from the Too big to fail Banks, to smaller Banks, Insurance Companies, Clearing Houses, market agents exposed to derivatives, and more.

At the end, this is the logical conclusion of a Financial System which is moving from a model based in Volume to a model based in Efficient Management of Capital.

Join the SAP Banking Group at: http://www.linkedin.com/e/gis/92860
Let's connect on Twitter: @FerranFrancesGi

Looking forward to read your opinions.

Kind Regards,
Ferran.

Capital Optimization in Leveraged Buyout business with Blockchain and SAP Bank Analyzer.

Dear,
Recently, I’ve been preparing the training program for a Blockchain course which, as you know, is a “popular topic” in the Finance and Technology discussions these days.

I’ve discussed and requested feed-back to friends and colleagues, some of them followers of this blog, to the proposed training program.

In general, they agree that the main issue on Blockchain and Fintech training programs, books and events is the lack of focus on Blockchain applications. The value of a new technology is always determined by its capacity to provide value, which respond to the main challenges of its potential users.

In my opinion, any book, blog or training program oriented to a technology, applicable to the Financial System, should provide an answer to the main challenges of the Financial System.

And what are those challenges?
In a few words, the world's Financial System is over-leveraged, with limited Return of the Assets, and rising regulatory Capital Requirements.

Consequently, the main challenge is Capital Scarcity.

If the main Challenge is Capital Scarcity, the priority must be Capital Optimization, and this is not rocket science, it’s just common sense.

Since Dr. Eliyahu M. Goldratt introduced the Theory of Constrains in the 80s, we have a management philosophy, for analyzing and optimizing business processes, in scenarios of scarcity of the critical resources (bottlenecks).

Capital Consumption depends on the Risk. The Capital consumed in a Business Process depends, directly, on the risk that the expected Value-Flows don’t become actual, mainly due to three reasons:

1) The probability that the counter-party, in the business process, don’t fulfill his obligations (credit risk).

2) The volatility of the environment, which makes fluctuate the value flows of the business process (market risk)

3) The probability that we make mistakes or suffer fraud (the process is not run efficiently), which generate losses (operational risk).

Naturally, a Capital Optimization program must start by identifying the business process, in which the risk of suffering big losses is higher, and focus in reducing the uncertainty of the expected value-flows (planning vs actual value-flows), due to any of the above risk types.

This is one of the biggest advantages of the Blockchain, increasing transparency and auditability of the value-flows; that’s what makes it particularly useful in Capital Optimization.

A good example of Capital Optimization, by using Blockchain, is the Leveraged Buyout Process, which consists in the acquisition of a company, with Capital lent by an investment bank. The investment bank requests, as a collateral of the Loan, shares, assets and rights, of the acquired company.

This process facilitates mergers and acquisitions; limiting the Capital that the acquiring company has to commit.

In this process, the Fair Value of the Loan depends, directly, on the performance of the acquired company.

If the acquired company does not perform well, the borrower will have difficulties for fulfilling his obligations, and incentives to declare bankruptcy. At the same time, the bad performance of the acquired company represents a worthless guarantee, and a waste of Capital for the investment bank.

Blockchain offer us the technology for integrating accurately the Financial Statements of the acquired company, in an auditable ledger, with the necessary data for determining the Fair Value of the Investment Bank Asset.

But, in management, Information is useless without Analytical tools, for supporting the decision-making processes; this is the value provided by Bank Analyzer in the construction.

Bank Analyzer is not just a regulatory reporting tool, or an accounting system. Bank Analyzer is a Capital Optimizer that can tell us how much capital we’re consuming, by business segment, portfolio, individual business, region, client, etc, and what is the expected return of the consumed capital.

This is the basis for prioritizing the best market opportunities and taking timely corrective actions, in case of mistakes, building the foundation for a Capital Efficient management.

Remember that we’re in a systemic crisis, driven by Capital Scarcity; technology investments also consume Capital, and we have to prioritize those technologies which represent a more efficient use of it.

Join the SAP Banking Group at: http://www.linkedin.com/e/gis/92860
Visit my SAP Banking Blog at: http://sapbank.blogspot.com/
Let's connect on Twitter: @FerranFrancesGi
K. Regards,
Ferran.

Why Bank Analyzer – AFI is not a sub-ledger anymore? Chapter II.

Dear,
We saw in the last blog the improved integration that comes with the simplification initiative of S4 HANA and the Universal Ledger.

https://www.linkedin.com/pulse/why-bank-analyzer-afi-sub-ledger-anymore-chapter-i-ferran-frances?published=t

Unfortunately Bank Analyzer has not been included, at least for the moment, in the S4 HANA simplification initiative, but this doesn’t mean that we can’t take advantage of the improved capabilities of the Universal Ledger.

Recently, we worked in a Proof of Concept for integrating SAP smart Accounting for Financial Instruments on Banking Services 9 with SAP S/4HANA Finance.

Conceptually, it’s not possible to fully integrate Bank Analyzer with the Universal Journal, as they have been designed for fulfilling different objectives and built on different architectures.

- The Universal Journal of SAP S/4HANA Finance is an Accounting System, whose final objective is providing multidimensional Financial Statements, eliminating the separation between Sub-Ledgers and the General Ledger

- Bank Analyzer is a Capital Optimizer, whose final objective is offering a multidimensional representation of the Accounting Results of a bank’s business segment, the Capital consumed for generating the Result, and the Liquidity generated or consumed in the process. This is the foundation of the Integrated Financial and Risk Architecture.

For that reason the Universal Journal of  SAP S/4HANA Finance generates Accounting Postings, while Bank Analyzer generates Cash-Flow Structures and Financial Position Objects, one of whose potential representations are Accounting Postings.

You probably remember that we discussed briefly about this topic in a previous blog.

https://www.linkedin.com/pulse/why-sap-bank-analyzer-accounting-system-ferran-frances?trk=hb_ntf_MEGAPHONE_ARTICLE_POST

For this reason, when we said that we worked in the integration of Bank Analyzer with the Universal Journal, we must clarify that the objective was limited to integrate the Accounting constellations of Bank Analyzer into the Universal Ledger architecture, and not the Risk and Liquidity ones.

Bank Analyzer was built as a Sub-ledger, with the Fat Sub-Ledger / Thin General Ledger approach.

Without the Universal Journal, accounting entries of Bank Analyzer are extracted from the RDL with the correspondent data-sources, transferred to SAP Business Information Warehouse, and in the standard scenario, reconciled with the General Ledger entries on the Bank Analyzer ERP MultiProvider of the Bank Analyzer Financial Data Mart.

By integrating the Bank Analyzer Accounting (sub-ledger type) Postings in the S4 HANA Universal Ledger we can enjoy some of the reconciliation and simplification advantages that the Universal Journal offers to other Sub-Ledgers (Real Estate, Projects System, Accounts Payable, Accounts Receivable, etc.).

From an Operations perspective, this approach represents several challenges.

1) Bank Analyzer Accounting Entries are available in the Results Data Layer after the Accounting Processes have been finished (PEBT, USBT and KDV), while they’re only available in the General Ledger after the GL-Connector processes have been finalized.

2) Extracting data from separated systems and data structures makes analysis and reconciliation more difficult. In the same way that extracting data from the Projects System Sub-Ledger and the General Ledger requires more effort than extracting all the necessary data from the Universal Journal.

In most of projects, Bank Analyzer and General Ledger reporting teams work in parallel, with duplicated teams mantaining BW Info-cubes ad-hoc reports, not following the final objective of the integration principle, which is providing one “Single Source of Truth”

As an alternative, in our Proof of Concept, the objective was building the Bank Analyzer analytical dimensions, as a subset of the Universal Ledger dimensions, but without adding any Info Object in the Bank Analyzer Accounting Dimensions, which couldn’t be mapped in a 1 to 1 relationship with the Universal Ledger Dimensions.

All the accounting entries of the RDL would be replicated to the Universal Ledger, which would provide both, the detailed (sub-ledger type) and aggregated (General Ledger type) accounting information, eliminating the barriers between the AFI sub-ledger and the General Ledger.

The Operations Plan should formally include the General Ledger-Connector process as part of the Bank Analyzer Accounting Processes.

With this approach, all the accounting entries, including AFI accounting entries, will be posted in the Universal Ledger, facilitating reconciliation and analysis of the information. We will not have to access to separated data-structures (Results Data Layer and General Ledger). All the accounting information will be available from the Universal Ledger.

All the reporting, predictive and analytical functionalities implemented on the Universal Ledger, taking advantage of the HANA capabilities, will be immediately available for the Accounting for Financial Instruments results.

Be aware that it’s technically possible, integrating non-Hana based Bank Analyzer systems, with the Universal Journal of S4 Hana. By following this approach, clients running a non-Hana based Bank Analyzer system, who don’t have short term plans to migrate their Bank Analyzer system, can still enjoy the capabilities of Hana based systems, by integrating their AFI processes in the Universal Journal of S4 HANA.

And Finally, all the Accounting Extractions to the Reporting Systems will have the Universal Journal as the “Single Source of Truth” simplifying the Reporting and Reconciliation requirements.

Let's connect on Twitter: @FerranFrancesGi
Join the SAP Banking Group at: http://www.linkedin.com/e/gis/92860

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

Why Bank Analyzer – AFI is not a sub-ledger anymore? Chapter I.

Dear,
Since version 5 of Bank Analyzer was released 10 years ago, we've enjoyed a powerful system for the management of the Financial Instruments of an institution, from two perspectives.

- Multi-GAAP, Accounting representation of the financial events, impacting the Bank's portfolio (Bank Analyzer-AFI).

- Capital Consumption and correspondent Capital Requirements of the Bank's Assets (Bank Analyzer-Credit Risk).

This double representation is the foundation of the Integrated Financial Risk Architecture of Bank Analyzer, which was already available in previous versions of the system.

On the other hand, and that was the most relevant improvement of the version 5, the Accounting for Financial Instruments module of Bank Analyzer offered complete Financial Statements of every contract of the Bank, fully integrated and reconcilable with the General Ledger.

This integration was provided with the structure of a sub-ledger. In the AFI sub-ledger we have the detailed statement of every Financial Instrument/Transaction, fully reconcilable on account level, with the aggregated statement of the company, available in the General Ledger.

On the other hand, as the number of entries of the detailed sub-ledger, is far bigger than the aggregated entries of the General Ledger, the final architecture was called Fat-Subledger / Thin-General Ledger.

This was 10 years ago; on 2010 we saw the release of the SAP HANA Database whose performance opened new opportunities in Information Systems simplification, and since 2015 we can enjoy a new concept of Accounting Simplification with the Universal Journal of S4 HANA.

Amongst other advantages, the Universal Journal of S4 HANA has eliminated the separation between the sub-ledgers and the General Ledger.

With the Universal Ledger, the accounting information is not spread in the information system of the company.

We don't have to look for accounting aggregated information in the General Ledger and detailed accounting information in the Sub-ledgers (Accounts Payable, Accounts Receivable, Assets Management, Projects System, Real Estate, Material Ledger, etc.). With the Universal Journal, we have all the accounting information in a single multi-dimensional ledger, with separated but integrated entries, structured on the multiple dimensions of this ledger.

The simplified architecture of the Universal Ledger comes with new capabilities for analyzing and reconciling the accounting information.

For instance, let's imagine that we have to model the business process of a construction company, in which the invested capital is collected in the Projects System module, till the Work in Process is activated in an Asset, that will be managed by the Assets System module of SAP ECC. Finally, the asset will generate profits by lease out contracts, managed with the Real Estate Module.

Without the Universal Journal, accounting information for Projects needs to be recovered from the WBS's tables (PROJ, PRPS, etc.), while the accounting information of the Assets is stored in the Assets System tables (ANLA, ANLB, ANLC, ANEK, etc.), and the Lease Out contracts are stored in the Real Estate tables (VIMIMV, VIMI01, etc.).

With the Universal Journal, the accounting entries of the WBS elements, the Assets and the Lease Out contracts will be posted in the Universal Journal tables (ACDOCA, BKPF, etc) during all phases of the business process, simplifying the reporting and reconciliation requirements.

But let's come back to the Bank Analyzer system; theoretically SAP – AFI is not part of the S4 HANA simplification initiative, and consequently it will not offer the integrated capabilities of the Universal Journal.

Recently, we worked in a proof of concept for taking advantage of the Universal Journal capabilities, integrated with the Accounting for Financial Instruments module of Bank Analyzer version 9.

We'll talk about our conclusions in the next blog.

Looking forward to read your opinions.
Join the SAP Banking Group at: http://www.linkedin.com/e/gis/92860
K. Regards,
Ferran.

"Utility Settlement Coin" as a driver of the Banking Transformation.

Dear,
Last year, we discussed about the opportunities of the Blockchain technology.

https://www.linkedin.com/pulse/bitcoin-sap-banking-ferran-frances?trk=mp-reader-card

https://www.linkedin.com/pulse/dynamic-collateral-management-sap-bank-analyzer-ferran-frances?trk=mp-reader-card

Several systemic banks, including UBS,  Deutsche Bank, Santander, BNY Mellon, the market operator ICAP and the technology company Clearmatics have partnered in the development of the new "Utility Settlement Coin".

The "Utility Settlement Coin"  is a digital currency, supported by the Blockchain technology, backed by financial assets deposited in central banks.

The liquidity of the assets backing the USC should help in reducing the volatility and incentive the adoption of the new currency.

Using Blockchain technologies, instead of clearing houses and traditional banking settlement networks, presents two advantages:

- Reduction of settlement time from days to minutes.

- Reduction of settlement costs. Some studies estimate that the adoption of Blockchain technology for banking settlements will produce costs reduction of $20 Billion a Year.

With this incentives, it's obvious that will see soon many other initiatives incentivizing the use of Blockchain distributed ledgers.

But the advantages of the Blockchain will not come by doing the same things cheaper and faster, the advantages of the Blockchain will come by doing new things that we can't do today.

The impact of the Internet in the two legs of the value chain has been unbalanced in the last two decades. While the leg of the supply of goods services from the vendor to the client has experienced revolutionary changes, the leg of the transfer of value and payment from the client to the vendor, is still in the pre-internet era.

Corporates have replaced legacy Information Systems with ERP's (mainly SAP), improving dramatically the transparency, efficiency and traceability of their Supply Chains,

Companies collaborate in integrated Supply Chains, with Subcontracting and Work Order Collaboration or Vendor Managed Inventory scenarios, but they have to clear the payments for this goods and services with Financial Services provided by banks which are still relying in outdated legacy systems, and inefficient clearing and payment networks.

Blockchain technology provides the foundation of the Internet of Value, which is going to drive dramatic changes on the way in which companies, clients, vendors and intermediaries interact in the Value Chain.

Revolutionary Financial Services are going to appear in the new years; Dynamic Collateral Management, Optimized Margin Management supported by smart-contracts in smart distributed ledgers like Ethereum, even new services that we can't imagine today.

But the question remains; is it possible to implement these services on outdated information systems?
I don't think so.

These services will require Simplified Information Systems, collaborating in value networks, with the Information Systems of their counter-parties.

SAP has simplification technologies like HANA, and deep knowledge of the best practices for running Supply Chains, that we will have to integrate with the new Internet of Value.

Considering these assets; does SAP have the opportunity to leader this transformation, as it has leadered the transformation of the Supply Chains?
I'm convinced it does, and I hope we will comment it together in this blog.

Looking forward to read your opinions.
Join the SAP Banking Group at: http://www.linkedin.com/e/gis/92860
K. Regards,
Ferran.

IFRS 15 implications for Banks and the SAP Bank Analyzer sub-ledger.

Dear,
Last February I commented in a blog, that IFRS 15 presented important implications for the Banks Information Systems.

https://www.linkedin.com/pulse/fulfilling-ifrs-9-ifrs-15-sub-ledger-requirements-sap-ferran-frances?trk=mp-reader-card

As a consequence, some colleagues and readers of this blog have come back to me privately reminding me that IFRS 15 does not apply for contracts with leases, that are subject to IFRS 9.

I always appreciate very much this feed-back, I'm sure I make many mistakes that I can fix with your help, and on the other hand; there's no better way of learning, than opening a discussion with other colleagues.

By the way, this is the basis of the Hegelian dialectic “Thesis, Antithesis, Synthesis”

In this particular case, it's true that IFRS 15 does not apply for contracts with leases, but this doesn't mean that Bank's information systems are not impacted by the IFRS 15 regulation, which should be implemented by January 1, 2018.

The reality is that Bank's have always offered non-lending services, Foreign Exchange Services, Locker Services, Debit Cards, Local and International Payment Services, and these services conditions must be specified on contracts, that according to IFRS 15 must be valuated individually.

And keep in mind, that as consequence of the current, historically low interest rates, revenues generated by not-lending services are more important in the operating results of banks, making them more relevant in the analysis of the banks' results.

If you're interested in this topic, I recommend you to read the working paper of the Bank for International Settlements “The influence of monetary policy on bank profitability”, that you can find in the following link.

http://www.bis.org/publ/work514.pdf

Fortunately, SAP Bank Analyzer capabilities, integrated with the cost and revenue recognition functionalities of  other SAP Components (Cost Center Accounting, Activity Based Costing, Controlling Orders, CRM, Profit and Cost Distribution tools of Business Planning and Consolidation, etc), offer powerful functionalities for the tracking and analysis of non-lending profits and costs.

The main competitive advantage of the SAP Business suite is the seamless integration of business process incorporating lending and non-lending business processes.

In some cases, separating the lending and non-lending components of a contract can be very challenging for the Information System of a Bank. For instance, one bank can offer a locker to a client who also has a mortgage loan, and both services payments are cleared in a current account with an overdraft facility.

Integrating the lending and non-lending contracts in Bank Analyzer will have many advantages.

Bank Analyzer supports the tracking of all the revenues and costs amounts, generated by the lending and non-lending services, posted with Business Transactions and Items.
These amounts will be accumulated in the correspondent Posting Key Figures by the multi-accounting logic of the Process and Methods Layer.
Finally, the Processing Categories of the Posting Key Figures will provide us the technical classification of the nature of the Profits and Costs, under the interpretation of the implemented Accounting Principles.

On the other hand, tracking accurately the costs associated to some of the services can be very challenging. In Bank Analyzer we can easily post the Standard Cost associated to a service, but the key point is determining an accurate and valid amount of the Standard Cost.

With decades of successful implementations in manufacturing and services companies, SAP ECC, CRM and Business Planning components have proved to be very useful for determining the actual and planned costs associated to non-lending services. This know-how can be leveraged in the determination of the costs associated to non-lending services of banks.

Finally, the open architecture of the Financial Database will provide the integration layer of the above calculations. Once they've been incorporated as accounting entries of the Results Data Layer, they will be transferred to the General Ledger with the standard capabilities of the General Ledger Connector, fulfilling the reconciliation requirements of IFRS 15.

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

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

Stress Testing, TLAC, MREL and Capital Optimization with SAP Bank Analyzer.

Dear,
Friday this week the European Banking Authority will release the results of its latest stress test.

http://www.eba.europa.eu/risk-analysis-and-data/eu-wide-stress-testing/2016

Capital requirements and capital levels have been the main topic in Banking supervision since the 2008  financial crisis.

In the same line, two words are going to become very popular in the next months, TLAC and MREL. TLAC stands for Total Loss Absorbing Capacity and MREL stands for Minimum Requirement for Own Funds and Elegible Liabilities.

The Total Loss Absorbing Capacity determines the capital requirements for systemic banks and financial groups, that must be available to absorb potential losses.

The Minimum Requirement for Own Funds and Elegible Liabilities will determine the capital requirements for non systemic banks.

Implementing these standards is going to have serious consequences. During this year, European banks have suffered heavy losses in the stock market as a consequence of high levels of delinquency, low profitability of the banking business, and the regulatory changes increasing the banks capital requirements.

Additionally, shareholders losses penalize the markets feeling on the banking sector, increasing the cost of capital of the industry, opening the gate for more losses.

Bringing clarity to the regulatory framework is the key to exiting this vicious cycle; hopefully, in the oncoming months, the regulator will define.

1) The standard and internal approaches to measure the Credit and Operational Risk.

2) Methods to determine the Leverage Ratio for systemic and non-systemic banks.

3) Final definition of the Total Loss Absorbing Capacity requirements and Minimum Requirement for Own Funds and Elegible Liabilities, for systemic and non-systemic banks.

The question is; what can be the impact of the final definition of the regulatory framework?
Let's see some estimations.

Two weeks ago, David Folkerts-Landau, chief economist of the Deutsche Bank, estimated that 150.000 million euros are needed for recapitalizing the European banking system.

http://www.bloomberg.com/news/articles/2016-07-10/eu-banks-need-166-billion-deutsche-bank-economist-tells-welt

According to Bloomberg, the European Banking Authority estimates that 470.000 million euros are needed for fulfilling the capital requirements determined by the TLAC and MREL standards.

http://www.bloomberg.com/news/articles/2016-07-20/european-banks-may-need-517-billion-of-loss-absorbing-capital

It's clear that Capital is going to be scarce and expensive, consequently Capital Optimization is going to be at the center of the banks strategic plans.

Capital Optimization starts by measuring how, where and when capital is consumed. Questions that can be answered by SAP Bank Analyzer.

Bank Analyzer comes with a data-model (Financial Database), and a calculation layer (Risk Engines of the Process and Methods Layer), which provide detailed measurement of the capital consumed by any analytical dimension.

The Financial Position Objects of the Results Data Layer represent the fundamental constituent of the capital and accounting value of the banks financial instruments.

Additionally, the Financial Position Objects can be stressed in simulated scenarios that will provide a holistic vision of the bank's portfolio value, and the capital consumed for generating this value.

And this is just the beginning; combining the computing capabilities of SAP HANA with known algorithms of discrete mathematics, like the Simplex method, we can build future Risk Engines for Capital Optimization.

This is the value proposition of Bank Analyzer, the best answer for the biggest concern of the banks' executives.

In my opinion, this value proposition should be highlighted, maybe calling it Capital Optimizer instead of Bank Analyzer, but this is a different story.

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

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

Why SAP Bank Analyzer is not an Accounting System?

Dear,
Recently I spoke with the Country Manager of an SAP Partner who has detected several opportunities for implementing Bank Analyzer - AFI in his region.

He mentioned his concerns about the challenges of implementing Bank Analyzer, compared to other competitors.

"It's hard to sell an IFRS Accounting System more expensive to implement, even if it comes from the leader on developing Integrated Information Systems".

But comparing Bank Analyzer with an IFRS Accounting system is a mistake, because Bank Analyzer is not just an accounting system.

Bank Analyzer is a Capital Optimizer, which also fulfills the IFRS reporting requirements of a Financial Institution.

Today, the executives of most of the Banks and Insurance companies of the world are concerned with being IFRS compliant in the next months, because they're very aware of the consequences if they are not.

But this is just the beginning, at the same time the credit risk managers are concerned about the Basel III reporting requirements and the justifications of their IRB Risk models.

The Bank's information architects are trying to determine the full implications of the BCBS 239 directive. And very soon, they will discover that IFRS 15 also applies for Banks and it comes with very deep implications for the Bank Information Systems Architecture.

And for making it worse, bank's executives are concerned  with the rising Capital Requirements, including the Total Loss Absorbing Capacity regulation, and the difficulties of generating value for their shareholders in a difficult environment of margins reduction.

It seems that the regulator has decided to make the bankers’ lives difficult, just when they face the worse economic environment with negative interest rates and limited growth.

This is not personal. Regulators know that we're in the middle of a Systemic Crisis that will transform the Financial System, from a model based in volume, to a model based in Efficient Management of Capital.

That's why they are driving bankers towards the new paradigm, saturating them with new and harder regulations.

IFRS 9, Basel III, IFRS 15, BCBS 239, TLAC are not isolated pieces of regulation, they're a complete framework designed to put Capital Efficiency at the centre of the banks' strategic objectives.

Additionally, auditors look at the figures, with the obligation of reconciling the information provided by all the reporting requirements.

The response to this challenge requires a holistic modelisation of the Bank's Capital and Liquidity. This is the Integrated Financial and Risk Architecture of SAP Bank Analyzer.

In one sentence; the Bank Analyzer IFRA provides an accurate mesurement of the Capital and Liquidity, generated and consumed, by any potential combination of analytical dimensions, including the business processes involved.

For instance, IFRS 9 requires to report in "accounting terms", the Capital generated and consumed by business segment, including Fair Value and Impairment Calculations.

Basel III and Total Loss Absorbing Capacity regulations require banks to report the Capital consumed by business segment, and BCBS 239 defines the Data Governance for proving the accuracy of the Capital and Liquidity calculations.

Bank Analyzer Primary Objects and Financial Position Objects are the bricks of the holistic data model, and the Bank Analyzer Risk Engines provide the necessary calculation logic to fulfill the above and future reporting requirements.

This is the answer I always give to clients who ask me why they must implement Bank Analyzer.

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

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

Project Finance with SAP Bank Analyzer.

Dear,

The main consequence of the new environment of Capital scarcity, which has emerged from 2008 Financial Crisis and the Great Recession that followed it, it's the necessity of managing scarce Capital efficiently.

A very interesting example of the challenges of the new environment is the financing of the construction of big infrastructures. Many big infrastructures construction are financed with the use of Project finance, which is the process of financing big infrastructures with equity or debt backed by the cash flows generated by the project.

The process is as it follows:

1) The project starts with an idea.

2) After the idea has been approved, a project plan is approved, and financial resources are committed for financing the plan.

3) The committed resources can be allocated as Equity, Debt backed by the cash flows generated by the project (Securitization of the project cash flows) or Loans collateralized by the project cash flows.

4) The project plan is executed and the expected cash flows become actual and they're used by the project managers for repaying to the investors.

The whole process can be managed with the Investment Management module of SAP ECC.

1) The initial idea can be model in SAP ECC with an Appropriation Request.

2) The project plan can be modeled in the Project Systems module of SAP ECC with Work Breakdown Structure elements or Orders. These WBS elements or Orders can be created from the Appropriation Request that represented the initial idea.

3) As capital is transferred in and out the Project Plan (expenses and profits), the capital movements can be represented as Business Transactions posted in the Project plan.

As the project has been financed with equity, securities backed by the project cash flows or Loans collateralized with the project cash-flows, the investors, debt holders and lenders require Fair Valuations of the project.

This is the first limitation of the Investment Management module of SAP ECC; Investment Management manages very well the valuations of the Project following “Nominal Accounting Principles”, but it does not translate accurately the Capital costs experienced by the project due to Risk related magnitudes, which impact the transformation of Expected cash flows in actual ones.

On the other hand, if we transfer the Business Transactions, Orders and  WBS elements, with their Expected Cash-Flows to Bank Anlayzer, the system will give us Fair Value calculations of the Project cash-flows, which is the basis to integrate the project value as Equity, Collateral of the Loans and Securitizied Debt.

When we plan the Expected Cash-Flows, ECC is capable of giving a Nominal Addition of the Expected Cash-Flows. But the value of future Cash-Flows is never the value of current ones, when we're estimating the value of an investment we have to include additional costs.

- Capital Costs.- Which are the statistical costs related to the potential losses the investor is facing as a consequence of the risk and uncertainty of the investment.

- Funding Costs.- They are the costs of having rented the funds, as they're not available for the investor till the investment pays-back.

The above costs can't be calculated by the Investments Management or Projects System of SAP ECC, but we can use the data provided by the Investments Management module, as a basis to determine the Capital and Funding Costs in Bank Analyzer.

When we plan the expected Costs and Profits of the project with the planning functionalities of SAP ECC, we're determining the expected Cash-Flows and the time when we expect them.

The project planner should also estimate the probability of the expected Cash-Flows become actual, and this will be the basis to determine the Spreads and Yield Curves for discounting the future Cash-Flows.

Once we've transferred the Business Transactions, WBS elements and Orders with their planned Cash-Flows (Financial Transactions) to Bank Analyzer, the Risk Engines of Bank Analyzer will determine the Fair Value of the Financial Transactions, including the related Capital and Funding Costs.

The Risk Engines of Bank Analyzer also require the Yield Curves associated to the investment, and we will determine them with the probability of the expected Cash-Flows becoming actual, that the Project Planner has estimated.

Finally, as the Project Fair-Value has been estimated, we'll have the basis to estimate the Financial performance of the Project, integrating it as the Underline of the correspondent Investment Vehicle.

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

Looking forward to read your opinions.

K. Regards,

Ferran.

Smart Accounting for Financial Instruments and the IFRA of Bank Analyzer.

Dear,
Release 9 of SAP Bank Analyzer comes with a new functionality called Smart Accounting for Financial Instruments, deeply related to the new concept of central GAAP.

For understanding the implications of the concept we have to look at the two sides of the Banking Processes.

- Operational Banking world or “world of the facts”.
- Analytical Banking world or “world of the opinions”.

Operational world is the world of our daily relationship with the Bank: disbursing a loan, paying a fee, being charged a commission, signing a contract, etc. At Operational world there is not much space for interpretation; if a client disburses 50 USD from his Credit Card, all the related magnitudes are very clear: amount, time, interest he will be charged, etc.


On the other hand, the Analytical Banking interpretation of the event depends on the Accounting Principles the bank is following.

For instance, if the bank charges the client a commission, the full amount of the commission will be considered a profit, under certain Accounting Principle, while only a partial amount of that commission will be considered a Profit under other Accounting Principal,

This different interpretation of the same event, according to different Accounting Principles, can be separated in two pieces: Nominal Accounting Entry and Accounting Principle dependent adjustments.

Nominal Accounting entries are very close to the world of the facts, they represent a transfer of value, as it happens in the operational world. Finally, Accounting Principle dependent adjustments will “adjust” the accounting entry according to specific Valuation Rules, Impairment calculations, etc.

As you can see, Nominal Accounting entries are not dependent on the accounting principles of any specific GAAP, and their amounts are reconcilable with the events in the Operational Banking system.

That is the main value proposition of the new Smart Accounting for Financial Instruments: building an accounting System which separates Accounting Independent entries (Nominal Accounting), from GAAP dependent adjustments.

Some clients and colleagues tend to think that this is not an important achievement, since most of the banks implementing Bank Analyzer – AFI have the objective of implementing as well International Financial Reporting Standards, which are meant to be common accepted accounting principles for every company, independently of the jurisdiction in which they operate.

I disagree; IFRS is meant to be a common accounting framework for analyzing quickly the company’s health, but we also need to look at the financial stability of an organization from alternative perspectives, and alternative accounting principles will fulfill this objective.

For instance, in some jurisdictions, the regulator requires that the Financial Institutions provide what they call “Shadow Accounting” statements. These Shadow Accounting statements, are basically Financial Statements, in which the Bank discloses the potential value of its portfolio, without including the Losses of the damaged Assets.

By comparing the results of the bank with and without Impairment Losses, the bank is providing an approximation to the potential and actual performance of its portfolio.

With the central GAAP approach and the Smart-AFI functionalities of Bank Analyzer 9, the bank can provide a Principal sub-ledger which follows the main Accounting Principals on this jurisdiction, and another sub-ledger following the Shadow Accounting Principals.

Additionally, both sub-ledgers can be transferred with the GL-Connector, to the Parallel Ledgers of the ECC-Finance or the S/4HANA Simple Finance System, with a seamless integration of the Financial Instruments Subledger and the General Ledger of ECC-Finance or the Universal Ledger of S/4HANA Simple Finance.

Another example; some banks represent their Expected Losses due to Credit Risk and the Value at Risk of their Market Risk exposures in their Financial Statements. Thanks to the Integrated Financial and Risk Architecture of Bank Analyzer is easy to develop a CVPM process which reads the Credit Risk-Expected Losses from the correspondent Result Type of the Results Data Layer (SKCRE) and generates accounting entries at Financial Transaction Level in the correspondent Result Type (SFISD).

But the Expected Loss Amount has different values according to the Approach the bank has followed to calculate it (standardized approach, Foundation IRB or Advanced IRB), and the correspondent accounting entries represent implicitly, an alternative Accounting Principle.

This means, that every parallel ledger of the Bank Analyzer sub-ledger, represents alternative valuations and costing sheets of the bank's Financial Instruments, providing justification of these valuations, from alternative perspectives and accounting models.

For the moment, we cannot calculate the Value at Risk in Bank Analyzer. But we can still integrate externally delivered calculations at the Results Data Layer, thus creating a gate for newer integrated scenarios of Risk and Accounting. And these scenarios will represent implicitly more Accounting Principles, and alternative interpretations for the value of the Bank's portfolio.

Join the SAP Banking Group at: http://www.linkedin.com/e/gis/92860
Looking forward to read your opinions.
K. Regards,
Ferran. 

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.

Impairment Calculations and Capital Optimization with SAP Bank Analyzer.

Dear,
The Financial System is in a process of Systemic Transformation, from a model based in volume to a model based in Efficient Management of Capital.

We're moving to a new era of limited growth, and in an environment of limited growth a fractional reserve financial system suffers solvency tensions. Consequently, the regulators increase the capital requirements, forcing the financial institutions to reduce their leverage.

As free capital becomes scarce, it also becomes more expensive, driving the Systemic Transformation.

Financial Assets consume Capital in three main ways:
- Credit Risk.

- Market Risk.

- Operational Risk.

The Basel III agreement establishes the main metric for measuring the Capital consumed due to Credit Risk exposure of the Financial Assets, and builds the foundation for the calculating the Capital requirements of a Financial Institution.

The Basel III agreement distinguishes between the Expected and Unexpected Loss produced by a Credit Risk exposure, the first one must be covered by Impairment Provisions, and the second one by Capital.

A valid model of capital optimization must reduce the capital consumed on credit risk exposures by limiting both, the Expected and the Unexpected Loss at the same time.

The Internal Rating Based Approach, both Foundation and Advanced gives us an opportunity for building a holistic Credit Risk Optimization System, as the Credit Risk model used for determining the Probability of Default, and the Loss Given Default and Exposure at Default (in case of the Advanced Approach) can be used, with some adjustments, as a basis for determining the Impairment Provisions.

In this model, the Impairment Provision is compared with the Expected Loss; if the Expected Loss is higher than the provision, the excess of Expected Loss is reduced from the capital.

On the other hand, if the Expected Loss is lower than the provision, banks may recognize the difference in Tier 2 capital up to a maximum of 0.6% of credit risk-weighted assets.

For details you can look at http://www.bis.org/publ/bcbs128.pdf

This holistic management of Capital Requirements and Impairment Provisions requires a integrated modeling of Risk and Accounting, which is exactly the foundation of the Integrated Financial and Risk Architecture of SAP Bank Analyzer.

From release 8, SAP Bank Analyzer offers the Impairment Processes submodule, fully integrated with the Accounting for Financial Instruments module.


The Impairment Processes of Bank Analyzer offer:

- Automatic determination of the percentage of Expected Loss from the Rating and the Delinquency Bands of the Exposures.

- Dynamic classification of the Financial Assets in the Bad or Good book by processing the Impairment Events.

- Determination of the Accruing Status of the Impaired and Performing Assets according to the IFRS requirements.

- Determination of Expected Loss, Provision Amounts, Write-down and Write-off, and the unwinding for the Exposures, including Off-Balance Exposures by using Credit Conversion Factors.

- Posting of the Impairment Provisions on the Bank Analyzer sub-ledger fully integrated with the Accounting Processes.

- Transfer of the Impairment Provisions to the General Ledger and complete reconciliation of the Impairment Provisions between the sub-ledger and the General Ledger.

And this is just the beginning; as mentioned above, the Integrated Financial and Risk architecture of SAP Bank Analyzer opens the gate for more complete representations of the banks capital consumption, we'll talk about them in future blogs.

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

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

Solvency II and SAP Insurance Analyzer.

Dear,
As you probably know, since January 1st 2016, all the European insurance companies must be compliant with the new Solvency II Directive.

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 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.

Additionally, Insurance companies must also be compliant with the IFRS standards, particularly IFRS 9 for Financial Instruments.

For helping insurance companies to meet with these regulations, SAP has delivered the Insurance Analyzer System.

https://help.sap.com/insurance-fsia

Technically the Insurance Analyzer 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 Insurance Analyzer 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 Insurance Analyzer, 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 9, 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.

Fulfilling IFRS-9 and IFRS-15 Sub-ledger requirements with SAP Bank Analyzer.

Dear,
One of the main concerns of the banks' IT executives today is the implementation of the International Accounting Standard IFRS 9 Standard, “Financial Instruments”

Impairment Calculations, Fair Value and Hedge Accounting adjustments represent a challenge for current Banking Information Systems and an opportunity to replace some of their components with modern technologies, like the Accounting for Financial Instruments module of SAP Bank Analyzer.

SAP Bank Analyzer covers the three main groups of calculation requirements of the IFRS-9 standard.

- Fair Value calculation of Over the Counter, Securities and Listed Derivatives contracts.- Financial Instruments and Financial Transactions. (Mark-to-Market, Cash Flow Discounting, Forward Transactions, Options, Futures and Structured Products).

- Impairment Adjustments.- Calculation of the Risk Provisions, write-down, write-off and the unwinding with full integration with Accounting.

- Hedge Accounting Adjustments for Fair Value, Cash-Flow and Portfolio Fair Value Hedging.

On the other hand, there's a common difficulty on understanding the implications of the IFRS requirements; many clients see IFRS 9 just as a reporting requirement that must be fulfilled before January 2018.

But limiting an IFRS compliance program to the IFRS 9 requirements is an incomplete vision of the implications of the new IFRS Regulatory framework. IFRS requirements must be seen as a transformation process, and not as unconnected pieces of regulation.

An interesting example of the above is the Accounting Standard IFRS 15 “Revenue from Contracts with Customers”.

IFRS 15 puts the focus in the Revenue Recognition of the customer contracts individually. While this standard has not been specifically designed for banks, underestimating the impact of the “Revenue from Contracts with Customers” in the bank's architecture would be a serious mistake.

Banks have to disclosue the revenues generated when they charge their customers for the services they're receiving; services like securities broking, wire transfers, accounts maintenance fees, etc. Accounting adjustments must be allocated to every customer contract, challenging portfolio-based adjustments, which are very common in the banking industry.

Bank Analyzer AFI (subledger scenario) provides a complete Financial Statement (Profit & Loss, Balance Sheet and Off-balance positions) per customer contract, and fully reconcilable with the General Ledger. This is the main requirement of IFRS 15.

By implementing the AFI module of SAP Bank Analyzer, we're not only fulfilling the accounting requirements of IFRS 9, but also preparing our system for the future requirements of IFRS 15.

We also must remember that Inefficient integration between the Operational and Analytical Systems limits the capacity of providing reporting Profit and Loss analysis functionalities on contract level.

Current Banking Information Systems, supported by Legacy systems suffer from inefficient integration between the Operational and Accounting Systems. Even some banks which have replaced some of their Information Systems in the last years have failed in improving the integration between their Operational and Analytical-Accounting Information Systems.

Typically, Operational and Analytical banking Systems come from different vendors with heterogeneous data-models, in which the incompatibilities between the data-models must be overcome with “reasonable” hypothesis developed as conversion routines in the Extraction and Transformation Layer.

In this scenario contract-base valuations and adjustments are usually replaced by portfolio-based adjustments which contradicts the requirements of IFRS 15.

SAP Banking has provided a seamless integration between the Operational and Analytical Banking components of Banking Services by using Integration Operational Analytics technology, this is the base for transferring all the necessary information to the Accounting System, according to the IFRS requirements.

As a conclusion, Financial institutions need to look at the IFRS requirements as a process; while IFRS 9 are increasing the effort on determining the value of the Financial Instruments and the recognitions of the related revenue, IFRS 15 puts the focus in reporting determining the revenue recognition contract by contract.

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

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