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.