7Cash Flow Dictionary

This chapter includes a list of columns required for this processing as well as a list of columns required to run the Oracle Financial Services Analytical Applications (OFSAA) cash flow edits.

Topics:

· Introduction to Cash Flow Dictionary

· Cash Flow Columns

Introduction to Cash Flow Dictionary

Cash flow processing is executed from Oracle Asset Liability Management ( ALM) and Oracle Funds Transfer Pricing (FTP). This processing accesses specific fields from instrument tables to perform cash flow calculations.

The OFSAA cash flow edits are executed from either Oracle ALM or Oracle FTP and are used to correct data in the columns used in OFSAA cash flow processing.

NOTE:

Both lists overlap for a majority of the columns.

For OFSAA cash flow processing to generate appropriate results, the data within the accessed instrument tables must be appropriate and consistent. The OFSAA cash flow edits function provides a measure of validation for this data. However, the cash flow edits function cannot ensure that the input data from the instrument tables are correct, and faithfully reflects reality. Therefore, this chapter contains detailed information necessary for the correct data population, including field definitions, formulas used in the cash flow process calculations, and recommended default values for the cash flow processing fields.

Unless otherwise stated, when calculations refer to frequency or term fields in this chapter, the implication is that both the frequency (or term) and its associated multiplier field are used. For example, if PMT_FREQ is used in a formula, it refers to PMT_FREQ and PMT_FREQ_MULT to determine the true payment frequency.

Cash Flow Engine does support off-balance products, but Cash Flow Edits Engine does NOT support off-balance products.

Cash Flow Columns

This section describes in detail the cash flow processing and cash flow edit columns for OFSAA.

Cash Flow Columns Listed

The OFSAA cash flow columns are listed in table format in this section along with information on whether they are associated with cash flow processing, cash flow edits, or both.

Table 44: List of Cash Flow Columns
Column Name	Cash Flow Processing	Cash Flow Edits	Usage
ACCRUAL_BASIS_CD	Yes	Yes	Input
ACCRUED_INTEREST	Yes	Pending	Input
ADJUSTABLE_TYPE_CD	Yes	Yes	Input
ALL_IN_TP_RATE	Yes	No	Output
All Leaf Fields	Yes	No	Input/Output
AMORT_METH_PDFC_CD	Yes	Pending	Input
AMRT_TERM	Yes	Yes	Input
AMRT_TERM_MULT	Yes	Yes	Input
AMRT_TYPE_CD	Yes	Yes	Input
AS_OF_DATE	Yes	Yes	Input
AVERAGE_LIFE_C	Yes	No	Output
BASE_INDEX_VALUE	Yes	No	Input
BASIS_RISK_CHARGE_CREDIT	Yes	No	Output
BASIS_RISK_COST_AMT	Yes	No	Output
BASIS_RISK_COST_RATE	Yes	No	Output
BEHAVIOUR_SUB_TYPE_CD	Yes	Pending	Input
BEHAVIOUR_TYPE_CD	Yes	Pending	Input
BREAKAGE_TYPE_CD	Yes	No	Input
BREAK_FUNDING_MV	Yes	No	Output
BREAK_FUNDING_AMT	Yes	No	Output
BREAK_FUNDING_AMT_CHG	Yes	No	Output
CAP_PROTECTION_CATEGORY	Yes	No	Input
CHARGE_CREDIT_OCOST	Yes	No	Output
CHARGE_CREDIT_OCOST_REM_TERM	Yes	No	Output
CHARGE_CREDIT_TRATE	Yes	No	Output
CHARGE_CREDIT_TRATE_REM_TERM	Yes	No	Output
COMPOUND_BASIS_CD	Yes	Yes	Input
CONVEXITY_C	Yes	No	Output
CUR_BOOK_BAL	Yes	Yes	Input
CUR_GROSS_RATE	Yes	Yes	Input
CUR_NET_PAR_BAL_C	No	Yes	Input
CUR_NET_RATE	Yes	Yes	Input
CUR_OAS	Yes	No	Input/Output
CUR_PAR_BAL	Yes	Yes	Input
CUR_PAYMENT	Yes	Yes	Input
CUR_STATIC_SPREAD	Yes	No	Input
CUR_TP_PER_ADB	Yes	No	Input
CUR_YIELD	Yes	No	Output
DEFERRED_CUR_BAL	Yes	Yes	Input
DEFERRED_ORG_BAL	Yes	Yes	Input
DEVOLVEMENT_STATUS_CD	Yes	Pending	Input
DURATION_C	Yes	No	Output
DV01_C	Yes	No	Output
EFF_INTEREST_RATE_C	Yes	No	Output
EXPECTED_BAL	Yes	Pending	Input
EXPECTED_BAL_GROWTH_PCT	Yes	Pending	Input
HISTORIC_OAS	Yes	No	Output
HISTORIC_STATIC_SPREAD	Yes	No	Output
HOLIDAY_CALC_OPTION_CD	Yes	No	Input
HOLIDAY_CALENDAR_CODE	Yes	No	Input
HOLIDAY_ROLLING_CONVENTION_CD	Yes	No	Input
INDEX_ADJ_TYPE	Yes	No	Input
INDEX_ID	Yes	No	Input
ID_NUMBER	Yes	Yes	Input
IDENTITY_CODE	Yes	Yes	Input
INSTRUMENT_TYPE_CD	Yes	No	Input
INT_TYPE	Yes	Yes	Input
INTEREST_RATE_CD	Yes	Yes	Input
ISSUE_DATE	Yes	Yes	Input
LAST_PAYMENT_DATE	Yes	Yes	Input
LAST_REPRICE_DATE	Yes	Yes	Input
LIQUIDITY_PREM_CHARGE_CREDIT	Yes	No	Output
LIQUIDITY_PREMIUM_AMT	Yes	No	Output
LIQUIDITY_PREMIUM_RATE	Yes	No	Output
LRD_BALANCE	Yes	Yes	Input
LRD_OFFSET_BAL	Yes	No	Input
MARGIN	Yes	No	Input
MARGIN_T_RATE	Yes	No	Input
MARGIN_GROSS	Yes	No	Input
MARKET_VALUE_C	Yes	No	Output
MARKET_VALUE_CLEAN_C	Yes	No	Output
MATCHED_SPREAD_ALT	Yes	No	Output
MATCHED_SPREAD_C	Yes	No	Input
MATURITY_AMOUNT	Yes	Pending	Input
MATURITY_DATE	Yes	Yes	Input
MAX_INDEX_VALUE	Yes	No	Input
MINIMUM_BALANCE	Yes	Pending	Input
MODIFIED_DURATION_C	Yes	No	Output
NEG_AMRT_AMT	Yes	No	Output
NEG_AMRT_EQ_DATE	Yes	Yes	Input
NEG_AMRT_EQ_FREQ	Yes	Yes	Input
NEG_AMRT_EQ_MULT	Yes	Yes	Input
NEG_AMRT_LIMIT	Yes	Yes	Input
NET_MARGIN_CD	Yes	Yes	Input
NEXT_PAYMENT_DATE	Yes	Yes	Input
NEXT_REPRICE_DATE	Yes	Yes	Input
OFFSET_PERCENT	Yes	Pending	Input
ORG_BOOK_BAL	No	Yes	Input
ORIG_OFFSET_BAL	Yes	No	Input
ORG_MARKET_VALUE	Yes	No	Input
ORG_PAR_BAL	Yes	Yes	Input
ORG_PAYMENT_AMT	Yes	Yes	Input
ORG_TERM	Yes	Yes	Input
ORG_TERM_MULT	Yes	Yes	Input
ORIGINATION_DATE	Yes	Yes	Input
OTHER_ADJ_AMOUNT_ALT	Yes	No	Output
OTHER_ADJ_CHARGE_CREDIT	Yes	No	Output
OTHER_ADJ_RATE_ALT	Yes	No	Output
OTHER_ADJUSTMENTS_AMT	Yes	No	Output
OPTION_RFR_IRC_CD	Yes	Pending	Input
OPTION_VOL_IRC_CD	Yes	Pending	Input
OPTION_MARKET_VALUE_C	No	No	Output
OTHER_ADJUSTMENTS_RATE	Yes	No	Output
PERCENT_SOLD	Yes	Yes	Input
PMT_ADJUST_DATE	Yes	Yes	Input
PMT_CHG_FREQ	Yes	Yes	Input
PMT_CHG_FREQ_MULT	Yes	Yes	Input
PMT_DECR_CYCLE	Yes	Yes	Input
PMT_DECR_LIFE	Yes	Yes	Input
PMT_FREQ	Yes	Yes	Input
PMT_FREQ_MULT	Yes	Yes	Input
PMT_INCR_CYCLE	Yes	Yes	Input
PMT_INCR_LIFE	Yes	Yes	Input
PRICING_INC_CHARGE_CREDIT	Yes	No	Output
PRICING_INCENTIVE_AMT	Yes	No	Output
PRICING_INCENTIVE_RATE	Yes	No	Output
PRIOR_TP_PER_ADB	Yes	No	Input
PMT_SET_LAG	No	No	Input
PMT_SET_LAG_MULT	No	No	Input
RATE_CAP_LIFE	Yes	Yes	Input
RATE_CHG_MIN	Yes	Yes	Input
RATE_CHG_RND_CD	Yes	Yes	Input
RATE_CHG_RND_FAC	Yes	Yes	Input
RATE_DECR_CYCLE	Yes	Yes	Input
RATE_FLOOR_LIFE	Yes	Yes	Input
RATE_INCR_CYCLE	Yes	Yes	Input
RATE_SET_LAG	Yes	Yes	Input
RATE_SET_LAG_MULT	Yes	Yes	Input
RESIDUAL_AMOUNT	Yes	Pending	Input
REMAIN_NO_PMTS_C	Yes	Yes	Input
REMAIN_TERM_MULT_C	No	No	Input
REPRICE_FREQ	Yes	Yes	Input
REPRICE_FREQ_MULT	Yes	Yes	Input
TEASER_END_DATE	Yes	Yes	Input
TP_AVERAGE_LIFE	Yes	No	Input/Output
TP_DURATION	Yes	No	Input/Output
TP_EFFECTIVE_DATE	Yes	Pending	Input
TRAN_RATE_REM_TERM	Yes	No	Output
TRAN_RATE_REM_TERM_ALT	Yes	No	Output
TRANSFER_RATE	Yes	No	Input/Output
TRANSFER_RATE_ALT	Yes	No	Output
DERIVATIVE_ONLY_COLUMNS
BINARY_RATE	Yes	Pending	Input
EXCHG_OF_PRINCIPAL	Yes	Pending	Input
INSTRUMENT_TYPE_CD	Yes	Pending	Input
LEG_TYPE	Yes	Pending	Input
MIN_BAL_AMORT	Yes	Pending	Input
PURCHASE_SALE_LOGIC	Yes	Pending	Input
SWAP_CLASS_CD	Yes	Pending	Input

Field Definitions

This section describes, in detail, the usage of these columns. For each column, the following information is provided:

· Column name as it appears in the appendix (upper and lower case) and as it appears in the database (upper case with underscores).

· Which OFSAA products are affected (ALM or FTP)?

· Data verification requirements and suggested defaults.

Accrual Basis Code (ACCRUAL_BASIS_CD)

Definition

The basis on which the interest accrual is calculated.

Module Usage

Oracle ALM and Oracle FTP cash flow methodologies use ACCRUAL_BASIS_CD for calculating interest income (financial element 430).

The accrual basis values are represented by code values as follows.

Table 45: List of Cash Flow Columns
Code Value	Accrual Basis
1	30/360
2	Actual/360
3	Actual/Actual
4	30/365
5	30/Actual
6	Actual/365
7	Business/252

NOTE:

For BUS/252 Accrual Basis: As a prerequisite, a holiday calendar must be defined, so the engine can determine the number of business days for the numerator (BUS). If Holiday calendar is not selected, and accrual basis code is BUS/252, then it defaults to Actual/Actual

Oracle ALM and Oracle FTP cash flow methodologies reference INT_TYPE in determining whether interest payments are made in arrears or in advance.

· If INT_TYPE = 1, the record is considered an interest in arrears. Interest payments are paid at the end of the payment period along with the principal payments. The following calculations assume that the interest is to be calculated as an interest in arrears.

· If INT_TYPE = 2, the record is considered interest in advance.

For calculation purposes, the accrual basis codes can be grouped in the following manner.

NOTE:

The following calculations assume a monthly payment frequency.

· If the ACCRUAL_BASIS_CD is 30/360, 30/365 or 30/Actual, OFSAA uses the following formula to calculate interest income on a payment date:

Previous Period's 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 mentioned earlier.

NOTE:

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 earlier 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 done for the following use cases:

§ For stub or extended payment at the origination or maturity of a record, where for the first forecasted payment, the Last Payment Date is not necessarily equal to the Calculated Last Payment Date.

§ For Payment dates impacted by Holiday adjustment (when Holiday calculation method is Recalculate Payment).

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

NOTE:

When interest calculated for days, see following scenarios:

1. Payment period (PMT_FREQ_MULT) is in days

2. Reprice period (REPIRCE_FREQ_MULT) is in days, applicable for adjustable/floating record.

3. Multiple repricing records, where a record reprices multiple times within a payment period, whenever interest calculated for days. For example, interest calculated from 6/30/2017 (NEXT_PAYMENT_DATE) to 7/15/2017 (NEXT_REPRICE_DATE) for 15 days.

4. When the payment/reprice date gets Holiday adjusted with holiday calculation as ‘Recalculate Payment’. Multiple repricing record, where a record reprices/payment dates get Holiday adjusted with holiday calculation as ‘Recalculate Payment’.

5. A record with the accrual basis of 30/360, 30/365, and 30/Actual is converted into Actual/365. A record having 30/365 convention, is converted into Actual/365 multiplied by the ratio of (360/365). For a record with 30/Actual accrual is converted into Actual/365 and is multiplied by the ratio of (360/Actual).

If the ACCRUAL_BASIS_CD is Actual/365, Actual/Actual, or Actual/360, OFSAA uses the following formula to calculate interest income on a payment date:

· Previous Period's Ending Balance * Cur Net Rate/100 * (Next Payment Date - Last Payment Date)/y

· Replace y with the denominator of one of the three accrual basis values mentioned earlier.

The actual numerator refers to the actual number of days in the current month.

The preceding two equations represent Interest in Arrears income calculations. The interest in advance calculations is indicated in the INT_TYPE section.

· If a compounding method has been chosen, OFSAA derives the compounded rate before calculating the preceding interest income amounts.

· If the ACCRUAL_BASIS_CD is Business/252, the following formula is used to calculate interest income on a payment date:

Previous Period's Ending Balance * Cur Net Rate/100* (Next Payment Date-Last Payment Date-y)/(252)

Here, y is the number of holidays/weekend days in the payment period.

Interest cash flow will be paid out on the next payment date. If the next payment turns out to be a holiday and you have selected the option of “Recalculate payment”, then the calculation will use the holiday adjusted next payment date and holiday adjusted last payment date in the calculation and payout on the holiday adjusted next payment date. If you have selected the “Shift Dates only” option, then the calculated interest cashflow will be output to the adjusted payment date with no recalculation of interest income.

Data Verification Requirements and Suggested Defaults

· Must be equal to values 1 -7.

· Suggested default depends on the product characteristics of the institution's data. Default to the most common ACCRUAL_BASIS_CD for the product leaf.

· If AMRT_TYPE_CD = 800, 801, or 802 (Schedule) or 1000 to 99999 (Pattern), the ACCRUAL_BASIS_CD cannot equal 1, 4 or 5.

Accrued Interest (ACCRUED_INTEREST)

Definition

Calculated interest due from the last payment date to the as of date.

Module Usage

For Oracle ALM, this field is used for Non-Maturity Behavior Pattern instruments, instruments that get repriced multiple times within a payment event, and for Annuity instruments.

1. For Non- Maturity Behavior Pattern instrument, Accrued interest provided is used to compute the first interest cash flow on the next_payment_date. If this information is available from the source system, the cash flow engine will be able to more accurately reflect the interest cash flow due to the next interest cash flow date (NEXT_PAYMENT_DATE). The cash flow engine combines the ACCRUED_INTEREST amount (up to the AS_OF_DATE) with a calculated interest from the AS_OF_DATE + 1day to the NEXT_PAYMENT_DATE.

NOTE:

For Non-Maturity Behavior Patterns, the principal payments are determined based on the pattern dates, and the interest payments are determined based on the NEXT_PAYMENT_DATE and PMT_FREQ from the instrument record.

2. When an adjustable Instrument gets repriced more than once from the last payment date to as of date, Engine expects Accrued Interest from LAST_PAYMENT_DATE till as of date to be supplied in the column ACCRUED_INTEREST for a more accurate reflection of Interest cash flow on next payment date.

If an Instrument gets repriced more than once from the last payment date till as of date, there will be multiple repriced rates to consider for that period, and the engine would not be able to go back to historical reprice rates between last payment date and as of date. It will use the current rate (CUR_NET_RATE) of the instrument and calculate interest from the last payment date until the next payment date. This could lead to incorrect initial interest cash flow on the next payment date. As an alternate, for these scenarios, the user can provide Accrued Interest for the period from last payment date till as of date, and the engine will calculate interest from as of date ass till next payment date, and add provided Accrued interest to get total interest cash flow on next payment date.

NOTE:

If Accrued interest is provided, the engine will use it in processing for the above notes scenarios. If the instrument is FIXED RATE (adjustable_type_cd= 0), then Interest is calculated from the Last Payment date till Next Payment Date

3. Annuity instruments (AMRT_TYPE_CD=850) use this field to store the accrued Interest from ORIGINATION_DATE of the instrument to As of Date. For Annuity, interest accumulates from origination date until Maturity.

On each payment date, the balance of the Annuity instrument increases with the payment amount. Also if these instruments are adjustable (ADUSTABLE_TYPE_CD= 250), rates will change from Origination Date to As of Date. The engine would not be able to go back in historical dates to calculate interest, considering the change in balance or rates, from origination.

To obtain proper interest, for both fixed and adjustable rates, it is recommended to provide accrued interest from the Origination date to As of date. When accrued interest is supplied, the cash flow engine would calculate Interest from As of date forward, and add provided accrued interest for proper total Interest cash flow population. The last payment date can be kept as the actual date as the cash flow engine will ignore the Last payment date in this case.

If the accrued interest is not available, and if you want to calculate interest from the Origination date, you can set the Last payment date = Origination date, however, interest will vary based on past payments and or rate changes.

Data Verification Requirements and Suggested Defaults

· Should be > 0 for non-maturity behavior pattern instruments.

· For non-maturity behavior pattern instruments, set LAST_PAYMENT_DATE = AS_OF_DATE.

· For non-maturity behavior pattern instruments, set NEXT_PAYMENT_DATE equal to the next expected interest payment date.

· For non-maturity behavior pattern instruments, set PMT_FREQ equal to the interest payment frequency.

Accrued Gross Amount (ACCRUED_GROSS_AMT)

Definition

Calculated gross interest due from the last payment date to the as of date.

Module Usage

For Oracle ALM, this field is used for Non-Maturity Behavior Pattern instruments, instruments that get repriced multiple times within a payment event.

1. For Non- Maturity Behavior Pattern instrument, Accrued gross amount provided is used to compute the first interest cash flow gross on the next_payment_date. If this information is available from the source system, the cash flow engine will be able to more accurately reflect the interest cash flow gross due to the next interest cash flow date (NEXT_PAYMENT_DATE). The cash flow engine combines the ACCRUED_GROSS_AMT (up to the AS_OF_DATE) with a calculated interest from the AS_OF_DATE + 1day to the NEXT_PAYMENT_DATE.

NOTE:

2. When an adjustable Instrument gets repriced more than once from the last payment date to as of date, Engine expects Accrued gross amount from LAST_PAYMENT_DATE till as of date to be supplied in the column ACCRUED_GROSS_AMT for a more accurate reflection of Interest cash flow gross on next payment date.

If an Instrument gets repriced more than once from the last payment date till as of date, there will be multiple repriced rates to consider for that period, and the engine would not be able to go back to historical reprice rates between last payment date and as of date. It will use the current gross (CUR_GROSS_RATE) of the instrument and calculate interest gross from the last payment date till the next payment date. This could lead to incorrect initial interest cash flow gross on the next payment date. As an alternate, for these scenarios, user can provide an Accrued gross amount for the period from last payment date till as of date, and the engine will calculate interest gross from as of date till next payment date, and add provided Accrued gross amount to get total interest cash flow gross on next payment date.

NOTE:

If an Accrued gross amount is provided, the engine will use it in processing for the above notes scenarios. If the instrument is FIXED RATE (adjustable_type_cd= 0), then the Interest gross is calculated from the Last Payment date till Next Payment Date.

Data Verification Requirements and Suggested Defaults

· Should be > 0 for non-maturity behavior pattern instruments.

Accrued Transfer Amount (ACCRUED_TRANSFER_AMT)

Definition

Calculated interest (transfer) due to the last payment date to the as of date.

Module Usage

For Oracle ALM, this field is used for Non-Maturity Behavior Pattern instruments, instruments that get repriced multiple times within a payment event, and for Annuity instruments.

1. For Non- Maturity Behavior Pattern instrument, Accrued transfer interest provided is used to compute the first interest cash flow transfer (tp) on the next_payment_date. If this information is available from the source system, the cash flow engine will be able to more accurately reflect the interest cash flow tp due to the next interest cash flow date (NEXT_PAYMENT_DATE). The cash flow engine combines the ACCRUED_TRANSFER_AMT (up to the AS_OF_DATE) with a calculated interest from the AS_OF_DATE + 1day to the NEXT_PAYMENT_DATE.

NOTE:

For Non-Maturity Behavior, Pattern fixed records (ADJUSTABLE_TYPEC_D=0), when Accrued Transfer Interest is provided, ensure to provide LAST_PAYMENT_DATE equal to AS_OF_DATE.

2. When an adjustable Instrument gets repriced more than once from the last payment date to as of date, the Engine expects Accrued transfer amount from LAST_PAYMENT_DATE till as of date to be supplied in the column ACCRUED_TRASNFER_AMT for a more accurate reflection of Interest cash flow tp on next payment date.

If an Instrument gets repriced more than once from the last payment date till as of date, there will be multiple repriced rates to consider for that period, and the engine would not be able to go back to historical reprice rates between last payment date and as of date. It will use the current transfer (TRANSFER_RATE) of the instrument and calculate interest tp from the last payment date till the next payment date. This could lead to incorrect initial interest cash flow tp on the next payment date. As an alternate, for these scenarios, user can provide Accrued transfer amount for the period from last payment date till as of date, and the engine will calculate interest tp from as of date till next payment date, and add provided Accrued transfer amount to get total interest cash flow tp on next payment date.

If the Accrued transfer amount is provided, the engine will use it in processing for the above notes scenarios. If the instrument is FIXED RATE (adjustable_type_cd= 0), then Interest tp is calculated from the Last Payment date till Next Payment Date

Data Verification Requirements and Suggested Defaults

· Should be > 0 for non-maturity behavior pattern instruments.

Adjustable Type Code (ADJUSTABLE_TYPE_CD)

Definition

Identifies the repricing method and repricing characteristics of the record.

Module Usage

For Oracle ALM, this field works in conjunction with REPRICE_FREQ to determine the repricing characteristics of an instrument. An ADJUSTABLE_TYPE_CD must be specified if the record is expected to reprice.

Oracle ALM

The code values for this field are as follows:

Table 46: List of 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.*
300	Tiered Balance Interest Rate	If using FTP, reprice frequency should be specified for each tier record.FTP requires this information to determine if a tier record is fixed or adjustable-rate	Depends on Adjustable Type of tier record(s)
500-99999	Reprice Pattern	> 0	Reprices based on pattern definition

*(if not in tease period)

§ If the ADJUSTABLE_TYPE_CD = 0 and the REPRICE_FREQ = 0, then the record is fixed-rate.

§ If the ADJUSTABLE_TYPE_CD = 30 or 50 and the REPRICE_FREQ > 0, then the reprice dates are driven by forecasted yield curve rate changes rather than by the REPRICE_FREQ. For these codes, Oracle ALM reprices the record by referencing the Forecast Rate Assumption - interest rate code (IRC) when producing cash flow information at the beginning of each bucket. There is one reference to the IRC per modeling bucket.

The database field, NEXT_REPRICE_DATE, is not used when the ADJUSTABLE_TYPE_CD = 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_CD should not be used for instruments with periodic caps and/or floors because periodic caps and floors infer a specific repricing frequency.

§ If the ADJUSTABLE_TYPE_CD = 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 fields for further explanations of the repricing process.

NOTE:

Records where REPRICE FREQ is frequent, say 1 DAY, user can either model it using ADJUSTABLE_TYPE_CD of 250 (Adjustable) with REPRICE FREQ as 1 D, or using ADJUSTABLE_TYPE_CD as 50 (Floating Rate). As each modeling time bucket has a single forecasted rate for a specific Interest Rate Term Point, the engine would fetch the same rate for ‘n’ number of repricing falling in that modeling time bucket. Both models are equivalent from a business perspective, but use ADJUSTABLE_TYPE_CD as 50 would provide processing efficiency.

4. The value input into theADJUSTABLE_TYPE_CD overrides the REPRICE_ FREQ value. For instance, even though the REPRICE_FREQ > 0 and if the ADJUSTABLE_TYPE_CD = 0, OFSAA treats the record as a fixed-rate instrument.

5. When an Instrument gets repriced more than once within a payment period, the engine uses the rates for each repricing period within a payment period as prevailing and calculate the interest payment. This is applicable only for Multiple Reprice rates/events in one payment period – Interest in Arrears.

For scenarios where the instrument gets repriced multiple times from LAST_PAYMENT_DATE to as of date, the interest cash flow calculation uses Accrued interest, if provided, and adds it with calculated interest from as of date till next payment date. If accrued interest is not provided, interest is calculated from the last payment date till the Next payment date.

6. ADJUSTABLE_TYPE_CD = 300 is used when a different interest rate is paid/charged for parts of an account balance that fall within set amount ranges. In such a case, additional data for each balance tier is required in table FSI_D_ACCOUNT_RATE_TIERS (sourced from STG_ACCOUNT_RATE_TIERS).For more details, see Tiered Balance Interest Rate.

Oracle Funds Transfer Pricing

Oracle Funds Transfer Pricing references REPRICE_FREQ to determine if the record is an adjustable-rate instrument.

Data Verification Requirements and Suggested Defaults

· If the record is a floating rate or administered rate product, ADJUSTABLE_ TYPE_CD = 30 or 50.

· If the record reprices contractually according to NEXT_REPRICE_DATE and REPRICE_FREQ information, ADJUSTABLE_TYPE_CD = 250.

· If the ADJUSTABLE_TYPE_CD > 0, REPRICE_FREQ > 0.

· If the record is fixed, ADJUSTABLE_TYPE_CD = 0.

All - in Transfer Rate (ALL_IN_TP_RATE)

Definition

The Transfer Pricing Engine outputs the All-in transfer rate that includes the base transfer pricing (TP) rate plus any defined transfer rate adjustments. The components of the All-in TP rate are defined in the Standard Transfer Pricing Process, Calculation Elements block.

Module Usage

This field is populated (optionally) by the FTP Process and represents the total of the base transfer rate plus any standard transfer rate adjustments.

Data Verification Requirements and Suggested Defaults

None

Amortization Method for Premiums and Discounts (AMORT_METH_PDFC_CD)

Definition

Code to indicate how the cash flow engine should amortize (or accrete) a discount or premium amount or fee amount. The amount considered for amortization on the instrument record is defined by the DEFERRED_CUR_BAL.

Module Usage

Premium and discount instruments use this field to indicate the method to amortize/accrete. Values are 0=Level Yield, 1=Straight Line. This input is read by the cash flow engine when the DEFERRED_CUR_BAL is > 0. See Deferred Current Balance (DEFERRED_CUR_BAL) for a description of the Level Yield calculation.

Data Verification Requirements and Suggested Defaults

If the DEFERRED_CUR_BAL < > 0 then AMORT_METH_PDFC_CD must be populated with 0 (default) or 1.

Amortization Type Code (AMRT_TYPE_CD)

Definition

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

Module Usage

Oracle ALM and Funds Transfer Pricing cash flow methodologies use AMRT_ TYPE_CD to determine the calculation method of the record's amortization of principal and the resulting calculation of interest. The following are the supported AMRT_TYPE code values.

Table 47: List of Conventionally Amortization Type Code Values
Conventionally Amortizing	Description
100	Conventional Fixed
400	Balloon
500	Adjustable Conventional
600	Adjustable Negative Amortizing
840	Lease

Table 48 : List of Non-Conventionally Amortization Type Code Values
Non Conventionally Amortizing	Description
700	Simple Interest
710	Rule of 78s
800 - 802	Payment Schedules
820	Level Principal
850	Annuity
999	Default Value
1000 - 69999	User-Defined Payment Patterns
70000-99999	User-Defined Behavior Patterns

The following are the explanations of each of the amortization type codes.

100, 400, 500, 600, 840 - Conventionally Amortizing AMRT_TYPE_CDs

Description of amortization type codes follows

The conventional amortization loan types have loan payments that are unevenly divided between principal balance and interest owed. The 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 record's interest rate and the remaining balance of the loan. Therefore, close to the loan's origination, a higher portion of the payment consists of interest rather than principal. As the loan is paid down, an increasing portion of each payment is allocated to the principal until a zero balance is reached at maturity.

NOTE:

For Lease amortization, the principal is reduced to the amount defined in the RESIDUAL_AMOUNT column rather than zero.

For these five AMRT_TYPE_CDs, the amount in the CUR_PAYMENT and/or ORG_PAYMENT_AMT fields should equal the principal plus interest.

Following is a breakout of these four conventionally amortizing AMRT_TYPE_CDs:

Table 49: Conventionally Amortizing AMRT_TYPE_CDs
Conventional Loan Type	Description
100 Conventional Fixed	(Described earlier)
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 the non-amortized loan balance.
500 Conventional Adjustable	Repricing instrument with conventional amortization.
600 Adjustable Neg Am	In a negatively amortizing instrument, the principal of a loan increase 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. For more details, see Negative Amortization Amount (NEG_AMRT_AMT)
840 Lease	A lease instrument amortizes down to the amount specified in the RESIDUAL_AMOUNT column.The CUR_PAYMENT and/or ORG_PAYMENT_AMT for a fixed rate lease should be entered so the instrument will achieve the RESIDUAL_AMOUNT on the MATURITY_DATE of the lease contract.For an adjustable-rate lease, the CUR_PAYMENT will be re-calculated by the cash flow engine considering the MATURITY_DATE, RESIDUAL_AMOUNT, and Current Rate.

The OFSAA cash flow engine does not treat AMRT_TYPE_CD 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_CD 100 can be used for a fixed-rate, adjustable-rate, or a balloon record. However, only an AMRT_ TYPE 600 record uses the negative amortization fields.

The cash flow engine does not use AMRT_TYPE_CD to identify whether a record is adjustable or not. It instead uses REPRICE_FREQ (and in Oracle ALM, ADJUSTABLE_TYPE_CD) for this purpose. Therefore, any amortization type can be adjustable.

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

A record must be AMRT_TYPE_CD 600 for the cash flow engine to process the record using the negative amortization fields.

A record must be AMRT_TYPE_CD 840 for the cash flow engine to process the record using the residual amount field.

700 Simple Interest (Non-amortizing)

Description of amortization type codes follows

For simple interest amortization type, no principal is paid until maturity. If NEXT_ PAYMENT_DATE < MATURITY_DATE, OFSA calculates interim interest-only payments as shown in the earlier diagram. OFSA pays the entire record's principal balance on the maturity date along with the appropriate interest amount.

For this AMRT_TYPE_CD, the CUR_PAYMENT and/or ORG_PAYMENT_AMT fields should equal 0.

710: Rule of 78s

An amortization type in which the following calculation is used in 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_CDs, the amount in the CUR_PAYMENT and/or ORG_PAYMENT_AMT field should equal the principal plus interest. For more details, see the Cash Flow Calculation Process

800 - 802: Payment Schedule

The key to matching the instrument record with its corresponding payment schedule record is the INSTRUMENT_TYPE_CD and ID_NUMBER.

800:Conventional Payment Schedule

This AMRT_TYPE_CD conventionally amortizes a record whose cash flows are defined in the PAYMENT_SCHEDULE table. Payment amounts should contain both principal + interest. Engine calculates Interest on provided schedule dates. The principal amount gets calculated as the difference between the Payment amount provided – Interest cash flow calculated on that date.

For example, if for a specific schedule date Payment amount provided is USD 55,000, and Interest calculated by the engine is USD 30,000. For this date, Principal amount populated would be = USD 55,000- USD 30,000= USD 25,000. The interest amount populated would be USD 30,000.

801: Level Principal Payment Schedule

This AMRT_TYPE_CD level principal amortizes a record whose cash flows are defined in the PAYMENT_SCHEDULE table. Payment amounts should contain the principal only. Engine calculates Interest on provided schedule dates.

For example, if for a specific schedule date Payment amount provided is USD 55,000, and Interest calculated by the engine is USD 30,000. For this date, the Principal amount populated would be equal to the payment amount provided, and the Interest amount populated would be USD 30,000.

802: Simple interest Payment Schedule

This AMRT_TYPE_CD simple interest amortizes a record whose cash flow dates are defined in the PAYMENT_ SCHEDULE table. Payment amounts should equal 0 (the engine calculates interest and ignores payment amount in the schedule records). The principal balance is paid on the maturity date as defined in the schedule.

820 Level Principal Payments

Description of amortization type codes follows

The level of principal payment is the amortization type in which the principal portion of the loan payment remains constant for the life of the 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. Because the principal portion of the paymentis constant for life, the total payment amount (principal plus interest) decreases as the loan approaches maturity.

For this AMRT_TYPE_CD, the amount in CUR_PAYMENT and ORG_PAYMENT_AMT fields should equal the principal portion only.

850 Annuities

The Annuity amortization type assumes the payment amount (CUR_PAYMENT and/or ORG_PAYMENT_AMT) will increase the principal balance rather than reduce it.

For this AMRT_TYPE_CD, the amount in the CUR_PAYMENT and/or ORG_PAYMENT_AMT fields should equal the amount of the regular / scheduled principal contribution. The CUR_PAYMENT and/or ORG_PAYMENT_AMT should be expressed as a positive value and the cash flow engine will multiply by -1 to reflect the principal contribution.

Users can also, optionally populate the MATURITY_AMOUNT column. If populated, this amount will be considered as the target amount and the required periodic payment will be calculated to achieve the Maturity Amount at the maturity of the instrument.

Interest from the origination of the annuity instrument is settled on maturity. On each payment date, the balance of the Annuity instrument increases with the payment amount. Also, if the record is adjustable, rates will change from origination to as of date. The engine does not look back to historical dates to calculate interest, considering the change in balance or rates, from origination. To obtain proper interest for both fixed and adjustable rates, we recommend providing accrued interest from the Origination date and keep the actual Last payment date. When accrued interest is supplied, the engine would calculate Interest from as of date forward, and add provided accrued interest for proper total interest cash flow population. If the accrued interest is not available, and if you want to calculate interest from the Origination date, you can set the Last payment date = Origination date, however, interest will vary based on past payments and or rate changes.

1000 - 69999: User-Defined Payment Patterns

Records with this range of AMRT_TYPE_CDs are matched to the user-defined amortizations in the Payment Pattern user interface. The key for matching is the AMRT_TYPE_CD value. These records can only be defined as conventionally amortizing, level-principal, or simple interest.

70000-99999: User-Defined Behavior Patterns

Records with this range of AMRT_TYPE_CDs are matched to the user-defined amortizations in the Behavior Pattern user interface. The key for matching is the AMRT_TYPE_CD value.

You can attach a behavior pattern code to a Behavior Pattern Rule, if you do not want to update BP code at instrument level, and want to have scenario-based BP runoff.

If behavior pattern code is not attached to a Behavior Pattern Rule, then the engine behaves as in an existing manner. That is, the Amortization type of instrument will apply to current business and Behavior Pattern from Product Characteristics to new business.

For more information, see the OFS ALM User Guide.

999: Other Amortization Type

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

Data Verification Requirements and Suggested Defaults

· All accounts require a valid AMRT_TYPE_CD as listed earlier.

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

· If the record defaults to AMRT_TYPE_CD 999, or if it cannot find a match in PAYMENT_SCHEDULE or PAYMENT_PATTERNS, the cash flow engine processes the record as AMRT_TYPE_CD 700.

· Suggested defaults in the following table are dependent on basic knowledge of product characteristics:

Table 50: Suggested defaults for product characteristics
Loan Type	Suggested AMRT_TYPE_CD
Non-amortizing, such as Certificates of Deposit	700
Fixed amortizing, such as short term consumer loans	100
Variable-rate amortizing, such as adjustable-rate mortgages	500

· Rule of 78s instruments is implicitly fixed.

· If AMRT_TYPE_CD = 710, REPRICE_FREQ = 0.

Oracle Funds Transfer Pricing

Any invalid AMRT TYPE code will default to 700 (Non-Conventionally amortization value).

Amortization Term (AMRT_TERM)

Definition

The amortization term is used in conjunction with AMRT_TERM_MULT to define the term over which the payment is amortized.

Module Usage

AMRT_TERM is used by Oracle ALM and Funds Transfer Pricing for adjust-able-rate cash flow transfer-priced records.

Amortization Term

Amortization term has two main purposes:

· Identifies whether a record is a balloon and is used in the 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 user interface.

Balloon Check

As an initial step before processing a record's cash flows, the cash flow engine compares the record's ORG_TERM with its AMRT_TERM. If AMRT_TERM = ORG_TERM. The cash flow engine then uses the CUR_PAYMENT from the record. When appropriate, the cash flow engine later recalculates the CUR_PAYMENT if 1) The record reprices; 2) The TEASER_END_ DATE is reached, or 3) 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. To perform this calculation, the cash flow engine must derive the remaining number of payments until the end of the amortization term. This is calculated by adding the AMRT_TERM to the ORIGINATION_DATE to determine the amortization end date. The remaining number of payments is calculated by determining how many payments can be made from and including the NEXT_PAYMENT_DATE and this date. Following is the formula used for determining the remaining number of payments:

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

Beginning of Payment Period Date refers to the date of the current payment that the cash flow engine is calculating. This would equal the detail record's NEXT_PAYMENT DATE if the engine were calculating the first forecasted cash flow. After the remaining number of payments have been calculated, the cash flow engine derives the CUR_PAYMENT amount and applies it to the record's cash flows. Ignoring repricings and other recalculation events, this payment amount is paid until maturity, at which time the cash flow engine pays the record's balloon payment (the remaining principal portion).

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 user interface also recalculate the payment amount using the earlier 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.

Amortization Term Multiplier (AMRT_TERM_MULT)

Definition

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

Module Usage

This field is the multiplier of the AMRT_TERM field. It is used in conjunction with AMRT_TERM to define the term over which the payment is amortized. Oracle ALM and Funds Transfer Pricing cash flow transfer-priced records reference AMRT_TERM_MULT when recalculating the current payment as defined under the AMRT_TERM section. 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

As of Date (AS_OF_DATE)

Definition

The date that the extracted data represents.

Module Usage

AS_OF_DATE is used for the following purposes:

· Application Preferences filter (Oracle ALM and Oracle FTP)

· Market value calculations (Oracle ALM)

t calculation

The term cash flow from AS_OF_DATE is used for matching cash flow for discounting purposes.

· Payment Schedules and Patterns - used to determine where in the life of the loan the record is.

· Transfer Pricing Remaining Term Pricing Basis

Application Preferences

Oracle ALM and Oracle FTP use AS_OF_DATE as a primary data filter. When executing an ALM or Transfer Pricing processing run, the engines compare the AS_OF_DATE in Application Preferences, against the AS_ OF_DATE field of the detail instrument record. If AS_OF_DATE from the instrument record is the same date as that from Application Preferences, then engines process the instrument record. Otherwise, engines do not process the instrument record.

Market Value Calculations

· When calculating the market valuation of a daily paying record (PMT_FREQ_MULT = D), Oracle ALM uses the AS_OF_DATE when calculating the t period variable.

· For the Oracle ALM Discount Methods - Spot Interest Rate Code and Forecast Remaining Term methods, the AS_OF_DATE is used in calculating the cash flow's discounting term. The cash flow date (the payment date) is subtracted from the AS_OF_DATE to determine this term. This term is then applied to the appropriate discount yield curve in the Oracle ALM Forecast Rates assumption rule to determine the discount rate for the record (after applying the indicated interpolation method).

Payment Schedules and User-Defined Payment Patterns

· Relative Patterns - AS_OF_DATE is used to determine where in the life of a Payment Pattern a record is currently positioned. For relative patterns, the Payment Frequencies specified in the Pattern interface are rolled forward from the ORIGINATION_DATE until the rolled date is greater than the AS_OF_ DATE.

· Absolute Patterns - In determining the first forecasted payment date, the cash flow engine selects the payment date in the pattern that corresponds to the first date after the AS_OF_DATE.

NOTE:

If NEXT_PAYMENT_DATE is different from the next defined payment date in the absolute pattern, the NEXT_ PAYMENT_DATE is used instead. Therefore, the cash flow engine requires that the NEXT_PAYMENT_DATE correspond to the appropriate date in the absolute payment pattern.

· Payment Schedules – the cash flow engine makes the first forecasted payment based on the first date in the payment schedule table after the AS_OF_DATE.

Transfer Pricing Remaining Term Pricing Basis

When the Remaining Term Pricing Basis is selected for Transfer Pricing, transfer rates for the relevant methodologies are calculated from the AS_OF_DATE.

Data Verification Requirements and Suggested Defaults

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

· AS_OF_DATE = MATURITY_DATE – REMAIN_TERM_C

· AS_OF_DATE < NEXT_REPRICE_DATE

· AS_OF_DATE < NEXT_PAYMENT_DATE

· AS_OF_DATE < MATURITY_DATE

· AS_OF_DATE >= ORIGINATION_DATE

· AS_OF_DATE >= ISSUE_DATE

· AS_OF_DATE < PMT_ADJUST_DATE

· AS_OF_DATE >= LAST_PAYMENT_DATE

· AS_OF_DATE >= LAST_REPRICE_DATE

Average Book Balance (AVG_BOOK_BAL)

Definition

Represents the monthly or month to date Average Book Balance of the account.

Model Usages

Average Balance is typically used in Funds Transfer Pricing for calculating instrument level charge/credit amounts by customers who run their FTP process monthly, because it gives the best approximation of the balance over the entire month and will result in a funds charge/credit amount that closely matches the interest income or expense for the account.

Note:The most accurate way to compute funds charges/credits is to run the calculation daily using end of day balances and accrue the charges/credits over the entire month.This approach will exactly match with the interest accruals.Use of Average balance as described above is the next best option.

In Funds Transfer Pricing, when using Average Balance, along with a monthly accrual, the charge/credit calculation is as follows:

AVG_BOOK_BALx TRANSFER_RATE/100 x Monthly Accrual Factor (e.g. ACT/ACT)

Data Verification Requirements and Suggested Defaults

None

Average Life Calculated (AVERAGE_LIFE_C)

Definition

The average life of a loan is the average number of years that the principal is outstanding. The calculated amount represents the time necessary for the principal to be reduced by one half of its current value.

Module Usage

This financial measure is calculated by Oracle ALM when the corresponding Calculation Element is selected and the result is written to FSI_O_RESULT_MASTER and FSI_O_CONSOLIDATED_MASTER. Users can additionally update each instrument record with the calculation result by selecting the related measure in Output Preferences.

Oracle FTP computes the Average Life when the Average Life TP Method is applied to an instrument record. With this TP Method, the user has the additional option to update the instrument record with the calculation results (TP_AVERAGE_LIFE). For more information on the Average Life TP Method, see the Oracle Financial Services Funds Transfer Pricing User Guide.

The cash flow engine calculates the average life using the following formula:

Title: Description of the Average Life formula follows - Description: The illustration shows the formula to calculate the Average Life.

Description of the Average Life formula follows

Where:

P is the principal

Pi is the principal repayment in coupon i, hence,

is the fraction of the principal repaid in coupon i and ti is the time from the start of coupon i.

Data Verification Requirements and Suggested Defaults

None

Base Index Value (BASE_INDEX_VALUE)

Definition

Represents Base index value to be provided for Inflation-Indexed Instruments.

Module Usage

Oracle ALM reference BASE_INDEX_VALUE to calculate Index Factor, for the inflation-indexed instrument.

For Index factor calculation, see Inflation-Indexed Instrument.

Data Verification Requirements and Suggested Defaults

None

Basis Risk Charge Credit (BASIS_RISK_CHARGE_CREDIT)

Definition

Oracle FTP calculates the funds charge or credit due to basis risk when the user selects the Adjustments, Charge/Credit option in the TP Process – Calculation Elements block.

Module Usage

This field is populated by the FTP process (optionally) if selected in the Calculation Elements block. The TP Engine calculates this amount as follows:

AVG_BOOK_BAL or CUR_BOOK_BAL X BASIS_RISK_COST_RATE/100 X ACCRUAL BASIS

NOTE:

The balance referenced in the preceding calculation is selected in the FTP Application Preferences screen.

Data Verification Requirements and Suggested Defaults

None

Basis Risk Cost Amount (BASIS_RISK_COST_AMT)

Definition

Oracle Funds Transfer Pricing populates this field (optionally) when the user specifies a Basis Risk Cost amount in the TP Adjustment Rule.

Module Usage

This field is related to FTP Adjustment Rules. When the basis risk adjustment type is defined and included in the TP process, the TP Engine calculates and populates this field according to the amount input by the user through the Adjustment Rule user interface.

Data Verification Requirements and Suggested Defaults

None

Basis Risk Cost Rate (BASIS_RISK_COST_RATE)

Definition

Oracle Funds Transfer Pricing populates this field (optionally) when the user specifies a Basis Risk Cost rate or defines a formula-based rate in the TP Adjustment Rule.

Module Usage

This field is related to FTP Adjustment Rules. When the basis risk adjustment type is defined and included in the TP process, the TP Engine calculates and populates this field according to the assumption input by the user through the Adjustment Rule user interface.

Data Verification Requirements and Suggested Defaults

None

Behavior Type Code (BEHAVIOUR_TYPE_CODE)

Definition

Behavior Type indicates the type of behavior pattern that is mapped to the instrument records.

Module Usage

Oracle ALM uses BEHAVIOUR_TYPE_CD to determine the type of behavior pattern being applied to the instrument record. The following are the supported BEHAVIOUR_TYPE_CODE values.

Table 51 : List of Behavior Type Code Values
Code Value	Behavior Type
1	Non-Maturity
2	Non-Performing
3	Devolvement and Recovery

NOTE:

Behavior patterns have specific requirements for Accrued Interest depending on the adjustable type (fixed or adjustable) code. For more information, see the ACCRUED_INTEREST section.

Data Verification Requirements and Suggested Defaults

· BEHAVIOR_TYPE_CD is mandatory when AMRT_TYPE_CD is populated with a Behavior Pattern code. Example: AMRT_TYPE_CD >= 70000 and <=99999.

· If AMRT_TYPE_CD is not in the Behavior Pattern range, then BEHAVIOR_TYPE_CD can default to NULL.

· If Behavior type code =2, then the MATURITY_DATE of instrument needs to be greater than max Tenor of the behavior pattern.

Behavior Sub Type Code (BEHAVIOUR_SUB_TYPE_CODE)

Definition

This field indicates the type of cash flow associated with Non-Performing or Devolvement and Recovery Behavior Pattern instruments.

Module Usage

Oracle ALM uses BEHAVIOUR_SUB_TYPE_CD to determine the SUB type of the behavior pattern being applied to the instrument record. The following are the supported BEHAVIOUR_SUB_TYPE_CODE values.

Table 52: List of Behavior Sub Type Code Values
Code Value	Behavior Sub Type
201	Substandard
202	Doubtful
203	Loss
301	Sight Devolvement
302	Sight Recovery
303	Usance Devolvement
304	Usance Recovery

Data Verification Requirements and Suggested Defaults

· BEHAVIOR_SUB_TYPE_CD is mandatory when AMRT_TYPE_CD is populated with a Behavior Pattern code. Example, AMRT_TYPE_CD >= 70000 and <=99999 AND the BEHAVIOR_TYPE_CD is 2 (Non-Performing) or 3 (Devolvement and Recovery).

· BEHAVIOR_SUB_TYPE_CD can be NULL when BEHAVIOR_TYPE_CD = 1 (Non-Maturity) or when the AMRT_TYPE_CD is not in the earlier mentioned Behavior Pattern Range.

Acceptable mapping of Behavior Pattern Type to Behavior Pattern Sub Type

Table 53: Mapping of Behavior Pattern Type to Behavior Pattern Sub Type
BP Type Code Value	Behavior Type	BP Subtype Code Value	Behavior Sub Type	Devolvement Status Code (Inst Record)	Notes
1	Non Maturity	101*	Core
1	Non Maturity	102*	Volatile
2	Non Performing	201	Substandard
2	Non Performing	202	Doubtful
2	Non Performing	203	Loss
3	Devolvement and Recovery	301	Sight Devolvement		defined bp pattern only, not on instrument record
3	Devolvement and Recovery	302	Sight Recovery		defined bp pattern only, not on instrument record
3	Devolvement and Recovery	303	Usance Devolvement		defined bp pattern only, not on instrument record
3	Devolvement and Recovery	304	Usance Recovery		defined bp pattern only, not on instrument record
3	Devolvement and Recovery	305**	Usance	0,1***	0 = Not Devolved, 1 = Devolved
3	Devolvement and Recovery	306**	Sight	0,1***	0 = Not Devolved, 1 = Devolved

NOTE:

** Instrument records need subtype value of 305 or 306 for D&R These are referenced against the behavior pattern subtype codes 301-304 in the D&R pattern definition

*** If Devolvement status cd = 0, CFE will process the Pattern with the corresponding devolvement and recovery subtypes

*** If Devolvement status cd = 1, CFE will process the Pattern with the corresponding recovery subtypes only.

For example, if Sub Type=306 and Devolvement Status = 0, then CFE processes the behavior pattern information for Sight Devolvement first followed by the Sight Recovery in the sequence of the tenors i.e, the pattern definition can have D followed by R followed by D followed by R and CFE will process the information in the same sequence. If Sub Type=306 and Devolvement Status = 1, then CFE processes the behavior pattern information for Sight Recovery only and will ignore any Devolevment event in the pattern.

Breakage Type Code (BREAKAGE_TYPE_CD)

Definition

Breakage Type Code indicates the type of Break for the given row of data. This column will exist only tables that hold break events, such as FSI_D_BREAK_FUNDING_CHARGES. This column must be populated for the Economic Loss Breakage Charge calculation to function properly.

Module Usage

Oracle FTP uses BREAKAGE_TYPE_CD to determine the type of break event. The following are the supported BREAKAGE_TYPE_CD values.

Code Value Breakage Type

· Full Break (type 1)

· Partial Break (type 2)

· Change in Attributes Break (type 3)

· Combination of Partial Break and Change in Attributes Break (type 5)

Data Verification Requirements and Suggested Defaults

BREAKAGE_TYPE_CD is mandatory for calculating an Economic Loss breakage charge. Values must be 1,2,3 or 5. These values are populated automatically by the Break Identification Process but must be populated manually if break data is being loaded from an external source.

Break Funding Market Value (BREAK_FUNDING_MV)

Definition

This field is populated by the FTP Standard Process when running with an Adjustment Rule + Breakage Charge – Economic Loss defined. It holds the calculated result of the market value using the selected interest rate of Transfer Rate, Liquidity Premium Rate, Basis Risk Cost Rate, Pricing Incentive Rate, or Other Adjustment Rate as specified by the user during Adjustment Rule definition. This value reflects the net present value of the cash flows calculated from as of date to the maturity date of the instrument (remaining term).

Module Usage

Oracle Funds Transfer Pricing populates this field (optionally), when the user defines the Break Charge – Economic Loss calculation through their Adjustment Rule and enables the Adjustment Calculation in the TP Process. This column only exists in the FSI_D_BREAK_FUNDING_CHARGES table.

Data Verification Requirements and Suggested Defaults

None

Break Funding Amount (BREAK_FUNDING_AMT)

Definition

This field is populated by the FTP Standard Process when running with an Adjustment Rule + Breakage Charge – Economic Loss defined. It holds the calculated result of the Book Value – Break Funding Market Value (for Assets) or Break Funding Market Value – Book Value (for Liabilities). This value reflects the embedded value of the instrument and can be either positive or negative.

Module Usage

Data Verification Requirements and Suggested Defaults

None

Break Funding Amount Change (BREAK_FUNDING_AMT_CHG)

Definition

This field is populated by the FTP Standard Process when running with an Adjustment Rule + Breakage Charge – Economic Loss defined. It holds the difference in Break Funding Amount between Prior Record and Current. If the record is a Full Break, then Break Funding Amount and Break Funding Amount Change will be the same. If Partial Break or Change in Attributes Break, then Break Funding Amount Change will show the change in the Break Funding amount (Prior Record – Current Record). This column holds the final result of the Breakage Charge calculation and is the actual “Breakage Charge”. If the value is positive, there is an Economic Gain to the bank, and if Negative, there is an Economic Loss. Both gains and losses are typically allocated to the originating business unit, for profitability reporting. The bank (originating business unit) should charge the customer for Economic Loss.

Module Usage

Data Verification Requirements and Suggested Defaults

None

Capital Protection Category (CAP_PROTECTION_CATEGORY)

Definition

The basis on which index factor is determined. Applicable for the inflation-indexed instrument.

Module Usage

Oracle ALM reference CAP_PROTECTION_CATEGORY to calculate Index Factor, for the inflation-indexed instrument.

Capital protection category values are represented by code values as follows.

Table 54: List of Capital Protection Category Code Values
Code Value	Capital Protection Category
0	No Floor
1	Floor of 1
2	Max during life

· If Capital Protection Category is ‘0’ (No Floor) then

Title: Description of the Index Factor formula follows - Description: The illustration shows the formula to calculate the Index Factor where the Capital Protection Category is 0.

Description of the Index Factor formula follows

· If Capital Protection Category is ‘1’ (Floor of 1) then

Title: Description of the Index Factor formula follows - Description: The illustration shows the formula to calculate the Index Factor where the Capital Protection Category is 1.

Description of the Index Factor formula follows

· If Capital Protection Category is ‘2’ (Max during life) then

Title: Description of the Index Factor formula follows - Description: The illustration shows the formula to calculate the Index Factor where the Capital Protection Category is 2.

Description of the Index Factor formula follows

Data Verification Requirements and Suggested Defaults

· Must be equal to values 0-2

· Suggested default, if the instrument is not inflation indexed, to keep this value to null or 0.

Charge Credit Option Cost (CHARGE_CREDIT_OCOST)

Definition

This field is populated by the FTP Stochastic Process and holds the charge/credit amount for the original term Option Cost.

Module Usage

Oracle Funds Transfer Pricing populates this field (optionally) when the user selects the Option Cost – Charge / Credit option in the Stochastic FTP Process.

AVG_BOOK_BAL or CUR_BOOK_BAL X (HISTORIC_OAS – HISTORIC_STATIC_SPREAD)/100 X ACCRUAL BASIS

Data Verification Requirements and Suggested Defaults

None

Charge Credit Option Cost Remaining Term (CHARGE_CREDIT_OCOST_REM_TERM)

Definition

This field is populated by the FTP Stochastic Process and holds the charge/credit amount for the remaining term Option Cost.

Module Usage

Oracle Funds Transfer Pricing populates this field (optionally) when the user selects the Option Cost – Charge / Credit option in the Stochastic FTP Process.

AVG_BOOK_BAL or CUR_BOOK_BAL X (CUR_OAS – CUR_STATIC_SPREAD)/100 X ACCRUAL BASIS

Data Verification Requirements and Suggested Defaults

None

Charge Credit Transfer Rate (CHARGE_CREDIT_TRATE)

Definition

This field is populated by the FTP Standard Process and holds the charge/credit amount for the original term Transfer Rate Charge or Credit.

Module Usage

Oracle Funds Transfer Pricing populates this field (optionally) when the user selects the Transfer Rate – Charge / Credit option in the Standard FTP Process.

AVG_BOOK_BAL or CUR_BOOK_BAL X TRANSFER_RATE / 100 X ACCRUAL BASIS

Data Verification Requirements and Suggested Defaults

None

Charge Credit Transfer Rate Remaining Term (CHARGE_CREDIT_TRATE_REM_TERM)

Definition

This field is populated by the FTP Standard Process and holds the charge/credit amount for the remaining term Transfer Rate Charge or Credit.

Module Usage

Oracle Funds Transfer Pricing populates this field (optionally) when the user selects the Transfer Rate – Charge / Credit option in the Standard FTP Process.

AVG_BOOK_BAL or CUR_BOOK_BAL X TRAN_RATE_REM_TERM / 100 X ACCRUAL BASIS

Data Verification Requirements and Suggested Defaults

None

Compounding Basis Code (COMPOUND_BASIS_CD)

Definition

Indicates the compounding frequency used to calculate interest income.

Module Usage

Oracle ALM and Funds Transfer Pricing cash flow calculations reference the COMPOUND_BASIS_CD field when determining the detailed record's compounding method to be applied during interest income (financial element 430) calculations.

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

Table 55: List of Compounding Basis Code Values
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	Semi-annual	Balance * [(1 + Rate/2)^2-1]
150	Annual	Balance * [(1 + Rate/1)^1-1]
160	Simple	Balance * Rate (no compounding)
170	Continuous	e(Rate Per Payment) -1
200	At Maturity	Balance * Rate (no compounding)
999	Other	Balance * Rate (no compounding)

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

2. OFSAA cash flow engine compounds the rate on the record at the time of the interest income calculation. If the record has repriced, the cash flow engine calculates the new rate, applies any rounding, caps/floors, or tease periods, and then applies the compounding calculation (COMPOUND_BASIS_CD) 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 calculated only 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.

5. Multiple reprice events within a payment event, compounding is applied when:

§ Compounding frequency is same as Repricing frequency

§ Compounding frequency is less than Payment frequency, and Payment frequency is same as Reprice frequency.

For above condition(s), on first payment date, post as of date, if accrued interest (see ACCRUED_INTEREST) is provided as download, interest is calculated on provided accrued interest. In addition, when compound frequency is less than payment frequency, there would be multiple compounding period within a payment event. Interest from last payment event until first compound period is used as an input for calculating interest for next compounding period, till next payment event is reached.

NOTE:

When Compounding frequency is same as Reprice frequency, with same payment and compounding frequency, compounding of interest would not happen.

For below Multiple Repricing use cases Compounding is defaulted to None:

1. When Adjustable type code =500-99999 (repricing patterns), COMPOUND_BASIS_CD defaults to None. An error message is logged "For Multiple Reprice Instruments with repricing patterns, the compounding defaults to None".

2. When Adjustable type =50 (floating-rate), COMPOUND_BASIS_CD defaults to None. An error message is logged "For Floating rate Multiple Reprice Instruments”, the compounding defaults to None”.

When COMPOUND_BASIS_CD is 170 (continuous), it is defaulted to None. An error message is logged “For Multiple reprice instruments when compounding frequency is set as Continuous (170). The compounding is defaulted to None”. This use case is applicable from release 8.1.1.1.0 onwards.

NOTE:

Simple to Annual compounding rate conversion: There are two points to note:

When term of cash flow is less than one year, then simple compounding rate would be used as it is for annual compounding. Because there is no compounding before 1 year.

When cash flow term is more than 1 Year, then the conversion is done by equating (P+I) for simple and annual compoundingSimple Compounding (P+I) Annual Compounding (P+I) 1 + (r*Term in Days/365)

= (1 + R) ^ (Term in Days/365)

R is rate after conversion from Simple to Annual compounding.

Data Verification Requirements and Suggested Defaults

A valid COMPOUND_BASIS_CD must be one of the values listed earlier.

Suggested default - If the record's compounding is unknown, default to COMPOUND_BASIS_CD = 160, Simple.

Convexity (CONVEXITY_C)

Definition

Convexity is a measure of the curvature of 2nd derivative of how the price of an instrument varies with the interest rate, that is, how the duration of an instrument changes as the interest rate changes.

Module Usage

Both the Static Deterministic and Dynamic Deterministic ALM processes will calculate and output convexity when the Market Value option is selected from the Calculation Elements block. This result is written to FSI_O_RESULT_MASTER and FSI_O_CONSOLIDATED_MASTER tables for each scenario defined in Forecast Rates. Additionally, users can choose to update the instrument data with Convexity for each record if the related option is selected on the Output Preferences block. The instrument record will be updated for scenario 1 result only.

The cash flow engine calculates convexity using the following formula:

Title: Description of the Convexity formula follows - Description: The illustration shows the formula to calculate the Convexity.

Description of the Convexity formula follows

Data Verification Requirements and Suggested Defaults

None

Current Book Balance (CUR_BOOK_BAL)

Definition

Current Gross Book Balance.

Module Usage

Oracle ALM

When there is deferred balance (DEFERRED_CUR_BAL), Oracle ALM uses CUR_BOOK_BAL to calculate accretion/amortization (financial element 540) and the deferred ending and average balances (financial element 520, 530).

Oracle Funds Transfer Pricing

Oracle Funds Transfer Pricing uses CUR_BOOK_BAL during calculations for LEDGER_STAT transfer pricing and if selected in Application Preferences, for calculation of Charge / Credit amounts.

When Remaining Term Calculation Mode is selected in the Standard TP Process, and the Target Balance for the subject product leaf is Book Balance (in the TP Rule), Oracle Transfer Pricing Option Cost calculations use CUR_BOOK_BAL as the target balance to which the sum of future discounted cash flows is set equal.

Data Verification Requirements and Suggested Defaults

Validate that CUR_BOOK_BAL = CUR_PAR_BAL + DEFERRED_CUR_BAL.

Current Gross Rate (CUR_GROSS_RATE)

Definition

The coupon rate of account expressed in terms of an annualized rate.

Module Usage

When the Model with Gross Rates switches is turned on in the Oracle ALM Product Characteristics rule, or in the Transfer Pricing Rule, CUR_GROSS_ RATE is used to calculate forecasted cash flows. When switched on, the cash flow engine uses the record's CUR_GROSS_RATE for 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 rate at which the customer prepays, the current customer rate must be compared to the market rate. If the Model with Gross Rates is switched on, then the customer rate is represented by the CUR_GROSS_ RATE. If the switch is not turned on, the CUR_NET_RATE is used as the current customer rate.

If Model with Gross Rates is used, the Oracle ALM 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) are calculated from the CUR_NET_RATE.

NOTE:

Depending on the NET_MARGIN_CD value, interest income is calculated differently.

Following is an explanation of how Oracle ALM calculates CUR_GROSS_ RATE:

Before the NEXT_REPRICE_DATE, the cash flow engine uses the CUR_GROSS_RATE from the detail record as the gross rate.

At or beyond the NEXT_REPRICE_DATE, the cash flow engine matches the REPRICE_FREQ, INTEREST_RATE_CD, and the reprice date to the information contained in the Oracle ALM Forecast Rates assumption rule. This is to assign a forecasted base rate. The MARGIN_GROSS is then added to this forecasted base rate. Any rounding, rate caps/floors, and tease periods are applied and the resulting rate is applied to the record as the gross rate.

NOTE:

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

Current Net Rate (CUR_NET_RATE)

Definition

The interest rate that interest income due to the bank is based upon.

Module Usage

Oracle ALM and Funds 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_CD and INT TYPE. These calculations are presented under the field heading Accrual Basis Code (ACCRUAL_BASIS_CD) and Interest Type Code (INT_TYPE). Interest income is calculated on payment dates or the record's maturity date. As the calculations indicate, after referencing the ACCRUAL_BASIS_CD, the cash flow engine applies the CUR_NET_RATE to the entire payment period (last Previous payment date to the 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.

NOTE:

Whether or not the Model with Gross Rates option has been selected in Product Characteristics (ALM) or the Transfer Pricing rule screen (Transfer Pricing), the cash flow engine always calculates the bank's income according to the CUR_NET_RATE.

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 a record's balance, a key input is the record's customer rate. If the Model with Gross Rates is not selected, then the cash flow engine uses the CUR_ NET_RATE for amortization purposes.

Depending on the NET_MARGIN_CD value, interest income is calculated differently.

Following is an explanation of how Oracle ALM calculates CUR_NET_RATE:

Before the NEXT_REPRICE_DATE, Oracle ALM uses the CUR_NET_RATE from the detail record as the net rate.

At or beyond the NEXT_REPRICE_DATE, Oracle ALM matches the REPRICE_ FREQ, INTEREST_RATE_CD, and the reprice date to the information contained in the Forecast Rates rule. This is to assign a forecasted rate. The MARGIN is then added to this forecasted base rate. Any rounding, rate caps/floors, and tease periods are applied and the resulting rate is applied to the record as the net rate.

NOTE:

ADJUSTABLE_TYPE_CD = 30 or 50 does not reference reprice dates.

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 the index that the account is tied to (assuming periodic/lifetime caps/floors do not apply and rounding is taken into consideration).

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 As Of Date.

Module Usage

Transfer Pricing When Remaining Term Calculation Mode is selected in the Stochastic TP Process, the Oracle Funds Transfer Pricing option cost module writes the result of its option-adjusted spread calculations to this column.

Data Verification Requirements and Suggested Defaults

None

Current Par Balance (CUR_PAR_BAL)

Definition

Represents the starting balance from which Oracle ALM cash flows are generated.

Module Usage

Oracle ALM and 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, CUR_PAR_BAL is the balance the cash flow engine amortizes over the remaining number of payments.

Oracle ALM

1. As the cash flow engine processes the record's payment dates and its maturity date, 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, the processing of the record ceases. The calculation method that defines how the CUR_PAR_BAL amount is reduced is represented by the AMRT_TYPE_CD and the CUR_PAYMENT fields.

2. The CUR_PAR_BAL is represented as Bucket 001 under financial element 60 (beginning balance in Oracle ALM Result Detail Table (RES_DTL_XXXXXX)) and as the CUR_PAR_BAL in the FSI_O_RESULT_MASTER Table. Generally, the CUR_ PAR_BAL from the detail record matches the balances in the Result Detail and RESULT_MASTER Tables. However, there are three exceptions.

3. Exception 1 - If the record's PERCENT_SOLD > 0, the cash flow engine recalculates the balance to equal CUR_PAR_BAL * (100 - PERCENT_SOLD). This is because if any percentage of the balance is not owned by the financial institution, it is not included in the forecast.

In this case, the RESULT_MASTER CUR_NET_PAR_BAL and Result Detail balances would be smaller than the record's CUR_PAR_ BAL.

§ Exception 2 - This exception applies to Discount/Premium records where the DEFERRED CUR BAL <> 0. The cash flow engine reads in the CUR_PAR_BAL amount but processes only book balances when calculating cash flows. The cash flow engine calculates the book balance by adding the CUR_PAR_BAL and the DEFERRED_CUR_BAL.

§ Exception 3 - This exception applies when the NEXT_PAYMENT_DATE < AS_OF_DATE. If the record's NEXT_PAYMENT_DATE is less than the AS_ OF_DATE and the record's AMRT_TYPE_CD <> 700, the cash flow engine reduces the CUR_PAR_BAL by the amount of the payments before the AS_OF_DATE.

§ For example, if the record's CUR_PAR_BAL = $1000 and there are two payments (each worth $100 of principal), the cash flow engine's beginning balance (financial element 60) would be equal to $800.

4. For User-Defined Payment Patterns where the payment method is defined as % Current Balance, Oracle ALM references the CUR_PAR_BAL field for all payment amounts beyond the first forecasted payment amount.

Transfer Pricing

· For the cash flow Remaining Term Pricing Basis methodologies in Oracle Funds Transfer Pricing, as the cash flow engine processes the record's payment dates and its maturity date, 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, the processing of the record ceases. The calculation method that defines how the CUR_PAR_BAL amount is reduced is represented by the AMRT_TYPE_CD and the CUR_PAYMENT fields.

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

When Remaining Term Calculation Mode is selected in the TP Process, and the Target Balance for the subject product leaf in the TP Rule is Par Balance, Oracle Transfer Pricing Option Cost calculations use CUR_PAR_BAL as the target balance to which the sum of future discounted cash flows is set equal.

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 does not process the record.

· CUR_PAR_BAL = CUR_BOOK_BAL - DEFERRED_CUR_BAL

· CUR_PAR_BAL should have the same sign as CUR_PAYMENT.

· CUR_PAR_BAL requires a valid balance for all accounts. If CUR_PAR_BAL = 0, then the cash flow engine does not process the record. You should not include these records for processing.

Current Payment (CUR_PAYMENT)

Definition

Represents the current periodic payment made against the outstanding balance.

Module Usage

For standard amortization types (those that are not non-patterned and non-scheduled), Oracle ALM and Funds Transfer Pricing use the CUR_PAYMENT from the detailed record for the life of the record until a payment re-calculation occurs. A payment re-calculation occurs when the record is an:

· An adjustable record and a reprice date (NEXT_REPRICE_DATE) is reached.

· Adjustable record and the TEASER_END_DATE is reached (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_CD, CUR_PAYMENT may be composed of principal or interest or both.

AMRT_TYPE_CD 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, a simple interest record's CUR_PAYMENT = 0. If a repricing event (payment recalculation event) occurs, the interest amount of the payment (financial element 430, and if applicable, 435) is recalculated as indicated under the ACCRUAL_BASIS_CD. The only principal payment is made at maturity (Maturity Payment = financial element 195, 197).

AMRT_TYPE_CD 100, 400, 500, 600 (Conventionally Amortizing) : For extracting purposes, CUR_PAYMENT = principal + interest. If a payment recalculation event occurs, the cash flow engine re-calculates the total CUR_PAYMENT amount using the following formula:

Title: Description of the Total Current Payment Amount formula follows - Description: The illustration shows the formula to calculate the Total Current Payment Amount.

Description of formula to calculate the Current Payment follows

For Leases (AMRT_TYPE_CD = 840), the amortization is conventional and the payment amount includes both principal and interest, but the equation is slightly different because it must incorporate the residual value. The following formula is used to compute the lease payment when re-calculation is required:

Title: Description of the Lease Payment formula follows - Description: The illustration shows the formula to re-calculate the Lease Payment.

Description of formula to calculate the Lease Payment follows

Where:

p = Remaining Balance or Current Par Balance

f = Maximum (Residual amount of lease, 0)

r = Current interest rate adjusted for accrual basis, compounding basis and adjusted for semi-annual compounding if enabled

n = Remaining number of payments on the day of calculation

These calculations derive the total payment amount, principal, and interest. To determine the interest income (financial element 430) portion and the principal (financial element 190 or 192) portion of this payment amount, the cash flow engine calculates the interest income as indicated under the ACCRUAL_BASIS_CD. This income amount is then subtracted from the calculated total payment amount to determine the principal portion.

AMRT_TYPE_CD 820 (Level Principal) : For extracting purposes, CUR_PAYMENT = principal only. If a repricing event occurs, the cash flow engine recalculates the total CUR_PAYMENT amount using the following formula:

Title: Description of the Total Current Payment Amount formula follows - Description: The illustration shows the formula to calculate the Total Current Payment Amount if a repricing event occurs.

Description of formula to calculate the Current Payment follows

This calculation yields the principal payment amount only (financial element 190 or 192). To derive the total payment amount, the interest amount (financial element 430) calculation is applied and added to the principal portion.

· AMRT_TYPE_CD 800: Conventional payment schedule Payment Amount should contain both principal + interest. Payment recalculation is the same as for conventionally amortizing. The cash flow engine uses the CUR_PAYMENT from the detailed record for the first forecasted payment. Therefore, the CUR_ PAYMENT on the detail record should equal the corresponding payment in the PAYMENT_SCHEDULE table.

· AMRT_TYPE_CD 801: Level principal payment schedule Payment Amount should contain the principal only. Payment re-calculation is the same as under level principal AMRT_TYPE_CD 820. The cash flow engine uses the CUR_ PAYMENT from the detailed record for the first forecasted payment. Therefore, the CUR_PAYMENT on the detail record should equal the corresponding payment in the PAYMENT_SCHEDULE table.

· AMRT_TYPE_CD 802: Simple interest payment schedule Payment Amount should be equal to zero (for simple interest, the engine ignores this field and just looks at the scheduled payment date). Interest recalculation is the same as indicated under simple interest AMRT_TYPE_ CD 700.

AMRT_TYPE_CD 1000 - 69999, User-Defined Payment Patterns: Depending on the payment method defined in the interface, Oracle ALM may or may not reference the CUR_PAYMENT field from the detail record.

Following is a grid that outlines the Oracle ALM use of the CUR_PAYMENT field depending on the payment method.

Table 56: Use of the CUR_PAYMENT field
% Current Payment	% Original Payment	Interest Only	% Original Balance	%Current Balance
Never (always calculated)	ALM -Referenced for first cash flow only.	Never (always calculated)	ALM -Referenced for first cash flow only.	ALM -Referenced for first cash flow only.

NOTE:

Oracle Funds Transfer Pricing does not reference CUR_PAYMENT when using User-Defined Payment Patterns.

The method of re-calculating payments for User-Defined Payment Patterns is dependent on the payment type that is defined for the payment pattern: conventional, level principal, or simple interest. Amortization re-calculations correspond to AMRT_TYPE_CDs 100, 820, and 700 respectively. Each is defined earlier.

Data Verification Requirements and Suggested Defaults

· If AMRT_TYPE_CD = 100, 400, 500, 600, 710, 800, 840 or is a conventionally-amortizing payment pattern, CUR_PAYMENT should include principal and interest.

· If AMRT_TYPE_CD = 820, 801 or is a level principal-amortizing payment pattern, CUR_PAYMENT should include principal only.

· If AMRT_TYPE_CD = 700, 802, 850 or is a simple interest-amortizing payment pattern, CUR_PAYMENT can be 0.

· For AMRT_TYPE_CD <> Simple Interest AMRT_TYPE_CDs, CUR_PAYMENT must have the same sign as CUR_BOOK_BAL.

· CUR_PAYMENT must be the same sign as the CUR_BOOK_BAL and CUR_ PAR_BAL fields.

· If AMRT_TYPE_CD = 600 (Negative Amortization) and PMT_DECR_LF <> 0, CUR_PAYMENT should be greater than or equal to ORG_PAYMENT_AMT * (1 - PMT_DECR_LF/100).

· If AMRT_TYPE_CD = 600 (Negative Amortization) and PMT_ INCR_LF <> 0, CUR_PAYMENT should be less 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 78s:

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_ C)))

· For leases:

[(CUR_PAR_BAL x (1+r)^n) - RESIDUAL_AMOUNT] x [r/((1+r)^n -1)]

· 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_C

· For Annuities:

CUR_PAYMENT = (MATURITY_AMOUNT – CUR_PAR_BAL) / REMAIN_NO_PMTS_C

· 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. This is demonstrated in the Remaining Number of Payments (REMAIN_NO_PMTS_C) section. 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])))

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 As Of Date.

Module Usage

Transfer Pricing- When Remaining Term Calculation Mode is selected in the Stochastic TP Process, the Oracle Funds Transfer Pricing Option Cost module writes the result of its static spread calculations to this column.

Data Verification Requirements and Suggested Defaults

None

Current Transfer Pricing Period Average Daily Balance (CUR_TP_PER_ADB)

Definition

The average balance at the LAST_REPRICE_DATE.

Module Usage

Oracle ALM

Oracle ALM does not reference CUR_TP_PER_ADB or PRIOR_TP_PER_ ADB.

Transfer Pricing

When processing with the mid-period repricing option, Oracle Funds 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.

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.

An example of a mid-period pricing scenario as follows. The table provides the scenario specifics, followed by an explanation.

Table 57: Mid-period Pricing Scenarios
Fields	Scenario
AS_OF_DATE	31-DEC
LAST_REPRICE_DATE	15-DEC
LAST_PAYMENT_DATE	15-DEC (balance was reduced on this date)
CUR_TP_PER_ADB	$10,000
PRIOR_TP_PER_ADB	$15,000
TRANSFER_RATE	3% from 15-NOV to 15-DEC (prior period, 30 days in the period)
TRANSFER_RATE	5% from 15-DEC to 15-JAN (current period, 31 days in the period)

Without the mid-period repricing option, Transfer Pricing would assign a 5% transfer rate to the record for 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 record's 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) + S(PRIOR_TP_PER_ADB * Prior Period Transfer Rate * Prior Period Days)) / ((CUR_TP_PER_ADB * Current Period Days) + S(PRIOR_TP_PER_ADB * Prior Period Days))

From the earlier example, 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%.

About the earlier 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 before the LAST_REPRICE_DATE.

If the TEASER_END_DATE is greater than the AS_OF_DATE, the Mid-Period Repricing does not apply and the CUR_TP_PER_ADB and PRIOR_TP_PER_ ADB fields are not used.

See the Oracle Financial Services Funds Transfer Pricing User Guide for more information.

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

Current Yield (CUR_YIELD)

Definition

The Yield to Maturity of the instrument record is computed using an internal rate of return calculation.

Module Usage

Both the Static Deterministic and Dynamic Deterministic ALM processes will calculate and output Yield to Maturity as standard output. This result is written to FSI_O_RESULT_MASTER and FSI_O_CONSOLIDATED_MASTER tables for each scenario defined in Forecast Rates. Additionally, users can choose to update the instrument data with YTM for each record if the related option is selected on the Output Preferences block. The instrument record will be updated for scenario 1 result only.

Data Verification Requirements and Suggested Defaults

None

Deferred Current Balance (DEFERRED_CUR_BAL)

Definition

The current, un-amortized deferred balance representing future income/expenses, such as premium, discount, fees, and costs.

Module Usage

DEFERRED_CUR_BAL holds the amount of unamortized discount or premium (fee or cost) associated with a bond or other instrument record.

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

For discounted instruments, the DEFERRED_CUR_BAL should be 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 should be positive, indicating that the balance is an expense.

The relationship between book, par, and the deferred amount is as follows:

CUR_BOOK_BAL = CUR_PAR_BAL + DEFERRED_CUR_BAL

An example of this relationship for a discounted loan follows:

CUR_PAR_BAL = $10,000

CUR_BOOK_BAL = $9,000

DEFERRED_CUR_BAL = - $1,000

1. A standard behavior is for the cash flow engine to perform a constant-yield (IRR) amortization of the DEFERRED_CUR_BAL. This enables the deferred balance to be amortized evenly over the life of the instrument. This life-long amortization 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 an account's maturity term even if the account itself does not amortize (Cash Flow Calculations, provides a textual explanation for the constant-yield calculation.)

In addition to level yield amortization of the discount or premium, users also have the option to apply a simplified straight-line amortization of the premium or discount. With this method, the discount or premium will be allocated in equal increments over the remaining life of the instrument. For related code values, see the description for Amortization Method for Premiums and Discounts (AMORT_METH_PDFC_CD).

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

Data Verification Requirements and Suggested Defaults

· For deferred income, (fees, discount), DEFERRED_CUR_BAL < 0.

· For deferred expense, (costs, premium), DEFERRED_CUR_BAL > 0.

· For accounts with deferred balances, the following equation must hold:

CUR_BOOK_BAL = CUR_PAR_BAL + DEFERRED_CUR_BAL

· For accounts with no deferred balances, DEFERRED_CUR_BAL = 0

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 field must exist on the instrument table for cash flow processing but is not used in any of the cash flow calculations.

Data Verification Requirements and Suggested Defaults

None

Devolvement Status Code (DEVOLVEMENT_STATUS_CD)

Definition

Related to Letters of Credit, devolvement status can be either not devolved or devolved. Not devolved is the default state. Devolvement occurs when the purchaser of the LC is not able to pay for receivables. When the LC moves into devolvement status, the bank begins the recovery process.

Module Usage

This field is required by the ALM process when the instrument uses a Devolvement/Recovery Behavior Pattern (BEHAVIOR_TYPE_CD = 3). The following values are possible for DEVOLVEMENT_STATUS_CODE.

0 – Not Devolved

1 – Devolved

In addition to DEVOLVEMENT_STATUS_CD, users are also required to populate the BEHAVIOR_SUB_TYPE_CD for Devolvement and Recovery Behavior Patterns. The following relationships are possible based on DEVOLVEMENT_STATUS_CD:

· If DEVOLVEMENT_STATUS_CD = 0 (not devolved)

§ BEHAVIOR_SUB_TYPE_CD = 301 (Sight Devolvement) or

§ BEHAVIOR_SUB_TYPE_CD = 303 (Usance Devolvement) or

§ BEHAVIOR_SUB_TYPE_CD = 302 (Sight Recovery) or

§ BEHAVIOR_SUB_TYPE_CD = 304 (Usance Recovery)

· If DEVOLVEMENT_STATUS_CD = 1 (devolved)

§ BEHAVIOR_SUB_TYPE_CD = 302 (Sight Recovery)

§ BEHAVIOR_SUB_TYPE_CD = 304 (Usance Recovery)

Data Verification Requirements and Suggested Defaults

· When BEHAVIOR_TYPE_CD = 3 then DEVOLVEMENT_STATUS_CD must be 0 or 1.

· If BEHAVIOR_TYPE_CD <> 3, then DEVOLVEMENT_STATUS_CD can be NULL.

Duration (DURATION_C)

Definition

The DURATION_C column holds the calculated Macaulay Duration output.

Module Usage

Both the Static Deterministic and Dynamic Deterministic ALM processes will calculate and output Macaulay Duration when the Market Value option is selected from the Calculation Elements block. This result is written to FSI_O_RESULT_MASTER and FSI_O_CONSOLIDATED_MASTER tables for each scenario defined in Forecast Rates. Additionally, users can choose to update the instrument data with Macaulay Duration for each record if the related option is selected on the Output Preferences block. Each instrument record will be updated for scenario 1 result only.

The cash flow engine calculates the duration using the following formula:

Title: Description of the Macaulay Duration formula follows - Description: The illustration shows the formula to calculate the Macaulay Duration.

Description of the Modified Duration formula follows

Data Verification Requirements and Suggested Defaults

None

DV01/PV01 (DV01_C)

Definition

The DV01_C column holds the calculated Dollar duration or Present Value of a Basis point output.

Model Usage

Both the Static Deterministic and Dynamic Deterministic ALM processes will calculate and output DV01 when the Market Value, YTM, Duration, DV01/PV01 option is selected from the Calculation Elements block. This result is written to FSI_O_RESULT_MASTER and FSI_O_CONSOLIDATED_MASTER tables for each scenario defined in Forecast Rates. Additionally, users can choose to update the instrument data with Dollar Duration for each record if the related option is selected on the Output Preferences block. Each instrument record will be updated for scenario 1 result only.

The cash flow engine calculates the DV01 using the following formula:

The illustration shows the formula to calculate the DV01.

Description of the Dollar Duration (DV01) formula follows

NOTE:

For update back to instrument table, Modified Duration and Market Value data are used from instrument table stored in MODIFIED_DURAION_C and MARKET_VALUE_C respectively. For output at Result Master or Consolidated Master Modified Duration and Market, Value data is used from Result Master and Consolidated Master respectively.

There may be cases, where the ALM process fails with an error while inserting FSI_O_RESULT_MASTER/FSI_O_CONSILIDATED_MASTER table. This is caused due to calculated DV01 value size larger than permitted DV01 column size.

To handle this condition, there has been a new configuration entry named "DV01_FLAG" in the SETUP_MASTER table which is by default set to "N", exhibiting existing Engine behavior. When this is set as Y, the DV01 value will be defaulted to `0' before getting output and stored in FSI_O_RESULT_MASTER/FSI_O_CONSILIDATED_MASTER.

Hence, you need to set this value to Y if the above issue is observed.

Effective Interest Rate (EFF_INTEREST_RATE_C)

Definition

An effective interest rate represents the Yield to Maturity of the instrument inclusive of fees and costs.

Module Usage

This financial measure is calculated by Oracle ALM and Oracle Hedge Management and IFRS Valuations when the corresponding Calculation Element is selected and the result is written to each instrument record selected in the process. Effective Interest Rate is not written to FSI_O_RESULT_MASTER or FSI_O_CONSOLIDATED_MASTER.

The Effective Interest Rate calculation is similar to Yield to Maturity, with the main difference being that it additionally considers the amount input into the FEES_EIR column.

Data Verification Requirements and Suggested Defaults

None

Expected Balance (EXPECTED_BAL)

Definition

This field represents the expected balance of a mortgage offset account (MOA). It is a data input (optionally) for each mortgage record and represents an offset to the outstanding loan balance for purposes of calculating interest.

This is intended to store the current period balance of the Offset (Deposit) account. It is the responsibility of the bank to populate this field as part of their ETL.

Module Usage

Used for modeling Mortgage Offset Accounts (MOA's). If populated, the cash flow engine will reduce the loan's principal balance in calculating interest.

This applies to all Charge/Credit calculations that are available in TP - Instrument level charge/credit calculations for all TP Methods, Adjustments, and Option Costs. This Charge/Credit formula applies to all Processing types – Standard Term and Remaining Term.

The following example illustrates how Mortgage Offset Account work:

Table 58: Example of Mortgage Offset Account
Mortgage Offset Account Example	Values
Current Balance	100,000
Rate of Interest (fixed)	10%
Interest Type	Arrears
Amortization term (Days)	366
Accrual Basis	1
Compounding Basis	160
Payment frequency (Months)	3
Current payment	25,000
Maturity Date	12/31/2010
Last Payment Date	12/31/2009
Remaining number of payments	4
MOA Expected Balance	60,000
MOA Expected Balance Growth %	5.00%
Mortgage Offset Percentage	40%
Minimum Balance of MOA	3,000

As depicted in the earlier sample data record, the MOA Expected Balance is 60,000 at the last payment date (12/31/2009). The MOA Expected Balance is changed at each payment date by a growth percentage factor. This amount could be positive, negative, or zero. Each of the remaining payment dates would have an MOA expected balance of :

Table 59: Example of MOA expected balance
Date	Value	Calculation
3/31/2010	60,750.00	= 60,000 * (1+(.05/12))*3)
6/30/2010	61,509.38
9/30/2010	62,278.24
12/31/2010	63,056.72

Table 60: Derived Information
Accrual Basis(1 = 30/360)	0.08333333
Compounding per the payment frequency	3
Payment frequency (Days)	91	91	92	92	90
Payment Dates		3/31/2010	6/30/2010	9/30/2010	12/31/2010
Remaining number of payments		3	2	1	0
MOA Expected Balance on every Payment date		60,750.00	61,509.38	62,278.24	63,056.72

The amount of interest calculated is derived as follows:

Table 61: Interest Calculation
A) Interest Cashflow Calculation without Offset
Payment Date	3/31/2010	6/30/2010	9/30/2010	12/31/2010
Opening Balance	100,000.00	76,908.31	53,226.86	28,940.66
Interest Rate per payment	0.025	0.025	0.025	0.025
Compounded Interest Rate	0.025	0.025	0.025	0.025
Interest cash flow	2,520.89	1,938.77	1,341.79	729.56
Actual Current payment amount	25,000.00	25,000.00	25,000.00	25,000.00
Principal Runoff	22,479.11	23,061.23	23,658.21	24,270.44
Ending Balance	77,520.89	53,847.09	29,568.65	4,670.22
MOA Prepay Runoff	612.58	620.23	627.99	635.84
Maturity Runoff	-	-	-	4,670.22
B) Interest Cashflow Calculation with Offset
Payment Date	3/31/2010	6/30/2010	9/30/2010	12/31/2010
Remaining Balance after offset (only for Interest calculations)	75,700.00	52,304.56	28,315.56	3,717.97
Interest cash flow	1,908.31	1,318.54	713.8	93.73
New Financial Elements related to MOA
MOA Prepayment Runoff (FE 184)	612.58	620.23	627.99	635.84
Timing of MOA Prepayment Runoff (FE 185)	-> MOA Prepayment Runoff * (Start date of the bucket - Payment date)/((Start date of the bucket - Payment date)+((Payment date+1)-End date of the bucket))

The Remaining Balance after Offset = Opening balance – (Expected balance on every payment date * Mortgage offset %)

For 3/31/2010, remaining balance for interest calculation = 100,000 – (60,750 * 40%) = 75,700.00

Interest cash flow considering the offset for the period is 75,700 * .025 = 1908.31

Data Verification Requirements and Suggested Defaults

For Mortgage Offset Account instruments, EXPECTED_BAL > 0

If EXPECTED_BAL > 0, then Selected balance, e.g. CUR_PAR_BAL - (EXPECTED_BAL * (OFFSET_PCT/100) ) x rate/100 * Accrual Basis.

If EXPECTED_BAL > MINIMUM_BALANCE, then Offset happens as follows.

MOA Minimum Balance condition will also applicable (EXPECTED_BAL/ ORG_OFFSET_BAL/ LRD_OFFSET_BAL after applying Growth%).

If growth % is negative, then the balance will fall below the minimum. In this case, the minimum balance will be applicable as follows:

Also, if expected balance is currently below the minimum (no offset applies), and given a positive growth %, eventually, then expected bal will become > minimum, at which point it should become active.

Expected Balance Growth Percentage (EXPECTED_BAL_GROWTH_PCT)

Definition

This input field represents the expected growth of the offset account balance, used to calculate interest for Mortgage Offset Accounts (MOA). This growth can be positive, negative, or zero. Mortgage offset account assumptions are optional when computing periodic interest.

This holds the annualized Growth % of the EXPECTED_BAL.

Module Usage

For sample calculations, see Expected Balance (EXPECTED_BAL).

Data Verification Requirements and Suggested Defaults

For Mortgage Offset Account instruments, EXPECTED_BAL_GROWTH_PCT = 0 (Default)

First Reset Cap Balance

Definition

The current balance of the instrument on the cashflow date.

This will be 0 if a fully indexed rate is between the Capped Rate adjusted with First Reset Cap and the Floored Rate adjusted with First Reset Floor.

Module Usages

Oracle ALM cash flow methodologies use the First_Reset_Cap to set the initial minimum cap value for mortgage instruments that have a tease period.

Data Verification Requirements and Suggested Defaults

This cap rate will be applicable at the tease end period, before the first reset. After this, the periodic and lifetime cap value will be applied.

First Reset Cap Effect Rate

Definition

The current rate of the instrument on the cashflow date. The calculation is performed as:

((Fully Indexed Rate - Capped Rate adjusted with First Reset Cap/Floor)* FE60)

This will be 0 if a fully indexed rate is between the Capped Rate adjusted with First Reset Cap and the Floored Rate adjusted with First Reset Floor.

Data Verification Requirements and Suggested Defaults

This cap rate will be applicable at the tease end period, before the first reset. After this, the periodic and lifetime cap value will be applied.

First Reset Cap Effect Amount

Definition

The calculation is performed as:

(Interest Cashflow Net without cap adjustment - Interest Cashflow Net with cap adjustment)

This will be 0 if a fully indexed rate is between the Capped Rate adjusted with First Reset Cap and the Floored Rate adjusted with First Reset Floor.

Data Verification Requirements and Suggested Defaults

This cap rate will be applicable at the tease end period, before the first reset. After this, the periodic and lifetime cap value will be applied.

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

Oracle ALM

If the Oracle ALM Product Characteristics, Model with Gross Rates option is switched on, MARGIN_GROSS is used by the cash flow engine during cash flow generation.

1. For adjustable-type records, MARGIN_GROSS is the contractual spread above/below the index that is applied throughout the instrument's life. The customer's gross rate (CUR_GROSS_RATE) is equal to the index to which the record is tied to plus a spread, which is defined by the MARGIN_GROSS field.

2. The events of a repricing involving MARGIN_GROSS 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_CD, REPRICE_FREQ, and repricing date of the detail record to the Forecast Rates assumption attached to the ALM Process.

After matching the rate from the Forecast Rates assumption rule, if the IR Margin type cd = 1 (Percent) engine calculates Gross Margin using forecast raw rates, andMargin gross percent provided in column MARGIN_GROSS as Gross MarginC = Gross Margin % * Raw RateC. Gross Margin calculated, is added back to Raw Rate., For more information, see theMargin Type code (IR_MARGIN_TYPE_CD).

If IR Margin type cd =0 (Rate), provided MARGIN_GROSS amount gets directly added to Raw Rate.

Any teases, rate caps/floors, and rounding are applied thereafter to derive the rate that is applied to the record.

NOTE:

As explained in the ADJUSTABLE_TYPE_CD section, the cash flow engine does not reference repricing date information for ADJUSTABLE_ TYPE_CD = 30 or 50.

3. The repriced rate, defined in Step 3, equals the coupon rate that is used for amortization and prepayment purposes only. Interest income (financial element 430) is still derived from the CUR_NET_RATE + MARGIN.

NOTE:

If the Model with Gross Rates option switched off (it is typically off), the cash flow engine uses the CUR_NET_RATE and MARGIN for amortization, prepayment, and interest income calculation purposes.

Transfer Pricing

MARGIN_GROSS is not used by Oracle Funds Transfer Pricing.

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.

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

Transfer Pricing When Standard Calculation Mode is selected in the Stochastic TP Process, the Oracle Funds Transfer Pricing option cost module writes the result of its option-adjusted spread calculations to this column.

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

Transfer Pricing- When Standard Calculation Mode is selected in the Stochastic TP Process, the Oracle Funds Transfer Pricing option cost module writes the result of its static spread calculations to this column.

Holiday Calculation Option Code (HOLIDAY_CALC_OPTION_CD)

Definition

Interest calculation logic when Holiday Calendar is applied

Module Usage

Oracle ALM and FTP

Oracle ALM and Oracle FTP cash flow methodologies use HOLIDAY_CALC_OPTION_CD to determine Interest calculation logic when the Holiday calendar is applied.

There are two options for holiday calendar calculation 1= Shift Dates Only, 2=Recalculate Payment.

· When the Holiday calculation method is "Shift Dates Only", Interest cash flow is calculated using Holiday unadjusted payment and reprice dates. Interest output is then posted to Holiday adjusted payment dates (if payment date falls on Holiday). Interest cash flow is shifted to the holiday adjusted payment date.

· When the Holiday calculation method is “Recalculate Payment” payment and reprice dates are the first holiday adjusted. Interest is calculated using holiday adjusted payment and reprice dates. As payment and reprice dates can get Holiday adjusted, and even move to a new time bucket, there can be a change in interest cash flow output.

NOTE:

Payment and Reprice dates for a record is adjusted, when the Holiday calendar is referred, and the dates fall on a holiday. The determination of Holiday adjusted dates depends on the rolling convention selected. For information, see the HOLIDAY_ROLLING_CONVENTION_CD section.

For example, NEXT_PAYMENT_DATE and NEXT_REPRICE_DATE for a record are 15/12/2016 with PMT_FREQ and REPRICE_FREQ equal to 1M. The following payment and reprice dates will be 15/1/2017, 15/2/2017, and 15/3/2017.

If 15/12/2016 and 15/2/2017 dates are Holiday, with the rolling convention of Following Business Day, payment and reprice day moves to 16/12/2016 and 16/2/2017 (next working day which is not a holiday). Hence holiday adjusted payment and reprice dates will be 16/12/2016, 15/1/2017, 16/2/2017, and 15/3/2017.

Data Verification Requirements and Suggested Defaults

When HOLIDAY_CALENDAR_CODE is entered, ensure HOLIDAY_CALC_OPTION_CODE is filled up with either 1 or 2 code values.

Holiday Calendar Code (HOLIDAY_CALENDAR_CODE)

Definition

Holiday Calendar code, which stores holiday information.

Module Usage

Oracle ALM and Oracle FTP use Holiday Calendar code to determine Holiday definition to be associated while calculation.

The Holiday Calendar Code stores the Holiday Calendar Definition which contains the details such as name, description, weekend holidays, fixed and moving holidays. The Holiday Calendar Code should be a unique number ranging from 1 to 99999.

Holiday calendar codes can be maintained at both the instrument level and Product Characteristic level. The definition is given at the Instrument level always takes precedence. If it is not defined at the instrument level, the engine will use details from the Product Characteristic level.

For New Business, Holiday details are derived from the Product Characteristic level only. For more information, see the Application Preference section of the OFS ALM User Guide.

NOTE:

Ensure “Enable Holiday calendar Adjustments” checkbox selected in Application Preferences. Else engine will skip Holiday adjustments.

Holiday Calendar adjustments are not supported for the following scenarios:

1. Historical dates are not holiday adjusted. For example, an Instrument which has already originated LAST_PAYMENT_DATE, LAST_REPRICE_DATE is before As of Date. These dates are not holiday adjusted

2. The instrument with PMT_FREQ less than 5 Days.

3. When the Payment schedule is used (AMRT_TYPE_CD=800, 801, 802). It is expected that Payment dates provided in the Payment schedule are Holiday adjusted dates.

NOTE:

With holiday calendar associated, multiple payments for an instrument may get rolled into a working day.

The engine cannot handle multiple payment events on a single date. Hence it is recommended to ensure multiple Tenor (Multiplier), in behavior pattern; payment pattern; user-defined Early Redemption/ Prepayment, do not combine or roll into a single payment date, on the event of a Holiday.

Data Verification Requirements and Suggested Defaults

When HOLIDAY_CALENDAR_CODE is entered, ensure HOLIDAY_CALC_OPTION_CD is either 1 or 2 (Shift Days only or Recalculate Payment)

HOLIDAY_ROLLING_CONVENTION_CD is filled with one of 1, 2, 3, 4, 5 code value.

Holiday Rolling Convention Code (HOLIDAY_ROLLING_CONVENTION_CD)

Definition

Holiday Calendar convention code determines how the cash flows will be rolled if it falls on a Holiday.

Module Usage

Oracle ALM and Oracle FTP use holiday rolling convention code. The rolling convention values are represented by code values as follows.

Table 62: List of Holiday Rolling Convention Code Values
Code Values	Rolling Convention Basis
1	Unadjusted
2	Following business day
3	Modified following business day
4	Previous business day
5	A modified previous business day

1. When the Rolling convention is Unadjusted (code=1), payment is done on the actual payment date of the instrument.

2. When it is Following Business Day (code=2), the payment date is rolled into the next business day.

3. With Modified Following business day (code=3), the payment date is rolled into the next business day, unless doing so would cause the payment to be in the next calendar month, in which case the payment date is rolled to the previous business day.

4. When the rolling convention is Previous business day (code=4), the payment date is rolled to the previous business day.

5. With Modified previous business day (code=5), the payment date is rolled to the previous business day, unless doing so would cause the payment to be in the previous calendar month, in which case the payment date is rolled to the next business day.

Modified Following and Modified Previous become applicable for many institutions having month-end accounting procedures.

NOTE:

If Holiday adjusted dates move to a new time bucket, cash flows will be populated in time bucket where the cash flow has moved into.

Data Verification Requirements and Suggested Defaults

None

ID Number (ID_NUMBER)

Definition

Account number or other unique identifier used for identifying individual customer accounts.

Module Usage

ID_NUMBER identifies the individual customer accounts in the instrument tables. The ID_NUMBER should be unique for a given IDENTITY_CODE within an instrument table. Cash flow processing uses ID_NUMBER to identify each account as it is processed.

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

Data Verification Requirements and Suggested Defaults

ID_NUMBER is loaded into instrument tables from the source data. Because the database ensures that ID_NUMBER is unique for each IDENTITY_CODE, there are no edits or defaults for this field.

Identity Code (IDENTITY_CODE)

Definition

Data identifier.

Module Usage

IDENTITY_CODE is an identifier for sets of data loaded into an instrument table. IDENTITY_CODE identifies the data source for the individual customer account. The cash flow engine uses IDENTITY_CODE to uniquely identify individual customer accounts.

The combination of ID_NUMBER and IDENTITY_CODE must be unique.

Data Verification Requirements and Suggested Defaults

IDENTITY_CODE is loaded into instrument tables from the source data. Because the database ensures that the combination of IDENTITY_CODE and ID_NUMBER is unique, there are no edits or defaults for this field.

Index Adjustment Type (INDEX_ADJ_TYPE)

Definition

This file is used to determine the type of protection to the inflation-indexed instrument.

Module Usage

Oracle ALM reference INDEX_ADJ_TYPE to determine whether the instrument is inflation-indexed and if it is inflation-indexed whether principal payment or interest payment or both are protected. Index Adjustment Type values are represented by code values as follows.

Table 63: Index Adjustment Type values are represented by code values
Code Value	Inflation Adjustment Type
0	Not applicable
1	Principal and Interest
2	Principal only
3	Interest-only

· When Inflation Adjustment type is ‘0’, the instrument will not be treated as inflation-adjusted.

· When Inflation Adjustment type is ‘1’ (Principal and Interest), then both Principal and Interest are protected.

· When the Inflation adjustment type is ‘2’ (Principal only), then the only principal cash flow is protected.

· When Inflation adjustment type is ’3’ (Interest only) then the only interest cash flow is protected.

For more information, see the Inflation-Indexed Instrument.

Data Verification Requirements and Suggested Defaults

· Must be equal to values 0-3

· If the Instrument is not inflation indexed, keep this value to null or 0.

Index ID (INDEX_ID)

Definition

Identifies the Index to which Economic indicator is tied.

Module Usage

Oracle ALM reference INDEX_ID to determine whether the inflation-indexed instrument is using the instrument is inflation data (forecasted via engine) or negotiated rate.

Data Verification Requirements and Suggested Defaults

If Index data is provided via FSI_ACCOUNT_INDEX_HIST, keep INDEX_ID as 0. For more information, see the Inflation-Indexed Instrument.

· If Index data is defined in Economic Indicator and to be derived from the forecasted economic indicator, INDEX_ID to be populated with system id of Economic indicator.

NOTE:

If forecasted economic data to be used, ensure to forecast economic indicators via forecast rate rule.

Instrument Type Code (INSTRUMENT_TYPE_CD)

Definition

Code identifying the instrument table/category of the customer account.

Module Usage

INSTRUMENT_TYPE_CD identifies the source table of the instrument record. The following table lists each of the available INSTRUMENT_TYPE_CD values:

Table 64: List of Instrument Type Code Values
Code Values	Description
110	Commercial loans
120	Consumer loans
130	Mortgages
140	Investments
141	MBS
145	Money Market Contracts
150	Credit card
160	Credit Lines
170	Leases
180	Loan Contracts
205	Annuity Contracts
210	Deposits
215	Checking and Savings
220	Wholesale Funding
230	Term Deposits
240	Retirement Accounts
310	Break Funding
410	Ledger Instruments
510	Merchant Cards
520	Mutual Funds
530	Other Services
540	Trusts
910	Derivatives
920	Forward Rate Agreements
925	Futures
930	FX Contracts
940	Caps / Floors / Collars
950	Guarantees
960	Swaps
970	Rate Lock Commitments

The cash flow engine uses the INSTRUMENT_TYPE_CD to determine the instrument of an account when accounts of different instruments are grouped (on a report or other query).

Data Verification Requirements and Suggested Defaults

The INSTRUMENT_TYPE_CD 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 TERM DEPOSITS table should be assigned INSTRUMENT_TYPE_CD = 230.

Interest Type Code (INT_TYPE)

Definition

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

Module Usage

Oracle ALM and Funds Transfer Pricing cash flow methodologies reference INT_TYPE in determining whether interest payments are made in arrears or in advance. INT_TYPE impacts the calculation of interest income (financial element 430, 435).

1. If INT_TYPE = 1, the record is considered an interest in arrears. Interest payments are paid at the end of the payment period along with the principal payments.

2. If INT_TYPE = 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. If INT_TYPE = 3, the record is considered as rate set in arrears, and the interest is also paid in arrears. This is a unique case where both the rate is set in arrears and the interest is paid in arrears. This setting will typically be used only for modeling Set in Arrears SWAPS.

4. The calculation used to determine interest income (financial element 430) for an interest in an advance record depends also on the ACCRUAL_BASIS_CD. Following are the relevant equations for an interest in the advance calculation:

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

Current Period's 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)

where:

Following Payment, Date is the payment after the Next Payment Date.

Calculated Following Payment Date is the Next Payment Date rolled forward by the number of months in PMT_FREQ.

In most cases (a) would be the same as (b); however, if there is a short or extended maturity, (a) <> (b), and therefore the last interest cash flow (in other words, the payment just before maturity) would need to consider this factor.

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

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

Current Period's Ending Balance * Cur Net Rate/100 * (Following Payment Date -Current Payment Date)/365.

5. Even though the cash flow engine pays interest in advance on every payment date except for the MATURITY_DATE, the REMAIN_NO_PMTS_C field should count MATURITY_DATE as a payment date because the principal is still paid on this date.

6. For multiple reprice events within a payment event, interest in advance is not supported. Instead, interest is calculated using interest in arrears concept. An error message is logged when multiple reprice data has Interested in advance “Interest in Advance is not supported for multiple reprice events. Hence defaulted to Interest in Arrears”.

Data Verification Requirements and Suggested Defaults

· If INT_TYPE = 2, AMRT_TYPE_CD = 700, 820, 850, 801, 802 or non-conventionally amortizing User-Defined Payment Patterns.

· INT_TYPE valid values are 1, 2, and 3.

· If INT_TYPE = 2, REMAIN_NO_PMTS_C should still count MATURITY_DATE as a payment date.

· If INT_TYPE = 2 and ORIGINATION_DATE > AS_OF_DATE, NEXT_ PAYMENT_DATE and LAST_PAYMENT_DATE = ORIGINATION_DATE.

· If the ORIGINATION_DATE > AS_OF_DATE, the NEXT_PAYMENT_DATE and LAST_PAYMENT_DATE should 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_CDs only.

· If a compounding method has been chosen, the cash flow engine derives the compounded rate before calculating the preceding interest income amounts.

Interest Rate Code (INTEREST_RATE_CD)

Definition

Identifies the index to which adjustable and floating rate accounts are tied.

Module Usage

Oracle ALM

The cash flow engine references INTEREST_RATE_CD when calculating a forecasted interest rate for an ALM process.

1. The detail record's INTEREST_RATE_CD has a corresponding reference in the Oracle ALM Forecast Rate assumption rule and related Rate Management Interest Rate UI. The Rate Management Interest Rate code screen is where the term structure and historical rate values are managed. The Forecast Rates UI is where the forecast rates are input for each IRC across all required scenarios.

2. At a repricing event (or a TEASER_END_DATE) for an adjustable-rate record, the cash flow engine matches the INTEREST_RATE_CD, REPRICE_FREQ, and repricing date of the detail record to the Forecast Rates assumption rule attached to the ALM Process. After matching the rate from the Forecast Rates rule, the cash flow engine adds the MARGIN amount and applies any teases, rate caps/floors, and rounding to derive the rate that is applied to the record.

NOTE:

As explained in the Adjustable Type Code (ADJUSTABLE_TYPE_ CD) section, the cash flow engine does not reference repricing date information for ADJUSTABLE_TYPE_CD = 30 or 50.

3. The exact value of the INTEREST_RATE_CD is user-defined, but it must be within the range of 1 - 99999.

4. Note, fixed-rate records do not reference an INTEREST_RATE_CD and can be defaulted to a value of 0.

Transfer Pricing

Oracle Funds Transfer Pricing does not reference INTEREST_RATE_CD because it processes cash flows within repricing periods.

Data Verification Requirements and Suggested Defaults

· If ADJUSTABLE_TYPE_CD = 0, INTEREST_RATE_CD can be defaulted to 0.

· If ADJUSTABLE_TYPE_CD <> 0, INTEREST_RATE_CD = 001 - 99999. Be sure that the Interest Rate Code value mapped to data records has a corresponding entry in the Rate Management Interest Rate Codes user interface.

Issue Date (ISSUE_DATE)

Definition

The date the account was originated (issued) by the originating institution. For derivative instruments, it would be equal to the Trade Date.

Module Usage

The cash flow engine references ISSUE_DATE for future originating accounts.

ISSUE_DATE is referenced by the cash flow engine in Market Value and GAP calculations when processing records with future origination dates. If ISSUE_DATE <= AS_OF_DATE and ORIGINATION_DATE > AS_OF_DATE, the record is an account which has been traded but not settled. Therefore, the record is included in the Oracle ALM Market Value and GAP results if these processing options have been selected.

However, if ISSUE_DATE > AS_OF_DATE and ORIGINATION_DATE > AS_OF_ DATE, the record has been neither traded nor originated. Therefore the balance associated with the record is not included in static Market Value or static GAP results (static means as of the AS_OF_DATE).

NOTE:

If the dynamic start dates in the Oracle ALM Time Buckets definition are set on or beyond the future ORIGINATION_ DATE of the record, Market Value and GAP results are calculated for the related Dynamic Start Date (START_DATE_INDEX).

Data Verification Requirements and Suggested Defaults

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

· For accounts acquired through the 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 <= 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_CD = 0, LAST_REPRICE_DATE can be defaulted to be less than or equal to the ISSUE_ DATE.

Last Payment Date (LAST_PAYMENT_DATE)

Definition

The date on which the record's last (previous) payment was made.

Module Usage

Oracle ALM

Oracle ALM uses LAST_PAYMENT_DATE to calculate the payment period and interest income (financial element 430) for the first forecasted cash flow.

1. The first forecasted cash flow from the AS_OF_DATE references NEXT_ PAYMENT_DATE minus LAST_PAYMENT_DATE to determine the payment period for interest income calculations. The use of LAST_PAYMENT_ DATE rather than (NEXT_PAYMENT_DATE - PMT_FREQ) provides 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.

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

3. For future originations (AS_OF_DATE < ORIGINATION_DATE), LAST_ PAYMENT_DATE should always be equal to the ORIGINATION_DATE.

4. Even though the first forecasted cash flow may be extended, the PMT_FREQ should always be extracted as the records general frequency of payment.

NOTE:

For Payment Schedules, the cash flow engine does not use the LAST_ PAYMENT_DATE field in the instrument table. For these records, Interest on the next payment is calculated from the last date in the payment schedule, before AS_OF_DATE till next date in payment schedule after AS_OF_DATE.

However, for Payment Schedules LAST_PAYMENT_DATE from the detail record should correspond to the last defined payment date before the AS_ OF_DATE in the Schedule or Pattern interface.

Transfer Pricing

Oracle Funds Transfer Pricing refers to LAST_PAYMENT_DATE in the following cases:

· When remaining term option is selected

· When calculating Economic Value

· When calculating Economic Loss on Breakage Charges

The impact on these calculations is the same as described above for ALM.

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 > AS_OF_DATE, LAST_PAYMENT_DATE = ORIGINATION_DATE.

· If ORIGINATION_DATE <= AS_OF_DATE, LAST_PAYMENT_DATE >= ORIGINATION_DATE.

· If INT_TYPE = 2 and ORIGINATION_DATE > AS_OF_DATE, NEXT_ PAYMENT_DATE and LAST_PAYMENT_DATE = ORIGINATION_DATE. (e.g. for FRA's)

Last Repricing Date (LAST_REPRICE_DATE)

Definition

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

Module Usage

Oracle ALM

Oracle ALM does not reference the LAST_REPRICE_DATE field for either fixed or adjustable-rate records. All rate information in the Oracle ALM context is generated in the future from the AS_OF_DATE. CUR_NET_RATE, CUR_GROSS_RATE, and TRANSFER_RATE information from the detail record are referenced to obtain the rate information from the LAST_REPRICE_DATE.

NOTE:

In addition to REPRICE_FREQ, Oracle ALM also uses the ADJUSTABLE_TYPE_CD to determine if a record is adjustable.

Transfer Pricing

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

For example, if the record's LAST_REPRICE_DATE = 1/15/2011 and the Rate Management Interest Rate Code (IRC) is defined at monthly intervals and only at month-end, the reference date would be 12/31/2010. The REPRICE_ FREQ is then matched to the same term on the transfer pricing yield curve (IRC) defined in Rate Management.

2. For an adjustable-rate cash flow transfer-priced record, FTP cash flow transfer prices 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 fields are not used directly to define the transfer rate. They are the starting and ending points within which FTP 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

· Oracle Funds Transfer Pricing specific:

If REPRICE_FREQ = 0, LAST_REPRICE_DATE = ORIGINATION_DATE

If REPRICE_FREQ <> 0, LAST_REPRICE_DATE >= ORIGINATION_DATE

· If REPRICE_FREQ <> 0, LAST_REPRICE_DATE <= AS_OF_DATE

· If REPRICE_FREQ <> 0 and TEASER_END_DATE <= AS_OF_DATE, LAST_ REPRICE_DATE + REPRICE_FREQ = NEXT_REPRICE_DATE

· LAST_REPRICE_DATE < NEXT_REPRICE_DATE

Last Reprice Date Expected Balance (LRD_EXPECTED_BAL)

Definition

This field holds the expected (offset) balance as of the last reprice date.

Module Usage

If the instrument is an Adjustable Rate, then the TP Engine reads this amount as the offset balance and net against the Last Reprice Date Balance for purposes of computing the interest amount.

This will apply to cash flow TP methods with standard terms selected. These do not apply to Economic Value or Economic Loss calculations.

Data Verification Requirements and Suggested Defaults

None

Last Reprice Date Balance (LRD_BALANCE)

Definition

Balance as of the record's previous repricing event.

Module Usage

Oracle ALM

Oracle ALM does not reference the LRD_BALANCE field.

Transfer Pricing

Oracle Funds 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, FTP 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 AS_OF_DATE, the record's existing CUR_PAR_BAL is smaller than it was on the LAST_REPRICE_DATE. Therefore, to provide an accurate balance amount at the time of the LAST_ REPRICE_DATE, the LRD_BALANCE is provided. Oracle Funds 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.

Liquidity Premium Charge Credit (LIQUIDITY_PREM_CHARGE_CREDIT)

Definition

Oracle FTP calculates the funds charge or credit due to liquidity risk when the user selects the Adjustments, Charge/Credit option in the TP Process – Calculation Elements block.

Module Usage

This field is populated by the FTP process (optionally) if selected in the Calculation Elements block. The TP Engine calculates this amount as follows:

AVG_BOOK_BAL or CUR_BOOK_BAL X LIQUIDITY_PREMIUM_RATE/100 X ACCRUAL BASIS

NOTE:

The balance referenced in the earlier calculation is selected in the FTP Application Preferences screen

Data Verification Requirements and Suggested Defaults

None

Liquidity Premium Amount (LIQUIDITY_PREMIUM_AMT)

Definition

Oracle Funds Transfer Pricing populates this field (optionally) when the user specifies a Liquidity Adjustment amount in the TP Adjustment Rule.

Module Usage

This field is related to FTP Adjustment Rules. When the Liquidity Adjustment type is defined and included in the TP process, the TP Engine calculates and populates this field according to the amount input by the user through the Adjustment Rule user interface.

Data Verification Requirements and Suggested Defaults

None

Liquidity Premium Rate (LIQUIDITY_PREMIUM_RATE)

Definition

Oracle Funds Transfer Pricing populates this field (optionally) when the user specifies a Liquidity Adjustment rate or defines a formula-based rate in the TP Adjustment Rule.

Module Usage

This field is related to FTP Adjustment Rules. When the Liquidity Adjustment type is defined and included in the TP process, the TP Engine calculates and populates this field according to the assumption input by the user through the Adjustment Rule user interface.

Data Verification Requirements and Suggested Defaults

None

Margin (MARGIN)

Definition

MARGIN is the contractual spread in Oracle ALM that is added to the pricing index and results in the financial institution's retention (net) rate, for adjust-able-rate accounts.

Module Usage

Oracle ALM

1. MARGIN is used during cash flow generation.

2. For adjustable-type records, MARGIN is the contractual spread above/below the index that is applied throughout the instrument's life. The financial institution's 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:

After matching the rate from the Forecast Rates assumption rule, if the IR Margin type cd = 1 (Percent) engine calculates Margin using forecast raw rates, and Margin percent provided in column MARGIN as MarginC = Margin % * Raw RateC. Margin calculated is added back to Raw Rate.

If IR Margin type cd =0 (Rate), provided MARGIN amount gets directly added to Raw Rate.

Any teases, rate caps/floors, and rounding are applied thereafter to derive the rate that is applied to the record.

NOTE:

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

Transfer Pricing

MARGIN is used only 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.

Margin Type Code(IR_MARGIN_TYPE_CD)

Definition

Identifies provided Margin and Margin Gross is fixed Rate spread or calculated as a percentage of the forecasted interest rate.

Module Usage

Oracle ALM uses IR_MARGIN_TYPE_CD to determine whether provided Margin, Margin Gross is fixed Rate or calculated using the forecasted interest rate.

Expected IR Margin type code values as follows

Table 65: List of IR Margin type codes
Code Value	IR Margin Type
0	Rate
1	Percent

· When IR_MARGIN_TYPE_CD = 0 (Rate), data is provided as a Fixed spread in Margin columns. Given Margin is added to the forecasted rate.

· When MARGIN_TYPE_CD =1, MARGIN, and GROSS MARGIN data is provided as Percent of forecasted rate. The engine uses Margin Percent data along with Forecasted Raw RateC to calculate Margin/ Margin Gross. The margin on reprice event is calculated as

MarginC = Margin % * Raw RateC.

For example:

IR_MARGIN_TYPE_CD=1, MARGIN=10, Raw Rate derived on next reprice event= 5%. 6% on following repricing event.

On the next reprice event:

MarginC= Margin Percentage (in percentage) * Raw Rates (in percentage)

MarginC = 10% * 5% or {[ (10/100) * (5/100) ] * 100} = 0.5%. Calculated Margin is added to raw rate of 5%, for a net rate of 5.5%

On Following reprice event:

MarginC = 10% * 6% or {[ (10/100) * (6/100) ] * 100} = 0.6%.Calculated Margin is added to raw rate (6%), for a net rate of 6.6%.

Any teases, rate caps/floors, and rounding are applied thereafter to derive the rate that is applied to the record.

Data Verification Requirements and Suggested Defaults

Margin can be defined as Rate or Percent. IR Margin type code column is used to identify the kind of Margin provided.

· Possible values are 0 and 1. Rate Spread is referred by 0. If Rate spread is 2%, provided as 2 in margin related columns.This rate will get added to the forecasted rate to arrive at the net rate used by the instrument

· Percent Spread is referred by 1. If Percent spread is 5% of the repriced rate, then it is provided as 5 in margin related columns.This rate will get multiplied by the forecasted rate to arrive net rate used by the instrument

Market Value (MARKET_VALUE_C)

Definition

Market Value, calculated by Oracle ALM, or populated by the institution for use by Oracle Transfer Pricing Option Cost calculations.

Module Usage

Oracle ALM

Both the Static Deterministic and Dynamic Deterministic ALM processes will calculate and output Market Value when the Market Value option is selected from the Calculation Elements block. This result is written to the FSI_O_RESULT_MASTER and FSI_O_CONSOLIDATED_MASTER tables for each scenario defined in Forecast Rates. Additionally, users can choose to update the instrument data with Market Value for each record if the related option is selected on the Output Preferences block. The instrument record will be updated for scenario 1 result only.

On the instrument record only, Market Value is stored as:

Market Value / Current Par Bal * (1-Pct sold)*100

Transfer Pricing

Oracle Funds Transfer Pricing does not use MARKET_VALUE_C (from the instrument record), except in Option Costing. When Remaining Term Calculation Mode is selected in the TP Process, and the Target Balance for the subject product leaf is Market Value, Oracle Funds Transfer Pricing Option Cost calculations use the product of CUR_PAR_BAL and MARKET_ VALUE_C as the target balance to which the sum of future discounted cash flows is set equal.

Data Verification Requirements and Suggested Defaults

Because Oracle ALM calculates MARKET_VALUE_C, the default can be set to 0 or NULL for organizations that use Oracle ALM only. Organizations that use Oracle Funds Transfer Pricing option cost calculations may need to populate the column during the extract and record loading process.

Market Value Clean (MARKET_VALUE_CLEAN_C)

Definition

Market Value Clean (or Clean Price) is equal to the standard market value less than the accrued interest.

Module Usage

Both the Static Deterministic and Dynamic Deterministic ALM processes will calculate and output Market Value Clean when the Market Value option is selected from the Calculation Elements block. This result is written to the FSI_O_RESULT_MASTER and FSI_O_CONSOLIDATED_MASTER tables for each scenario defined in Forecast Rates. Additionally, users can choose to update the instrument data with Market Value Clean for each record if the related option is selected on the Output Preferences block. The instrument record will be updated for scenario 1 result only.

Data Verification Requirements and Suggested Defaults

None

Matched Spread (MATCHED_SPREAD_C)

Definition

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

Module Usage

Oracle ALM

Oracle ALM does not use MATCHED_SPREAD_C.

Transfer Pricing

Oracle Funds Transfer Pricing computes MATCHED_SPREAD_C when processing using the standard pricing basis (when the remaining term pricing basis switch in the Standard Transfer Pricing Process is off).

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

None

Matched Spread Alternate (MATCHED_SPREAD_ALT)

Definition

Interest margin on a product, calculated by Oracle Funds Transfer Pricing when an Alternate Rate Output Mapping Rule is attached to the Standard TP process and the target for the alternate Transfer Rate is TRANSFER_RATE_ALT.

Module Usage

Alternate Rate Output Mapping rules allow the user to map transfer pricing results to alternate columns rather than standard output columns. This functionality allows the user to calculate and output more than one Transfer Rate and the related Matched Spread for all records included in the TP process.

Oracle ALM

Oracle ALM does not use MATCHED_SPREAD_ALT.

Transfer Pricing

Oracle Funds Transfer Pricing computes MATCHED_SPREAD_ALT when processing using the standard TP process with an Alternate Rate Output Mapping Rule attached. The Standard TP Process calculates and outputs the MATCHED_SPREAD_ALT as follows:

For assets: Current Net Rate - Transfer Rate Alternate

For liabilities: Transfer Rate Alternate - Current Net Rate

Data Verification Requirements and Suggested Defaults

None

Maturity Amount (MATURITY_AMOUNT)

Definition

This optional column is used when AMRT_TYPE_CD = 850 (Annuity). Maturity Amount is an optional input and represents the value (principal and accrued interest) of the record at the maturity date for annuities.

Module Usage

Maturity Amount allows the user to define the target ending balance for the account to reach by maturity date.

Data Verification Requirements and Suggested Defaults

None

Maturity Date (MATURITY_DATE)

Definition

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

Module Usage

For both Oracle ALM and Funds Transfer Pricing, MATURITY_DATE defines the final date of payment for the record. The MATURITY_DATE signals the end of processing for a given record.

Oracle ALM

1. As described in the NEXT_PAYMENT_DATE section, the cash flow engine processes a record until the MATURITY_DATE has been reached. This occurs in one of two ways:

§ The PMT_FREQ is rolled until it finally reaches the MATURITY_DATE.

§ The REMAIN_NO_PMTS_C is reduced to 1, in which case, the record immediately moves to its MATURITY_DATE.

2. MATURITY_DATE is considered the final payment date. Any remaining principal balance that was not reduced by a scheduled payment date is paid on the MATURITY_DATE (regularly scheduled principal runoff is financial element 190 or 192 and maturity principal runoff is financial element 195 or 197). Therefore, at the MATURITY_DATE, the record's balance is reduced to 0.

3. If the record has a balloon amortization, the maturity payment includes the balloon or large final payment.

4. User-Defined Payment Schedules are an exception. Payment Schedules make their final payment on the last day as defined in the PAYMENT_SCHEDULE table. MATURITY_DATE is not referenced.

5. User-Defined Payment Patterns reference the MATURITY_DATE as the final payment date. Also, to calculate the remaining number of payments, if the payment pattern is split or if the balance is a new business record, Oracle ALM references the payment pattern payment frequencies and counts the number of payments from the AS_OF_DATE to the MATURITY_DATE (new business records reference the future date of origination rather than the AS_OF_DATE).

Transfer Pricing

1. MATURITY_DATE is referenced for fixed-rate straight term transfer pricing methodologies. When defining the record's transfer pricing term, FTP subtracts the ORIGINATION_DATE from the MATURITY_DATE. The term is then matched to the relevant Interest Rate Code (IRC) in Rate Management. 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, FTP 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. Its use is the same as described in the following, for Oracle ALM records.

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

Data Verification Requirements and Suggested Defaults

· For non-term accounts, MATURITY_DATE = AS_OF_DATE + 1 Day. If MATURITY_DATE defaults to 01-JAN-1900, the record's balance is not processed by Oracle ALM.

· For term accounts, MATURITY_DATE is required.

· If the record is not past due or defaulted, MATURITY_DATE > AS_OF_DATE.

· MATURITY_DATE = ORIGINATION_DATE + ORG_TERM

· MATURITY_DATE = AS_OF_DATE + REMAIN_TERM_C

· MATURITY_DATE <= NEXT_PAYMENT_DATE + (REMAIN_NO_PMTS_C * PMT_FREQ).

Assume that MATURITY_DATE is less than NEXT_PAYMENT_DATE + (REMAIN_NO_PMTS_C * PMT_FREQ). This implies that an account's calculated final payment date 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 condition 6 is not met (most likely caused because REMAIN_NO_PMTS_C is too low), the cash flow engine skips scheduled payments.

Max Index Value (MAX_INDEX_VALUE)

Definition

Represents Max index value to be used for Inflation-Indexed Instruments.

Module Usage

Oracle ALM reference MAX_INDEX_VALUE for the inflation-indexed instrument when CAP_PROTECTION_CATEGORY is Max during Life (CD=2).

When CAP_PROTECTION_CATEGORY= Max during life, Max index value from Origination is used to determine the Index Factor. The engine would not be able to go back to obtain historical index value for calculation of maximum index value from the origination date till as of date. Hence max index value from origination to as of date needs to be provided in this field.

Minimum Balance (MINIMUM_BALANCE)

Definition

Used for modeling Mortgage Offset Accounts (MOA's), this field represents the minimum balance required in the MOA (before and after potential offsets) for any offsets to occur. This is an input field that should be present in the consumer, mortgage, or commercial loan table records that are tied to deposit/savings accounts. If the balance of the MOA is less than the MINIMUM_BALANCE, no offsets occur.

Module Usage

The cash flow engine uses MINIMUM_BALANCE to apply Mortgage Offset Account product parameters to the mortgage offset procedure. Each financial institution can set limit minimums appropriate for each loan record.

Data Verification Requirements and Suggested Default

Minimum Balance > 0 when modeling Mortgage Offsets Accounts

Modified Duration (MODIFIED_DURATION_C)

Definition

Calculated by ALM Deterministic Processes (optionally), this output field represents the modified duration.

Module Usage

Both the Static Deterministic and Dynamic Deterministic ALM processes will calculate and output Modified Duration when the Market Value option is selected from the Calculation Elements block. This result is written to FSI_O_RESULT_MASTER and FSI_O_CONSOLIDATED_MASTER tables for each scenario defined in Forecast Rates. Additionally, users can choose to update the instrument data with Modified Duration for each record if the related option is selected on the Output Preferences block. The instrument record will be updated for scenario 1 result only.

The cash flow engine calculates the modified duration using the following formula:

Title: Description of the Modified Duration formula follows - Description: The illustration shows the formula to calculate the Modified Duration.

Description of the Modified Duration formula follows

Data Verification Requirements and Suggested Defaults

None

Negative Amortization Amount (NEG_AMRT_AMT)

Definition

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

Module Usage

The Oracle ALM and Funds Transfer Pricing adjustable-type cash flow methodologies reference NEG_AMRT_AMT in calculating the current payment for negative amortization-type accounts. This is relevant only for adjustable-rate accounts with AMRT_TYPE_CD = 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 field 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 enable the application 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.

Following is the process of events in regards to NEG_AMRT_AMT and related negative amortization fields:

3. Record is currently negatively amortizing because the payment amount, as defined by CUR_PAYMENT, is not enough to cover the principal and an interest portion. The unpaid interest at each payment date goes into the NEG_AMRT_ AMT field and back into the principal.

4. While calculating a payment event (the payment date), if the cash flow engine calculates negative principal runoff, it additionally checks the negative amortization limit (NEG_AMRT_LIMIT) 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 recalculates the payment amount to fully amortize the instrument.

5. 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, the record may 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.

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

7. 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 record's CUR_PAYMENT will be fully re-amortized. NEG_AMRT_EQ_DATE will ignore 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 will no longer be 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_CD <> 600, NEG_AMRT_AMT = 0.

· If AMRT_TYPE_CD = 600, 0 <= NEG_AMRT_AMT <= NEG_AMRT_ LIMIT/100 * ORG_PAR_BAL.

· If not applicable, default to 0.

Negative Amortization Equalization Date (NEG_AMRT_EQ_DATE)

Definition

The next date that a negative amortization-type account will fully re-amortized, regardless of payment caps and floors.

Module Usage

The Oracle ALM and Funds 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 relevant only for adjustable-rate accounts with AMRT_TYPE_CD = 600.

· limits for the life of the record. Therefore, after the payment recalculation of a NEG_AMRT_EQ_DATE, the record will no longer be negatively amortizing.

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

NOTE:

If AMRT_TYPE_CD <> 600, NEG_AMRT_EQ_DATE = 01-JAN-1900.

· If AMRT_TYPE_CD = 600, NEG_AMRT_EQ_DATE > ORIGINATION_DATE.

· If AMRT_TYPE_CD = 600, NEG_AMRT_EQ_DATE < MATURITY_DATE.

Negative Amortization Equalization Frequency (NEG_AMRT_EQ_FREQ)

Definition

Used in conjunction with NEG_ AMRT_EQ_MULT to define the frequency that negatively amortizing accounts are fully re-amortized.

Module Usage

Oracle ALM and Funds Transfer Pricing cash flow methodologies reference NEG_AMRT_EQ_FREQ in calculating the current payment for negative amortization-type accounts. This is relevant only for adjustable-rate accounts with AMRT_TYPE_CD = 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 record's CUR_ PAYMENT will be fully re-amortized. NEG_AMRT_EQ_FREQ will ignore payment decrease/increase limits per period and payment decreases/increase limits for the life of the record. Therefore, after the payment recalculation of a NEG_AMRT_EQ_FREQ, the record will no longer be negatively amortizing.

3. If NEG_AMRT_EQ_FREQ = 0, once the modeling date is past the NEG_AMRT_ EQ_DATE, the cash flow engine will not attempt to re-amortize the negative amortized amount. In this case, any negative amortized balance will balloon at maturity.

Data Verification Requirements and Suggested Defaults

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

· If AMRT_TYPE_CD <> 600, NEG_AMRT_EQ_FREQ = 0.

· If AMRT_TYPE_CD = 600, 0 <= NEG_AMRT_EQ_FREQ < ORG_TERM.

· If AMRT_TYPE_CD = 600, AS_OF_DATE < NEG_AMRT_EQ_DATE <= MATURITY_DATE.

· Validation of NEG_AMRT_EQ_FREQ should always be done in conjunction with NEG_AMRT_EQ_MULT.

Negative Amortization Equalization Frequency Multiplier (NEG_AMRT_EQ_MULT)

Definition

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

Module Usage

This field is the multiplier of the NEG_AMRT_EQ_FREQ field. It is used in conjunction with NEG_AMRT_EQ_FREQ to define the frequency that negatively amortizing accounts are fully re-amortized. Oracle ALM and Funds Transfer Pricing cash flow calculations reference NEG_AMRT_EQ_MULT when recalculating the current payment as defined under the NEG_AMRT_EQ_FREQ section. 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

· The suggested default is M.

Negative Amortization Limit (NEG_AMRT_LIMIT)

Definition

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

Module Usage

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

1. While calculating a payment event (the payment date), if the cash flow engine calculates negative principal runoff, the CFE also checks the negative amortization limit (NEG_AMRT_LIMIT) 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 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, the record may continue to negatively amortize even after a NEG_AMRT_LIMIT has been exceeded. If negative amortization does continue, the NEG_AMRT_AMT will continue to grow.

Data Verification Requirements and Suggested Defaults

· If AMRT_TYPE_CD <> 600, NEG_AMRT_LIMIT = 0.

· If AMRT_TYPE_CD = 600, NEG_AMRT_LIMIT >= 0.

Net Margin Code (NET_MARGIN_CD)

Definition

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

Module Usage

Fixed Net Rate (NET_MARGIN_CD = 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. Because 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 detail record's NET_MARGIN_CD field is set to 1 (fixed) and the Model With Gross Rates switch is turned on in the ALM Product Characteristics rule, the existing business record does not reprice even if the record is an adjustable-rate product (CUR_NET_RATE does not reprice). 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 record's CUR_NET_RATE field represents this fixed spread and is used for interest income (financial element 430) calculations while the record's CUR_GROSS_RATE is used for prepayments and amortization.

With regards to new business (business originating beyond the AS_OF_DATE), if the Product Characteristics rule's Net Margin Flag is set to Fix Net Rate and the Model With Gross Rates switch is turned on, the rate used to derive new business interest income is taken from the Pricing Margin rule Net Margin and not from the Forecast Rates. This is because it is assumed that the Pricing Margin assumption contains the fixed spread that the bank is receiving as payment for maintaining the loans. The Net Margin from the Pricing Margin rule is used for interest income calculations while the gross rate, which is derived from the Forecast Rates assumption, is used for prepayment and amortization calculations.

NOTE:

If the NET_MARGIN_CD is set to Fix Net Rate, but the Model with Gross Rates switch is not turned on, the cash flow engine treats the records as if they were Floating Net Rate.

Data Verification Requirements and Suggested Defaults

NET_MARGIN_CD must be equal to 0 or 1.

For fixed-rate accounts and adjustable accounts that reprice, NET_MARGIN_ CD = 0 (default setting).

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

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.

Oracle ALM

Processing order in regards to NEXT_PAYMENT_DATE is as follows:

From the AS_OF_DATE, 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. See the following details.

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

On the payment date, the cash flow engine calculates the interest payments, principal payments, current deferred payments, prepayments, and negative amortization, if applicable. For an adjustable-type record where REPRICE_FREQ < PMT_ FREQ, the cash flow engine applies only the last repriced rate for payment calculation. If the record is not an AMRT_TYPE_CD 700 (non-amortizing), AMRT_TYPE_CD 850 (Annuity), or AMRT_TYPE_CD 600 (negatively amortizing), the record's principal balance is reduced at each payment date.

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

MATURITY_DATE is the final payment date. If the record's principal was not reduced by the payment amounts, the remaining principal balance is paid on the MATURITY_DATE.

Transfer Pricing

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. To define all the payment events within this period, it 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 four cash flow transfer pricing methodologies to derive the transfer rate.

Data Verification Requirements and Suggested Defaults

Required Conditions:

NEXT_PAYMENT_DATE > AS_OF_DATE

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 cash flow engine.

For example, if the NEXT_PAYMENT_DATE defaults to 01-JAN-1900, the cash flow engine rolls the record by PMT_FREQ from that date until the maturity date.

NEXT_PAYMENT_DATE <= MATURITY_DATE

If REMAIN_NO_PMTS_C > 1, NEXT_PAYMENT_DATE < MATURITY_DATE

If REMAIN_NO_PMTS_C = 1, NEXT_PAYMENT_DATE = MATURITY_DATE

MATURITY_DATE <= NEXT_PAYMENT_DATE + (REMAIN_NO_PMTS_C * 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 should always correspond to the relevant (next payment date after the AS_OF_DATE) predefined payment date information of the Absolute Pattern interface or PAYMENT_SCHEDULE table.

Suggested default:

If the next payment date is unknown, set to either:

2. AS_OF_DATE + PMT_FREQ , or

NOTE: MATURITY_DATE

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 from the AS_ OF_DATE.

Oracle ALM

In Oracle ALM the processing and use of NEXT_REPRICE_DATE are as follows:

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

If ADJUSTABLE_TYPE_CD = 30 or 50, the cash flow engine does not reference the NEXT_ REPRICE_DATE.

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

1. In defining the customer rate, on each reprices date, the cash flow engine matches the record's INTEREST_RATE_CD, the reprice date, and the REPRICE_FREQ to the appropriate term point on the forecasted Interest Rate Code (IRC) in the Forecast Rates assumption rule. To this derived rate, the cash flow engine adds the MARGIN (or MARGIN_ GROSS, if applicable) to arrive at the full note rate.

NOTE: The cash flow engine then applies interest rate rounding and periodic/lifetime rate caps/floors. If the record's TEASER_END_DATE is less than or equal to the AS_OF_DATE, the cash flow engine applies the calculated forecasted rate to the record. Otherwise, it applies the defined teased rate.

2. On a payment date, the forecasted rate derived on the repricing date is used for recalculating payment amounts.

If the Process with Transfer Rates option has been selected in the ALM Deterministic Process under Calculation Elements, the cash flow engine produces transfer rates by referring to the Transfer Pricing Rule attached to the ALM Process. No rounding, rate caps/floors, or tease checks are applied to the calculated transfer rate.

Transfer Pricing

4. NEXT_REPRICE_DATE is used by adjustable-rate straight term transfer-priced records when using the Remaining Term Pricing Basis. The AS_OF_DATE and NEXT_REPRICE_DATE define the term of the transfer pricing period. This term is matched to the relevant Interest Rate Code (IRC) in Rate Management to derive a transfer rate.

5. 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. To define all the payment events within this period, FTP rolls back from the NEXT_PAYMENT_DATE by the PMT_FREQ until just after the LAST_REPRICE_DATE. From this calculated payment date, FTP again rolls forward by the PMT_FREQ until just before the NEXT_ REPRICE_DATE. As FTP rolls forward, cash flows are produced. The cash flows produced are used by one of the four cash flow transfer pricing methodologies to derive the transfer rate.

Data Verification Requirements and Suggested Defaults

NOTE: For fixed-rate accounts, NEXT_REPRICE_DATE = MATURITY_DATE.

1. For administered rate accounts and floating rate accounts, use ADJUSTABLE_ TYPE_CD 30 or 50, which does not reference NEXT_REPRICE_DATE. Set the default to NEXT_REPRICE_DATE = NEXT_PAYMENT_DATE or MATURITY_ DATE.

2. If ADJUSTABLE_TYPE_CD = 250 and repricing information is available, then:

NEXT_REPRICE_DATE > AS_OF_DATE

NEXT_REPRICE_DATE <= MATURITY_DATE

Offset Percentage (OFFSET_PERCENT)

Definition

Used in the Mortgage Offset Account (MOA) process, the OFFSET_PERCENT is applied to the MOA expected balance at every payment date to calculate the remaining balance after offset for interest calculation purposes.

This is the percentage of the balance which is available as an offset. It can range from > 0 and <= 100. If set to 100, then the entire EXPECTED_BAL amount is used to offset the loan balance. If less than 100, then the EXPECTED_BAL used to offset the loan balance is reduced by the specified percentage.

Module Usage

The cash flow engine calculates the interest due on each loan payment date applying the OFFSET_PERCENT to the expected MOA loan balance assuming that the MOA meets minimum balance criteria. The cash flow engine calculates loan interest due using offsets for MOA for consumer, mortgage, and commercial data table instruments that have these columns populated. For more information see Expected Balance (EXPECTED_BAL).

For Mortgage Offset Accounts, OFFSET_PERCENT > 0

Option Risk-Free Rate (OPTION_RFR_IRC_CD)

Definition

Identifies the interest rate curve to be used as the risk-free interest rate source for the Black 76 options market valuation.

Module Usage

Oracle ALM cash flow methodologies reference OPTION_RFR_IRC_CD as one of the inputs required for the Black 76 options market valuation.Currently only supports adjustable-rate options (e.g. caps and floors).

Data Verification Requirements and Suggested Defaults

The assigned interest rate curve must be defined as risk-free and match instrument currency.The instrument must be adjustable-rate type in Investments, Mortgages, Borrowings, and Caps/Floors and have valid rate options and option volatility assigned.

Option Volatility Surface (OPTION_VOL_IRC_CD)

Definition

Identifies the option volatility surface, required for evaluating rate options using the Black 76 options market valuation method.

Module Usage

Oracle ALM cash flow methodologies reference OPTION_VOL_IRC_CD as one of the inputs required for the Black 76 options market valuation.Currently only supports adjustable-rate options (e.g. caps and floors).

Data Verification Requirements and Suggested Defaults

The assigned option volatility surface must match instrument currency and as-of date.The instrument must be adjustable-rate type in Investments, Mortgages, Borrowings, and Caps/Floors, and have valid rate options and valid risk-free interest rate assigned.

Option Market Value (OPTION_MARKET_VALUE_C)

Definition

Total net rate option value, as calculated by Oracle ALM using the Black 76 options market value model or populated by the institution for use in reporting.

Module Usage

Static Deterministic processes where the Black 76 Option Market Valuation has been selected for calculation, Oracle ALM cash flow will write back the total net lifetime value of all interest rate options in the base forecast rate scenario to this field.

Alternatively, institutions may also populate this value.NOTE:Any pre-populated values will be replaced by the Oracle ALM if the Options Market Valuation approach is selected in a static-deterministic process.

Data Verification Requirements and Suggested Defaults

Because Oracle ALM calculates OPTION_MARKET_VALUE_C, the default can be set to 0 or NULL for organizations that use Oracle ALM.All pre-requisite option market value inputs must be present and valid, and processing must be selected for Black 76 option valuation and selected to be written back in processing Output Presences.

Original Market Value (ORG_MARKET_VALUE)

Definition

The market value of the instrument at origination expressed as a percentage of the Original Par Balance.

Module Usage

Transfer Pricing

Oracle Funds Transfer Pricing uses ORG_MARKET_VALUE when calculating Option Costs.

When Standard Calculation Mode is selected in the Stochastic TP Process, and the Target Balance for the subject product leaf is Market Value, Oracle Funds Transfer Pricing Option Cost calculations use the product of ORG_PAR_BAL and ORG_MARKET_VALUE as the target balance to which the sum of future discounted cash flows is set equal.

Data Verification Requirements and Suggested Defaults

None

Original Payment Amount (ORG_PAYMENT_AMT)

Definition

The original payment amount at the date of origination.

Module Usage

Oracle ALM and Funds Transfer Pricing cash flow methodologies reference ORG_PAYMENT_AMT when referencing the payment amount at the time of the record's origination.

Oracle ALM

For User-Defined Payment Patterns with the payment method defined as % Original Payment, the cash flow engine uses the record's ORG_PAYMENT_AMT for all payments beyond the first forecasted one. The first forecasted one uses CUR_PAYMENT. For all other payment pattern payment methods, the cash flow engine uses the ORG_PAYMENT_ AMT.

Transfer Pricing

· 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 record's MATURITY_DATE. 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_CD.

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

Oracle ALM and Funds Transfer Pricing

NOTE: ORG_PAYMENT_AMT is also used in determining if the NEG_AMRT_AMT is exceeding its defined limits. This is relevant only for adjustable-rate accounts where AMRT_TYPE_CD = 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 to create a fully amortized record. After the recalculation, the cash flow engine references payment life increases/decreases fields (PMT_INCR_LIFE, PMT_DECR_LIFE). These fields limit the amount that 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.

Data Verification Requirements and Suggested Defaults

1. If AMRT_TYPE_CD <> 600 ORG_PAYMENT_AMT = 0.

2. If AMRT_TYPE_CD = Payment Pattern which references ORG Payment, ORG_PAYMENT_AMT should be a valid non-zero value.

3. If adjustable-rate and AMRT_TYPE_CD = 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.

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

Oracle ALM

ORG_PAR_BAL is referenced when processing User-Defined Payment Patterns in which the payment method is %Original Balance. When this payment pattern is selected, the cash flow engine applies payment amounts throughout the life of the loan that is a percentage of the value in the detail record's ORG_PAR_BAL field.

Transfer Pricing

Cash flow transfer pricing methodologies for fixed-rate records use ORG_PAR_BAL as the starting balance for all cash flow generation.

The Oracle 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 record's MATURITY_DATE. 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_CD.

When Standard Calculation Mode is selected in the TP Process, and the Target Balance for the subject product leaf is Par Balance, Oracle Funds Transfer Pricing Option Cost calculations use ORG_PAR_BAL as the target balance to which the sum of future discounted cash flows is set equal.

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.

· The original balance on Rule of 78 instruments should not be greater than the current balance. If AMRT_TYPE_CD = 710, ORG_PAR_BAL should be less than CUR_PAR_BAL.

Original Term (ORG_TERM)

Definition

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

Module Usage

The ORG_TERM of the instrument is referenced by Oracle Funds Transfer Pricing and Oracle ALM as the period from ORIGINATION_DATE to MATURITY_ DATE.

Transfer Pricing

ORG_TERM is referenced by Oracle Funds Transfer Pricing when calculating cash flows for fixed-rate cash flow methodologies. Additionally, FTP Adjustment Rules refer to Org Term when the Reference Term is set to Original Term.

Transfer Pricing and ALM

· Oracle Funds Transfer Pricing and Oracle ALM 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.

· If ORG_TERM < AMRT_TERM, the cash flow 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.

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_C

· ORG_TERM + ORIGINATION_DATE = MATURITY_DATE

Original Term Multiplier (ORG_TERM_MULT)

Definition

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

Module Usage

The cash flow engine references ORG_TERM_MULT when calculating current payments for adjustable-rate accounts and in transfer pricing fixed-rate accounts. ORG_TERM MULT determines the units (Months, Days, or Years) of ORG_TERM.

Data Verification Requirements and Suggested Defaults

Valid values are:

D - Days

M - Months

Y - Years

For non-term accounts, default to M.

Origination Date (ORIGINATION_DATE)

Definition

The date the current institution originated or acquired the instrument.

Module Usage

Both Oracle ALM and Funds Transfer Pricing reference the ORIGINATION_DATE as the start date of the record.

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

Additionally, when using a Prepayment Models:

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 (that is, TEASE_END_DATE > Current Bucket Date), then the REPRICE_FREQ is calculated as (ROUND(TEASE_END_DATE - ORIGINATION_DATE)/30.42,0)

Oracle ALM

ORIGINATION_DATE is used to determine the last payment date. If the LAST_ PAYMENT_DATE is erroneously before the ORIGINATION_DATE, the cash flow engine uses the ORIGINATION_DATE value instead. This is used during interest income calculations where the LAST_PAYMENT_DATE is referenced for the first forecasted interest income cash flow (financial element 430).

User-Defined amortization payment patterns that are defined as % Current Payment and have multiple payment frequencies (as defined in the Payment Pattern user interface) use ORIGINATION_DATE when calculating amortization to determine the payment amount. Transfer Pricing

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

When defining the record's payment dates, the cash flow engine starts from the record's 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_CD.

Straight term methodology references ORIGINATION_DATE when defining the transfer pricing term that is matched to the term on the yield curve (Rate Management 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's origination.

If the record is transfer-priced using a Spread From Interest Rate Code or Redemption Curve methodology, the option of choosing the IRC's 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 a fixed rate, the date of the IRC used for transfer rate calculations is the same as the detailed record's ORIGINATION_DATE. If an IRC of the same date does not exist the cash flow engine uses the closest preceding date's yield curve information.

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 <= AS_OF_DATE (unless future originations booked on system)

NOTE: 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)

Original Expected Balance (ORG_EXPECTED_BAL)

Definition

This field holds the original amount of the expected (offset) balance.

Module Usage

If the instrument record is Fixed Rate, then the TP Engine reads this amount as the offset balance and net against the Original Loan Balance for purposes of computing the interest amount.

This will apply to cash flow TP methods with standard terms selected. These do not apply to Economic Value or Economic Loss calculations.

Data Verification Requirements and Suggested Defaults

None

Other Adjustment Amount Alternate (OTHER_ADJ_AMOUNT_ALT)

Definition

Oracle Funds Transfer Pricing populates this field (optionally) when the user specifies an Other Adjustment amount in the TP Adjustment Rule and additionally attaches an Alternate Rate Output Mapping rule to the TP Process. The Other Adjustment type can be used for defining any type of TP Add-on Rate that does not fit into one of the other predefined Adjustment Type classifications.

Module Usage

This field is related to FTP Adjustment Rules. When the Other Adjustment adjustment type is defined and included in the TP process, the TP Engine calculates and populates this field according to the amount input by the user through the Adjustment Rule user interface.

Data Verification Requirements and Suggested Defaults

None

Other Adjustment Charge Credit (OTHER_ADJ_CHARGE_CREDIT)

Definition

Oracle FTP calculates the funds charge or credit due to the Other Adjustment adjustment type when the user selects the Adjustments, “Charge/Credit” option in the TP Process – Calculation Elements block.

Module Usage

This field is populated by the FTP process (optionally) if selected in the Calculation Elements block. The TP Engine calculates this amount as follows:

AVG_BOOK_BAL or CUR_BOOK_BAL X OTHER_ADJUSTMENTS_RATE/100 X ACCRUAL BASIS

Data Verification Requirements and Suggested Defaults

None

Other Adjustment Rate Alternate (OTHER_ADJ_RATE_ALT)

Definition

Oracle Funds Transfer Pricing populates this field (optionally) when the user specifies the Other Adjustment rate or defines a formula-based rate in the TP Adjustment Rule and additionally attaches an Alternate Rate Output Mapping rule to the TP Process. The Other Insurance User GuideOracle Financial Services Investigation Hub ApplicationAdjustment type can be used for defining any type of TP Add-on Rate that does not fit into one of the other pre-defined Adjustment Type classifications.

Module Usage

This field is related to FTP Adjustment Rules. When the Other Adjustment adjustment type is defined and included in the TP process, the TP Engine calculates and populates this field according to the assumption input by the user through the Adjustment Rule user interface.

Data Verification Requirements and Suggested Defaults

None

Other Adjustments Amount (OTHER_ADJUSTMENTS_AMT)

Definition

Oracle Funds Transfer Pricing populates this field (optionally) when the user specifies an Other Adjustment amount in the TP Adjustment Rule. The Other Adjustment type can be used for defining any type of TP Add-on Rate that does not fit into one of the other pre-defined Adjustment Type classifications.

Module Usage

Data Verification Requirements and Suggested Defaults

None

Other Adjustments Rate (OTHER_ADJUSTMENTS_RATE)

Definition

Oracle Funds Transfer Pricing populates this field (optionally) when the user specifies the Other Adjustment rate or defines a formula-based rate in the TP Adjustment Rule. The Other Adjustment type can be used for defining any type of TP Add-on Rate that does not fit into one of the other pre-defined Adjustment Type classifications.

Module Usage

This field is related to FTP Adjustment Rules. When the Other Adjustment adjustment type is defined and included in the TP process, the TP Engine calculates and populates this field according to the assumption input by the user through the Adjustment Rule user interface.

Data Verification Requirements and Suggested Defaults

None

Payment Adjustment Date (PMT_ADJUST_DATE)

Definition

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

Module Usage

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

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 provides for additional negative amortization to occur even after PMT_ADJUST_DATE has recalculated the payment amount.

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

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

Data Verification Requirements and Suggested Defaults

· For fixed-rate and non-term accounts, PMT_ADJUST_DATE = 01-JAN-1900.

· For adjustable rate accounts with AMRT_TYPE_CD <> 600, PMT_ADJUST_ DATE = NEXT_REPRICE_DATE.

· For adjustable rate accounts with AMRT_TYPE_CD = 600, the following conditions should exist:

PMT_ADJUST_DATE > AS_OF_DATE

PMT_ADJUST_DATE > ORIGINATION_DATE

PMT_ADJUST_DATE <= AS_OF_DATE + PMT_CHG_FREQ) PMT_ ADJUST_DATE <= MATURITY_DATE

Payment Change Frequency (PMT_CHG_FREQ)

Definition

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

Module Usage

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

NOTE: The PMT_CHG_FREQ is used to increment forward from the PMT_ADJUST_ DATE.

· 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 provides for additional negative amortization to occur even after the PMT_CHG_FREQ event has recalculated the payment amount.

Data Verification Requirements and Suggested Defaults

· If AMRT_TYPE_CD = 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_CD <> 600, PMT_CHG_FREQ = REPRICE_FREQ.

· For adjustable-rate accounts with AMRT_TYPE_CD = 600, the following conditions should exist:

PMT_CHG_FREQ <> 0

PMT_CHG_FREQ <= PMT_ADJUST_DATE - AS_OF_DATE

Payment Change Frequency Multiplier (PMT_CHG_FREQ_MULT)

Definition

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

Module Usage

Oracle ALM and Funds 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

5. Valid values are:

D - Days

M - Months

Y - Years

· For information on PMT_CHG_FREQ_MULT validation, see the validation details for Payment Change Frequency (PMT_CHG_FREQ)

Payment Decrease Limit - Cycle (PMT_DECR_CYCLE)

Definition

Maximum payment decrease allowed during a payment change cycle of an adjust-able-rate instrument.

Module Usage

Oracle ALM and Funds Transfer Pricing cash flow methodologies reference PMT_DECR_CYCLE when re-calculating the current payment for negative amortization events such as NEG_AMRT_LIMIT, PMT_ADJUST_DATE, and PMT_ CHG_FREQ. This is relevant only for adjustable rate accounts where AMRT_TYPE_ CD = 600.

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

· PMT_DECR_CYCLE is defined in terms of a percentage. The cash flow 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 earlier equation, the cash flow 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.

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

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

Data Verification Requirements and Suggested Defaults

· For accounts with AMRT_TYPE_CD <> 600, PMT_DECR_CYCLE = 0.

NOTE: For accounts with AMRT_TYPE_CD = 600, 0 <= PMT_DECR_CYCLE < 100

Payment Decrease Limit - Life (PMT_DECR_LIFE)

Definition

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

Module Usage

Oracle ALM and Funds Transfer Pricing cash flow methodologies reference PMT_DECR_LIFE when re-calculating the current payment for negative amortization events such as NEG_AMRT_LIMIT, PMT_ADJUST_DATE, and PMT_CHG_ FREQ. This is relevant only for adjustable-rate accounts where AMRT_TYPE_CD = 600.

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 cash flow engine performs the following check:

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

· If the newly calculated payment satisfies the earlier 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.

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

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

· NEG_AMRT_LIMIT

PMT_ADJUST_DATE

PMT_CHG_FREQ

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

Data Verification Requirements and Suggested Defaults

§ For accounts with AMRT_TYPE_CD <> 600, PMT_DECR_LIFE = 0.

· For accounts with AMRT_TYPE_CD = 600, 0 <= PMT_DECR_LIFE < 100.

Payment Frequency (PMT_FREQ)

Definition

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

Module Usage

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

Oracle ALM

PMT_FREQ is used in the Market Value calculation. The calculation is as follows:

MV = Cash Flow/(1 +r)t

PMT_FREQ is used to derive the r and t value for records when PMT_FREQ_MULT = M.

Following is an explanation of how the calculations that use the PMT_FREQ.

For records with PMT_FREQ MULT = M, r is defined as the discount rate divided by the number of payments per period. The number of payments per period is calculated as (12/PMT_FREQ).

r = Discount Rate/12/PMT_FREQ

The t value is defined as the number of days in the payment period from the AS_ OF_DATE divided by 30.41667. This amount is then rounded to a whole integer and then divided by the PMT_FREQ. The equation is as follows:

t = (Round((Current Payment Date - AS_OF_DATE) / 30.41667))/PMT_FREQ.

For user-defined Payment Schedules and Patterns, the Market Value formula is the same as used for PMT_FREQ = D records. That formula is:

t = (Current Payment Date - AS_OF_DATE/PMT_FREQ).

Funds Transfer Pricing

PMT_FREQ is referenced by the cash flow transfer pricing methodologies when deriving discounted cash flows.

Oracle ALM and Funds Transfer Pricing

Both Oracle ALM and Funds Transfer Pricing use PMT_FREQ in defining payment dates.

Oracle ALM defines the date of payment using PMT_FREQ in the following manner:

· During cash flow generation, from the NEXT_PAYMENT_DATE, cash flow engine increments forward by the PMT_FREQ until the MATURITY_DATE. Oracle ALM does not use NEXT_PAYMENT_DATE for payment schedule records.

· Oracle Funds 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. To define all the payment events within this period, FTP 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 four cash flow transfer pricing methodologies 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 record's ORIGINATION_DATE and rolls forward by the PMT_FREQ until the MATURITY_DATE.

· Oracle ALM and Funds Transfer Pricing both use the PMT_FREQ in the following, similar manner:

1. On the date of payment, the cash flow engine calculates the interest payments, principal payments, current deferred payments, prepayments, unscheduled prepayments, and negative amortization, if applicable. For an adjustable-type record where REPRICE_FREQ < PMT_FREQ, Oracle ALM applies only the last repriced rate for payment calculation.

2. During the payment calculation processing, PMT_FREQ is used for interest income calculations (financial element 430) for records with ACCRUAL_ BASIS_CDs of 30/360, 30/365, 30/ACTUAL.

3. PMT_FREQ is used in the Remaining Number of Payment calculation when calculating the payment amounts for balloon records and specific user-defined payment pattern instances.

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

PMT_FREQ <= ORG_TERM

MATURITY_DATE <= NEXT_PAYMENT_DATE + (REMAIN_NO_PMTS_C * PMT_FREQ).

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

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

Payment Frequency Multiplier (PMT_FREQ_MULT)

Definition

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

Module Usage

Oracle ALM and Funds 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

Payment Increase Limit - Cycle (PMT_INCR_CYCLE)

Definition

A maximum payment increase allowed during a payment change cycle of an adjustable-rate instrument.

Module Usage

Oracle ALM and Funds Transfer Pricing cash flow methodologies reference PMT_INCR_CYCLE when re-calculating the current payment for negative amortization events such as NEG_AMRT_LIMIT, PMT_ADJUST_DATE, and PMT_ CHG_FREQ. This is relevant only for adjustable-rate accounts where AMRT_TYPE_ CD = 600.

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

NOTE: 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 earlier 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.

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

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

NEG_AMRT_LIMIT

PMT_ADJUST_DATE

PMT_CHG_FREQ

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

Data Verification Requirements and Suggested Defaults

§ If AMRT_TYPE_CD <> 600, PMT_INCR_CYCLE = 0

§ If AMRT_TYPE_CD = 600, 0 <= PMT_INCR_CYCLE < 100

Payment Increase Limit - Life (PMT_INCR_LIFE)

Definition

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

Module Usage

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

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

§ 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 earlier 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.

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

NEG_AMRT_LIMIT

PMT_ADJUST_DATE

PMT_CHG_FREQ

· For an explanation of PMT_INCR_LIFE's relationship with other related negative amortization fields, see the e Negative Amortization Amount (NEG_AMRT_AMT).

Data Verification Requirements and Suggested Defaults

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

2. If AMRT_TYPE_CD <> 600, PMT_INCR_LIFE = 0.

3. If AMRT_TYPE_CD = 600, 0 <= PMT_INCR_LIFE < 100.

Percent Sold (PERCENT_SOLD)

Definition

Percent of balance sold to investors.

Module Usage

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

Oracle ALM and Funds Transfer Pricing cash flow methodologies use PERCENT_SOLD to perform all net balance calculations.

4. 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 that participated (sold) by the bank.

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

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

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

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

1. Oracle ALM only writes out Result Detail balance results in a net of participation.

2. PERCENT_SOLD must be greater than or equal to zero and must be less than 100%.

Data Verification Requirements and Suggested Defaults

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

3. 0 < PERCENT_SOLD < 100.

4. CUR_NET_BOOK_BAL_C = CUR_BOOK_BAL * (100 - PERCENT_SOLD) / 100.

· CUR_NET_PAR_BAL_C = CUR_PAR_BAL * (100 - PERCENT_SOLD) / 100.

· ORG_NET_BOOK_BAL_C = ORG_BOOK_BAL * (100 - PERCENT_SOLD) / 100.

· ORG_NET_PAR_BAL_C = ORG_PAR_BAL * (100 - PERCENT_SOLD) / 100.

1. If not applicable, PERCENT_SOLD = 0.

Pricing Incentive Charge Credit (PRICING_INC_CHARGE_CREDIT)

Definition

Oracle Funds Transfer Pricing calculates the funds charge or credit due to Pricing Incentives when the user selects the Adjustments, Charge/Credit option in the TP Process – Calculation Elements block.

Module Usage

This field is populated by the FTP process (optionally) if selected in the Calculation Elements block. The TP Engine calculates this amount as follows:

AVG_BOOK_BAL or CUR_BOOK_BAL X PRICING_INCENTIVE_RATE/100 X ACCRUAL BASIS

None

Pricing Incentive Amount (PRICING_INCENTIVE__AMT)

Definition

Oracle Funds Transfer Pricing populates this field (optionally) when the user specifies a Pricing Incentive Adjustment amount in the TP Adjustment Rule.

Module Usage

This field is related to FTP Adjustment Rules. When the Pricing Incentive Adjustment type is defined and included in the TP process, the TP Engine calculates and populates this field according to the amount input by the user through the Adjustment Rule user interface.

Data Verification Requirements and Suggested Defaults

None

Pricing Incentive Rate (PRICING_INCENTIVE_RATE)

Definition

Oracle Funds Transfer Pricing populates this field (optionally) when the user specifies a Pricing Incentive rate or defines a formula-based rate in the TP Adjustment Rule.

Module Usage

This field is related to FTP Adjustment Rules. When the Pricing Incentive adjustment type is defined and included in the TP process, the TP Engine calculates and populates this field according to the assumption input by the user through the Adjustment Rule user interface.

Data Verification Requirements and Suggested Defaults

None

Prior Transfer Pricing Period Average Daily Balance (PRIOR_TP_PER_ADB)

Definition

The average balance at the reprice date(s) before the LAST_REPRICE_DATE.

Module Usage

Oracle ALM

Oracle ALM does not reference PRIOR_TP_PER_ADB or CUR_TP_PER_ ADB.

Oracle Funds Transfer Pricing

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

2. 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 pricing equation. PRIOR_TP_ PER_ADB is used to determine the balance on the reprice date before the LAST_REPRICE_DATE and CUR_TP_PER_ADB is used to determine the balance as of the LAST_REPRICE_DATE.

For additional information. See Oracle Financial Services Funds Transfer Pricing User Guide.

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

4. If the TEASER_END_DATE is greater than the AS_OF_DATE, the mid-period repricing does not apply and the CUR_TP_PER_ADB and PRIOR_TP_PER_ ADB fields are not used.

Data Verification Requirements and Suggested Defaults

5. If the record is adjustable and repricing occurs within the month, PRIOR_TP_ PER_ADB = (average) balance at the time of the reprice date before the LAST_ REPRICE_DATE.

6. If the average balance at the time of the reprice date before the LAST_ REPRICE_DATE is not available, use CUR_PAR_BAL.

Rate Cap Life (RATE_CAP_LIFE)

Definition

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

Module Usage

Oracle ALM

Oracle ALM references RATE_CAP_LIFE when calculating a forecasted interest rate for adjustable rate records.

Existing business adjustable-rate records: The cash flow engine matches the REPRICE_FREQ, INTEREST_RATE_CD, and the reprice date to the information contained in the Forecast Rates assumption rule to assign a forecasted rate. The margin is then added to this forecasted rate. Any rounding, rate caps (RATE_CAP_LIFE), or floors and tease periods are applied, and the resulting rate is applied to the record as the record's repriced rate.

For accounts beyond the tease period: After the rounding and rate change minimum is applied to the forecast rate plus margin, if the resulting rate is > RATE_CAP_LIFE, the cash flow engine sets the record's forecasted rate = RATE_CAP_LIFE.

For Interest Rate Cap (Interest Rate Derivatives) accounts, the Rate_Cap_life field is used to store the Cap Strike rate. The cash flow engine will calculate interest cash flow when the underlying floating rate will go above given Rate_Cap_Life.

Oracle Funds Transfer Pricing

Oracle Funds Transfer Pricing does not reference RATE_CAP_LIFE because it processes cash flows within repricing periods.

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.

Rate Change Minimum (RATE_CHG_MIN)

Definition

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

Module Usage

Oracle ALM

Oracle ALM references RATE_CHG_MIN when calculating a forecasted interest rate.

· For existing business adjustable-rate records, the cash flow engine matches the REPRICE_ FREQ, INTEREST_RATE_CD, and the reprice date to the information contained in the Forecast Rates assumption rule to assign a forecasted rate. 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.

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 Forecast Rates assumption rule. After the RATE_CHG_MIN is calculated any other cap/floor, rounding, and tease periods are then applied.

Oracle Funds Transfer Pricing

Oracle Funds Transfer Pricing does not reference RATE_CHG_MIN because it processes cash flows within repricing periods.

Data Verification Requirements and Suggested Defaults

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

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

Rate Change Rounding Code (RATE_CHG_RND_CD)

Definition

The method used for rounding of the interest rate change.

Module Usage

Oracle ALM

Oracle ALM uses RATE_CHG_RND_CD to determine the rounding method that is applied to the current rate after a repricing event. RATE_CHG_ RND_CD is used in conjunction with RATE_CHG_RND_FAC.

For existing business adjustable-rate records, the cash flow engine matches the REPRICE_ FREQ, INTEREST_RATE_CD, and the reprice date to the information contained in the Forecast Rates assumption rule. This is to assign a forecasted rate. The margin is then added to this forecasted rate. Any rounding (RATE_CHG_RND_CD and RATE_ CHG_RND_FAC), rate caps/floors, and tease periods are applied, and the resulting rate is applied to the record as the record's repriced rate.

The RATE_CHG_RND_CD accepts values 1 - 4. Depending on the value input, the value of the forecasted rate as calculated earlier will differ.

NOTE: Following are explanations of the possible values:

Table 68: List of Rate Change Rounding Code Values
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 forecasted = 8.65, the truncated forecasted rate =8.00.
RATE_CHG_RND_CD = 2	Round-Up The cash flow engine rounds the rate up to 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 cash flow 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 cash flow 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.

Oracle Funds Transfer Pricing

Oracle Funds Transfer Pricing does not reference RATE_CHG_RND_CD because it processes cash flows within repricing periods.

Data Verification Requirements and Suggested Defaults

· RATE_CHG_RND_CD must be within the range of 0 to 4.

· For fixed-rate accounts, RATE_CHG_RND_CD = 4 and RATE_CHG_RND_FAC = 0.

· For variable-rate accounts with rates that are not rounded, RATE_CHG_RND_ CD = 4 and RATE_CHG_RND_FAC = 0.

Rate Change Rounding Factor (RATE_CHG_RND_FAC)

Definition

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

Module Usage

Oracle ALM

Oracle ALM 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_CD.

Oracle Funds Transfer Pricing

Oracle Funds Transfer Pricing does not reference RATE_CHG_RND_FAC because it processes cash flows within repricing periods.

Data Verification Requirements and Suggested Defaults

· For fixed-rate accounts, RATE_CHG_RND_CD = 4 and RATE_CHG_RND_FAC = 0.

NOTE: For variable-rate accounts with rates that are not rounded, RATE_CHG_RND_ CD = 4 and RATE_CHG_RND_FAC = 0.

· For variable-rate accounts with RATE_CHG_RND_FAC <> 0, 0 < RATE_CHG_ RND_FAC <= 1.

Rate Decrease Limit - Cycle (RATE_DECR_CYCLE)

Definition

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

Module Usage

Oracle ALM

Oracle ALM references RATE_DECR_CYCLE when calculating a forecasted interest rate. RATE_DECR_CYCLE sets the maximum amount (in terms of basis points) that the interest rate may decrease in a given REPRICE_FREQ.

· For existing business adjustable-rate records, the cash flow engine matches the REPRICE_ FREQ, INTEREST_RATE_CD, and the reprice date to the information contained in the Forecast Rates assumption rule. This is to assign a forecasted rate. 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 the record's repriced rate.

When applying the RATE_DECR_CYCLE, the cash flow engine checks for the following:

· Previous Current Rate > Calculated forecasted rate.

NOTE: 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

Oracle Funds Transfer Pricing

Oracle Funds Transfer Pricing does not reference RATE_DECR_CYCLE because it processes cash flows within repricing periods.

Data Verification Requirements and Suggested Defaults

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

Rate Floor Life (RATE_FLOOR_LIFE)

Definition

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

Module Usage

Oracle ALM

Oracle ALM references RATE_FLOOR_LIFE when calculating a forecasted interest rate for adjustable-rate records.

· For existing business adjustable-rate records, the cash flow engine matches the REPRICE_ FREQ, INTEREST_RATE_CD, and the reprice date to the information contained in the Forecast Rates assumption rule. This is to assign a forecasted rate. 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.

If the forecast rate plus margin < RATE_FLOOR_LIFE, the cash flow engine sets the record's forecasted rate = RATE_FLOOR_LIFE. Rounding and tease periods are then applied.

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

· For Interest Rate Floor (Interest Rate Derivatives) accounts, the Rate_Floor_life field is used to store the Floor Strike rate. The cash flow engine will calculate interest cash flow when the underlying floating rate will go below given Rate_Floor_Life.

Oracle Funds Transfer Pricing

Oracle Funds Transfer Pricing does not reference RATE_FLOOR_LIFE because it processes cash flows within repricing periods.

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.

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

Rate Increase Limit - Cycle (RATE_INCR_CYCLE)

Definition

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

Module Usage

Oracle ALM

Oracle ALM 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.

§ For existing business adjustable-rate records, the cash flow engine matches the REPRICE_ FREQ, INTEREST_RATE_CD, and the reprice date to the information contained in the Forecast Rates assumption rule. This is to assign a forecasted rate. The margin is then 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 the record's repriced rate.

When applying the RATE_INCR_CYCLE, the cash flow 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

Oracle Funds Transfer Pricing

Oracle Funds Transfer Pricing does not reference RATE_INCR_CYCLE because it processes cash flows within repricing periods.

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.

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 ALM

Oracle ALM references RATE_SET_LAG when calculating a forecasted interest rate.

· For existing business adjustable-rate records, the cash flow engine matches the REPRICE_ FREQ, INTEREST_RATE_CD and the lagged reprice date (after referencing RATE_SET_LAG) to the information contained in the Oracle ALM Forecast Rates assumption rule. This is to assign a forecasted rate. 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 the record's repriced rate.

If RATE_SET_LAG > 0, the cash flow engine does not assign a forecasted interest rate based upon NEXT_REPRICE_DATE. Instead, the cash flow 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 = 01-APR

RATE_SET_LAG = 1

RATE_SET_LAG_ MULT = M

MARGIN = 1.00

In this example, the account is tied to the Treasury Yield Curve. Because of the RATE_SET_LAG, Oracle ALM references the Treasury Yield Curve one month before the NEXT_REPRICE_DATE. The 3-Month point on the Treasury Yield Curve on 01-MAR equals 5%. Therefore the repriced rate equals 6% (5% plus the 1% margin).

· If the rate set date is less than the As of Date, the historical rate is retrieved from up to one year before the As of Date.

Oracle Funds Transfer Pricing

Oracle Funds Transfer Pricing does not reference RATE_SET_LAG because it processes cash flows within repricing periods.

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 .

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

Rate Set Lag Multiplier (RATE_SET_LAG_MULT)

Definitions

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

Module Usage

The Oracle ALM cash flow engine references RATE_SET_LAG_MULT when calculating a forecasted interest rate. 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

Remaining Number of Payments (REMAIN_NO_PMTS_C)

Definition

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

Module Usage

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

Oracle ALM and Funds Transfer Pricing

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

Definition of payment dates on which principal and interest are paid: As each payment is made during the life of the instrument, the cash flow engine reduces the REMAIN_ NO_PMTS_C by 1 and rolls the payment period forward by the PMT_FREQ. If the newly calculated REMAIN_NO_PMTS_C = 1, the cash flow engine no longer rolls the PMT_FREQ and makes the next (and final) payment on the MATURITY_DATE.

Amortization re-calculation purposes: When a re-calculation occurs (repricing or negative amortization event), the cash flow engine references the REMAIN_NO_PMTS_C for recalculation of amortization.

You should be aware that there are some exceptions to the use of REMAIN_NO_ PMTS_C 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.

Oracle Funds Transfer Pricing

· The Transfer Pricing - Remaining Term Pricing Basis cash flow methodology for fixed-rate records uses REMAIN_NO_PMTS_C as described earlier.

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

REMAIN_NO_PMTS_C + number of payment periods between the NEXT_ PAYMENT_DATE and the LAST_REPRICING_DATE.

Data Verification Requirements and Suggested Defaults

· REMAIN_NO_PMTS_C >= 1.

· If REMAIN_NO_PMTS_C = 0, record is invalid.

· If REMAIN_NO_PMTS_C = 1, NEXT_PAYMENT_DATE = MATURITY_DATE.

1. If REMAIN_NO_PMTS_C > 1, NEXT_PAYMENT_DATE < MATURITY_DATE.

2. Generally:

REMAIN_NO_PMTS_C * PMT_FREQ <= ORG_TERM * ORG_TERM_MULT.

MATURITY_DATE <= NEXT_PAYMENT_DATE + (REMAIN_NO_PMTS_ C * PMT_FREQ).

· For Behavior Pattern Instruments, REMAIN_NO_PMT_C should equal the number of payments (tenors) specified in the Behavior Pattern.

· For non-term accounts (Other Assets, Other Liabilities, and so on), REMAIN_NO_PMTS_C = 1.

· The maximum number of payment and repricing events that can be modeled cannot exceed 16000. REMAIN_NO_PMTS_C + (REMAIN_TERM_C (in days)) / (REPRICE_FREQ (in days)) > 16000.

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 ALM and Funds Transfer Pricing reference REPRICE_FREQ when identifying adjustable-rate instruments and calculating a transfer pricing term or forecasted interest rate.

Oracle ALM

· In identifying an adjustable record, Oracle ALM uses ADJUSTABLE_ TYPE_CD and REPRICE_FREQ. If the ADJUSTABLE_TYPE_CD > 0 and the REPRICE_FREQ > 0, the record is adjustable.

1. 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 record's remaining forecasted reprice dates. Rolling by the REPRICE_FREQ continues until MATURITY_DATE.

2. In defining the CUR_NET_RATE, CUR_GROSS_RATE, and TRANSFER_RATE on each reprices date, the cash flow engine matches the record's INTEREST_RATE_CD (TP IRC from the selected TP Rule in the case of transfer rates), the reprice date and the REPRICE_FREQ to the appropriate term point on the forecasted Interest Rate Code (IRC) in the Oracle ALM Forecast Rates assumption rule. To this derived rate, the cash flow engine adds the relevant margin amount (MARGIN, MARGIN_GROSS). For Transfer Rate, if the Transfer Pricing option is selected in the ALM Process, the cash flow engine will refer to the TP Rule selected in the process and will apply the appropriate TP Method and related TP IRC to determine the new TP rate on the reprice date.

· Any rate caps/floors, tease periods, and rounding is then applied.

· ADJUSTABLE_TYPE_CD = 30 and 50 will not reference reprice date.

Oracle Funds Transfer Pricing

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

· For adjustable-rate straight term methodology, Oracle Funds Transfer Pricing matches the REPRICE_FREQ to the same term on the Transfer Pricing yield curve (Interest Rate Code) defined in Rate Management. For additional information, see theLast Reprice Date Expected Balance (LRD_EXPECTED_BAL).

· FTP Adjustment Rules refer to REPRICE_FREQ when the Reference Term is set to Reprice Frequency. If the instrument is fixed rate and, therefore, does not have a reprice frequency, the calculation retrieves the rate associated with the term point equaling the original term on the instrument.

Data Verification Requirements and Suggested Defaults

· If REPRICE_FREQ > 0, MATURITY_DATE >= NEXT_REPRICE_DATE > AS_ OF_DATE.

· If REPRICE_FREQ > 0, INTEREST_RATE_CD is in the range of 1 - 99999.

· If REPRICE_FREQ > 0, ADJUSTABLE_TYPE_CD > 0.

1. REPRICE_FREQ must be either 0 or positive.

In Oracle ALM, ADJUSTABLE_TYPE_CD is used in conjunction with REPRICE_FREQ to define adjustable-rate records.

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 ALM and Funds Transfer Pricing reference 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

Residual Amount (RESIDUAL_AMOUNT)

Definition

Used for instruments with AMRT_TYPE_CD = 840 (Lease). This column represents the residual value of the lease at the maturity date.

Module Usage

Oracle ALM and Funds Transfer Pricing reference RESIDUAL_AMOUNT when AMRT_TYPE_CD = 840 (lease) to calculate the monthly payment due on the lease contract.

Data Verification Requirements and Suggested Defaults

3. If AMRT_TYPE_CD = 840, RESIDUAL_AMOUNT > 0.

4. If AMRT_TYPE_CD = 840, CUR_PAYMENT should include the P and I payment amount required to amortize the current principal balance to the residual amount by the maturity date.

5. If AMRT_TYPE_CD = 840 and ADJUSTABLE_TYPE_CD <> 0, the cash flow engine will re-compute the CUR_PAYMENT on each reprices date so the principal will amortize to the RESIDUAL_AMOUNT at maturity of the instrument.

Teaser-rate End Date (TEASER_END_DATE)

Definition

The date that the tease rate (introductory rate) ends and the normal product 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 (IRC) plus a margin.

Oracle ALM

· 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 modeling horizon.

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

· TEASER_END_DATE does not apply to fixed-rate accounts.

Oracle Funds Transfer Pricing

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

· If the TEASER_END_DATE is greater than the AS_OF_DATE, the Oracle Funds Transfer Pricing mid-period repricing does not apply. For further information, see the Oracle Financial Services Funds Transfer Pricing User Guide.

Data Verification Requirements and Suggested Defaults

· TEASER_END_DATE > ORIGINATION_DATE

· TEASER_END_DATE < MATURITY_DATE

NOTE: For fixed-rate accounts TEASER_END_DATE = 01-JAN-1900.

· TEASER_END_DATE >= NEXT_REPRICE_DATE

Transfer Price Average Life (TP_AVERAGE_LIFE)

Definition

In Oracle Funds Transfer Pricing, this is both an output field and an input field. The TP_AVERAGE_LIFE column can be populated by the Standard FTP process (optionally) when the TP Method selection is Cash Flow: Average Life and the related, update instrument option is selected in the Transfer Pricing rule. If selected, the calculated average life is output to the TP_AVERAGE_LIFE column of the instrument record. The average life amount in the TP_AVERAGE_LIFE column is additionally referenced by TP Adjustment Rules when the Reference Term selection is Average Life.

This column is only populated and read by Transfer Rate calculations.This column is not referenced by Adjustment Rate calculations.

Module Usage

The Average Life method determines the average life of the instrument by calculating the effective term (expressed in Years) required to repay half of the principal or nominal amount of the instrument. When applied as a Transfer Pricing method, the resulting TP rate is equivalent to the rate on the associated interest rate curve corresponding to the calculated term. Oracle Funds Transfer Pricing derives the Average Life based on the cash flows of an instrument determined by the characteristics specified in the Instrument Table and additionally applying any specified prepayment assumption. The average life formula calculates a single term, which is a point on the yield curve used to transfer price the instrument being analyzed.

Title: Description of the Average Life formula follows - Description: The illustration shows the formula to calculate the Average Life.

Description of _the Average Life formula follows

Where:

P is the principal

Pi is the principal repayment in coupon i, hence,

Description of principal and principal repayment

is the fraction of the principal repaid in coupon i and ti is the time from the start of coupon i.

Data Verification Requirements and Suggested Defaults

If the Adjustment Rule Reference Term selection is Average Life, then TP_AVERAGE_LIFE > 0. Note, this field can be populated manually (Expressed in Years) using an external calculation source or by the Transfer Pricing process.

Transfer Price Duration (TP_DURATION)

Definition

In Oracle Funds Transfer Pricing, this is both an output field and an input field. The TP_DURATION column can be populated by the Standard FTP process (optionally) when the TP Method selection is Cash Flow: Duration and the related, update instrument option is selected in the Transfer Pricing rule. If selected, the calculated Duration is output to the TP_DURATION column of the instrument record. The Duration amount in the TP_DURATION column is additionally referenced by TP Adjustment Rules when the Reference Term selection is Duration.

This column is only populated and read by Transfer Rate calculations.This column is not referenced by Adjustment Rate calculations.

Module Usage

Oracle Funds Transfer Pricing derives the Macaulay Duration (in Years) based on the cash flows of each instrument as determined by the characteristics specified in the Instrument Table and using any applicable prepayment rate. The Macaulay Duration formula calculates a single term, that is, a point on the yield curve used to transfer price the instrument.

Title: Description of the Modified Duration formula follows - Description: The illustration shows the formula to calculate the Modified Duration.

Description of the_Macaulay_Duration_formula_follows

Where:

N = Total number of payments from Start Date until the earlier of repricing or maturity

CFn = Cash flow (such as regular principal, prepayments, and interest) in period n

r = Periodic rate (current rate/payments per year)

m = Remaining term to cash flow/active payment frequency

tn = Remaining term to cash flow n, expressed in years

Within the Macaulay Duration calculation, the discount rate or current rate, r, is defined in the Transfer Pricing rule in one of three ways:

· The current rate is defined as the current net rate if the processing option, Model with Gross Rates is not selected and the current gross rate if the option is selected. The current rate is used as a constant discount rate for each cash flow.

· The user may directly input while defining the TP rule, a constant rate to use for discounts. If specified, this rate is used as a constant discount rate for each flow.

· The user can select to discount the cash flows using spot rates from a selected interest rate curve. With this approach, a discount rate is read from the selected interest rate curve corresponding to the term of each cash flow.

Data Verification Requirements and Suggested Defaults

If the Adjustment Rule Reference Term selection is Duration, then TP_DURATION > 0. Note, this field can be populated manually (expressed in Years) using an external calculation source or by the Transfer Pricing process.

Transfer Price Effective Date (TP_EFFECTIVE_DATE)

Definition

In Oracle Funds Transfer Pricing, TP_EFFECTIVE_DATE is used by the FTP Standard Process as an override date for determining the historical rate from the specified interest rate curve (IRC). TP_EFFECTIVE_DATE is typically used in cases where the customer rate on the instrument record is set before the origination date and users wish to align the TP Rate lookup with the date that the customer rate was set.

Module Usage

The FTP process normally uses the ORIGINATION_DATE for fixed-rate instruments or LAST_REPRICE_DATE for adjustable-rate instruments to determine historical rate effective date for the transfer rate lookup. This input allows users to specify an alternate effective date.

Data Verification Requirements and Suggested Defaults

· If applicable, set the TP_EFFECTIVE_DATE = ISSUE_DATE or the date on which the customer rate was set.

· TP_EFFECTIVE_DATE should be NULL if not applicable. Do not default TP_EFFECTIVE_DATE (for example, 01-JAN-1900) to a valid date as the TP Engine will reference any valid date.

· TP_EFFECTIVE_DATE <> ORIGINATION_DATE

· TP_EFFECTIVE_DATE <> LAST_REPRICE_DATE

Transfer Rate Margin (MARGIN_T_RATE)

MARGIN_T_RATE has been deprecated. The FTP rate is completely dictated by the method and IRC defined in the TP Rule. MARGIN_T_RATE on the instrument record is not used.

Transfer Rate (TRANSFER_RATE)

Definition

The associated transfer rate for the account, using the standard Transfer Pricing basis.

Module Usage

Oracle ALM

The TRANSFER_RATE from the detail record is used to calculate Cost/Credit for funds (financial element 450) and Weighted Average Transfer Rate (financial element 170) until the record's NEXT_REPRICE DATE. At the NEXT_REPRICE DATE, Oracle ALM refers to the Transfer Pricing rule attached to the ALM process and re-calculates the future TP rates based on the applicable TP Method and TP IRC.

Oracle Funds Transfer Pricing

After calculating a record's transfer rate using one of the transfer pricing methodologies and the standard pricing basis, the result is written out to the TRANSFER_ RATE field.

If TRANSFER RATES are to be loaded directly from an external source, data must be in % format (10% = 10, not 0.10).

Transfer Rate Alternate (TRANSFER_RATE_ALT)

Definition

The transfer rate alternate column is an optional output field used in FTP to hold the calculated Transfer Rate when an Alternate Rate Output Mapping rule is attached to the Standard TP Process.

Module Usage

Oracle Funds Transfer Pricing

In Oracle Funds Transfer Pricing, the default behavior is to output transfer pricing results to the standard seeded columns. If additional Transfer Rates are required, users can attach an Alternate Rate Output Mapping rule to the standard TP Process allowing them to choose an alternate column target for populating the TP Rate. TRANSFER_RATE_ALT is a seeded alternate column that can be selected in the Alternate Rate Output Mapping rule. Users can also add user-defined alternate output columns and additionally select these within Alternate Output Mapping rules.

Data Verification Requirements and Suggested Defaults

None

Transfer Rate Remaining Term (TRAN_RATE_REM_TERM)

Definition

The associated transfer rate for the account, using the remaining term pricing basis.

Module Usage

Oracle ALM

Oracle ALM does not use TRAN_RATE_REM_TERM.

Oracle Funds Transfer Pricing

After calculating a record's transfer rate using one of the transfer pricing methodologies and the remaining term pricing basis, the result is written out to the TRAN_ RATE_REM_TERM field.

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

Transfer Rate Remaining Term Alternate (TRAN_RATE_REM_TERM_ALT)

Definition

The transfer rate remaining term alternate column is an optional output field used in FTP to hold the calculated Remaining Term Transfer Rate when an Alternate Rate Output Mapping rule is attached to the Standard TP Process.

Module Usage

Oracle ALM

Oracle ALM does not use TRAN_RATE_REM_TERM_ALT.

Oracle Funds Transfer Pricing

In Oracle Funds Transfer Pricing, the default behavior is to output transfer pricing results to the standard seeded columns. If additional Transfer Rates are required, users can attach an Alternate Rate Output Mapping rule to the standard TP Process allowing them to choose an alternate column target for populating the TP Rate. TRAN_RATE_REM_TERM_ALT is a seeded alternate column that can be selected in the Alternate Rate Output Mapping rule. Users can also add user-defined alternate output columns and additionally select these within Alternate Output Mapping rules.

When the remaining term pricing basis is used, the transfer rate is written to the TRAN_RATE_REM_TERM field.

Data Verification Requirements and Suggested Defaults

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

Derivative Only Columns

Binary Rate (BINARY_RATE)

Definition

The Binary Rate input is used for modeling Binary interest rate caps and floors. For Binary Interest rate Cap, when the underlying rate goes above Rate_Cap_Life, Interest Cash flow is calculated using a given Binary Rate.

For Binary Interest rate Floor, when the underlying rate goes below Rate_Floor_Life, Interest Cash flow is calculated using a given Binary Rate.

No cash flows are exchanged if the underlying rate is below Rate_Cap_life for Binary Interest-rate cap. Similarly, no cash flows are exchanged if the underlying rate is above Rate_Floor_life for the Binary Interest rate floor.

Module Usage

Oracle ALM

In Oracle ALM, when modeling Interest Rate Caps or Floors, the binary rate is an optional input. If specified, the cash flow engine will treat Interest Rate Caps or Floors as Binary Interest rate Caps or Floors and will limit the maximum exposure on the floating leg of the contract by the given binary rate.

Data Verification Requirements and Suggested Defaults

If applicable, set binary rate > 0, otherwise set binary rate = NULL

Exchange of Principal flag (EXCHG_OF_PRINCIPAL)

Definition

The exchange of principal flag is used to indicate whether the Principal amount is exchanged as part of the on the contract. Derivatives contracts, where Principal is notional and not exchanged can be modeled with data of 0 in this column.

Module Usage

Oracle ALM

In Oracle ALM, the exchange of principal flag indicates whether or not principal flows will be exchanged in the life of the contract.

Exchange of Principal values:

0 = No Exchange of Principal. Principal Runoff related FEs, apart from IR Gap Principal FEs, will not get populated.

1= Exchange of Principal. Principal Runoff related FE s will get populated.

Data Verification Requirements and Suggested Defaults

For most derivative instruments, Exchange of Principal = 0 (default)

Leg Type (LEG_TYPE)

Definition

The Leg Type column is used for modeling derivative instruments and indicates if the record is a Payable Leg or a Receivable leg. Derivative instruments should be mapped to an Account Type attribute of the Off-Balance Sheet.

Module Usage

In Oracle ALM the values for LEG_TYPE are as follows:

0 – Indicates the instrument, not a derivative (appears in ALM result tables only)

1 – Indicates the instrument is the payable leg of a derivative contract.

2 – Indicates the instrument is the receivable leg of a derivative contract. So Interest Rate Swap receive leg will get populated with leg type of 2, and paying leg will get populated with leg type of 1.

Data Verification Requirements and Suggested Defaults

· For Derivative Instruments – Payable Leg, LEG_TYPE = 1

· For Derivative Instruments – Receivable Leg, LEG_TYPE = 2

Minimum Balance Amortizing Swap (MIN_BAL_AMORT)

Definition

The Minimum Balance Amortizing input indicates the minimum balance that a swap will amortize down to. Amortization will stop when it reaches this specified amount.

Module Usage

Oracle ALM

In Oracle ALM, the Minimum Balance Amortizing input applies to Amortizing Swaps and allows users to specify the minimum amortization balance. The cash flow engine will stop amortizing the contract when this amount is reached.

The account type must be set to Off-Balance Sheet for this field to become active.

Data Verification Requirements and Suggested Defaults

For Amortizing Swap with a minimum balance, MIN_BAL_AMORT > 0 otherwise default to 0.

Purchase Sale Logic (PURCHASE_SALE_LOGIC)

Definition

The Purchase Sale Logic column indicates whether the contract has been purchased or sold by the Bank.

Module Usage

Oracle ALM

In Oracle ALM, the following values should be used for PURCHASE_SALE_LOGIC.

1 – indicates the contract was sold (short).

2 – indicates the contract was purchased (long).

Data Verification Requirements and Suggested Defaults

· For Derivative Instruments which are purchased (long), PURCHASE_SALE_LOGIC = 2

· For Derivative Instruments which are sold (short), PURCHASE_SALE_LOGICE = 1

Swap Classification Code (SWAP_CLASS_CD)

Definition

The Swap Classification Code is used to identify the type of swap contract.

Module Usage

Oracle ALM, the Swap Classification code column is used to identify the type of swap contract.

Possible Values:

0 – Swap

1 – Swap with embedded option (reserved for future use)

2 – Swaption (reserved for future use)

Data Verification Requirements and Suggested Defaults

For swap contracts, SWAP_TYPE_CD = 0 (Default)