Artificial Intelligence and Financial Chatbots with SAP Banking.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SAP Banking provides the technological architecture for tackling both requirements:

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

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

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

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

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

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

Looking forward to read your opinions.

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

Kind Regards,
Ferran Frances.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Let's connect on Twitter: @FerranFrancesGi

Looking forward to read your opinions.

Kind Regards,
Ferran Frances.

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.