This chapter describes the procedure for capturing instrument payment patterns that are too complex to be accommodated in the standard fields of Account tables.
This chapter covers the following topics:
User defined payment patterns allow you to define custom repayment patterns for products in your portfolio. You can include a payment pattern while generating cash flows for transfer pricing and option cost processing by entering the payment pattern code as the amortization type code for the instrument. See: Defining Payment Patterns.
The procedure for working with and managing Payment Patterns is, to a certain extent, similar to that of other Oracle Transfer Pricing business rules. It includes the following steps:
Viewing and Updating Payment Patterns. See: Viewing and Updating Rules.
Duplicating Payment Patterns. See: Duplicating Rules.
Deleting Payment Patterns. See: Deleting Rules.
Related Topics
Search for a payment pattern to perform any of the following tasks:
Update
Duplicate
Delete
Predefined payment patterns
Navigate to the Payment Pattern home page. This page is the gateway to all payment patterns and related functionality. You can navigate to other pages relating to payment patterns from this page.
Use the Search.
Select the type of search: Code or Description.
Enter the code or description of the Pattern.
Click Go.
Only patterns that match the search criteria are displayed.
Related Topics
Overview of User Defined Payment Patterns
You create payment patterns to capture the repayment behavior of instruments that are too complex to be accommodated through use of the standard account table fields.
Navigate to the Payment Pattern home page.
Click Create Payment Pattern.
The Create Payment Pattern page is displayed.
Enter a code value for the new payment pattern.
Important: The code, also known as an amortization type code, is a numeric internal identifier for the payment pattern. The code value must be a number between 1000 and 29999. 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_CODE field) to connect the instrument to the appropriate pattern.
Enter a brief description for the pattern.
Note: If you do not provide a description for the pattern at the time of its creation, the system automatically generates a generic description: Payment Pattern: Code Value.
Select the Payment Pattern Type: Absolute, Relative, or Split.
Define the Payment Pattern Term Specifications for payment phases.
The selection of the payment pattern type made in the previous step determines the information you must provide to successfully define that pattern type. See:
Note: The Create Payment Pattern page displays the specifications associated with the Absolute Payment Pattern Type, which is the default Payment Pattern Type value. Should you decide to change this value for any of the other two alternatives, Relative or Split, the system will refresh the payment specifications 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 cause a data loss.
Related Topics
Overview of User Defined Payment Patterns
Absolute payment patterns are commonly used for instruments that are on a seasonal schedule, such as agricultural or construction loans that require special payment handling based on months or seasons.
When working with absolute payment patterns, it is sufficient to define payments for one calendar year. Once the term exceeds a year, the payment schedule will loop until the instrument matures.
Select Absolute as the Pattern Type.
This table describes some terms in the pages used for this procedure.
Term | Description |
---|---|
Month | This drop-down list allows you to select the month of the payment phase being defined. |
Day | Used to specify the day of the month the payment is due. |
Delete | Used to delete a row. |
Select the Payment Type from the drop-down list: Conventional, Level Principal, or Non-Amortizing.
Note: The Payment Type determines the type of information required to successfully define the Payment Phase. See Relation between Payment Phase Attributes and Payment Types.
Define the Payment Phases.
Note: A Payment Phase is a set of payment characteristics that defines the time line of the instrument's amortization.
Select a Month for the pattern.
Enter a Date for the pattern.
Select the Payment Method.
Note: The available Payment Methods depend on the Payment Type. See: Relation between Payment Method and Payment Types for details. Payment Methods do not apply to the Non-Amortizing Payment Type.
Enter the Value for the Payment Method you selected in the previous step for applicable Payment Types.
Note: If you selected the Interest Only Payment Method in the previous step, the Value field does not apply.
Click Add Another Row to add additional Payment Phases to the Pattern and click Delete corresponding to the rows you want to delete.
Important: A Payment Pattern must have at least one valid Payment Phase to be successfully defined. The system raises a warning if you try to save a Payment Pattern with an incomplete Payment Phase. You can define up to 365 Payment Phases for each Payment Pattern.
Click Apply.
The Payment Pattern is saved and the Payment Pattern home page is displayed.
Note: Any empty rows are ignored and not saved with the payment pattern.
When a detail instrument using an Absolute Payment Pattern is processed for Remaining Term cash flow processing, the Next Payment Date is internally calculated to determine which Payment Phase should be used. The calculated Next Payment Date is only used for this purpose. The Next Payment Date stored on the instrument record in the Account table is always the date used for processing the initial payment.
The following table describes the relationship between Payment Phase properties and Payment Types.
Conventional | Level Principal | Non Amortizing | |
---|---|---|---|
Month | Yes | Yes | Yes |
Day | Yes | Yes | Yes |
Payment Method | Yes | Yes | |
Value | Yes | Yes |
The following table describes relationship between Payment Method and Payment Types.
Payment Method | Conventional | Level Principal | Non-Amortizing |
---|---|---|---|
Percentage of Original Balance | Yes | ||
Percentage of Current Balance | Yes | ||
Percentage of Original Payment | Yes | Yes | |
Percentage of Current Payment | Yes | Yes | |
Absolute Payment | Yes | Yes | |
Interest Only | Yes | Yes |
Related Topics
You create Relative Payment patterns for instruments that have irregular scheduled payments.
Select Relative as the Pattern Type.
This table describes some terms in the pages used for this procedure.
Term | Description |
---|---|
Frequency | The frequency of the payment. |
Multiplier | The unit of time applied to the frequency. The choices are:
|
Repeat | The number of times the Payment Phase should be repeated. |
Move Up | Allows you to move a particular Payment Phase row up by one position.
Note: The Move Up icon for the first row of the table is always inactive. |
Move Down | Allows you to move a particular row down by one position.
Note: The Move Down icon for the last row of the table is always inactive. |
Delete | Allows you to delete a row. |
Select the Payment Type from the drop-down list: Conventional, Level Principal, or Non-Amortizing.
The payment type determines the available characteristics for defining the payment amount.
Define the Payment Phase.
Note: The payment type determines the type of information required to successfully define the payment phase. See: Relation between Payment Phase Attributes and Payment Types.
Enter the Frequency for each payment phase.
Select the appropriate Multiplier for each payment phase.
Enter the number of times each Payment Phase should be repeated in the Repeat column.
Select the Payment Method.
Note: The available payment methods depend on the payment type. See: Relation between Payment Method and Payment Types for details. Payment Methods do not apply to the Non-Amortizing Payment Type.
Type the Value for the Payment Method you selected in the previous step for applicable Payment Types.
Click Add Another Row to add additional Payment Phases to the Pattern and click Delete corresponding to the rows you want to delete.
Important: A Payment Pattern must have at least one valid Payment Phase to be successfully defined. The system raises a warning if you try to save a Payment Pattern with an incomplete Payment Phase. You can define up to 365 Payment Phases for each Payment Pattern.
Click Apply.
The payment pattern is saved and the Payment Pattern home page is displayed.
Note: Any empty rows are ignored and not saved with the payment pattern.
It is not necessary to set up relative payment patterns for the complete term of an instrument. The payment pattern automatically repeats until maturity date. Suppose a payment pattern is created to make monthly payments for the first year and quarterly payments for the next three years. If you apply this pattern to an instrument record with an original term of five years, the payment pattern wraps around and the fifth year is scheduled for monthly payments.
An easy way to set up payment patterns for instruments with varying original terms is to use the repeater of 999 in the last row of the payment pattern. For example, a payment pattern that pays monthly for the first year and quarterly thereafter, can be set up with two rows. The first row shows 12 payments at one month. The second row shows 999 payments at three months. When this payment pattern is processed it repeats the three-month payment frequency until the maturity date is reached.
The following table describes the relationship between payment phase attributes and payment types.
Payment Phase Attributes | Payment Types: Conventional | Payment Types: Level Principal | Payment Types: Non-Amortizing |
---|---|---|---|
Frequency | Yes | Yes | Yes |
Multiplier | Yes | Yes | Yes |
Repeat | Yes | Yes | Yes |
Payment Method | Yes | Yes | |
Value | Yes | Yes |
Related Topics
You use a Split payment pattern for financial instruments that make principal payments along two concurrent amortization schedules. Split patterns may be a combination of Absolute and Relative Payment Patterns for example, and contain multiple sets of payment phases under a single amortization code. These patterns could further use a combination of Conventional, Level Principal, and Non-Amortizing Payment Types.
Select Split as the pattern type.
This table describes some terms in the pages used for this procedure.
Term | Description |
---|---|
Percent | The percent value represents the percentage weight of the time line being defined for the individual payment phases (each row). The sum of the percentage weights must total 100%. |
Click Create Split.
The Create Term Specifications page is displayed.
Select the required Pattern Type.
Absolute
Relative
Define the Payment Phases or Splits.
Tip: The payment pattern term specifications for different payment phases or splits vary depending on whether you select the Absolute or Relative Pattern Type. You can define the term specifications for the splits following the steps described previously for defining payment phases for these patterns. See:
Click Apply to add splits. The Create Payment Pattern page is displayed.
Enter the percentage value for each split.
Important: The sum of the percent values of all splits must add up to 100.
Click Apply.
The Split payment pattern is saved and the Payment Pattern home page is displayed.
Related Topics