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.

Dynamic Collateral Management with SAP Bank Analyzer and the Blockchain.

Dear,

In my opinion, the Blockchain is the most important innovation of the Finance Technology in the last years.

The Blockchain represents to the Internet of Value, what the TCP IP Protocol represented for the Internet of Information 25 years ago.

In the same way that it was difficult to imagine Facebook, Amazon, Skype or Netflix 25 years ago, it's difficult to imagine the services that Blockchain will support in the future.

Today, we know that some services are about to be implemented in the Blockchain, some of the most important ones are:

International Payments.
http://www.ibtimes.co.uk/

Securities Trading.
http://www.wired.com/2015/12/

Both are major achievements in terms of efficiency and transparency, but today I'm going to focus on some implications of the second one.

As we discussed in previous blogs, we're in the middle of a systemic crisis whose main characteristic is Capital Scarcity, as a consequence Capital Optimization will be the priority of the Financial System that will emerge of this crisis.

Capital has many shapes, and one of the most important is collateral, consequently Efficient Management of Collaterals is a critical activity in Capital Optimization.

Securities are one of the most usual forms of collateral, they're liquid assets traded in an organized market which provides them an updated price.

Blockchain provides a revolutionary technology for the efficient trading of securities, as securities trading and ownership are moved to a public, efficient and structured database like the Blockchain, the opportunities of improving the use of these securities in collateral agreements also increase.

Efficient use collateral rights require reduce the Loss Given Default of the exposures by implementing risk mitigation techniques, but avoiding over-collateralization which freezes capital without generating any return.

But balancing collaterals and exposures in order or improving the Risk Adjusted Return on Capital (RAROC) is not an easy task. The Loss Given Default depends on the rating of the counterpart (or his Probability of Default), and the value of the collateral fluctuates every second. Consequently the assignment of Collateral portions of a Collateral Pool to the bank's exposures should be a dynamic activity, that must be adjusted as the market and counterparty situations change.

For instance, as the rating of the counterparty improves, or the collateral value increases, the LGD will be reduced till it achieves a limit (full collateralization) in which better rating or more col lateralization are not improving the Risk Weighted Assets. This collateral excess could be used as a guarantee in another transaction, like a Repurchase Agreement, which will improve the portfolio return, without compromising capital consumption.

On the other hand, if collateral value declines or counterparty rating gets worse, higher portions of the collateral pool will be required for reducing capital consumption.

But the above theory presents practical constrains; in order of facilitating the optimal distribution of collaterals we need some requirements to be covered.

- Accurate calculation of the collateralization levels of the bank's exposures.

- Efficient (including inexpensive transactions) trade of collateral rights.

SAP Bank Analyzer is the answer to the first request, Blockchain is the answer to the second.

With Bank Analyzer we can guarantee an accurate measure of the capital consumed by the bank's portfolio, individually or by portfolios.

Additionally, we can implement alerts in the Analytical Layer of Bank Analyzer Credit Risk Module, informing the Bank's Capital Manager of the exception situations (under or over capitalization) which will trigger his attention in order of taking corrective actions.

But we also need that the transaction costs (including fees, transaction speed and settlement risk) are reduced, because if not, the potential profits of managing dynamically the bank's collateral will be reduced by the transaction costs.

This is exactly what blockchain is offering us, efficient, inexpensive and transparent trading of securities rights.

But securitization and efficient management of collaterals also presents other challenges, we'll talk about them in future blogs.

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

Looking forward to read your opinions.

May the Force be with you.

Ferran.