19 Prepayment Rules

This module describes the procedure for working with and managing Prepayment rules.

Topics

·        Overview of Prepayment Rules

·        Creating Prepayment Rules

·        Defining Prepayment Methodologies

·        Defining Early Redemption Assumptions

·        Associating Conditional Assumptions with Prepayment Rules

Overview of Prepayment Rules

Prepayment rules allow you to specify methodologies to model the loan prepayment and deposit early redemption behavior of products in your portfolio and quantify the associated prepayment risk in monetary terms. For more information, see Defining Prepayment Methodologies section.

The methodologies contained in the Prepayment rule are referenced by Transfer Pricing and ALM Pro­cesses.

The procedure for working with and managing the Prepayment rule is similar to that of other Oracle Asset Liability Management business rules. It includes the following steps:

·        Searching for Prepayment rules.

·        Creating Prepayment Rules

·        Viewing and Editing Prepayment rules.

·        Copying Prepayment rules.

·        Deleting Prepayment rules.

As part of creating and updating Prepayment rules, you can also define prepayment methodologies for all relevant product / currency combinations. For more information, see the following sections:

·        Defining Prepayment Methodologies

·        Defining the Constant Prepayment Method

·        Defining the Prepayment Model Method

·        Defining the PSA Prepayment Method

·        Defining the Arctangent Calculation Method

·        Associating Conditional Assumptions with Prepayment Rules

Oracle Asset Liability Management provides you with the option to copy, in total or selectively, the product assumptions contained within the Prepayment rules from one currency to another currency or a set of currencies or from one product to another product or a set of products. For more information, see Associating Conditional Assumptions with Prepayment Rules section.

Creating Prepayment Rules

You create a Prepayment rule to define prepayment assumptions for new products.

Procedure

1.     Navigate to the Prepayment rule summary page.

2.     Complete standard steps for this procedure.

 

NOTE:   

In addition to the standard steps for creating rules, the procedure for creating a Prepayment rule involves one extra step. After Standard Step 6, you can select a product hierarchy. You can define methodologies at any level of the hierarchical product dimension. The hierarchical relationship between the nodes allows inheritance of methodologies from parent nodes to child nodes.

Defining Prepayment Methodologies

The assignment of prepayment assumptions is part of the Create or Edit Prepayment rule process where assumptions about loan prepayments or deposit early redemptions are made for product-cur­rency combinations. When you click Save in the Create Prepayment rules process, the rule is saved and the Prepayment rule Summary page is displayed. However, prepayment assumptions have not yet been defined for any of your products at this point. Typically, you would start defining your prepay­ment assumptions for product-currency combinations before clicking Save.

The Prepayment rule supports definition of prepayment assumptions for combinations of two dimen­sions: Product and Currency.

Once you have created a Prepayment rule, you can assign prepayment methodologies to product-cur­rency combinations in either of the following two ways:

·        By creating a conditional assumption using conditional logic. For more information, see  Associ­ating Conditional Assumptions with Prepayment Rules section.

·        Directly on the Prepayment methodology page, as described here.

Defining Prepayments Using Node Level Assumptions

Node Level Assumptions allow you to define assumptions at any level of the Product dimension Hierar­chy. The Product dimension supports a hierarchical representation of your chart of accounts, so you can take advantage of the parent-child relationships defined for the various nodes of your product hierarchies while defining rules. Children of parent nodes on a hierarchy automatically inherit the assumptions defined for the parent nodes. However, assumptions directly defined for a child take pre­cedence over those at the parent level.

Prerequisites

Performing basic steps for creating or editing a Prepayment rule.

Procedure

This table describes key terms used for this procedure.

Table 1:  Key terms used for Defining Prepayment Rule
 

Term

 

Description

 

Calculation Method

 

The method used to model prepayment behavior of instru­ments. Oracle Asset Liability Management provides four pre­payment calculation methods: Constant, Prepayment Model, PSA, and Arctangent.

 

Cash Flow Treatment

 

Allows you to specify one of the following two ways in which prepayments are made.

  • Refinance: This is the most commonly used option. Select refinance to keep payment amounts after pre­payment consistent with a portfolio-based assump­tion. This reduces the scheduled payment amount on each loan and maintains the same maturity term.

  • Curtailment: Select curtailment to change the peri­odic payment amounts due. The prepayments are treated as accelerated payments, with a payoff earlier than the originally scheduled term.

 

Market Rate

 

The market rate is defined as the sum of the Index (the yield curve rate as described by the Interest Rate Code) and the Spread (the difference between the customer rate and market rate).

 

Associated Term

 

Allows you to define the term for the point on the yield curve selected in the Market Rate definition that will be used in obtaining the market rate.

  • Remaining Term: The number of months remaining until the instrument matures.

  • Reprice Frequency: The frequency with which the instrument reprices. This defaults to the original term for a fixed rate instrument.

  • Original Term: The number of months that was the originally scheduled life of the instrument.

 

Prepayment Rate Defini­tion

 

This table allows you to specify constant annual prepayment rate, or the associated factors, that you want to apply to the instruments having origination dates in a particular date range.

 

Seasonality

 

This table allows you to specify seasonality adjustments. Sea­sonality refers to changes in prepayments that occur predict­ably at given times of the year.

Seasonality adjustments are based on financial histories and experiences, and should be modeled when you expect the amount of prepayments made for certain types of instruments to increase or decrease in certain months.

The default value for seasonality factors is 1, which indicates that no seasonality adjustment is made for a month. Changing the seasonality factors is optional. You can change the season­ality factors for none, one, or multiple months.

To make seasonality adjustments, you need to enter a value between 0.00 and 99.9999 for the seasonality factors associ­ated with each month. Seasonality factors less than 1 mean that prepayments are decreased for a particular month. Sea­sonality factors greater than 1 indicate that prepayments are increased for a particular month.

1.     Navigate to the Prepayment assumption details page by selecting a currency and one or more products from the hierarchy.

2.     Select a Calculation Method, Constant, Prepayment Model, PSA, or Arctangent.

NOTE:   

The default value for the Calculation Method drop down list is Constant. If you select "Do not calculate" as the calculation method, no prepayment assumptions will be assigned to the particular product-currency combination. This is a particularly useful option when using node level assumptions because it allows you to exclude a particular child from inheriting a parent assumption.

 

3.     Select a Cash Flow Treatment type, Refinance or Curtailment.

Refinance is the most commonly used method.

4.     Define the parameters and annual prepayment rates for the selected calculation method: Con­stant, Prepayment Model, PSA or Arctangent.

NOTE:   

The parameters displayed on the Prepayment methodology page vary depending on the calculation method (Constant, Prepayment Model, PSA or Arctangent) that you have selected. For more infor­mation, see:

·        Defining the Constant Prepayment Method

·        Defining the Prepayment Model Method

·        Defining the PSA Prepayment Method

·        Defining the Arctangent Calculation Method

5.     Click Apply.

The Assumption Browser Definition page is displayed.

At this point you can:

§       Continue defining additional methodologies for other product-currency combinations by repeating the above procedure.

§       Complete the process by clicking Save.

When you click Save, the prepayment assumptions are saved and the Prepayment rule summary page is displayed.

NOTE:   

Oracle Asset Liability Management provides you with the option to copy, in total or selectively, the product assumptions contained within the Prepayment rules from one currency to another currency or a set of currencies or from one product to another product or set of products. For more information, see Associating Conditional Assumptions with Prepayment Rules.

Defining the Constant Prepayment Method

Use this procedure to define prepayment assumptions using the Constant Prepayment method.

Prerequisites

Performing basic steps for creating or updating a Prepayment rule.

Procedure

Users also have two options for determining the timing of the Constant Prepayment assumption. The options include:

·        Use Payment Dates: This is the default option. If this option is selected, then Constant Prepay­ment runoff will occur on scheduled payment dates only.

·        User Defined Prepayment Tenors: If this option is selected, users can specify any runoff timing. For example, users might choose to define the prepayment to runoff on the first day of the fore­cast.

Above options will be available only for Asset Instrument types.

To define constant prepayment within the Prepayment Rule, follow the steps given in below sections:

·        Use Payment Dates

·        User Defined Prepayment Tenors

Use Payment Dates

1.     Select the Use Payment Dates option.

2.     Select the Start Origination Date using the date picker. Alternatively, you can enter the Start Origination Date in the space provided.

NOTE:   

The first cell in the Start Origination Date column and all of the cells in the End Origination Date column are read only. This ensures that all possible origination dates have supporting refer­ence values when Prepayment assumption lookups occur.

Each row in the End Origination Date column is filled in by the sys­tem when you click Add Row or save the rule.

The first Start Origination Date (in row 1) has a default value of January 1, 1900. When you enter a Start Origination Date in the next row, the system inserts a date that is a day prior to the previous End Origination Date field.

3.     Enter the annual prepayment rate percent that you want to apply to the instruments having orig­ination dates in a particular Start Origination-End Origination Date range.

4.     The Percent column represents the actual annualized prepayment percentage that the system uses to generate the principal runoff during the cash flow calculations.

5.     Click Add Row to add additional rows and click the corresponding Delete icon to delete a row.

6.     You can add as many rows in this table as you require. However you need to enter relevant parameters for each new row.

7.     You can also use the Excel import/export feature to add the Prepayment rate information.

8.     You can use Data Input Helper feature. For more information, refer to Data Input Helper.

9.     Define Seasonality assumptions as required to model date specific adjustments to the annual prepayment rate. Inputs act as multiplier, For Example, an input of 2 will double the prepayment rate in the indicated month.

User Defined Prepayment Tenors

1.     Select the User Defined Prepayment Tenors option. This option allows you to specify the term and multiplier to prepayment date for the particular row.

2.     ou can calculate the prepayment rate based on Current/Reducing Balance and Annual/De-annual Prepayment Rate. Select the Balance Type as Current Balance or Reducing Balance.

3.     If the Balance Type is selected as Current Balance, then the prepayment amount will be calcu­lated using CUR_PAR_BAL on As of Date. That is, without reducing the balance by any payment/prepayment that may have occurred between as of date and prepayment date.

4.     If the Balance Type is selected as Reducing Balance, then the prepayment amount will be calcu­lated using balance as on Prepayment Date. That is, after reducing the CUR_PAR_BAL by any payment/prepayment that may have occurred between as of date and prepayment date.

5.     Select the Prepayment Rate Type as Annual Prepayment Rate De-annual Prepayment Rate.

6.     When Annual Prepayment Rate is selected then prepayment rate entered in screen is directly used. In the other case, rate entered in screen in de-annualised before calculating prepayment amount.

7.     Enter the Start Origination Date and End Origination Date ranges, add additional ranges as required using the Add Row button.

8.     Enter the term to runoff tenor and multiplier for each of the date ranges.

9.     Enter the annual prepayment rate percent for each of the date ranges.

10.  Enter 'Repeat' if you want same prepayment to occurs multiple times. By default it is set to 1.

11.  Click Add Row to add additional runoff % rows and click the corresponding Delete icon to delete a row.

12.  Define Seasonality assumptions as required to model date specific adjustments to the annual prepayment rate. Inputs act as multiplier, for example, an input of 2 will double the prepayment rate in the indicated month.

The manner in which prepayment / redemption tenor is interpreted has changed from ALM 8.0.7 onwards in case of user defined prepayment and user defined early redemption. Earlier runoff occurred on “As of date + Prepayment / early redemption tenor”. From ALM 8.0.7 onwards only first runoff occurs on “As of date + Prepayment / early redemption tenor”. Subsequent runoff occur on “Previous prepayment / early redemption date + Prepayment / early redemption tenor”. Thus customers who are upgrading or migrating to ALM 807 from a previous release must appropriately modify tenors in prepayment rules where user defined prepayment tenor and user defined early redemption tenor have been used.

Defining the Prepayment Model Method

Use this procedure to define prepayment assumptions using the Prepayment Model Calculation method.

Prerequisites

·        Performing basic steps for creating or updating a Prepayment rule

·        Creating Prepayment Model rule

Procedure

1.     Define the source for the Market Rate by Selecting an Index (Interest Rate Code) from the list of values.

2.     Enter the Spread. The spread is added to the rate from the underlying interest rate curve to determine the market rate.

3.     Select an Associated Term: Remaining Term, Reprice Frequency, or Original Term.

4.     Specify the Prepayment Model parameters.

§       Select the Start Origination Date using the date picker. Alternatively, you can enter the Start Origination Date in the space provided.

§       Enter the Coefficient (if needed) by which the Prepayment Rate should be multiplied.

This multiple is applied to the instruments for which the origination date lies in the range defined in the Start Origination Date-End Origination Date fields.

§       Select a predefined prepayment model from the Prepayment model Rule list of values. Click the View Details icon to preview the selected Prepayment Model.

§       The system uses the prepayment model assumptions to calculate the prepayment amounts for each period. You need to associate a prepayment model for every Start Origination-End Origination Date range.

§       Click Add Another Row to add additional rows and click the corresponding Delete to delete a row.

You can add as many rows in this model as you require. However you need to enter relevant parameters for each new row.

You can also use the Excel import/export feature to add the Prepayment rate information.

5.     Define Seasonality assumptions as required to model date specific adjustments to the annual prepayment rate. Inputs act as multiplier, for example, an input of 2 will double the prepayment rate in the indicated month.

Defining the PSA Prepayment Method

Use this procedure to define prepayment assumptions using the PSA Prepayment method.

Prerequisites

Performing basic steps for creating or updating a Prepayment rule.

Procedure

1.     Select the Start Origination Date using the date picker. Alternatively, you can enter the Start Origination Date in the space provided.

The first cell in the Start Origination Date column and all of the cells in the End Origination Date column are read only. This ensures that all possible origination dates have supporting reference values when Prepayment assumption lookups occur. Each row in the End Origination Date col­umn is filled in by the system when you click Add Row or save the rule.

The first Start Origination Date (in row 1) has a default value of January 1, 1900. When you enter a Start Origination Date in the next row, the system inserts a date that is a day prior to the previous End Origination Date field.

2.     Enter the PSA speed that you want to apply to the instruments having origination dates in a par­ticular Start Origination-End Origination Date range. The PSA method is based on a standard PSA curve. You can view the seeded model by selecting the View Details icon.

3.     The default value is 100 PSA and inputs can range from 0 to 1667.

4.     Click Add Row to add additional rows and click the corresponding Delete icon to delete a row. You can add as many rows in this table as you require. However you need to enter relevant parameters for each new row.

5.     You can also use the Excel import/export feature to add the Prepayment rate information.

6.     Define Seasonality assumptions as required to model date specific adjustments to the annual prepayment rate. Inputs act as a multiplier, For example, an input of 2 will double the prepayment rate in the indicated month.

Defining the Arctangent Calculation Method

Use this procedure to define prepayment assumptions using the Arctangent Calculation method.

Prerequisites

Performing basic steps for creating or updating a Prepayment rule.

Procedure

1.     Define the source for the Market Rate by Selecting an Index (Interest Rate Code) from the list of values.

2.     Enter the Spread.

3.     The spread is added to the rate from the underlying interest rate curve to determine the market rate.

4.     Select an Associated Term: Original Term, Reprice Frequency, or Remaining Term.

5.     Specify the Arctangent Argument table parameters.

6.     Select the Start Origination Date using the date picker. Alternatively, you can enter the Start Origination Date in the space provided.

7.     Enter the values for the Arctangent parameters (columns K1 through K4) for each Start Origina­tion Date in the table. The valid range for each parameter is -99.9999 to 99.9999.

8.     Click Add Another Row.

9.     You can add as many rows in this table as you require. However you need to enter relevant parameters for each new row.

10.  You can also use the Excel import/export feature to add the Prepayment rate information.

11.  Define the Seasonality assumptions as required to model date specific adjustments to the annual prepayment rate. Inputs act as multiplier, For example, an input of 2 will double the pre­payment rate in the indicated month.

Defining Early Redemption Assumptions

If you are working with deposit products, it is possible to define Early Redemption assumptions within the Prepayment Rule. While defining assumptions, the Prepayment rule will consider whether or not the product is an asset or liability (based on the account type attribute defined in dimension member management). If the product is an asset, then the Prepayments tab will be active in the prepayment assumption detail page. If the product is a liability, then the Early Redemption tab will be active.

Prerequisites

·        Performing basic steps for creating or updating a Prepayment rule.

·        To define Early Redemption assumptions, the account type for the selected product must be a Liability.

 

Procedure

The procedure for defining Early Redemptions is the same as noted above for prepayments, with two exceptions:

·        The list of Calculation Methods is limited to Constant and Prepayment Models

·        The range definitions are based on Maturity Date ranges of the instruments rather than Origina­tion Date ranges

Users also have two options for determining the timing of the early redemption assumption. Options include:

·        Use Payment Dates: This is the default option. If selected early redemption runoff will occur on scheduled payment dates only.

·        User Defined Redemption Tenors: If selected, users can specify any runoff timing. For exam­ple, users might choose to define the early redemption to runoff on the first day of the forecast.

To define Early Redemptions within the Prepayment Rule, follow the steps given below:

Use Payment Dates

1.     Select the Use Payment Dates option.

2.     Enter the Start Maturity and End Maturity Dates.

3.     The first cell in the Start Maturity Date column and all of the cells in the End Maturity Date col­umn are read only. This ensures that all possible Maturity dates have supporting reference val­ues when Prepayment assumption lookups occur. Each row in the End Maturity Date column is filled in by the system when you click Add Row or save the rule. The first Start Maturity Date (in row 1) has a default value of January 1, 1900. When you enter a Start Maturity Date in the next row, the system inserts a date that is a day prior to the previous End Maturity Date field.

4.     Enter the annual prepayment rate percent that you want to apply to the instruments having orig­ination dates in a particular Start Maturity-End Maturity Date range.

5.     The Percent column represents the actual annualized prepayment percentage that the system uses to generate the principal runoff during the cash flow calculations.

6.     Click Add Row to add additional rows and click the corresponding Delete icon to delete a row.

7.     You can add as many rows in this table as you require. However you need to enter relevant parameters for each new row.

8.     You can use Data Input Helper feature. For more information, see  Data Loader section.

9.     You can also use the Excel import/export feature to add the Prepayment rate information. For more details, see Excel Import/Export section.

User Defined Redemption Tenors

1.     Select the User Defined Redemption Tenors option. This option allows you to specify the term to runoff for the particular row.

2.     Enter the Start Maturity and End Maturity date ranges, add additional ranges as required using the Add Row button.

3.     You can calculate the prepayment rate based on Current/Reducing Balance and Annual/De-annual Prepayment Rate. Select the Balance Type as Current Balance or Reducing Balance.

4.     If the Balance Type is selected as Current Balance, then the prepayment amount will be calcu­lated using CUR_PAR_BAL on As of Date. That is, without reducing the balance by any payment/prepayment that may have occurred between as of date and prepayment date.

5.     If the Balance Type is selected as Reducing Balance, then the prepayment amount will be calcu­lated using balance as on Prepayment Date. That is, after reducing the CUR_PAR_BAL by any payment/prepayment that may have occurred between as of date and prepayment date.

6.     Select the Prepayment Rate Type as Annual Prepayment Rate Or De-annual Prepayment Rate.

7.     When Annual Prepayment Rate is selected then prepayment rate entered in screen is directly used. In the other case, rate entered in screen in de-annualised before calculating prepayment amount.

8.     Enter the Start Origination Date and End Origination Date ranges, add additional ranges as required using the Add Row button.

9.     Enter the term to runoff tenor and multiplier for each of the date ranges.

10.  Enter the early redemption runoff percentage for each of the date ranges.

11.  Enter 'Repeat' if you want same prepayment to occurs multiple times. By default it is set to 1.

12.  Click Add Row Delete.

13.  Define Seasonality assumptions as required to model date specific adjustments to the annual prepayment rate or early redemption rate. Inputs act as multiplier, for example an input of 2 will double the runoff rate in the indicated month.

The manner in which prepayment / redemption tenor is interpreted has changed from ALM 8.0.7 onwards in case of user defined prepayment and user defined early redemption. Earlier runoff occurred on “As of date + Prepayment / early redemption tenor”. From ALM 8.0.7 onwards only first runoff occurs on “As of date + Prepayment / early redemption tenor”. Subsequent runoff occur on “Previous prepayment / early redemption date + Prepayment / early redemption tenor”. Thus custom­ers who are upgrading or migrating to ALM 807 from a previous release must appropriately modify tenors in prepayment rules where user defined prepayment tenor and user defined early redemption tenor have been used.

Associating Conditional Assumptions with Prepayment Rules

Oracle Asset Liability Management extends setup and maintenance of assumptions by allowing users to integrate conditional logic (optional) into the setup of, prepayment methods. You can define prepay­ment methodologies using IF-THEN-ELSE logic based on the underlying characteristics of your finan­cial instruments, such as dates, rates, balances, and code values. The Conditional Assumption UI is accessed from the Assumption Browser by selecting the Conditional Assumption icon.

The conditional logic is defined through use of Data Filters and/or Maps. These existing objects pro­vide the building blocks for defining Conditional logic. For example, each Data Filter can provide the logic for a specific condition. In the example below, the where clause is "Adjustable Type Code = 'Adjustable Rate'". This type of Data Filter can be selected within the Conditional Assumption UI.

Similarly, a Mapper object provides the necessary reference to one or more hierarchies, when dimen­sion / hierarchy data is needed to define conditional logic. In the example below, this map refers to a hierarchy created on the Organization Unit dimension.

NOTE:   

Maps are accessed from the Infrastructure (HOME) page. You can find them at the following path:

Navigate to Common Object Maintenance, select  Unified Analytical Metadata, then select Map Maintenance.

To create a map, use the following steps:

1.     Navigate to Map Maintenance.

2.     Select icon to create new Map.

3.     On the left hand side, select one or more hierarchies that were enabled in the initial step.

4.     Fill in required information, that is Name, Effective Dates, and Entity Name.

5.     Click Save button.

6.     From the Map Maintenance Summary page, select the Map and the icon for " Mapper Mainte­nance".

Here, you will see the hierarchy and all parent/child relationships.

The range of product attributes supported for conditional assumptions and available for use within Data Filters is determined by columns which are part of the "Portfolio" definition. The "Portfolio" table class is seeded with the installation, and can be extended to include user defined columns.

For more information on adding user defined columns to the Portfolio table class, see Data Model Util­ities Guide.

When using mappers, Conditional Assumptions can be attached to any level of the hierarchy, allowing assumptions to be inherited from parent nodes by child nodes.

For example, you can use the Org Unit column to drive the assignment of Transfer Pricing Methods for all members of a particular Organization. You can create one Conditional Assumption to convey the entire Transfer Pricing Methodology logic and attach it to the top-level node of the Org Unit hierarchy. All nodes below the top-level node will inherit the same Transfer Pricing assumption.

The logic included in a Conditional Assumption determines the specific Transfer Pricing method, Pre­payment assumption or Adjustment Rule that the system will assign to each individual instrument record at run time.

The Conditional Assumption screen allows users to select explicit conditions (from Data Filters and/or Maps) and apply methods and rule selections to each condition directly. The Filter Conditions are pro­cessed by the engine in the order that they appear on the screen. As soon as a condition is satisfied, the related assumption is applied.

If an instrument record does not meet any of the conditions, then the rule logic reverts to the standard assumption that is directly assigned to the Product / Currency combination. In the example below, you can see that Fed Funds has both a direct assignment and a conditional assumption. If the condition is not met, the "Fixed Rate" assumption (ELSE condition) will be applied. In the case of Reverse Repo's, there is only a Conditional Assumption. In the absence of an ELSE assumption, the engine will use the conditional assumption in all cases for the Product/Currency pair. To avoid this, users should define the Standard/Else assumption with an appropriate input.

Conditional Assumptions can be applied only to detailed account records (data stored in the Instrument Tables).