data management of the accounting for financial instruments key data valuation

Best_Practice_BA_KDV_DataManagement_V21.doc – 03.11.2008

Best Practice

Data Management of the Accountingfor Financial Instruments –

Key Date Valuation

Dietmar-Hopp-Allee 16D-69190 Walldorf

CS STATUScustomer published

DATE VERSION

Nov-03 2008 2.1

SOLUTION MANAGEMENT PHASE SAP SOLUTION

Design Operations Generic Best Practices for Bank Analyzer

TOPIC AREA SOLUTION MANAGER AREA

Data Management of the Accounting for FinancialInstruments - Key Date Valuation

Data Volume Management

Best PracticeData Management of the Accounting for Financial Instruments Key Date Valuation

© 2008 SAP AG - Best_Practice_BA_KDV_DataManagement_V21.doc page 2/28

Table of Contents1 Management Summary 3

1.1 Goal of Using This Service 31.2 Alternative Practices 31.3 Staff and Skill Requirements 31.4 System Requirements 41.5 Duration and Timing 4

2 Best Practice Procedure 52.1 Why Data Management? 52.2 General Conditions 52.3 Design of Bank Analyzer IAS 5

2.3.1 Business Content 62.3.2 General Design Key Date Valuation 7

2.3.2.1 Financial Position Object 72.3.2.2 Calculation Management 82.3.2.3 Calculation Procedure 102.3.2.4 Content of Calculation Procedures 122.3.2.5 Amortization, Valuation and Hedge Adjustment 122.3.2.6 Deferred Tax 142.3.2.7 Transfer Postings of Currency Valuations 142.3.2.8 Valuation of Foreign Currency Positions 14

2.3.3 Data Management of Key Date Valuation 142.3.3.1 Conditions 142.3.3.2 Calculation Model of Database Growth 152.3.3.3 Daily Versus Monthly Processing 172.3.3.4 Key Date Valuation Process with Reset Valuation 18

2.3.4 Database Growth Monitoring Setup 242.3.4.1 Operations Architecture 242.3.4.2 System Requirements 27

Index of Figures 28



1 Management Summary

1.1 Goal of Using This Service

Companies expect high availability and continuity of their solutions, flexibility to react in a short time on legalor business changes, and lowering total cost of ownership (TCO). This document will focus especially on thereduction and stabilization of total cost of ownership, by highlighting the impact on database size and growththrough considering several influencing factors during the implementation of the Bank Analyzer Accountingfor Financial Instruments (AFI) solution

With this Run SAP document, you gain experiences from other customer projects to consider the design ofthe process in the most efficient manner and therefore reduce TCO costs during the implementation of yoursolution and operation phase.

Optimized database growth of core business processes is one key requirement for any successful operationin a banking environment. The IT department of a bank is usually facing the following challenges in this area: Legal requirements (governmental restrictions regarding archiving and retention periods) High performance requirements of mass data processing, which can be negatively impacted by huge

database tables and fast database growth Reduction of TCO costs for the operation of the system, e.g. cost for system administration and disks

requirements or increased time frame for DB reorganization Limited time windows for archiving of tables because of the high workload of the system

The document will enable you to understand the impact of business decisions regarding settings for key datevaluations on the database growth. In general, the daily key date valuation and a key date valuation withreset leads to a significant higher database growth as explained in detail in the document. This shouldalready be considered during the Blueprint phase and the creation of the specification documents for the KeyDate Valuation (KDV) process.

1.2 Alternative Practices

Bank Analyzer data management experts can support you during the Design and the Setup of the Key DateValuation process ordering a Data Volume Management service as part of a premium support engagement.This service is exclusively available within an SAP Support engagement (that is SAP Enterprise Support,SAP Max Attention, SAP Safeguarding, SAP Premium Support or as a single service on request in case ofengagement evaluation or de-escalation).

1.3 Staff and Skill Requirements

To implement this Best Practice, you require a Data Volume Management expert with detailed knowledge ofthe Key Date Valuation process. This expert is responsible for the data management strategy and the sizingof the future solution. Already during the Design phase the expert should define how to manage and reducethe future expected database growth by following a holistic approach that considers and integrates thefollowing options: data avoidance, data summarization, data deletion and data archiving.



1.4 System Requirements

The document is only valid for the Key Date Valuation process of the Bank Analyzer Accounting for FinancialInstruments solution and is mainly based on BA release 5.0.

1.5 Duration and Timing

Duration and timing of the Data Volume Management service have to be determined based on the scope andthe needs of the customer.



2 Best Practice Procedure

Before performing this Best Practice, ensure that you complete the following preliminary tasks or checks inthe system: Collect the relevant business requirements regarding the functionality that should be implemented for the

Key Date Valuation process Collect the volume information of the product catalog that will be implemented Make sure that general hardware capabilities and sizing figures are available

2.1 Why Data Management?

To implement Run SAP recommendations means to follow SAP Best Practices of how IT can run a bankingsolution more efficiently. This document focuses on Best Practices for Key Date Valuation data managementof the Bank Analyzer AFI scenario and the consequences and means for IT departments with regard toperformance and data management. It also describes ways of how to implement SAP Bank Analyzer KeyDate Valuation with an optimized data design with regard to database growth and how to set up thecustomizing in a manner that the system will run on a very high performance to ensure that the businessrequirements of banks are met. The purpose of the document is to create customer awareness of whatbusiness decisions bring about in terms of database growth and performance as database growth (andperformance) can be influenced by taking the right decisions during implementation. Usually, the amount ofwork increases significantly when you have to change the design of the solution in a late project phase orafter the go-live of the solution.

A Data Volume Management strategy contributes to The risk mitigation through early identification of expected data volume The reduction of the total cost of ownership by minimizing the monthly data growth

2.2 General Conditions

The document will not cover all possibilities of the calculation management of the Key Date Valuation processbut focuses mainly on the business content customizing of Bank Analyzer release 5.0 and will provide aninsight in the flow generation process and its expected impact on database growth and performance, which ishelpful in the Design and Implementation phase of the Accounting for Financial Instruments scenario. Thedescribed scenario is based on an exemplary portfolio of a model bank.

The general calculation of the database growth is also relevant for the Banking Services releases 6.0 and 7.0.As of release 7.0 there is also an SDL aggregation available, which can significantly reduce the data volumefor retail products like Current Accounts and Savings Accounts.

2.3 Design of Bank Analyzer IAS

The following chapters provide an introduction to the Bank Analyzer AFI architecture, which is a preconditionto understand the used calculation model. After the description of the general design, an estimation of thedatabase growth for a chosen sample is shown in detail

Bank Analyzer is a generic solution for the current external reporting requirements. It is based on theIntegrated Finance and Risk Architecture (IFRA).



The figure below shows the system architecture and the data flow needed for IAS 32/39, beginning inoperational systems through the layers of AFI to final reporting in BI.

Figure 1 Solution architecture

The process and methods layer (P&M layer) contains all the processes like Key Date Valuation and methodswithin the application context of the business solutions of the Bank Analyzer platform. The generated resultsare based on data from the SDL and from data that has already been delivered from the feeder systems orthat has been calculated in previous steps and is stored in the Result Data Area (RDL). The RDL managesconsistent and reusable financial and risk data from various calculation and valuation processes for financialinstruments and financial transactions.

2.3.1 Business Content

The BA business content includes comprehensive configuration and can be used to quickly implement thesolution, thus reducing total cost of ownership for the implementation and operation in your softwareenvironment. Without implementing business content, efforts for the system setup are significantly higher,due to the fact that business content offers a wide range of pre-configured settings, like product types. Thedescribed database calculations in the document are all based on the BA business content 5.0.



Figure 2 Business content AFI

2.3.2 General Design Key Date Valuation

Key Date Valuation is a process step of the process and method layer that is used to valuate financialinstruments for a certain key date, usually at period end. Three processes are available in the Key DateValuation package. Key Date Valuation is carried out with the report for key date valuations for all financialpositions or for single financial positions. The document only focuses on the behavior of the Key DateValuation process for all financial positions. The resulting valuations can be reversed with the relevant reportfor reversing key date valuations.

At the beginning of a key date valuation you can decide if the key date valuation is to be reset in the sameprocess. This means that the valuation document with the posting date is reversed on the date after the keydate valuation. A more detailed description about the impact of the reset functionality is given in chapter2.3.3.4.

2.3.2.1 Financial Position Object

Financial Position Objects (FPOs) are entities in the Bank Analyzer accounting scenario. They carryaccounting-relevant characteristics and are used for data consistency during accounting processing. Theposition object automatically "inherits" all characteristics from the first business transaction of this financialposition.



Figure 3 Financial position objects

You can also define additional defining and descriptive characteristics for the position object. Thecharacteristics of the position object are populated from primary objects (accounts, financial instruments, andfinancial transactions) of SDL. The defining characteristics of the financial position object are populateddirectly from the first business transaction. The descriptive characteristics can either be populated directly bythe characteristics in the business transaction or derived from these characteristics.

2.3.2.2 Calculation Management

Calculation management is part of the internal processes of Key Date Valuation. The main task of thecalculation management is to define and execute the calculation.

Calculation management specifies how a business transaction is transformed into flow results of a resultsdata area. In other words, it specifies which document lines are generated in which order and how the keyfigures are calculated and populated accordingly.

This approach is based on: Calculation procedures Calculation steps Calculation methods Item types (Posting) key figures

Posting key figures are key figures that are defined on the basis of accounting-relevant key figure classes.The figures below show the differences between the calculation management in release 5.0 and 6.0.



Figure 4 Calculation management overview for BA 5.0

Figure 5 Calculation management overview for BA 6.0



2.3.2.3 Calculation Procedure

Figure 6 Derivation of calculation procedure: Example

The KDV calculation procedure can be derived from financial position types, holding category or all otherFPO characteristics within the key date valuation.

Each calculation procedure is assigned to a template that determines: Which calculation step types can (or must) be included in the procedure In which order the calculation step types are processed

The procedure class of a calculation procedure describes in which process the calculation procedure is used. Valuation procedure

The calculation step category determines: Which calculation methods are permitted for a calculation step Whether and when a calculation step can take place in a calculation procedure derived from a specific

template Item types for the derivation of key figures



Figure 7 Assignment of calculation steps to calculation procedure

Figure 8 Calculation procedure: Overview

A calculation step category and a calculation method are assigned to the customer-defined calculation step.The item types define which key figures are affected and which posting logic is concerned.

Calculation steps are grouped to forms and represent the highest level of detail.

Calculation methods are used to determine the value.



2.3.2.4 Content of Calculation Procedures

The following calculation step categories are used in the calculation procedures of the KDV class. The firstthree calculation step categories are covered in section 2.3.2.5:

Amortization (0S05)

Cash flow-based products can be valued at continued acquisition costs. The difference between acquisitionvalue and nominal value is distributed over the term. The value calculated in this calculation step is posted toa P&L key figure.

Valuation (0S06)

Positions not assigned to the HTM or OLR holding categories can be valued at fair value. The valuecalculated in this calculation step can be posted to a P&L key figure or against the revaluation reserve.

Hedge adjustment (0S49)

If a position is part of a hedging relationship, then the hedge adjustment book value component is calculated.The hedge adjustment is not described in detail in this document and is only mentioned to ensurecompleteness.

Accruals (0S07, 0S08, 0S54, 0S55)

Key figure values of components that must be closed out over a specific time period are updated.

Deferred taxes (0S28, 0S29)

Deferred taxes are calculated based on the difference between the tax value according to local accounting(external tax value) and the IAS book value. Deferred taxes are calculated only on the key date provided thatthe external tax value is made available.

Currency valuations

In the case of products for which foreign currency items were created (forward exchange transactions, foreigncurrency swaps, stocks of the AFS holding category), these items (object item, general item, P&L item,cumulated P&L item) must be evaluated at the exchange rate of the key date.

2.3.2.5 Amortization, Valuation and Hedge Adjustment

This section describes how the calculation steps of amortization, hedge adjustment and valuation areprocessed. Note that the continued acquisition costs are the sum of all amortizations and acquisition valuesfor a position.

In the case of hedged positions, there is the additional book value component for the hedge adjustment.

In the case of an OLR loan, the book value is the sum of the amortized cost and the sum of the hedgeadjustment documents for the position.

In the case of a transaction to AfS or HfT, you must add the documents for "instrument valuation" to this valueto obtain the book value (and hence the fair value).



Figure 9 Composition of the amortized cost and fair value

Bank Analyzer strictly separates the data basis for the amortization, fair value, and hedge adjustmentcalculation steps from the value determination (in the fair value server).

The data basis is the data that currently exists in accounting. In the calculation steps, accounting uses thecalculation method to request values based on this data basis for a date/SDL time stamp.

The calculation program in the fair value server (see the Fair Value Server SMG) determines the value thatwas requested for a date- or time stamp. In cash flow-based transactions, the accounting values to bedetermined are generally calculated using fictitious cash flows.

An amortization calculation in Bank Analyzer is generally only useful for cash flow-based transactions. Anamortization must be calculated if a position is changed on a long position.

Note: Amortization on short positions can be avoided as follows: Create an additional calculation proce-dure without amortization. The position situation (FPO characteristics /BA1 C55QSIGN or /BA1C55VSIGN/) isthen used as a source characteristic for deriving the calculation procedure and the procedure is executed withor without amortization depending on the plus/minus sign of the position. The /BA1/C55QSIGN and/BA1/C55VSIGN characteristics are available for both, the source and target position of a business trans-action.

For information about the valuation of cash flow-based transactions, read the Fair Value Server and CashFlow Generation SMGs.

Notes on amortization

Only one amortization occurs on a position per day. No amortization occurs for an initial purchase.



2.3.2.6 Deferred Tax

Deferred tax obligations are future profit tax obligations that result from taxable temporary differences.Deferred tax claims are tax benefits obtainable in future. The latter can result from deductible temporarydifferences, loss carry forward or unused tax credits. All the financial products (as in IAS 39) that aremanaged in accounting are subject to the automatic determination and posting process.

2.3.2.7 Transfer Postings of Currency Valuations

According to IFRS, foreign currency revenues must be converted to the financial reporting currency using thekey date rate. Each financial position has exactly one calculation procedure that is executed for the transferposting of foreign currency revenues. This procedure is automatically triggered after each calculation step.

2.3.2.8 Valuation of Foreign Currency Positions

For each foreign currency, one general, profit and total position exist. These are valuated once during keydate valuation. The object position exists on financial position level and is valuated during the valuation of thecorresponding financial position.

Note: The operational systems of a bank, and therefore the supplied business transactions, do not know thefinancial position management in Bank Analyzer. This means that when a complex financial position objectwith multiple components is generated in Bank Analyzer, for example, it is possible that only one singlebusiness transaction will affect all the components of the position. It is then the task of Bank AnalyzerAccounting to distribute the results of the Key Date Valuation process to the relevant components.

2.3.3 Data Management of Key Date Valuation

The data management of Key Date Valuation is mainly depending on the calculation procedures that areexecuted per object during the Key Date Valuation process. An overview of the relevant product types for thisinvestigation is provided in the document.

2.3.3.1 Conditions

The calculations are based on the business content 5.0 and the standard configuration settings for thechosen products. Generally, they are also valid for the same constellation of product type, holding categoryand used calculation modules of the Banking Services releases 6.0 and 7.0. The impact of the general FPO(GFPO) on the database growth is very limited so that it was not necessary to include the GFPO in ourcalculation model. Asset/liability postings due to asset liability changes are not covered in the calculationmodel to keep it simple and understandable. However, a very high number of such swinging contracts(typically accounts) will likely have an impact on processing time.

In real business scenarios of a bank, the implementation has to cover a product range that is broader thanthat used in the example. The example can only give a rough overview and provide an insight in the impact ofcertain products, customizing settings and business decisions on the database growth of the Key DateValuation process.



2.3.3.2 Calculation Model of Database Growth

This section provides an introduction to the database growth calculation of the Key Date Valuation processbased on the general data mode that was explained in detail in the previous chapters.

In the table below a simplified differentiation between product types, holding categories, used calculationmethods was chosen to allow a calculation of the database growth. At the end of each line in the columnFlows per KDV, the expected number of flows per product is shown. Some products are listed twice becauseof a different Holding category which is reflected in a different calculation procedure. For some products, acurrency valuation was taken into account, to have a more realistic business scenario. Structured productswill always be saved on database level with one header FPO and two related legs.

Very obvious in the table are the differences between the products with and without currency valuations.Valuations in foreign currencies must be converted to the financial reporting currency using the key date rate.This means that each flow is generated in object currency and financial reporting currency. Besides that alsoP&L-relevant postings and transfer postings are generated out of the currency conversion, which alsoincreases the number of generated flows.

For an estimate of the database growth per KDV execution, the size of each flow document in the AFIscenario was calculated with 4.5 KB, which includes a debit and credit item.



To summarize the findings: Due to the currency valuation, customers that have a high number of foreigncurrency financial instruments and financial transaction will have a much higher database growth thancustomers with a small portion of foreign currency objects.

Second, an impact on the database growth and performance can also be expected for current accountsbecause of the accrual calculation within the KDV for that product type.

Note: As of release 6.0 the accruals can also be delivered from the legacy environment to a separate resultdata area for accruals. This will allow switching off the calculation method for accruals in the Key DateValuation process. The KDV for all financial positions will then still consume CPU power for the selection ofthe current accounts but it will be much less compared to other products with valuations because theaccounts will be selected as well in the KDV process for all financial positions.

ProductType

Number ofFPOs

HoldingCategory

Amortization Accruals FairValue

DeferredTaxes

Curr.Valuation

Flows per KDV perFG/FI (Delta)

S_BOND 1 HFT X X X 3

S_BOND 1 AFS X X X 3

S_MCBOND 3 HFT X X X X 34

S_MCBOND 3 OLI X X X 34

S_CAPFLR 1 HFT X X 2

S_CCSWAP 3 HFT X X X 24

S_CDSWAP 1 HFT X 1

S_FET 3 HFT X X 12

S_FRWRAG 3 HFT X X X 24

S_FUTURE 1 HFT X X 2

S_FXSPOT 3 HFT X X 12

S_IRSWAP 3 HFT X X 4

S_LOAN 1 LAR X X 2

S_OPTION 1 HFT X 1

S_OTCOPT 1 HFT X 1

S_REPO 1 LAR X X X 4

S_SECLND 1 LAR / OLI X X X 4

S_SHARE 1 AFS X X 2

S_SHARE 1 HFT X 1

S_SWAPTN 1 HFT X 1

S_TIDEPO 1 OLI X X 2

S_WRBOND 3 AFS X X X 6

S_WRBOND 3 HFT X X X 6

S_CUACCT 1 HTM X 1



All the mentioned findings are also shown in the example below.

Product Type Holding Category Summary ofFlows

Number of Objects Total DB Growth inKB

Total DB Growthin GB

S_BOND HFT 3 2000 27000

S_MCBOND HFT 34 200 30600

S_CAPFLR HFT 2 200 1800

S_CCSWAP HFT 24 2000 216000

S_CDSWAP HFT 1 24000 108000

S_FET HFT 12 12000 648000

S_FRWRAG HFT 24 4000 432000

S_FUTURE HFT 2 4000 36000

S_LOAN LAR 2 50000 450000

S_OTCOPT HFT 1 5000 22500

S_REPO LAR 4 4000 72000

S_SHARE AFS 2 500 4500

S_TIDEPO OLI 2 50000 450000

S_CUACCT HTM 1 100000 450000

Total 307400 2948400 2,81

In the table above, a random example was chosen to show the impact on the database growth. The overalldatabase growth to be expected for the example is 2.81 GB per execution. A detailed analysis reveals thatmost part of database growth is related to the structured foreign currency products (forward exchangetransaction = S_FET and forward rate agreement (FX) = S_FRWRAG), due to the high number of flows thatare necessary for a fair value evaluation as well as a currency conversion per financial transaction.

The standard retail products loans (S_LOAN), current accounts (S_CUACCT) and time deposits (S_TIDEPO)also contribute more than 1,35 GB to the expected database growth but it is much less per financialtransaction compared to the structured products per execution. If a currency conversion is required for theseproducts, too, they will also become more expensive with regard to the database growth.

Note: The main database growth for current accounts and time deposits will be caused in the Post ExternalBusiness Transactions and the Update Secondary Business Transaction processes, due to the high numberof expected daily postings per account.

2.3.3.3 Daily Versus Monthly Processing

Some banks might require the calculation of daily accruals especially for Cash Flow-based transactions. Thisis often due to the need to get precise steering information for the business. Some banks use their daily Profit& Loss (P&L) to derive information for their business. They require the most accurate information. Dependingon the underlying business, the daily accruals can have certain impact on the reporting figures.

In general, these reports are created for the management and not for statutory or regulatory reasons. Oneexample for such a management report is the daily P&L to analyze the business. According to the month-end



P&L, all relevant information should be included within the daily reports, which means that the figures foreach day should represent the current business as of the day. For this reason the reports should also includeaccruals to present the figures in the correct period. For example, for a branch which is very strong in theretail business, interest income from loans should be reported on daily business with the interest accrued ona daily basis. A single loan contract with a volume of several millions has an impact on the daily result andthis cumulates with an increasing number of those contracts.

However, since these reports are in general more of the character of management reports, it is notrecommended to actually post the daily accruals on a daily basis and to reverse them the next day. Thiswould lead to an enormous increase of postings and finally increase your database size and negativelyimpact the performance of the system. As mentioned above, the information regarding daily accruals is notrequired for regulatory requirements. It is usually sufficient to have the accrual information only as statisticalinformation. To get this information, the reports should be combined with the real postings from FI and CO toshow the accurate daily figures. There is no need to post the daily accruals into the general ledger and toreverse the postings the next day.

It is very important to verify in advance if the benefit of the additional information provided by the daily accrualcalculation will justify the 20 times higher database growth and therefore a significantly higher TCO for theoperation of the system. The figures will become more obvious in the next example: If the businessdepartment requires a daily accruals calculation or daily valuation of the fair value, the influence on thedatabase growth caused by KDV will be much higher. Let’s assume that the KDV runs for 20 business dayseach month. For a KDV without reset, it would lead to a database growth of 56.2 GB per month in comparisonto 2.81 GB for a monthly execution. The comparison of the figures is impressing if you compare the dailyagainst the yearly KDV. For monthly processing of the KDV without reset, a database growth of 33.7 GB canbe expected per year. The database growth for a daily processing of the same KDV would lead to a databasegrowth of 674.4 GB per year.

The Key Date Valuation process was developed to fulfill regulatory requirements for IAS reporting in banks.Therefore the Key Date Valuation process is generally designed as part of the month end process. Thismeans the IAS-relevant valuations are expected to be executed only once a month.

2.3.3.4 Key Date Valuation Process with Reset Valuation

Beside the usual Key Date Valuation process, you have the possibility to execute the Key Date Valuationprocess with a reset valuation (see reset flag below).



Figure 10 Reset valuation

If the Key Date Valuation has been started with reset, the corresponding cancellation documents aregenerated for the following day in addition to the flows resulting out of the Key Date Valuation process. Thestatus of the position object is set on the day of the reset. This means that for nearly each flow generated outof the Key Date Valuation process a corresponding cancellation document is generated for the following day;one because of the cancellation and one because of the new valuation of the financial position on the keydate. It is important to note that not all of the generated flow items can actually be cancelled, for example, theflows out of the amortization.

If the Key Date Valuation is started with a reset, the reversals (inverse postings) for the generated documentsare generated for the following day. This is true in general for the valuation of unsettled transactions(characteristic in the position object).

In the next figures a business example is shown to describe the differences from the business perspective fora financial asset like accruals. To be able to describe the business impact, several points for an evaluation ofa transaction have to be considered. In the example below, timestamp 1 (t1) will be the point of the inflow, t2will be the time of the cancellation and t3 will be the date where the new Key Date Valuation has to take placeto consider the changes in the exchange rate.

We assume an exchange currency rate USD to EUR of 1.25 in timestamp 1 (t1). The evaluation will then takeplace in t2 and the exchange currency rate will have changed to a rate of 1.2 in t3.



Business example without reset

As shown in the example without reset, the usual P&L flow happens in timestamp1 (t1). The accruals willhave an amount of -100 USD in object currency, which will be equal to -80 EUR in reporting currency. In t3the currency exchange rate has changed to 1.2 and a currency gain of 3.33 EUR can be realized.

Bank Analyzer

t1 t3Financial Asset - Accruals ObjCurr -100,00

ObjCurr 100,00 -100,00RepCurr 80,00

P/L

Statistical ObjCurrObjCurr 100,00RepCurrEquivalent Value 80,00 3,33

P/L - Position in USD

Currency Gain 3,33ObjCurr -80,00 -3,33Total Position in EUR

Equivalent Value -80,00 -3,33

The same is shown in the next table: In the balance sheet, the object position will stay at -100 USD, which isequal to the book value of 83.33 EUR in timestamp 3. A currency gain of 3.33 EUR can be realized in theP&L statement at timestamp 3.

OW BW

B/S Financial Asset - Accruals -100,00 -83,33

P/L Currency Gain P/L - Position in USD 3,33 3,33

P/L P/L ObjCurr in USD 0,00 0,00

P/L P/L ObjCurr in EUR 80,00 80,00

FX P/L - Position in USD 100,00 83,33

FX Total Position in EUR -83,33 -83,33

EV Equivalent Value P/L - Position in USD 0 83,33

EV Equivalent Value Total Position in EUR 0 -83,33



Business example with reset

In the table below, the same example for the database growth is calculated for a Key Date Valuation withreset to show the implications for the business. Timestamp t1 will be identical in both scenarios. In t2, thecurrency conversion is cancelled, so that at the end the currency conversation from t1 will be cancelled. Intimestamp 3 a new Key Date Valuation will take place, but for t1 and t3 no P&L-relevant posting will begenerated and, because of the cancellation of the last Key Date Valuation, there is no currency gain to berealized. Therefore, the Key Date Valuation with reset is a year-to-date valuation.

OW BW

B/S Financial Asset - Accruals -100,00 -83,33

P/L Currency Gain P/L - Position in USD 0,00 0,00

P/L P/L ObjCurr in USD 0,00 0,00

P/L P/L ObjCurr in EUR -83,33 -83,33

FX P/L - Position in USD 100,00 83,33

FX Total Position in EUR -83,33 -83,33

EV Equivalent Value P/L - Position in USD 0 83,33

EV Equivalent Value Total Position in EUR 0 -83,33

After a short description of the differences of both business scenarios, the impact on the database growth willbe discussed. Due to the fact that Bank Analyzer has to write a cancellation document for nearly each flowout of the Key Date Valuation the database growth will be much higher in this scenario.

-83,3380,00-80,00Equivalent Value-83,3380,00-80,00ObjCurrTotal Position in EUR

Currency Gain83,33-80,0080,00Equivalent Value

RepCurr83,33-100,00100,00ObjCurrP/L - Position in USD

Statistical ObjCurr-83,33-80,0080,00RepCurr

100100,00-100,00-100,00100,00ObjCurrP/L

-100100,00-100,00ObjCurrFinancial Asset -Accruals

t3t2t1

Bank Analyzer

-83,3380,00-80,00Equivalent Value-83,3380,00-80,00ObjCurrTotal Position in EUR

Currency Gain83,33-80,0080,00Equivalent Value

RepCurr83,33-100,00100,00ObjCurrP/L - Position in USD

Statistical ObjCurr-83,33-80,0080,00RepCurr

100100,00-100,00-100,00100,00ObjCurrP/L

-100100,00-100,00ObjCurrFinancial Asset -Accruals

t3t2t1

Bank Analyzer



First of all the differences in the flow creation are calculated based on the data model and product type(shown in the next table). The last two columns of the table below show the differences between a KDV withand without reset on product type level.

ProductType

Numberof FPOs

HoldingCategory

Amortization Accruals FairValue

DeferredTaxes

Curr.Valuation

Flows perKDV per

FG/FI (Delta)

Flows perKDV per

FG/FI (Reset)

S_BOND 1 HFT X X X 3 5

S_BOND 1 AFS X X X 3 5

S_MCBOND 3 HFT X X X X 34 58

S_MCBOND 3 OLI X X X 34 58

S_CAPFLR 1 HFT X X 2 3

S_CCSWAP 3 HFT X X X 24 38

S_CDSWAP 1 HFT X 1 2

S_FET 3 HFT X X 12 24

S_FRWRAG 3 HFT X X X 24 38

S_FUTURE 1 HFT X X 2 3

S_FXSPOT 3 HFT X X 12 24

S_IRSWAP 3 HFT X X 4 6

S_LOAN 1 LAR X X 2 3

S_OPTION 1 HFT X 1 2

S_OTCOPT 1 HFT X 1 2

S_REPO 1 LAR X X X 4 7

S_SECLND 1 LAR / OLI X X X 4 7

S_SHARE 1 AFS X X 2 3

S_SHARE 1 HFT X 1 2

S_SWAPTN 1 HFT X 1 2

S_TIDEPO 1 OLI X X 2 3

S_WRBOND 3 AFS X X X 6 10

S_WRBOND 3 HFT X X X 6 10

S_CUACCT 1 HTM X 1 2

Summary of the findings: The created number of flows will nearly be doubled by a Key Date Valuation withreset because the valuation document from the last KDV is cancelled on the day after the Key Date Valuationis executed. This means that for each created flow document a cancellation document has to be created forthe next day. Only the amortization-related flows will not be canceled each time.

This can be very crucial for the TCO of your Bank Analyzer accounting infrastructure and should thereforealready be considered during the design of the Key Date Valuation process.



Product Type HoldingCategory

Summary ofFlows with Reset

Number ofObjects

Total DB Growth(Reset KDV) in KB

Total DB Growth(Reset KDV) in GB

S_BOND HFT 5 2000 45000

S_MCBOND HFT 58 200 52200

S_CAPFLR HFT 3 200 2700

S_CCSWAP HFT 38 2000 342000

S_CDSWAP HFT 2 24000 216000

S_FET HFT 24 12000 1296000

S_FRWRAG HFT 38 4000 684000

S_FUTURE HFT 3 4000 54000

S_LOAN LAR 5 50000 675000

S_OTCOPT HFT 2 5000 45000

S_REPO LAR 7 4000 126000

S_SHARE AFS 6 500 6750

S_TIDEPO OLI 5 50000 675000

S_CUACCT HTM 2 100000 900000

Total 257900 5119650 4,88

The mentioned differences are also shown in the table below. The first calculation of 2.81 GB was made for aKDV without reset. The second calculation (GB) was done for a KDV with reset. If it is really necessary toexecute the KDV with reset, you have to expect a nearly doubled database growth per execution (2.81 to4.88 GB) in comparison to the execution without reset.

Product type Number of Objects Total DB Growth(Delta) in KB

Total DBGrowth in KB

Total DB Growth(Reset) in KB

Total DB Growth(Reset) in GB

S_BOND 2000 27000 45000

S_MCBOND 200 30600 52200

S_CAPFLR 200 1800 2700

S_CCSWAP 2000 216000 342000

S_CDSWAP 24000 108000 216000

S_FET 12000 648000 1296000

S_FRWRAG 4000 432000 684000

S_FUTURE 4000 36000 54000

S_LOAN 50000 450000 675000

S_OTCOPT 5000 22500 45000

S_REPO 4000 72000 126000

S_SHARE 500 4500 6750

S_TIDEPO 50000 450000 675000



S_CUACCT 100000 450000 900000

Total 257900 2948400 2,81 5119650 4,88

This fact will be even more critical in combination with a daily Key Date Valuation processing. If the businessdepartment requires a daily accruals calculation or daily valuation of the fair value, the influence on thedatabase growth caused by KDV with or without reset will be much higher. Let us assume that KDV shall runfor 20 business days each month. For a KDV without reset this would lead to a database growth of 56.2 GB incomparison to 97.6 GB per month. This leads to 674.4 GB per anno and 1171.2 GB per anno caused by theKDV process. The comparison of the figures is very impressive if you compare the daily against the yearlyKDV. For monthly processing of the KDV with reset a database growth of 58.6 GB can be expected. The dailyprocessing of the same KDV would lead to a database growth of 1171.2 GB.

Note: Based on our experiences, archiving of created flows takes place earliest after 15 months becausemost banks leave all flows in the system for at least one complete business year and some additional monthsaccording to regulatory requirements.

Recommendation: If you compare the best case, KDV without reset executed monthly (33.7 GB), and theworst case, KDV with reset daily (1171.2 GB), the impact of the database growth gets very obvious. Alreadyduring the Blueprint phase and the creation of the specification documents for the Key Date Valuation, youshould therefore be aware of the doubled database growth for a Key Date Valuation with reset per executionand the importance of a daily and monthly processing for the data management of your Bank Analyzersolution

Therefore we recommend designing the Key Date Valuation process in a manner that the KDV with resetcan be avoided, otherwise the TCO of the system will be much higher.

2.3.4 Database Growth Monitoring Setup

2.3.4.1 Operations Architecture

To monitor the database growth either during the test phase or in running operations, banks can use theBusiness Process Monitor of SAP Solution Manager. It is designed to monitor the database growth of severalapplications. In the mentioned case, the database growth per table is the most relevant monitor. The informa-tion is collected in SAP Solution Manager and stored in BI cubes and therefore offers the possibility toanalyze the cubes with the available BI reporting functionality. From the InfoCube, different charts can becreated to help the management to analyze the performance of the critical processes and support them tomake decisions.

Figure 11 shows the landscape for database growth monitoring of different SAP Banking solutions.



Figure 11 Solution architecture monitoring

Generally, the activation of the Business Process Monitor session and the implementation of the relevant BIreporting can be supported by SAP AGS as part of a premium support engagement. For production usage,complex customer-specific queries can be created based on the customer’s requirements.

The next figures show some general database growth charts.

Figure 12 Chart of database growth in total per system



The chart shows the database size per satellite system and their contribution with regards to database growthto the overall system infrastructure. These kinds of charts will help the IT department to identify the mostcritical systems in a system landscape as regards database growth.

The next chart is one level below the first one. It provides detailed information about the database growth perday.

Figure 13 Chart of database growth per system per day

The screen shown in the last figure provides detailed information regarding the database growth per system.Here the user can investigate in detail the tables that contribute most to the database growth of a system andwill get some more detailed information about the object size, number of indices and number of records perday. Especially the columns Object Size and Number of Records with the possibility of a daily comparison willallow a detailed analysis of the database growth for a Key Date Valuation process. Here, the monitoringshould be focused on the relevant result data area tables and their growth after a Key Date Valuation processwas executed.



Figure 14 Sample screenshot: Database growth of a system

2.3.4.2 System Requirements

To implement the above concept, the following software components are required in SAP Solution Mangerand satellite system.

SAP Solution Manager: ST: SAP Solution Manager tool that contains the general SAP Solution Manager infrastructure. ST-SER: SAP Solution Manager service tool containing all service sessions, incl. BPMon Setup session. BI_CONT: Business Intelligence Content that contains the predefined BPM InfoCube and BPM data

extraction process. Additionally, BI_CONT needs to be activated in SAP Solution Manager. The required release is 703 with

level 08 (SAPKIBIIP8).

Satellite system: ST-PI: SAP solution tools plug-in that contains coding for data collectors and cross-application monitoring

functionality. ST-A/PI: Application service tool that contains coding for the banking-specific mass activity data collector

(MassMan).

The current release of the above software component can be found in SAP Note 521820.



Index of FiguresFigure 1 Solution architecture 6Figure 2 Business content AFI 7Figure 3 Financial position objects 8Figure 4 Calculation management overview for BA 5.0 9Figure 5 Calculation management overview for BA 6.0 9Figure 6 Derivation of calculation procedure: Example 10Figure 7 Assignment of calculation steps to calculation procedure 11Figure 8 Calculation procedure: Overview 11Figure 9 Composition of the amortized cost and fair value 13Figure 10 Reset valuation 19Figure 11 Solution architecture monitoring 25Figure 12 Chart of database growth in total per system 25Figure 13 Chart of database growth per system per day 26Figure 14 Sample screenshot: Database growth of a system 27

© Copyright 2007 SAP AG. All Rights ReservedNo part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.The information contained herein may be changed without prior notice.Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries,zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBMCorporation.Oracle is a registered trademark of Oracle Corporation.UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of CitrixSystems, Inc.HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, MassachusettsInstitute of Technology.Java is a registered trademark of Sun Microsystems, Inc.JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented byNetscape.MaxDB is a trademark of MySQL AB, Sweden.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as theirrespective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. Allother product and service names mentioned are the trademarks of their respective companies. Data contained in this document servesinformational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any formor for any purpose without the express prior written permission of SAP AG.This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This documentcontains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP toany particular course of business, product strategy, and/or development. Please note that this document is subject to change and maybe changed by SAP at any time without notice.SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of theinformation, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind,either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages thatmay result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you mayaccess through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide anywarranty whatsoever relating to third-party Web pages.

data management of the accounting for financial instruments key data valuation

Documents