Financial Services Industry Applications This section discusses:
Financial Services Industry applications.
Integration with Enterprise Performance Management Warehouses.
Common Enterprise Performance Management Warehouse metadata and functions.
Common financial services industry concepts.
Financial Services Industry Applications The financial services industry environment is a collection of rules that support the valuation of the financial services industry balance sheet and off-balance sheet items; they measure the sensitivity of those values under alternative economic and operating assumptions. Many of these rules define financial application behavior and their attributes; for example, term to maturity, accrual basis, compounding frequencies, and so on. Other rules define interest rate environments, customer behavioral models, service fee models, and so on.
Here are the rules and processes that create the financial services industry environment:
Financial calculation rules.
Establishes how the PeopleSoft Enterprise Financial Services Industry applications calculate specific financial measures or application results for each instrument pool. This may include processing rules for stratification, behavioral models, application pricing, forecasting, funds transfer pricing, and risk-weighted capital. This is the core functionality of the PeopleSoft Enterprise Financial Services Industry system.
Product definitions.
Specifies many of the cash flow characteristics of financial instruments. Some attributes include type of balance, term, interest calculations, payment frequency, and dates. PeopleSoft Enterprise Financial Services Industry applications use product definitions for processing.
Service fees modeling.
Models non-interest revenues and expenses in earnings simulations.
Behavioral modeling.
Models the interest rate sensitivity of customers with respect to loan prepayment, loan charge-off, deposit growth and runoff, and rate lock options.
Cash flow modeling.
Models cash flows for an instrument or application. You can graph and view the results online, as well as write the results to the database. You can interactively explore assumptions affecting cash flows, such as the rate environment, terms, and payment characteristics of the instrument, and the effects of the behavioral model.
Pricing indices definition.
Defines indices underlying the market-based interest rates that are representative of bank management's pricing strategy for loans and deposits. Pricing indices are one of the core-supporting components of PeopleSoft Enterprise Financial Services Industry applications. Indices are used for multiple purposes, such as repricing and behavioral modeling. There are two parts to using pricing indices in PeopleSoft Enterprise Financial Services Industry: pricing and repricing instruments and products, and providing benchmark rates to the behavioral models.
Product ratings definition.
Creates customized product attributes to calculate risk capital or expected losses at a product-specific level.
Calculates settings that go into effect for certain products when the payment does not cover the interest on the loan and the amount of the loan (principle) is increasing over time.
Seasonality groups.
Define cyclical patterns that may be factored into the interest rate behavior models or application forecasts.
Model definitions.
Define various runtime parameters on a model-ID level. Such parameters are product, balance sheet, and income statement trees. By using different trees, you can run applications on different sets of data. Other parameters that are set on the model ID level are cash flow settings, error log settings, and engine-specific settings for PeopleSoft Enterprise Funds Transfer Pricing and PeopleSoft Enterprise Risk-Weighted Capital.
Yield curve generation.
Creates curves based on generic or market data, using rules for defining source data, and flexible interpolations for determining rates between data points. Curves may be built exclusively from market data (that is, Treasury, LIBOR, and so on). or may be the result of a mathematical operation. An evaluator component provides discount factors, spot rates, and forward rates.
Stratification.
Aggregates the volume of financial instruments (individual instances of an application) to a manageable scale for processing purposes.
Balance sheet and income statement rules.
Specify the application tree nodes and account nodes for the balances that PeopleSoft Enterprise Financial Services Industry applications process. These rules define how to reconcile the instrument balances and position balances to the ledger account balances.
Reconciliation rules.
Enable you to reconcile a variety of instrument balances to the ledger.
Integration with Enterprise Performance Management Warehouses PeopleSoft Enterprise Financial Services Industry analytic applications (PeopleSoft Enterprise Risk-Weighted Capital and PeopleSoft Enterprise Funds Transfer Pricing) draw data from the Enterprise Performance Management (EPM) Warehouse for their processing and post results back to the EPM Warehouse tables for reporting. After loading the data from a source system, the EPM Warehouse validates, enriches, stores, and moves the data for multidimensional reporting and analysis.
This section discusses:
Performance ledger, products, and instruments.
Performance ledger versus average daily balance ledger.
Instrument table population.
Performance Ledger, Products, and Instruments The analytic applications can process data at either a summary level, using performance (PF) ledger data, or at a detail level, using instrument or treasury position data. The primary table for PF ledger balances is PF_LEDGER_ F00, containing data that originates from the general ledger. PF ledger balances are typically current, end-of-period balances, that are used for management profitability reporting, as opposed to GAAP reporting. You can think of the relationship between the PF ledger, product definitions, and instrument balances, as a type of hierarchy. The PF ledger is the highest level in the tree hierarchy. Many of the PF ledger accounts consist of application balances that roll up to the balance sheet accounts in the PF Ledger table, and the products are made up of individual instrument balances.
Use the financial product definition pages to define the characteristics and processing rules used by the financial analytic applications for all of the instruments you define. The product definitions specify the types of financial products that the institution sells or carries in its portfolio, for example, mortgages, auto loans, foreign exchange contracts. The instruments are the specific financial obligations, contracts, and accounts. A product or application defines the attributes of a generic instrument, specifically its behavior in terms of cash flow. An instrument is a specific instance of a product. The instrument records are the institution's specific individual financial obligations, and one of the key defining attributes on the instrument record is its product ID. In terms of the bank's balance sheet, the product or instrument can be an asset (loans, lines of credit), or a liability (checking accounts, certificates of deposit), or an off-balance sheet item (derivative contracts, foreign exchange contracts).
In some cases, it makes sense to define analytic application rules and process them at the PF ledger account level. Several types of balance sheet accounts are not application-specific, for example, fixed assets, cash, accounts receivable, and accounts payable. However, these account balances can still represent a significant source or use of funds and should have an internal funding credit or charge allocated to them. For most product specific balances, analyze and report at the product or instrument detail, where individual attributes (such as credit risk), or cash flow characteristics (such as loan prepayments) require individual treatment.
To minimize processing time and enhance efficiency, instruments can be aggregated into instrument pools by the Stratification application engine, using criteria and stratification rules that you define. The instrument pool is viewed and treated like a synthetic instrument and can be used by the cash flow generator as a proxy for all of the instruments that were aggregated into the instrument pool.
Performance Ledger versus Average Daily Balance Ledger
The PF Ledger table stores current end-of-period balances. The Average Daily Balance (ADB) Ledger table (PF_LED_ADB_F00) stores average daily balances. You may prefer to use average daily balances for such calculations as monthly funds transfer charges or risk-weighted capital allocations for accounts whose balances fluctuate throughout the month (for example, cash and credit cards). PeopleSoft Enterprise Financial Services Industry analytic applications enable you to choose either PF ledger or ADB ledger type balances for your processing.
Note. PF ledger is the master table that stores all account balances, and it is the sole basis for selection of rows (balances) for processing. Once a balance sheet rule processes an account, it does not process it again. The reason for this is to prevent any possibility of double-counting a balance that may be included in more than one basis ID. Likewise, a balance sheet rule can process a ledger row as either an ADB or a PF ledger type of balance, but never both.
Instrument Table Population You load the data warehouse tables with financial instrument details from the source systems. The instrument details are stored in the FI_INSTR_F00 table. Because a product defines a type of instrument in generic terms, the product definitions (or templates) may be used as default values for instrument details in the FI_INSTR_F00 table. This may be done in cases where the source data are not available or when the analysis at hand does not warrant the loading of individual instrument details. In such cases, generic product descriptions may be sufficient. If you use product templates to populate the FI_INSTR_F00 table, the following data must be provided at a minimum from the source system:
Instrument ID.
Initial and current balances of the instrument.
Start and end dates.
Customer ID.
Product ID.
current interest rate.
Note. If you want to do instrument level profitability reporting from the performance ledger, make sure that you use only 18 characters to uniquely identify each instrument ID. Use only 18 of the available 20 characters in FI_INSTRUMENT_ID. The reason is that when you run the PF_EDIT program prior to posting data to PF_LEDGER, it checks that each of these instrument IDs appears in the PF_OBJ_TBL, which can only handle field sizes up to 18 characters.
See Understanding Common PeopleSoft Financial Services Industry Processes.
Common Enterprise Performance Management Warehouse Metadata and Functions PeopleSoft Enterprise Financial Services Industry applications commonly use metadata and functions from the EPM Warehouse. Brief definitions of this metadata and functions are as follows:
|
Enable replication of an organization's business processes for analysis of cost flow through customers, departments, and channels. |
|
|
Point to a model ID and define the business rules, economic assumptions, and chunking selection for processing. |
|
|
Define the physical relationships between data warehouse tables and are the foundation for datamaps. |
|
|
Enable you to define a logical view of the physical EPM Warehouse tables by bringing together information from the different tables specified in a tablemap and defining them as if they were one entity or table. |
|
|
Enable you to define what subset of data gets processed by or uses a specific business rule. Not every row of data may be necessary to process your data. Filters enable you to select only those rows that you want. |
|
|
Enable you to define business rules for processing and also let you create and reuse filters. Filters are a base for building constraints, and constraints are based on datamaps. |
|
|
Provide a user defined set of information for various engines restricting the columns used and returned rows using constraints. |
|
|
Enable you to define functions one time through a common interface, then use them throughout many of the analytic applications. For example, PeopleSoft Enterprise Risk-Weighted Capital uses them to build risk functions and the yield curve environment uses them to build pricing index functions. |
See Also
Financial Services Industry Implementation
Common Financial Services Industry ConceptsHere are some common concepts for PeopleSoft Enterprise Financial Services Industry applications:
Historic and Forecasted Scenarios
As a general guideline, when you process historic scenarios, you use instrument-level data, whereas when you process forecasted scenarios, you use product-level data. There are, however, exceptions to this guideline. PeopleSoft gives you the flexibility, through the Attributes Options field on the Model Definition page, to determine whether processes access product or instrument-level data. The system stores instrument-level data in the FI_INSTR_F00 table and its child tables. The system stores product-level data in the FI_PRODUCT_TBL table and its child table FI_PRODUCT_SEQ.
PeopleSoft Enterprise Financial Services Industry applications, features, or both, may need you to define an accrual basis. The accrual basis measures the number of days between two dates (start date and end date) and the number of years (or portions thereof) between two dates. The system counts the days between the start date and the end date, and then divides this number by the appropriate divisor, depending on the accrual method that you select. Each of the start dates and the end dates has a specified year, month, and day.
Your choices are:
30/360
30N/360
30E/360
Actual/Actual
Actual/360
Actual/365
These procedures explain how the accrual basis is determined for each of these options.
30/360
If the start date falls on the 31st of the month, then treat it as the 30th of the month.
If the end date falls on the 31st of the month, and the start date is the 30th of the month, then treat the end date as the 30th of the month.
Multiply 360 times the difference between the years of the start date and end date.
Multiply 30 times the difference between the months of the end date and the start date.
Count the days between the end date and the start date.
Add the results of steps 3, 4, and 5 above.
Divide the sum by 360.
30N/360
If the end date falls on the last day of February, then treat the end date as the 30th of the month.
If the start date falls on the last day of February, then treat the start date as the 30th of the month.
All of the rules for 30/360 apply (steps 3 to 7 above).
30E/360
If the end date falls on the 31st of the month, then treat it as the 30th of the month.
If the start date falls on the 31st of the month, then treat it as the 30th of the month.
Multiply 360 times the difference between the years of the end date and the start date.
Multiply 30 times the difference between the months of the end date and the start date.
Count the days between the end date and the start date.
Add the results of steps 3, 4, and 5 above.
Divide the sum by 360.
Actual/Actual
Count the days between the start date and the end date, dividing them into two segments: number of days that fall in a leap year, and number of days that fall in a non-leap year.
Divide the number of days in the non-leap year by 365.
Divide the number of days in the leap year by 366.
Add the ratios in steps 2 and 3 above.
Actual/360
Count the days between the start date and the end date.
Divide by 360.
Actual/365
Count the days between the start date and the end date.
Divide by 365.