Skip Headers

Oracle Financial Services Reference Guide
Release 12.1
Part Number E13528-03
Go to Table of Contents
Contents
Go to previous page
Previous
Go to next page
Next

Cash Flow Calculations

This chapter discusses cash flow calculation concepts and processes.

This chapter covers the following topics:

Overview of Cash Flow Calculations

Oracle Transfer Pricing makes use of the OFS Cash Flow Engine to ensure modeling consistency across Oracle Financial Services (OFS) applications. An understanding of the Oracle Transfer Pricing cash flow calculations requires knowledge of cash flow calculation concepts and processes as well as that of the capabilities of the OFS Cash Flow Engine and the calculations that can be performed by it.

Note: As cash flows for an instrument are modeled through time, the data associated with the instrument changes due to payments, repricings, and other characteristics or events. These changes apply only in memory and do not affect the information stored in the Account Tables.

In this exposition, a subscript notation of m for memory and r for detail record helps differentiate between forecasted and actual data. For example, Current paymentr refers to the current payment stored in the Account Table. Current paymentm refers to the current payment in memory that is updated each time a payment recalculation occurs.

Cash Flow Calculations Characteristics and Concepts

A complete understanding of Oracle Transfer Pricing cash flow calculations requires familiarity with the following key concepts and characteristics:

Related Topics

Overview of Cash Flow Calculations

Instrument Level Modeling

Several transfer pricing methods require cash flows to generate results. Oracle Transfer Pricing supports the following cash flow transfer pricing methods:

Oracle Transfer Pricing generates cash flows at the individual instrument level. Each individual instrument record processed generates a set of cash flows as defined by that instrument record's product characteristics. The cash flows produced are then processed further to generate the required results such as transfer rates or option costs.

The usage of cash flows generated from individual instruments for processing provides an optimum level of accuracy.

Related Topics

Cash Flow Calculations Characteristics and Concepts

Modeling Flexibility

Oracle Transfer Pricing instrument data provides for modeling flexibility. Each instrument record has the following data:

Specific cash flow characteristics defined in an instrument record determine the cash flows to be generated. There are more than 50 data columns that directly affect the cash flow results. Depending on the information in these columns, you can model an unlimited number of instruments.

Related Topics

Cash Flow Calculations Characteristics and Concepts

Daily Cash Flows

Oracle Transfer Pricing lets you set instrument records in such a manner that cash flows can occur on any date, and with any frequency thereafter. This functionality is essential for generating accurate results.

Related Topics

Cash Flow Calculations Characteristics and Concepts

Event-Driven Logic

Oracle Transfer Pricing generates cash flows as a series of events. On any day, and with any frequency, depending on the instrument characteristics, any of the following events can occur:

Each of these events requires cash flow calculations.

Related Topics

Cash Flow Calculations Characteristics and Concepts

Financial Elements

On an event date, such as a payment or repricing event date, the OFS Cash Flow Engine computes the results of that event. The results of an event are represented in the form of financial elements. For example, on a payment event date, the Cash Flow Engine can compute the following:

The cash flow engine generates and outputs over 50 financial elements to the FTP_PROCESS_CASH_FLOWS table that can be used to validate results.

Related Topics

Cash Flow Calculations Characteristics and Concepts

The Cash Flow Calculation Process

The cash flow calculation process comprises the following broad stages:

  1. Initialization of the modeling data and parameters for the instruments to be modeled. See: Initialization of Modeling Data and Parameters.

  2. Processing of modeling events until current date equals the maturity date or the modeling end date, or the current balance equals zero. This stage involves the following steps:

See: Processing Modeling Events.

Related Topics

Overview of Cash Flow Calculations

Initialization of Modeling Data and Parameters

The first step in the cash flow calculation process is to gather the information necessary to model an instrument. This information is available from several sources, including:

Related Topics

The Cash Flow Calculation Process

Determination of Account Type

The Extended Account Type attribute of the Line Item Dimension Member determines the account type of an individual record. Account types:

The following table illustrates the different cash flow processing types and associated account types.

Cash Flow Processing Types
Cash Flow Types Process Description - Detail Associated Account Type
Detail cash flow Processes daily cash flow events and generates necessary financial elements. Interest-Earning Asset
Interest-bearing Liability
Off Balance Sheet Receivable
Off Balance Sheet Payable
Balance Only Processes the record originating on the origination date and running off on the maturity date. No payments are processed. Other Asset
Other Liability
Interest Only Processes the instrument as a single interest payment covering the time from the origination date to the maturity date. Recognizes the current balance as an interest cash flow on the maturity date, but accrues interest from the origination date to the maturity date. Interest Income
Interest Expense

Note: For information about financial elements output by account types, see the Financial Element Calculations table.

Related Topics

Initialization of Modeling Data and Parameters

Initialization of Interface Data

Data retrieved from the interface impacts how an instrument is processed. The interface data that affect processing are as follows:

User Defined Payment Patterns

Payment pattern data is retrieved when the cash flow engine needs to process an instrument that has a payment pattern code ranging from 1000 to 29999 as its amortization type code.

The amortization type code from the detail instrument record is matched to the set of payment pattern data with the same code. If no match is found for the amortization code from the detail record, the instrument record is assumed to be of nonamortizing type.

User Defined Repricing Pattern

Repricing pattern data is retrieved when the cash flow engine needs to process an instrument that has a repricing pattern code ranging from 500 to 998 as its adjustable type code.

If no related repricing pattern data is found, the engine defaults to the record characteristics in the repricing frequency column and processes the instrument as a standard adjustable instrument.

When a match is made, the instrument is modeled based on the repricing pattern. The cash flow engine first evaluates the status of the instrument as of the starting date of the cash flow process. The current repricing date is determined by rolling forward from the origination date to the next repricing date that follows the process start date. If the process start date does not correspond to the next repricing date, the repricing date from the record is used.

A repricing event is triggered when the period between two repricing events has elapsed. When this occurs, the defined rates are assigned to the detail record of the instrument. If the repricing type is Flat Rate, the rate from the event detail of the repricing pattern is applied to the detail record of the instrument. If the repricing type is Indexed Rate, a rate lookup is triggered for the customer rate and the transfer pricing rate. If the interest rate code (IRC) is a yield curve, the point on the yield curve used is the repricing term associated with the current repricing information, unless the IRC term has been specified in the repricing pattern event. This rate, plus the specified margin, is the new fully indexed rate. Rate caps and floors are applied after this calculation occurs.

Related Topics

Initialization of Modeling Data and Parameters

Initialization of Cash Flow Data

The cash flow engine gathers the cash flow data for the instrument to be processed. The cash flow data for an instrument is a subset of the information stored in the Account Tables for that instrument record. For a complete list of columns referenced in the cash flow calculation process, see theFinancial Element Calculations table.

The cash flow data provides current information about the characteristics of a cash flow instrument. This information must be consistent to ensure accurate output. Before processing cash flows, the cash flow edits checks should be run to avoid producing unreasonable results. See:

Cash flow data can be classified into the following three categories defining its use during the processing of an event:

Static Characteristics

Static characteristics provide information to the cash flow engine about how the instrument should be modeled. For non-pattern and non-schedule instruments, all of the following characteristics remain constant during the modeling process:

For pattern and schedule instruments, the payment frequency can vary throughout the life of the instrument.

Dynamic Characteristics

Dynamic characteristics are updated each time an event occurs, as a result of what has occurred during the event. These include the following:

Triggers

Triggers signal the cash flow engine when it is time to model a particular event and can change their value during the modeling process. These include the following:

Related Topics

Initialization of Modeling Data and Parameters

Initialization of Schedule Records

Oracle Transfer Pricing provides a payment schedule table, FTP_PAYMENT_SCHEDULE, for loading cash flow details related to instruments that have unique, non-standard payment characteristics which cannot easily be captured using traditional amortization methods or into a payment pattern definition. To properly model scheduled-amortization instruments, the cash flow engine must retrieve payment dates and payment amounts from the payment schedule table.

The payment schedule table is referenced by the Cash Flow engine by lookup, based on a match of the Instrument type code (INSTRUMENT_TYPE_CODE) and Account number (ID_NUMBER) columns from the instrument record to the same data in the payment schedule table. The Cash Flow engine looks at this table when the AMRT_TYPE_CODE column on the instrument record is populated with a value of 800, 801, or 802. If no match is found, the instrument is processed as a non-amortizing record.

Amortization Code 800

An amortization code of 800 denotes conventional payment schedule and signifies that payment amounts are principal and interest amounts. On payment dates, these payments are processed as conventional amortization payments.

Amortization Code 801

An amortization code of 801 denotes level principal payment schedules. On the schedules for these instruments, the payment amount comprises the principal portion of the payment only. For both conventional (800) and level principal (801) payment schedules, the payment amounts should be expressed gross of any participations.

Amortization Code 802

An amortization code of 802 denotes simple interest payment schedule. Instruments with amortization codes of 802 do not reference the principal amount column in the schedule tables. These instruments are processed as interest only records, with all principal, with the exception of prepayments, running off on the maturity date.

The data in the maturity date, next payment date, last payment date, remaining number of payments, and current payment columns of the instrument record should coincide with the same information in the schedule table. When this information is inconsistent, the information in the detail record supersedes the data in the schedule table.

In this case, the payment on the next payment date occurs on the date defined in the next payment date column of the instrument record, for the amount defined in the current payment column of the instrument record.

All payments after this date and before the maturity date are made according to the payment date in the schedule table. On the maturity date, the date from the maturity date column of the instrument record is used to pay off the remaining balance of the instrument record. If payment dates exist in the schedule beyond this date, they are ignored.

Related Topics

Initialization of Modeling Data and Parameters

Initialization of Pattern Records

The following logic applies to both user defined payment and repricing patterns.

Single Timeline Patterns

To initialize an instrument record whose payment (or repricing) characteristics are defined by a single timeline pattern, the cash flow engine must synchronize the detail instrument record with the payment (or repricing) pattern. Synchronization determines the current payment of the instrument within the payment (or repricing) pattern.

The synchronization process depends on whether the pattern is relative or absolute.

To synchronize a relative pattern, the cash flow engine calculates the payment (or repricing) dates for the instrument record by rolling the origination date forward by the pattern frequencies. Once it calculates a payment (or repricing) date greater than the calendar period end date, it stops. The number of times it was necessary to roll the date forward determines the current payment (or repricing event) number for the record.

Example

An instrument record processed on an calendar period end date of 03/31/1996 with an origination date of 01/01/1996, and a next payment (or repricing) date of 05/15/1996 is matched to the pattern described in the following table:

Example of Single Timeline Pattern
Row # Frequency Repetitions
1 1 M 3
2 3 M 3

The origination date is rolled forward in the following manner from the Starting point - 01/01/1996:

After the third roll forward, the payment (or repricing) date is greater than the calendar period end date. The cash flow engine interprets that the record is on its third payment (or repricing), which is the final monthly payment (or repricing). It models this payment (or repricing) on the next payment (or repricing) date from the detail record, in this case, 05/15/1996. The next payment (or repricing) is scheduled for 8/15/1996, using the three month frequency from the fourth payment (or repricing) in the schedule.

Absolute patterns do not require the same rolling mechanism for synchronization. The next payment (or repricing) date from an absolute pattern is determined by the first month and day after the calendar period end date. If this date does not correspond to the next payment (or repricing) date from the detail record, the next payment (or repricing) date of the detail record supersedes the date of the pattern. From that point on in the process, the payment (or repricing) dates from the pattern are used.

The cash flow engine has been designed in this manner to allow greater flexibility in modeling payment and repricing patterns. However, this flexibility increases the importance of detail data accuracy to ensure that when discrepancies exist between detail data and patterns, the differences are intended.

Multiple Timeline Patterns (Payment Patterns Only)

To initialize a detail instrument record tied to a split pattern, the cash flow engine generates a separate record for each split. The current balance for each split record is calculated using the percentage apportioned to that split, as defined through the payment pattern interface. The original balance, original payment, and current payment columns are also apportioned according to the percentage defined through the interface.

For each timeline resulting from the split of a detail instrument record, the current payment date must be determined. The method for determining the payment date is the same as described for single timeline patterns with one exception. For these instruments, the next payment date from the original instrument record does not override the calculated next payment date. The date derived from rolling the origination date forward for relative timelines or locating the next date for absolute timeliness is assumed to be the correct payment date.

Related Topics

Initialization of Modeling Data and Parameters

Determination of Modeling Start and End Dates

Modeling start and end dates are determined by the type of processing and the instrument being processed, as shown in the following table:

Modeling Start and End Dates
Processing and instrument type Start Sate End Date
OFS Transfer Pricing Standard Calculation Mode - Adjustable last reprice date next reprice date
OFS Transfer Pricing Standard Calculation Mode - Fixed origination date maturity date
OFS Transfer Pricing Remaining Term Calculation Mode - Adjustable effective date + 1 day next reprice date
OFS Transfer Pricing Remaining Term Calculation Mode - Fixed effective date + 1 day maturity date

Oracle Transfer includes records for processing after filtering them using the calendar period end date and dataset group parameters such as ledger and input datasets.

For example, only records that have a value in the Calendar Period column of the database equal to the Calendar Period input as a run parameter for the Transfer Pricing Process rule are included.

Related Topics

Initialization of Modeling Data and Parameters

Initialization of Additionally Derived Data

The transfer pricing of adjustable rate instruments involves the following additional steps:

Data Reset to Values Consistent with the Last Reprice Date

Oracle Transfer Pricing resets data to values consistent with the last reprice date by rolling back the next payment date by the payment frequency to the first payment date after the last reprice date. The application increases the remaining number of payments by the number of payments added in the rollback process.

The Last Reprice Date Balance is used in place of the current balance in a transfer pricing process. If the balance as of the last reprice date is not available, the application updates this column with the current balance. Oracle Transfer Pricing program has a special feature that re-amortizes the current payment if the following conditions are met:

These three conditions signal the cash flow engine that the balance as of the last reprice date is not available and that the current balance should be used as a proxy.

Percent Sold Adjustment

Balances must be adjusted for participations:

Related Topics

Initialization of Modeling Data and Parameters

Processing Modeling Events

The cash flow engine models the following four events:

When multiple events occur on the same day the cash flow engine processes them in the following order:

Note: For interest in advance instruments, payment calculation is not applicable. Payment calculation occurs only on conventionally amortizing instruments.

The cash flow engine processes an event as follows:

Related Topics

The Cash Flow Calculation Process

Payment Calculation Event

The cash flow data for payment calculation has the following characteristics:

Static Information: Conventional Adjustable and Payment Patterns

Additional Information: Adjustable Negative Amortization (NGAM):

Event Trigger: Transfer Pricing

Event Triggers: Conventional Adjustable and Conventional Payment Patterns

Event Triggers: Adjustable Negative Amortization (NGAM)

Related Topics

Processing Modeling Events

Payment Calculation Steps

Payment calculation comprises the following steps:

  1. Calculation of New Current Payment

  2. Application of Periodic Payment Change Limits

  3. Application of Lifetime Payment Change Limits

  4. Negative Amortization (NGAM) Equalization

  5. Update of Current Payment Field

1. Calculation of New Current Payment

Conventionally Amortizing Payment = Current Par Balancem / (1 / Current Ratec) x (1 - (1 + Current Ratec) ^ rem pmtsa)

Here:

For conventional schedules that reprice, payment recalculation does not occur. For patterns which reprice, payment recalculation does not occur during the repricing event. For these instruments, the payment is calculated at the time of payment. See: Payment Event.

Current Compounded Customer Rate per Payment

The customer rate must be adjusted to a rate per payment. If no compounding occurs, the rate can be divided by the payments per year. The following table illustrates how a current customer rate of 7.5% is adjusted to a rate per payment.

Example of Current Customer Rate Adjusted to a Rate per Payment
Payment Frequency Calculation Rate per Payment
monthly 7.5 ÷12 0.625
quarterly 7.5 ÷ 4 1.875
yearly 7.5 ÷ 1 7.5

If the instrument compounds, the rate must be adjusted for compounding. For monthly rates that compound daily, an average number of days assumption of 30.412 is used.

Remaining Number of Payments Based on Amortization

If the amortization term is equal to the original term, the calculation of the remaining number of payments is simple.

However to calculate the remaining number of payments when the amortization term is lesser or greater than the original term, the cash flow engine adds the amortization term to the origination date to determine the amortization end date. The cash flow engine calculates the remaining number of payments by determining the number of payments that can be made between the next payment date and the amortization end date, and adding one additional payment for the payment on the next payment date.

The cash flow engine calculates the remaining number of payments for patterns based on the payment frequency at the time of repricing. As with conventional instruments, the amortization end date is used for payment recalculation. The remaining term is calculated using the difference between the next payment date and the amortization end date. This term is divided by the active payment frequency and one additional payment is added to it for the payment on the next payment date.

2. Application of Periodic Payment Change Limits

Periodic payment change limits restrict the amount by which a payment installment can increase over its previous value. These limits are applied only when the payment installment recalculation is triggered by a payment adjustment date or a negative amortization limit. Because of these limits, the principal may continue to negatively amortize when the negative amortization limit has been reached. The following table describes payment conditions and related adjustments.

Payment Conditions and Related Adjustments
Condition Adjustment
Increasing Payment: Newly Calculated Payment > (1 + (Payment Increase Lifer/100)) * Original Paymentr Current Paymentm = (1+ (Payment Increase Lifer/100)) * Original Paymentr
Decreasing Payment: Newly Calculated Payment < (1 + (Payment Decrease Lifer/100)) * Original Paymentr Current Paymentm = (1 + (Payment Decrease Lifer/100)) * Original Paymentr

3. Application of Lifetime Payment Change Limits

Lifetime payment cap and floor set the maximum and minimum amount for a payment installment. These limits are applied only when a payment recalculation is triggered by a payment adjustment date or a negative amortization limit. Because of these limits, principal may continue to negatively amortize when the negative amortization limit has been reached.

Payment Conditions and Related Adjustments
Condition Adjustment
Increasing Payment: Newly Calculated Payment > (1 + (Payment Increase Lifer/100)) * Original Paymentr Current Paymentm = (1+ (Payment Increase Lifer/100)) * Original Paymentr
Decreasing Payment: Newly Calculated Payment < (1 + (Payment Decrease Lifer/100)) * Original Paymentr Current Paymentm = (1 + (Payment Decrease Lifer/100)) * Original Paymentr

4. Negative Amortization (NGAM) Equalization

If a payment recalculation is triggered by a NGAM equalization date, payment change limits do not apply. If the newly calculated payment is greater than the lifetime payment cap or less than the lifetime payment floor, the appropriate lifetime payment limit (cap/floor) is set equal to the newly calculated payment.

5. Update of Current Payment Field

Once all the payment limits have been applied, the new current payment is updated in memory for the processing of future events.

Related Topics

Processing Modeling Events

Payment Event

The cash flow data for payment event has the following characteristics:

Static Information

Dynamic Information

Event Triggers

Related Topics

Processing Modeling Events

Payment Event Steps

The payment event comprises the following steps:

  1. Calculation of Interest Cash Flows

  2. Calculation of Current Payment for Patterns and Schedules

  3. Calculation of Principal Runoff

  4. Performing Special Negative Amortization Check

  5. Identifying Maturity Date Case

  6. Update of Current Balance

  7. Update of Remaining Number of Payments

  8. Update of Next Payment Date

1. Calculation of Interest Cash Flows

The cash flow engine calculates the amount of interest to be paid on a payment date as described in the following table:

Interest Rate Calculation Formulas
Interest Cash Flow Calculation
Interest cash flow gross Current net par balance * gross rate per payment
Interest cash flow net Current net par balance * net rate per payment

Note: Loans with amortization schedules based on the Rule of 78 are exceptions. These loans have a precomputed interest schedule. See: Example of the Rule of 78.

Rate per Payment: Accrual Adjustment

The annual coupon rate must be adjusted to a rate per payment. The accrual basis codes define how this adjustment should be made.

Accrual Basis Codes Example

The following table shows how using different accrual basis codes an annual coupon rate of 6 percent is adjusted to a rate per payment for a June 30 payment for an instrument that has a payment frequency of three months.

Accrual Basis Codes and Rate per Payment Adjustments
Accrual Basis Code Payment Adjustment Rate per Payment
30/360 (3*30)/360 * 6.0 1.500%
30/365 (3*30)/365 * 6.0 1.4795%
30/Actual 90/365 * 6.0 1.4795%
Actual/Actual (30+31+30)/365 * 6.0 1.4959%
Actual/365 (30+31+30)/365 * 6.0 1.4959%
Actual/360 (30+31+30)/360 * 6.0 1.5167%

This formula assumes a single rate per payment period. If an instrument reprices multiple times within a payment period, only the last repricing event affects the interest cash flow.

Rate per Payment: Compounding Adjustment

The cash flow engine compounds the rate used in interest calculation if the compounding frequency is less than the payment frequency. The following table describes the interest rate compounding codes and the associated compounding formula.

Compounding Codes and Formula
Compounding Code Calculation
Simple No compounding
At Maturity No compounding
Continuous e^(rate per payment) -1
Daily (1 + rate/365 or 366) ^ (days in payment) -1
Monthly, Quarterly, Semi-Annually, Annually (1 + rate per pmt/cmp pds per pmt) ^ (cmp pds per pmt)

Rate per Payment: Stub and Extended Payment Adjustment

An adjustment may be made if the expected payment frequency (in days) is different from the actual payment frequency (in days). The number of days between the next payment date and the last payment date is compared to the payment frequency specified in days. The payment frequency specified in days depends on the month the payment occurs. If these numbers are not equal, the interest cash flow is adjusted by the following ratio:

(next payment date - last payment date)/payment frequency in days

This adjustment holds true for all payments other than the final payment. For the final payment, the number of days between the maturity date and the last payment before the maturity date is compared to the payment frequency specified in days. The payment frequency specified in days depends on the month in which the maturity date occurs. If these numbers are not equal, the interest cash flow is adjusted by the following ratio:

(maturity date - last payment date)/payment frequency in days

2. Calculation of Current Payment for Patterns and Schedules

For amortization patterns, the payment amount can be defined independently for each payment date. Therefore, on each payment, the payment amount must be calculated according to the characteristics defined for that date. The payment amounts depends on the following factors:

Percent of Original Payment

You can choose to transfer price your product portfolio either in the Standard or in Remaining Term calculation mode. See: Transfer Pricing Process Rule and Calculation Modes, Oracle Transfer Pricing User Guide.

In the Standard calculation mode, the cash flow engine calculates the payment amount for each payment that falls between the last reprice date and the next reprice date (adjustable rate instruments) or between the origination date and maturity date (fixed rate instruments) by using the original payment from the instrument record and applying the pattern percent from the interface. The pattern percent is the percent of original payment specified in the interface for that payment.

In the Remaining Term calculation mode, the cash flow engine calculates the payment amount as follows:

On the first modeled payment on a detail instrument record, the amount in the current payment column is assumed to accurately represent the payment amount as of the next payment date. If this instrument record is partially sold, the current payment is multiplied by (100 - percent sold)/100 to get the net payment amount.

If this is the first payment made by a new business record, the payment amount is calculated using the original balance, original rate, and original number of payments.

On subsequent payment dates, the cash flow engine calculates the amount paid by multiplying the pattern percent by the amount in the original payment amount column, adjusted for percent sold, if applicable.

Percent of Current Payment

On the payment date, the cash flow engine determines the amount to be paid by first calculating a new payment according to the “active” characteristics, including the current balance, current rate, current payment frequency, and calculated remaining number of payments. The remaining number of payments is calculated by determining the amount of time remaining in the amortization term and dividing this term by the current payment frequency.

After the payment has been calculated, the pattern percent is applied.

Percent of Current Balance

Percent of Current Balance is applicable only for Level Principal payment patterns. On the first modeled payment, the amount in the current payment column is assumed to accurately represent the payment amount as of the next payment date. If the instrument is partially sold, the amount should be multiplied by (100 - percent sold)/100 to get the net payment amount. For all subsequent payments, the payment amount should be calculated at the time of payment by multiplying the outstanding balance by the pattern percent. However, for fixed rate instruments, modeling begins at the origination date, using the original balance. For adjustable rate instruments, modeling begins at the last reprice date, using the last reprice date balance.

Percent of Original Balance

Percent of Original Balance is applicable only for Level Principal payment patterns. On the first modeled payment, the amount in the current payment column is assumed to accurately represent the payment amount as of the next payment date. If the instrument is partially sold, the amount should be multiplied by (100 - percent sold)/100 to get the net payment amount.

For all subsequent payments, the payment amount should be calculated at the time of payment by multiplying the original balance, net of participations, by the pattern percent.

Absolute Value

On the first modeled payment, the amount in the current payment column is assumed to accurately represent the payment amount as of the next payment date. If the instrument is partially sold, the amount should be multiplied by (100 - percent sold)/100 to get the net payment amount.

For all subsequent payments, the absolute value amount from the pattern is used. If the instrument has a percent sold, the percent sold is applied to the absolute payment amount.

For standard transfer pricing, the absolute payment amount is used, adjusted for the participation percent.

Interest Only

On all interest only payments, the payment amount is calculated as the interest due on that date. No reference is made to the current payment column from the detail instrument record. Any payments in the current payment column are ignored.

3. Calculation of Principal Runoff

Principal runoff is a function of the amortization type of the instrument and the current payment. The current payment on a conventionally amortizing record represents the total principal and interest payment, while the current payment on a level principal record represents the principal portion of the total payment.

Simple Amortization

(code = 700, 802, and any Non-Amortizing Pattern Codes)

General case: Principal Runoff = 0

Interest Credited: -1 * interest cash flow gross

Conventional Amortization

(code = 100, 500, 600, 800, and any conventionally amortizing pattern codes)

Principal Runoff = current paymentm - interest cash flow gross

Level Principal Amortization

(code = 820, 801, and any level principal amortizing pattern codes)

Principal Runoff = current paymentm

Rule of 78 (code = 710)

Principal Runoff = current paymentm - interest cash flow gross

4. Performing Special Negative Amortization Check

If principal runoff is negative and the instrument record is adjustable negative amortization, then it must be ensured that the record is not exceeding negative amortization limits. As part of special negative amortization check, the cash flow engine verifies if the following condition holds true.

-1 * principal runoff + neg am balancem > neg am limitt /100 * original balancer

If this condition is true, the payment is not made. The payment is recalculated. See: Payment Event.

After the new payment has been calculated, the scheduled principal runoff is recalculated, based on the new payment information.

5. Identifying Maturity Date Case

If the payment date is also the maturity date, then the remaining balance must be paid off.

Principal At Maturity = Current Balancem - Scheduled Principal Runoff

6. Update of Current Balance

The current balance must be updated to reflect the principal portion of the payments and any interest credited.

Current Balancem = Current Balancem - Principal Runoff - Principal At Maturity + Interest Credited

7. Update of Remaining Number of Payments

After a payment has been made, the underlying information must be updated in preparation for the next event.

The remaining number of payments is reduced by 1. If remaining number of payments is zero, the modeling for this instrument is complete.

Remaining Paymentsm = Remaining Paymentsm - 1

8. Update of Next Payment Date

For standard amortization instruments, the next payment date is set equal to the current payment date plus the payment frequency.

Next payment datem = Current payment date + payment frequency

If an instrument has an amortization schedule, the next payment date is determined from the dates in the schedule table.

If an instrument has an amortization pattern, the next payment date is determined by incrementing the current payment date by the current payment frequency for relative patterns. For absolute patterns, the next payment date is determined by the next consecutive date in the pattern.

If the remaining number of payments is equal to 1, or the next payment date is greater than the maturity date, the next payment date is set equal to the maturity date.

Related Topics

Processing Modeling Events

Payment Event Steps for Interest-in-Advance Instruments

The following steps are applicable only to payment calculation for interest-in-advance records. Interest-in-advance instruments require their first payment to be made on the origination date. The last payment, made on the maturity date, is a principal only payment.

  1. Determination of New Current Payment on Schedules and Patterns

    See: Calculation of Current Payment for Patterns and Schedules.

  2. Calculation of Principal Runoff

    For interest-in-advance records, the principal runoff occurs before the interest cash flow is calculated. Because conventionally amortizing instruments cannot have interest-in-advance characteristics, amortizing interest-in-advance instruments are always level principal. Therefore, the principal runoff equals the current payment amount.

    For the payment on the maturity date, all remaining principal is also paid off.

  3. Update Of Current Balance

    Before calculating the interest cash flow, the current balance must be updated for the amount of principal runoff. If the payment is the maturity date, the balance is set to zero, and no further calculations are necessary.

  4. Calculation of Interest Cash Flow

    If the payment date is not the maturity date, an interest cash flow is made. The interest cash flow calculation for interest-in-advance instruments is similar to the interest in arrears calculation. The calculation differs in the count for number of days. Rather than counting from the last payment date to the current payment date, the number of days is counted from the current payment date to the next payment date.

  5. Update of Remaining Number of Payments

    After a payment has been made, the underlying data must be updated in preparation for the next event. The remaining number of payments is reduced by 1.

  6. Update Next Payment Date

    For standard amortization instruments, the next payment date is set equal to the current payment date plus the payment frequency.

    Next payment datem = Current payment date + payment frequency

    If the instrument has an amortization schedule, the next payment date is determined from the dates in the schedule table.

    If the instrument has an amortization pattern, the next payment date is determined by incrementing the current payment date by the current payment frequency for relative patterns. For absolute patterns, the next payment date is determined by the next consecutive date in the pattern.

    If the remaining number of payments is equal to 1, or the next payment date is greater than the maturity date, the next payment date is set equal to the maturity date.

Related Topics

Processing Modeling Events

Prepayment Event

The cash flow data for prepayment event has the following characteristics:

Static Information

Dynamic Information

Additional Assumption Information

Event Triggers

Related Topics

Processing Modeling Events

Prepayment Event Steps

The prepayment event comprises the following steps:

  1. Update of the Value of the Prepayment Dimensions

  2. Determination of the Base Annual Prepayment Rate

  3. Adjustment for Seasonality

  4. Selection of the Prepay in Full Option

  5. De-annualization of the Prepayment Option

  6. Adjustment of the Prepayment Rate for Stub or Extended Payments

  7. Determination of the Prepayment Amount

  8. Update of the Current Balance

  9. Application of the Prepayment Factor to Current Payment

1. Update of the Value of the Prepayment Dimensions

Depending on the prepayment assumptions for a product, values for the prepayment dimensions may need to be updated. The prepayment assumptions for the product are defined in a Prepayment rule, which is then selected for the current processing run.

If the prepayment method is Constant Rate, these updates are not necessary. If the prepayment method is Arctangent, only the rate ratio need be calculated. For Prepayment Table method, the required updates depend on the dimension within the table for the proper origination date range.

The possible prepayment dimensions are as follows:

Market Rate

The market rate is selected per product within the Prepayment rule. You must choose an interest rate code (IRC) from the list of IRCs contained in the active Historical Rates database. The chosen IRC provides the base value for the market rate.

Additionally, you must specify the term point you want to use for IRCs which are yield curves. There are three possible methods for you to select:

Coupon Rate

The coupon rate is the current gross rate of the instrument record (as of the current date in the forecast).

Rate Difference

The rate difference is the spread between the coupon rate and the market rate. Before calculating this dimension, the market rate must be retrieved.

Rate Difference = Coupon Rate - Market Rate

Rate Ratio

The rate ratio is the proportional difference between the coupon rate and the market rate. Before calculating this dimension, the market rate must be retrieved.

Rate Ratio = Coupon Rate/Market Rate

Original Term

The original term is retrieved from the original term of the instrument. If the original term is expressed in months, no conversion is necessary. Otherwise, the following calculations are applied:

Original Termmonths = ROUND((Original Termdays)/30.412)

Original Termmonths = Original Termyears*12

Reprice Frequency

The value for reprice frequency depends on the adjustable type code and the tease characteristics of the instrument data.

Remaining Term

The remaining term value represents the remaining number of months until maturity. The value is rounded to the nearest whole number of months.

Remaining Term = ROUND((Maturity Date - Current Date)/30.412)

Expired Term (Age)

The expired term represents the age of the instrument. It represents the time elapsed since the origination of the instrument. The value is rounded to the nearest whole number of months.

Expired Term = ROUND((Current Date - Origination Date)/30.412)

Term to Reprice

As with reprice frequency, the calculation of term to reprice depends on the adjustable type code and tease characteristics of the instrument characteristics.

2. Determination of the Base Annual Prepayment Rate

The method for determining the annual prepayment rate depends on the prepayment method.

Constant Rate

Constant prepayment rates can vary for different origination date ranges. The rate is determined by finding the proper range of origination dates and using the constant rate from this range.

Base Annual Prepayment Rate = Constant Rate

Arctangent

The arctangent formula describes the relationship between prepayments and the ratio of coupon rate to market rate. Four coefficients, to which you enter coefficients, define the shape of the curve. These coefficients can vary by origination date range.

Base Annual Prepayment (PP) Rate = Coeff1 - Coeff2 * ARCTANGENT(Coeff3* (Coeff4 - Rate Ratio))

The following graphic illustrates the base annual prepayment rate based on the arctangent formula.

the picture is described in the document text

Prepayment Table

Under the Prepayment Table method, a Prepayment Table rule is referenced within the Prepayment rule for a particular product and origination date range. This prepayment table may be factored by a coefficient to scale the prepayment rates which reside in the table up or down. The prepayment table factor is also defined per product, currency, and origination date.

The Prepayment Table rule contains a table of prepayment rates dimensioned by other characteristics. The Prepayment Table rule can hold a maximum of three dimensions. For each dimension, you can define the lookup method along that dimension, either range or interpolate.

Along each dimension of the table, range lookup or interpolation is performed to pinpoint the proper prepayment rate from the table. Once the prepayment rate is retrieved from the prepayment table, the prepayment table factor is applied to this rate.

Base Annual Prepayment Rate = PPTableFactor * PPTableLOOKUP(dimensionx, dimensiony, dimensionz)

3. Adjustment for Seasonality

For each prepayment method, seasonality factors can be applied to adjust the prepayment rate. The seasonality factors are defined per month. The month of the current date is used to determine the proper seasonality factor to use.

Annual Prepayment (PP) Rate = Seasonality Factor (Current Month) * Base Annual PP Rate

4. Selection of the Prepay in Full Option

If the adjusted final prepayment rate is equal to 100%, the instrument is paid off in full.

5. De-annualization of the Prepayment Option

The annual prepayment rate is adjusted to a rate per payment. The formula is as follows:

Prepay Factor = (1-(1- Annual PPRate)^(1/Payments per Year))

6. Adjustment of the Prepayment Rate for Stub or Extended Payments

The prepayment rate per payment is adjusted if the payment is a stub or extended payment. This adjustment is made in the same manner that interest cash flows are adjusted, as follows:

Adjusted prepay factor = Prepay Factor * (next payment date - last payment date) / (pmt frequency in days)

7. Determination of the Prepayment Amount

The amount of runoff due to prepayments is calculated. The prepay factor is applied to the current balance.

Prepay Runoff = Current Balance * Prepay Factor

8. Update of the Current Balance

The current balance must be reduced by the amount of prepay runoff.

Current Balance = Current Balance - Prepay Runoff

9. Application of the Prepayment Factor to Current Payment

An option exists in the Prepayment rule to reduce the payment proportionally to reflect the amount of principal that has been prepaid. If the prepayment treatment is Refinance, the current payment is reduced as follows:

Current Payment = Current Payment * (1 - Prepay Factor)

If the payment treatment is Curtailment, the current payment will remain constant, effectively reducing the term of the instrument.

Related Topics

Processing Modeling Events

Reprice Event

The cash flow data for the repricing event has the following characteristics:

Important: The modeling of an adjustable rate instrument begins at the last reprice date and ends at the next reprice date, with the next repricing date treated like a maturity date for the instrument. Therefore, no repricing events occur during a transfer pricing process.

Static Information:

Dynamic Information

Event Triggers

Detail Cash Flow Data

The following table describes detail cash flow data.

Tip: The values of the Event Use codes used in the table are as follows:

Detail Cash Flow Data
Column Name Column Description Column Type Event use
ID_NUMBER Unique identifier static I
LINE_ITEM_ID Dimension member value that determines the financial account type of detail instrument static I
ADJUSTABLE_TYPE_CODE Determines whether repricing occurs, and, if it occurs, whether it occurs according to reprice dates or bucket dates static R
ACCRUAL_BASIS_CODE Method of accrual used to determine the rate per payment static P
AMRT_TERM & AMRT_TERM_MULT Determines the time over which principal is amortized. Used in payment recalculation. static P, PC
AMRT_TYPE_CODE Determines the method for amortizing principal. Used to match to payment pattern data. static PC
CUR_PAYMENT Amount of current payment. Meaning depends on amortization type code. dynamic P, PC
CUR_PAR_BAL Balance on which principal runoff, interest cash flows, and deferred runoff are based dynamic P, PC, PP
CUR_NET_RATE Interest rate that the financial institution pays/receives dynamic P, R, PC, PP
CUR_GROSS_RATE Interest rate that the customer pays/receives. Used in determining payments and prepayments. dynamic P, R, PC, PP
DEFERRED_CUR_BAL Holds current unamortized premium, discount, fees, and costs dynamic D
ISSUE_DATE Date instrument is recognized as on-the-books   I
INT_TYPE_CODE Determines how interest is calculated and accrued static P
INSTRUMENT_TYPE_CODE Used to match a schedule instrument record to its scheduled payment dates and amounts static I
LAST_PAYMENT_DATE Date of last payment before the calendar period end date. Used to calculate days in first payment for interest in arrears instruments and to calculate accruals before the first payment in interest in advance instruments. static P
LRD_BALANCE Balance as of last reprice date static I
LAST_REPRICE_DATE Date instrument rate repriced last static I
MATURITY_DATE Date of final payment static P, PP
NEG_AMRT_AMT Amount of current balance due to negative amortization of interest payments dynamic P
NEG_AMRT_EQ_DATE Date an instrument fully re-amortizes, irrespective of payment caps event trigger PC
NEG_AMRT_EQ_FREQ &      
NEG_AMRT_EQ_MULT Frequency of negative amortization equalization events. 0 denotes negative amortization equalization never occurs. static PC
NEG_AMRT_LIMIT Maximum possible amount by which an instrument can negatively amortize. Stored as a percent of original balance. event trigger PC
NEXT_PAYMENT_DATE Date of next payment event trigger P, PC
NEXT_REPRICE_DATE Date of next rate change event trigger R, PP
ORG_PAYMENT_AMT Payment used for cash flow transfer pricing of fixed rate records. Used by pattern instruments to calculate payment amount. static PC,I
ORG_PAR_BAL Used in conjunction with negative amortization limit to determine the maximum amount that instrument can negatively amortize. Used for Rule of 78 schedules. Used by pattern instruments to calculate payment amount. static PC,I
ORG_TERM & ORG_TERM_MULT Time from origination date to maturity date. Used in determining whether an instrument balloons for payment recalculation purposes. static PC,PP
ORIGINATION_DATE Determines age of instrument for prepayments. Used in calculating remaining amortization term. Used in determining payment number in pattern records. static PP,PC
PERCENT_SOLD Determines net balance static I
PMT_ADJUST_DATE Date of next scheduled payment recalculation for negative amortization instruments event trigger PC
PMT_CHG_FREQ & PMT_CHG_FREQ_MULT Frequency of regular payment change calculation for negative amortization instruments only. 0 denotes that payment never changes. static PC
PMT_DECR_CYCLE Maximum possible percent decrease in payment from its previous value static PC
PMT_DECR_LIFE Minimum payment amount. Stored as a percent of original payment amount. Can be overwritten on negative amortization equalization dates. static PC
PMT_FREQ & PMT_FREQ_MULT Frequency of payments. Should be set equal to original term if the instrument is bullet requiring principal and interest to be paid at maturity date, or has the other asset, other liability, interest income, interest expense, non-interest income, or non-interest expense account type. static P, PC, PP
PMT_INCR_CYCLE Maximum possible percent increase in the value of a payment static PC
PMT_INCR_LIFE Maximum payment amount. Stored as a percent of original payment amount. Can be overwritten on negative amortization equalization dates. static PC
RATE_CAP_LIFE Maximum value to which current rate can reprice static R
RATE_CHG_MIN Minimum amount by which current rate must change before a rate change occurs static R
RATE_CHG_RND_CODE Type of rounding to be applied to current rate static R
RATE_CHG_RND_FAC Precision of rounding. 0 denotes no rounding. static R
RATE_DECR_CYCLE Maximum amount by which rate can decrease within a repricing period static R
RATE_FLOOR_LIFE Minimum value to which current rate can fall upon repricing static R
RATE_INCR_CYCLE Maximum amount by which rate can increase within a repricing period static R
RATE_SET_LAG & RATE_SET_LAG_MULT Time lag used when repricing. Used to determine rate set date on reprice event. static R
REMAIN_NO_PMTS Number of payments left to be made on an instrument from the calendar period end date to the maturity date dynamic P, PC
REPRICE_FREQ & REPRICE_FREQ_MULT Frequency by which an instrument reprices. 0 denotes fixed rate. static R, PP
ORG_PAYMENT_AMT Payment used for cash flow transfer pricing of fixed rate records static I
TEASER_END_DATE Date that a teased instrument begins repricing event trigger R, PP
NET_MARGIN_CODE Defines relationship between gross rate and net rate. 0 denotes floating net rate. 1 denotes constant net rate. static R

Related Topics

Overview of Cash Flow Calculations

Financial Element Calculations

The following table describes financial element calculations.

Tip: The Account Type Processing column of the table specifies for which account types financial elements are processed. The values of the codes used in the Account Type Processing column of the table are as follows:

Financial Element Calculations
Financial Element Description Financial Element Number Averaging Type Weighting Factor Account Type Processing
After Reprice Balance 255 At Last   DCF
After Reprice Gross Rate 290 At Last After Reprice Balance DCF
After Reprice Net Rate 300 At Last After Reprice Balance DCF
After Reprice Transfer Rate 310 At Last After Reprice Balance DCF
Average Balance 140 Daily Average   B, DCF
Average Gross Rate 150 Daily Average Average Balance DCF
Average Rem Term Transfer Rate 172      
Average Net Rate 160 Daily Average Average Balance DCF
Average Transfer Rate 170 Daily Average Average Balance DCF
Before Reprice Balance 250 At First   DCF
Before Reprice Gross Rate 260 At First Before Reprice Balance DCF
Before Reprice Net Rate 270 At First Before Reprice Balance DCF
Before Reprice Transfer Rate 280 At First Before Reprice Balance DCF
Beginning Balance 60 At First   B, DCF
Beginning Gross Rate 70 At First Beginning Balance DCF
Beginning Net Rate 80 At First Beginning Balance DCF
Beginning Transfer Rate 90 At First Beginning Balance DCF
Charge/Credit Rem Term 452      
Current Option Cost 173      
Current Option Cost Charge/Credit 453      
Deferred Average Balance 530 Daily Average   DCF
Deferred Ending Balance 520 At Last   DCF
Deferred Runoff 540 Accrual   DCF
Discount Rate 490 AVG_BY_DAYS_WTD   DCF
Ending Balance 100 At Last   B, DCF
Ending Gross Rate 110 At Last Ending Balance DCF
Ending Net Rate 120 At Last Ending Balance DCF
Ending Transfer Rate 130 At Last Ending Balance DCF
Fully Indexed Gross Rate 320 Sum   DCF
Fully Indexed Net Rate 330 Sum   DCF
Historic Option Cost 171      
Current Option Cost Charge/Credit 453      
Interest Accrual - Gross 445 Accrual   DCF, I
Interest Accrual - Net 440 Accrual   DCF, I
Interest Accrual - Transfer Rate 450 Accrual   DCF, I
Interest Cash Flow Gross 435 Sum   DCF, I
Interest Cash Flow Net 430 Sum   DCF, I
Interest Cash Flow Transfer Rate 437 Sum   DCF, I
Interest Credited 480 Sum   DCF
Lifetime Cap Balance 580 Daily Average   DCF
Lifetime Cap Effect 600 Accrual   DCF
Lifetime Cap Rate 590 Daily Average Lifetime Cap Balance DCF
New Add Balance 340 Sum   DCF
New Add Gross Rate 350 Sum New Add Balance DCF
New Add Net Rate 360 Sum New Add Balance DCF
New Add Transfer Rate 370 Sum New Add Balance DCF
NGAM Balance 640 Daily Average   DCF
NGAM Interest 650 Accrual   DCF
Non-Interest Income 455 Sum   N
Non-Interest Expense 457 Sum   N
Periodic Cap Balance 550 Daily Average   DCF
Periodic Cap Effect 570 Accrual   DCF
Periodic Cap Rate 560 Daily Average Periodic Cap Balance DCF
Prepay Balance 515 Sum   DCF
Prepay Rate (Annual) 510 Sum Prepay Balance DCF
Prepay Runoff 180 Sum   DCF
Prepay Runoff 182 Sum   DCF
Present Value of the Total Cash Flow 495 SUM   DCF
Present Value of the Transfer Rate Interest Cash Flow 497 SUM   DCF
Roll Add Balance 380 Sum   DCF
Roll Add Gross Rate 390 Sum   DCF
Roll Add Net Rate 400 Sum   DCF
Roll Add Transfer Rate 410 Sum   DCF
Scheduled Principal Runoff 190 Sum   DCF
Tease Balance 610 Daily Average   DCF
Tease Effect 630 Accrual   DCF
Tease Rate 620 Daily Average Tease Balance DCF
Timing of Prepay Runoff (positive) 181 Sum Prepay Runoff (positive) DCF
Prepay Runoff (negative) 182 Sum   DCF
Timing of Prepay Runoff (negative) 183 Sum Prepay Runoff (negative) DCF
Timing of Total Runoff (positive) 211 Sum Total Runoff (positive) DCF
Total Runoff (negative) 212 Sum   DCF
Timing of Total Runoff (negative 213 Sum Total Runoff (negative) DCF
Total Runoff 210 Sum   DCF
Total Runoff (negative) 212 Sum   DCF
Total Runoff Gross Rate 220 Sum Total Runoff DCF
Total Runoff Net Rate 230 Sum   DCF
Total Runoff Transfer Rate 240 Sum   DCF
Weighted Average Term 500 Sum Ending Balance DCF

Related Topics

Overview of Cash Flow Calculations

Example of the Rule of 78

The Rule of 78 denotes an approach used by banks to formulate a loan amortization schedule. Also known as The Rule of the Sum of the Digits, this method of computing unearned interest is used on installment loans with add-on interest. The number 78 is based on the sum of the digits from 1 to 12. This approach causes a borrower to pay more interest at the beginning of the loan when there is more money owed and less interest as the obligation is reduced.

This example of the Rule of 78 is based on a 12 month loan with current payment installment of $93.33 and original balance of $1,000.00.

  1. Sum all principal and interest payments made over the life of the instrument:

    ∑ Cash Flow

    = current payment * total number of payments

    = $93.33 * 12

    = $1,120.00

  2. Determine total amount of interest paid over the life of the instrument.

    ∑ Interest

    = ∑ cash flow - original par balance

    = $1,120.00 - $1,000.00

    = $120.00

  3. Sum the payment numbers.

    ∑ Payments

    = total num of payments * (total num of payments + 1)/2

    = 12 * 13/2

    = 78

  4. Calculate principal and interest amount at each payment.

    Interest = ∑ interest * (payments remaining/∑ payments)

    Principal = current payment - interest

    The following table describes the Rule of 78 calculations for this example.

    Rule of 78 Calculations
    Month Interest Calculation Interest Principal Calculation Principal Remaining Balance
    1 120 * 12/78 $18.46 93.33-18.46 $74.87 $925.13
    2 120 * 11/78 $16.92 93.33-16.92 $76.41 $848.72
    3 120 * 10/78 $15.38 93.33-15.38 $77.95 $770.77
    4 120 * 9/78 $13.85 93.33-13.85 $79.48 $691.29
    5 120 * 8/78 $12.31 93.33-12.31 $81.02 $610.27
    6 120 * 7/78 $10.77 93.33-10.77 $82.56 $527.71
    7 120 * 6/78 $9.23 93.33-9.23 $84.10 $443.61
    8 120 * 5/78 $7.69 93.33-7.69 $85.64 $357.97
    9 120 * 4/78 $6.15 93.33-6.15 $87.18 $270.79
    10 120 * 3/78 $4.61 93.33-4.61 $88.72 $182.07
    11 120 * 2/78 $3.08 93.33-3.08 $90.25 $91.82
    12 120 * 1/78 $1.54 93.33-1.54 $91.79 $0.00

Related Topics

Overview of Cash Flow Calculations