In a user defined payment pattern, you can assign a unique amortization type code to a set of payment events, which may include some of the following customized features:
· Changes in payment frequency
· Seasonal payment dates
· Nonstandard or variable payment amounts
Once you create a payment pattern, you can use it by entering the payment pattern code as the amortization type code for the instrument.
Oracle Balance Sheet Planning allows you to build three types of payment patterns:
· Absolute
· Relative
· Split
These payment patterns differ in terms of how they address payment schedules, which determine whether the payment events constituting the pattern are determined by calendar dates or periods. Absolute patterns are defined with sets of payment characteristics scheduled on specific calendar dates. Relative patterns are defined with sets of payment characteristics scheduled for certain periods of time.
You can also define a payment pattern with both absolute and relative payment events. This type of pattern is called a split pattern.
In addition, for each payment pattern, you need to specify a payment type, either conventional, level principal, or non-amortizing. Your choice of the pattern type and the payment types will determine the fields that are used for calculation.
You must define one or more payment event to complete a payment pattern. A payment event is a set of payment characteristics, which define the time line and amount of a specific payment in the payment pattern.
Though the characteristics of the payment phase change based on whether you are defining an absolute, relative, or split pattern, there are two characteristics that are required for all amortizing patterns:
· Payment method
· Value
The payment methods determine the payment amount for the payment event. There are six different methods.
The following table describes the different payment methods.
Method |
Description |
|---|---|
% of Original Balance |
This method calculates the payment as a percentage of the original balance; the percentage being defined by the input percent. This method is useful for apportioning the starting balance on a level principal instrument over several payments. This method is only available for payment patterns defined with a level principal payment type. |
% of Current Balance |
This method calculates the payment as a percentage of the current balance prior to payment; the percentage being defined by the input percent. This method is only available for payment patterns defined with a level principal payment type. |
% of Original Payment |
This method calculates the payment as a percentage of the original payment column from the detail instrument data. This percentage is defined by the input percent. |
% of Current Payment |
This method calculates the payment as a percentage of the previous payment; the percentage being defined by the input percent. This payment is calculated on the payment date based on the characteristics of the instrument at the time of the payment, including the current rate, current balance, and current payment frequency. |
Absolute Payment |
This is an input payment amount. This amount represents both principal and interest for a conventional payment type, and represents only principal for a level principal payment type. For both types of patterns, absolute value payment amounts are entered as gross of participations. |
Interest Only |
This is a calculated payment amount. An interest-only payment is calculated during processing as balance times rate times accrual factor. |
Value
The value reflects the percentage or payment amount based on the method chosen for the payment event. Value is disabled for phases using the Interest Only payment method.
Payment amounts for conventional pattern phases must reflect both principal and interest payments. Payment amounts for level principal pattern phases only reflect the principal portion of the payment. For level principal pattern phases, the total cash flow on a payment date is the principal amount stored as the payment plus the calculated interest.
Note The payment method and value columns are not displayed for payment patterns defined with a non-amortizing payment type. All payments are assumed to be interest only for this type of payment pattern. |
Absolute payment patterns are commonly used for instruments that pay on a seasonal schedule, such as agricultural or construction loans that require special payment handling based on months or seasons.
Take the example of a loan that follows a seasonal payment pattern, in which the payment patterns for January, February and March are scheduled for interest-only payments. As revenues for the customer increase, the payment amount also increases. Therefore, the payments for April and May are 80% of the original payment, and June through September is 100% of the original payment. The payment decreases as the production season slows. The payment for October is decreased to 80% of the original payment, and the payments for November and December are decreased again to 50% of the original payment.
Note You can define absolute payment patterns only up to a year. This is because all entries are automatically ordered by date and are scheduled in a single year rotation. |
Relative payment patterns are commonly used for modeling instruments with irregular payment frequencies or for instruments where the payment type changes over time. Take the case of a four-year loan for example. The payment for the first 12 months could only be interest. The first 35 payments are scheduled for 50% of the currently scheduled payment, and the last payment is a balloon payment for the balance of the loan.
A split pattern contains multiple sets of payment patterns under a single amortization code. You use a split pattern for financial instruments that make principal payments along two concurrent amortization schedules. Each separate amortization schedule is termed a time line and assigned a percentage of the balance. A Split Pattern can constitute both absolute and/or relative payment patterns within itself.