User defined behavior patterns allow you to define principal amortization schedules and replicating portfolio characteristics for non-maturity products in your portfolio. You can utilize a behavior pattern while generating cash flows (for use in ALM and Liquidity Risk Management) by entering the behavior pattern code as the amortization type code (AMRT_TYPE_CD) for the relevant instrument records. In Funds Transfer Pricing, for certain TP Methods, you can select a Behavior Pattern to support your Transfer Pricing assumptions.
In many cases, particularly for ALM processing, the "non-maturity" instruments will be aggregated or summarized balances.
The Behavior Pattern codes can range from 70000 to 99999.
Depending on the Transfer Pricing method, the Behavior Pattern mapped to the individual instrument records (amrt_type_cd), may or may not be used. For cash flow TP methods, the engine will read the Behavior Pattern from the instrument record. For Tractor, Caterpillar and Weighted Average Perpetual methods, the Behavior Pattern is assigned directly within the TP Rule at a Product / Currency level and hence, the TP engine will not refer to the Behavior Pattern assigned to the individual instrument records for these methods.
The procedure for working with and managing Behavior Patterns is similar to that of other Oracle Funds Transfer Pricing assumption rules. It includes the following steps:
· Searching for Behavior Pattern
· Creating Behavior Pattern
· Viewing and Editing Behavior Patterns
· Copying Behavior Patterns
· Deleting Behavior Patterns
Search for a behavior pattern to perform any of the following tasks:
· View
· Edit
· Copy
· Delete
· Check Dependencies
Prerequisites
Predefined behavior patterns
Figure 1: Behavior Patterns Summary page
To search for the predefined behavior patterns, do the following:
1. From the LHS menu, select Funds Transfer Pricing, select FTP Maintenance, select Patterns, and then select Behavior Patterns to open the Behavior Pattern summary page. This page is the gateway to all behavior patterns and related functionality. You can navigate to other pages relating to behavior patterns from this page.
2. Enter the Search criteria.
3. Enter the code or name of the Pattern.
4. Click the Search icon.
Only patterns that match the search criteria are displayed.
|
NOTE |
You can control the number of rows to display on screen by selecting the "Pagination Options" icon from the action bar. |
You create behavior patterns to capture the principal run-off behavior of product types that do not have contractual maturities.
To create a behavior pattern, do the following:
1. Navigate to the Behavior Pattern summary page.
2. Click the Add icon to display the Behavior Pattern details page.
Figure 2: Behavior Pattern Definition page
3. Enter a Code for the new behavior pattern.
|
NOTE |
The code, also known as an amortization type code, is a numeric identifier for the behavior pattern. The code value must be a number between 70000 and 99999. The code value you assign to the new pattern must be unique. In addition, the code must be mapped to the appropriate instrument records, (AMRT_TYPE_CD field) to connect the instrument to the appropriate pattern. |
4. Enter the Name and a Description for the pattern.
5. Select the Behavior Pattern Type from the following options:
§ Non Maturity
§ Non Performing
§ Devolvement and Recovery.
|
NOTE |
The Replicating Portfolio option is enabled only for the Non Maturity Behavior Pattern. This option should be selected only when defining a Behavior Pattern for use in Funds Transfer Pricing – Tractor TP Method. Replicating Portfolio Behavior Pattern codes should not be mapped to instrument records (amrt_type_cd) and will not be available for selection in any UI other than Tractor TP Method. |
6. Define the Behavior Pattern Term Specifications for maturity tranches.
7. The selection of the Behavior Pattern type made in the previous step determines the information you must provide to successfully define that pattern type. See:
§ Defining Non-Maturity Behavior Patterns (for non-Tractor TP Method use)
§ Defining Non-Maturity Behavior Patterns (for Tractor TP Method use)
§ Defining Non-Performing Behavior Patterns
|
NOTE |
The Behavior Pattern details page above, displays the specifications associated with the Non Maturity Pattern Type. Should you change this value for one of the other two alternatives, Non Performing or Devolvement and Recovery, the system will refresh the payment specifications section corresponding to the new Pattern Type. Although you can change your selection of the Pattern Type at any point in this procedure, sometimes this might result in loss of data related to any prior selection. |
Non Maturity behavior patterns are commonly used for deposit products like checking, savings and money market accounts as well as for credit card accounts. These account types are similar in that they do not have contractual cash flows because customers have the option to deposit or withdraw any amount at any time (up to any established limits).
When working with non maturity behavior patterns, your percentage weights, assigned to maturity terms must add up to 100%.
To define a non-maturity behavior pattern for non-Tractor TP method, follow these steps:
1. In the Behavior Pattern details page, select Non Maturity as the Behavior Pattern Type.
2. Enter/select the following details:
§ Tenor: Used to specify the maturity term for the particular row. For example, if “1 Day” is defined, then the applicable percentage of the balance will runoff (mature) on the As of Date + 1 Day.
§ Multiplier: The unit of time applied to the Tenor. The choices are:
— Days
— Months
— Years
§ Percentage: The outstanding balance indicating how much of the outstanding balance will mature on the specified term.
§ Allocation Input Type: This field allows you to select the Amount or Percentage when defining the volume for each maturity tier.
§ Type: Allows you to classify the runoff based on the appropriate type. If you select Percentage under 'Allocation Input Type', this allows you to select Core or Volatile. When Amount 'Allocation Input Type' is selected, only Core amounts are allowed to be entered. The TP engine calculates the Volatile amount internally based on the sum of the portfolio balance less the sum of the core amounts. i.e. 100% of the portfolio balance is accounted for as either core or volatile.
|
NOTE |
There is no difference in behavior from a cash flow perspective, but the runoff amount will be written to a principal runoff financial element corresponding to the selected Runoff Type. |
3. Click the Add icon to add additional payment strips to the Pattern. After defining the initial strip as Volatile, subsequent strips are typically classified as Core with varying maturity terms assigned.
4. To delete a row, select the check box corresponding to the row you want to remove and click the Delete icon.
5. Click Save.
The Behavior Pattern is saved and the Behavior Pattern summary page is displayed.
The Tractor Transfer Pricing Method, utilizes a replicating portfolio concept. Replicating Portfolio's are a special type of Non-Maturity Behavior Pattern and are created and managed through the Non-Maturity Behavior Pattern UI.
Through the replicating portfolio UI, users can define one or more core balance amounts. Users assign a term to each core and generate balance strips at any granularity (for example, typically daily or monthly, depending on the frequency of the transfer pricing process). To maintain the portfolio over time, users must roll and re-balance the portfolio to update the volatile plug amount and if needed re-balance the core amount.
To define a non-maturity behavior pattern for Tractor TP method use, follow these steps:
1. In the Behavior Pattern details page, select Non Maturity as the Behavior Pattern Type.
2. Enter/select the following details:
This table describes key terms used for this procedure.
|
Term |
Description |
|---|---|
|
Core Allocation Input |
This drop-down is a mandatory selection. The drop-down values are Amount and Percentage. |
|
Core Allocation |
The amount that is apportioned to each core. The Allocation amount in absolute or percentage for each strip is automatically determined (when Strip Tenor is "Days", or "Months") by evenly spreading the defined Core Amount across the number of strips for the portfolio. When Strip Tenor is "At Maturity", the entire amount is placed at the maximum term, determined by the inputs for "Term " and "Multiplier". If the user selects 'Amount' in the Core Allocation Input drop-down , then the 'Core Allocation' text box accepts values from 0.0000 to 9,999,999,999.9999. If the user selects 'Percentage' in the Core Allocation Input drop-down , then the 'Core Allocation' text box accepts only a percentage value between 0.0000 and 100.0000. |
|
Tenor |
Used to specify the maturity term for the portfolio. This term defines the maximum term for the initial strip balance and the rollover term for each rollover strip. When you manually select or schedule the replicating portfolio process, the Org term of the volatile strip is calculated. Replicating Portfolio generates the volatile strips that sets the ORG_TERM equal to the Period between Maturity date and Origination date. |
|
Multiplier |
The unit of time applied to the Tenor. The choices are: · Days · Months · Years |
|
Type |
For replicating portfolio, type is defaulted to core. The Volatile strip is generated automatically as a reconciling plug entry to balance the portfolio. The term of the plug entry is defaulted to 1 Day, unless a holiday calendar is used, in which case the volatile amount maturity can be extended to the next business day. |
|
Strip Tenor |
Indicates the frequency of the strips generated for the portfolio. Available options are "Days", "Months" or "At Maturity". For example, if "Days" is selected, strips will be generated for each day from the as-of-date to the maturity term. If "At Maturity" is selected, a single strip will be generated and the balance will be placed at the maturity term. |
|
Source Balance Selection |
The source balance selection allows the user to define the source Instrument Table (or Ledger Table) and product / currency against which the core balance will be reconciled. The difference between the core balance and the actual instrument balance will determine the amount of the Volatile Plug strip for the current period. |
|
Balance Type |
The Balance type allows you to select the type of the Balance. It can be either Average Balance or Ending Balance. This option will be enable if the Source Balance is selected as "Management Ledger". |
|
Enable Holiday Calendar |
Replicating Portfolio's allow users to enable a holiday calendar. If this option is selected, portfolio strips will not be generated on weekends or holidays. In addition, during rollover of maturing strips new maturity dates will be adjusted to ensure maturities fall only on working days. |
|
Holiday Calendar Code |
The holiday calendar code allows users to select the applicable holiday calendar. |
|
Holiday Calendar Rolling Convention |
The rolling convention within replicating portfolios is defaulted to next business day. Related to this method is an additional date adjustment to ensure that only one core strip falls on a single date. We refer to this secondary adjustment as an exclusive business day convention. |
|
Default Portfolio Roll Frequency |
The default portfolio roll frequency option allows you to set default rolling frequency of replicating portfolio. |
|
Merge Delta Strips on Re-balancing |
If Merge Delta Strips on Re-balancing option is enabled, then the core strips will be merged during the rebalancing. |
|
Generate the Portfolio |
After initially creating (and saving) the replicating portfolio definition, users should Generate the Portfolio. This action launches a background process which generates the strip records for the portfolio. Prior to running this process be mindful of the As-of-date defined in your Application Preferences, as this date will be used as the initial Origination Date for the newly created strips. If % is selected as the Core Allocation Input type, the procedure will read the current period balance (CUR_BOOK_BAL or Ending Balance), for the selected “Product Member” (from Source Balance selection) and determine the Required Core Amount based on the resulting Balance x Core %. This applies to both Management Ledger (Ending Balance) and Instrument table (CUR_BOOK_BAL). |
|
Roll the Portfolio |
Each period (day or month), users will need to roll the portfolio forward. The new as-of-date for the portfolio will be determined based on the existing as-of-date plus the default roll frequency. As a general rule, users should update their as-of-date in application preferences prior to running the Roll Portfolio Process. |
|
Re-balance the Portfolio |
After rolling the portfolio, users will need to re-balance the portfolio. There are two options provided for re-balancing: · Plug to Volatile Strip: This option should be selected when no changes to the core allocation have been made. This process will compare the current period source balance with the current portfolio strip balance. The difference will be posted to the new volatile strip. The “Plug to Volatile Strip” Re-balance method will not be relevant when the Core input type is % as the portfolio balance will change with every new as-of-date and new balancing/delta strips will be required to re-balance the portfolio. · Rebalance Core Strips: This option should be selected only when users have modified the Core Allocation or when the Core input type is %. If the Core Allocation has increased or decreased, balancing strips will be generated for each tenor to bring the core strip balance back in line with the Core Allocation Balance. This process will additionally run the Plug to Volatile process to create the plug strip. |
|
View the Portfolio |
This option allows you to view the portfolio strips. |
This table describes various fields in the Behavior Pattern Details page. You can enter or select the relevant details to populate the screen to define the Non-maturity Behavior Patterns for the Tractor TP Method use.
3. Make your required selections in the Source Balance Selection section.
4. Click Add Core (one or more) to input the core amount, associated maturity term and strip frequency.
5. To delete a row, select the check box corresponding to the row you want to remove and click the Delete icon.
6. Click Save.
Figure 3: Behavior Pattern Summary page
The Behavior Pattern is saved and the Behavior Pattern summary page is displayed.
7. Return to the Behavior Pattern / Replicating Portfolio in EDIT mode and execute the portfolio maintenance activities, including:
§ Generate Portfolio
§ Roll Portfolio
§ Rebalance Portfolio
§ View Portfolio
|
NOTE |
Once the Replicating Portfolio is generated and the volatile plug has been updated for the current period, it is ready for processing by the FTP Engine. FTP Processes utilizing the Tractor TP Method should not be run until all Replicating Portfolio's have been updated. |
There is an option through the Replicating Portfolio > View Portfolio UI to manually edit existing portfolio strips through Export and Import of the active Strip Data. The following screen shot illustrates the functionality:
Figure 4: Replicating Portfolio Viewing page with collapsed Excel options
· The Export option works against the entire active portfolio. For example, a user can currently filter on a specific CORE # or look at results for all Core's. Additionally, the selection of Strips can span multiple pages, for example - as seen in the preceding screen shot, 1-20 of 71. In this example, all 71 active strips are exported to Excel.
· The import function will replace ALL existing “Active” strips.
· The strip data being imported is validated to confirm that all required data is included. If the data is not complete, for example, it does not provide information for Core #, Strip Type, As of Date, Maturity Date, Tenor, Multiplier, Allocation (or Amount), then a warning message is given indicating that “The selected data is incomplete and cannot be imported. Please re-check the data and try again.” The portfolio can also be edited directly on the view portfolio screen after new strips have been imported.
· When you click Strip Source option, the status column in the summary table shows the tagged strip records that have been created by system or manually. You can edit these tags for strips that are manually created or existing strips after exporting them into Excel.
Figure 5: Exported Data in Excel
In addition to using the “Roll Portfolio” and “Re-balance Portfolio” button options in the Replicating Portfolio UI or the “Merge Portfolio” option, users have the ability to batch and schedule these functions through a Simplified Batch or ICC Batch process.
There are three seeded tasks listed under the Transform Data task type for scheduling these actions:
· Roll_Portfolio
· Rebalance_Portfolio
· Merge_Portfolio
To open the Simplified Batch process screen, from the LHS menu, select Common Object Maintenance, select Operations, and then select Simplified Batch to open the Simplified Batch process page. This page is the gateway for defining the batch processes for behavior pattern batch process and related functionality.
The following screen shot illustrates these tasks selected within a Simplified Batch process.
Figure 6: Simplified Batch process screen
The following parameters are required for each task:
Roll Portfolio
· Run ID: when running via ICC batch and Simplified batch process, this parameter can be passed as ''
· Process ID: when running via ICC batch and Simplified batch process, this parameter can be passed as ''
· Execution ID: when running via ICC batch and Simplified batch process, this parameter can be passed as ''
· Run Surrogate Key: when running via ICC batch and Simplified batch process, this parameter can be passed as ''
· Pattern Code: for example, '70001'
· Application ID: for example, 'TP' (this is a static value)
· FTP User: for example, 'TP USER 1'
These parameters would appear as follows in the simplified batch parameter input block:
'','','','','70001','TP','TP USER 1'
When executing from the Run Rule Framework, the user does not have to pass the Run ID, Process ID, Execution ID, and Run Surrogate Key, as the framework itself passes these values along with the Batch ID and MISDATE. The parameters would appear as follows:
"70001","TP","TP USER 1"
Re-balance Portfolio
· Run ID: when running via ICC batch and Simplified batch process, this parameter can be passed as ''
· Process ID: when running via ICC batch and Simplified batch process, this parameter can be passed as ''
· Execution ID: when running via ICC batch and Simplified batch process, this parameter can be passed as ''
· Run Surrogate Key: when running via ICC batch and Simplified batch process, this parameter can be passed as ''
· Pattern Code: for example, '70001'
· Re-balance type: for example, '1' (plug to volatile) or '2' (rebalance core strips)
· FTP User: for example, 'TP USER 1'
· Application ID: for example, 'TP' (this is a static value)
These parameters would appear as follows in the simplified batch parameter input block:
'','','','', '70001', '1', 'TP USER 1', 'TP'
When executing from the Run Rule Framework, the user does not have to pass the Run ID, Process ID, Execution ID, and Run Surrogate Key, as the framework itself passes these values along with the Batch ID and MISDATE. The parameters would appear as follows:
"70001","1","TP USER 1","TP"
Merge Portfolio
· Run ID: when running via ICC batch and Simplified batch process, this parameter can be passed as ''
· Process ID: when running via ICC batch and Simplified batch process, this parameter can be passed as ''
· Execution ID: when running via ICC batch and Simplified batch process, this parameter can be passed as ''
· Run Surrogate Key: when running via ICC batch and Simplified batch process, this parameter can be passed as ''
· Pattern Code: for example, '70001'
· FTP User: for example, 'TP USER 1'
· Application ID: for example, 'TP' (this is a static value)
When to merge (roll versus rebalance): when running via ICC batch and Simplified batch process, this parameter should always be 'N'
Maturity date identifying maturing strips to be merged on roll : when running via ICC batch and Simplified batch process, this parameter should always be ''
These parameters would appear as follows in the simplified batch parameter input block:
'','','','','70001', 'TP USER 1', 'TP', 'N', ''
When executing from the Run Rule Framework, the user does not have to pass the Run ID, Process ID, Execution ID, and Run Surrogate Key, as the framework itself passes these values along with the Batch ID and MISDATE. The parameters would appear as follows:
"70001","TP USER 1","TP","N",""
Non Performing behavior patterns are commonly used for balances that are classified as non-earning assets. These balances are typically sourced from the management ledger as aggregate balances. Users are able to assign expected maturity profiles to these balances classifying them into appropriate categories of Sub Standard, Doubtful or Loss.
To define the non-performing behavior patters, follow these steps:
1. In the Behavior Pattern details page, select Non Performing as the Behavior Pattern Type.
2. Enter the Code, Name, and Description for the Behavior Pattern.
3. Click the Add icon to open the Non Performing Behavior Patterns summary page.
Figure 7: Behavior Pattern with Type as Non-Performing
4. Enter/select the following details:
§ Tenor: Specify the maturity tenor for the first maturity strip. For example, if “1 Day” is defined, then the applicable percentage of the balance will runoff (mature) on the As of Date + 1 Day.
§ Multiplier: The unit of time applied to the Tenor. The choices are:
— Days
— Months
— Years
§ Percentage: The relative amount of the principal balance that will mature on the date specified by the Tenor + Multiplier. The percentage amounts can exceed 100% for non performing patterns.
§ Runoff Type: Allows you to classify the runoff based on the appropriate type. The options are:
— Substandard
— Doubtful
— Loss
|
NOTE |
There is no difference in behavior from a cash flow perspective, but the runoff amount will be written to a principal runoff financial element corresponding to the selected Runoff Type. |
5. Click the Add icon to add additional payment strips to the Pattern and define appropriate assumptions for each strip.
6. To delete a row, select the check box corresponding to the row(s) you want to remove and click the Delete icon
7. Click Save.
The Behavior Pattern is saved and the Behavior Pattern summary page is displayed.
Devolvement and Recovery behavior patterns are commonly used for estimating cash flows associated with Letters of Credit and Guarantees. These product types are typically categorized as off balance sheet accounts. Users are able to assign expected maturity profiles to the related balances classifying them into appropriate categories of Sight Devolvement and Sight Recovery or Usance Devolvement and Usance Recovery. Sight Devolvement and Recovery are the most common types.
To define the non-performing behavior patters, follow these steps:
1. In the Behavior Pattern details page, select Devolvement and Recovery as the Behavior Pattern Type.
2. Enter the Code, Name, and Description for the Behavior Pattern.
3. Click the Add icon to open the Non Performing Behavior Patterns summary page.
Figure 8: Behavior Pattern with Type as Devolvement and Recovery
4. Enter/select the following details:
§ Tenor: Specify the maturity tenor for the first maturity strip. For example, if “1 Day” is defined, then the applicable percentage of the balance will runoff (mature) on the As of Date + 1 Day.
§ Multiplier: The unit of time applied to the Tenor. The choices are:
— Days
— Months
— Years
§ Percentage: The relative amount of the principal balance that will mature on the date specified by the Tenor + Multiplier. The percentage amounts can exceed 100% for devolvement and recovery patterns.
§ Runoff Type: Allows you to classify the runoff based on the appropriate type. The options are:
— Sight Devolvement: indicates the Beneficiary is paid as soon as the Paying Bank has determined that all necessary documents are in order. This is preferred approach.
— Sight Recovery
— Usance: is a period of time which can be between 30 and 180 days after the bill of lading date.
— Usance Recovery
|
NOTE |
There is no difference in behavior from a cash flow perspective, but the runoff amount will be written to a principal runoff financial element corresponding to the selected Runoff Type. |
5. Click the Add icon to add additional payment strips to the Pattern and define appropriate assumptions for each strip.
6. To delete a row, select the check box corresponding to the row(s) you want to remove and click the Delete icon
7. Click Save.
The Behavior Pattern is saved and the Behavior Pattern summary page is displayed.
The Behavior Pattern is saved and the Behavior Pattern summary page is displayed.
This release includes a facility which enables automatic load of behavior patterns. There is a Behavior Pattern Loader Utility which helps to automatically load model output records from STG_BEHAVIOUR_PATTERN into FSI_BEHAVIOUR_PATTERN_MASTER and FSI_BEHAVIOUR_PATTERN_DETAIL. The utility first performs sanity check on all records as per business requirement and only moves records that pass these checks. In the case of non-maturing behavior pattern, only non-replicating portfolio patterns can be loaded through this utility. For more information, see the Data Model Utilities Guide.