An effective financial services performance management system should include the following key requirements:
· Flexible, efficient access to account level information
· Multiple views of the organization
· Matched rate funds transfer pricing at the account level of detail
· Flexible definition of cost accounting processes with strong accounting controls
· Powerful modeling capabilities
Together with OFSAA Funds Transfer Pricing, OFSAA Profitability Management addresses these requirements by linking general ledger, account-level, and statistical data together in a unique manner.
Topics:
· Multiple Dimensions of Profitability
· Overview of Profitability Management Methodologies
· Initial Loads to the Management Ledger
OFSAA Profitability Management allows you to construct customized solutions for enriching financial data to generate multidimensional Management Accounting profitability views. Without restricting your ability to select any dimension you choose, the following are representative examples of the types of multi-dimensional performance management views you can construct using OFSAA Profitability Management.
Topics:
· Key Processing Dimensions in the OFSAA Data Model
· User-Defined Organizational Units
· Product
· User-Defined Key Processing Dimensions
· Additional Profitability Dimensions
· Additional Working Dimensions
An Organizational View facilitates the measurement of profitability at any level in your organizational structure, such as Bank, Region, Company, Legal Entity, or Division level; or at lower levels such as Branch, Cost Center or Department. While the Organizational Unit Key Processing Dimension is normally designed to match Responsibility Centers (Cost Centers or Profit Centers) that are found both in your source systems and in your General Ledger extract, you may define additional “organizational” Key Processing Dimensions. For example, you might use the seeded Organizational Unit dimension in reconciling your instrument extracts to your Ledger data (where your Ledger Class Table is populated with an extract from your General Ledger) and you might use a second user-defined “organizational” Key Processing Dimension for Legal Entity or Company if one of those dimensions is present in your source General Ledger.
Alternatively, if you have more than one kind of Organizational dimension in your source General Ledger (e.g., Cost Center, Company, Legal Entity, Line of Business), you may be able to concatenate one or more such General Ledger dimensions in your ledger and source system extracts (e.g., Cost Center plus Company) to populate a compound Organizational Unit dimension in your OFSAA data model.
A Product View facilitates the measurement of profitability of specific product lines including
· On balance-sheet customer-facing products such as Checking, Savings, Time Deposits, Credit Cards, Commercial Loans, Consumer Loans, Credit Lines, or Mortgages
· On balance-sheet, internal products (non-customer facing products) such as Wholesale Funding or Investments
· Off-balance sheet customer-facing services such as Merchant Card, insurance policies, or mutual fund positions
· Off-balance sheet products that may be either internal or custom facing such as options, other derivatives, etc
A Customer View facilitates the measurement of customer profitability under any definition of customer you choose to implement. Examples of customers or customer segments might include demographic segments, commercial customers, high net worth customers, retail customer segments, etc.
A Channel View facilitates the measurement of the profitability of various methods for delivering products or services to your customer base. As with Customer, you may define your channels any way you wish. Examples of channels might include ATM, Electronic Banking, Telephone, Retail Branch, and Mail. A better understanding of the cost structures of your delivery channels can assist you in steering your customers to lower cost channels or in doing a better job of aligning true costs with revenues through fee structures designed to encourage customers to utilize lower cost channels.
Key Processing Dimensions are the keys that the OFSAA engines use to access and segment business data. Every Key Processing Dimension is present in nearly all of your business fact tables, and the usage of processing dimensions permeates most OFSAA rule types.
Seeded dimensions include Financial Element (only found in the Management Ledger), Organizational Unit, General Ledger Account, Common Chart of Accounts, and Product. You may add your own user-defined processing dimensions to your data model.
Used only in the Management Ledger, Financial Element classifies your data in a fashion not typically found in most General Ledgers. When you initially load your Financial Accounting data from your General Ledger, Financial Elements are used to distinguish between:
· Ending monthly balances (FE 100)
· Average monthly balances (FE 140)
· Interest Income or Expense (FE 420)
· Non-Interest Income (FE 455)
· Non-Interest Expense (FE 457)
The Financial Element dimension is the only seeded Key Processing Dimension that comes with its own seeded dimension member values. Seeded Financial Element values – dimension members from 0 to 10,000 – may not be modified, but they may be used as storage targets for initial load data or as output targets from allocation rules or other processes. In addition to the five Financial Elements discussed above, OFSAA comes seeded with dozens of additional Financial Elements. For the most part, these other seeded Financial Element values are used as output dimensions member values for:
· The result tables produced by OFSAA Asset/Liability Management (see the Oracle Financial Services Asset Liability Management (OFSALM) User Guide.) These Financial Elements are only rarely used within the Management Ledger table.
· Aggregated Instrument-level transfer pricing charges and credits. Such aggregations can be accomplished by using allocation rules or by using application functionality contained within the OFSAA Funds Transfer Pricing application (see the Oracle Financial Services Funds Transfer Pricing User Guide.) Seeded Financial Elements that are commonly used as targets in aggregations of FTP data are Financial Element 450 – Transfer Pricing Charge/Credit; and Financial Element 170 – Weighted Average Transfer Rate.
· Direct transfer pricing of the Ledger Class Table (see the Oracle Financial Services Funds Transfer Pricing User Guide; the same Financial Elements (170 and 450) are also used as output targets for direct transfer pricing of the Ledger Class Table).
· Storing final, ready to report, fully allocated multidimensional results. While user-defined Financial Elements may also be used for this purpose, there are a series of seeded Financial Elements that you may choose to utilize as they are pre-built to function as “reporting lines” within the Oracle Financial Services Profitability Analytics OBI application.
For a complete listing of all seeded Financial Elements, see Appendix F: Seeded Financial Elements. For examples of the usage of user-defined Financial Elements, see the sections Initial Loads to the Management Ledger and Usage Examples of User-Defined Financial Elements.
Found in your Management Ledger as well as in all of your Instrument and Transaction Summary tables, Organizational Unit is generally mapped to your General Ledger responsibility center (cost center or profit center) or department.
Additional organizational dimensions may be added as user-defined key dimensions. For example:
· In a Management Ledger implementation, you may wish your profitability implementation to record the organizational source of allocated expense balances to facilitate inbound-outbound center-to-center allocation reporting.
· When loading account level data into the OFSAA Data Model, you will normally map your Book-of-Record cost center to the Organizational Unit dimension (the value that reconciles to your General Ledger). You might also, however, wish to define a Relationship Owning Center or a Company, Line of Business, or Legal Entity dimension.
General Ledger Accounts are mapped from your source General Ledger systems. Financial Accounting systems sometimes refer to this dimension as GL Account or Natural Account.
The Common Chart of Accounts dimension is a high-order product dimension that is typically used to link budgeting definitions of product with Transfer Pricing, ALM, or Profitability Management definitions of product (see the User Guides for Funds Transfer Pricing, Asset Liability Management, and Balance Sheet Planning; also see Appendix G: Debit and Credit Conventions).
Nearly every Profitability Management implementation is interested in a Product view of profitability. Additionally, the seeded Product dimension is normally used for modeling purposes in Funds Transfer Pricing and/or in Asset Liability Management.
You may customize your data model by adding your own user-defined Key Processing Dimensions. See the section entitled “Overview of Dimensionality in OFSAA” or the Installation & Configuration Guide for details on adding your own user-defined Key Processing dimensions.
You may also add Standard Dimensions or Simple dimensions to your data model, but the OFSAA Profitability Management engine can only actively utilize Key Processing Dimensions within allocations rule sources, drivers, or outputs.
One reason for adding user-defined Key Processing Dimensions is that your institution's design calls for additional profitability dimensions such as Channel, Customer, Geography, Line of Business, or Relationship Owning Unit, Company, or Legal Entity.
Another reason you may wish to add a user-defined Key Processing Dimension is that you need an additional working dimension, i.e., a dimension along which you do not intend to fully develop Management Accounting analytics. For example, you may wish to add a user-defined Key Processing Dimension for Cost Pool, Transaction or Activity. These dimensions may be actively used within your allocation rules but are typically “in process” dimensions, i.e., dimensions used as stepping stones along the path to fully allocated profitability dimensions.
Yet another reason you may wish to add Key Processing Dimensions is that you must map all of the dimensions present in your source General Ledger to OFSAA Key Processing Dimensions. If your source General Ledger has dimensions such as Company or Legal Entity, you may need to add these dimensions to your model. If a dimension present in your source General Ledger is “organizational” in nature (i.e., Company or Legal Entity), it may be possible to concatenate such dimensions into the single OFSAA Organization Unit dimension as you design and build your ETL for loading source data for your OFSAA data model (ledger data, instrument data, or transaction summary data).
Topics:
· Financial Accounting vs. Management Accounting
· Management Accounting Models
· Management Ledger Profitability Models
· Account Level Profitability Models
General Ledger systems are designed to yield Financial Accounting results such as Balance Sheets, Income Statements, Sources & Uses Statements, and other regulatory reports that must be compiled according to international or local accounting standards such as International Financial Reporting Standards (IFRS) or Generally Accepted Accounting Principles (US). In addition to these external reporting functions, GL systems serve internal control and management accountability functions. GL systems need to be able to account for and answer questions such as:
· How much is being spent on occupancy expense?
· How much is being spent on salary and benefits expense?
· How well are we managing IT and network costs?
· Are cost center managers under- or over-budget?
· How are we accounting for cash and receivables?
· How are we accounting for depreciation, goodwill, and other intangibles?
· How are we managing cash flow (cash basis accounting vs. accrual basis accounting)?
· Can we demonstrate appropriate segregation of duties and other internal controls?
· Can we track General Ledger balances back to source transactions and documents?
· Can we satisfy our external stakeholders including auditors, regulators, and investors?
Management accounting systems are often derived in whole or in part from Financial Accounting systems, but are designed to answer a different class of questions such as:
· Which products, customers, geographies, lines of business, divisions, and channels are most profitable?
· How can we influence customer behavior to maximize profitability?
· How well are we controlling risks including interest rate risk, foreign currency risk, credit risk, fiduciary risk, legal risk, operating risk, and market risk?
· Can we measure our profitability in all dimensions on a risk-adjusted basis?
· How can we optimize our external fee structures and internal incentives to optimize risk adjusted profitability?
· Are we properly organized to optimize internal incentives?
· How well are we managing capacity?
Profitability Management models can generally be divided into two types: Management Ledger level profitability (an aggregated multi-dimensional view) and Customer Account Level profitability (a very detailed view). Management Ledger-level profitability solutions have some advantages over Account Level solutions. They are generally easier to construct and maintain, have shorter processing cycles, and results in smaller, more manageable volumes of data than Account Level profitability solutions.
The primary advantages of Account Level profitability solutions over Management Ledger-level solutions is their ability to segment profitability results using both dimensional measures and non-dimensional attributes & measures found at the account level. Such account level attributes and measures can be exploited to stratify your results; they can also be assembled into “pseudo” dimensions (low cardinality dimensions) that typically would not support hierarchies in a reporting context. Examples of ways in which you might exploit account level attributes to supplement multidimensional results would include
· New Business vs. Total Book of Business
· Repricing Profiles
· Runoff Profiles
· Ranges of Risk
· Customer Level Balance Ranges
· Age of Customer Relationship
Another important advantage of Account Level solutions is that they allow you to construct highly granular capital allocation methodologies. This is particularly valuable in developing Risk Adjusted Profitability Management (RAPM) metrics (you may, however, aggregate your bottom-up equity allocations to the Management Ledger-level).
Institutions often construct models that yield both kinds of profitability results. When both kinds of models are built, they will sometimes reconcile to one another and they will sometimes not reconcile to one another. Whether or not they reconcile is a function of the methodologies you select and your institution's preferences.
The starting point for most Management Ledger-level profitability solutions is the Financial Accounting data that you import from your General Ledger system. A number of different processes are generally performed to manipulate your initial Financial Accounting data to produce Management Accounting results.
Management Ledger-level models often involve both “top-down” and “bottom-up” kinds of processes. In the Management Ledger context, top-down processes are typically composed of series of allocation rules that operate in a cascading or “waterfall” sequence that begin with your Financial Accounting data.
For example, in constructing Organizational profitability within a Management Ledger, your design might begin with an analysis in which you subdivide all of your Organizational Units (or Responsibility Centers) into either Cost Centers or Profit Centers. Cost Center managers are responsible for managing their expenses and meeting their budgets while Profit Center managers have P & L responsibility. While your General Ledger may support independent P & L's for Divisions, Regions, Lines of Business, or Companies, your objective in a top-down Organizational Profitability solution is to push P & L responsibility down to much lower levels: branches, loan origination centers, etc.
You might continue your analysis by organizing your Cost Centers into functional groups such as Overhead, Indirect Support, and Direct Support. You might then devise a series of allocation rules that allocate Indirect Support expenses to Direct Support cost centers which in turn allocate their (burdened) expenses to Profit Centers. You might finish by allocating Overhead expenses directly to Profit Centers. In some cases, you might also need to allocate some non-interest revenues. Since interest income and interest expense are typically booked to Profit Centers within your General Ledger, it is less likely that you will need to allocate these balances.
You also might wish to build some balance sheet allocations to move non-financial assets & liabilities (such as cash, fixed assets, goodwill, and equity) to the Profit Centers that rely upon those non-financial assets & liabilities to support their businesses. The rationale here is that you generally want to transfer price the entire balance sheet, not just instrument-level balances. As with your instrument balances, these non-financial balances will generate transfer pricing charges & credits and these secondary transfer pricing charges & credits need to be assigned to the proper Profit Centers.
Frequently, Management Ledger implementations focus on both Organizational Profitability and Product Profitability. Typically, these kinds of implementation will first complete the Organizational Profitability component and then continue with additional allocation rules to develop Product Profitability. Product Profitability is normally developed using both top-down and bottom-up methods.
The above narrative is meant to be illustrative; there are an enormous variety of methodologies you might choose from in constructing Management Ledger-level models for Organizational Profitability, Product Profitability, or multi-dimensional profitability incorporating additional dimensions.
As mentioned above, Management Ledger-level models typically involve both “top-down” and “bottom-up” kinds of processes. One kind of bottom-up process is matched term funds transfer pricing. In matched term funds transfer pricing, every instrument asset record is assigned a “cost of funds used” and every instrument liability record is assigned a “credit for funds provided”. These instrument level charges and credits (expenses and revenues) are subsequently aggregated to the Management Ledger. In implementations where activity based costs (and sometimes revenues) are assigned to each instrument level record, these charges and credits may also be aggregated to the Management Ledger-level.
As with Management Ledger-level solutions, Account Level solutions are also frequently constructed using a combination of top-down and bottom-up processes. For example, you might employ top-down allocations to distribute Management Ledger-level income and expenses (expenses being more typical) to the instrument level; and you might employ bottom-up processes such as account level funds transfer pricing and/or allocation rules that employ unit costs and volumes to assign income and expenses (again, expenses being more typical) to instrument level records (note that such low-level, bottom-up income and expense assignments may also be aggregated to the Management Ledger).
When you initially load the Management Ledger with data extracted from your General Ledger, you need to map each row of extracted data to a Financial Element. Similarly, if or when you load other externally sourced data into the Management Ledger table (i.e., statistical data not extracted from your General Ledger), you must also map each row of your extracted data to a Financial Element.
The recommended Financial Elements for General Ledger data or for externally sourced statistical data is as follows:
· Ending Balances – Financial Element 100
· Average Balances – Financial Element 140
· Interest Income & Expense Balances – Financial Element 420
· Non-Interest Income Balances – Financial Element 455
· Non-Interest Expense Balances – Financial Element 457
· Statistical data – Financial Element 10,000
Topics:
· Usage Examples of User-Defined Financial Elements
· Using Financial Elements as Income Statement Reporting Lines
· Reporting Lines for Selected Balance-Sheet Balances
You may, of course, create additional user-defined Financial Elements for use in storing:
· Additional statistics that you source from an external system
· Driver statistics that are built up through allocation rule processes and that you intend to use in subsequent allocation rules
· Allocation rule outputs if, for example, you are building up cost pools or other intermediate balances that represent “in process” balances that are not yet fully allocated to final multidimensional results
· Final, fully allocated balances that you wish to report on (i.e., you may use a range of user-defined Financial Elements to build up a “reporting line” structure for fully allocated multidimensional profitability results)
You may wish to build up fully allocated, multidimensional profitability balances that represent reporting lines in your final analytical results. For example, if you wish to construct income statements by Organizational Unit and by Product and by Geography, you might choose to construct allocation rules that will drive towards final result balances by Organization Unit, by Product, by Geography, and by Financial Element where Financial Elements are used to store reporting line balances for:
· Interest Income / Interest Expense
· Charge for Funds Used / Credit for Funds Provided
· Fee Income
· Direct Expense
· Indirect Acquisition Expense
· Indirect Servicing Expense
· Direct & Indirect Taxes
Under this approach, Financial Elements that serve as “Reporting Lines” in your Management Accounting income statements take the place of the General Ledger Account dimension that serves the “reporting line” function in pre-allocated Financial Accounting income statement data extracted from your General Ledger. Whereas your Financial Accounting income statements may be very detailed and may be comprised of hundreds or even thousands of GL Accounts, your Management Accounting income statement reporting line structure will likely have far fewer rows, probably 30-60 lines.
A seeded set of Financial Elements that you may wish to use as reporting lines are included in the standard data model (the complete list of all seeded Financial Elements is documented in Appendix F: Seeded Financial Elements).
A seeded Financial Element hierarchy is also provided that contains rollup points for the seeded “reporting line” Financial Elements. These rollup points, which include values such as Total Interest Income, Total Interest Expense, Net Interest Income, Risk Adjusted Net Interest Income, and Risk Adjusted Net Income, are structured to function as subtotals. The seeded “reporting line” Financial Elements (leaf member values plus rollup point values) are pre-built in to the Oracle Financial Services Performance Analytics (OFSPA) Business Intelligence (BI) application. If you choose to develop a strategy that involves allocating balances to Financial Elements that are intended to support such a “reporting line” structure, you may customize the seeded profitability Financial Element structure by (1), adding your own user-defined Financial Elements and (2), modifying the seeded Financial Element hierarchy. After having customized the seeded profitability Financial Elements and the related subtotaling hierarchy, the changes can be made to flow seamlessly into the analytical dashboards within the OFSPA BI application without any additional customization.
You may, of course, choose not to develop a “reporting line” strategy for developing multidimensional profitability; or you might choose to build out reporting lines under another user-defined Key Processing Dimension.
Regardless of what dimension you choose for storing “reporting line” balances within your Management Ledger (assuming that you do adopt such a strategy), your final “reporting line” balances may be the result of bottom up processes such as:
· Aggregation of Transfer Pricing charges and credits from the instrument level. Such FTP charges and credits may result from charges or credits for principal balances, charges or credits for basis risk or liquidity risk, or charges or credits for secondary balances that you have allocated to instruments (such secondary balances are typically allocated from the Management Ledger to the instrument level; examples would include loan loss reserves, risk equity, central bank reserves; or other allocated debit or credit balances such as plant & equipment, cash & due from banks, goodwill, prepaid expenses, etc.) The charges & credits associated with these allocated balance-sheet balances may be generated using the transfer pricing rates that have already been assigned to each instrument's principal balance; or you may adopt a simple methodology for ascribing transfer rates to these allocated balances (e.g., pre-determined rates that are assigned to each allocated balance as a function of its perceived duration).
· Aggregation of rate times volume results from the Instrument and/or Transaction Summary levels for activity based expenses or revenues
· Aggregation of instrument level revenues or expenses that are derived directly from your source systems (e.g. Accrued Interest Payable or Receivables, Fee income, etc.)
Or they may be the result of top-down processes such as
· Non-interest expense balances (typically in the form of center-to-center or center-to-product allocations)
· Direct Transfer Pricing of Ledger balances (such direct transfer pricing charges and credits may be generated within the Management Ledger using OFSAA Funds Transfer Pricing; OFSAA FTP posts such results to Financial Element 450). For details on direct transfer pricing of ledger balances, see the OFSAA Funds Transfer Pricing User Guide.
You may also wish to build up “reporting line” Financial Elements for selected balance-sheet balances. Although you will not always be able to demonstrate a balanced balance-sheet (for example, it is not meaningful to construct a balanced balance-sheet for a Product line or for a Line of Business), if you build out selected balances, those balances could be used in ratio analysis either within the OFS Profitability Analytics OBI application or within your own reporting tool. The OFS Profitability Analytics OBI application includes predefined cube definitions that generate ratios and formulas that use such balance-sheet balance reporting lines (e.g., for risk adjusted profitability ratios such as return on assets, risk adjusted return on equity, net income after capital charge, etc.)