Skip Headers

Oracle Transfer Pricing User Guide
Release 12.1
Part Number E13524-03
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

User Defined Payment Pattern

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:

Overview of User Defined Payment Patterns

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:

Related Topics

Standard Navigation Paths

Searching for Payment Patterns

Search for a payment pattern to perform any of the following tasks:

Prerequisites

Procedure:

  1. 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.

  2. Use the Search.

    1. Select the type of search: Code or Description.

    2. Enter the code or description of the Pattern.

    3. Click Go.

      Only patterns that match the search criteria are displayed.

Related Topics

Defining Payment Patterns

Overview of User Defined Payment Patterns

Standard Navigation Paths

Creating 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.

Procedure:

  1. Navigate to the Payment Pattern home page.

  2. Click Create Payment Pattern.

    The Create Payment Pattern page is displayed.

  3. 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.

  4. 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.

  5. Select the Payment Pattern Type: Absolute, Relative, or Split.

  6. 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

Defining Payment Patterns

Overview of User Defined Payment Patterns

Standard Navigation Paths

Defining Absolute 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.

Prerequisites

Procedure:

This table describes some terms in the pages used for this procedure.

Selected Terminology
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.
  1. 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.

  2. Define the Payment Phases.

    Note: A Payment Phase is a set of payment characteristics that defines the time line of the instrument's amortization.

    1. Select a Month for the pattern.

    2. Enter a Date for the pattern.

    3. 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.

    4. 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.

    5. 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.

  3. 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.

Guidelines

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.

Relationship between Payment Phase Attributes 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.

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

Defining Payment Patterns

Creating Payment Patterns

Defining Relative Payment Patterns

You create Relative Payment patterns for instruments that have irregular scheduled payments.

Prerequisites

Procedure:

This table describes some terms in the pages used for this procedure.

Selected Terminology
Term Description
Frequency The frequency of the payment.
Multiplier The unit of time applied to the frequency. The choices are:
  • Days

  • Months

  • Years

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.
  1. 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.

  2. 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.

    1. Enter the Frequency for each payment phase.

    2. Select the appropriate Multiplier for each payment phase.

    3. Enter the number of times each Payment Phase should be repeated in the Repeat column.

    4. 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.

    5. Type the Value for the Payment Method you selected in the previous step for applicable Payment Types.

    6. 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.

  3. 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.

Guidelines

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.

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

Defining Payment Patterns

Creating Payment Patterns

Defining Split Payment Patterns

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.

Prerequisites

Procedure:

This table describes some terms in the pages used for this procedure.

Selected Terminology
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%.
  1. Click Create Split.

    The Create Term Specifications page is displayed.

  2. Select the required Pattern Type.

  3. 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:

  4. Click Apply to add splits. The Create Payment Pattern page is displayed.

  5. Enter the percentage value for each split.

    Important: The sum of the percent values of all splits must add up to 100.

  6. Click Apply.

    The Split payment pattern is saved and the Payment Pattern home page is displayed.

Related Topics

Defining Payment Patterns

Creating Payment Patterns