Transfer Pricing & ALM Validations

Validate Funds Transfer Pricing (FTP) Transfer Rates

How to Validate Funds Transfer Pricing (FTP) Transfer Rates (Doc ID 2010935.1)

GOAL

How can you validate or calculate Oracle Financial Services Funds Transfer Pricing (FTP) Transfer Rates?

SOLUTION

Below is a list of documents available to assist in calculating Transfer Rates output by FTP:

Straight Term

Document 239800.1 "How to Validate Transfer Rate for Straight Term TP Method"Document 123767.1 "Clarification of Straight Term Transfer Pricing Method"Document 1583836.1 "Example of How to Validate a Straight Term Transfer Rate Using the Mid Period Repricing Option"

Moving Averages

Document 100096.1 "How is the Moving Averages Transfer Pricing Method Calculated?"Document 1177584.1 "How to Calculate TP Moving Averages Method When Historical Rates Are Missing"

Caterpillar Method

Document 1329313.1 "How to Validate Caterpillar Method for FTP 5.2"

Cash Flow: Average Life

Document 1330066.1 "How to Validate FTP Average Life Calculations for "Cash Flow: Average Life"?"

Cash Flow: Weighted Term

Document 1266418.1 "What Type of Rate is Used for the Discount Rate in the FTP Cash Flow: Weighted Term Method?"

Cash Flow: Zero Discount Factors

Document 1322140.1 "Usage of "p" in Calculation of FTP Cash Flow: Zero Discount Factors (ZDF)"Document 1546502.1 "Are Conversions Done to the IRC Rates Used in Calculations for the TP Method 'Cash Flow: Zero Discount Factors'?"

Loan Commitments

Document 1605151.1 "How to Validate Forward Rates Output for FTP Process Run Against the Loan Commitments Table"

Hybrid Interest Rate Codes

Document 1499905.1 "Questions on How to Calculate the Moving Average Hybrid Curve Interest Rates"

Miscellaneous

Document 1380909.1 "How to Calculate FTP Market Value and Duration Values Output to FSI_O_PROCESS_CASH_FLOWS"Document 1944236.1 "OFSAA FTP Economic Loss - Breakage Charge Market Value Calculations"Document 277376.1 "How To Validate Prepayment Runoff Calculated In Risk Manager and Transfer Pricing"Document 1535267.1 "Fund Transfer Pricing (FTP) Computations For Amortizing Loans In OFSAA"Document 1943935.1 "What Are the Cubic Spline and Quartic Spline Interpolation Methods?"Document 1322118.1 "Definition of the "Computed Last Reprice Date" for Mid Period Repricing in FTP"

Straight TermClarification of Straight Term Transfer Pricing Method (Doc ID 123767.1)

GOAL

You would like clarification on how Oracle Transfer Pricing's (TP) or Funds Transfer Pricing's (FTP) straight term method calculates the transfer rate.

SOLUTION

The Straight Term transfer pricing method calculates the transfer rate in the following manner:

When setting up the straight term method in the Transfer Pricing ID or Transfer Pricing Rule, you first select your transfer pricing yield curve from the Interest Rate Code drop down list. 

The point on the curve determining the transfer rate is then found in the following manner:

Note: All referenced fields below refer to the field values on the instrument record in question.

Not Using Mid-Period Repricing:

1. Standard Pricing Basis

  a) Fixed Rate record: 

  Yield Curve Date = Origination Date   Yield Curve Term = Maturity Date - Origination Date 

  b) Adjustable Rate record (not in a Tease period): 

  Yield Curve Date = Last Reprice Date   Yield Curve Term = Repricing Frequency 

  c) Adjustable Rate record (in a Tease period): 

  Yield Curve Date = Origination Date   Yield Curve Term = Tease End Date - Origination Date 

2. Remaining Term Pricing Basis 

  a) Fixed Rate record: 

  Yield Curve Date = As of Date   Yield Curve Term = Maturity Date - As of Date 

  b) Adjustable Rate record: 

  Yield Curve Date = As of Date   Yield Curve Term = Next Reprice Date - As of Date

Using Mid-Period Repricing:

The Mid-Period repricing option only applies to adjustable rate, instrument level records.  It does not work with the Remaining Term Pricing Basis.  Also, you cannot use the Bulk processing option with Mid-Period Repricing.

You also must accurately populate two instrument table fields: CUR_TP_PER_ADB = Current Transfer Pricing Repricing Period Avg Daily Balance PRIOR_TP_PER_ADB = Prior Transfer Pricing Repricing Period Avg Daily Balance

There is a very detailed explanation of the mid-period repricing method beginning on page 3-19 of the 4.5 Transfer Pricing Reference Guide available in Document 69544.1 "Oracle Financial Services Applications (OFSA) 4.5 Product Documentation".  A similar section exists under "Transfer Pricing Methods and the Mid-Period Repricing Option" in the Oracle Financial Services Funds Transfer Pricing User Guide.

Important: You must use rate interpolation to determine the final Transfer Rate.  See an example in Document 239800.1 "How to Validate Transfer Rate for Straight Term TP Method".

How to Validate Transfer Rate for Straight Term TP Method (Doc ID 239800.1)

GOAL

How do you validate the Transfer Rate generated by the Straight Term Transfer Pricing (TP) Method?

SOLUTION

For the straight term method, Oracle Transfer Pricing (TP) and Funds Transfer Pricing (FTP) uses a term and date value to select a rate from the yield curve specified in the Transfer Pricing ID or Transfer Pricing Rule.  The term and date value used depends on the instrument record's repricing characteristics.  For detailed information on the term and date value selection, see Document 123767.1 "Clarification Of Straight Term Transfer Pricing Method".

To validate a straight term transfer rate, first collect the information the TP engine uses to determine which point on the Interest Rate Curve (IRC) to use.

1. Convert the IRC's term values from Months to Days where 1 month = 30.4166666 days.

For example, a 3M term is changed to:3*30.4166666 = 91.25 days

2. Calculate the cash flow term of the instrument record in days.  Again, the values used in this calculation depend on the record's repricing characteristics (see Document 123767.1).

For example, for a fixed rate record, TP uses the calculation of Maturity Date - Origination Date in days.  For an adjustable record, it converts the Repricing Frequency to days.

3. Determine which Date row on the IRC to use by determining the cash flow date.

For example, for a fixed rate record, TP uses Origination Date as the IRC date.For an adjustable record, TP uses Last Reprice Date.

After collecting the above information, TP finds the transfer rate on the IRC. 

Most often the date and term values on the instrument record and IRC do not match exactly.  To validate the TP cash flow engine process, do the following:

1. Determine IRC Date row to use

If no exact date match is found on the IRC, TP uses the first date prior to the instrument record's yield curve date.

For example, if the record's yield curve date is 01/15/2003 and the IRC has the following dates:

11/30/200212/31/200201/31/2003

TP uses the 12/31/2002 row on the IRC.

If the date for the lookup > dates available, TP uses the last date available.  If the date for the lookup < dates available, TP uses the first date available.

2. When term values do not exactly match, use rate interpolation to determine the Transfer Rate.  TP must use interpolation because the transfer rate on the curve falls between two term points.

For example:

Term on IRC is 3M -- converts into 91.25 daysTerm from fixed rate record:Maturity Date - Origination Date04/03/2003 - 01/03/2003 = 90 days

The rate falls between term point of 90 days and 91.25 days.  Use rate interpolation to determine the term point and the transfer rate.

Example of Rate Interpolation:

Example of IRC row:

Term 1M (30.4166666 days) 3M (91.25 days)12/31/2002 7.4175% 8.261%

Interpolation: y = mx + bx, y = the coordinates of a point on the linem = the slope of the line determined by two points: (x1, y1) and (x2, y2)b = the intercept of the line with the y axis

Values used in calculation:x1 = 30.4166666x2 = 91.25y1 = 7.4175y2 = 8.261

First, solve for "b"

b = y - mxb =7.4175-((8.261-7.4175)/(91.25-30.4166666))*30.4166666b = 6.99575

Then, use the b value to solve for "y" where x = the term of the instrument record (90 days)y = mx+by =((8.261-7.4175)/(91.25-30.4166666))*90+6.99575y = 8.2437

Transfer Rate = 8.2437

Example of How to Validate a Straight Term Transfer Rate Using the Mid Period Repricing Option (Doc ID 1583836.1)

GOAL

The following is an example of how to calculate the Transfer Rate when the "Mid Period" option is selected for the Straight Term Transfer Pricing method in Oracle Financial Services Funds Transfer Pricing (FTP).

Normally, FTP calculates the Straight Term Transfer Rate for an Adjustable Rate record by getting the rate from the Interest Rate curve associated with the "Last Reprice Date".  However, this method can mis-state the Transfer Rate in periods where rates change substantially.  If the "Mid Period" option is selected, FTP calculates a Transfer Rate for each Repricing Period that exists in the month for which the Transfer Rate is calculated and generates a weighted average to output to the TRANSFER_RATE column.

SOLUTION

The Mid Period Repricing Option is described in the Oracle Financial Services Funds Transfer Pricing (FTP) User Guide under the section "Transfer Pricing Methods and the Mid-Period Repricing Option".  Below is an example of how to calculate the Transfer Rate using this option.

In this example, an Adjustable Rate instrument record has the following characteristics:

AS_OF_DATE: 31-MAY-2013LAST_REPRICE_DATE: 31-MAY-2013NEXT_REPRICE_DATE: 30-JUN-2013PRIOR_TP_PER_ADB: 4,600,000CUR_TP_PER_ADB: 4,600,000

Interest Rate Curve:

Date 21 Days 1 Month5/1/2013 0.19092 0.207235/31/2013 0.18525 0.19647

Do the following to calculate the Transfer Rate:

1. Calculate the Transfer Rate for the "Current Period"

Get the Transfer Rate from the Interest Rate Code specified for the Straight Term method using the following IRC lookup details:

Term: NEXT_REPRICE_DATE - LAST_REPRICE_DATEDate: LAST_REPRICE_DATE

Term: 6/30/2103 - 5/31/2013 = 30 DaysDate: 5/31/2013

You must use Rate Interpolation to calculate the rate from the IRC as described in Document 239800.1 "How to Validate Transfer Rate for Straight Term TP Method".

Use y = mx + b.

First, calculate "b":

b =0.18525-((0.19647-0.18525)/(30.4166666-21))*21b = 0.160228407

The, use "b" to calculate "y":

y =((0.19647-0.18525)/(30.4166666-21))*30+0.160228407y = 0.19597354

Current Period Transfer Rate: 0.19597354

2. Calculate the Transfer Rate for the "Prior Period"

For the Prior Period, use the following for the Interest Rate Code lookup:

First, determine the "Prior Last Reprice Date" (Prior LRD) using the following calculation:

Prior LRD = LAST_REPRICE_DATE - "Repricing Frequency" where the "Repricing Frequency" is the number of days between NEXT_REPRICE_DATE and LAST_REPRICE_DATE.Prior LRD = 5/31/2013 - 30 Days + 1 Day = 5/1/2013

Get the Transfer Rate from the Interest Rate Code specified for the Straight Term method using the following IRC lookup details:

Term: LAST_REPRICE_DATE - Prior LRDDate: Prior LRD

Term: 5/31/2013 - 5/1/2013 = 30 DaysDate: 5/1/31

Again, you must use Rate Interpolation to calculate the rate from the IRC as described in Document 239800.1 "How to Validate Transfer Rate for Straight Term TP Method".

Use y = mx + b.

First, calculate "b":

b =0.19092-((0.20723-0.19092)/(30.4166666-21))*21b =0.154547256

Then, use "b" to calculate "y":

y =((0.20723-0.19092)/(30.4166666-21))*30+0.154547256y = 0.206508318

Prior Period Transfer Rate: 0.206508318

At this point, you have a Transfer Rate for the Current Period and for the Prior Period.

3. Determine the "Number of Days" to use for each Transfer Rate.

Calculation for Current Period: End of Month - (1 - LAST_REPRICE_DATE)

The Current Period Transfer Rate will be used for the following number of days:

Number of Days = 5/31/2013 - (1-5/31/2013) = 1 Day

The Current Period Transfer Rate is used for 1 Day.

Calculation for Prior Period: LAST_REPRICE_DATE - Beginning of Month

The Prior Period Transfer Rate will be used for the following number of days:

Number of Days = 5/31/2013 - 5/1/2013 = 30 Days

The Prior Period Transfer Rate is used for 30 Days.

4. Finally, use the information above to calculate the Mid-Period Transfer Rate.

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

Mid Period Transfer Rate = ((4,600,000 * 0.19597354 * 1) + (4,600,000 * 0.206508318 * 30)) / ((4,600,000 * 1) + (4,600,000 * 30))

Mid Period Transfer Rate = 0.206168

The Mid Period Transfer Rate is a weighted average of the Current Period and Prior Period Transfer Rates.

Moving Averages

How is the Moving Averages Transfer Pricing Method Calculated? (Doc ID 100096.1)

GOAL

You need to validate the results of your Oracle Transfer Pricing (TP) or Oracle Financial Services Funds Transfer Pricing (FTP) process run and you do not know how the cash flow engine calculates the transfer rate using the "Moving Averages" TP method type.

SOLUTION

The Moving Average TP method takes a straight average of the rates in the Historical Rates table defined by your "Yield Curve Term" and "Historical Term" in the Transfer Pricing ID.

Example:          Historical Rates Table            Bank A Yield Curve 

              1 D    1 M   *2 M*   6 M               ------------------------- 01/01/1999    8.0    8.3    8.4    8.3 02/01/1999    8.1    8.2   *8.5*   8.3 03/01/1999    8.1    8.1   *8.5*   8.1 04/01/1999    8.1    8.1   *8.3*   8.0 05/01/1999    8.4    8.0   *8.6*   7.9 06/01/1999    8.3    8.2    8.7    7.9 

Settings in the Transfer Pricing ID: 

Interest Rate Code = Bank A Yield Curve Yield Curve Term = 2 Months Historical Term = 4 Months (02/01/1999 - 05/31/1999)

As of Date = 5/31/1999

Note: The range of dates is based on the as of date minus the historical term plus one day.

To get the Moving Average, you need to average the rates in the table designated by the Transfer Pricing ID:

= (8.5 + 8.5 + 8.3 + 8.6) / (4)

Note: This is explained in the 4.5 Transfer Pricing Reference Guide on pages 16-4 thru 16-5 and in the Release 6 Funds Transfer Pricing (FTP) User Guide on pages 13-11 and 13-12 under "Moving Averages".

How to Calculate TP Moving Averages or Straight Term Method When Historical Rates Are Missing (Doc ID 1177584.1)

GOAL

In Oracle Financial Services Funds Transfer Pricing (FTP), how do you calculate the transfer rate for the Moving Average or Straight Term methods in the following cases:

Case #1: Rate is missing for a date/term pointCase #2: Complete date row is missing

SOLUTION

In general, the Moving Average TP method takes a straight average of the rates in the Historical Rates table defined by your "Yield Curve Term" and "Historical Term" in the Transfer Pricing Rule.

See Document 100096.1 "How Is the Moving Averages Transfer Pricing Method Calculated" for a detailed explanation.For Straight Term, see Document 239800.1 "How to Validate Transfer Rate for Straight Term TP Method".

Transfer Pricing Rule definition used in the examples below:

Yield Curve Term: 1YHistorical Term: 4 Days

Case #1: Null rate exists for a date/term point

Date 1Y30-Jun-2010 129-Jun-2010 10028-Jun-2010 null27-Jun-2010 -300

TP uses rate interpolation to calculate a rate for 28-Jun-2010.  TP takes the rates defined for the other term values for 28-Jun-2010 to interpolate a rate for the 1Y term:

Date 6M (182.5 Days)

1Y (360 Days) 2Y (730 Days)

28-Jun-2010 10 null 30

Rate interpolation:

b=y-mxb=10-((30-10)/(730-182.5))*182.5b=3.3333

y=mx+by=((30-10)/(730-182.5))*365+3.3333y=16.6666

Interpolated rate for 28-Jun-2010 1Y = 16.6666

So, TP calculates the moving average as follows:

=(1+100+16.6666+-300)/4=45.58

Note: If the term with the missing rate is the first term point or the last term point, TP uses the rate from the nearest term point.  For example, if a rate curve has term points of 1M, 2M, and 3M, and the rate is missing from the 1M point for a date, TP takes the rate from the 2M point instead.

TP uses the same method when getting the Straight Term transfer rate if rate values are missing.

Case #2: Missing date row

Date 1Y30-Jun-2010 129-Jun-2010 10028-Jun-2010 -3026-Jun-2010 10

In this case, there is no rate interpolation because no rates exist in the other Term columns.  The date row for 27-Jun-2010 is missing.  As a result, the calculation uses only 3 rows instead of 4.

= (1+100+-30)/3=23.66667

For the Straight Term method, if the date row is missing, TP uses the first date prior to the date.

Caterpillar Method

How to Validate Caterpillar Method for FTP 5.2 (Doc ID 1329313.1)

GOAL

How to validate the caterpillar method for Oracle Financial Services Funds Transfer Pricing (FTP) 5.2.

SOLUTION

The caterpillar strips are stored in FSI_TP_CATERPILLAR_INTRMDIATE.  The attached spreadsheet:  Perpetual Methods-Template.xls provided by development which shows the calculation logic.

To replicate the example, an FTP process should be run with Transfer Pricing Rule + Caterpillar Method + Behavior Pattern selection for three different As of Date.  in order to simplify things, month-end dates are recommend (i.e):

February 28, 2011

March 31, 2011

April 30, 2011

Once the process is complete, review the strip table to view the results, e.g. how the strips for each as-of-date are inserted and how FTP rates for each period are assigned and retained until maturity of the strip.

Cash Flow: Average LifeHow to Validate FTP Average Life Calculations for "Cash Flow: Average Life"? (Doc ID 1330066.1)

GOAL

How to calculate Average life for Oracle Financial Services Funds Transfer Pricing (FTP) Methodology "Cash Flow: Average Life"?

SOLUTION

The Average Life method determines the average life of the instrument by calculating the effective term required to repay back half of the principal or nominal amount of the instrument. The 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 as determined by the characteristics specified in the Instrument Table and using your specified prepayment rate, if applicable. The average life formula calculates a single term, that is, a point on the yield curve used to transfer price the instrument being analyzed.

Note: The Average Life TP Method provides the option to Output the result of the calculation to the instrument record (TP_AVERAGE_LIFE). This can be a useful option if you'd like to refer to the average life as a reference term within an Adjustment Rule.

Average life is calculated as follows:Sum Of CF = 0.Sum of product of CF and days = 0.

For each cash flow, if cash flow date > origination date

1. Compute CF = runoff amount2. CF = CF + reprice balance if it is a repricing cash flow3. If cash flow type selected is principal and interestCF = CF + interest amount4. Sum of CF = Sum of CF + CF5. Days = Cash flow date - origination date6. Sum of product of CF and days = Sum of product of CF and days + (CF * days)

Average life in days = Sum of product of CF and days / Sum Of CFAverage life in years = Average life in days / 365.25

for more information on FTP Average life please consult the Oracle® Financial Services Funds Transfer Pricing User Guide (Note: 1073394.1 - Oracle Financial Services Analytical Applications (OFSAA) Product Documentation).

Cash Flow: Weighted TermWhat Type of Rate is used for the Discount Rate in the FTP Cash Flow: Weighted Term Method? (Doc ID 1266418.1)

GOAL

For Oracle Financial Services Funds Transfer Pricing (FTP), what type of rate is used for the discount rate in the "Cash Flow: Weighted Term" method?  Can you use a user defined rate or yield curve rate?

FIX

For "Cash Flow: Weighted Term", the coupon rate or CUR_NET_RATE is used as the discount rate.  For this Transfer Pricing method, you cannot take the discount rate from a yield curve or use a user defined rate.  (Note: The option to select an IRC during the TP method setup relates to the TP Curve selection from which the TP Rate for each cash flow will be read.)

Originally, the decision was made to use the coupon rate as the discount rate back in the OFSA version 4.5 because using the coupon rate makes the calculation easier to understand for users receiving the TP Rate.  Using a single discount rate also improves performance.

Clarification of TP Method Weighted Average Cash Flow (WACF) Calculation (Doc ID 245311.1)

GOAL

 For Transfer Pricing (TP) 4.5, you want clarification on how to calculate Transfer Rates for the TP Method Weighted Average Cash Flow (WACF) Calculation (also known as Cash Flow Weighted Term).   You need more information on how the different components are determined.

SOLUTION

The calculation for the Weighted Average Cash Flow (WACF) Transfer Pricing (TP) method is located in two places within the 4.5 Transfer Pricing Reference Guide:

1. Pages 3-2 and 3-32. Pages 3-17 and 3-18 (where it is restated "in plain language")

Where does TP get the data used in the calculation?

TP gets data for this calculation from the Financial Element ID rows in the OFSA_PROCESS_CASH_FLOWS table.  To write rows to OFSA_PROCESS_CASH_FLOWS for a Process ID, select the "Detail Cash Flow" box on the "Process Mode" tab of the TP Process ID.

How does TP determine the yield curve point used in the Transfer Rate calculation?

TP determines the Transfer Rate using a rate lookup for each cash flow based on Model Start Date and Term to Cash Flow (from page 3-18).

Term to Cash Flow = Difference between the cash flow date and the transfer pricing date.

Transfer Pricing Date/Model Start Dates:

Adjustable = Last Reprice DateFixed = Origination DateRemaining Term Fixed = As of DateRemaining Term Adjustable = As of Date

(From the "Cash Flow Columns Used in Calculations" matrix beginning on page 3-15.)

What is the cash flow End Date?

Adjustable = Next Reprice DateFixed = Maturity Date

For additional assistance with understanding the TP calculation, review the extensive information available in Chapter 3: Transfer Pricing Methods of the 4.5 Transfer Pricing Reference Guide.

Cash Flow: Zero Discount FactorsUsage of "p" in Calculation of FTP Cash Flow: Zero Discount Factors (ZDF) (Doc ID 1322140.1)

GOAL

In Oracle Financial Services Funds Transfer Pricing (FTP), when calculating the Transfer Rate using "Cash Flow: Zero Discount Factors" (ZDF), should the formula in Chapter 11 of the FTP User Guide be multiplied by "p" or "1/p"?

See below:

SOLUTION

The formula should be multiplied by "p".  The calculation in the FTP Guide is wrong.

The following documentation bug exists for this issue:

Bug 12337306 - FTP USER GUIDE - CASH FLOW ZDF FORMULA IS STATED INCORRECTLY

Note: This documentation bug is fixed in the 5.2 and 6 Funds Transfer Pricing guides.

See the sample Zero Coupon Transfer Rate validation spreadsheet attached below:

Sample Zero Coupon Transfer Rate Validation.xls

This spreadsheet was created originally for the OFSA 4.5 TP but applies to FTP 5.2 also.

Are Conversions Done to the IRC Rates Used in Calculations for the TP Method 'Cash Flow: Zero Discount Factors'? (Doc ID 1546502.1)

GOAL

In Oracle Financial Services Funds Transfer Pricing (FTP), for the Interest Rate Codes defined in Rate Management, is a rate conversion done for the TP method "Cash Flow: Zero Discount Factors" if the Rate Format is "Yield to Maturity"?  Are the converted rates output to Financial Element (FE) 437?  Does FTP use the Compound Basis and Accrual Basis defined for the IRC when calculating the transfer rate?

SOLUTION

The Transfer Pricing method "Cash Flow: Zero Discount Factors" requires rates to have a rate format of "Zero Coupon Yield" and an Accrual Basis of "Actual/Actual".  If the "Attributes" defined in Rate Management for the Interest Rate Code (IRC) selected in the Transfer Pricing rule are different, the rates are converted to the required format.  Below is the explanation from Chapter 9 "Rate Conversion" in the Oracle Financial Services Cash Flow Engine Reference Guide:

Zero Discount Factors: The zero discount factor method must calculate discount factorsfor the transfer pricing yield curve. If the transfer pricing yield curve is stored asyield-to-maturity rates, the rates must first be translated into zero-coupon yields so thatthe discount factor can be calculated from them. If the transfer pricing yield curve isalready in zero-coupon yield format, then discount factors can be calculated directlyfrom the rates.

For Funds Transfer Pricing, the converted rates are output to FE 437.  These are the rates used in the transfer rate calculation.

Note: The rates output to FE 437 for fixed rate instruments currently are incorrect.  The rates are from the As of Date point on the IRC instead of the Origination Date.  See the following bug:

Bug 16219352 - FE 437 SHOWING RATE FROM WRONG REFERENCE DATE FOR FIXED RATE WITH ZCDF TP METHOD

The Compound Basis and Accrual Basis of the IRC are used to define the characteristics of the rates in the curve.  As described above, in certain cases, the rates are converted into a different format if required by the TP method.  Cases that require conversion are described in the "Rate

Conversion" Chapter of the Oracle Financial Services Cash Flow Engine Reference Guide.

Note: When calculating the ZCDF transfer rate, it does not take into the account the Compound Basis and Accrual Basis defined for the IRC.  This calculation uses the values from the instrument record.  The Compound Basis and Accrual Basis of the IRC is only used when checking to see if the rates need to be converted into a specific format.

Bug 16219352 : FE 437 SHOWING RATE FROM WRONG REFERENCE DATE FOR FIXED RATE WITH ZCDF TP METHOD

Hdr: 16219352 N/A ENG_GENCAL 5.6 ENG_OTHER PRODID-5659 PORTID-212 16553343Abstract: FE 437 SHOWING RATE FROM WRONG REFERENCE DATE FOR FIXED RATE WITH ZCDF TP METHOD *** 01/24/13 04:01 pm ***1) Problem Description---------------------- zero coupon rate from the IRC specified in the TP rule, it uses the AS_OF_DATE to locate the date on the curve.  The customer feels this is incorrect for Fixed Rate instrument records.  For Fixed Rate records, they feel it should be using the ORIGINATION_DATE instead of the AS_OF_DATE to get the rate from the rate curve. 2) Steps to Reproduce Problem----------------------------- 1. Identify a fixed rate instrument record with a 1 Month term for processing2. Create or identify an Interest Rate Curve that has dates for the Origination Date and As of Date for a 1 Month term.3. Create a Transfer Pricing Rule for the appropriate product using the Transfer Pricing Method = "Cash Flow: Zero Discount Factors". 3) Environment Information--------------------------Customer environment: OFSAA I 7.2.11 Hi Ara,  I'm not able to re-create this bug on the 6.0.3 PM Environment.  In my test I did the following: As of Date = 31-MAY-2011Origination Date = 30-APR-2011AMRT_TYPE_CD = 100ADJUSTABLE_TYPE_CD=0Reprice Freq = 0 MTP Effective Date is NULL I used IRC # 801 and input rates for both 30-APR and 31-MAY.  The April rates are approx. 20% and the May Rates are approx 1%.  When I run my Standard TP Process, the result is coming back as approx. 20%, which indicates to me that the effective for rate lookup is 30-APR, i.e. Origination Date and not As of Date. My test records are > 1M however. Is there anything special about the 1 month term in your example above or did you randomly select that instrument?*** 02/14/13 10:15 am ***I just ran 1 more test with a 1M term, fixed rate record and the TP Rate is consistent with Origination Date and not As of Date, so still not able to re-create the issue.*** 02/14/13 10:15 am *** (CHG: Sta->32)*** 02/14/13 10:40 am ***

Ara,  I think I see the confusion now.  In the detail cf output, we are writing 2 discount factor FE's: FE 490 (Discount Rate IS)FE 492 (Discount Factor) FE 437 (Interest CF T-Rate) seems to be showing the As of Date rate, rather than origination date rate In my test, I see the following for the above FE's FE 490 = 99.19378My historical rate for origination date = 10%, so the following formula confirms the calculated DF is based on 10%:=1/POWER((1+0.10),((31)/365)) = .9919378 Also, my TRANSFER_RATE result is approx. 10% FE 492 = .998736FE 437 = 1.255178 You can further closely tie out FE 492 as =1/POWER((1+0.01255178),((31)/365)) = .9989 I'm not sure what is causing the minor difference in the FE 492 calc, but from this is clear that FE 490 is being used to generate the Transfer Rate result. The takeaway is that we need to correct the FE outputs to make validation easier, but the underlying calculation for the TP Rate seems to be ok. Comments from mail thread: From Leena:This has been in place since 5.1 and is not related to EL calculation change. I tried to identify the reason/use case for this change, but couldn’t find any. I believe this is not intentional and hence can be reverted to the original design. From Chris:Hi Leena, Following up on this thread.  Can you comment on why we are now writing an as-of-date based rate to FE 437 instead of the origination date rate?  Is this related to a change made for the Economic Loss calculation?  I have noted the general need to add clarity with regard to specific calculations in the Audit output in the below mentioned bug which we can take as part of 6.2, but I also want to understand if the change in output to FE 437 is intentional with a specific use case in mind and also understand if we should instead revert to the original design which was to populate FE 437 with the Origination Date based TP rate. *** 03/04/13 08:12 am ***Based on above clarifications, we should fix this specific case as part of this bug #.

Loan Commitments

GOAL

For Oracle Financial Services Funds Transfer Pricing (FTP) 6.1, when you run a Cash Flow FTP Process against the Loan Commitments (FDI_D_LOAN_COMMITMENTS) table with the "Forward Transfer Rate" option selected, how are the forward rates output to FSI_O_FTP_IMP_FWD_RATES_AUDIT generated?  What are the steps to calculate or validate the forward rates?

SOLUTION

The forward rate calculation is available in the Oracle Financial Services Cash Flow Engine Reference Guide in Chapter 8 "Transfer Pricing Option Costs".  See the section "Calculate Forward Rates".  This section contains the formula used to calculate the forward rates.

This Reference Guide is available in the Documentation Library for Oracle's Enterprise Performance Management (6.x) and Data Foundation (7.3/7.4.0.0.0).

Development provided a spreadsheet that shows a method to confirm the forward rates are correct.

Download the spreadsheet here: Example_of_FWD_Rate_Validaton.xls

Below is the sample test case development used in the spreadsheet:

1. Create a record in FSI_D_LOAN_COMMITMENTS with the following characteristics:

COMMIT_TERM = 1MAS_OF_DATE = 31-OCT-2013COMMIT_START_DATE = 15-OCT-2013COMMIT_MAT_DATE = 15-NOV-2013ORIGINATION_DATE = 15-NOV-2013MATURITY_DATE = 15-NOV-2014ADJUSTABLE_TYPE_CD = 0

2. Create an Interest Rate Code with term points 1M, 2M, 3M, 4M, etc. to 12M3. Input historical rates for 15-OCT-20134. Setup Transfer Pricing Rule to transfer price the above instrument using a cash flow TP method, e.g. Cash Flow Duration5. Setup an FTP Process, select the Loan Commitments table and select Transfer Rate and Forward Rates in Calculation Selection.

6. Select Audit options to output detail cash flows for the above instrument and output forward rates.7. Run the FTP process8. Query the forward rates from the audit table,

select * from fsi_o_ftp_imp_fwd_rates_audit where process_id= <insert FTP Process  Syd ID>;

Note: Data is only inserted into FSI_O_FTP_IMP_FWD_RATES_AUDIT if you use a "Cash Flow" Transfer Pricing Method and you select the Audit option for rates.

FTP should output the forward rates for each forward start date (in the sample test case, 1 record = 1 forward start date).  In the sample above, the forward rates would be calculated using the 15-OCT-2013 spot curve (equal to Commit Start Date) and would be 1M forward from that date (e.g. they would be applicable to the Origination Date of 15-NOV-2013).  This approach can be modified for different commit terms and variations of dates as needed.

Hybrid Interest Rate CodesQuestions on How to Calculate the Moving Average Hybrid Curve Interest Rates (Doc ID 1499905.1)

GOAL

Moving Average Hybrid Curves are created in Master Maintenance > Rate Management > Interest Rates by selecting Structure Type = Hybrid and Hybrid Curve Type = Moving Average. 

Q1. If you use a "Moving Average Term" of 1 Month, does Rate Management convert it to the equivalent days and look back by that term? Does it understand that some months have 30 days and some 31 days?  What about for years?

Q2. If you use a "Moving Average Term" of 10 days but only have 5 days of rates data, when calculating the moving average, will the denominator be 10 or 5?

Q3. Does the Moving Average Hybrid Curve calculation reference the Holiday Calendar?

Q4. Provide an example of the Moving Average Hybrid Curve calculation. 

SOLUTION

A1:  The Moving Average Hybrid Curve calculation uses the ADD_MONTHS SQL function to determine the period for calculating the Moving Average.

For example, if the Moving Avg Term is 1 Month, the following is used to determine the first Effective Date to use for the calculation:

(SELECT add_months(to_date('02/29/2012','mm/dd/yyyy'),-1) Effective FROM dual) + 1 day

The same function is used for the Year Term.

A2: If only 5 date rows exist over the 10 Day term, the denominator will be 5.  If a denominator of 10 was used, the resulting rate would be much lower than the existing rates.

A3:  No.  The calculations do not reference the Holiday Calendar.

Important: Please be aware of the issue described in Document 1430948.1 "Incorrectly Generated Rates from Hybrid Moving Average Rate Generation".

A4: Example:

Moving Average Term: 31 Days

in the benchmark curve you select for the Hybrid Curve, you have rates defined for an "Effective Date" = 31-JUL-2013 and you want to generate a 31 Day Moving Average Rates for this date on the Hybrid Curve.

To calculate the 31 Day Moving Average:

Step 1: Determine the date range for calculating the Moving Average

Start Date = (Effective Date - 31 Days) + 1 DayStart Date = (31-JUL-2013 - 31) + 1 = 01-JUL-2013

End Date = Effective DateEnd Date = 31-JUL-2013

So, the Moving Average is calculated using rates from 01-JUL-2013 to 31-JUL-2013.

Step 2: Do the Moving Average Calculation

For example, in the benchmark curve, there are 3 Effective Dates in the IRC between 01-JUL-2013 to 31-JUL-2013 for the 1 Day Term point:

Effective Date 1 Day Term

01-JUL-2013 0.01

15-JUL-2013 1

31-JUL-2013 1.01

The Moving Average Hybrid Rate for 1D is calculated as follows:

(0.01 + 1 + 1.01) / 3 = 0.673333

When you check the rates on the Hybrid Curve, there will be a row with:

Term 1D:

31-JUL-2013 - Rate = 0.673333

The same process is used to calculate rates for the other Term points.

Note: The Hybrid Moving Average curve will be identical to the benchmark curve if rates do not exist for multiple Effective Date values over the period selected.

Incorrectly Generated Rates from Hybrid Moving Average Rate Generation (Doc ID 1430948.1)

SYMPTOMS

On Oracle Financial Services Analytical Applications (OFSAA) 5.6 Rate Management -> Interest Rates when generating moving average hybrid rates, the correct rates do not appear to be calculated.

ACTUAL BEHAVIOR Incorrect 1 month average term, monthly rates are calculated.

EXPECTED BEHAVIORExpect the correct monthly average rates to be generated.

The issue can be reproduced at will with the following steps:1. Create a standard curve and uploaded rates for all business days in Sep 20112. Create a hybrid curve which is the 1 month moving average of the stated standard curve.3. Click apply and generate to generate hybrid rates==> Generated rates do not appear to be correct.

CAUSE

Issue is caused by a missing rates populated in the FSI_IRC_RATE_HIST for the base IRC curve.

An ER is under consideration for a future release:

- Rather than calculating a missing rate by taking a prior term and later term for the same date, OFSAA should instead refer to same term for prior effective date to get the rate.

This is explained in the following enhancement request:Bug :13733810 - incorrect generated rates from hybrid curve of 1 month moving average.

SOLUTION

Rates are being generated as designed. Be sure to populate rates for all expected term points and effective dates.

The following is the calculation logic for moving average rates in the case if rates are not available:

1) If rates are not available for the specific day then OFSAA gets the rate by taking the previous and next day rates average of the three and add it by previous days rate and finally calculates the average.

2. If rates are not available for consecutive days then OFSAA gets the rate from the previous dates depending on the number of days rates not available and finally calculates the average.

Rates are never "inserted" . The above behavior is relevant only when the effective date is input, and one or more term points have null values. OFSAA does not fill in data for dates where there would be no rates, e.g. weekends and holidays. Therefore, if rates for all tenors and any given effective date are properly input, OFSAA simply takes the average of the rates given.

As an example, if 30 days is input as the moving average period and if there are only two rates input for those 30 days, the following logic is used to generate the moving average rate:

First Date = Target Date – 30 + 1If there are two inputs in the 30 days then it would average 2 rates.

The logic used for days is:

Start Date = Effective Date - Moving Average Term + 1End Date = Effective Date

-----------------------------------------------------------------------------------------------------------------------------------------If an effective date does not have an IRC, no Moving Average Hybrid curve would be generated for that day.So, for a 3 day moving average term:22 – 3 days + 1 = 20/11/2009

Effective Date = End Date = 22/11/2009 - 6%21/11/2009 -Start Date = 20/11/2009 - 5%The three day moving Average = (6% + 5%)/2-----------------------------------------------------------------------------------------------------------An ER is under consideration for a future release:

Rather than calculating a missing rate by taking a prior term and later term for the same date, OFSAA should instead refer to same term for prior effective date to get the rate.

Miscellaneous

How to Calculate FTP Market Value and Duration Values Output to FSI_O_PROCESS_CASH_FLOWS (Doc ID 1380909.1)

GOAL

In Oracle Financial Services Funds Transfer Pricing (FTP), how do you calculate the Market Value (FE 710) and Duration (FE 720) amounts output for FSI_O_PROCESS_CASH_FLOWS when you run an FTP process with a Cash Flow method and the Detailed Cash Flow Audit Option selected?

SOLUTION

Use the following to validate the Market Value for one Cash Flow Date:

Market Value = Cash Flow Amt / (1 + Cur Rate)^ t

"Cur Rate" is from the instrument record."t" changes for each Cash Flow Date to take into account the number of days between the Cash Flow Date and the As of Date.

See two examples below for an As of Date = 9/30/2010 with Cur_Net_Rate = 4.25:

Cash Flow Date = 10/31/2010:

=(FE 190 + FE 430)/((1+0.0425)^(31/365))=(373.000274+90.239726)/((1+0.0425)^(31/365))Market Value = 461.6053415

Cash Flow Date = 11/30/2010:

=(377.214179+86.025821)/((1+0.0425)^((31+30)/365))Market Value = 460.0289063

Use the following to validate the Duration for one Cash Flow Date:

Duration = (Market Value*t)/Sum of all Market Value results

Cash Flow Date = 10/31/2010:

= (FE 710 * t)/Sum of all Market Value results= (461.605341 * (31/365))/25051.40067Duration = 0.001564976

Cash Flow Date = 11/30/2010:

= (460.028906 * ((31+30)/365))/25051.40067Duration = 0.003068952

Important: If using the "Cash Flow: Duration" Transfer Pricing method, you must select the "Single Rate" option in the Transfer Pricing rule to use the calculations above.  If you select the "Multiple Rate" option, Cur_Net_Rate is not used in the Market Value calculation.  Instead, the rate is taken from the Interest Rate Code selected in the TP rule and you must use rate interpolation to determine the rate used by FTP.

OFSAA FTP Economic Loss - Breakage Charge Market Value Calculations (Doc ID 1944236.1)

GOAL

In the example on page 13-52 of the Oracle Financial Services Funds Transfer Pricing (FTP) User Guide regarding the calculation of economic loss on breakage charges, where does the Market Value (MV) # come from? Is there a spreadsheet example of the calculation of that MV? Does that Market Value get output?

SOLUTION

Market Value in the example in the User Guide is the Net Present Value of the cash flows shown below discounted using the current market rate. Attached is an Excel example that goes along with the cash flows shown in the User Guide at 13-52.

When the Economic Loss Breakage Charge runs (via TP Adjustment Rule, against instruments in FSI_D_BREAK_FUNDING_CHARGES), the following outputs are written:

BREAK_FUNDING_MV = Net Present Value of remaining term cash flows with the interest cash flow based on the specified rate, e.g. typically TRANSFER_RATEBREAK_FUNDING_AMT = (order depends on asset or liability), CUR_BOOK_BAL – BREAK_FUNDING_MVBREAK_FUNDING_AMT_CHG = (order depends on asset or liability), Current BREAK_FUNDING_AMT - Prior Record BREAK_FUNDING_AMT. This is only relevant for partial breaks and changes in attributes. For full breaks, there is typically only 1 data record, so the BREAK_FUNDING_AMT_CHG = BREAK_FUNDING_AMT

How to Validate Prepayment Runoff Calculated in ALM / RM and TP / FTP (Doc ID 277376.1)

GOAL

You are looking to validate your prepayment runoff, FE 180, generated by your Prepayment ID / Prepayments Rule in either Oracle Risk Manager (RM), Oracle Transfer Pricing (TP). Oracle Financial Services Asset Liability Management (ALM), or Oracle Financial Services Funds Transfer Pricing (FTP). How does OFSA/OFSAA calculate prepayment?

SOLUTION

From the Oracle Financial Services Technical Reference Manual, Release 4.5, Chapter 9 Cash Flow Calculations, Cash Flow Calculation Process, Prepayment Event Steps (example follows at the end).  The same calculations can be found for OFSAA in the Oracle Financial Services Cash Flow Engine Reference Guide, Release 5 or 6.

1.Determine Base Annual Prepayment Rate.

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

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

Base Annual PP Rate = Constant Rate

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

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

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

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

Range LookupRange Lookups treats the nodes within the dimension as a starting value for a range that extends to the next node dimension. For example, take an original term dimension with node values of 0,12, and 24. The range lookup treats these values as three sets of ranges: 0 to 11, 12 to 23, and >= 24.

Interpolation LookupIf the interpolation method is selected, the lookup applies straight line interpolation to determine the proper prepayment rate for values that fall between nodes.

Lookups Outside the Given RangeFor both lookup methods, lookup for values less than the lowest node value receives the prepayment rate associated with the lowest node. Values greater than the highest node receive the prepayment rate associated with the highest node.

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

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

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

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

3. Check Prepayment in Full Option.If the adjusted final prepayment rate is equal to 100%, the instrument is paid off in full.

4. De-annualize the Prepayment Option.The annual prepayment rate is adjusted to a rate per payment. The formula

is as follows:

Prepayment Factor = (1-(1- Annual PPRate)^(1/payments per year)

5. Adjust Prepayment Rate for Stub or Extended Payments.The prepayment rate per payment is adjusted if the payment is a stub or extended payment. This adjustment is made in the same manner that interest cash flows are adjusted, as follows:

Adjusted prepayment factor = Prepayment Factor * (next payment date -last payment date) / (payment frequency in days)

6. Determine prepayment amount.The amount of runoff due to prepayments is calculated. The prepayment factor is applied to the current balance.

Prepayment Runoff = Current Balance * prepayment factor

7. Update current balance.The current balance must be reduced by the amount of prepayment runoff.

Current Balance = Current Balance - Prepayment runoff

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

Current Payment = Current Payment * (1 - prepayment factor)

If the payment treatment is "Curtailment", the current payment remains constant, effectively reducing the term of the instrument.

Therefore, based on a simple example (again please note, the calculation is dependent upon your instrument records as in Step 5 above), your validation will be something like:

1.Determine Base Annual Prepayment Rate.Base Annual PP Rate = Constant Rate

==>From the Prepayment ID: 18.89% for all Origination Dates

2. Adjust for Seasonality.Annual PP Rate = Seasonality Factor(Current Month) * Base Annual PP Rate

==>Assuming no seasonality: Annual PP Rate 18.89%

3. Check Prepayment in Full Option.If the adjusted final prepayment rate is equal to 100%, the instrument is paid off in full.

==>Annual PP Rate <> 100%

4. De-annualize the Prepayment Option.The annual prepayment rate is adjusted to a rate per payment. The formula is as follows:Prepayment Factor = (1-(1- Annual PPRate)^(1/payments per year)

==>Assuming 1 month payment frequency: Prepayment Factor = (1-(1-(18.89/100))^(1/12))=0.017296

5. Adjust Prepayment Rate for Stub or Extended Payments.Adjusted prepayment factor = Prepayment Factor * (next payment date -last payment date) / (payment frequency in days)

==> Assuming no stub or extended payments.

An example of an extended payment adjustment would be:

last payment date = 17-APR-2013next payment date = 01-AUG-2013payment frequency = 3M

Difference between last payment date and next payment date = 106 days.

Payment frequency in days = next payment date - payment frequency  = 01/AUG/2013 - 3M = 01/AUG/2013  -   01/MAY/2013  = 92

Adjusted prepayment factor = 0.017296 * 106/92 = 0.019928

6. Determine prepayment amount.Prepayment Runoff = Current Balance * prepayment factor

==> Current Balance is actually adjusted by the Payment Runoff i.e, FE 60 - FE 190 as the Prepayment Event happens after the Payment Event. Assuming Cur_Par_Bal = 100,000 and Payment Runoff for the month = 1000 then:Prepayment Runoff = 90,000*0.017296= 1556.64

Please reference the attached spreadsheet,  prepayment_validation.xls   for a validation example using a Prepayment Table with a fixed rate instrument.

Note: Prepayment output is calculated on Payment date, and is summed up in each time bucket, if there are multiple prepayment events in that bucket.  If Prepayment Cash Flow Treatment = Refinance, Cur payment gets updated with formula Current Payment = Current Payment * (1 - prepayment factor).  An example of prepayment validation with multiple prepayment events can be found in the  Loan_Prepay_Validation_dev.xlsx .

Bug 23514454 : CANNOT VALIDATE PREPAYMENT AFTER BUCKET_001 FOR CONSTANT PREPAYMENT

Hdr: 23514454 N/A CALCENG 8.0.1 PRODID-5662 PORTID-226Abstract: CANNOT VALIDATE PREPAYMENT AFTER BUCKET_001 FOR CONSTANT PREPAYMENT *** 06/01/16 02:47 pm ***Currently trying to validate ALM constant prepayment output using the following from DOC ID 277376.1: De-annualize the Prepayment Option.The annual prepayment rate is adjusted to a rate per payment. The formula is as follows:Prepayment Factor = (1-(1- Annual PPRate)^(1/payments per year) Adjust Prepayment Rate for Stub or Extended Payments.The prepayment rate per payment is adjusted if the payment is a stub or extended payment. This adjustment is made in the same manner that interest cash flows are adjusted, as follows: Adjusted prepayment factor = Prepayment Factor * (next payment date -last payment date) / (payment frequency in days) The first bucket appears to match expected results however not able to validate the following buckets.  Please advice. 2) Steps to Reproduce Problem-----------------------------Run ALM process with constant prepayment.Attempt to reconcile prepayment results. 3) Environment Information--------------------------ALM 8.0.1 4) Workaround-------------NA *** 06/01/16 02:48 pm *** *** 06/01/16 02:51 pm ****** 06/01/16 02:52 pm ****** 06/01/16 02:47 pm ****** 06/02/16 12:01 am *** (CHG: Sta->30 Asg->COKI)*** 06/02/16 12:01 am ****** 06/08/16 08:32 pm *** (CHG: Sta->92 Asg->BIPKUNDU)*** 06/08/16 08:32 pm ***

Fund Transfer Pricing (FTP) Computations For Amortizing Loans In OFSAA (Doc ID 1535267.1)

GOAL

Can OFSAA FTP compute transfer rates for the following products given the benchmark rate/curve and adjustment logic are given:

1. Amortizing loans with fixed interest rate during the tenor2. Amortizing loans with floating interest rate during the tenor

FIX

1. Yes, FTP supports amortizing loans with fixed interest rate during the tenor. Typically Cash Flow TP Methods are applied to Fixed Rate Amortizing instruments. Cash Flow Zero Discount Factor or Cash Flow Duration are most common.  It is also common to see prepayment assumptions applied to these products.  In the case of a fixed rate instrument, the reference date for TP Rate lookup is the Origination Date of the contract.  Cash flows are generated for the contract from Origination Date to Maturity Date and are applied to the selected TP Methodology to arrive at an appropriate cost of funds.

2. Yes, FTP supports amortizing loans with floating interest rate during the tenor. For adjustable rate / floating rate instruments, the reference date for TP Rate lookup is the last reprice date. Depending on the repricing frequency, users typically choose either cash flow TP methods (for longer term repricing periods) or simpler non-cash flow methods such as straight term or even one of the pool funding methods, depending on the underlying index.  If a cash flow method is selected, then cash flows are generated from last reprice date to next reprice date.

What Are the Cubic Spline and Quartic Spline Interpolation Methods? (Doc ID 1943935.1)

GOAL

For Oracle Financial Services Funds Transfer Pricing (FTP) 6.1, can you provide more information on the new interpolation methods available in the "Calculation Selection" screen of an FTP Process:

Cubic SplineQuartic Spline

SOLUTION

Both Cubic Spline and Quartic Spline are used in the same context as the Linear method for interpolating between two points when doing rate lookups.  These new options add curvature to the interpolated points in contrast to the linear interpolation method.  Cubic spline is the first step to adding this curvature and Quartic spline is a step further.  Both concepts are very much dependent on the underlying mathematical concept of polynomials but the business application is essentially the same as the linear method.

There is additional information on the Cubic Spline interpolation in the Oracle Financial Services Cash Flow Engine Reference Guide, Release 6.  See Chapter 11 "Monte Carlo Analytics" in the section "Choosing a Smoothing Method".

Detailed information on both the Cubic Spline and Quartic Spline interpolation methods can be found on the internet.

Definition of the "Computed Last Reprice Date" for Mid Period Repricing in FTP (Doc ID 1322118.1)

GOAL

In the Oracle Financial Services Funds Transfer Pricing (FTP) User Guide, in Chapter 11 "The Oracle Funds Transfer Pricing Process", under "Transfer Pricing Methods and the Mid-Period Repricing Option", the guide repeatedly refers to the "Computed Last Reprice Date". What is the definition of the "Computed Last Reprice Date"?

SOLUTION

According to development, the user guide is using the term "Computed" generically to refer to either the values within NEXT_REPRICE_DATE and LAST_REPRICE_DATE or the computed values, depending on the specific step within the calculation.  

In the example on page 11-18, the diagram illustrates there are two repricing events to be considered.  One calculation is the current period, where the NEXT_REPRICE_DATE - LAST_REPRICE_DATE (actual values) are both used.  When calculating the prior period rate, the LAST_REPRICE_DATE becomes the "computed" next reprice date and an additional "prior" reprice date is computed to determine the relevant term for the first repricing event.  The prior reprice date is the LAST_REPRICE_DATE - REPRICE_FREQ.

So, in one part of the diagram, the LAST_REPRICE_DATE is considered the "computed last reprice date" and the NEXT_REPRICE_DATE is considered the "computed next reprice date".  In the other part of the diagram, the LAST_REPRICE_DATE becomes the "computed next reprice date" and a new date "prior reprice date" becomes the "computed last reprice date".

Validate Asset Liability Management (ALM) Financial Elements and Results

How to Validate Asset Liability Management (ALM) Financial Elements and Results (Doc ID 1919870.1)

GOAL

How can you validate or calculate Oracle Financial Services Asset Liability Management (ALM) Financial Elements and other results?

SOLUTION

You can find an explanation of how ALM performs cash flow calculations in the Oracle Financial Services Cash Flow Engine Reference Guide.  Go to Chapter 17 "Financial Elements.  Then, go to "Financial Elements Listed by Number".  See the column "Formula / Detailed Description".  You can also review Chapter 5 "Cash Flow Calculations" in combination with Chapter 6 "Cash Flow Dictionary".  This document is available on the following web site:

http://docs.oracle.com/cd/E28033_01/homepage.htm

Oracle Financial Services Cash Flow Engine Reference Guide

Result Detail Table

Document 223205.1 "How to Validate Interest Cash Flow (FE 430) for ALM and RM"Document 223206.1 "How to Validate Interest Accrual (FE 440) for RM and ALM"Document 1310533.1 "How to Calculate Average Balance (FE 140) for ALM"Document 1626997.1 "How to Calculate Average Net Rate (FE 160) for ALM"Document 420636.1 "Incorrect Deferred Runoff FE540 Results"Document 1572395.1 "How to Calculate WARM (FE 500) for ALM"Document 277376.1 "How To Validate Prepayment Runoff Calculated In Risk Manager and Transfer Pricing"Document 280005.1 "How to Calculate Prepayment Runoff (FE 180) in RM or ALM"Document 95753.1 "Cannot Validate Cash Flow Results With Semi-Annual Rates" Document 177650.1 "How Does Risk Manager Generate FE 212 - Negative Runoff" 

Document 158942.1 "How is Transfer Rate Calculated in RM for both Actual and New Business" 

Document 156717.1 "Which Instrument Column Is Used for Starting Balance in RM"Document 1540092.1 "How Does ALM Calculate a Currency Conversion After an Exchange Rate Shock?"Document 1318314.1 "How to Validate New Business Avg Balance with Target Growth and Distributed Option"

Stochastic

Document 1475286.1 "How to Validate ALM Stochastic Earnings At Risk (EAR)"

Gap

Document 244125.1 "How to Understand Gap Results in the RES_DTL_xxxxx Table"

Market Value

Document 1382119.1 "How to Calculate Market Value for ALM 5.x/6.x"

Note: "Risk Manager" is the name of the previous version of Asset Liability Management.  They both use the same cash flow engine.

How to Validate Interest Cash Flow (FE 430) for ALM and RM (Doc ID 223205.1)

GOAL

How does Oracle Risk Manager (RM) and Oracle Financial Services Asset Liability Management (ALM) calculate Interest Cast Flow (FE 430)?How can you validate Interest Cast Flow (FE 430) for Risk Manager or Asset Liability Management?

SOLUTION

Several different calculations exist for validating interest cash flow (financial element 430) in Oracle Risk Manager or Asset Liability Management.  The calculation to use depends on three pieces of information:

1. "Compounding Method" within the RM Configuration ID or "Pay Equivalent Compounding Convention" within the ALM Product Characteristics

2. Value in COMPOUND_BASIS_CD column on instrument record3. Value in ACCRUAL_BASIS_CD column on instrument record

Product Characteristics Compounding Method

If "Semi-Annual" is selected for compounding in the active RM Configuration ID or ALM Product Characteristics, rates are quoted in the database as semi-annual.  You must convert these rates to an annual rate before proceeding with interest cash flow validation.

Spreadsheet: interest cash flow (financial element 430) validation.

For example:

Cur Net Rate: 16.99 Payment Freq: 1M 

Annual Rate = ((1 + rate/2)^(payment freq/12 * 2) - 1) * (12/payment freq) = ((1+0.1699/2)^(1/12*2)-1)*(12/1) = 0.164180805

Use the annual rate of 16.418 in the interest cash flow calculations.

If "Annual" is the compounding method in the RM Configuration ID or "Do Not Adjust" is the Pay Equivalent Compounding Convention in ALM, use the rate stored on the instrument record.

Basic Interest Cash Flow Calculation

Interest Cash Flow = Current Balance * Rate Per Payment

In the "Rate Per Payment" calculation, use the ACCRUAL_BASIS_CD to adjust the annual current rate to reflect what the rate will be for one payment period.

The COMPOUND_BASIS_CD is critical to consider when calculating the "Rate Per Payment" component of the interest cash flow.  Page 9-23 of the 4.5 OFSA Technical Reference Manual (TRM) contains a table that details the calculation adjustment made for various compounding codes.  The same information is also located in the Oracle Financial Services Cash Flow Engine Reference Guide, Release 5, in the "Cash Flow Calculations" Chapter, in the section "Payment Event Steps".

Below are examples of Rate Per Payment calculations for records with two different accrual factors - simple and daily.

Rate Per Payment = (Current Rate*(Days in Pmt Freq/Days in Year)

Example:

As of Date: 01/31/2000 Cur Net Rate: 16.99 Cur Net Par Bal: 3422.31 Next Pmt Date: 02/24/2000 Pmt Freq: 3M

Rate Per Payment -- Simple Compound Basis Code & Actual/Actual accrual

= 0.1699*((30+31+31)/366) = 0.042707104 = 4.27%

Rate Per Payment -- Simple Compound Basis Code & 30/360 accrual

= 0.1699*((30*3)/360) = 0.042475 = 4.25%

Rate Per Payment -- Daily Compound Basis Code & Actual/Actual accrual

Rate per Payment = (1+Cur Net Rt/Days in Year)^(Days in Pmt Freq)-1 = (1+0.1699/366)^(30+31+31)-1 

= 0.043621832 = 4.36%

For the additional Compound Basis Code formulas, see the 4.5 TRM or the Oracle Financial Services Cash Flow Engine Reference Guide, Release 5.

After calculating the Rate Per Payment, calculating the Interest Cash Flow is simple:

Interest Cash Flow = Current Balance * Rate Per Payment

For the simple Compound Basis Code & Actual/Actual accrual example:

= 3422.31 * 0.042707104

Interest Cash Flow = 146.1569491

Interest Cash Flow Calculation with Monthly Compound Basis & Stub / Extended Pmt Adjustment

Example:

Cur Par Bal: 8862841.00Cur Net Rate: 16.25Pmt Freq: 3MLast Payment Date: 12/24/2013Next Payment Date: 03/01/2014Next Payment Date - Last Payment Date = 67Compound Basis Cd: MonthlyAccrual Basis: Actual/Actual

Rate Per Payment:

=0.1625*(90/365)=0.040068493

Monthly Compound Basis Adjustment:

From CFE Guide: (1+ rate per pmt/cmp pds per pmt)^(cmp pds per pmt) - 1

=(1+0.040068493/3)^3-1=0.040606037

Balance * Adjusted Rate Per Payment:

=8862841*0.040606037=359884.8496

Stub / Extended Payment Adjustment:

You must make this adjustment when PMT_FREQ <> # of Days between NEXT_PAYMENT_DATE - LAST_PAYMENT_DATE.  In this example, the PMT_FREQ is 3M or 90 Days and there are 67 Days between Last Payment Date and Next Payment Date.  

=359884.8496*(67/90)= 267914.2769

FE 430 Interest Cash Flow = 267914.28

Note: The adjustment for stub / extended payment is required even if the payment period is off by one day.  For example, if LAST PAYMENT DATE= 11/10/2015 and NEXT PAYMENT DATE =5/11/2016. A single day more day of interest (11/10/2015) is considered by ALM. If LAST PAYMENT DATE was = 11/11/2015, then we would get interest for 6 months only (no extra or less days).

Note on INT_TYPE

For "Interest in Arrears", interest is paid at the end of the payment period and is calculated using the previous period's Ending Balance (or the Cur_Par_Bal from the instrument record for Bucket_001).  The Payment Frequency is calculated by taking Next Payment Date - Last Payment Date.

For "Interest in Advanced", interest is paid at the beginning of the payment period and is calculated using the current period's Ending Balance (FE 100 from Bucket_001). The Payment Frequency is calculated by taking the "Calculated Following Payment Date" - Next Payment Date where the "Calculated Following Payment Date" is Next_Payment_Date rolled forward by Pmt_Freq.

Development explains this in the Oracle Financial Services Technical Reference Manual, in Chapter 10 "Cash Flow Dictionary" under section "Interest Type Code".  The same information can be found in the Oracle Financial Services Cash Flow Engine Reference Guide, Release 5, in the "Cash Flow Dictionary" chapter.

Note: The Oracle Financial Services Cash Flow Engine Reference Guide is available in the Documentation Library for Oracle's EPM Suite for OFSAA 7.1/7.2/5.x.

Bug 22910348 : INCORRECT FE 430 INTEREST CASH FLOW FOR FIXED RATE PRODUCTS

Hdr: 22910348 N/A CALCENG 8.0.1 PRODID-5662 PORTID-226Abstract: INCORRECT FE 430 INTEREST CASH FLOW FOR FIXED RATE PRODUCTS *** 03/10/16 11:25 am ***1) Problem Description---------------------- On ALM  8.0.1 is generating incorrect results FE 430 Interest Cash Flow for some of the instruments. ACTUAL BEHAVIOR  ---------------The generated cash flow results - FE 430 interest cash flow appears to be incorrect for some instruments.  Other instruments appear to be fine.  All instruments are fixed rate. EXPECTED BEHAVIOR-----------------------Calculate FE 430 for maturity using Document:223205.1 "How to Validate Interest Cash Flow (FE 430) for ALM and RM"  and Cash Flow Engine guide. 2) Steps to Reproduce Problem-----------------------------Issue reproduced in support instance: 1. Loaded data from export-fsi-d-borrowings.xlsx to FSI_D_BORROWINGS2. UPDATE FSI_D_BORROWINGS SET LEGAL_ENTITY_ID = -1 where as_of_date = '22-FEB-16';3. Created new Common COA IDs as Earning Assets: COMMON_COA_ID211750211751211760212400212800212810212813 4. Added to Total Common COA Hierarchy 5. Updated Application Preferences: 2/22/16 6. Created new ALM Static Deterministic Process: coki_pat - 200236 7. Ran the process, reproduced the results: select * from fsi_o_process_cash_flows where result_sys_id = 200236 AND FINANCIAL_ELEM_ID IN (210,430) ORDER BY ID_NUMBER, CASH_FLOW_SEQUENCE DESC;SELECT * FROM RES_DTl_200236 order by common_coa_id;

How to Validate Interest Accrual (FE 440) for RM and ALM (Doc ID 223206.1)

GOAL

How to Validate / Calculate Interest Accrual (FE 440) for Risk Manager 4.5 and Asset Liability Management (ALM).

SOLUTION

Risk Manager (RM) and Asset Liability Management (ALM) calculate interest accrual based upon the payment periods.  If the modeling bucket start and end dates defined in the RM Configuration ID/ALM Time Buckets are different from the last and next payment dates, two different accrual amounts must be calculated for the two different payment periods that occur during the modeling bucket to validate the results.

For example:Instrument Data =============== As of Date:  01/31/2000 Last Payment Date:  01/24/2000 Next Payment Date:  02/24/2000 Payment Frequency:  1M Interest Type: In Advance

RES_DTL_XXX Data ================ BUCKET_001 Start Date: 02/01/2000 BUCKET_001 End Date: 02/29/2000 Interest Cash Flow (FE 430) for BUCKET_001: 47.91 Interest Cash Flow (FE 430) for BUCKET_002: 40.45

To calculate the interest accrual for the first modeling bucket, BUCKET_001, calculate the daily accruals that occur between 02/01/2000 and 02/29/2000.

Daily Interest Accrual = Interest Cash Flow / number of days in payment

In this example, there will be two different daily interest accrual amounts because the modeling buckets contains two payment periods:Payment Date  Interest Cash Flow     Days in Payment ============  ==================     =============== 02/24/2000          47.91             31 (01/24/2000 - 02/24/2000)03/24/2000          40.45             29 (02/24/2000 - 03/24/2000)

Daily Interest Accrual for 02/24/2000 payment period:47.91/31 = 1.545483871 

Daily Interest Accrual for 03/24/2000 payment period: 40.45/29 = 1.394827586

Note: Interest in advance records calculate interest accruals from the current payment date to the next payment date.  Interest in arrears records calculate interest accruals from the current payment date to the previous payment date.

To calculate the interest accrual for the modeling bucket, multiply the daily accruals by the number of payment period days contained in the modeling bucket.

Between 02/01/2000 and 02/24/2000 = 24 days Between 02/25/2000 and 02/29/2000 = 5 days 

Interest Accrual for BUCKET_001: = 24 days @ 1.545483871 + 5 days @ 1.394827586 = 44.06575083

Note: The same calculation is used for the following Financial Elements with minor changes:

441 Interest Accrued Net (Current Basis) - Uses Interest Cash Flow that is calculated after factoring in the current bucket's exchange rate

445 Interest Accrual - Gross - Uses Interest Cash Flow FE 435 in place of 430 

450 Interest Accrual - Transfer Rate - Uses Interest Cash Flow FE 437 in place of 430

Note: If using a Payment Schedule, then the LAST_PAYMENT_DATE on the record should also be included in the FSI_D_PAYMENT_SCHEDULE table for correct cash flow.  Correct data is key for proper cash flow results.  Confirm that LAST_PAYMENT_DATE, NEXT_PAYMENT_DATE and PMT_FREQ populated on the instrument record have the correct data.

Sample validation spreadsheet: Interest Accrual Spreadsheet.xls.

How to Calculate Average Balance (FE 140) for ALM (Doc ID 1310533.1)

GOAL

In Oracle Financial Services Asset Liability Management (ALM), in the Result Detail table, how is the value for Average Balance Financial Element 140 validated?

SOLUTION

The Avg. Balance is calculated by taking the Beginning Balance (FE 60) and the Ending Balance (FE 100) and weighting each balance by the number of days the balance exists in the bucket.  The sum is of the weighted balances is then divided by the number of days in the bucket.

Example:

BUCKET_001: 01/01/2000 to 01/31/2000 = 31 DaysCash Flow Runoff Date: 01/15/2000

Note:  An example of the runoff date is a NEXT_PAYMENT_DATE that occurs in the bucket.  If unsure of the date, review detailed runoff dates listed in FSI_O_PROCESS_CASH_FLOWS when you select the Cash Flow Audit option.

Begin Balance (FE 60): 1,945.86End Balance (FE 100): 1,674.24

Days the Beg. Balance is in Bucket_001: 15 (01/01/2000 - 01/15/2000)Days the End Balance is in Bucket_001: 16 (01/16/2000 - 01/31/2000)

Beg. Balance weighted by days: 1,945.86 * 15 = 29,187.9End Balance weighted by days: 1,674.24 * 16 = 26,787.84

Average Balance: (29,187.9+26,787.84)/31 = 1,805.67

the spreadsheet below contains the example: Avg_Bal_FE140_Calc.xls.

How to Calculate Average Net Rate (FE 160) for ALM (Doc ID 1626997.1)

GOAL

For Oracle Financial Services Asset Liability Management (ALM), how does the cash flow engine calculate the Average Net Rate (Financial Element 160)?

SOLUTION

The ALM cash flow engine takes a weighted average of the Beginning Net Rate (FE 80) and Ending Net Rate (FE 120) to calculate the Average Net Rate (FE 160).

See the example below:

Financial Elem BUCKET_00160 1945.8680 179.99100 1704.24120 74.99140 1821.15160 125.8

 In the example, BUCKET_001 has the date range of 01-JAN-2000 to 31-JAN-2000 or 31 Days.

NEXT_REPRICE_DATE: 15-JAN-2000

To calculate the Average Net Rate, calculate a weighted average for the bucket:

Days to Reprice Date in Bucket_001: 15 (01-JAN-2000 to 15-JAN-2000)Days after Reprice Date in Bucket_001: 16 (16-JAN-2000 to 31-JAN-2000)

Begin. Rate (FE 80) weighted by days: 179.99 * 15 = 2,699.85End Rate (FE 120) weighted by days: 74.99 * 16 = 1,199.84

Average Rate: (2,699.85+1,199.84)/31 = 125.8

To get the rate value, take Avg. Net Rate FE 160 / Avg. Net Balance FE 140:

125.8 / 1821.15 = 0.0690772314197073 = 6.91%

Note: The initial rate is taken from the instrument record.  When a Repricing Event occurs, the new rate is taken from the Forecast Rates values generated for the Interest Rate Curve.

Incorrect Deferred Runoff FE540 Results (Doc ID 420636.1)

GOAL

You are currently trying to validate your Deferred Runoff (FE 540) results using the formula in the Oracle Financial Services Technical References Guide, but the results seem to be incorrect.

Deferred Runoff = (par_bal + deferred) * (average rate + spread)/a - Interest Accrued

SOLUTION

There is an internal RM Bug: 1443909 DEFERRED RUNOFF CALC SHOULD CALCULATE IRR EXCLUDING ACCRUED INTEREST which will cause incorrect results if the as_of_date of the instrument records are between payment dates:

In calculating deferred runoff, the engine has to calculate an internal rate of return (IRR) so that it equates with cur_par_bal and deferred_cur_bal (this sum is referred to the market value). But, if the as_of_date is between payment dates, then the market value is slightly off because it includes accrued interest from last_payment_date to as_of_date. This will have an effect that it overstates the market value and so calculate incorrect deferred runoff.

The proper method to calculate the IRR is to subtract the accrued interest from last_payment_date to as_of_date when summing all the discounted cashflows as follows:

cur_par_bal + deferred_cur_bal = sum(from t = 1 to N) { CF(i) / (1+IRR)^t } - accrued interest

ACCRUED INTEREST can be calculated as

First Interest Cash Flow * (AOD - LPD)/ (NPD - LPD) where LPD = last payment date from the instrument recordNPD = next payment date from the instrument record LPD and NDP are also the last payment date and the next payment date used in the calculation of the first interest cash flow.

Find the IRR to solve this equation and use this IRR for subsequent deferred runoff amount.

Therefore, if the AS_OF_DATE on the instrument is between the payment_dates, the deferred balance calculation will be incorrect.

This bug is scheduled to be fixed later this year.

Bug 1443909 : DEFERRED RUNOFF CALC SHOULD CALCULATE IRR EXCLUDING ACCRUED INTEREST

Hdr: 1443909 0 CALCENG 4 PRODID-270 PORTID-46 AR-16560 1443768Abstract:  DEFERRED RUNOFF CALC SHOULD CALCULATE IRR EXCLUDING ACCRUED INTEREST

Submitted by Mertes, Rondi. In calculating deferred runoff, the engine has to calculatean internal rate of return (IRR) so that it equates withcur_par_bal and deferred_cur_bal (this sumis refered to the market value).  But, ifthe as_of_date is between payment dates, then themarket value is slightly off because it includes accruedinterest from last_payment_date to as_of_date.  Thiswill have an effect that it overstates the market value andso calculate incorrect ddeferred runoff. The proper method to calculate the IRR is to subtractthe accrued interest from last_payment_date to as_of_date when summing all the discounted cashflowsas follows: cur_par_bal + deferred_cur_bal =sum(from t = 1 to N) { CF(i) / (1+IRR)^t } - accrued interest ACCRUED INTEREST can be calculated as First Interest Cash Flow * (AOD - LPD)/ (NPD - LPD)where LPD = last payment date from the instrument recordand NPD = next payment date for the instrument record LPD and NDP are also the last payment date and the next payment date used in the calculation of the first interest cash flow Find the IRR to solve this equation and use this IRRfor subsequent deferred runoff amount. To Duplicate:1. Config ID: VLW_SABRINA 1036752. Process ID: VLW_SABRINA 103678

*** 01/28/04 10:59 am *** *** 03/23/07 08:50 am *** *** 05/04/07 07:30 am *** *** 05/04/07 07:30 am *** Yes, we would definitely want to push for solution as having incorrect deferred runoff would result in incorrect income projection and hence inaccurate reporting to management, board, rating agencies and regulators. This would have a very serious impact to the bank, as  wrong decision and strategy could be made resulting from the incorrect figures. In addition, the Bank may be overstate the risk exposures and hence regulators  may impose stringent controls to the bank. Base on the above, we think that the severity of the SR and bug should be raised to 2. We hope the issue can be resolved at the soonest.

How to Calculate WARM (FE 500) for ALM (Doc ID 1572395.1)

GOAL

For Oracle Financial Services Asset Liability Management (ALM), how do you calculate Financial Element (FE) 500 WARM?

SOLUTION

WARM is the Maturity Date - Bucket End Date.

In the ALM Result Detail table (RES_DTL_xxxxx), the value is stored in Years.  To get the value, divide FE 500 by FE 100 (Ending Balance).

Example for BUCKET_001:

BUCKET_001 is from 1/1/2000 to 1/31/2000.MATURITY_DATE: 6/12/2004

FE 100 = 6782.61FE 500 = 29620.49

WARM = 29620.49 / 6782.61 = 4.3671 Years

Validate the value as follows:

6/12/2004 - 1/31/2000 = 1594 Days

Covert to months: 1594 / 30.4166667 = 52.41 Months

Convert to Years: 52.41 / 12 = 4.3671

How to Validate Prepayment Runoff Calculated in ALM / RM and TP / FTP (Doc ID 277376.1)

GOAL

You are looking to validate your prepayment runoff, FE 180, generated by your Prepayment ID / Prepayments Rule in either Oracle Risk Manager (RM), Oracle Transfer Pricing (TP). Oracle Financial Services Asset Liability Management (ALM), or Oracle Financial Services Funds Transfer Pricing (FTP). How does OFSA/OFSAA calculate prepayment?

SOLUTION

From the Oracle Financial Services Technical Reference Manual, Release 4.5, Chapter 9 Cash Flow Calculations, Cash Flow Calculation Process, Prepayment Event Steps (example follows at the end).  The same calculations can be found for OFSAA in the Oracle Financial Services Cash Flow Engine Reference Guide, Release 5 or 6.

1.Determine Base Annual Prepayment Rate.

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

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

Base Annual PP Rate = Constant Rate

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

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

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

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

Range LookupRange Lookups treats the nodes within the dimension as a starting value for a range that extends to the next node dimension. For example, take an original term dimension with node values of 0,12, and 24. The range lookup treats these values as three sets of ranges: 0 to 11, 12 to 23, and >= 24.

Interpolation LookupIf the interpolation method is selected, the lookup applies straight line interpolation to determine the proper prepayment rate for values that fall between nodes.

Lookups Outside the Given RangeFor both lookup methods, lookup for values less than the lowest node value receives the prepayment rate associated with the lowest node. Values greater than the highest node receive the prepayment rate associated with the highest node.

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

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

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

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

3. Check Prepayment in Full Option.If the adjusted final prepayment rate is equal to 100%, the instrument is paid off in full.

4. De-annualize the Prepayment Option.The annual prepayment rate is adjusted to a rate per payment. The formula

is as follows:

Prepayment Factor = (1-(1- Annual PPRate)^(1/payments per year)

5. Adjust Prepayment Rate for Stub or Extended Payments.The prepayment rate per payment is adjusted if the payment is a stub or extended payment. This adjustment is made in the same manner that interest cash flows are adjusted, as follows:

Adjusted prepayment factor = Prepayment Factor * (next payment date -last payment date) / (payment frequency in days)

6. Determine prepayment amount.The amount of runoff due to prepayments is calculated. The prepayment factor is applied to the current balance.

Prepayment Runoff = Current Balance * prepayment factor

7. Update current balance.The current balance must be reduced by the amount of prepayment runoff.

Current Balance = Current Balance - Prepayment runoff

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

Current Payment = Current Payment * (1 - prepayment factor)

If the payment treatment is "Curtailment", the current payment remains constant, effectively reducing the term of the instrument.

Therefore, based on a simple example (again please note, the calculation is dependent upon your instrument records as in Step 5 above), your validation will be something like:

1.Determine Base Annual Prepayment Rate.Base Annual PP Rate = Constant Rate

==>From the Prepayment ID: 18.89% for all Origination Dates

2. Adjust for Seasonality.Annual PP Rate = Seasonality Factor(Current Month) * Base Annual PP Rate

==>Assuming no seasonality: Annual PP Rate 18.89%

3. Check Prepayment in Full Option.If the adjusted final prepayment rate is equal to 100%, the instrument is paid off in full.

==>Annual PP Rate <> 100%

4. De-annualize the Prepayment Option.The annual prepayment rate is adjusted to a rate per payment. The formula is as follows:Prepayment Factor = (1-(1- Annual PPRate)^(1/payments per year)

==>Assuming 1 month payment frequency: Prepayment Factor = (1-(1-(18.89/100))^(1/12))=0.017296

5. Adjust Prepayment Rate for Stub or Extended Payments.Adjusted prepayment factor = Prepayment Factor * (next payment date -last payment date) / (payment frequency in days)

==> Assuming no stub or extended payments.

An example of an extended payment adjustment would be:

last payment date = 17-APR-2013next payment date = 01-AUG-2013payment frequency = 3M

Difference between last payment date and next payment date = 106 days.

Payment frequency in days = next payment date - payment frequency  = 01/AUG/2013 - 3M = 01/AUG/2013  -   01/MAY/2013  = 92

Adjusted prepayment factor = 0.017296 * 106/92 = 0.019928

6. Determine prepayment amount.Prepayment Runoff = Current Balance * prepayment factor

==> Current Balance is actually adjusted by the Payment Runoff i.e, FE 60 - FE 190 as the Prepayment Event happens after the Payment Event. Assuming Cur_Par_Bal = 100,000 and Payment Runoff for the month = 1000 then:Prepayment Runoff = 90,000*0.017296= 1556.64

Please reference the attached spreadsheet,  prepayment_validation.xls   for a validation example using a Prepayment Table with a fixed rate instrument.

Note: Prepayment output is calculated on Payment date, and is summed up in each time bucket, if there are multiple prepayment events in that bucket.  If Prepayment Cash Flow Treatment = Refinance, Cur payment gets updated with formula Current Payment = Current Payment * (1 - prepayment factor).  An example of prepayment validation with multiple prepayment events can be found in the  Loan_Prepay_Validation_dev.xlsx .

Bug 23514454 : CANNOT VALIDATE PREPAYMENT AFTER BUCKET_001 FOR CONSTANT PREPAYMENT

Hdr: 23514454 N/A CALCENG 8.0.1 PRODID-5662 PORTID-226Abstract: CANNOT VALIDATE PREPAYMENT AFTER BUCKET_001 FOR CONSTANT PREPAYMENT *** 06/01/16 02:47 pm ***Currently trying to validate ALM constant prepayment output using the following from DOC ID 277376.1: De-annualize the Prepayment Option.The annual prepayment rate is adjusted to a rate per payment. The formula is as follows:Prepayment Factor = (1-(1- Annual PPRate)^(1/payments per year) Adjust Prepayment Rate for Stub or Extended Payments.The prepayment rate per payment is adjusted if the payment is a stub or extended payment. This adjustment is made in the same manner that interest cash flows are adjusted, as follows: Adjusted prepayment factor = Prepayment Factor * (next payment date -last payment date) / (payment frequency in days) The first bucket appears to match expected results however not able to validate the following buckets.  Please advice. 2) Steps to Reproduce Problem-----------------------------Run ALM process with constant prepayment.Attempt to reconcile prepayment results. 3) Environment Information--------------------------ALM 8.0.1

How to Calculate Prepayment Runoff (FE 180) in RM or ALM (Doc ID 280005.1)

GOAL

How does the Risk Manager (RM) or Asset Liability Management (ALM) cash flow engine calculate the Prepayment Runoff value - Financial Element 180?

SOLUTION

Risk Manager and Asset Liability Management use the following calculation to generate Prepayment Runoff (FE 180):

Prepayment Runoff = (Beginning Balance - Payment Runoff) * Prepayment Factor * Seasonality

The Prepayment Factor is a de-annualized version of the Prepayment Rate.  RM/ALM has two different calculations for the "Prepayment Factor" depending on whether a Payment Schedule is used.

Prepayment Factor - No Payment Schedule-------------------------------------------------------

Prepayment Factor = 1 - ((1 - Prepayment Rate)^(1/Payments Per Year))

Prepayment Factor - Payment Schedule Used-------------------------------------------------------

Prepayment Factor = 1 - ((1 - Prepayment Rate)^(1/(365/Days in Payment Period)))

Note: 365 is always used -- even in leap years.

Example - Record Using Payment Schedule - Payment Event in June

Beginning Balance: 184,862,058Payment Runoff: 1,346,431Prepayment Rate: 0.75Seasonality: 1

Payment Period: 05/10/2004 - 06/10/2004(Last Payment Date - Next Payment Date)= 31 Days (because there are 31 days in May)

Prepayment Factor = 1 - ((1-0.75)^(1/(365/31))) = 0.111072918

Prepayment Runoff =(184,862,058-1,346,431)*0.111072918*1 = 20,383,616.19

Note I: The Prepayment Runoff calculations above assume that there are no stub or extended Payments.  See the "Prepayment Event Steps" section of the "Cash Flow Calculations" chapter of the 4.5 OFSA Technical Reference Manual for information on adjusting for stub or extended payments.  The same information is available in the Oracle Financial Services Cash Flow Engine Guide in the "Cash Flow Calculations" chapter.

Note II: If the Prepayment Rate is 100%, RM / ALM automatically pays off the instrument in full.

Cannot Validate Cash Flow Results With Semi-Annual Rates (Doc ID 95753.1)

Problem Description-------------------You cannot validate your interest cash flow results from Oracle RiskManager (RM) or Oracle Transfer Pricing (TP) using the rate from the Account level data. In your Configuration ID, you have a "CompoundingMethod" of "Semi-Annual."

Solution Description--------------------To validate cash flow results when the "Compounding Method" is set to "Semi-Annual" in the active Configuration ID, you must convert the account level rate found on the instrument record from "semi-annual" to "annual."

Use the following calculation to annualize the rate where payment frequencyis specified in months:

Annual Rate = ((1+Rate/2)^(Payment Frequency/12*2)-1)*(12/Payment Frequency)

You can find this calculation on page 30-6 of the 3.5 Risk ManagerReference Guide or page E-6 of the 3.5 Transfer Pricing ReferenceGuide.

Example:Rate = 9.5%Payment Frequency = 4 months

Annual Rate = ((1+0.095/2)^(4/12*2)-1)*(12/4) = 0.094263368Annual Rate = 9.4263368%

Solution Explanation--------------------The "Compounding Method" option in the Configuration ID defines howrates are quoted in the database. You can store them as either "Annual" or "Semi-Annual." However, the Oracle Financial Services Applications (OFSA) cash flow engine only uses annual rates in its internal calculations.If a rate is stored in the database as semi-annual, the cash flow engine will first convert the rate to an annual rate and then perform the internalcalculations. As a result, when validating cash flow engine output, you mustuse the above calculation to convert your semi-annual rate to the correspondingannual rate before proceeding with your validation calculations.

References----------3.5 Oracle Risk Manager Reference Guide (Part # A60611-01)4.0 Oracle Risk Manager Reference Guide (Part # A68684-01)3.5 Oracle Transfer Pricing Reference Guide (Part # A60378-01)4.0 Oracle Transfer Pricing Reference Guide (Part # A68683-01)

How Does Risk Manager Generate FE 212 - Negative Runoff (Doc ID 177650.1)

GOAL

How does Risk Manager (RM) generate Financial Element (FE) 212 - negative runoff?

SOLUTION

The Cash Flow engine generates Financial Element 212 - Negative Runoff - when Interest is greater than the Current Payment.

Interest is calculated as follows:

principal * rate *(cur_pmt_date - last_pmt_date)  ------------------------------------------------  * accrual basis  (cur_pmt_date - last_pmt_date) * pmt_freq

If the result of the above calculation is greater than the Current Payment, RM generates a negative runoff.

Three options exist to address negative runoff:

1. Leave the negative runoff2. Change the Current Payment so that it is greater than the Interest3. Change the Last_Pmt_Date

Example:

Principal       = 21,217,735  Rate            = 18.5%  Current Payment = 700,000  Last_pmt_date   = 06/30/97  Next_pmt_date   = 01/01/98  Number of days  = 185 days  Interest = 21,217,735 *18.5%* 185/365 = 1,989,526  Negative Runoff = 1,289,526

How is Transfer Rate Calculated in RM for both Actual and New Business (Doc ID 158942.1)

GOAL

How is Transfer Rate Calculated in RM for both Actual and New Business?

SOLUTION

The following applies to scenario-based processing.

In Risk Manager, transfer rates for both existing and new business are taken from an interest rate curve. The method for determining which rate on the curve is used is detailed in the 4.0 Risk Manager Reference Guide and the 4.5 OFSA Technical Reference Manual. For 4.0, review the "Reprice Event" section beginning on page 31-33 of the RM guide. For 4.5, review the "Reprice Event" section beginning on page 9-37 of the TRM.

For existing business, financial element 130 contains the transfer rate. The interest rate curve used is specified in the T_RATE_INT_RT_CD column on the instrument record.

For new business, financial element 370 contains the transfer rate. The interest rate curve used is specified in the Leaf Characteristics ID.

Note: Rates in the RES_DTL_XXX tables are stored as balances. To get the actual rate, divide the transfer rate balance by the weighting factor balance specified in the Risk Manager Financial Elements chapter (4.0 RM Guide/4.5 TRM). For example, divide financial element 130 by the end balance financial element (FE100).

Which Instrument Column Is Used for Starting Balance in RM (Doc ID 156717.1)

GOAL

Which instrument column is used for the starting balance?

SOLUTION

The sum of CUR_PAR_BAL is the starting balance from which cash flows are generated. This balance is stored in Financial Element 60 on the RES_DTL_XXX table.

If generating Budgeting Cash Flows in OFSA 3.5, the CUR_PAR_BAL sum is stored in Financial Element 100 in the Bucket representing the current month.

The CUR_PAR_BAL amount may be altered by the following conditions:

1. PERCENT_SOLD > 0Starting Balance = CUR_PAR_BAL*(100 - PERCENT_SOLD)

2. DEFFERRED_CUR_BAL <> 0Starting Balance = CUR_PAR_BAL + DEFERRED_CUR_BAL

3. NEXT_PAYMENT_DATE < AS_OF_DATE and AMRT_TYPE_CD <> 700Starting Balance = CUR_PAR_BAL minus payment(s) prior to AS_OF_DATE.

How Does ALM Calculate a Currency Conversion After an Exchange Rate Shock? (Doc ID 1540092.1)

GOAL

In Oracle Financial Services Asset Liability Management (ALM), you are running an ALM Process against multiple currencies and consolidating the results to the CONS_DTL_xxxxx table.  You have defined different Currency Rate scenarios in the Forecast Rates rule.  Example: (1) flat,  (2) up 1, and (3) down -0.03.  You understand how the flat results are calculated in the CONS_DTL_xxxxx but cannot validate the other scenarios. 

How does ALM convert the balances for the currency rate shocks when populating the CONS_DTL_xxxxx table?

FIX

ALM performs the Currency Rate shocks as follows:

In this example, AED is the functional currency and everything is translated to AED in the Consolidated Detail table.

Flat Scenario

In the Rate Management > Currency Rates screen (Floating), the following exists:

From Currency: AED   To Currency: USD3.672959671

In RES_DTL_xxxxx, FE 100 = 100,000 USD.

For the Flat Scenario (no rate shocks), to convert the balance to AED, ALM calculates 100,000 USD * 3.672959671 = 367,295.97 AED.

Exchange Rate Shock Up

For Scenario 2, there is a rate increase of 1.

To convert the USD balance to AED, go to FSI_EXCHNG_RATE_DIRECT_ACCESS where FROM_CURRENCY_CD = 'USD' and TO_CURRENCY_CD = 'AED'.  The exchange rate change is applied to this value.

For example, in FSI_EXCHNG_RATE_DIRECT_ACCESS, you have EXCHANGE_RATE = 0.27226 (which is the inverse of 3.672959671).

The adjusted (+1) EXCHANGE_RATE = 1 + 0.27226 = 1.27226.  This new exchange rate indicates a depreciation of USD against AED.

ALM then uses the inverse of this adjusted rate when doing the conversion.

Get the inverse of 1.27226:

1/1.27226 = 0.786002861

ALM uses this inverse value to convert the balance from RES_DTL_xxxxx for Scenario 2:

100,000 USD * 0.786002861 = 78,600.29 AED

Exchange Rate Shock Down

For Scenario 3, there is a rate decrease of -0.03.

Again, the rate change is applied to EXCHANGE_RATE = 0.27226 (from FSI_EXCHNG_RATE_DIRECT_ACCESS where FROM_CURRENCY_CD = 'USD' and TO_CURRENCY_CD = 'AED'):

The adjusted (-0.03) EXCHANGE_RATE = 0.27226 - 0.03 = 0.24226

ALM then uses the inverse of this adjusted rate when doing the conversion.

Get the inverse of 0.24226:

1/0.24226 = 4.127796582

ALM uses this inverse value to convert the balance from RES_DTL_xxxxx for Scenario 3:

100,000 USD * 4.127796582 = 412,779.66 AED

This is how ALM computes the converted balances in the Consolidated Detail for exchange rate shocks.

Note: There has been a request to enhance the current functionality to allow the exchange rate shock to be applied to the rate where, from the example above, FROM_CURRENCY_CD = 'AED' and TO_CURRENCY_CD = 'USD' in

FSI_EXCHNG_RATE_DIRECT_ACCESS when doing the conversion (ex. 3.672959671).  For the current status of this request, see Enhancement Request Bug 16304157 - RESULTS NOT CORRECT AFTER SHOCK TO CURRENCY EXCHANGE RATE.

Bug 16304157 : ER: RESULTS NOT CORRECT AFTER SHOCK TO CURRENCY EXCHANGE RATE

To Bottom

Hdr: 16304157 N/A CALCENG 6.0.1 ENG_CASHFLOW PRODID-5662 PORTID-226Abstract: ER: RESULTS NOT CORRECT AFTER SHOCK TO CURRENCY EXCHANGE RATE *** 02/08/13 09:08 am ***1) Problem Description---------------------- In Oracle Financial Services Asset Liability Management (ALM) 6.0, the forecasted currency exchange rate shock is not getting added to the current exchange rate correctly.  This results in an incorrevct Total Currency Gain/Loss value (FE 465). The customer has the following setup: Functional Currency: AED In the Rate Management > Currency Rates screen (Floating), they entered the following for: From Currency: AED    To Currency: USD= 3.672959671 In RES_DTL, they have FE 100 = 100,000.In CONS_DTL, for the flat Scenario 1, ALM calculates 100,000 * 3.672959671 = 367,295.97 For Scenario 2, they want an increase of 1 for the Currency Rate.  They expect ALM to calculate the following for Scenario 2: 100,000 * 4.672959671 = 467,295.97 However, ALM is not doing this. Instead, ALM is taking the inverse of 3.672959671 which is 0.27226.  It applies the rate shock to the inverse: =1.27226 Then, it uses the inverse of 1.27226 for the rate shock used in the CONS_DTL table: = 1/1.27226 = 0.786002861 ALM uses this value to calculate the new balance in CONS_DTL: = 100,000 * 0.786002861 = 78,600.29 The customer feels this is wrong.  For a beginning balance of 367,295.97 (100,000*3.672959671), they feel the ending balance after a currency shock of 1 should be 467,295.97 (100,000*4.672959671) and not 78,600.29.

See the customer's example in FX Deals & Other Info.xlsx. 2) Steps to Reproduce Problem----------------------------- 1. Create a Forecast Rates rule with 2 Scenarios 2. In the "Currency Codes" section for the Forecast Rates, define Scenario 1 as Flat and define Scenario 2 as Structural Change with a Total Rate change of 1 in the first bucket. 3. Create and run an ALM process against a record that will be converted by the Exchange Rate. Review the result in CONS_DTL and compare the flat balance with the balance impacted by the structural change. 3) Environment Information--------------------------The customer is using ALM 6.0.1.

How to Validate New Business Avg Balance with Target Growth and Distributed Option (Doc ID 1318314.1)

GOAL

For Oracle Financial Services Asset Liability Management (ALM), how can you validate the New Business Average Balance (140) value generated when running a Dynamic Deterministic process with a Forecast Balance method of Target Growth = 0% (flat balance sheet) and New Business Timing = "Distributed"?

SOLUTION

To calculate the New Business (RESULT_TYPE_CD = 1) Average Balance (FE 140) for a specific Time Bucket, take the balance added to keep the growth flat (listed in New Add Balance FE 340) and multiply it by the number of days the balance exists in the bucket divided by the total number of days in the bucket.

Example:

BUCKET_001: 01/01/2000 to 01/31/2000 = 31 Days

To keep the balance flat, the New Add Balance is added on the Next Payment Date.

NEXT_PAYMENT_DATE: 1/15/2000New Add Balance (FE 340): 271.62

So, the New Add Balance exists in BUCKET_001 from 1/15/2000 to 1/31/2000 = 16 Days.

The Average Balance for New Business is calculated as:

271.62 * 16 / 31 = 140.19

In BUCKET_002 and subsequent buckets, the Average Balance must also incorporate the existing new business balance, minus runoff, in addition to the New Add Balance.  See the uploaded spreadsheet Target_Growth_Distr_Orig_Avg_Bal.xls for an example.

Target_Growth_Distr_Orig_Avg_Bal.xls

Bug 11884042 : NO NEW BUSINESS CREATED FOR BEHAVIOR PATTERN RECORDS AFTER PATCH 11060542

Hdr: 11884042 N/A CALCENG 5.2.2 ENG_CASHFLOW PRODID-5662 PORTID-23Abstract: NO NEW BUSINESS CREATED FOR BEHAVIOR PATTERN RECORDS AFTER PATCH 11060542 *** 03/17/11 02:28 pm ***============================================================================           Problem Description, Including All Error Messages============================================================================ For Oracle Financial Services Asset Liability Management (ALM) 5.2.2, after applying Patch 11060542: "FE430,440 OR INCORRECT FOR 1ST TENOR IN NON-MATURITY BEHAVIOUR PATTERN", instrument records with a Behavior Pattern AMRT_TYPE_CD no longer output New Business records with RESULT_TYPE_CD = 1 in the RES_DTL_xxxxxx table. Records without a Behavior Pattern still output New Business records. Before applying Patch 11060542, records with a Behavior Pattern could create New Business records successfully. Can we adjust the distribute Balance equation to be similar to Bucket end, whereNew_Business_Balance = (1.0 + Target Growth %) * GiveBegBalTotal(ScenNo, Bucket)By adding the 1.0 + target growth%, distributed will support a 0% growth strategy (flat balance sheet)Is Behavior Type Code required when forecasting with Behavior Patterns and if yes - we don't appear to have any way for the user to input this assumption.  It seems this should be an input option within Product Characteristics (and Product Profiles) and Transaction Strategies.

OTP Bank is expecting this fix for the 5.5 release.  Can you confirm if this is on track.  Also, can you circulate results for review or provide us with access to an environment where some smoke testing can occur?

OFSAA FE 340 and 360 Are Not Generated in RES_DTL Table (Doc ID 1316345.1)

SYMPTOMS

After running an ALM Process, FE 360 and 340 are not generated in RES_DTL table.

CAUSE

&quot;New Origination Balances and Rates&quot; was not checked.

SOLUTION

Select the Dynamic Deterministic ALM process and go to the Calculation Elements screen.

On the right side, select New Origination Balances and Rates.

Then re-run the ALM process. FE 360 and 340 should be generated in the output.

How to Validate ALM Stochastic Earnings At Risk (EAR) (Doc ID 1475286.1)

GOAL

In Oracle Financial Services Asset Liability Management (ALM), how do you validate the "Earnings" value in the EAR_LEAF_AVG_xxxxx table?

Note: These tables are only output by Dynamic Stochastic processes.

SOLUTION

The "Earnings" value in the EAR_LEAF_AVG_xxxxx table is similar to the Interest Accrued calculation described in Document 223206.1 "How to Validate Interest Accrual (FE 440) for RM and ALM".

To calculate the value, first, run the Dynamic Stochastic ALM process with "Detail Cash Flows" selected in the "Audit" screen.

Then, calculate "Earnings" using the Interest Cash Flow (FE 430) data output to FSI_O_PROCESS_CASH_FLOWS.

For each Bucket Start Date and End Date, use the Interest Cash Flow balances to determine the daily interest accrued.  Daily Interest Accrued is calculated by taking the Interest Cash Flow (FE 430) and dividing it by the number of days in the payment period.

Note: A Bucket Start Date and End Date range may contain multiple payment periods and require you to calculate a separate daily interest accrual for each payment period.

To get the "Earnings" balance, multiple the daily interest accrual by the number of days in the Start Date-End Date range.  It is a sum of the daily interest accrual across the bucket.

For a detailed example, see Document 223206.1 "How to Validate Interest Accrual (FE 440) for RM and ALM".

How to Understand Gap Results in the RES_DTL_xxxxx Table (Doc ID 244125.1)

GOAL

In Oracle Risk Manager (RM) 4.5, how do you understand Gap results in RES_DTL_xxxxx table?How can you interpret the Gap results in the result detail table?

FIX

The bucket columns in the RES_DTL_xxxxx tables have a unique meaning for Gap results.  The date range for the buckets is not defined by the Modeling Buckets but by the Dynamic Buckets listed in the Configuration ID.

Gap results in RES_DTL_xxxxx must be viewed in conjunction with the Dynamic Buckets screen.  These dates are stored in the OFSA_RESULT_BUCKET table.  Query for the relevant rows in OFSA_RESULT_BUCKET using the Sys Id Num of the RM Process ID:

select * from ofsa_result_bucket where result_sys_id = <Sys Id Num>;

Several rows may exist with different DGAP_SCENARIO_NUM values in OFSA_RESULT_BUCKET.  The different DGAP_SCENARIO_NUM values represent the different term columns in the Dynamic Buckets screen of the Configuration ID.  Each column has its own Start Date.

In the RES_DTL_xxxxx table, the DGAP_SCENARIO_NUM corresponds to the START_DATE_INDEX column.

The FROM_DATE_xxx and TO_DATE_xxx columns in OFSA_RESULT_BUCKET define the date ranges for the BUCKET_xxx columns in RES_DTL_xxxxx.  In RM, the FROM_DATE_xxx and TO_DATE_xxx values are defined by the rows at the bottom of the Dynamic Buckets screen.

For example, if the Gap result in RES_DTL_xxxxx is in BUCKET_001, look at FROM_DATE_001 and TO_DATE_001 in OFSA_RESULT_BUCKET to see the date range for that bucket.  If the Gap result is in BUCKET_003, look at FROM_DATE_003 and TO_DATE_003.  Do not look at the Modeling Buckets screen for Gap date range information.

Risk Manager Gap results are easier to read when converted by the Transformation ID.  Transforming the RES_DTL_xxxxx table creates two

output tables: one for the basic RES_DTL_xxxxx Financial Elements and one for the Gap Financial Elements.  The Gap table name will be the same as the name specified in the Transformation ID but it will have an "_G" extension.

Example: OFS_RPT_RES_DTL_102831_G

How Does RM Output Gap Runoff for Fixed and Adjustable Records (Doc ID 362822.1)

GOAL

How does Oracle Risk Manager (RM) or Oracle Financial Services Asset Liability Management (ALM) output Gap Runoff for fixed rate and adjustable rate records?  Why would there be no Gap results in some of the Dynamic Buckets?

SOLUTION

If viewing Gap results from within the Result Detail table RES_DTL_xxxxx, first review Document:244125.1 "How to Understand Gap Results in the RES_DTL_xxxxx Table".

RM and ALM output Gap Runoff (Financial Element 661) as follows:

Fixed Rate Records

For fixed rate records (adjustable_type_cd = 0 and reprice_freq = 0), the cash flow engine outputs Gap Runoff until the cash flow engine reaches the Maturity Date of a record. 

Adjustable Rate Records

For adjustable rate records (adjustable_type_cd = 250 and reprice_freq > 0), the cash flow engine outputs Gap Runoff in each bucket until it reaches the Next Reprice Date of a record.  After RM/ALM reaches the Next Reprice Date, no more Gap Runoff is output.

Floating Rate Records

RM/ALM treats floating rate records the same as adjustable rate records.  However, the "Next Reprice Date" of a floating rate record is not determined by the NEXT_REPRICE_DATE column but by the date an interest rate change occurs in the rate curve specified by the INTEREST_RATE_CD column.  After the interest rate changes, no more Gap Runoff is output.

Note: For RM 4.5, there is a known issue with the Leaf Characteristics ID and Transaction ID that may prevent Gap Runoff from being output for floating rate "new business" records.  See the following MetaLink Document IDs:

     Note:292364.1 "Gap Runoff FE 660 Only Appears in Maturity Bucket for Floating New Business Records"

     Note:284583.1 "No New Business Gap Results Output in Res_Dtl_XXXXXX Table"     Note:283629.1 "No RM Gap Repricing Runoff (662) for New Business with Floating Adjustable Type"

Using all of the above information, no gap results will exist in a Dynamic Bucket if (1) there are no Maturity Dates for fixed rate records that fall in the Dynamic Bucket's date range, (2) there are no adjustable rate records with a Next Reprice Date past the Dynamic Bucket's start date, and/or (3) there are no floating rate records whose first rate change in the associated interest rate curve occurs past the Dynamic Bucket's start date.

Gap Runoff FE 660 Only Appears in Maturity Bucket for Floating New Business Records (Doc ID 292364.1)

SYMPTOMS

Gap Runoff (FE 660) for New Business with an Adjustable Type of "Floating" in the Leaf Characteristics ID is only appearing in the last, maturity bucket. FE 660 should have balances in earlier buckets as well.

CAUSE

Bug:3900809 Risk Manager (RM) does not recognize "floating" in the Leaf Characteristics ID as adjustable. Instead, the cash flow engine incorrectly views "floating" as being fixed rate for New Business. As a result, the Gap Runoff is put in the maturity bucket as it would be for any fixed rate product.

FIX

Workaround---------

1. Open the Leaf Characteristics ID2. Select the COA that uses "Floating"3. Change "Adjustable Type" = "Adjustable"4. Enter a Repricing Frequency and Multiplier value5. Save6. Change "Adjustable Type" = "Floating"7. Save

After re-running the RM Process ID, you should now have balances for Gap Runoff (FE 660) in additional buckets.

No New Business Gap RM Results Output in Res_Dtl_XXXXXX Table (Doc ID 284583.1)

SYMPTOMS

You find that there are no new business GAP results being output to the RES_DTL_XXXXXX table. Upon querying the result detail table, you find there are new business financial elements being output (RES_DTL_XXXXXX.RESULT_TYPE_CD = 1), however there are no new business GAP financial elements in your output.

CAUSE

Possible timing issue. It is likely that the instrument reprices before the new business rolls on. Since GAP repricing financial elements are output at repricing, if the new business rolls on after repricing, then there will be no new business output with GAP.

SOLUTION

TROUBLESHOOTING STEPS

Make sure the Leaf Characteristics ID for the product in question is either set to Adjustable with a Repricing Frequency > 0 or Floating and you have used the following workaround from Note: 283629.1No RM Gap Repricing Runoff (662) for New Business with Floating Adjustable Type (currently there is a known issue with the Leaf Characteristics ID and Gap FEs).

Workaround

1. Open the Leaf Characteristics ID2. Select the COA that uses "Floating"3. Change "Adjustable Type" = "Adjustable"4. Enter a Repricing Frequency and Multiplier value5. Save6. Change "Adjustable Type" = "Floating"7. Save

To eliminate the possibility that your issue is a timing issue, follow the steps below:

From your latest RES_DTL_XXXXX table, compare your full beginning balance, FE60, to your FE662 Gap Repricing Runoff. If the numbers are the same, this means that the balances are being calculated for Gap (i.e. repricing) BEFORE the new business

has a chance to roll on. 

To make this easier to illustrate, try the following:

1. Create a data filter for one or two instrument records. Make sure this record either

a. Matures during your first modeling bucket if non amortizing, i.e. MATURITY_DATE=07/01/2004 -07/31/2004 with AMRT_TYPE_CD=700 

OR

b. That it is an amortizing instrument with a payment during the first bucket ie.NEXT_PAYMENT_DATE = MATURITY_DATE=07/01/2004 - 07/31/2004 with AMRT_TYPE_CD=100

2. Confirm your Leaf Characteristics ID for the product in question is either set to Adjustable with a Repricing Frequency > 0 or Floating and you have used the following workaround from Note: 283629.1 No RM Gap Repricing Runoff (662) for New Business with Floating Adjustable Type

3. Setup a new Configuration ID with Dynamic Gap Start Dates (Active Configuration ID -> Dynamic Buckets) that include three Start Dates with the following:

Term 0 1 6Multiplier M M MStart Date 06/30/2004 07/31/2004 12/31/2004

4. Run the new test RM Process.

Depending on the repricing characteristics of your test instrument record, you should see New Business Gap results in either one or both of your dynamic start dates, 2 or 3.

No RM Gap Repricing Runoff (662) for New Business with Floating Adjustable Type (Doc ID 283629.1)

SYMPTOMS

A Risk Manager (RM) Gap Process with new business does not output any Gap Repricing Runoff (Financial Element 662) rows when assigned an Adjustable Type of "Floating" in the Leaf Characteristics ID. The rates within the Forecast Rates ID do change over time so the new business should reprice.

The same behavior also occurs if you create new records using the Transaction Strategy ID.

CAUSE

Bug:3900809 NO GAP REPRICING RUNOFF WITH FLOATING ADJUSTABLE TYPE & NEW BUSINESS

If OFSA_IDT_LEAF_CHARACTERISTICS where FIELD_NUM = 15 and 16 has 0 (no repricing frequency) and -1 (no multiplier) respectively, no Gap Repricing Runoff is generated.

FIX

Workaround

1. Open the Leaf Characteristics ID2. Select the COA that uses "Floating"3. Change "Adjustable Type" = "Adjustable"4. Enter a Repricing Frequency and Multiplier value5. Save6. Change "Adjustable Type" = "Floating"7. Save

After re-running the RM Process ID, you should now have rows for Gap Repricing Runoff (FE 662).

How to Calculate Market Value for ALM 5.x/6.x (Doc ID 1382119.1)

GOAL

In Oracle Financial Services Asset Liability Management (ALM), how can you calculate or validate the Market Value in FSI_O_RESULT_MASTER?

SOLUTION

ALM uses the following Market Value calculation for each Cash Flow Event listed in FSI_O_PROCESS_CASH_FLOWS:

Market Value = Cash Flow Amt / ((1 + Discount rate)^t)

where t = Days in Cash Flow period / Days in yearand "Cash Flow Amt" is usually Total Runoff FE 210 + Interest Cash Flow FE 430

However, it can be difficult to calculate the exact value output by the ALM Cash Flow Engine (CFE) for Market Value.  The reason is that the specific calculation of the Discount Rate used by the CFE is not documented currently.  If you do not use the "Spot Rate" Discount Method, you must use rate interpolation to get the Discount Rate and factors such as rounding or truncating to a certain decimal place or what "day" amount to use when converting a Month term to days can have an impact on the final interpolated rate.  This, in turn, can have an impact on the calculated Market Value.  Unless you use all of the same methods as the Cash Flow Engine, your result may be slightly different.

Currently, the only way to calculate the exact Market Value result is using an ALM Process with a Discount Method that has Method = Spot Input.

If you do want to validate a Market Value result for a Discount Method of "Spot IRC", we recommend you start with an Interest Rate Code that has the following characteristics:

Rate Format: Zero Coupon Yield Compound Basis: Annual Accrual Basis: Actual/Actual

If you use other options, rate conversion calculations are needed to adjust the rate taken from the Interest Rate curve in addition to the rate interpolation.

The following enhancement request exists asking development to provide

better documentation on the Market Value calculation performed by ALM:

Enhancement Bug 12574060 - "EXPLAIN VARIANCES IN MARKET VALUE CALCULATION OR IMPROVE VALIDATION STEPS"

Additionally, development is planning to add additional Financial Elements in ALM 6.0 or 6.1 that will assist in validating the Market Value result.

A sample Market Value Validation Spreadsheet is attached below: mkt_value_calc.xls.

Questions on Market Value Calculations for ALM 5.2 (Doc ID 1289349.1)

GOAL

Several questions regarding Oracle Asset Liability Management (ALM) Market Value calculations in OFSAA:

Question 1: What does market_value_clean represent in fsi_o_result_master?Question 2: Why keep dirty price (market_value) if calculating clean price (market_value_clean)?Question 3: What is the weighting factor for duration?Question 4:  In fsi_o_result_master, does the modified_duration represent the so-called modified duration (duration weighted by market value)? 

SOLUTION

Answer 1: Clean Price is a form of Market Value and is computed by excluding the accrued interest from the cash flows used to calculate the market value, where the accrued interest is the amount of interest from the last payment date to the as of date. Note, this adjustment has also been made in the code in calculating the YTM for deferred runoff. The MARKET_VALUE_CLEAN was added as an enhancement to output the clean market value as per above.

Answer 2: Per development: Market Value Clean (Clean Price) = Market Value (Dirty Price) – Accrued Interest. Both Market Value types are useful for analysis and therefore both values are output to provide both the Historical Market Value (Dirty Price) and the new Clean Price.

Answer 3: The weighting factor for duration is still MARKET_VALUE.

Answer 4: Modified Duration is weighted by Market Value. The modified_duration is the so-called modified duration.i.e. modified_duration = (duration/(1+(YTM/n))where duration represents Macaulay duration

The following are the correct weighting factors for ALM for Duration, Convexity and Modified Duration:

Duration = fsi_o_result_master.duration/fsi_o_result_master.market_valueConvexity = fsi_o_result_master.convexity/fsi_o_result_master.market_value

Modified Duration= fsi_o_result_master.modified_duration/fsi_o_result_master.market_value

Spreadsheet: FINANCIAL_MEASURES_CALCULATION.xls