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

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

A common mistake is confusing Hedge Management with Hedge Accounting.

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

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

Effective Hedge Management requires 3 steps.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Let's connect on Twitter: @FerranFrancesGi

Looking forward to read your opinions.

Kind Regards,
Ferran.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

Looking forward to read your opinions.

Kind Regards,
Ferran.

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

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

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

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

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

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

Consequently, the main challenge is Capital Scarcity.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

From an Operations perspective, this approach represents several challenges.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Reduction of settlement time from days to minutes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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