SAP Performance Management for Financial Services (FS-PER).

Dear,

Recently, we finished a Proof of Concept of SAP Performance Management for Financial Services (FS-PER), in a client which implemented Bank Analyzer – AFI some years ago.

SAP has always had strong Cost Management and Accounting functionalities, even in SAP R2, which was the first SAP system I ever put my hands on.

Today, we have SAP Finance and Controlling, Business Planning and Consolidation, and some Cost Management and Accounting Functionalities in Bank Analyzer (Profit Analyzer), so, when I first heard about SAP Performance Management for Financial Services, I thought it should have an overlapping with other SAP Systems.

I was wrong, SAP Performance Management for Financial Services covers an important gap that we had with previous Cost Management systems in Financial Services.
One of the main challenges we have in Banking implementations is the data collection from multiple legacy systems, with different sets of master and transactional data. It’s very difficult to find a Bank which has a Single Source of Truth for Operational data. Usually, Business Partners, Contracts, Products, etc. are stored in multiple systems with a different set of values in every legacy system of the bank.

In SAP Bank Analyzer, we have the Source Data Layer for building a Single Source of Truth of Operational Data, but the Source Data Layer Primary Objects are oriented to the management and storing of “banking” master and transactional data (business partners, financial transactions, business transactions, positions, etc.)

On the other hand, managing “non-banking” data like process-costs, assets-amortization costs, etc. in the Bank Analyzer Source Data Layer, is not that simple.
Actually, these costs and revenues are more easily managed with the Accounting Management modules of  SAP-ECC or SAP Business Planning and Consolidation. But, what happens when we want to merge banking and non-banking data in a Cost Analysis model, or the client stores the Cost Management data in a legacy system?

For instance, let’s look at the direct cost that a foreign bank charges to our bank because our clients use the foreign bank ATM machine; this cost is posted as an invoice for a service provided by a vendor. If the foreign bank gives us the list of the ATM-cards using its ATM machine, we should post these costs as a direct cost of every account related to each of the ATM-cards.

With SAP Performance Management for Financial Services, we can easily collect the invoice cost from the Vendor’s Invoice and post it in the Bank Analyzer – Results Data Layer. Once in the Results Data Layer, we can include the ATM-card costs of the foreign bank in the cost and profit analysis of our client’s accounts (Financial Transactions).
In my opinion, this is the main advantage of SAP Performance Management for Financial Services, its capacity of integrating in a cost analysis model, data from different and heterogeneous sources.

SAP Performance Management for Financial Services supports data collection from the Bank Analyzer Source Data Layer, the General Ledger, HANA tables, external data, etc. and write the results in Business Warehouse or Business Planning and Consolidation Infocubes, or, as I mentioned before, in the Bank Analyzer Results Data Layer.

Additionally,  SAP Performance Management for Financial Services offers data cleansing capabilities, that we also can find in other SAP systems (BW for instance). The advantage is we can optimize the process of data transformation by having all the elements in the same system.
In terms of Data Transformation and Calculation, SAP Performance Management for Financial Services comes from a very rich library of functions for Costs Settlement, Funding Price Calculation, etc.

Finally, SAP Performance Management for Financial Services comes with two pieces of Business Content; Sample Content for Profitability and Efficiency Management and Business Content on Solvency II. The business content can be used as a template for our own Financial Calculations and Transformations, accelerating the implementation process.

Combining the functionalities of SAP Performance Management for Financial Services with the functionalities of the new Financial Services Data Platform and the high performance computing of HANA, SAP is offering us a powerful business suite for Profit Analysis in complex banking landscapes.

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

IFRS 15 for Banks with SAP Revenue Accounting.

Dear,

From January 1st 2018, a new Accounting Standard becomes mandatory for reporting the Revenue Recognition in Contracts with Clients IFRS 15, becomes effective.



IFRS 15 enhances the process of Revenue Recognition by establishing a 5 steps process.

1) Identify the contract with the customer.

A contract with a customer falls within the scope of IFRS 15 if all the following conditions are fulfilled.

- The contract has been approved by the parties to the contract

- Each party’s rights in relation to the goods or services to be transferred can be identified

- The payment terms for the goods or services to be transferred can be identified

- The contract has commercial substance; and it is probable that the consideration to which the entity is entitled to in exchange for the goods or services will be collected.



2) Identify the performance obligations in the contract.

Usually, operational systems represent the Performance Obligations in the contract but there are two possible exceptions:

- Several Operational Items representing the same Performance Obligation. For instance, in a Desktop Computer (represented by a Sales BOM), several Items are detailed in the Sales Order (Monitor, CPU and Keyboard) but they represent the same Performance Obligation of delivering the Computer.

- One Operational Item representing several Performance Obligations. For instance some Computer Manufacturers offer one year technical support service (Performance Obligation) with every computer sold (Performance Obligation).



3) Determining the Transaction Price.

The transaction price is the amount that the vendor expects to receive in exchange for the goods or services.



4) Allocating the Transaction Price to performance obligations.

Once the transaction price for the contract has been determined, IFRS 15 requires to allocate it to the performance obligations of the Contract. Considering the two cases above, in which the Operational System Items does not represent univocally the Performance Obligations, we can understand the challenge of allocating the Transaction Price to the Performance Obligations.



First, IFRS 15 requires to determine the Stand-Alone Selling Price which is the price that the vendor expects to receive in exchange for delivering the goods or services of the performance obligation are sold separately to a customer. Be aware of the difficulty of estimating the Stand-Alone Selling Price when several performance obligations are sold together with a bundle price.

In order of determining the Stand-Alone Selling Price, IFRS 15 permits three approaches.

1. Adjusted Market Assessment. Estimating the Stand-Alone Selling Price according to the conditions of an specific market, reflecting the vendor costs and margins.

2. Expected cost plus margin. Estimating the Stand-Alone Selling Price according to the expected costs of the performance obligation for the vendor, plus its correspondent margin.

3. Residual Method. In case of bundle prices for grouped performance obligations, in which we can not estimate the Stand-Alone Selling Price of all the performance obligations, IFRS 15 proposes the following two-steps approach.

First we have to estimate the Stand-Alone Selling Price of the performance obligations of the group, that can be estimated with one of the previous approaches. The we will estimate the Stand-Alone Selling Prices of the rest of the performance obligations, by deducting the Stand-Alone Selling Price of the performance obligations already estimated, from the total contract price of the group of performance obligations.



5) Recognize revenue when each performance obligation is satisfied.

In case of a good or service delivered in one step, the performance obligation is satisfied at the moment of the final delivery to the customer, but in case of services or goods delivered during a period of time, IFRS 15 requires that the revenue is recognized according to the percentage of the performance obligation that has been delivered in every financial period.



Although, IFRS 15 impacts other industries much more than Banking (which is much more impacted by IFRS 9), there are some banking services impacted by the requirements of IFRS 15.

Fulfilling IFRS 15 requirements, requires Information Systems with strong sub-ledger capabilities, that we described briefly in a previous blog.



http://sapbank.blogspot.com/2016/02/fulfilling-ifrs-9-and-ifrs-15-sub.html



Additionally, SAP provides the Revenue Accounting and Reporting module for IFRS 15, which supports all the requirements of the 5 steps approach for Revenue Recognition described above.

We have worked recently in the design of an IT architecture, combining Bank Analyzer and SAP Revenue Accounting and Reporting for IFRS 15, for supporting IFRS 15 requirements in Banking.

I’ll give you some details in a future blog.

Looking forward to read your opinions.

Kind 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

What is SAP Bank Analyzer Smart-AFI?

Dear,

In the last months, several clients have asked me about the new concept of Smart-AFI of Bank Analyzer, and its differences with the traditional Accounting for Financial Instruments Module of SAP Bank Analyzer.

I’ll start with a short description of the evolution of the Accounting for Financial Instruments module of SAP Bank Analyzer until the most recent 9.0 version, which includes Smart-AFI.

The Accounting for Financial Instruments module of Bank Analyzer is the system responsible of creating a Financial Statement, including the valuation, of the Financial Instruments (Securities and Over the Counter Contracts) of a Bank. Actually Bank Analyzer call them Financial Instruments when they are securities, and Financial Transactions when they are Over the Counter contracts.

Until the Version 5,  the Accounting for Financial Instruments Module of Bank Analyzer was not a proper sub-ledger. The Version 4.2 and older versions were not capable of integrating the Financial Statements of the Financial Instruments in the General Ledger, in fact the results were stored in the Results Data Base (precursor of the Results Data Layer but much less flexible). From the Results Data Base, the system provided Data Sources for sending the Financial Statements to an specific Business Content in Business Information Warehouse. At the end we could import the Financial Instruments statements and the General Ledger Statements to a Business Information Infocube which contained the complete Financial Statement of the Bank. This approach, which “merged” the Financial Instruments Statements and the General Ledger in a Business Information Warehouse Infocube, was called Merged Scenario.

With the Version 5.0 (released 10 years ago), we got the first Bank Analyzer - AFI System which could be called a real sub-ledger, this version brought two big improvements:

- The Results Data Layer, capable of storing Accounting, Risk and other formats of data (including external Data). Foundation of the Integrated Financial and Risk Architecture.

- The General Ledger Connector, responsible of extracting the Accounting Data from the Results Data Layer and send it to the General Ledger, where the aggregated accounting entries, fully reconcilable with the Financial Instruments sub-ledger, are posted.

Version 5 of Bank Analyzer supported multi Accounting System functionalities (actually older versions supported several accounting systems too), meaning that the Financial Statements of the Financial Instruments could be generated according to different Accounting Principals (typically Local GAAP and IFRS).

And finally, we arrive to Bank Analyzer 9 and Smart-AFI. One point that we must consider when we’re thinking about Bank Analyzer-AFI is that Bank Analyzer valuates individually and builds a complete Financial Statement per individual contract (Financial Transaction or per every Security managed in an specific Securities Account), and this is a huge computing effort, when we’re valuating the portfolio of a commercial or investment bank.

Additionally, if the Bank is evaluating the portfolio according to several Accounting Systems (for instance Local GAAP and IFRS), the system suffers a double computing effort. This is the way that all Bank Analyzer versions, older than Smart-AFI, support the multi Accounting System requirements.

On the other hand, there’s a more efficient way of generating multiple Financial Statements, according to multiple Accounting Systems. Instead of creating completely isolated Financial Statements, the system can create a Central Ledger, and additional Ledgers, with the differences-adjustments, also called “deltas”, from the Central Accounting Systems to the parallel ledgers, supporting alternative Accounting Systems.

From a Legal Accounting perspective, the result is the same, but from a performance-computing perspective, the Smart-AFI is much more efficient. Smart-AFI covers the same multi-Accounting requirements, with the same accuracy and flexibility, but with much less computing effort; this is the Smart part of Smart-AFI.

Looking forward to read your opinions.

Kind 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

IFRS 9 for Dummies.

Dear,
Last months I have given several workshops of Bank Analyzer, and the implications of the new IFRS 9 regulation, which was issued by the International Accounting Standard Board on 24 July 2014, and it is mandatory from 1 January 2018.

In some cases, I’ve seen that the IFRS 9 regulation and its implications is not fully understood; this made me think about the opportunity of writing this blog.

IFRS 9 is the new Accounting Standard for Financial Instruments, which is replacing the former IAS 39, and it covers the following topics.

- Classification and measurement of financial instruments
- Impairment of Financial Assets.
- Hedge Accounting.

The Classification and measurement part establishes that Financial Instruments must be classified according to the business model, which must be determined by the company executives, and the nature of the cash flows.

IFRS 9 also establishes two measurement category, depending on the Financial Instrument classification: Fair Value and Amortized Cost.

Amortized Cost is available for assets that meet two conditions:

1) The assets must be held in a business model whose objective is to collect the contractual cash-flows.
2) The contractual cash-flows must represent repayment of principal and interest on principal.

IFRS 9 proposes the following classification of Financial Assets:

- Debt instruments at amortized cost.
- Debt instruments at fair value through other comprehensive income with cumulative gains and losses reclassified to profit or loss upon derecognition.
- Debt instruments, derivatives and equity instruments at fair value through profit or loss.
- Equity instruments designated as measured at fair value though other comprehensive income, with gains and losses remaining in other comprehensive income.

Finally, IFRS 9 permits reclassifications when the company changes its business model or the holding of the assets.

The Impairment of Financial Assets topic has changed from the model of incurred losses on IAS 39, based on the principle that the Loans are repaid unless there’s an event producing the losses, to the model of expected losses that are recognized during the life-cycle of the Financial Asset.

Some advantages of this new approach are:
- Reduce the complexity of impairment measurements to a unified model.
- Avoids late recognition of the credit losses, as it happened during the 2008 Financial Crisis.
The Hedge Accounting part has been redesigned towards an approach which aligns Hedge Accounting with Risk Management, with the following requirements.

- Increase the available information for Risk Management, including the integration of the Risk Management policies in the Financial Statements.

- Support Hedge Accounting with internal information for Risk Management.

- Disclose the impact and effectiveness of the Risk Management and Hedge Accounting measures in the Financial Statements, including the impact of the Derivatives in the future cash-flows.

This is just a short introduction of the new IFRS 9 regulation, but this is a very important topic and we will look at it in future blogs.

Looking forward to read your opinions.
Kind 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

IFRS 9 implications on Accounts Receivable Open Items.

Dear,
IFRS 9 implications go further than what many Banks and Corporates executives expect. For this reason, many Banks and Corporates are far from being ready to be compliant to IFRS 9, which is mandatory from January 1st, 2018.

A particularly interesting example is the management and Value Recognition of Account Receivable Open Items on IFRS 9.

According to IFRS 9 Accounts Receivable Open Items are classified as LAR (Loans and Receivables) and valuated at Amortized Cost using the effective interest method. Technically, this means to determine the Cost of Capital related to the Open Item (considering the Probability of Default of the Counter-party and Loss Given Default of the Exposure) and penalize its Nominal Value accordingly.

Remember that not only banks, but also publicly listed companies are subject to IFRS 9, which means that in 2 months they should have developed the Risk Models for determining the Probability of Defaults of their clients, and Loss Given Defaults of their Account Receivable Open Items. 

Are they going to be ready on time? We’ll see.

But let’s look at the IFRS 9 implications from the Banks perspective.

Factoring is a very common Financial Service offered by Banks for the management of Account Receivables; with Factoring a Corporate “sales” its Account Receivable rights to a Bank in exchange for cash, which means that the Bank is taking the counterparty Risk and the Cost of Capital related to the Assets (Accounts Receivable Open Items).

Again, this means that in 2 months they should have developed the Risk Models for determining the Probability of Defaults of the counterparties of the acquired  Account Receivables, and Loss Given Defaults of the related Exposures, so they can valuate the acquired assets at Amortized Cost, using the effective interest method. . 

Are they going to be ready on time? We’ll see.

But the analysis becomes a little bit more complicated when we look carefully at the IFRS 9 implications for the acquired assets. If the Bank acquiring the assets has the positive intention to hold to maturity the acquired assets, they are classified as LAR and valuated at Amortized Cost (analogously as the corporate would), but if not, they must be valuated at Fair Value, which obviously brings new challenges to the Valuation of the acquired assets.

Once again, are they going to be ready on time? We’ll see.

On the other hand, there are two different Financial Services related to  Accounts Receivable Open Items, one is the Factoring, that we analyzed above, the second one is Invoice Discounting.

With Invoice Discounting Financial Service, a Corporate borrows cash from a Bank, using its Account Receivable Open Items as Collateral of the Loan.

With Invoice Discounting, the Counterparty Risk remains in the Corporate and the associated Cost of Capital of the Account Receivable Open Items must be posted in the Corporate books. Additionally, the Corporate holds a liability (the money borrowed from the Bank) that must also be reflected in the Corporate books.

SAP offers a complete solution for the management of the Account Receivables Open Items and the Factoring and Invoice Discounting Financial Services related, combining FI-CA, Bank Analyzer and other modules, but this blog has become too long, we’ll talk about it in a future one.

Looking forward to read your opinions.
Kind 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

The European Central Bank increases Capital Requirements. It is time for SAP Bank Analyzer.

Dear,

As we have commented in previous blogs, the Financial System is at the middle of a Systemic Transformation, from a model based in Volume to a model based in Capital Optimization.

The transformation is forced by the regulators, by increasing Capital Levels (Basel III, Basel IV. TLAC), implementing new Accounting Principles (From Nominal Accounting and Incurred Losses to IFRS Accounting and Expected Losses) or increasing Reporting Requirements with BCBS 235.

Last week, the European Central Bank released a new draft on Provisioning Requirements for Non Performing Loans. 

You can find the details here.

https://www.bankingsupervision.europa.eu/press/pr/date/2017/html/ssm.pr171004.en.html

In a nutshell, the new requirements increase pressure on European Banks to reduce Non Performing Loans in their balance sheets. 

Currently, European banks hold one trillion Euros of Non Performing Loans. On average, the coverage of this type of assets is 45%; with this new regulation, Non Performing Loans with collateral must be 100% provisioned in seven years, and Non Performing Loans without collateral must be fully covered in two years.

On the other hand, ECB which has been reducing Bank’s cost of capital by acquiring Bank’s bonds during each of the quantitative-easing cycles, it’s close to reduce significantly the size of this purchases.

https://www.bloomberg.com/news/articles/2017-10-12/ecb-is-said-to-consider-cutting-qe-purchases-in-half-next-year

As Capital becomes more scarce and expensive, the priority becomes Capital Optimization, this is the foundation of the Financial System which is emerging from this Systemic Crisis.

SAP provides the Best of Breed Capital Optimizer with SAP Bank Analyzer; with SAP Bank Analyzer, banks executives get an answer to the three most critical questions of strategic management in the new paradigm.

- How much Profit is the bank’s making in each business segment?

- How much Capital is the bank’s consuming in each business segment?

- How much Liquidity is the bank’s consuming (or generating) in each business segment?

Recently, a group of experienced SAP Banking consultants have decided to join our efforts in an initiative, for providing SAP Banking transformation programs, with focus in Capital Optimization; the result is Capitency.

www.capitency.com

In Capitency, we believe that SAP technology is critical for providing bank’s with Capital Optimization Information Systems, helping them with the challenges of the Systemic Transformation.

We are looking forward to accompany you during this journey.

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

Kind Regards,

Ferran Frances.

Ferran.frances@capitency.com

The road to IFRS 9 and IFRS 17 compliance with SAP Bank Analyzer.

Dear,
On January 1st, 2018 (5 months from now), IFRS 9 becomes effective.
We’ve talked about IFRS 9 in previous blogs, in general this is not just a new regulation, it actually represents a paradigm change in the valuation of the Financial Instruments.

IFRS 9  implementation has been a long journey, the first discussion paper was published by the International Accounting Standard Board in March 2008. The paper proposed that all financial instruments should be valuated at fair value. Some months later, as a result of the financial crisis of 2008, the IASB decided to revise their accounting standards according to some recommendations of this paper.

After 9 years, all Banks should be ready for presenting their books according to the new standards; we’ll see next year if they really are.

In my opinion IFRS 9 represents two critical challenges:

- According to a survey conducted by the European Banking Authority,  European banks estimate an increase of provisions of 18% on average (and up to 30% for 86% of the respondents) compared to the current levels of provisions under IAS 39. On the other hand, the common equity tier 1 (CET1) ratios are expected to decrease on average by up to 59 basis points (bps) (and up to 75 bps for 79% of the respondents). In limited cases the impact of IFRS 9 could be higher. This represents a very relevant reduction of the Capital ratios of Banks, reducing their capacity to lend and invest.

http://www.eba.europa.eu/-/eba-provides-its-views-on-the-implementation-of-ifrs-9-and-its-impact-on-banks-across-the-eu

- Regulators are watching very closely and they are expecting robust reporting systems, providing reconcilable results, proving the strict implementation of the standards. This represents a lot of stress on the Information Systems of Banks, many of them supported by legacy systems, which are far from being capable of fulfilling the regulators expectations.

SAP Bank Analyzer provides the best answer for tackling these challenges:
Bank Analyzer provides the Fair Value of every Financial Transaction (Over The Counter Contract) and every Financial Instrument (Security or Listed Derivative) with the AFI Module. Additionally, determines the Risk Weighted Assets (Capital Requirements) of every contract, with the Basel III Module.

With information, the Banks Capital Managers can determine contract by contract the Profit or Losses generated by every Contract, and the Capital consumed by it.

Additionally, every contract is categorized by a set of Reporting Dimensions which will provide the basis for Business and Regulatory Reporting. Aggregating bottom up every contract, according to the values of its Reporting Dimensions, the Banks Capital Managers will estimate the Profit or Losses generated by every micro-portfolio, including the performance of the portfolio in stressed scenarios.

Insurance companies, will face very similar challenges with the implementation of IFRS 17, with effective date January 1, 2021, and Bank Analyzer, or in this case Insurance Analyzer, is also the best alternative to support the challenges that will come with it.

We’ll talk about it in a future blog.

Looking forward to read your opinions.

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

Kind Regards,

Ferran Frances.

Capital Optimization and the Business Case for SAP Bank Analyzer.

Dear,

Some weeks ago, I had the chance to speak with a reader of this blog, who holds a senior position in an Investment Fund.
He said “literally” that the new era of Banking is going to be dominated by Capital, as the previous era was dominated by Debt. An alternative way of saying that we’re moving from a Financial System driven by Volume to a Financial System driven by Capital Optimization.

According to some estimates, European Banks may face a Capital gap of $128 Billion with the implementation of the new regulation drawn by the Basel Committee on Banking Supervision.

https://www.bloomberg.com/news/articles/2017-04-13/european-banks-may-face-128-billion-capital-gap-as-basel-bites

Rising this Capital is going to have a profound impact on the European Banks’ profits and return on equity. Capital determines the capacity of a Bank for Lending or Investing; it is the main resource for supporting Bank’s activities.

As the Banks’ main resource (Capital) becomes scarce, the only alternative is managing this resource efficiently, which brings the question: how can we optimize the consumption of a critical resource?
Optimizing the consumption of a critical resource is a two steps activity:

1) Measuring accurately the consumption of the critical resource.

2) Planning and simulating the consumption of the critical resource under different conditions.

Bank Analyzer offers multiple advantages in the accurate measurement of the banks Capital consumption.

- Risk Exposures are evaluated individually.

- Bank Analyzer offers standard integration with the Operational Banking system, avoiding data mismatching and Operational errors.

https://www.linkedin.com/pulse/reducing-operational-costs-sap-banking-standard-ferran-frances

- Risk dimensions can be freely determined and assigned to the risk exposures, facilitating the multi-factor analysis of the portfolios behavior in stress-scenarios.

Additionally, the high-performance of the SAP HANA In Memory Database facilitates fast calculations of the Risk Weighted Assets and Capital Consumption, under multiple sets of planning data. Fast computing is the prerequisite for running simulation scenarios.

If the new banking era is driven by Capital efficiency, there’s no more critical activity than preparing the organizations for the systemic change.
For most people, SAP Bank Analyzer is the SAP component for preparing the regulatory reporting of a bank; this is a limited vision of SAP business case.
How do we want to sale a Bank Analyzer project if the message is:

“With SAP Bank Analyzer you’re going to report how well or how bad the bank performed in the last quarter.”

Is this management or  should we do better?
Management requires planning, optimization and strategic alignment.

With Bank Analyzer, we can establish the foundation of an IT Architecture for providing answers to the most important concerns that bankers and  regulators have in the new system.

- What’s the profit I expect to make with this strategic plan?

- How much capital will be consumed with this strategic plan?

- How much liquidity will be consumed?

This is the true value proposition of Bank Analyzer, and sooner than later it will be recognized.

Looking forward to read your opinions.

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

Kind Regards,
Ferran Frances.

Reconciling IFRS and Basel III with the Integrated Financial and Risk Architecture of SAP Bank Analyzer.

Dear,

As we commented in previous blogs, we’re in the middle of a systemic transformation; from a Financial System based in Volume to a Financial System based in efficient management of Capital.
And in a globalized Financial System, efficient Capital Management requires a commonly accepted regulatory framework, for measuring the Capital consumed by bank’s assets.

Today’s main sources of regulation for banks are; the International Accounting Standard Board (IFRS), and the Basel Committee on Banking Supervision (Basel III).

http://www.ifrs.org/About-us/IASB/Pages/Home.aspx

https://www.bis.org/bcbs/

The main responsibility of the BCBS is establishing the Capital Requirements for assuring the financial stability of the banking system, while the main responsibility of the IASB is establishing Fair Valuations of the assets.

Actually, both organizations are looking at the same problem, of measuring Capital consumption, from different perspectives.

- IFRS. The Fair Valuation of a Financial Assets, determines the provisions which adjust the Nominal Value of the Asset to a Fair Value, which includes the “Cost of Risk”.

- Basel III. The Capital requirements of an asset determine the capital consumed by investing (or lending).

It sounds reasonable to establish some level of reconciliation between the two approaches.

Basel III requires Banks to accumulate Capital during the expansion phase of the economic cycle, to cope with potential losses during the contraction phase of the economic cycle. These Countercyclical capital requirements are not linked to any particular loan, so they are Generic.

On the other hand, the International Financial Reporting Standards establishes the provisions, that banks must recognize, for covering the losses on their portfolio, due to events which have already happened and will affect future cash flows.

Part of these losses, come from detected failed loans, but others come from failed loans that we’re aware that exist in the portfolio, but we haven’t detected yet. For that reason, we have to evaluate the whole portfolio and adjust its value globally, also with the format of a Generic Provision.

But the problem remains, how to determine the Fair Provision for a non-visible failed loan?

An interesting approach for determining the value of these generic provisions, utilizes the Internal Ratings-Based Approach of the Credit Risk Calculation (Basel III).

For the IRB Credit Risk Calculation, we have to evaluate several components; the Probability of Default (PD), the Loss Given Default (LGD), the Exposure at Default (EAD) and the maturity of the contracts (M).

Additionally, the IRB approach let us calculate the expected losses of the portfolio (EL), which is the expected loss for every loan that we can calculate with the following formula:

EL=PD*LGD*EAD

As a driver of our reconciliation exercise, we're using the concept of Expected Losses of IRB, which is close to the concept of Incurred Losses of IFRS but not exactly the same.

The Expected Losses of the IRB approach is the average flow of losses that the internal rating calculation methods forecasts that is going to materialize in one year, while the Incurred Losses of the IFRS is the stock of existing losses of the portfolio at any given time, due to events in the past which will generate losses in the future.

Both, Incurred Losses and Expected Losses are different from the yearly manifested losses (flow of yearly defaults) and consequently the yearly flow of specific provisions.

Nevertheless, we can calculate the Incurred Losses according to the IFRS, by estimating the yearly flow of expected losses, and the time from the event which makes the loan failed, and the time when the failed loan becomes visible. This period between both events is called Loss Identification Period (LIP).

For instance if the counter-party losses his job, becoming incapable of fulfilling his payment obligations 18 months later, the Loss Identification Period would be 18 months.

Consequently if we know both magnitudes (the Expected Losses and the Loss Identification Period) we can estimate the Incurred Losses multiplying both.

For example, if the calculated Expected Losses of our portfolio (IRB Approach) are 45 million dollars/year and the average Loss Identification Period is 2 years, that means the Incurred Loss in our portfolio is 90 million dollars.

Incurred Losses (IFRS) = Expected Losses (IRB Approach) * Loss Identification Period

On the expansion phase of the economic cycle the Loss Identification Period is longer due to the easiness for refinancing policies supported but the good economic conditions.

And according to the formula the longer Loss Identification Period will make the Incurred Losses higher during the expansion phase.

This way, we’re reconciling the calculation of the IFRS Generic Provisions with the counter-cyclical capital buffer, requested by Basel III

Bringing the above method to the management of a real bank’s portfolio, requires an integrated Accounting (IFRS) and Risk (Basel III) management system, in a holistic data-model.

This is the foundation of the Integrated Financial and Risk Architecture of Bank Analyzer.

And this is what makes it the best system for measuring and optimizing the capital of a bank.

Looking forward to read your opinions.
Join the SAP Banking Group at: http://www.linkedin.com/e/gis/
Visit my SAP Banking Blog at: http://sapbank.blogspot.com/
Let's connect on Twitter: @FerranFrancesGi

Kind Regards,
Ferran Frances.

Accepting the Systemic Change. From a Financial System based in Volume to a Financial System based in Capital Optimization.

Dear

Some months, ago most of European banks complained that the low interest policy of the ECB was damaging their profitability.

https://www.bloomberg.com/news/articles/2016-06-01/european-banks-feel-the-pinch-from-draghi-s-negative-rates

But today we read that if the ECB reduces the stimulus, this will increase dramatically the risk of their bad loans.

http://www.reuters.com/article/us-eu-banks-regulations-idUSKBN16M23T

In conclusion, the problem is not low or high interest rates, because this has never been a liquidity problem. This a solvency problem due to Capital scarcity.

But assuming this has consequences; because it represents a Systemic Change, from a Financial System based in Volume to a Financial System based in Capital Optimization.

We'll talk about them in a future blog.

Looking forward to read your opinions.

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

Kind Regards,

Ferran Frances.

Artificial Intelligence and Financial Chatbots with SAP Banking.

Dear,
As the Financial System passes the transition period; from a model based in Volume to a model based in efficient Management of Capital, Banks are pushed by two main forces; cost reduction and innovation.

Some weeks ago, we could read that Bank of America has opened several branches without employees.

http://www.reuters.com/article/us-bank-of-america-idUSKBN15M2DY

This is just the beginning, as technology evolves, new IT-supported interaction channels between banks and clients will be implemented, reducing costs and improving efficiency.

One of the most innovative technologies are the Financial Chatbots, computer systems capable of conducting conversations via auditory or textual methods.

Financial Chatbots have existed for more than 20 years, but new computing capabilities have brought a new concept on conversational interaction with computers .

While traditional Chatbots were based on a set of rules, taking actions and giving advises by selecting options in an predetermined decision tree; newest Financial Chatbots support their decisions in Artificial Intelligence algorithms.

- Financial Chatbots based on rules provide limited functionalities, offering answers and questions according to sets and sequences of deterministic rules.

- Financial Chatbots supported by Neural Networks understand the context of the conversation, and learn from conversations they have with people.

What do Financial Chatbots represent in the Technological Architecture of a Bank’s Information System.

Financial Chatbots, in combination with the development of other interaction technologies, offer a great potential of cost reduction and customer service. But the limits of this technology will be determined, not by doing the same activities automatically, but by facilitating new value propositions.

The best example is Google, which just two years ago, introduced a new system for generating responses to search queries, with the self-learning capacities of the Artificial Intelligence; replacing the search engine algorithm that made the company successful.

https://www.bloomberg.com/news/articles/2015-10-26/google-turning-its-lucrative-web-search-over-to-ai-machines

The key word is relevancy; Bank’s will only take advantage of the full potential of their Artificial Intelligence initiatives, if their information systems are capable of capturing, storing and managing all the relevant data.

This is a serious challenge, as banks information systems are supported by Silo style Information Systems; poorly integrated, and with limited capacity of crossing information by processes, products, requirements, client’s profile, etc.

Lifting this limitation requires:
- An integrated data-model, capable of providing relevant data that the Analytical Information System can process, feeding the Artificial Intelligence System.

- A High Performance Predictive Technology supporting the learning process of the the Artificial Intelligence System.

SAP Banking provides the technological architecture for tackling both requirements:

- An integrated data-model, including client’s experience, holistic business partner description, operational processes, solvency, profitability and accounting.

- The SAP HANA Predictive Analysis Library for supporting Artificial Intelligence developments.

With this two technological pillars, SAP Banking can provide the foundation of a new generation of  “Smart Banks”; taking advantage of the he Artificial Intelligence revolution, not only in client interaction, but in most of the bank’s core activities.

For instance, recently, we’ve participated in a research initiative for evaluating the potential of the Neural Networks in solving Capital Adequacy Requirements simulations.

Imagine the potential of translating the result of these simulations in marketing campaigns, private banking activities or risk mitigation initiatives.

We’re just at the beginning of the Artificial Intelligence revolution, we’ll look at other examples of this revolution in a future blog.

Looking forward to read your opinions.

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

Kind Regards,
Ferran Frances.

Fulfilling Banks' Integrated Reporting Dictionary regulation with SAP Bank Analyzer.

Dear,
On May the 18th, 2016 the European Central Bank published the REGULATION (EU) 2016/867 OF THE EUROPEAN CENTRAL BANK on the collection of granular credit and credit risk data (ECB/2016/13)

This regulation is commonly known as the Banks' Integrated Reporting Dictionary (BIRD).

https://www.ecb.europa.eu/ecb/legal/pdf/celex_32016r0867_en_txt.pdf

The main objective of the BIRD is defining a common framework of the data and  transformation rules which banks may implement in their Information System to fulfill the reporting requirements of the regulatory authorities.

In words of the President of the ECB, Mr Mario Draghi,

“Disaggregated data are indeed necessary to identify and analyse the heterogeneity that characterises the real world. For central banks this is particularly important: to implement policy in the most effective way, we need to know how our policy actions affect all sectors of the economy. Both the challenges posed by the current economic climate for monetary and macroprudential policy, and the information required to carry out microprudential supervision by the Single Supervisory Mechanism (SSM) increase our need for granular data”.

https://www.ecb.europa.eu/press/key/date/2016/html/sp160706.en.html

Today, banks store and analyze their risk data on pools of assets with “homogeneous” characteristics, and generate provisions, measure Capital consumption, stress the contracts, and analyze their performance with the hypothesis that all the contracts of the pool present a common risk sensitivity behavior.

But, as Mr. Draghi is pointing out, this is not enough, the level of detail (granularity) that is required today is much higher than the levels of detail required before the Financial Crisis.

SAP Bank Analyzer architecture is capable of fulfilling these requirements, with two architecture pillars:

1) Contracts and Exposures are individually analyzed by the Bank Analyzer Risk Engines. Consolidation of the Results, according to the reporting dimensions, comes later.

This bottom-up approach in which all the contracts and exposures are analyzed and stressed allows a fine-grained analysis of the Risk position of the bank;  supporting the determination of the Risk Weighted Assets and Capital consumed by any potential set of reporting dimensions.

On the other hand, the system stores the required Operational Information in the Source Data Layer, and the very detailed analytical information on the Results Data Layer, opening the gate for drilling-down from the aggregated to the detailed data, and facilitating the reconciliation.

2) The high-performance capabilities of the in-memory HANA Database, provides the capacity of processing high volumes of data with response times that can’t be provided by traditional (not in-memory) databases.

I still remember, when years ago, in my first Bank Analyzer project, the client complained, because a Credit Risk calculation with Bank Analyzer took for several hours, when apparently, other products promised to provide the calculation much faster.

The reason is that SAP Bank Analyzer calculates one by one, the Risk Weighted Assets of every contract and exposure, with the detailed granularity required by the Banks' Integrated Reporting Dictionary, and mentioned by the president of the ECB.

But today, we also have the high performance capacity of the Hana in-memory database, which is capable of offering the computing power necessary for running high-granularity analysis in the same time that other systems calculate aggregated, low-granularity analysis.

As we commented months ago, when we talked about the SAP Bank Analyzer value proposition for fulfilling the BCBS 239 requirements, the Banks' Integrated Reporting Dictionary is not an isolated piece of regulation. The whole regulatory framework is been transformed, and oriented towards disclosure and capital optimization.

https://www.linkedin.com/pulse/bcbs-239-principles-sap-bank-analyzer-ferran-frances

Consequently we need a holistic approach for fulfilling the regulatory requirements.
We’ll come back to this topic in a future blog.

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