Cash Flow Dictionary

This chapter lists and describes the account table columns that store cash flow data and are accessed by Oracle Transfer Pricing during cash flow processing and edits.

The chapter also provides detailed information on how to correctly populate account table columns with instrument data, including column descriptions, usage, and recommended default values for the cash flow processing columns.

This chapter covers the following topics:

• Overview of Cash Flow Columns
• Cash Flow Column Descriptions

Overview of Cash Flow Columns

The cash flow columns of the account tables store cash flow related data for financial instruments.

Oracle Transfer Pricing accesses specific columns from account tables to perform cash flow processing to generate transfer pricing and option cost results. The application also accesses account table columns to perform cash flow edits. Cash flow edit rules validate and correct account table data used in cash flow processing. See: Overview of Cash Flow Edits Rules, Oracle Transfer Pricing User Guide.

The following table lists cash flow columns of account tables and provides information on whether they are associated with cash flow processing, cash flow edits, or both.

Cash Flow Columns

Column Name	Cash Flow Processing	Cash Flow Edits
ACCRUAL_BASIS_CODE	Yes	Yes
ADJUSTABLE_TYPE_CODE	Yes	Yes
All_DIMENSION_FIELDS	Yes	No
AMRT_TERM	Yes	Yes
AMRT_TERM_MULT	Yes	Yes
AMRT_TYPE_CODE	Yes	Yes
CALENDAR_PERIOD	Yes	Yes
COMPOUND_BASIS_CODE	Yes	Yes
CUR_BOOK_BAL	Yes	Yes
CUR_GROSS_RATE	Yes	Yes
CUR_NET_PAR_BAL	No	Yes
CUR_NET_RATE	Yes	Yes
CUR_PAR_BAL	Yes	Yes
CUR_PAYMENT	Yes	Yes
CUR_TP_PER_ADB	Yes	No
DEFERRED_CUR_BAL	Yes	Yes
DEFERRED_ORG_BAL	Yes	Yes
ID_NUMBER	Yes	Yes
INSTRUMENT_TYPE_CODE	Yes	No
INT_TYPE_CODE	Yes	Yes
INTEREST_RATE_CODE	Yes	Yes
ISSUE_DATE	Yes	Yes
LAST_PAYMENT_DATE	Yes	Yes
LAST_REPRICE_DATE	Yes	Yes
LRD_BALANCE	Yes	Yes
MARGIN	Yes	No
MARGIN_GROSS	Yes	No
MARGIN_T_RATE	Yes	No
MARKET_VALUE	Yes	No
MATCHED_SPREAD	Yes	No
MATURITY_DATE	Yes	Yes
NEG_AMRT_AMT	Yes	No
NEG_AMRT_EQ_DATE	Yes	Yes
NEG_AMRT_EQ_FREQ	Yes	Yes
NEG_AMRT_EQ_MULT	Yes	Yes
NEG_AMRT_LIMIT	Yes	Yes
NET_MARGIN_CODE	Yes	Yes
NEXT_PAYMENT_DATE	Yes	Yes
NEXT_REPRICE_DATE	Yes	Yes
ORG_BOOK_BAL	No	Yes
ORG_PAR_BAL	Yes	Yes
ORG_PAYMENT_AMT	Yes	Yes
ORG_TERM	Yes	Yes
ORG_TERM_MULT	Yes	Yes
ORIGINATION_DATE	Yes	Yes
PERCENT_SOLD	Yes	Yes
PMT_ADJUST_DATE	Yes	Yes
PMT_CHG_FREQ	Yes	Yes
PMT_CHG_FREQ_MULT	Yes	Yes
PMT_DECR_CYCLE	Yes	Yes
PMT_DECR_LIFE	Yes	Yes
PMT_FREQ	Yes	Yes
PMT_FREQ_MULT	Yes	Yes
PMT_INCR_CYCLE	Yes	Yes
PMT_INCR_LIFE	Yes	Yes
PRIOR_TP_PER_ADB	Yes	No
PMT_SET_LAG	No	Yes
PMT_SET_LAG_MULT	No	Yes
RATE_CAP_LIFE	Yes	Yes
RATE_CHG_MIN	Yes	Yes
RATE_CHG_RND_CODE	Yes	Yes
RATE_CHG_RND_FAC	Yes	Yes
RATE_DECR_CYCLE	Yes	Yes
RATE_DECR_LIFE	Yes	Yes
RATE_FLOOR_LIFE	Yes	Yes
RATE_INCR_CYCLE	Yes	Yes
RATE_INCR_LIFE	Yes	Yes
RATE_SET_LAG	Yes	Yes
RATE_SET_LAG_MULT	Yes	Yes
REMAIN_NO_PMTS	Yes	Yes
REMAIN_TERM_MULT	No	Yes
REPRICE_FREQ	Yes	Yes
REPRICE_FREQ_MULT	Yes	Yes
T_RATE_INT_RATE_CODE	Yes	Yes
TEASER_END_DATE	Yes	Yes
TRAN_RATE_REM_TERM	Yes	No
TRANSFER_RATE	Yes	No

Cash Flow Column Descriptions

The account table data must be clean, complete, and appropriate for Oracle Transfer Pricing to perform cash flow processing and generate accurate transfer pricing and option cost results. Although Cash Flow Edit rules clean and prepare account table data, they cannot ensure that the account table columns are populated with appropriate data that reflect business realities.

Consequently, you need the following information on correct data population of cash flow columns:

• Column name as it appears in the database (in upper case with underscores).

• Definition of the column.

• Usage in Oracle Financial Services (OFS) applications such as Oracle Transfer Pricing.

• Formulas used in the cash flow calculations.

• Data verification requirements and suggested defaults.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Accrual Basis Code (ACCRUAL_BASIS_CODE)

Definition

The basis on which the cash flow engine calculates interest accrual.

Module Usage

Oracle Transfer Pricing cash flow methodologies use ACCRUAL_BASIS_CODE for calculating interest income (financial element 430).

The following table illustrates the accrual bases and the corresponding codes, available for use by Oracle Transfer Pricing.

Accrual Bases and Corresponding Codes

Code Value	Accrual Basis
1	30/360
2	30/365
3	30/ACT
5	ACT/360
6	ACT/365
7	ACT/ACT

Oracle Transfer Pricing cash flow methodologies reference INT_TYPE_CODE in determining whether interest payments are made in arrears or in advance.

If INT_TYPE_CODE = 1, the record is considered interest in arrears. For such a record, interest payments are paid at the end of the payment period along with the principal payments. The calculations detailed below assume that the interest is to be calculated as interest in arrears.

If INT_TYPE_CODE = 2, the record is considered interest in advance. For a description of the formula used to calculate interest in advance, see: Interest Type Code (INT_TYPE_CODE).

For calculation purposes, the accrual basis codes can be grouped in the following manner. Note that the calculations below assume a monthly payment frequency.

1. If the ACCRUAL_BASIS_CODE is 30/360, 30/365 or 30/Actual, the cash flow engine uses the following formula to calculate interest income on a payment date:

   Previous Periods Ending Balance * Cur Net Rate/100 * PMT_FREQ [number of months] * x * (Next Payment Date - Last Payment Date)/(Next Payment Date - Calculated Last Payment Date)

   Replace x with one of the three accrual basis values from above. Note that the actual denominator refers to the actual number of days in the year. Other than leap years, this equals 365 days. Also note that the Calculated Last Payment Date is the Next Payment Date rolled back by the number of months in PMT_FREQ.

   The final portion of the above calculation,

   (Next Payment Date - Last Payment Date)/(Next Payment Date Calculated Last Payment Date)

   is a ratio that calculates the percentage of the payment frequency period that should be applied to calculate the Interest Income amount. This adjustment is necessary because the Last Payment Date is not necessarily equal to the Calculated Last Payment Date for the first forecasted payment. This would be the case of a stub or extended payment at the origination or maturity of a record.

   If the Last Payment Date is precisely equal to the Calculated Last Payment Date, then the ratio will be equal to 1 and, therefore, will not impact the Interest Income calculation.

2. If the ACCRUAL_BASIS_CODE is Actual/365, Actual/Actual, or Actual/360, the cash flow engine uses the following formula to calculate interest income on a payment date:

   Previous Periods Ending Balance * Cur Net Rate/100 * (Next Payment Date - Last Payment Date)/y

   Replace y with the denominator of one of the three accrual bases values from above. Note the actual numerator refers to the actual number of days in the current month.

   The above two equations represent Interest in Arrears income calculations. For the interest in advance calculations, see: Interest Type Code (INT_TYPE_CODE).

   Note: If a compounding method has been chosen, the cash flow engine derives the compounded rate before calculating the interest income amounts. See Compounding Basis Code (COMPOUND_BASIS_CODE).

Data Verification Requirements and Suggested Defaults

• Must be equal to values 1, 2, 3, 5, 6, or 7.

• Suggested default depends on product characteristics of institution's data; default to the most common ACCRUAL_BASIS_CODE for the product.

• If AMRT_TYPE_CODE = 800, 801, or 802 (Schedule) or 1000 to 29999 (Pattern), the ACCRUAL_BASIS_CODE cannot equal 1, 2, or 3.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Adjustable Type Code (ADJUSTABLE_TYPE_CODE)

Definition

Identifies the repricing method and repricing characteristics of a record.

Module Usage

Oracle Transfer Pricing uses ADJUSTABLE_TYPE_CODE in conjunction with RERPICE_FREQ to determine the repricing characteristics of an instrument during Option Cost processing. Oracle Transfer Pricing does not use Adjustable Type Code for Standard Transfer Rate processing.

1. The following table describes the code values for this column:

   Adjustable Type Code Values

   Code Value	Definition	Repricing Frequency	Repricing Method
   000	Fixed	0	No Repricing
   030	Administered Rate	> 0	Reprices when IRC (interest rate code) changes.*
   050	Floating Rate	> 0	Reprices when IRC (interest rate code) changes.*
   250	Adjustable	> 0	Last Reprice Date + Reprice Frequency.*
   500-998	Repricing Pattern	>0	Based on pattern definition

   * If not in tease period.

   1. If the ADJUSTABLE_TYPE_CODE = 0 and the REPRICE_FREQ = 0, then the record is fixed-rate.

   2. If the ADJUSTABLE_TYPE_CODE = 30 or 50 and the REPRICE_FREQ > 0, then the reprice dates are driven by forecasted yield curve rate changes based on the Monte Carlo rates rather than by the REPRICE_FREQ. For these codes, the cash flow engine reprices the record by referencing the interest rate code (IRC) defined on the instrument when producing cash flow information at the beginning of each period. There is one reference to the IRC for each payment period.

      The database field, NEXT_REPRICE_DATE, is not used when the ADJUSTABLE_TYPE_CODE = 30 or 50. The database field, REPRICE_FREQ, is used to determine the yield curve point when the IRC is a yield curve as opposed to a single rate IRC.

      Note: Floating/Administered ADJUSTABLE_TYPE_CODE should not be used for instruments with periodic caps or floors since periodic caps and floors imply a specific repricing frequency.

   3. If the ADJUSTABLE_TYPE_CODE = 250 and the REPRICE_FREQ > 0, then the repricing frequency of the record is determined by the REPRICE_FREQ and NEXT_REPRICE_DATE. See these columns for further explanations of the repricing process.

2. When calculating Transfer Rates, the value input into the REPRICE_FREQ overrides the ADJUSTABLE_TYPE_CODE value. For instance, even though the ADJUSTABLE_TYPE_CODE > 0, if the REPRICE_FREQ = 0, the cash flow engine treats the record as a fixed-rate instrument.

   Note: Oracle Transfer Pricing references REPRICE_FREQ to determine if the record is adjustable.

500-998: User-Defined Repricing Patterns

Records with this range of ADJUSTABLE_TYPE_CODEs are matched to the user-defined repricing pattern in the Repricing Pattern interface. The key for matching is the ADJUSTABLE_TYPE_CODE value.

Data Verification Requirements and Suggested Defaults

• If the record is an adjustable floating or administered product, ADJUSTABLE_TYPE_CODE = 30 or 50.

• If the record reprices according to NEXT_REPRICE_DATE and REPRICE_FREQ information, ADJUSTABLE_TYPE_CODE = 250.

• If the ADJUSTABLE_TYPE_CODE > 0, REPRICE_FREQ > 0.

• If the record is fixed, ADJUSTABLE_TYPE_CODE = 0.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Amortization Type Code (AMRT_TYPE_CODE)

Definition

Defines the method by which the principal and interest of an account are amortized.

Module Usage

Oracle Transfer Pricing cash flow methodologies use AMRT_TYPE_CODE to determine the calculation method for the amortization of principal and interest of a record. The following table describes the AMRT_TYPE_CODE values.

Amortization Type Code Values for Conventional Amortizing Instruments

Amortization Type Code	Conventional Amortizing
100	Conventional Fixed
400	Balloon
500	Adjustable Conventional
600	Adjustable Negative Amortizing

Amortization Type Code Values for Non-conventional Amortizing Instruments

Amortization Type Code	Non-conventional Amortizing
700	Simple Interest
710	Rule of 78
800 - 802	Payment Schedules
820	Level Principal
999	Default Value
1000 -29999	User-Defined Payment Patterns

100, 400, 500, 600 - Conventionally Amortizing AMRT_TYPE_CODEs

The following graphic illustrates the amortization type of conventionally amortizing instruments.

The conventional amortization loan types have loan payments that are unevenly divided between principal balance and interest owed. Total payment amount (principal + interest) is generally equal throughout the life of the loan. The interest portion (non-shaded portion) of each payment is calculated based on the interest rate of the record and the remaining balance of the loan. Therefore, close to the loan origination, a higher portion of the payment consists of interest rather than principal. As the loan is paid, an increasing portion of each payment is allocated to principal until a zero balance is reached at maturity.

For these four AMRT_TYPE_CODEs, the amount in the CUR_PAYMENT field should equal principal and interest.

The following table describes the four conventionally amortizing amortization type codes:

Description of Conventionally Amortizing Amortization Type Codes

Conventional Loan Type	Description
100 Conventional Fixed	(Described above)
400 Balloon	A loan in which the amortization term (AMRT_TERM) of an instrument exceeds the maturity term (ORG_TERM). For example a loan with an original term of seven years is amortized conventionally as if it were a 30-year instrument. At the end of the 7th year, there exists a large balloon payment that represents 23 years of non-amortized loan balance.
500 Conventional Adjustable	Repricing instrument with conventional amortization.
600 Adjustable Negative Amortizing	For a negatively amortizing instrument, the principal of a loan increases when the loan payments are insufficient to pay the interest due. The unpaid interest is added to the outstanding loan balance, causing the principal to increase rather than decrease, as payments are made. See Negative Amortization Amount (NEG_AMRT_AMT).

Note that the cash flow engine does not treat AMRT_TYPE_CODE 100, 400 or 500 differently. For a given record, the use of any of these three types produces identical results. The division is simply for product distinction purposes. For instance, AMRT_TYPE_CODE 100 can be used for a fixed-rate, adjustable-rate or a balloon record. However, only a record with an amortization type code of 600 can utilize the negative amortization fields.

• The cash flow engine does not use AMRT_TYPE_CODE to identify whether a record is adjustable or not. The cash flow engine uses REPRICE_FREQ for this purpose. Therefore, any amortization type can be adjustable.

• The cash flow engine does not use AMRT_TYPE_CODE to determine whether a record is a balloon or not. The cash flow engine uses AMRT_TERM and ORG_TERM for this purpose. Therefore, even a level principal AMRT_TYPE_CODE could be treated as a balloon instrument.

• A record must have the AMRT_TYPE_CODE 600 in order for the cash flow engine to process the record using the negative amortization fields.

700 Simple Interest (Non-amortizing)

The following graphic illustrates the Simple Interest amortization type.

For simple interest amortization type, no principal is paid until maturity. If NEXT_PAYMENT_DATE < MATURITY_DATE, the cash flow engine calculates interim interest-only payments as shown in the above diagram. The cash flow engine pays the entire principal balance for the record on the maturity date along with the appropriate interest amount.

For this AMRT_TYPE_CODE, the CUR_PAYMENT field should equal 0.

710: The Rule of 78

An amortization type in which the following calculation is used for computing the interest rebated when a borrower pays off a loan before maturity.

For example, in a 12-month loan, the total is 78 (1 + 2 + ... 12 = 78). For the first month, 12/78 of the total interest is due. In the second month, this amount is 11/78 of the total.

For Rule of 78 AMRT_TYPE_CODEs, the amount in the CUR_PAYMENT field should equal principal plus interest. See Overview of Cash Flow Calculations.

800 - 802: Payment Schedule

The cash flow engine matches an instrument record with its corresponding payment schedule record based on a combination of INSTRUMENT_TYPE_CODE and ID_NUMBER values.

• 800: Conventional Payment Schedule

  This AMRT_TYPE_CODE conventionally amortizes a record whose cash flows are defined in the PAYMENT_SCHEDULE table. Payment amounts contain both principal and interest.

• 801: Level Principal Payment Schedule

  This AMRT_TYPE_CODE amortizes a record whose cash flows are defined in the PAYMENT_SCHEDULE table. Payment amounts contain principal only.

• 802: Simple Interest Payment Schedule

  This AMRT_TYPE_CODE amortizes a record whose cash flow dates are defined in the PAYMENT_SCHEDULE table. Payment amounts equal 0 (the cash flow engine calculates interest and ignores payment amount in the schedule records). Principal balance is paid on the maturity date as defined in the schedule.

820 Level Principal Payments

The following graphic illustrates the Level Principal amortization type.

Level principal payment is the amortization type in which the principal portion of the loan payment remains constant for the life of loan. Interest (non-shaded portion) is calculated as a percentage of the remaining balance, and therefore, the interest portion decreases as the maturity date nears. Since the principal portion of payment is constant for life, the total payment amount (principal + interest) decreases as the loan approaches maturity.

For this amortization type code, the amount in the CUR_PAYMENT column should equal the principal portion only.

1000 - 29999: User-Defined Payment Patterns

Records with amortization type codes in this range are matched to the user-defined amortizations in the payment pattern interface. The key for matching is the AMRT_TYPE_CODE value. These records can only be defined as conventionally amortizing, level-principal, or simple interest.

999: Other Amortization Type

If this value is used, the payment pattern uses the AMRT_TYPE_CODE 700, simple interest amortization method. Using this AMRT_TYPE_CODE for product identification purposes is not recommended. This should be reserved for indicating erroneous data extraction.

Note: This code is only used for Cash Flow Edits error handling. The Cash Flow Edits rule uses this code as a default value, and the calculation engine treats it as Amortization Type Code 700 (Simple Interest).

For calculation methods of the different AMRT_TYPE_CODEs, see: Current Payment (CUR_PAYMENT).

Data Verification Requirements and Suggested Defaults

• All accounts require a valid AMRT_TYPE_CODE.

• If the AMRT_TYPE <> 700 or is not a simple interest-amortizing schedule or pattern record, CUR_PAYMENT must be valid. If CUR_PAYMENT value is too small or equal to 0, the cash flow engine may generate erroneous cash flows, depending on the AMRT_TYPE_CODE selected.

• If the record is defaulted to AMRT_TYPE_CODE 999, or if the cash flow engine cannot find a match in PAYMENT_SCHEDULE or PAYMENT_PATTERNS, the cash flow engine processes record as AMRT_TYPE_CODE 700.

• Suggested defaults are dependent on basic knowledge of product characteristics. The following table describes the suggested defaults:

  Default Amortization Type Codes

  Suggested Loan Type	AMRT_TYPE_CODE
  Non-amortizing, such as Certificates of Deposit	700
  Fixed amortizing, such as short term consumer loans	100
  Variable amortizing, such as adjustable-rate mortgages	500

• The Rule of 78 instruments are implicitly fixed.

  If AMRT_TYPE_CODE = 710, REPRICE_FREQ = 0.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Amortization Term (AMRT_TERM)

Definition

Amortization term is used in conjunction with amortization term multiplier (AMRT_TERM_MULT) to define the term over which the payment is amortized.

Module Usage

AMRT_TERM is used by Oracle Transfer Pricing for adjustable rate instruments when calculating option costs.

Amortization Term

Amortization term has two main purposes:

• Identifies whether a record is a balloon and is used in calculation of payment amounts.

• Used when recalculating payment amounts for User-Defined Payment Pattern records that are defined as % Current Payment and have more than one payment frequency defined in the Payment Pattern interface.

Balloon Check

As an initial step before processing cash flows, the cash flow engine compares the ORG_TERM of a record with its AMRT_TERM. If AMRT_TERM = ORG_TERM, then the cash flow engine uses the CUR_PAYMENT from the record. The cash flow engine later recalculates the CUR_PAYMENT if:

• The record reprices.

• The TEASER_END_DATE is reached.

• A negative amortization-related recalculation date is reached.

If the AMRT_TERM > ORG_TERM, the cash flow engine recognizes the record as a balloon, and recalculates the payment amount. In order to perform this calculation, the cash flow engine must derive the remaining number of payments until the end of the amortization term. See: Current Payment (CUR_PAYMENT).

The remaining number of payments is calculated by adding the AMRT_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 uses the following formula to determine the remaining number of payments:

(((ORIGINATION_DATE - Beginning of Payment Period Date) / 30.41667 + AMRT_TERM) / PMT_FREQ)

In the formula, the Beginning of Payment Period Date refers to the date of the current payment that the cash flow engine is calculating. This would equal the NEXT_PAYMENT_DATE for the detail record if the cash flow engine were calculating the first forecasted cash flow. After the remaining number of payments are calculated, the cash flow engine derives the CUR_PAYMENT amount and applies it to the cash flows for the record. In the absence of repricing and other recalculation events, this payment amount is paid until maturity, at which time, the cash flow engine applies the balloon payment (the remaining principal portion) for the record.

User-Defined Pattern

Records that are defined as % Current Payment in the User-Defined Payment Pattern screen and have more than one payment frequency defined in the payment pattern interface also recalculate the payment amount using the same formula.

The remaining number of payments on pattern records is calculated by rounding to the nearest number of payments when the remaining term is not exactly divisible by the payment frequency.

Data Verification Requirements and Suggested Defaults

• If the record is a balloon, AMRT_TERM > ORG_TERM.

• If the record is not a balloon, AMRT_TERM = ORG_TERM.

• AMRT_TERM should never be less than ORG_TERM.

• Do not default AMRT_TERM or ORG_TERM to 0. Use 1.

• The validation of AMRT_TERM should always be done in conjunction with AMRT_TERM_MULT.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Amortization Term Multiplier (AMRT_TERM_MULT)

Definition

Used in conjunction with amortization term (AMRT_TERM) to define the term over which the payment is amortized.

Module Usage

This column is the multiplier of the AMRT_TERM column. It is used in conjunction with AMRT_TERM to define the term over which the payment is amortized. Oracle Transfer Pricing cash flow transfer-priced records reference AMRT_TERM_MULT when recalculating the current payment as defined in the AMRT_TERM column. AMRT_TERM_MULT determines the units (months, days or years) of AMRT_TERM.

Data Verification Requirements and Suggested Defaults

Values are:

D = Days

M = Months

Y = Years

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Calendar Period End Date (CAL_PERIOD_ID)

Definition

Although the CAL_PERIOD_ID generally encompasses a range of dates, in the context of Oracle Transfer Pricing it refers to the Calendar Period End Date. Calendar Period End Date is the date that the extracted data represents. It is equivalent to the As of Date column in the v4.5 of Oracle Financial Services (OFS) applications.

Module Usage

CAL_PERIOD_ID is used for the following purposes:

• As a filter to identify instrument records to include in the current process.

• Transfer Pricing Remaining Term Pricing Basis.

User Preferences

Oracle Transfer Pricing uses the CAL_PERIOD_ID as a primary data filter. When executing a transfer pricing process run, the cash flow engine compares the Calendar Period defined as a Transfer Pricing Process rule run time parameter against the CAL_PERIOD_ID field of the detail account table record. If CAL_PERIOD_ID from the account table record is the same date as that from the run time parameter selection, then the cash flow engine processes the account table record. Otherwise, the cash flow engine ignores the account table record.

Transfer Pricing in Remaining Term Calculation Mode

When the Remaining Term calculation mode is selected on the Transfer Pricing rule run page, the transfer rates for the relevant methodologies are calculated from the Calendar Period date.

Data Verification Requirements and Suggested Defaults

Unless the record has a future ORIGINATION_DATE, the following conditions exist:

• CALENDAR_PERIOD = MATURITY_DATE - REMAIN TERM C.

• CALENDAR_PERIOD < NEXT_REPRICE_DATE

• CALENDAR_PERIOD < NEXT_PAYMENT_DATE

• CALENDAR_PERIOD < MATURITY_DATE

• CALENDAR_PERIOD >= ORIGINATION_DATE

• CALENDAR_PERIOD >= ISSUE_DATE

• CALENDAR_PERIOD < PMT_ADJUST_DATE

• CALENDAR_PERIOD > LAST_PAYMENT_DATE

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Compounding Basis Code (COMPOUND_BASIS_CODE)

Definition

Indicates the compounding used to calculate interest income.

Module Usage

Oracle Transfer Pricing cash flow calculations reference the COMPOUND_BASIS_CODE when determining the detail records compounding method to be applied during interest income (financial element 430) calculations.

1. The following table shows the available code values for the COMPOUND_BASIS_CODE and the interest calculation logic for an annual-paying instrument with 30/360 accrual basis code.

   Compounding Basis Codes: Descriptions and Annual Payment Calculations

   Code Value	Description	Annual Payment Calculation
   110	Daily	Balance * [(1 + Rate/365)^365-1]
   120	Monthly	Balance * [(1 + Rate/12)^12-1]
   130	Quarterly	Balance * [(1 + Rate/4)^4-1]
   140	Semiannual	Balance * [(1 + Rate/2)^2-1]
   150	Annual	Balance * [(1 + Rate/1)^1-1]
   160	Simple	Balance * Rate (no compounding)
   170	Continuous	eRate Per Payment -1
   200	At Maturity	Balance * Rate (no compounding)
   999	Other	Balance * Rate (no compounding)

   The annualized rate that is applied to the record for interest income calculations is compounded according to one of the methods listed in this table.

2. The cash flow engine compounds the rate on the record at the time of interest income calculation. If the record has repriced during option cost processing, the cash flow engine calculates the new rate, applies rounding, caps/floors, or tease periods, if any are required, and then applies the compounding calculation (COMPOUND_BASIS_CODE) before calculating interest income (financial element 430).

3. Simple and At Maturity calculate interest in the same manner. These two codes do not compound the rate.

4. Compounded interest is only calculated when the compounding frequency is less than the PMT_FREQ. If the compounding frequency is greater than the PMT_FREQ, the model assumes simple compounding.

Data Verification Requirements and Suggested Defaults

• A valid COMPOUND_BASIS_CODE; must be one of the values listed in the Compounding Basis Codes table.

• Suggested default - if the records compounding is unknown, default to COMPOUND_BASIS_CODE = 160, Simple.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Current Book Balance (CUR_BOOK_BAL)

Definition

Current Gross Book Balance.

Module Usage

Oracle Transfer Pricing uses CUR_BOOK_BAL in calculations for FEM_BALANCES based transfer pricing and for Charge/Credit migration processing when the Remaining Term calculation mode is selected in the Transfer Pricing Process rule.

Note: The calculation for FEM_BALANCES based transfer pricing figures the current book balance net of participations.

Data Verification Requirements and Suggested Defaults

Validate that CUR_BOOK_BAL = CUR_PAR_BAL + DEFERRED_CUR_BAL.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Current Gross Rate (CUR_GROSS_RATE)

Definition

Coupon rate of account, expressed in terms of an annualized rate.

Module Usage

When the Model with Gross Rates option is selected while setting the Transfer Pricing rule and Remaining Term calculation mode is selected on the Transfer Pricing Process rule, CUR_GROSS_RATE is used by the cash flow engine. When this option is selected, the cash flow engine uses the CUR_GROSS_RATE of the records for the following two calculations:

Amortization

When conventionally amortizing a record's balance with the Model with Gross Rates option selected, the cash flow engine uses the CUR_GROSS_RATE as the customer rate. If the option is not selected, then the cash flow engine uses CUR_NET_RATE as the customer rate for amortization calculation.

Prepayments

To determine the prepayment rate, the current customer rate must be compared to the market rate. If the Model with Gross Rates option is selected, then the customer rate is represented by the CUR_GROSS_RATE. If the Model with Gross Rates option is not selected, the CUR_NET_RATE is used as the current customer rate.

If Model with Gross Rates is selected, the cash flow engine uses the CUR_GROSS_RATE for gross interest cash flow (financial element 435) calculations. This means that the record amortizes and prepays according to the CUR_GROSS_RATE, but the net cash flows associated interest income (financial element 430) is calculated from the CUR_NET_RATE.

Note: Depending on the NET_MARGIN_CODE value, interest income is calculated differently.

For a complete explanation of the relationship between NET_MARGIN_CODE, CUR_GROSS_RATE, and CUR_NET_RATE, see: Net Margin Code (NET_MARGIN_CODE).

Data Verification Requirements and Suggested Defaults

• All term accounts require a valid CUR_GROSS_RATE.

• For non-interest earning/bearing accounts, CUR_GROSS_RATE = 0.

• For transaction accounts where the rate changes daily, based upon average balances, CUR_GROSS_RATE should be the spot rate at the time the extract program is run.

• CUR_GROSS_RATE >= 0.

• CUR_GROSS_RATE = MARGIN_GROSS + value of index (IRC) that the account is tied to (assuming periodic/lifetime caps/floors, tease periods do not apply and rounding is taken into consideration).

• CUR_GROSS_RATE should be validated while validating CUR_PAYMENT. For validation formulas, see: Current Payment (CUR_PAYMENT).

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Current Net Rate (CUR_NET_RATE)

Definition

Interest rate on which interest income due to the bank is based.

Module Usage

When the Remaining Term calculation mode is selected on the Transfer Pricing Process rule run page, Oracle Transfer Pricing cash flow calculations reference CUR_NET_RATE for the following purposes:

Interest Income (Financial Element 430) Calculation

CUR_NET_RATE is used to derive the interest cash flow (income/expense) that is due to the financial institution (referred to as net). The cash flow engine uses different interest income calculations depending on the ACCRUAL_BASIS_CODE and INT_TYPE. These calculations are presented under the Accrual Basis Code (ACCRUAL_BASIS_CODE) and Interest Type Code (INT_TYPE_CODE). Interest income is calculated on payment dates or the records maturity date. As the calculations indicate, after referencing the ACCRUAL_BASIS_CODE, the cash flow engine applies the CUR_NET_RATE to the entire payment period (last Previous payment date to next Current payment date). If any repricing occurred during the payment period, the cash flow engine uses the last repriced rate that occurred immediately before the next Current payment date.

Prepayments

As defined in the Prepayment rule interface, the cash flow engine compares the customer rate to the market rate when determining the prepayment rate. If the Model with Gross Rates option is not selected, the CUR_NET_RATE is the customer rate and therefore is used for prepayment calculations.

Amortization

When amortizing the balance of a record, a key input is customer rate for the record. If the Model with Gross Rates options is not selected, then the cash flow engine uses the CUR_NET_RATE for amortization purposes.

Note: Depending on the NET_MARGIN_CODE value, interest income is calculated differently. For a complete explanation of the relationship between NET_MARGIN_CODE, CUR_GROSS_RATE, and CUR_NET_RATE, see: Net Margin Code (NET_MARGIN_CODE).

Data Verification Requirements and Suggested Defaults

• All term accounts require a valid CUR_NET_RATE.

• For non-interest earning/bearing accounts, CUR_NET_RATE = 0.

• For transaction accounts where the rate changes daily based upon average balances, CUR_NET_RATE should be the spot rate at the time the extract program is run.

• For interest-bearing accounts, CUR_NET_RATE >= 0.

• CUR_NET_RATE = MARGIN + value of index that the account is tied to (assuming periodic/lifetime caps/floors do not apply and rounding is taken into consideration).

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Current Option-Adjusted Spread (CUR_OAS)

Definition

The average spread over all stochastic rate paths that equate the discounted sum of future cash flows to the target balance at the Calendar Period date.

Module Usage

When the Remaining Term calculation mode is selected in the Transfer Pricing Process Rule, the Oracle Transfer Pricing option cost process writes the result of its option-adjusted spread calculations to this column.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Current Par Balance (CUR_PAR_BAL)

Definition

Represents the starting balance from which remaining term cash flows are generated.

Module Usage

Oracle Transfer Pricing Cash Flow Remaining Term Pricing Basis methodologies use the CUR_PAR_BAL field to derive the starting balance for amortization calculations. For amortizing accounts, the cash flow engine amortizes the Current Par Balance (CUR_PAR_BAL) over the remaining number of payments.

1. For the cash flow Remaining Term Pricing Basis methodologies in Oracle Transfer Pricing, as the cash flow engine processes the payment dates and the maturity date for the record, the CUR_PAR_BAL is reduced by the principal portion of the CUR_PAYMENT amount until the principal balance reaches 0. Once the balance has been reduced to 0, processing of the record ceases. The calculation method that defines how the CUR_PAR_BAL amount is reduced is represented by the AMRT_TYPE_CODE and the CUR_PAYMENT fields.

2. For User-Defined Payment Patterns where the payment method is defined as “% Current Balance”, Oracle Transfer Pricing references the CUR_PAR_BAL column for all payment amounts including the first one.

Data Verification Requirements and Suggested Defaults

• CUR_PAR_BAL requires a valid balance for all accounts. If CUR_PAR_BAL = 0, the Cash Flow Engine will not process the record.

• CUR_PAR_BAL = CUR_BOOK_BAL - DEFERRED_CUR_BAL

• CUR_PAR_BAL should have the same sign as CUR_PAYMENT.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Current Payment (CUR_PAYMENT)

Definition

Represents the current periodic payment made to repay the outstanding balance.

Module Usage

For standard amortization types (those that are not nonpatterned and nonscheduled), Oracle Transfer Pricing (remaining term methods) uses the CUR_PAYMENT from the detail record for the life of the record until a payment recalculation occurs. A payment recalculation occurs when the record is an:

• Adjustable record and a reprice date (NEXT_REPRICE_DATE) is reached.

• Adjustable record and the TEASER_END_DATE is reached (note that if TEASER_END_DATE < NEXT_REPRICE_DATE, TEASER_END_DATE takes precedence).

• AMRT_TYPE = 600 and the PMT_ADJUST_DATE, NEG_AMRT_EQ_DATE, or the NEG_AMRT_LIMIT is reached.

Depending on AMRT_TYPE_CODE, CUR_PAYMENT may be composed of principal or interest or both.

AMRT_TYPE_CODE 700 (Simple Interest):

CUR_PAYMENT equals interest only. The cash flow engine always calculates the interest component of any payment amount. Therefore, for extracting purposes, for a simple interest record CUR_PAYMENT = 0.

AMRT_TYPE_CODE 100, 400, 500, 600 (Conventionally Amortizing):

For extracting purposes, CUR_PAYMENT = principal + interest.

For additional information on AMRT_TYPE_CODE 600, see: Negative Amortization Amount (NEG_AMRT_AMT).

AMRT_TYPE_CODE 820 (Level Principal):

For extracting purposes, CUR_PAYMENT = principal only.

AMRT_TYPE_CODE 800AMRT_TYPE_CODE 820 (Conventional Payment Schedule):

Payment Amount contains both principal and interest.

AMRT_TYPE_CODE 801 (Level Principal Payment Schedule):

Payment Amount contains principal only.

AMRT_TYPE_CODE 802 (Simple Interest Payment Schedule):

Payment Amount equals zero (for simple interest, the cash flow engine ignores this field and just looks at the scheduled payment date).

AMRT_TYPE_CODE 1000 - 29999, User-Defined Payment Patterns:

Note: Oracle Transfer Pricing does not reference CUR_PAYMENT when using the User-Defined Payment Patterns.

Data Verification Requirements and Suggested Defaults

• If AMRT_TYPE_CODE = 100, 400, 500, 600, 710, 800 or is a conventionally-amortizing payment pattern, CUR_PAYMENT includes principal and interest.

• If AMRT_TYPE_CODE = 820, 801 or is a level principal-amortizing payment pattern, CUR_PAYMENT includes principal only.

• If AMRT_TYPE_CODE = 700, 802, or is a simple interest-amortizing payment pattern, CUR_PAYMENT can be 0.

• For AMRT_TYPE_CODE <> Simple Interest AMRT_TYPE_CODEs, CUR_PAYMENT must have the same sign as CUR_BOOK_BAL.

• CUR_PAYMENT must have the same sign as the CUR_BOOK_BAL and CUR_PAR_BAL columns.

• If AMRT_TYPE_CODE = 600 (Negative Amortization) and PMT_DECR_LIFE <> 0, CUR_PAYMENT is greater than or equal to ORG_PAYMENT_AMT * (1 - PMT_DECR_LIFE/100).

• If AMRT_TYPE_CODE = 600 (Negative Amortization) and PMT_INCR_LIFE <> 0, CUR_PAYMENT is lesser than or equal to ORG_PAYMENT_AMT * (1 + PMT_INCR_LF/100).

• CUR_PAYMENT can be validated by performing the following calculations:

  • For conventionally amortizing and Rule of 78:

    CUR_PAYMENT = (CUR_BOOK_BAL* (CUR_GROSS_RATE/((12/PMT_FREQ[in months]) *100))) / (1 - ((1+(CUR_GROSS_RATE /((12/ PMT_FREQ [in months])*100))) ^-(REMAIN_NO_PMTS)))

  • For fixed rate accounts:

    CUR_PAYMENT = (ORG_BOOK_BAL* (CUR_GROSS_RATE/((12/PMT_FREQ[in months]) *100))) / (1 - ((1+(CUR_GROSS_RATE /((12/ PMT_FREQ [in months])*100))) ^-(ORG_TERM/PMT_FREQ [in months])))

  • For Level Principal records:

    CUR_PAYMENT = CUR_BOOK_BAL / REMAIN_NO_PMTS

  • For fixed-rate accounts level principal records, the following should also be true:

    CUR_PAYMENT = ORG_BOOK_BAL/ (ORG_TERM/ PMT_FREQ [in months])

  • For balloon records, the calculated remaining number of payments in the amortization term (CRPAT) must be calculated first. See: Remaining Number of Payments (REMAIN_NO_PMTS).

    The following calculation is used:

    CUR_PAYMENT = (CUR_BOOK_BAL* (CUR_GROSS RATE/((12/PMT_FREQ[in months]) *100))) / (1 - ((1+(CUR_GROSS_RATE /((12/ PMT_FREQ [in months])*100))) ^-(CRPAT)))

  • For fixed rate accounts, the following should be true:

    CUR_PAYMENT = (ORG_BOOK_BAL* (CUR_GROSS_RATE/((12/PMT_FREQ[in months]) *100))) / (1 - ((1+(CUR_GROSS_RATE /((12/ PMT_FREQ [in months])*100))) ^-(AMRT_TERM/PMT_FREQ [in months])))

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Current Static Spread (CUR_STATIC_SPREAD)

Definition

The spread over the implied forward rates that equates the discounted sum of future cash flows to the target balance at the Calendar Period.

Module Usage

When Remaining Term calculation mode is selected in the Transfer Pricing Process Rule, the Oracle Transfer Pricing option cost process writes the result of its static spread calculations to this column.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Current Transfer Pricing Period Average Daily Balance (CUR_TP_PER_ADB)

Definition

The average balance at the LAST_REPRICE_DATE.

Module Usage

When processing with the mid-period repricing option, Oracle Transfer Pricing references CUR_TP_PER_ADB as the average daily balance at the time of the last repricing event. This field is used in conjunction with the PRIOR_TP_PER_ADB field.

1. Mid-period repricing produces an average transfer rate over the current processing month if the LAST_REPRICE_DATE occurred since the beginning of the processing month. CUR_TP_PER_ADB and PRIOR_TP_PER_ADB are used as average balance weightings in the mid-period pricing equation.

   The following table presents a mid-period repricing scenario, which is followed by an explanation.

   A Sample Mid-Period Repricing Scenario

   Field	Scenario
   CALENDAR_PERIOD	12/31/2006
   LAST_REPRICE_DATE	12/15/2006
   LAST_PAYMENT_DATE	12/15/2006 (balance was reduced on this date)
   CUR_TP_PER_ADB	$10,000
   PRIOR_TP_PER_ADB	$15,000
   TRANSFER_RATE	3% from 11/15/2006 to 12/15/2006 (prior period, 30 days in the period)
   TRANSFER_RATE	5% from 12/15/2006 to 1/15/2007 (current period, 31 days in the period)

   Without the mid-period repricing option, the cash flow engine would assign a 5% transfer rate to the record for the month of December. However, this is the transfer rate only for the second half of December. The true transfer rate for the month should be a balance-weighted average transfer rate over the entire month. Mid-period repricing provides this by calculating the final transfer rate by weighting the transfer rate results (from current and previous repricing periods) by average balances and days. This final transfer rate is then applied to the detail records TRANSFER_RATE field.

   The equation used by Oracle Transfer Pricing for calculating Mid-Period Repricing is as follows:

   ((CUR_TP_PER_ADB * Current Period Transfer Rate * Current Period Days) + (PRIOR_TP_PER_ADB * Prior Period Transfer Rate * Prior Period Days)) / ((CUR_TP_PER_ADB * Current Period Days) + (PRIOR_TP_PER_ADB * Prior Period Days))

   From the example from above, the equation would be:

   ((10,000 * 5% * 31) + (15,000 * 3% * 30))/ ((10,000 * 31) + (15,000 * 30)) = 3.82%

   Therefore, the correct transfer rate is 3.82%.

2. In reference to this calculation, the CUR_TP_PER_ADB is used to determine the balance as of the LAST_REPRICE_DATE and PRIOR_TP_PER_ADB is used to determine the balance as of the repricing dates prior to the LAST_REPRICE_DATE.

3. If the TEASER_END_DATE is greater than the CALENDAR_PERIOD, the mid-period repricing does not apply and the CUR_TP_PER_ADB and PRIOR_TP_PER_ADB columns are not used.

Data Verification Requirements and Suggested Defaults

• If the record is adjustable and repricing occurs within the month, CUR_TP_PER_ADB = (average) balance at the time of the LAST_REPRICE_DATE.

• If the CUR_TP_PER_ADB and PRIOR_TP_PER_ADB are not available, use CUR_PAR_BAL as your default (otherwise mid-period repricing could result in a zero transfer rate).

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Deferred Current Balance (DEFERRED_CUR_BAL)

Definition

Current non-amortized deferred balance representing future income/expense such as premium, discount, fees, and costs.

Module Usage

DEFERRED_CUR_BAL holds the discount or premium (fee or cost) associated with a bond or loan record.

Discounted Instrument

A discount loan or instrument is one with interest deducted from the face value (CUR_PAR_BAL) of the loan at its origination. The discount amount (DEFERRED_CUR_BAL) is the difference between the loans current market price (CUR_BOOK_BAL) and its stated par value (CUR_PAR_BAL). The DEFERRED_CUR_BAL, which represents income, will be amortized over the life of the instrument according to a constant yield calculation. Therefore, as the instrument approaches maturity, the CUR_BOOK_BAL approaches the CUR_PAR_BAL.

For discounted instruments, the DEFERRED_CUR_BAL is a negative balance. This indicates to the cash flow engine that the balance is income.

Premium Instrument

A premium bond or instrument is one in which the face value is issued below the book value. The premium is represented by the DEFERRED_CUR_BAL field, and, as with discounts, the deferred portion is accreted over the life of the instrument. For a premium instrument the DEFERRED_CUR_BAL represents an expense.

For instruments sold at a premium, DEFERRED_CUR_BAL is positive, indicating that the balance is an expense.

The relationship in the cash flow engine between book, par, and the deferred amount is as follows:

CUR_BOOK_BAL = CUR_PAR_BAL + DEFERRED_CUR_BAL

Given below is an example of this relationship for a discounted loan:

CUR_PAR_BAL = $9,000

CUR_BOOK_BAL = $8,000

DEFERRED_CUR_BAL = $1,000

1. The cash flow engine performs a constant-yield amortization of the DEFERRED_CUR_BAL. This allows the deferred balance to be accreted evenly over the life of the instrument. This lifelong accretion rather than a one-time realization of the deferred amount at the inception of the instrument is dictated by general accounting rules regarding discount or premium instruments. For certain fees and costs, as well as premiums and discounts, banks must recognize income/expense over the life of an account instead of at the inception of the account. Hence, some deferred balances are amortized over the maturity term of an account even if the account itself does not amortize. See: Detail Cash Flow Data.

2. If the DEFERRED_CUR_BAL = 0, the cash flow engine will recognize this record as having no discount or premium (CUR_BOOK_BAL = CUR_PAR_BAL).

Data Verification Requirements and Suggested Defaults

• For deferred income (fees or discount) DEFERRED_CUR_BAL < 0.

• For deferred expense (costs or premium) DEFERRED_CUR_BAL > 0.

• For accounts with deferred balances, the following equation must hold true: CUR_BOOK_BAL = CUR_PAR_BAL + DEFERRED_CUR_BAL

• For accounts with no deferred balances, DEFERRED_CUR_BAL = 0

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Deferred Original Balance (DEFERRED_ORG_BAL)

Definition

Original non-amortized deferred balance representing future income/expense such as premium, discount, fees, and costs.

Module Usage

This column must exist in the account table for cash flow processing, but is not used in any of the Transfer Pricing calculations.

Data Verification Requirements and Suggested Defaults

Not applicable.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Gross Margin (MARGIN_GROSS)

Definition

The contractual spread that is added to the pricing index, which results in the customer (Gross) rate, for adjustable rate accounts.

Module Usage

MARGIN_GROSS is used by Oracle Transfer Pricing during option cost processing when Model with Gross rates option has been selected while defining the Transfer Pricing rule.

Data Verification Requirements and Suggested Defaults

• For fixed rate accounts, MARGIN_GROSS = 0.

• For adjustable rate accounts with no contractual margin, MARGIN_GROSS = 0.

• For administered rate accounts, MARGIN_GROSS = 0.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Historic Option-Adjusted Spread (HISTORIC_OAS)

Definition

The average spread over all stochastic rate paths that equates the discounted sum of future cash flows to the target balance at origination.

Module Usage

When Standard calculation mode is selected in the Transfer Pricing Process Rule, the Oracle Transfer Pricing option cost process writes the result of its option-adjusted spread calculations to this column.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Historic Static Spread (HISTORIC_STATIC_SPREAD)

Definition

The spread over the implied forward rates that equates the discounted sum of future cash flows to the target balance at origination.

Module Usage

When Standard calculation mode is selected in the Transfer Pricing Process rule, the Oracle Transfer Pricing option cost process writes the result of its static spread calculations to this column.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

ID Number (ID_NUMBER)

Definition

Account number identifying individual customer accounts.

Module Usage

ID_NUMBER identifies the individual customer accounts in account tables. The ID_NUMBER should be unique for a given Calendar Period within an account table. The cash flow engine utilizes ID_NUMBER to identify an account as it is processed.

It is also important for instruments with payment schedules (AMRT_TYPE_CODE 800, 801, 802) because the cash flow engine uses the combination of INSTRUMENT_TYPE_CODE and ID_NUMBER to determine the payment dates and amounts from the PAYMENT_SCHEDULE table.

Note: While propagating results you must ensure that the, target and source records have matching ID Numbers and Source System Codes.

Data Verification Requirements and Suggested Defaults

• ID_NUMBER is loaded into account tables from the source data. Because the detail client data loader ensures that ID_NUMBER is unique for each Calendar Period, there are no edits or defaults for this field.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Instrument Type Code (INSTRUMENT_TYPE_CODE)

Definition

Code identifying the instrument category of the customer account. This code generally matches the Account Table in which the data is loaded.

Module Usage

INSTRUMENT_TYPE_CODE identifies the instrument category of an account. The following table lists each of the available INSTRUMENT_TYPE_CODE values:

Instrument Type Codes and Descriptions

Code Value	Description
110	Commercial loans
120	Consumer loan
130	Mortgages
140	Investments
141	MBS
150	Credit card
210	Deposits
220	Wholesale funding
230	Credit line
240	Off balance sheet
250	Leases

The cash flow engine utilizes the INSTRUMENT_TYPE_CODE to determine the instrument of an account when accounts of different instrument category are grouped together (on a report or other query).

It is also important for instruments with Payment Schedules (AMRT_TYPE_CODE 800, 801, 802) because the cash flow engine uses the INSTRUMENT_TYPE_CODE and ID_NUMBER to determine the payment dates and amounts from PAYMENT_SCHEDULE table.

Data Verification Requirements and Suggested Defaults

The INSTRUMENT_TYPE_CODE value for an individual account should match the instrument type of the table in which it is stored. For example, all account records stored in the DEPOSITS table should be assigned INSTRUMENT_TYPE_CODE = 210.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Interest Type Code (INT_TYPE_CODE)

Definition

Determines whether interest cash flows are paid in advance or in arrears.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference INT_TYPE_CODE to determine whether interest payments are made in arrears or in advance. INT_TYPE_CODE impacts the calculation of interest income (financial element 430, 435).

1. If INT_TYPE_CODE = 1, the record is considered interest in arrears. Interest payments are paid at the end of the payment period along with the principal payments. See: Accrual Basis Code (ACCRUAL_BASIS_CODE).

2. If INT_TYPE_CODE = 2, the record is considered interest in advance. Interest payments are paid at the beginning of the payment period starting from the ORIGINATION_DATE. Payments are made on every payment date except for the MATURITY_DATE.

3. The calculation used to determine interest income (financial element 430) for an interest in advance record depends also on the ACCRUAL_BASIS_CODE. The equations relevant to an interest in advance calculation are as follows:

   For ACCRUAL_BASIS_CODE 30/360, 30/365 and, 30/Actual the interest income calculation, when PMT_FREQ_MULT = M (assuming no compounding), is:

   Current Periods Ending Balance * Cur Net Rate/100 * PMT_FREQ [number of months] * [accrual basis] * (Following Payment Date - Next Payment Date)/(Calculated Following Payment Date - Next Payment Date)

   Here:

   • Following Payment Date is the payment after Next Payment Date - (a).

   • Calculated Following Payment Date is the Next Payment Date rolled forward by the number of months in PMT_FREQ -(b).

     In most cases, (a) is the same as (b). However, if there is a short or extended maturity, (a) <> (b), and therefore the cash flow engine needs to consider this factor while calculating the last interest cash flow (in other words, the payment just before maturity).

     Note: The Following Payment Date is the payment that follows the one currently being calculated.

     For ACCRUAL_BASIS_CODE Actual/365, Actual/Actual, Actual/360 (the example is for an Actual/365 record), the interest income calculation is:

     Current Periods Ending Balance * Cur Net Rate/100 * (Following Payment Date - Current Payment Date)/365

4. Even though the cash flow engine pays interest in advance on every payment date except for the MATURITY_DATE, the REMAIN_NO_PMTS column should count MATURITY_DATE as a payment date since principal is still paid on this date.

Data Verification Requirements and Suggested Defaults

• If INT_TYPE_CODE = 2, AMRT_TYPE_CODE = 700, 820, 801, 802 or non-conventionally amortizing User-Defined Payment Patterns.

• INT_TYPE_CODE valid values are 1 and 2.

• If INT_TYPE_CODE = 2, REMAIN_NO_PMTS still counts MATURITY_DATE as a payment date.

• If INT_TYPE_CODE = 2 and ORIGINATION_DATE > CALENDAR_PERIOD, NEXT_PAYMENT_DATE and LAST_PAYMENT_DATE = ORIGINATION_DATE.

• If the ORIGINATION_DATE > CALENDAR_PERIOD, the NEXT_PAYMENT_DATE and LAST_PAYMENT_DATE both equal the ORIGINATION_DATE.

• For conventionally amortizing records, interest in advance is not a valid INT_TYPE_CODE. Interest in advance functions with simple interest and level principal AMRT_TYPE_CODEs.

• If a compounding method has been chosen, the cash flow engine derives the compounded rate before calculating the interest income amounts. See: Compounding Basis Code (COMPOUND_BASIS_CODE).

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Interest Rate Code (INTEREST_RATE_CODE)

Definition

Identifies the index to which adjustable rate accounts are tied.

Module Usage

Oracle Transfer Pricing references INTEREST_RATE_CODE when calculating option costs and uses the relevant interest rate from the defined interest rate code (IRC) together with the margin to determine the reprice rate for the instrument. The value populated in this column for each account record must be synchronized with the actual interest rate code values defined in Oracle Transfer Pricing.

Data Verification Requirements and Suggested Defaults

• If ADJUSTABLE_TYPE_CODE = 0, INTEREST_RATE_CODE can be defaulted to 0.

• If ADJUSTABLE_TYPE_CODE <> 0, INTEREST_RATE_CODE = 1 - 99999.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Issue Date (ISSUE_DATE)

Definition

Date the account was originated (issued) by the originating institution.

Module Usage

Oracle Transfer Pricing does not reference Issue Date. However, it is recommended that you populate this field with the actual issue date or as a default equal to ORIGINATION_DATE.

Data Verification Requirements and Suggested Defaults

• For accounts originated by the current institution, ISSUE_DATE = ORIGINATION_DATE.

• For accounts acquired through acquisition of another institution, or purchase of a pool of accounts, ISSUE_DATE < ORIGINATION_DATE.

• If ORIGINATION_DATE from the original institution is not available, ISSUE_DATE = ORIGINATION_DATE.

• ISSUE_DATE + ISSUE TERM = MATURITY_DATE

• ISSUE_DATE <= LAST_REPRICE_DATE

• ISSUE_DATE <= ORIGINATION_DATE. ISSUE_DATE cannot be greater than ORIGINATION_DATE.

• For adjustable-rate records, when the LAST_REPRICE_DATE is less than the ISSUE_DATE, transfer pricing does not occur. If ADJUSTABLE_TYPE_CODE = 0, LAST_REPRICE_DATE can be defaulted to be less than or equal to the ISSUE_DATE.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Last Payment Date (LAST_PAYMENT_DATE)

Definition

The date on which the last payment for the record was made.

Module Usage

When Remaining Term calculation mode is selected on the Transfer Pricing Process rule run page Oracle Transfer Pricing uses LAST_PAYMENT_DATE for cash flow transfer pricing methods to calculate the payment period and interest income (financial element 430) for the first cash flow.

1. The first cash flow from the CALENDAR_PERIOD references NEXT_ PAYMENT_DATE minus LAST_PAYMENT_DATE in order to determine the payment period for interest income calculations. The use of LAST_PAYMENT_ DATE rather than (NEXT_PAYMENT_DATE - PMT_FREQ) allows for short or extended first period payments. Beyond the first forecasted cash flow (NEXT_ PAYMENT_DATE), the cash flow engine rolls forward by PMT_FREQ until MATURITY_ DATE. See: Next Payment Date (NEXT_PAYMENT_DATE).

2. For instruments that have been originated in the past (CALENDAR_PERIOD >= ORIGINATION_DATE), the LAST_PAYMENT_DATE is always greater than or equal to the ORIGINATION_DATE.

3. For future originations (CALENDAR_PERIOD < ORIGINATION_DATE), LAST_ PAYMENT_DATE is always equal to the ORIGINATION_DATE.

4. Even though the first cash flow may be extended, the PMT_FREQ is always extracted as the general frequency of payment for the record.

5. For interest income calculation examples that reference LAST_PAYMENT_ DATE, see:

   • Accrual Basis Code (ACCRUAL_BASIS_CODE).

   • Interest Type Code (INT_TYPE_CODE).

Data Verification Requirements and Suggested Defaults

• Default to NEXT_PAYMENT_DATE - PMT_FREQ if actual LAST_PAYMENT_DATE is not available.

• LAST_PAYMENT_DATE < NEXT_PAYMENT_DATE.

• If ORIGINATION_DATE > CALENDAR_PERIOD, LAST_PAYMENT_DATE = ORIGINATION_DATE.

• If ORIGINATION_DATE <= CALENDAR_PERIOD, LAST_PAYMENT_DATE >= ORIGINATION_DATE.

• If INT_TYPE = 2 and ORIGINATION_DATE > CALENDAR_PERIOD, NEXT_PAYMENT_DATE and LAST_PAYMENT_DATE = ORIGINATION_DATE.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Last Repricing Date (LAST_REPRICE_DATE)

Definition

For adjustable rate accounts, the last date that the current interest rate changed.

Module Usage

1. For an adjustable-rate straight term transfer-priced record, Oracle Transfer Pricing uses the LAST_REPRICE_DATE to identify the assignment date (Yield Curve Date). The assignment date of the Interest Rate Code just before (or equal to) the LAST_REPRICE_DATE of the record is used as the transfer pricing yield curve.

   For example, if the LAST_REPRICE_DATE of the record is 1/15/2006 and the Historical Rate interest rate code (IRC) is defined at monthly intervals and only at month-end, the assignment date would be 12/31/2005. The REPRICE_FREQ is then matched to the same term on the transfer pricing yield curve (IRC) defined in the Historical Rates in Oracle Transfer Pricing.

2. For an adjustable-rate cash flow transfer-priced record, Oracle Transfer Pricing uses cash flow methods to transfer price all payments that occur from the LAST_REPRICE_DATE to the NEXT_REPRICE_DATE. In this case, the term and date as defined by these two columns are not used directly to define the transfer rate. They are the starting and ending points within which the cash flow engine applies cash flow transfer pricing.

3. For fixed-rate records, the LAST_REPRICE_DATE and NEXT_REPRICE_DATE are not referenced. ORIGINATION_DATE and MATURITY_DATE are used instead.

Data Verification Requirements and Suggested Defaults

• If REPRICE_FREQ <> 0, LAST_REPRICE_DATE <= CALENDAR_PERIOD.

• If REPRICE_FREQ <> 0 and TEASER_END_DATE <= CALENDAR_PERIOD, LAST_REPRICE_DATE + REPRICE_FREQ = NEXT_REPRICE_DATE.

• LAST_REPRICE_DATE < NEXT_REPRICE_DATE.

• If REPRICE_FREQ = 0, LAST_REPRICE_DATE = ORIGINATION_DATE.

• If REPRICE_FREQ <> 0, LAST_REPRICE_DATE >= ORIGINATION_DATE.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Last Reprice Date Balance (LRD_BALANCE)

Definition

Balance as of the previous repricing event of the record.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference LRD_BALANCE when transfer-pricing adjustable-rate records. LRD_BALANCE holds the balance as of the LAST_REPRICE_DATE.

When transfer pricing adjustable-rate records, LRD_BALANCE is used as the starting balance from the LAST_REPRICE_DATE. When cash flow transfer pricing an adjustable-rate record, the cash flow engine calculates the payment events from the LAST_REPRICE_DATE to the NEXT_REPRICE_DATE. If payments (amortization) occurred in between the LAST_REPRICE_DATE and the CALENDAR_PERIOD, CUR_PAR_BAL of the record is smaller than it was on the LAST_REPRICE_DATE. Therefore, in order to provide an accurate balance amount at the time of the LAST_REPRICE_DATE, the LRD_BALANCE has been provided. Oracle Transfer Pricing amortizes the LRD_BALANCE from the LAST_REPRICE_DATE until the NEXT_REPRICE_DATE.

Data Verification Requirements and Suggested Defaults

• If the record is fixed-rate, LRD_BALANCE = ORG_PAR_BAL.

• If the record is adjustable-rate, LRD_BALANCE = balance as of the last reprice date.

• If the balance as of the last reprice date is not known, default LRD_BALANCE to CUR_PAR_BAL.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Margin (MARGIN)

Definition

MARGIN is the contractual spread that is added to the pricing index and results in the financial institutions retention (net) rate, for adjustable-rate accounts.

Module Usage

1. MARGIN is used during cash flow generation when calculating option costs for adjustable rate instruments.

2. For adjustable-type records, MARGIN is the contractual spread above/below the index that is applied throughout the life of the instrument. The financial institutions retention rate (CUR_NET_RATE) is equal to the index that the record is tied to plus a spread, which is defined by the MARGIN field.

3. The events of a repricing involving MARGIN are as follows: At a repricing event (or a TEASER_END_DATE) for an adjustable-rate record, the cash flow engine matches the INTEREST_RATE_CODE, REPRICE_FREQ and repricing date of the detail record to the rate generated by the Monte Carlo rate engine. After matching the rate, the cash flow engine adds the MARGIN amount and applies any teases, rate caps/floors, and rounding to derive the rate that will be applied to the record.

   Note: Note: The cash flow engine does not reference repricing date information for ADJUSTABLE_TYPE_CD = 30 or 50. See: Cash Flow Column Descriptions.

4. The repriced rate defined in Step 3 equals the coupon rate that is used for amortization, prepayment, and interest income (financial element 430) calculations.

   Note: Note: If the Transfer Pricing rule has the Model with Gross Rates option selected, the cash flow engine uses the CUR_ GROSS_RATE and MARGIN_GROSS for amortization and prepayment purposes.

5. MARGIN is also used in Oracle Transfer Pricing when mid-period repricing is selected for spread from Note Rate to compute the rate from a prior period.

Data Verification Requirements and Suggested Defaults

• For administered rate accounts, MARGIN = 0.

• For adjustable rate accounts with no contractual margin, MARGIN = 0.

• For applicable accounts, margin can be positive or negative.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Matched Spread (MATCHED_SPREAD)

Definition

Interest margin on a product, calculated by Oracle Transfer Pricing.

Module Usage

Oracle Transfer Pricing computes MATCHED_SPREAD when processing using the Standard calculation mode. It is calculated as follows:

For assets: Current Net Rate - Transfer Rate

For liabilities: Transfer Rate - Current Net Rate

Data Verification Requirements and Suggested Defaults

Since the cash flow engine calculates MATCHED_SPREAD, the default can be set to 0.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Maturity Date (MATURITY_DATE)

Definition

Contractual date on which the principal balance of an earning asset or debt instrument is due and payable to the holder.

Module Usage

MATURITY_DATE defines the final date of payment for a record. The MATURITY_DATE signals the end of processing for a given record.

1. MATURITY_DATE is referenced for fixed-rate straight term transfer pricing methodologies. When defining the transfer pricing term for a record, the cash flow engine subtracts the ORIGINATION_DATE from the MATURITY_DATE. The term is then matched to the relevant Interest Rate Code (IRC). The derived rate is applied to the record as the TRANSFER_RATE.

2. MATURITY_DATE is referenced by cash flow transfer pricing methodologies for both adjustable and fixed-rate records. For adjustable records, the cash flow engine transfer prices all cash flows on payment dates within the LAST_REPRICE_DATE and NEXT_REPRICE_DATE. The MATURITY_DATE is used to determine the last payment of a record.

3. The MATURITY_DATE is also referenced in order to determine the remaining number of payments for user-defined payment pattern records. The cash flow engine references the payment pattern payment frequencies and counts the number of payments from the ORIGINATION_DATE to the MATURITY_DATE.

4. Maturity Date is referenced during option cost processing for Fixed Rate and Adjustable rate instruments as cash flows are generated to maturity in both cases for these calculations.

Data Verification Requirements and Suggested Defaults

• For non-term accounts, MATURITY_DATE = CALENDAR_PERIOD + 1 Day.

• For term accounts, MATURITY_DATE is required.

• If the record is not past due or defaulted, MATURITY_DATE > CALENDAR_PERIOD.

• MATURITY_DATE = ORIGINATION_DATE + ORG_TERM.

• MATURITY_DATE = ISSUE_DATE + ISSUE_TERM.

• MATURITY_DATE = CALENDAR_PERIOD + REMAIN_TERM.

• MATURITY_DATE <= NEXT_PAYMENT_DATE + (REMAIN_NO_PMTS* PMT_FREQ).

  Assume that MATURITY_DATE is less than NEXT_PAYMENT_DATE + (REMAIN_NO_PMTS * PMT_FREQ). This implies that the calculated final payment date for an account differs from MATURITY_DATE (the condition results in what is called a stub payment). In this case, the cash flow engine forces the true last payment to be made on the maturity date. If this condition is not met (most likely caused because REMAIN_NO_PMTS is too low), the cash flow engine skips scheduled payments.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Negative Amortization Amount (NEG_AMRT_AMT)

Definition

The total amount of principal added to outstanding principal, resulting from payments which were not large enough to cover interest due.

Module Usage

The Oracle Transfer Pricing adjustable-type cash flow methodologies reference NEG_AMRT_AMT in calculating the current payment for negative amortization-type accounts. This is only relevant for adjustable-rate accounts with AMRT_TYPE_CODE = 600.

1. In a negatively amortizing record, the CUR_PAYMENT is less than the principal and interest that is due on the payment date. The interest portion that is not included in the payment goes to two places. It is added to the NEG_AMRT_AMT column and is added back to the principal amount. Because the NEG_AMRT_AMT balance is already included in the outstanding principal balance, NEG_AMRT_AMT is not explicitly used when the cash flow engine fully re-amortizes the account.

2. NEG_AMRT_AMT is used by the cash flow engine to keep track of negative amortization separately from non-negative amortization (normal) principal balance. It is separate for two reasons:

   • Because the cash flow engine pays down the negatively amortized portion before the principal portion, a separation of the two amounts must be done to allow the cash flow engine to identify what portion of the principal balance is negatively amortized.

   • When calculating the current payment, the cash flow engine uses NEG_AMRT_AMT in its check to see if NEG_AMRT_LIMIT has been exceeded. See: Negative Amortization Limit (NEG_AMRT_LIMIT).

Following is the process of events with regard to NEG_AMRT_AMT and related negative amortization fields:

1. Record is currently negatively amortizing since the payment amount, as defined by CUR_PAYMENT, is not enough to cover the principal and interest portion. The unpaid interest at each payment date goes into the NEG_AMRT_AMT field and back into the principal.

2. While calculating a payment event (payment date), if the engine calculates negative principal runoff, the cash flow engine also checks the negative amortization limit (NEG_AMRT_LIMIT) in order to ensure that the current NEG_AMRT_AMT is not exceeding its limit. NEG_AMRT_LIMIT is defined as a percentage of the original principal balance. If NEG_AMRT_AMT is exceeding this limit, the cash flow engine will recalculate the payment amount in order to fully amortize the instrument.

3. However, when deriving the recalculated payment amount after a NEG_AMRT_LIMIT has been exceeded, the cash flow engine also applies payment decrease/increase limits per period (PMT_DECR_CYCLE, PMT_INCR_CYCLE) and payment decrease/increase limits for the life of the record (PMT_DECR_LIFE, PMT_INCR_LIFE). Because these fields limit how much the CUR_PAYMENT can be changed, it is possible that the record will continue to negatively amortize even after a NEG_AMRT_LIMIT has been exceeded. If negative amortization does continue, the NEG_AMRT_AMT continues to grow.

4. The cash flow engine also attempts to recalculate the negatively amortizing payment amount on a PMT_ADJUST_DATE. Just like a payment recalculation for a NEG_AMRT_LIMIT, a payment recalculation on the PMT_ADJUST_DATE takes into account the effects of payment decrease/increase limits per period and payment decrease/increase limits for the life of the record. This allows for additional negative amortization to occur even after the PMT_ADJUST_DATE has recalculated the payment amount. PMT_ADJUST_DATE is incremented forward by the PMT_CHG_FREQ field until the maturity.

5. In addition to PMT_ADJUST_DATE and NEG_AMRT_LIMIT, the record can experience a payment recalculation on the negative amortization equalization date (NEG_AMRT_EQ_DATE). On this date, the CUR_PAYMENT for the record is fully re-amortized. NEG_AMRT_EQ_DATE ignores payment decrease/increase limits per period and payment decrease/increase limits for the life of the record. Therefore, after the payment recalculation of a NEG_AMRT_EQ_DATE, the record is no longer negatively amortizing and the NEG_AMRT_EQ_DATE is incremented forward by the NEG_AMRT_EQ_FREQ until maturity.

Data Verification Requirements and Suggested Defaults

• NEG_AMRT_LIMIT must be within the range of 0 to 100.

• For AMRT_TYPE_CODE <> 600, NEG_AMRT_AMT = 0.

• If AMRT_TYPE_CODE = 600, 0 <= NEG_AMRT_AMT <= NEG_AMRT_LIMIT/100 * ORG_PAR_BAL.

• If not applicable, default to 0.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Negative Amortization Equalization Date (NEG_AMRT_EQ_DATE)

Definition

The date on which a negative amortization-type account fully re-amortizes, regardless of payment caps and floors.

Module Usage

The Oracle Transfer Pricing adjustable-type cash flow methodologies reference NEG_AMRT_EQ_DATE when calculating the current payment for negative amortization-type accounts. NEG_AMRT_EQ_DATE is only relevant for adjustable-rate accounts with AMRT_TYPE_CODE = 600.

1. On the NEG_AMRT_EQ_DATE, the payment for a negatively amortizing record is recalculated. On this date, the CUR_PAYMENT for the record is fully re-amortized. NEG_AMRT_EQ_DATE ignores payment decrease/increase limits per period and payment decrease/increase limits for the life of the record. Therefore, after the payment recalculation of a NEG_AMRT_EQ_DATE, the record is no longer negatively amortizing.

2. NEG_AMRT_EQ_DATE is incremented forward by the NEG_AMRT_EQ_FREQ until the maturity date is reached.

3. For an explanation of NEG_AMRT_EQ_DATEs relationship with other related negative amortization fields, see: Negative Amortization Amount (NEG_AMRT_AMT).

   Note: If NEG_AMRT_EQ_FREQ = 0, once the modeling date is past the NEG_AMRT_EQ_DATE, the cash flow engine does not attempt to re-amortize the negative amortized amount.

Data Verification Requirements and Suggested Defaults

• If AMRT_TYPE_CODE <> 600, NEG_AMRT_EQ_DATE = 01/Jan/1900.

• If AMRT_TYPE_CODE = 600, NEG_AMRT_EQ_DATE > ORIGINATION_DATE.

• If AMRT_TYPE_CODE = 600, NEG_AMRT_EQ_DATE < MATURITY_DATE.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Negative Amortization Equalization Frequency (NEG_AMRT_EQ_FREQ)

Definition

Used in conjunction with NEG_AMRT_EQ_MULT to define the frequency with which negatively amortizing accounts are fully re-amortized.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference NEG_AMRT_EQ_FREQ in calculating the current payment for negative amortization-type accounts. This is only relevant for adjustable-rate accounts with AMRT_TYPE_CODE = 600.

1. From the NEG_AMRT_EQ_DATE, the cash flow engine rolls forward by the NEG_AMRT_EQ_FREQ until the maturity date.

2. At each instance of a NEG_AMRT_EQ_FREQ, the cash flow engine recalculates the payment as it did for the NEG_AMRT_EQ_DATE. On these roll dates, the CUR_PAYMENT for the record is fully re-amortized. NEG_AMRT_EQ_FREQ ignores payment decrease/increase limits per period and payment decrease/increase limits for the life of the record. Therefore, after the payment recalculation of a NEG_AMRT_EQ_FREQ, the record is no longer negatively amortizing.

3. If NEG_AMRT_EQ_FREQ = 0, once the modeling date is past the NEG_AMRT_EQ_DATE, the engine does not attempt to re-amortize the negative amortized amount. In this case, any negative amortized balance balloons at maturity.

4. For an explanation of NEG_AMRT_EQ_FREQs relationship with other related negative amortization fields, see: Negative Amortization Amount (NEG_AMRT_AMT).

Data Verification Requirements and Suggested Defaults

• If AMRT_TYPE_CODE = 600, NEG_AMRT_EQ_FREQ must be either 0 or a positive value. NEG_AMRT_EQ_FREQ cannot be negative.

• If AMRT_TYPE_CODE <> 600, NEG_AMRT_EQ_FREQ = 0.

• If AMRT_TYPE_CODE = 600, 0 <= NEG_AMRT_EQ_FREQ < ORG_TERM.

• If AMRT_TYPE_CODE = 600, CALENDAR_PERIOD < NEG_AMRT_EQ_DATE <= MATURITY_DATE.

• Validation of NEG_AMRT_EQ_FREQ is always done in conjunction with NEG_AMRT_EQ_MULT.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Negative Amortization Equalization Frequency Multiplier (NEG_AMRT_EQ_MULT)

Definition

Used in conjunction with NEG_AMRT_EQ_FREQ to define the frequency with which negatively amortizing accounts are fully re-amortized.

Module Usage

This column is the multiplier of the NEG_AMRT_EQ_FREQ column. It is used in conjunction with NEG_AMRT_EQ_FREQ to define the frequency with which negatively amortizing accounts are fully re-amortized. Oracle Transfer Pricing cash flow calculations reference NEG_AMRT_EQ_MULT when recalculating the current payment as defined in the NEG_AMRT_EQ_FREQ column. NEG_AMRT_EQ_MULT determines the units (Months, Days or Years) of NEG_AMRT_EQ_FREQ.

Data Verification Requirements and Suggested Defaults

• Valid values are:

  • D: Days

  • M: Months

  • Y: Years

• Suggested default is M.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Negative Amortization Limit (NEG_AMRT_LIMIT)

Definition

Maximum negative amortization allowed as a percentage of the original balance.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference NEG_AMRT_LIMIT when determining if the NEG_AMRT_AMT is exceeding its defined limits. This is only relevant for adjustable-rate accounts with AMRT_TYPE_CODE = 600.

1. While calculating a payment event (payment date), if the cash flow engine calculates negative principal runoff, the cash flow engine also checks the negative amortization limit (NEG_AMRT_LIMIT) in order to ensure that the current NEG_AMRT_AMT is not exceeding its limit. NEG_AMRT_LIMIT is defined as a percentage of the original principal balance.

   For example, NEG_AMRT_LIMIT = 25 means that the negative amortization amount should never exceed 25% of the original principal balance (principal balance should never exceed 125% of the original balance). The formula for this check is:

   (-1 * calculated (negative) principal runoff + negative amortization balance > NEG_AMRT_LIMIT/100 * ORG_PAR_BAL)

   If NEG_AMRT_AMT is exceeding this limit, the cash flow engine recalculates the payment amount in order to fully amortize the instrument.

2. When deriving the recalculated payment amount after a NEG_AMRT_LIMIT has been reached, the cash flow engine also applies payment decrease/increase limits per period (PMT_DECR_CYCLE, PMT_INCR_CYCLE) and payment decrease/increase limits for the life of the record (PMT_DECR_LIFE, PMT_INCR_LIFE). Because these fields limit how much the CUR_PAYMENT can be changed, it is possible that the record continues to negatively amortize even after a NEG_AMRT_LIMIT has been exceeded. If negative amortization does continue, the NEG_AMRT_AMT continues to grow.

3. For an explanation of NEG_AMRT_LIMITs relationship with other related negative amortization fields, see: Negative Amortization Amount (NEG_AMRT_AMT).

Data Verification Requirements and Suggested Defaults

• If AMRT_TYPE_CODE <> 600, NEG_AMRT_LIMIT = 0.

• If AMRT_TYPE_CODE = 600, NEG_AMRT_LIMIT >= 0.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Net Margin Code (NET_MARGIN_CODE)

Definition

NET_MARGIN_CODE defines the relationship between CUR_GROSS_RATE and CUR_NET_RATE for the cash flow engine.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference NET_MARGIN_CODE when calculating a forecasted interest rate. NET_MARGIN_CODE has the following two, valid values:

• Floating Net Rate = 0

• Fixed Net Rate = 1

These are described below:

Floating Net Rate (NET_MARGIN_CODE = 0)

This is the default value for the Net Margin Code. If the detail data NET_MARGIN_CODE column is set to 0 (floating), the Existing Business record reprices at the relevant reprice dates as described under the NEXT_REPRICE_DATE section. Interest Income (FE 430) is based off of the CUR_NET_RATE.

Fixed Net Rate (NET_MARGIN_CODE = 1)

This setting is used by financial institutions that maintain the loans of other financial institutions. For example, Bank A may service (operate and process) the loans of Bank B. Bank B pays Bank A a fixed spread or margin as payment for maintaining the loans. Since Bank A receives a guaranteed fixed spread, only Bank B gains or loses when the actual loan reprices. For this reason, if the record reprices, Bank A should not experience any change in interest income.

If the NET_MARGIN_CODE column of the detail record is set to 1 (fixed) and the Model With Gross Rates option is selected on the Transfer Pricing rule, the existing business record does not reprice even if the record is an adjustable-rate product (CUR_NET_RATE will not reprice). This is because it is assumed that the rate received by the bank (Bank A) equals the fixed spread that the bank is receiving as payment for maintaining the loans. The CUR_NET_RATE column of the record represents this fixed spread and is used for interest income (financial element 430) calculations while the CUR_GROSS_RATE for the record is used for prepayments and amortization.

Note: The CUR_GROSS_RATE is used for amortization and prepayment calculation purposes and reflects the correct repriced rate for all such calculations.

If the NET_MARGIN_CODE is set to Fixed Net Rate, but the Model with Gross Rates option is not selected, the cash flow engine treats the records as if they are Floating Net Rate.

Data Verification Requirements and Suggested Defaults

• NET_MARGIN_CODE must be equal to 0 or 1.

• For fixed-rate accounts and adjustable accounts that reprice, NET_MARGIN_CODE = 0.

• For adjustable-rate accounts that represent records being serviced for a fixed fee, set NET_MARGIN_CODE = 1.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Next Payment Date (NEXT_PAYMENT_DATE)

Definition

Due date of the next scheduled payment. Otherwise known as cash flow date or date of runoff.

Module Usage

NEXT_PAYMENT_DATE is used to define the next scheduled (forecasted) payment date.

NEXT_PAYMENT_DATE is used for adjustable-rate cash flow transfer-priced records. In defining the transfer rate for an adjustable rate record, the cash flow engine produces cash flows for each payment date from the LAST_REPRICE_DATE to the NEXT_REPRICE_DATE. In order to define all the payment events within this period, the cash flow engine rolls back from the NEXT_PAYMENT_DATE by the PMT_FREQ until just before the LAST_REPRICE_DATE. From this calculated payment date, the cash flow engine again rolls forward by the PMT_FREQ, but this time cash flows are produced. The cash flows produced are used by one of the three cash flow transfer pricing methodologies in order to derive the transfer rate.

If the remaining term calculation option is selected on the Transfer Pricing Process rule, the processing order in regards to NEXT_PAYMENT_DATE is as follows:

1. From the CALENDAR_PERIOD, the first cash flow event processed by the cash flow engine is the NEXT_PAYMENT_DATE. The cash flow engine references the NEXT_PAYMENT_DATE for the first forecasted payment date only. This applies to payment patterns (relative and absolute), but not for Payment Schedules.

2. From the NEXT_PAYMENT_DATE, the cash flow engine increments forward by the PMT_ FREQ until the MATURITY_DATE is reached.

   Note: For User-Defined Payment Schedules or Patterns, the cash flow engine does not reference the PMT_FREQ field. Instead, the cash flow engine references the schedule or pattern information to define the additional forecasted payment dates.

3. On the payment date the cash flow engine calculates the interest payments, principal payments, prepayments, and negative amortization, if applicable. Note that for an adjustable-type record where REPRICE_FREQ < PMT_FREQ, the cash flow engine applies only the last repriced rate for the purpose of payment calculation. If the record is not an AMRT_TYPE_CODE 700 (non-amortizing) or an AMRT_TYPE_CODE 600 (negatively amortizing), the principal balance of the record is reduced at each payment date.

   Note: The use of REMAIN_NO_PMTS varies depending on record type. For payment-patterned records, see:

   • Remaining Number of Payments (REMAIN_NO_PMTS).

   • Amortization Term (AMRT_TERM).

4. As each payment is made the cash flow engine reduces the REMAIN_NO_PMTS by 1. If the newly calculated REMAIN_NO_PMTS = 1, the next payment date is set to MATURITY_DATE.

   Note: The use of REMAIN_NO_PMTS varies depending on record type. For special consideration for payment-patterned records, see:

   • Remaining Number of Payments (REMAIN_NO_PMTS).

   • Amortization Term (AMRT_TERM).

5. MATURITY_DATE is the final payment date. If the principal of a record is not reduced by the payment amounts, the remaining principal balance is paid on the MATURITY_DATE. For Payment Schedules, the cash flow engine does not use the NEXT_PAYMENT_ DATE columns. For these records, the cash flow engine makes the next payment on the first date in the schedule after the CALENDAR_PERIOD. However, for Payment Schedules and User-Defined Payment Patterns, the NEXT_PAYMENT_DATE from the detail record corresponds to the next defined payment date after the CALENDAR_PERIOD in the Schedule or Pattern interface.

Data Verification Requirements and Suggested Defaults

Required Conditions:

• NEXT_PAYMENT_DATE > CALENDAR_PERIOD.

• Also included in NEXT_PAYMENT_DATE is the modeling of past due, delinquent, or non-term accounts, if they are to be processed by the engine.

  For example, if the NEXT_PAYMENT_DATE is defaulted to 1900/01/01, the cash flow engine will roll the record by PMT_FREQ from that date until the maturity date. Note that this consumes considerable processing time.

• NEXT_PAYMENT_DATE <= MATURITY_DATE.

• If REMAIN_NO_PMTS > 1, NEXT_PAYMENT_DATE < MATURITY_DATE.

• If REMAIN_NO_PMTS = 1, NEXT_PAYMENT_DATE = MATURITY_DATE.

• MATURITY_DATE <= NEXT_PAYMENT_DATE + (REMAIN_NO_PMTS * PMT_FREQ).

• If the amortization type is an absolute pattern or payment schedule, the payment dates are predefined. The NEXT_PAYMENT_DATE on the detail record always corresponds to the relevant (next payment date after the CALENDAR_PERIOD) predefined payment date information of the Absolute Pattern interface or PAYMENT_SCHEDULE table.

• Suggested default:

  If next payment date is unknown, set to either:

  • CALENDAR_PERIOD + PMT_FREQ, or

  • MATURITY_DATE

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Next Repricing Date (NEXT_REPRICE_DATE)

Definition

Date of next scheduled interest rate change for adjustable rate accounts.

Module Usage

NEXT_REPRICE_DATE defines the first forecasted repricing event after the Calendar Period date.

1. NEXT_REPRICE_DATE is used by adjustable-rate straight term transfer-priced records when using the Remaining Term calculation mode. The CALENDAR_PERIOD and NEXT_REPRICE_DATE define the term of the transfer pricing period. This term is matched to the relevant Interest Rate Code (IRC) to derive a transfer rate.

2. Adjustable-rate cash flow transfer-priced records use LAST_REPRICE_DATE and NEXT_REPRICE_DATE as the starting and ending points of the transfer-pricing period. In order to define all the payment events within this period, the cash flow engine rolls back from the NEXT_PAYMENT_DATE by the PMT_FREQ until just after the LAST_REPRICE_DATE. From this calculated payment date, the cash flow engine again rolls forward by the PMT_FREQ until just before the NEXT_REPRICE_DATE. As the cash flow engine rolls forward, cash flows are produced. The cash flows produced are used by one of the three cash flow transfer pricing methodologies in order to derive the transfer rate. See: Teaser-rate End Date (TEASER_END_DATE).

When calculating option costs, the following also applies when remaining term calculation mode is selected on the Transfer Pricing Process rule:

1. If the record is defined as ADJUSTABLE_TYPE_CODE = 250 and REPRICE_FREQ > 0, the cash flow engine references NEXT_REPRICE_DATE when calculating the first forecasted interest rate change.

   Note: AMRT_TYPE_CODE definition does not impact whether the record is adjustable or not.

   Note: If ADJUSTABLE_TYPE_CODE = 30 or 50, the cash flow engine does not reference the NEXT_ REPRICE_DATE. See: Adjustable Type Code (ADJUSTABLE_TYPE_CODE).

2. The cash flow engine rolls forward from NEXT_REPRICE_DATE to define the remaining forecasted Reprice Dates of the record. Rolling by the REPRICE_FREQ continues until MATURITY_DATE.

3. In defining the customer rate, on each reprice date, the cash flow engine matches the INTEREST_RATE_CODE, the reprice date and the REPRICE_FREQ of the record to the appropriate term point on the forecasted Interest Rate Code (IRC). To this derived rate, the cash flow engine adds the MARGIN (or MARGIN_GROSS, if applicable).

4. The cash flow engine then applies interest rate rounding and periodic/lifetime rate caps/floors. If the records TEASER_END_DATE is less than or equal to the CALENDAR_PERIOD, the cash flow engine applies the calculated forecasted rate to the record. Otherwise the cash flow engine applies the defined teased rate.

   Note: If multiple reprice dates exist within one payment period, (that is, if REPRICE_FREQ < PMT_FREQ) only the forecasted rate of the reprice date immediately preceding the payment date is used for payment calculation purposes. The cash flow engine stores Before Reprice and After Reprice, Gross Rates and Net Rates as financial elements 260 to 290.

Data Verification Requirements and Suggested Defaults

• For fixed-rate accounts, NEXT_REPRICE_DATE = MATURITY_DATE.

• For administered rate accounts and floating rate accounts, use ADJUSTABLE_TYPE_CODE 30 or 50, which does not reference NEXT_REPRICE_DATE. Set the default to NEXT_REPRICE_DATE = NEXT_PAYMENT_DATE or MATURITY_DATE.

• If ADJUSTABLE_TYPE_CODE = 250 and repricing information is available, then:

  • NEXT_REPRICE_DATE > CALENDAR_PERIOD.

  • NEXT_REPRICE_DATE <= MATURITY_DATE.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Original Payment Amount (ORG_PAYMENT_AMT)

Definition

The original payment amount at the date of origination.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference ORG_PAYMENT_AMT when referencing the payment amount at the time of the record origination.

1. Cash flow transfer pricing methodologies for fixed-rate records use ORG_PAYMENT_AMT as the payment amount for amortization purposes. For a fixed-rate record, the cash flow engine rolls forward from the ORIGINATION_DATE by PMT_FREQ when defining payment dates up to the MATURITY_DATE of the record. From origination, the cash flow engine amortizes the original balance (ORG_PAR_BAL) by the ORG_PAYMENT_AMT. The precise method of this amortization depends on the AMRT_TYPE_CODE.

2. ORG_PAYMENT_AMT is also used if the User-Defined Payment Pattern payment method % Original Payment is designated.

ORG_PAYMENT_AMT is also used in determining if the NEG_AMRT_AMT is exceeding its defined limits. This is only relevant for adjustable-rate accounts where AMRT_TYPE_CODE = 600.

1. For negative amortization-type accounts, the cash flow engine uses ORG_PAYMENT_AMT in determining whether a recalculated payment increase or decrease exceeds PMT_INCR_LIFE and PMT_DECR_LIFE.

2. On a recalculation date caused by a NEG_AMRT_LIMIT or PMT_ADJUST_DATE, the cash flow engine recalculates the payment amount in order to create a fully amortized record. After the recalculation, the cash flow engine references payment life increases/decreases columns (PMT_INCR_LIFE, PMT_DECR_LIFE). These fields limit the amount by which the recalculated payment amount can change from the original payment amount (ORG_PAYMENT_AMT).

   For example, if PMT_INCR_LIFE = 25.00, the recalculated payment amount is not allowed to increase by more than 25% of the ORG_PAYMENT_AMT. See:

   • Payment Increase Limit - Life (PMT_INCR_LIFE).

   • Payment Decrease Limit - Life (PMT_DECR_LIFE).

Data Verification Requirements and Suggested Defaults

• If AMRT_TYPE_CODE <> 600, ORG_PAYMENT_AMT = 0.

• If adjustable-rate and AMRT_TYPE_CODE = 600, ORG_PAYMENT should be a valid non-zero value.

• ORG_PAYMENT may be validated using the following formula:

  ORG_PAYMENT = (ORG_BOOK_BAL* (CUR GROSS RATE/((12/PMT_FREQ[in months]) *100))) / (1 - ((1+(CUR_GROSS_RATE /((12/ PMT_FREQ [in months])*100))) ^-(ORG_TERM/PMT_FREQ [in months])))

• If ORG_PAYMENT_AMT is unknown, default to CUR_PAYMENT.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Original Par Balance (ORG_PAR_BAL)

Definition

Represents the starting balance from which all fixed rate transfer pricing cash flows are generated, including principal run-off, prepayments, and interest cash flows.

Module Usage

Cash flow transfer pricing methodologies for fixed-rate records use ORG_PAR_BAL as the starting balance for all cash flow generation. For the treatment of adjustable-rate records, see: Last Reprice Date Balance (LRD_BALANCE).

The cash flow engine bases interest cash flows and principal runoff on ORG_PAR_BAL when transfer pricing cash flow methodology fixed-rate accounts. During processing, the cash flow engine rolls forward from the ORIGINATION_DATE by PMT_FREQ when defining payment dates up until the MATURITY_DATE of the record. From origination, the cash flow engine amortizes the original balance (ORG_PAR_BAL) by the ORG_PAYMENT_AMT. The precise method of this amortization depends on the AMRT_TYPE_CODE.

Data Verification Requirements and Suggested Defaults

• ORG_PAR_BAL requires a valid balance for all accounts.

• ORG_PAR_BAL = ORG_BOOK_BAL - DEFERRED_ORG_BAL .

• ORG_PAR_BAL must have the same sign as ORG_PAYMENT_AMT and CUR_PAYMENT.

  For the transfer pricing of fixed-rate instruments, the original balance should be populated. If REPRICE_FREQ = 0, ORG_PAR_BAL <> 0.

• Original balance on Rule of 78 instruments should not be greater than the current balance. If AMRT_TYPE_CODE = 710, ORG_PAR_BAL should be less than CUR_PAR_BAL.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Original Term (ORG_TERM)

Definition

Used in conjunction with ORG_TERM_MULT to define the contractual term at origination date.

Module Usage

The ORG_TERM of the instrument is referenced by Oracle Transfer Pricing as the period from ORIGINATION_DATE to MATURITY_DATE.

ORG_TERM is referenced by Oracle Transfer Pricing when calculating cash flows for fixed-rate cash flow methodologies.

1. Oracle Transfer Pricing cash flow methodologies use ORG_TERM when calculating the current payment for adjustable-rate accounts and in transfer pricing fixed-rate accounts. For adjustable-rate accounts, the cash flow engine compares ORG_TERM against AMRT_TERM, checking to see if the account is a balloon-type account.

2. If ORG_TERM < AMRT_TERM, the engine recognizes the record as a balloon. The cash flow engine amortizes the outstanding principal balance over the calculated number of payments, based upon the amortization maturity date. See: Amortization Term (AMRT_TERM).

Data Verification Requirements and Suggested Defaults

• ORG_TERM > 0.

• ORG_TERM <= ISSUE_TERM.

• ORG_TERM <= AMRT_TERM.

• ORG_TERM >= REPRICE_FREQ.

• ORG_TERM >= PMT_FREQ.

• ORG_TERM >= REMAIN_TERM.

• ORG_TERM + ORIGINATION_DATE = MATURITY_DATE.

  Note: Validation of ORG_TERM should always be done in conjunction with ORG_TERM_MULT.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Original Term Multiplier (ORG_TERM_MULT)

Definition

Used in conjunction with ORG_TERM to define the contractual term at origination date.

Module Usage

ORG_TERM_MULT is referenced by Oracle Transfer Pricing when calculating cash flows for fixed-rate cash flow methodologies.

Data Verification Requirements and Suggested Defaults

• Valid values are:

  • D: Days

  • M: Months

  • Y: Years

• For non-term accounts, default to M.

• For information on ORG_TERM_MULT validation, see: Original Term (ORG_TERM).

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Origination Date (ORIGINATION_DATE)

Definition

The date the current financial institution originated or acquired the instrument.

Module Usage

Oracle Transfer Pricing references the ORIGINATION_DATE as the start date of the record. For additional information, see: Issue Date (ISSUE_DATE).

Prepayment assumptions also reference ORIGINATION_DATE. Separate assumptions can be defined for ORIGINATION_DATE ranges.

Additionally, when using a Prepayment Table rule:

• If the prepayment rate is driven by the Expired Term, the ORIGINATION_DATE is used to determine the age of the instrument using the following formula:

  (ROUND(Current Bucket Date - ORIGINATION_DATE)/30.42, 0)

• If the prepayment rate is driven by the ORIGINATION_DATE and the instrument is still in its tease period (i.e., TEASE_END_DATE > Current Bucket Date), then the REPRICE_FREQ is calculated as:

  (ROUND(TEASE_END_DATE - ORIGINATION_DATE)/30.42,0)

1. Fixed-rate cash flow transfer-priced records reference ORIGINATION_DATE in order to calculate the payment dates for amortization purposes.

   Note: For adjustable rate accounts, transfer pricing cash flow calculations begin on LAST_REPRICE_DATE.

   Note: When defining the payment dates for the record, the cash flow engine starts from the records ORIGINATION_DATE and rolls forward by PMT_FREQ until the MATURITY_DATE is reached. The cash flow engine bases interest cash flows and principal runoff on ORG_PAR_BAL when transfer pricing cash flow methodology fixed-rate accounts. From ORIGINATION_DATE, the cash flow engine amortizes the original balance (ORG_PAR_BAL) by the ORG_PAYMENT_AMT. The precise method of this amortization depends on the AMRT_TYPE_CODE.

2. Straight term methodology references ORIGINATION_DATE when defining the transfer pricing term that is matched to the term on the yield curve (Transfer Pricing Interest Rate Code). For fixed-rate instruments, the term defined by MATURITY_DATE - ORIGINATION_DATE is matched to the relevant Interest Rate Code (IRC).

   For adjustable-rate instruments in their tease period, the term is figured as the (TEASE_END_DATE - ORIGINATION_DATE). The transfer pricing assignment date for the IRC is also determined by the ORIGINATION_DATE of the record. That is, the date of the yield curve (IRC) is matched to the date of the record origination.

3. If the record is transfer-priced using a Spread From Interest Rate Code or Redemption Curve methodology, the option of choosing the IRCs assignment date is available. If the Origination Date is chosen as the assignment date, or if the assignment date is the Last Repricing Date and the instrument is fixed rate, the date of the IRC used for transfer rate calculations is the same as the detail records ORIGINATION_DATE. If an IRC of the same date does not exist the cash flow engine uses yield curve information for the closest preceding date.

4. For records that reference the User-Defined Payment Patterns, the cash flow engine derives the remaining number of payments by counting the number of payments from the ORIGINATION_DATE to the MATURITY_DATE.

Data Verification Requirements and Suggested Defaults

• For all accounts, a valid ORIGINATION_DATE is required.

• ORIGINATION_DATE >= ISSUE_DATE.

• ORIGINATION_DATE <= CALENDAR_PERIOD (unless future originations booked on system).

• ORIGINATION_DATE <= LAST_REPRICE_DATE.

• For term accounts only:

  • ORIGINATION_DATE + ORG_TERM = MATURITY_DATE.

  • ORIGINATION_DATE <= TEASER_END_DATE (if TEASER_END_DATE is valid).

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Payment Adjustment Date (PMT_ADJUST_DATE)

Definition

Date of next payment adjustment for adjustable-rate, negative amortization-type accounts.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference PMT_ADJUST_DATE when processing and calculating the current payment for negative amortization-type accounts. This is only relevant for adjustable-rate accounts where AMRT_TYPE_CODE = 600.

1. The cash flow engine recalculates negatively amortizing payment amounts on a PMT_ADJUST_DATE. Just like a payment recalculation for a NEG_AMRT_LIMIT, a payment recalculation on the PMT_ADJUST_DATE takes into account the effects of payment decrease/increase limits per period (PMT_DECR_CYCLE, PMT_INCR_CYCLE) and payment decrease/increase limits for the life of the record (PMT_DECR_LIFE, PMT_INCR_LIFE). This allows for additional negative amortization to occur even after the PMT_ADJUST_DATE has recalculated the payment amount.

2. PMT_ADJUST_DATE is incremented forward by the PMT_CHG_FREQ field until maturity.

3. PMT_ADJUST_DATE differs from NEG_AMRT_EQ_DATE because on PMT_ADJUST_DATE, the calculated payment is constrained by payment decrease/increase limits per period and payment decrease/increase limits for the life of the record. However, on the NEG_AMRT_EQ_DATE, the calculated payment overrides these payment change limits.

4. For an explanation of the relationships among the relevant negative amortization fields, see: Negative Amortization Amount (NEG_AMRT_AMT).

Data Verification Requirements and Suggested Defaults

• For fixed-rate and non-term accounts, PMT_ADJUST_DATE = 01-Jan-19000.

• For adjustable-rate accounts with AMRT_TYPE_CODE <> 600, PMT_ADJUST_DATE = NEXT_REPRICE_DATE.

• For adjustable-rate accounts with AMRT_TYPE_CODE = 600, the following conditions should exist:

  • PMT_ADJUST_DATE > CALENDAR_PERIOD.

  • PMT_ADJUST_DATE > ORIGINATION_DATE.

  • PMT_ADJUST_DATE <= CALENDAR_PERIOD + PMT_CHG_FREQ

  • PMT_ADJUST_DATE <= MATURITY_DATE.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Payment Change Frequency (PMT_CHG_FREQ)

Definition

Used in conjunction with PMT_CHG_FREQ_MULT to define the frequency at which the payment for an account adjusts.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference PMT_CHG_FREQ when processing and calculating the current payment for negative amortization-type accounts. This is only relevant for adjustable-rate accounts where AMRT_TYPE_CODE = 600.

1. The PMT_CHG_FREQ is used to increment forward from the PMT_ADJUST_DATE.

2. The cash flow engine recalculates negatively amortizing payment amounts on a PMT_CHG_FREQ. Just like a payment recalculation for a NEG_AMRT_LIMIT, a payment recalculation on the PMT_CHG_FREQ takes into account the effects of payment decrease/increase limits per period (PMT_DECR_CYCLE, PMT_INCR_CYCLE) and payment decrease/increase limits for the life of the record (PMT_DECR_LIFE, PMT_INCR_LIFE). This allows for additional negative amortization to occur even after the PMT_CHG_FREQ event has recalculated the payment amount.

3. Negative Amortization Amount (NEG_AMRT_AMT).

Data Verification Requirements and Suggested Defaults

• If AMRT_TYPE_CODE = 600, PMT_CHG_FREQ must be either 0 or a positive value. PMT_CHG_FREQ cannot be negative.

• For fixed-rate and non-term accounts, PMT_CHG_FREQ = 0.

• For adjustable-rate accounts with AMRT_TYPE_CODE <> 600, PMT_CHG_FREQ = REPRICE_FREQ.

• For adjustable-rate accounts with AMRT_TYPE_CODE = 600, the following conditions should exist:

  • PMT_CHG_FREQ <> 0.

  • PMT_CHG_FREQ <= PMT_ADJUST_DATE - CALENDAR_PERIOD.

    Note: Validation of PMT_CHG_FREQ should always be done in conjunction with PMT_CHG_FREQ_MULT.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Payment Change Frequency Multiplier (PMT_CHG_FREQ_MULT)

Definition

Used in conjunction with PMT_CHG_FREQ to define the frequency at which the payment for an account adjusts.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference PMT_CHG_FREQ_MULT when processing and calculating the current payment for negative amortization-type accounts. PMT_CHG_FREQ_MULT determines the units (months, days or years) of PMT_CHG_FREQ.

Data Verification Requirements and Suggested Defaults

• Valid values are:

  • D: Days

  • M: Months

  • Y: Years

• For information on PMT_CHG_FREQ_MULT validation, see: Negative Amortization Amount (NEG_AMRT_AMT).

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Payment Decrease Limit - Cycle (PMT_DECR_CYCLE)

Definition

Maximum payment decrease allowed during the payment change cycle of an adjustable-rate instrument.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference PMT_DECR_CYCLE when recalculating the current payment for negative amortization events such as NEG_AMRT_LIMIT, PMT_ADJUST_DATE, and PMT_CHG_FREQ. This is only relevant for adjustable-rate accounts where AMRT_TYPE_CODE = 600.

1. For negative amortization-type accounts, the cash flow engine uses PMT_DECR_CYCLE to calculate the maximum decrease in the payment amount allowed from the previous payment change to the next.

2. PMT_DECR_CYCLE is defined in terms of a percentage. The engine performs the following check:

   Previous Current Payment - Newly calculated payment > (PMT_DECR_CYCLE/100 * Previous Current Payment)

   If the newly calculated payment satisfies the above equation, the engine limits the decrease to the amount = (PMT_DECR_CYCLE * Previous Current Payment).

   For example, if PMT_DECR_CYCLE = 5.00, the calculated current payment is not allowed to decrease by more than 5% of the previous current payment.

3. If PMT_DECR_CYCLE = 0, the cash flow engine assumes that there is no payment decrease limit per payment change period.

4. The PMT_DECR_CYCLE is referenced when the following negative amortization events occur: NEG_AMRT_LIMIT, PMT_ADJUST_DATE, and PMT_CHG_FREQ.

5. For an explanation of the relationship of the PMT_DECR_CYCLE with other related negative amortization fields, see: Negative Amortization Amount (NEG_AMRT_AMT).

Data Verification Requirements and Suggested Defaults

• For accounts with AMRT_TYPE_CODE <> 600, PMT_DECR_CYCLE = 0.

• For accounts with AMRT_TYPE_CODE = 600, 0 <= PMT_DECR_CYCLE < 100.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Payment Decrease Limit - Life (PMT_DECR_LIFE)

Definition

Maximum payment decrease allowed during the life of an adjustable-rate instrument.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference PMT_DECR_LIFE when recalculating the current payment for negative amortization events such as NEG_AMRT_LIMIT, PMT_ADJUST_DATE, and PMT_CHG_FREQ. This is only relevant for adjustable-rate accounts where AMRT_TYPE_CODE = 600.

1. For negative amortization-type accounts, the cash flow engine uses PMT_DECR_LIFE to calculate the maximum decrease in the payment allowed during the life of the account. PMT_DECR_LIFE is defined in terms of a percentage of ORG_PAYMENT. The engine performs the following check:

   ORG_PAYMENT - Newly calculated payment > (PMT_DECR_LIFE/100 * ORG_PAYMENT)

   If the newly calculated payment satisfies the above equation, the cash flow engine limits the decrease to the amount = (PMT_DECR_LIFE * ORG_PAYMENT).

   For example, if PMT_DECR_LIFE = 25.00, the calculated current payment is not allowed to decrease by more than 25% of ORG_PAYMENT.

2. If PMT_DECR_LIFE = 0, the cash flow engine assumes that there is no lifetime payment decrease limit.

3. The PMT_DECR_LIFE field is referenced when the following negative amortization events occur:

   • NEG_AMRT_LIMIT

   • PMT_ADJUST_DATE

   • PMT_CHG_FREQ

4. For an explanation of the relationship of PMT_DECR_LIFE with other related negative amortization fields, see: Negative Amortization Amount (NEG_AMRT_AMT).

Data Verification Requirements and Suggested Defaults

• For accounts with AMRT_TYPE_CODE <> 600, PMT_DECR_LIFE = 0.

• For accounts with AMRT_TYPE_CODE = 600, 0 <= PMT_DECR_LIFE < 100.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Payment Frequency (PMT_FREQ)

Definition

Used in conjunction with PMT_FREQ_MULT to define the payment frequency of an account.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference PMT_FREQ for calculating and processing payments and prepayments. The engine forecasts future next payment dates by incrementing NEXT_PAYMENT_DATE forward by PMT_FREQ.

PMT_FREQ is referenced by the cash flow transfer pricing methodologies when deriving discounted cash flows. See: Detail Cash Flow Data.

Oracle Transfer Pricing uses PMT_FREQ in defining payment dates.

1. Oracle Transfer Pricing defines the date of payment using PMT_FREQ in the following ways:

   • Adjustable-rate Cash Flow Transfer-priced Records: In defining the transfer rate for an adjustable-rate record, the cash flow engine uses the PMT_FREQ to define the payment dates from the LAST_REPRICE_DATE to the NEXT_REPRICE_DATE. In order to define all the payment events within this period, the cash flow engine rolls back from the NEXT_PAYMENT_DATE by the PMT_FREQ until just before the LAST_REPRICE_DATE. From this calculated payment date, the cash flow engine again rolls forward by the PMT_FREQ, but this time cash flows are produced. The cash flows produced are used by one of the three cash flow transfer pricing methodologies in order to derive the transfer rate.

   • Fixed-rate Cash Flow Transfer-priced Records: In defining the payment dates for cash flow transfer-priced fixed-rate records, the cash flow engine starts from the ORIGINATION_DATE of the record and rolls forward by the PMT_FREQ until the MATURITY_DATE.

     Note: If the transfer pricing record utilizes User-Defined Payment Schedules or Patterns, PMT_FREQ is not referenced for payment date information.

2. Oracle Transfer Pricing utilizes the PMT_FREQ in the following manner:

   • On date of payment, the cash flow engine calculates the interest payments, principal payments, current deferred payments, prepayments, unscheduled prepayments, and negative amortization, if applicable.

   • During the payment calculation processing, PMT_FREQ is used for interest income calculations (financial element 430) for records with ACCRUAL_BASIS_CODEs of 30/360, 30/365, 30/ACTUAL. See:

     • Accrual Basis Code (ACCRUAL_BASIS_CODE).

     • Interest Type Code (INT_TYPE_CODE).

   • PMT_FREQ is used in the Remaining Number of Payments calculation when calculating the payment amounts for balloon records and specific user-defined payment pattern instances. See: Amortization Term (AMRT_TERM).

   • As each payment is made on the PMT_FREQ, the cash flow engine reduces the REMAIN_NO_PMTS by 1. If the newly calculated REMAIN_NO_PMTS = 1, the next payment date is set to MATURITY_DATE.

     Note: The use of REMAIN_NO_PMTS varies depending on record type. See:

     • Remaining Number of Payments (REMAIN_NO_PMTS).

     • Amortization Term (AMRT_TERM).

Data Verification Requirements and Suggested Defaults

• PMT_FREQ > 0 in all cases. PMT_FREQ = 0 can cause incorrect calculations to occur.

• PMT_FREQ <= ORG_TERM

• MATURITY_DATE <= NEXT_PAYMENT_DATE + (REMAIN_NO_PMTS * PMT_FREQ).

  Note that PMT_FREQ = 1 and PMT_FREQ MULT = D requires the cash flow engine to perform cash flow calculations for every day of the modeling horizon. This slows processing significantly.

  Note: Validation of PMT_FREQ should always be done in conjunction with PMT_FREQ_MULT.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Payment Frequency Multiplier (PMT_FREQ_MULT)

Definition

Used in conjunction with PMT_FREQ to define the payment frequency of an account.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference PMT_FREQ_MULT for calculating and processing payments. PMT_FREQ_MULT determines the units (months, days, or years) of PMT_FREQ.

Data Verification Requirements and Suggested Defaults

• Valid values are:

  • D: Days

  • M: Months

  • Y: Years

• For information on PMT_FREQ_MULT validation, see: Payment Frequency (PMT_FREQ).

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Payment Increase Limit - Cycle (PMT_INCR_CYCLE)

Definition

Maximum payment increase allowed during the payment change cycle of an adjustable-rate instrument.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference PMT_INCR_CYCLE when recalculating the current payment for negative amortization events such as NEG_AMRT_LIMIT, PMT_ADJUST_DATE, and PMT_CHG_FREQ. This is only relevant for adjustable-rate accounts where AMRT_TYPE_CODE = 600.

1. For negative amortization-type accounts, the cash flow engine uses PMT_INCR_CYCLE to calculate the maximum increase in the payment amount allowed from the previous payment change to the next.

2. PMT_INCR_CYCLE is defined in terms of a percentage. The cash flow engine performs the following check:

   Newly Calculated Payment - Previous Current Payment > (PMT_INCR_CYCLE/100 * Previous Current Payment)

   If the newly calculated payment satisfies the above equation, the cash flow engine limits the increase to the amount = (PMT_INCR_CYCLE * Previous Current Payment).

   For example, if PMT_INCR_CYCLE = 5.00, the calculated current payment is not allowed to increase by more than 5% of the previous current payment.

3. If PMT_INCR_CYCLE = 0, the cash flow engine assumes that there is no payment increase limit per payment change period.

4. The PMT_INCR_CYCLE is referenced when the following negative amortization events occur:

   • NEG_AMRT_LIMIT

   • PMT_ADJUST_DATE

   • PMT_CHG_FREQ

5. For an explanation of PMT_INCR_CYCLEs relationship with other related negative amortization fields, see: Negative Amortization Amount (NEG_AMRT_AMT).

Data Verification Requirements and Suggested Defaults

• If AMRT_TYPE_CODE <> 600, PMT_INCR_CYCLE = 0.

• If AMRT_TYPE_CODE = 600, 0 <= PMT_INCR_CYCLE < 100.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Payment Increase Limit - Life (PMT_INCR_LIFE)

Definition

Maximum payment increase allowed during the life of an adjustable-rate instrument.

Module Usage

Oracle Transfer Pricing cash flow methodologies reference PMT_INCR_LIFE when recalculating the current payment for negative amortization events such as NEG_AMRT_LIMIT, PMT_ADJUST_DATE, and PMT_CHG_FREQ. This is only relevant for adjustable-rate accounts where AMRT_TYPE_CODE = 600.

1. For negative amortization-type accounts, the cash flow engine uses PMT_INCR_LIFE to calculate the maximum increase in the payment allowed during the life of the account.

2. PMT_INCR_LIFE is defined in terms of a percentage of ORG_PAYMENT. The cash flow engine performs the following check:

   Newly calculated payment - ORG_PAYMENT > (PMT_INCR_LIFE/100 * ORG_PAYMENT)

   If the newly calculated payment satisfies the above equation, the cash flow engine limits the increase to the amount = (PMT_INCR_LIFE * ORG_PAYMENT).

   For example, if PMT_INCR_LIFE = 25.00, the calculated current payment is not allowed to increase by more than 25% of ORG_PAYMENT.

3. The PMT_INCR_LIFE is referenced when the following negative amortization events occur:

   • NEG_AMRT_LIMIT

   • PMT_ADJUST_DATE

   • PMT_CHG_FREQ

4. For an explanation of PMT_INCR_LIFEs relationship with other related negative amortization fields, see: Negative Amortization Amount (NEG_AMRT_AMT).

Data Verification Requirements and Suggested Defaults

• If PMT_INCR_LIFE = 0, the cash flow engine assumes that there is no lifetime payment increase limit.

• If AMRT_TYPE_CODE <> 600, PMT_INCR_LIFE = 0

• If AMRT_TYPE_CODE = 600, 0 <= PMT_INCR_LIFE < 100

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Percent Sold (PERCENT_SOLD)

Definition

Percent of balance sold to investors.

Module Usage

PERCENT_SOLD is used to calculate net balance and net payment when an instrument is partially participated out to another financial institution. In the case of a participated loan, the bank partially owns the loan. A bank participates out the balance of the loan to another financial institution if it is not able to lend the entire amount or if lending the entire amount exceeds the legal lending limits of the bank. By selling most of the financing to another financial institution, the bank earns fee income from servicing the loan and is able to retain other banking relationships, such as checking accounts.

1. Oracle Transfer Pricing cash flow methodologies use PERCENT_SOLD to perform all net balance calculations.

2. The cash flow engine performs all of the cash flow calculations on a gross balance basis, but must net out the principal and interest portions not owned/owed by the bank. PERCENT_SOLD defines the percent of the balances participated (sold) by the bank.

3. The calculation performed to net out participations sold is:

   [Net Balance] = [Gross Balance] * (100 - PERCENT_SOLD)/100

4. PERCENT_SOLD does not apply if an account has been sold to another subsidiary of the same company. In the case of accounts that have had portions sold from one legal entity of a holding company to another, PERCENT_SOLD = 0.

5. For wholly (100%) owned accounts, PERCENT_SOLD = 0.

Data Verification Requirements and Suggested Defaults

For accounts with PERCENT_SOLD <> 0, the following conditions should exist:

• 0 < PERCENT_SOLD <= 100.

• CUR_NET_BOOK_BAL = CUR_BOOK_BAL * (100 - PERCENT_SOLD) / 100.

• CUR_NET_PAR_BAL = CUR_PAR_BAL * (100 - PERCENT_SOLD) / 100.

• ORG_NET_BOOK_BAL = ORG_BOOK_BAL * (100 - PERCENT_SOLD) / 100.

• ORG_NET_PAR_BAL = ORG_PAR_BAL * (100 - PERCENT_SOLD) / 100.

• If not applicable, PERCENT_SOLD = 0.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Prior Transfer Pricing Period Average Daily Balance (PRIOR_TP_PER_ADB)

Definition

The average balance at the reprice date prior to the LAST_REPRICE_DATE.

Module Usage

When processing with the mid-period repricing option, Oracle Transfer Pricing references PRIOR_TP_PER_ADB as the average daily balance at the time of the last repricing event prior to the LAST_REPRICE_DATE. This column is used in conjunction with the CUR_TP_PER_ADB field.

1. Mid-period repricing produces an average transfer rate over the current processing month if the LAST_REPRICE_DATE occurred since the beginning of the processing month. PRIOR_TP_PER_ADB and CUR_TP_PER_ADB are used as average balance weightings in the mid-period repricing equation. PRIOR_TP_PER_ADB is used to determine the balance on the reprice date prior to the LAST_REPRICE_DATE and CUR_TP_PER_ADB is used to determine the balance as of the LAST_REPRICE_DATE.

   For an example and explanation of the relationship between PRIOR_TP_PER_ADB and CUR_TP_PER_ADB, see: Current Transfer Pricing Period Average Daily Balance (CUR_TP_PER_ADB).

2. If the CUR_TP_PER_ADB and PRIOR_TP_PER_ADB are not available, use CUR_PAR_BAL as the default.

3. If the TEASER_END_DATE is greater than the CALENDAR_PERIOD, the mid-period repricing does not apply and the CUR_TP_PER_ADB and PRIOR_TP_PER_ADB columns are not used.

Data Verification Requirements and Suggested Defaults

• If the record is adjustable and repricing occurs within the month, PRIOR_TP_PER_ADB = (average) balance at the time of the reprice date prior to the LAST_REPRICE_DATE.

• If the average balance at the time of the reprice date prior to the LAST_REPRICE_DATE is not available, use CUR_PAR_BAL.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Rate Cap Life (RATE_CAP_LIFE)

Definition

Maximum interest rate allowed during life of an adjustable-rate instrument.

Module Usage

Oracle Transfer Pricing references RATE_CAP_LIFE when calculating option costs.

For adjustable-rate records, the cash flow engine matches the REPRICE_FREQ, INTEREST_RATE_CODE, and the reprice date to the information generated by the Monte Carlo rate engine. The margin is then added to this forecasted rate. Any rounding, rate caps (RATE_CAP_LIFE) or floors, and tease period are applied, and the resulting rate is applied to the record as its repriced rate.

Data Verification Requirements and Suggested Defaults

• If the record is fixed-rate, RATE_CAP_LIFE = 0.

• If the record is adjustable without a rate cap, RATE_CAP_LIFE = 0.

• If RATE_CAP_LIFE <> 0, CUR_GROSS_RATE and CUR_NET_RATE <= RATE_CAP_LIFE.

• If RATE_CAP_LIFE <> 0, RATE_CAP_LIFE = ORG_RATE + RATE_INCR_LIFE.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Rate Change Minimum (RATE_CHG_MIN)

Definition

Minimum change in the repricing index that is necessary for a change to be made to the interest rate.

Module Usage

Oracle Transfer Pricing references RATE_CHG_MIN during option cost processing when calculating a forecasted interest rate.

1. For adjustable-rate records, the cash flow engine matches the REPRICE_ FREQ, INTEREST_RATE_CODE, and the reprice date to the information generated by the Monte Carlo rate engine. The margin is then added to this forecasted rate. Any rounding is applied, followed by a check of the RATE_CHG_MIN, when determining the fully indexed rate. Rate caps or floors and tease periods are applied, and the resulting rate is used as the repriced rate for the record.

   Note: ADJUSTABLE_TYPE_CODE = 30 or 50 does not reference reprice dates.

2. If the absolute value of [(forecasted rate + margin) - (previous rate + margin)] < RATE_CHG_MIN, the cash flow engine sets the new forecasted rate = previous rate. The cash flow engine does not change the previous rate to the new forecasted rate. The previous rate is defined as either the rate on the detail record (CUR_ NET_RATE or CUR_GROSS_RATE) or the previous forecasted rate from the Monte Carlo engine. After the RATE_CHG_MIN is calculated any other cap/floor, rounding, and tease periods is then applied. See:

   • Next Repricing Date (NEXT_REPRICE_DATE).

   • Overview of Cash Flow Calculations.

Data Verification Requirements and Suggested Defaults

• If the record is fixed-rate, RATE_CHG_MIN = 0.

• If the record is adjustable, without a minimum rate change amount, RATE_CHG_MIN = 0.

• If RATE_CHG_MIN <> 0, 0 < RATE_CHG_MIN <= 1.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Rate Change Rounding Code (RATE_CHG_RND_CODE)

Definition

Method used for rounding of the interest rate change.

Module Usage

Oracle Transfer Pricing references RATE_CHG_RND_CODE when calculating option costs.

The cash flow engine uses RATE_CHG_RND_CODE to determine the rounding method that is applied to the current rate after a repricing event. RATE_CHG_ RND_CODE is used in conjunction with RATE_CHG_RND_FAC.

1. For adjustable-rate records, the cash flow engine matches the REPRICE_ FREQ, INTEREST_RATE_CODE, and the reprice date to the information generated by the Monte Carlo rate engine. The margin is then added to this forecasted rate. Any rounding (RATE_CHG_RND_CODE and RATE_ CHG_RND_FAC), rate caps/floors, and tease periods are applied, and the resulting rate is applied to the record as its repriced rate.

   Note: ADJUSTABLE_TYPE_CODE = 30 or 50 does not reference reprice dates.

2. The RATE_CHG_RND_CODE accepts values 1 to 4. Depending on the value input, the value of the forecasted rate differs. The following table describes the possible values of the RATE_CHG_RND_CODE:

Rate Change Rounding Codes

Rate Change Rounding Code	Description
RATE_CHG_RND_CD = 1	Truncate: The cash flow engine truncates the forecasted rate to a whole value. For example, if unrounded forecast = 8.65, the truncated forecasted rate = 8.00.
RATE_CHG_RND_CD = 2	Round Up: The engine rounds the rate up the nearest multiple of the RATE_CHG_RND_FAC. For example, if the unrounded forecasted rate is 8.65 and the RATE_CHG_RND_FAC = 0.5, the rounded forecasted rate = 9.00.
RATE_CHG_RND_CD = 3	Round Down: The engine rounds the rate down to the nearest multiple of RATE_CHG_ RND_FAC. For example, if the unrounded forecasted rate is 8.65 and the RATE_CHG_ RND_FAC = 0.25, the rounded forecasted rate = 8.50.
RATE_CHG_RND_CD = 4	Round Nearest: The engine rounds the rate to the nearest multiple of RATE_CHG_RND_FAC. For example, if the unrounded forecasted rate is 8.65 and the RATE_CHG_RND_FAC = 0.25, the rounded forecasted rate = 8.75.

Data Verification Requirements and Suggested Defaults

• RATE_CHG_RND_CODE must be within the range 0 to 4.

• For fixed-rate accounts, RATE_CHG_RND_CODE = 4 and RATE_CHG_RND_FAC = 0.

• For variable-rate accounts with rates that are not rounded, RATE_CHG_RND_CODE = 4 and RATE_CHG_RND_FAC = 0.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Rate Change Rounding Factor (RATE_CHG_RND_FAC)

Definition

Factor by which the rate change on an adjustable instrument is rounded.

Module Usage

Oracle Transfer Pricing references RATE_CHG_RND_FAC when calculating option costs.

The cash flow engine references RATE_CHG_RND_FAC when calculating a forecasted interest rate, and contains the value to which forecasted interest rates are rounded. RATE_CHG_RND_FAC is used in conjunction with RATE_CHG_RND_ CODE.

1. For adjustable-rate records, the cash flow engine will match the REPRICE_ FREQ, INTEREST_RATE_CODE, and the reprice date to the information generated by the monte carlo rate engine. The margin will then be added to this forecasted rate. Any rounding (RATE_CHG_RND_CODE and RATE_ CHG_RND_FAC), rate caps/floors, and tease periods will be applied, and the resulting rate is applied to the record as the records repriced rate.

   Note: ADJUSTABLE_TYPE_CODE = 30 or 50 does not reference reprice dates.

2. For an explanation of usage and the relationship between RATE_CHG_RND_ FAC and RATE_CHG_RND_CODE, see: Rate Change Rounding Code (RATE_CHG_RND_CODE).

Data Verification Requirements and Suggested Defaults

• For fixed-rate accounts, RATE_CHG_RND_CODE = 4 and RATE_CHG_RND_FAC = 0.

• For variable-rate accounts with rates that are not rounded, RATE_CHG_RND_CODE = 4 and RATE_CHG_RND_FAC = 0.

• For variable-rate accounts with RATE_CHG_RND_FAC <> 0, 0 < RATE_CHG_RND_FAC <= 1.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Rate Decrease Limit - Cycle (RATE_DECR_CYCLE)

Definition

Maximum rate decrease allowed during a repricing cycle for an adjustable-rate instrument.

Module Usage

Oracle Transfer Pricing references RATE_DECR_CYCLE when calculating option costs.

The cash flow engine references RATE_DECR_CYCLE when calculating a forecasted interest rate. RATE_DECR_CYCLE sets the maximum amount (in terms of basis points) by which the interest rate may decrease in a given REPRICE_FREQ.

1. For adjustable-rate records, the cash flow engine matches the REPRICE_ FREQ, INTEREST_RATE_CODE, and the reprice date to the information generated by the Monte Carlo rate engine. The margin is then added to this forecasted rate. Any rounding, rate caps/floors (RATE_DECR_ CYCLE), and tease periods are applied, and the resulting rate is applied to the record as its repriced rate.

   Note: ADJUSTABLE_TYPE_CODE = 30 or 50 does not reference reprice dates.

2. When applying the RATE_DECR_CYCLE, the engine checks for the following:

   • Previous Current Rate > Calculated forecasted rate

   • Previous Current Rate - Calculated forecasted rate > RATE_DECR_CYCLE

     If both equations are true, the rate change during the repricing period has exceeded RATE_DECR_CYCLE. In this case, the new forecasted rate is limited to the previous current rate - RATE_DECR_CYCLE.

     This is illustrated in the following example:

     RATE_DECR_CYCLE = 2.00 (200 basis points)

     Previous Current Rate = 10.00

     Calculated (raw) rate = 7.75

     • 10.00 > 7.75

     • 10.00 - 7.75 (= 2.25) > 2.00

     New current rate = 10.00 - 2.00 = 8.00

Data Verification Requirements and Suggested Defaults

• For fixed-rate accounts, RATE_DECR_CYCLE = 0.

• For variable-rate accounts without a maximum rate decrease, RATE_DECR_CYCLE = 0.

• For RATE_DECR_CYCLE <> 0, 0 < RATE_DECR_CYCLE <= RATE_DECR_LIFE.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Rate Floor Life (RATE_FLOOR_LIFE)

Definition

Minimum interest rate allowed during the life of an adjustable-rate instrument.

Module Usage

Oracle Transfer Pricing references RATE_FLOOR_LIFE when calculating option costs.

The cash flow engine references RATE_FLOOR_LIFE when calculating a forecasted interest rate for adjustable-rate records.

1. For adjustable-rate records, the cash flow engine matches the REPRICE_ FREQ, INTEREST_RATE_CODE, and the reprice date to the information generated by the Monte Carlo rate engine. The margin is then added to this forecasted rate. Any rounding, rate caps/floors (RATE_FLOOR_ LIFE), and tease periods are applied, and the resulting rate is applied to the record as the repriced rate.

2. If the rate plus margin < RATE_FLOOR_LIFE, the cash flow engine sets the forecasted rate of the record equal to the RATE_FLOOR_LIFE. Rounding and tease periods are then applied. For details of the repricing process see, Next Repricing Date (NEXT_REPRICE_DATE).

3. For any forecasted rate changes throughout the life of the instrument, the cash flow engine references RATE_FLOOR_LIFE.

Data Verification Requirements and Suggested Defaults

• If the record is fixed-rate, RATE_FLOOR_LIFE = 0.

• If the record is adjustable without a rate floor, RATE_FLOOR_LIFE = 0.

• If RATE_FLOOR_LIFE <> 0, CUR_GROSS_RATE and CUR_NET_RATE >= RATE_FLOOR_LIFE.

• If RATE_FLOOR_LIFE <> 0, RATE_FLOOR_LIFE = ORG_RATE - RATE_DECR_LIFE.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Rate Increase Limit - Cycle (RATE_INCR_CYCLE)

Definition

Maximum rate increase allowed during a repricing cycle for an adjustable-rate instrument.

Module Usage

Oracle Transfer Pricing references RATE_INCR_CYCLE when calculating option costs.

The cash flow engine references RATE_INCR_CYCLE when calculating a forecasted interest rate. RATE_INCR_CYCLE sets the maximum amount (in terms of basis points) that the interest rate may increase in a given REPRICE_FREQ.

1. For adjustable-rate records, the cash flow engine matches the REPRICE_ FREQ, INTEREST_RATE_CODE, and the reprice date to the information generated by the Monte Carlo rate engine. The margin will then be added to this forecasted rate. Any rounding, rate caps (RATE_INCR_CYCLE) or floors, and tease periods are applied, and the resulting rate is applied to the record as its repriced rate.

   Note: ADJUSTABLE_TYPE_CODE = 30 or 50 does not reference reprice dates.

2. When applying the RATE_INCR_CYCLE, the engine checks for the following:

   • Calculated forecasted rate > Previous Current Rate

   • Calculated forecasted rate - Previous Current Rate > RATE_INCR_CYCLE.

     If both equations are true, the rate change during the repricing period has exceeded RATE_INCR_CYCLE. In this case, the new forecasted rate is limited to the previous current rate + RATE_INCR_CYCLE. This is illustrated in the following example:

     RATE_INCR_CYCLE = 2.00 (200 basis points)

     Previous Current Rate = 10.00

     Calculated Rate = 12.25

     • 12.25 > 10.00

     • 12.25 -10.00 (= 2.25) > 2.00

     New Current Rate = 10.00 + 2.00 = 12.00

Data Verification Requirements and Suggested Defaults

• For fixed-rate accounts, RATE_INCR_CYCLE = 0.

• For variable-rate accounts without a maximum rate increase, RATE_INCR_CYCLE = 0.

• For RATE_INCR_CYCLE <> 0, 0 < RATE_INCR_CYCLE <= RATE INCR LIFE.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Rate Set Lag (RATE_SET_LAG)

Definition

Used in conjunction with RATE_SET_LAG_MULT to define the period by which repricing lags the current interest rate changes.

Module Usage

Oracle Transfer Pricing references RATE_SET_LAG when calculating option costs.

The cash flow engine references RATE_SET_LAG when calculating a forecasted interest rate.

1. For adjustable-rate records, the cash flow engine matches the REPRICE_ FREQ, INTEREST_RATE_CODE, and the lagged reprice date (after referencing RATE_SET_LAG) to the information generated by the Monte Carlo rate engine. The margin is then added to this forecasted rate. Any rounding, rate caps/floors, and tease periods are applied, and the resulting rate is applied to the record as its repriced rate.

   Note: ADJUSTABLE_TYPE_CODE = 30 or 50 does not reference reprice dates.

2. If RATE_SET_LAG > 0, the cash flow engine does not assign a forecasted interest rate based upon NEXT_REPRICE_DATE. Instead, the engine assigns the account an interest rate based upon the date NEXT_ REPRICE_DATE - RATE_SET_LAG.

   This is illustrated in the following example:

   REPRICE_FREQ = 3

   REPRICE_FREQ_MULT = M

   NEXT_REPRICE_DATE = 11/30/2007

   RATE_SET_LAG = 1 RATE_SET_LAG_ MULT = M

   MARGIN = 1.00

   In this example, the account is tied to the Treasury Yield Curve. Due to the RATE_SET_LAG, the cash flow engine references the Treasury Yield Curve one month before the NEXT_REPRICE_DATE. The 3-month point on the Treasury Yield Curve on 10/31/2007 equals 5%. Therefore, the repriced rate equals 6% (5% plus the 1% margin).

3. If the RATE_SET_LAG > (Cash Flow Date - CALENDAR_PERIOD), the cash flow engine uses the base rate from the Monte Carlo rate engine. The cash flow engine does not reference the rates historically. For instance, if a 3-month RATE_SET_LAG is applied to a repricing event that is two months from the CALENDAR_PERIOD, the cash flow engine does not reference the Historical Rates to obtain the yield curve information that is one month before the CALENDAR_PERIOD. Instead, the cash flow engine applies the base rate from the Monte Carlo rate engine output.

Data Verification Requirements and Suggested Defaults

• RATE_SET_LAG must be either 0 or a positive value.

• If the record is a fixed-rate account, RATE_SET_LAG = 0.

• If the record is an adjustable-rate account, RATE_SET_LAG >= 0

  Note: Validation of RATE_SET_LAG should always be done in conjunction with RATE_SET_LAG_MULT.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Rate Set Lag Multiplier (RATE_SET_LAG_MULT)

Definition

Used in conjunction with RATE_SET_LAG to define the rate set lag period.

Module Usage

Oracle Transfer Pricing references RATE_SET_LAG_MULT when calculating option costs. RATE_SET_LAG_MULT determines the units (months, days, or years) of RATE_SET_LAG.

Data Verification Requirements and Suggested Defaults

• Valid values are:

  • D: Days

  • M: Months

  • Y: Years

• For information on RATE_SET_LAG_MULT validation, Rate Set Lag (RATE_SET_LAG).

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Remaining Number of Payments (REMAIN_NO_PMTS)

Definition

The remaining number of principal, interest, or principal and interest payments to be made from the CALENDAR_PERIOD until the MATURITY_DATE of the record.

Module Usage

The Oracle Transfer Pricing cash flow methodologies reference REMAIN_NO_PMTS when calculating and processing payments. The cash flow engine uses REMAIN_NO_PMTS to determine the number of payments that remain to be paid until the account matures.

The number of remaining payments is used by the cash flow engine for two purposes:

• Definition of payment dates on which principal and interest is to be paid: As each payment is made during the life of the instrument, the cash flow engine reduces the REMAIN_NO_PMTS by 1 and rolls the payment period forward by the PMT_FREQ. If the newly calculated REMAIN_NO_PMTS = 1, the cash flow engine no longer rolls the PMT_FREQ and makes the next (and final) payment on the MATURITY_DATE. See: Amortization Term (AMRT_TERM).

• Amortization recalculation purposes: When a recalculation occurs (repricing or negative amortization event), the cash flow engine references the REMAIN_NO_PMTS for recalculation of amortization. See: Current Payment (CUR_PAYMENT).

  There are some exceptions to the use of REMAIN_NO_PMTS for balloon records and specific user-defined payment patterns and schedules. Depending on the record characteristics, the cash flow engine may calculate the remaining number of payments itself. See: Amortization Term (AMRT_TERM).

1. The Transfer Pricing Remaining Term Pricing Basis cash flow methodology for fixed-rate records uses REMAIN_NO_PMTS as described above.

2. The Transfer Pricing Standard Pricing Basis cash flow methodology for an adjustable-rate record calculates the remaining number of payments as follows:

   REMAIN_NO_PMTS + number of payment periods between the NEXT_PAYMENT_DATE and the LAST_REPRICING_DATE

Data Verification Requirements and Suggested Defaults

• REMAIN_NO_PMTS >= 1.

• If REMAIN_NO_PMTS = 0, record is invalid.

• If REMAIN_NO_PMTS = 1, NEXT_PAYMENT_DATE = MATURITY_DATE.

• If REMAIN_NO_PMTS > 1, NEXT_PAYMENT_DATE < MATURITY_DATE.

• Generally:

  • REMAIN_NO_PMTS * PMT_FREQ <= ORG_TERM * ORG_TERM_MULT.

  • REMAIN_NO_PMTS * PMT_FREQ <= ISSUE_TERM * ISSUE_TERM_MULT.

  • MATURITY_DATE <= NEXT_PAYMENT_DATE + (REMAIN_NO_PMTS * PMT_FREQ).

• For non-term accounts, REMAIN_NO_PMTS = 1.

• The maximum number of payment and repricing events that can be modeled cannot exceed 2000. REMAIN_NO_PMTS + (REMAIN_TERM (in days)) / (REPRICE_FREQ (in days)) > 2000.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Repricing Frequency (REPRICE_FREQ)

Definition

Used in conjunction with REPRICE_FREQ_MULT to define the frequency of rate change of an account.

Module Usage

Oracle Transfer Pricing references REPRICE_FREQ when identifying adjustable-rate instruments and calculating a transfer pricing term or forecasted interest rate.

1. REPRICE_FREQ is used to identify whether records are adjustable or not. If REPRICE_FREQ > 0, the record is considered adjustable. If REPRICE_FREQ = 0, the record is fixed-rate.

2. For adjustable-rate straight term methodology, Oracle Transfer Pricing matches the REPRICE_FREQ to the same term on the Transfer Pricing yield curve (Interest Rate Code) defined in the Historical Rates Rule. See: Last Repricing Date (LAST_REPRICE_DATE).

When Calculate Option Costs is selected on the Transfer Pricing Process rule, the following applies:

1. In identifying an adjustable record, the cash flow engine uses ADJUSTABLE_ TYPE_CODE and REPRICE_FREQ. If the ADJUSTABLE_TYPE_CODE > 0 and the REPRICE_FREQ > 0, the record is adjustable.

2. The cash flow engine uses the REPRICE_FREQ to identify repricing events beyond the NEXT_ REPRICE_DATE. The cash flow engine rolls forward from NEXT_REPRICE_DATE by the REPRICE_FREQ to define the remaining forecasted reprice dates for the record. Rolling by the REPRICE_FREQ continues until MATURITY_DATE. See: Next Repricing Date (NEXT_REPRICE_DATE).

3. In defining the CUR_NET_RATE and CUR_GROSS_RATE on each reprice date, the cash flow engine matches the INTEREST_RATE_CODE, the reprice date, and the REPRICE_FREQ of the record to the appropriate term point on the forecasted Interest Rate Code (IRC) generated by Monte Carlo rate engine. To this derived rate, the cash flow engine adds the relevant margin amount (MARGIN, MARGIN_GROSS). Any rate caps/floors, tease periods, and rounding is then applied.

   Note: ADJUSTABLE_TYPE_CODE = 30 and 50 does not reference reprice date.

Data Verification Requirements and Suggested Defaults

• If REPRICE_FREQ > 0, MATURITY_DATE >= NEXT_REPRICE_DATE > CALENDAR PERIOD.

• If REPRICE_FREQ > 0, INTEREST_RATE_CODE is in the range of 1 - 99999.

• If REPRICE_FREQ > 0, ADJUSTABLE_TYPE_CODE > 0.

• REPRICE_FREQ must be either 0 or positive.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Repricing Frequency Multiplier (REPRICE_FREQ_MULT)

Definition

Used in conjunction with REPRICE_FREQ to define the frequency of rate change of an account.

Module Usage

Oracle Transfer Pricing references REPRICE_FREQ when identifying adjustable-rate instruments and calculating a transfer pricing term or forecasted interest rate. REPRICE_FREQ_MULT determines the units (months, days, or years) of REPRICE_FREQ.

Data Verification Requirements and Suggested Defaults

Valid values are:

• D: Days

• M: Months

• Y: Years

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Teaser-rate End Date (TEASER_END_DATE)

Definition

Date that the tease rate (introductory rate) ends and the normal product interest rate begins.

Module Usage

The cash flow engine references TEASER_END_DATE when calculating a forecasted interest rate. The TEASER_END_DATE defines the end of a tease period, which is an initial low interest rate period from the origination of a loan. At the TEASER_END_DATE, the low rate is repriced to a value defined by the market index plus margin.

1. Because TEASER_END_DATE overrides the other repricing fields, if a record is currently in its tease period, the last repricing date equals the ORIGINATION_DATE and the next repricing date equals the TEASER_END_DATE.

2. If the TEASER_END_DATE is greater than the CALENDAR_PERIOD, the Oracle Transfer Pricing mid-period repricing does not apply. See: Mid-period Repricing, Oracle Transfer Pricing User Guide.

If calculate Option Costs is selected on the Transfer Pricing Process rule, the following applies:

1. The cash flow engine does not adjust the rate on an adjustable-rate account until the TEASER_END_DATE is less than the current date within the cash flow timeline.

2. TEASER_END_DATE takes precedence over NEXT_REPRICE_DATE and REPRICE_FREQ. Even if NEXT_REPRICE_DATE < TEASER_END_DATE, the record does not reprice until the TEASER_END_DATE.

3. TEASER_END_DATE does not apply to fixed-rate accounts.

Data Verification Requirements and Suggested Defaults

• TEASER_END_DATE > ORIGINATION_DATE .

• TEASER_END_DATE < MATURITY_DATE.

• For fixed-rate accounts TEASER_END_DATE = 01-JAN-1900.

• TEASER_END_DATE >= NEXT_REPRICE_DATE.

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Transfer Rate (TRANSFER_RATE)

Definition

The associated transfer rate for the account, calculated using the Standard transfer pricing calculation mode.

Module Usage

After calculating the transfer rate for a record using one of the transfer pricing methodologies and the Standard transfer pricing calculation mode, the result is written out to the TRANSFER_RATE column.

Note: When the Remaining Term transfer pricing calculation mode is used, the transfer rate is written to the TRAN_RATE_REM_TERM field.

Data Verification Requirements and Suggested Defaults

If TRANSFER RATES are to be loaded directly from client systems, data must be in percent format (10% = 10 not 0.10).

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions

Transfer Rate Remaining Term (TRAN_RATE_REM_TERM)

Definition

The associated transfer rate for the account, using the Remaining Term transfer pricing calculation mode.

Module Usage

After calculating the transfer rate for a record using one of the transfer pricing methodologies and the Remaining Term transfer pricing calculation mode, the result is written out to the TRAN_RATE_REM_TERM column.

Note: When the Standard transfer pricing calculation mode is used, the transfer rate is written to the TRANSFER_RATE column.

Data Verification Requirements and Suggested Defaults

If TRAN_RATE_REM_TERM values are to be loaded directly from client systems, data must be in % format (10% = 10 not 0.10).

Related Topics

Overview of Cash Flow Columns

Cash Flow Column Descriptions