Cash Flow Calculation Differences

1 Interest and principal payment events

ALM 8.x behavior

Interest and principal payments are expected to occur at the same time. Exceptions include non-amortizing instruments and interest-only payment patterns.
For an instrument, payment frequency and payment dates are the same for interest and principal.

ALM Cloud Service behavior

Interest and principal payment frequencies and dates can be different when the amortization type is Level Principal.
Different interest and principal payment dates can be provided for a Level Principal schedule.
A Principal Only event can be defined in a Level Principal payment pattern. Reason for change Customer requirement.

Reason for change:Customer requirement.

2 Rate forecasting

ALM 8.x behavior

The ALM Income Simulation time bucket is used as the forward period for forecasting interest rates, currency exchange rates, and economic indicators.

ALM Cloud Service behavior

Forecast rates are calculated at monthly intervals for up to 30 years, or 360 forward months.

Reason for change

De-link forecast rates from ALM time buckets so that other cash-flow users can consume the rates.
Improve forecast consistency by avoiding complexity caused by multiple time buckets.

3 Compounding basis

ALM 8.x behavior

Compounding basis values Simple (160), At Maturity (200), and Other (999) behave the same way; no compounding occurs.

ALM Cloud Service behavior

At Maturity (200) and Other (999) are discontinued. Simple (160) covers the no-compounding behavior.

Reason for change: At Maturity (200) and Other (999) duplicate the Simple Interest behavior.

4 Accrual basis

ALM Cloud Service standardizes accrual-basis behavior for Actual/Actual calculations, periods expressed in days, holiday adjusted payment dates, and reprice-date interest calculations.

4.1Actual/Actual

ALM 8.x behavior

The denominator is derived from the calculated payment date.
Payment Date = Last Payment Date + Payment Frequency.
The calculated payment date is reduced by one day. If that day falls in a leap year, the denominator is 366; otherwise, it is 365.
Example: Last Payment Date 1-Dec-2015 and Payment Frequency 31D result in a calculated payment date of 1-Jan-2016. Since the prior day is 31-Dec-2015, interest is calculated as 31/365.
Example: Last Payment Date 28-Mar-2015 and Payment Frequency 1Y result in a calculated payment date of 28-Mar-2016. Since the prior day is 27-Mar-2016, interest is calculated as 366/366.
Example: Origination Date 30-Sep-2015 and Payment Frequency 6M result in a first payment date of 31-Mar-2016. The denominator is 366 for Actual/Actual.

ALM Cloud Service behavior

Actual/Actual (Euro) is used. The denominator is 365 when the calculation period does not include February 29 and 366 when the period includes February 29.

Reason for change:Align with industry practice and make usage consistent.

4.2 Accrual basis for periods in days

ALM 8.x behavior

When interest is calculated for a period expressed in days, 30/360 is converted to Actual/365.
30/365 is converted to (Actual/365) * (360/365).
30/Actual is converted to (Actual/365) * (360/Actual).

ALM Cloud Service behavior

If Payment Frequency is Days and Accrual Basis is 30/360, use Actual/360.
If Payment Frequency is Days and Accrual Basis is 30/365, use Actual/365.
If Payment Frequency is Days and Accrual Basis is 30/Actual, use Actual/Actual.

Reason for change

Keep the denominator consistent with the original accrual basis even when the numerator changes from 30 to the actual number of days.
Example for 25-Mar-2018 to 10-Apr-2018, 16 days, and 5% annual interest: 30/360 changes from 0.00219178 to 0.00222222; 30/365 changes from 0.00216176 to 0.00219178; 30/A changes from 0.00216176 to 0.00219178.

4.3 Holiday calendar and accrual basis

ALM 8.x behavior

When holiday-adjusted payment dates are used for interest cash-flow calculation, records with accrual basis 30/360, 30/365, or 30/Actual are converted into Actual/365-based logic.

ALM Cloud Service behavior

When holiday-adjusted payment dates are used for interest cash-flow calculation, the instrument accrual basis is used.

Reason for change: Bring uniformity to CFE logic and avoid unnecessary complexity.

4.4 Interest amount on reprice date

ALM 8.x behavior

If ACCRUALBASISCD_FLAG in SETUP_MASTER is N, the engine calculates interest for the reprice event by number of days and divides by 365.
If ACCRUALBASISCD_FLAG in SETUP_MASTER is Y, the engine calculates interest by number of days and uses the denominator from the provided accrual-basis code.
If ACCRUAL_BASIS_CD is 1 (30/360) or 2 (Act/360), the denominator is 360.
If ACCRUAL_BASIS_CD is 3 (Act/Act) or 5 (Act/Act), the denominator is the actual number of days in the year.
If ACCRUAL_BASIS_CD is 4 (30/365) or 6 (Act/365), the denominator is 365.

ALM Cloud Service behavior

The instrument accrual basis is always used for calculations.

Reason for change

The previous logic supported net and gross interest-rate calculation for reprice-only events.
The new engine stores accrued interest for broken periods separately, including periods caused by reprice or another event.
The updated behavior makes CFE calculations consistent.

5 Usage of accrued interest

ALM 8.x behavior

Accrued Interest (AI), both gross and net, represents interest due from the last payment date to the as-of date. ALM 8.x uses AI for non-maturity behavior patterns, multiple-reprice instruments, and annuity instruments. In those cases, if AI is available, CFE calculates interest from the as-of date to the next payment date; otherwise, it calculates from the last payment date to the next payment date. AI is ignored for other cases.

ALM Cloud Service behavior

Subject to the preference set at product-currency level in the process, when AI is supplied, CFE calculates interest from the as-of date onward regardless of amortization type or adjustable type. When AI is not supplied, calculation starts from the last payment date and assumes that the current interest rate applies from the last payment date to the as-of date. This behavior applies only when the calculation date range is As of Date to Maturity or As of Date to Next Reprice Date.

Reason for change

Most core banking source systems accrue interest daily, and AI is usually available with account data.
Other OFSAA applications, including Basel and LRM, use provided AI for Exposure at Default and other calculations.
Using supplied AI improves calculation accuracy, especially for adjustable-rate instruments.
The change makes calculation logic uniform.

6 Usage of the 30.412 factor

ALM 8.x behavior

Values 30.412, 30.42, and 30.41667 are used in multiple places to convert months to days and days to months.
Prepayment logic uses the 30.412 divisor in multiple formulas.

ALM Cloud Service behavior

One month is treated as 30.41667 days, or 365/12, in all day-month conversions.

Reason for change

Bring uniformity to calculation logic. Examples from ALM 8.x Original Term_months = ROUND(Original Term_days / 30.412) Reprice Frequency_months = ROUND(Reprice Frequency_days / 30.412) Remaining Term = ROUND((Maturity Date - Current Date) / 30.412)
30.41667 is used to derive the remaining number of payments for balloon instruments.
30.42 is used to convert months to days and days to months in compounding logic. • The factor is also used during rate lookup and forecasting.

7 Interest credit and capitalized interest

ALM 8.x behavior

Interest credited is available for non-amortizing instruments. Instead of being paid, the interest amount is added back to principal. Accumulated interest and principal are paid at maturity.
Negative principal runoff is shown on all payment dates before maturity. This represents capitalized interest.
Positive interest runoff is shown on all payment dates through maturity. This represents interest for the payment period.
The functionality is supported only for non-amortizing instruments.

ALM Cloud Service behavior

Only one principal runoff is shown on maturity date. The amount includes principal plus accumulated interest.
No interest runoff is shown because all interest is capitalized and becomes part of the principal cash flow.
Three new instrument-level output measures are produced: accumulated net interest, accumulated gross interest, and interest credited.
The functionality is supported for non-amortizing instruments and non-maturity behavior patterns.

Reason for change: Remove ambiguity in results and improve auditability.

8 Payment schedule

8.1 Usage of current payment amount

ALM 8.x behavior

When Amortization Type is Conventional Schedule or Level Principal Schedule, current and original payment amounts provided at account level are used for the first payment, or Next Payment Date.
The amount in the schedule is not used for the first payment.
After the first payment date, the amount from the schedule is used.
This requires the schedule amount to be updated to the account record whenever a payment date passes.

ALM Cloud Service behavior

When cash flow must be generated using a payment schedule, current and original payment amounts at account level are ignored. Only amounts provided in the schedule are used for cash-flow calculation.

Reason for change

When amounts are provided in the schedule, requiring separate account-level current and original payment amounts is not useful.
Schedules are usually used for staggered or step-up/down payments where amounts change over time.
Requiring current payment amount increases ETL burden because ETL must supply the correct amount whenever data is loaded.

8.2 Remaining number of payments

ALM 8.x behavior

When Amortization Type is Schedule, Remaining Number of Payments at account level is expected to equal the count of payment dates in the schedule after the as-of date.
If the account-level value does not match the count of future payment dates in the schedule, the engine calculates incorrect cash flows using the first payment date from the schedule.
If Remaining Number of Payments is not supplied at account level, the record is skipped and not processed.

ALM Cloud Service behavior

The Remaining Number of Payments requirement is removed when a payment schedule is supplied. The dates in the schedule are assumed to be correct.

Reason for change

Schedules are used for staggered or step-up/down payments where both amount and frequency can change.
Payment dates in the schedule can be treated as the correct representation of expected cash flows.
The maturity date on the instrument record is ignored. The final date in the schedule is treated as the maturity date.

8.3 Holiday calendar for payment schedules

ALM 8.x behavior

Payment dates provided in the payment schedule are expected to be holiday-adjusted dates.

ALM Cloud Service behavior

Holiday calendar support is available for payment schedules. Payment dates in the schedule do not need to be holiday adjusted.

Reason for change

Customer demand.
Bring uniformity to CFE logic.

9 Amortization type

9.1 Payment and behavior pattern

ALM 8.x behavior

Payment Pattern (PP) and Behavior Pattern (BP) are selected by assigning Amortization Type Codes (AMRT_TYPE_CD) at instrument level.
Codes 1000-69999 represent user-defined payment patterns.
Codes 70000-99999 represent user-defined behavior patterns.
A maximum of 69,000 payment patterns can be defined.
A maximum of 30,000 behavior patterns can be defined.

ALM Cloud Service behavior

The limit on the number of payment and behavior patterns is removed.
Amortization Type Code 20 identifies user-defined payment patterns.
Amortization Type Code 10 identifies user-defined behavior patterns.
Instrument tables include PMT_PATTERN_CD and BEHAVIOR_PATTERN_CD to store the actual payment or behavior code.
When CFE sees Amortization Type Code 10 or 20, it uses the corresponding pattern-code attribute and metadata lookup to generate cash flows.

Reason for change: Remove constraints on the number of payment patterns and behavior patterns that can be used.

9.2 Conventional amortization

ALM 8.x behavior

The Cash Flow Engine does not treat Conventional Fixed (100), Balloon (400), or Conventional Adjustable (500) differently. For a given record, any of these types produces identical results.
The code division is used for product distinction only. For example, Amortization Type 100 can be used for a fixed-rate, adjustable-rate, or balloon record.
CFE does not use Amortization Type to identify whether a record is adjustable. FTP uses Reprice Frequency, and ALM uses Adjustable Type.
CFE does not use Amortization Type to identify whether a record is a balloon. It uses Amortization Term and Original Term.

ALM Cloud Service behavior

Conventional Adjustable (500) is discontinued. Use Conventional (100) for both fixed-rate and adjustable-rate records.
Balloon (400) is still recognized but is treated the same as Conventional (100).
If Amortization Term is greater than Original Term, the instrument is treated as a balloon instrument.

Reason for change: Rationalize code values.

10 Holiday calendar

10.1 Multiple payment events on the same day

ALM 8.x behavior

Holiday calendar adjustments are not supported for instruments with payment frequency less than five days.
When a holiday calendar is associated with an instrument, multiple payments can roll into the same working day.
The ALM 8.x engine cannot handle multiple payment events on one date.

ALM Cloud Service behavior

The engine handles multiple payment events on the same day. When a cash flow rolls to a date that already has an event, both events are shown in the detailed cash-flow result.

Reason for change

Customer demand.
Bring uniformity to CFE logic.

11 Prepayment and early redemption

11.1 Holiday calendar calculation

ALM 8.x behavior

A prepayment factor adjustment is used for stub or extended payments.
The formula is: Prepayment Factor * (Next Payment Date - Last Payment Date) / (Payment Frequency in days).
Payment Frequency in days is calculated as Next Payment Date - Calculated Last Payment Date.
When the payment date is holiday adjusted using Recalculate, Calculated Last Payment Date is derived by rolling forward the origination date by payment frequency until it reaches the date immediately before the next payment date.
When the holiday calendar is not used or is shift-only, Calculated Last Payment Date is derived by rolling back the next payment date by payment frequency.

ALM Cloud Service behavior

Calculated Last Payment Date is derived by rolling back the next payment date by payment frequency, regardless of whether the dates are holiday adjusted.
Example: If Last Payment Date is 10-May-2015, Next Payment Date is 25-Jun-2015, and Payment Frequency is 1 month, the adjustment factor is (25-Jun-2015 minus 10-May-2015) / (25-Jun-2015 minus 25-May-2015).
In the example, 25-May-2015 is the Calculated Last Payment Date because it is 25-Jun-2015 rolled back by one month.

Reason for change

Bring uniformity to prepayment calculation logic.
Make Calculated Last Payment Date consistent with interest amount calculation.
Address Bug 29490951: Incorrect payment calculation (FE 180) with holiday calendar where the cash-flow date is holiday adjusted.

11.2 Options in Use Payment Dates

ALM 8.x behavior

When Use Payment Dates is selected, prepayment or early redemption amount is calculated on both interest and principal payment dates. For non-amortizing instruments, a prepayment can occur when only interest was due.

ALM Cloud Service behavior

When Use Payment Dates is selected, users can specify the dates on which prepayment or early redemption occurs.
Options are: both principal and interest payment dates; only principal payment dates; only interest payment dates.

Reason for change: Provide more flexibility, especially when principal and interest payment frequencies or dates are different.

11.3 Early redemption support for user-defined tenor

ALM 8.x behavior

Prepayment on user-defined tenor applies when Amortization Type is Simple Interest (700), Conventional Fixed (100), Conventional Adjustable (500), Level Principal (820), or Payment Schedule.
Early Redemption on user-defined tenor applies only when Amortization Type is Simple Interest (700).

ALM Cloud Service behavior

Both prepayment and early redemption on user-defined tenor apply when Amortization Type is Simple Interest (700), Conventional Fixed (100), Conventional Adjustable (500), Level Principal (820), or Payment Schedule.

Reason for change

Provide more flexibility when early redemption is used.
Align prepayment and early-redemption logic.

11.4 Transfer pricing: prepayment on user-defined tenor

ALM 8.x behavior

Prepayment or early redemption on user-defined tenor using the Constant method is not used for Transfer Pricing.

ALM Cloud Service behavior

Prepayment or early redemption on user-defined tenor using the Constant method is used to generate cash flows for all end uses.

Reason for change: Customer requirement.

11.5 Prepayment runoff on maturity date

ALM 8.x behavior

Prepayment runoff is calculated on maturity date when Use Payment Dates is selected.

ALM Cloud Service behavior

Prepayment runoff is not calculated on maturity date.

Reason for change

On maturity date, all remaining balance is paid as maturity runoff. Functionally, there cannot be prepayment on maturity date.

12 Behavior pattern

12.1 Development and recovery

ALM 8.x behavior

Interest amount is not calculated.
Instrument maturity date is ignored when development runoff is generated.
Recovery amount can be higher than the amount that has been devolved.

ALM Cloud Service behavior

Interest amount is calculated using the instrument payment dates and frequency, as with non-maturity behavior patterns.
Previously devolved amount is used in runoff and recovery calculations.
Development runoff date cannot exceed the account maturity date.
Recovery runoff cannot exceed the amount that has been devolved.

Reason for change

Development and Recovery behavior patterns are used for products such as letters of credit and bank guarantees.
Banks charge interest when the recovery period extends beyond the contract expiry date.
A letter of credit has an expiry date after which the customer cannot use the amount.
Principal recovery should not exceed the amount paid to the customer.

13 Payment pattern

13.1 Rollover of End-of-Month date

ALM 8.x behavior

If a cash-flow date is 30-Jun-2019 and the next cash-flow tenor in the payment pattern is one month, the next cash-flow date is derived as 30-Jul-2019 instead of 31-Jul-2019.

ALM Cloud Service behavior

When n months or years are added to an End-of-Month (EOM) date, the resulting date is also EOM.

Reason for change

The updated logic is already used in the old engine for normal amortization types.
Make CFE logic consistent.

13.2 Payment pattern with holiday recalculation

ALM 8.x behavior

When a cash-flow date shifts to the previous or next business day and the calculation option is Recalculation, following cash flow dates are derived using the previous holiday-adjusted date as the reference.

Table 11-2 Holiday Recalculation

Recalculation	Tenor	Day/Month	Original Dates	Dates-without holiday	Dates-with holiday
Previous business day	-	-	08-Jul-15	-	-
	30	D	07-Aug-15	-	-
	30	D	06-Sep-15	-	-
	30	D	06-Oct-15	-	-
AOD: 09-Oct-2015	30	D	05-Nov-15	21-Nov-15	20-Nov-15
	30	D	05-Dec-15	21-Dec-15	18-Dec-15
	1	M	05-Jan-16	21-Jan-16	18-Jan-16
	1	M	05-Feb-16	21-Feb-16	18-Feb-16
	1	M	05-Mar-16	21-Mar-16	18-Mar-16
	1	M	05-Apr-16	21-Apr-16	18-Apr-16
	1	M	05-May-16	21-May-16	18-May-16

Example: 21-Dec-2015 is a holiday and changes to the previous business day, 18-Dec-2015. Subsequent cash-flow dates fall on the 18th of the month instead of the original 21st.

ALM Cloud Service behavior

The original starting date, or next payment date, remains the reference for all cash-flow dates.
In the example, actual cash-flow dates are 20-Nov-2015, 18-Dec-2015, 21-Jan-2016, 21-Feb-2016, 21-Mar-2016, 21-Apr 2016, and 21-May-2016.

Reason for change

The updated logic applies to all CFE areas, including cases where a payment pattern is not used.
Make CFE logic consistent.

13.3 Split payment pattern

ALM 8.x behavior

When a split payment pattern is used, FTP and ALM results differ.
Detailed cash flow in ALM is generated for each split separately.
Detailed cash flow in FTP is aggregated across splits. If payment dates differ across splits, aggregation produces incorrect results.

ALM Cloud Service behavior

Each split can have different payment dates. This is a valid business case.
CFE produces cash flows separately for each split.
Split ID is a new attribute in cash-flow output.

Reason for change

Correct errors in cash-flow generation.
Transfer pricing is calculated separately for each split because measures such as duration and average life can differ. A single transfer rate can then be calculated for the instrument.

14 Mortgage offset account

14.1 Expected balance

ALM 8.x behavior

Expected offset balance is calculated on every payment date.
The current formula assumes that payment frequency is always expressed in months.

ALM Cloud Service behavior

Expected balance is calculated using accrual start and end dates so that day- and year-based payment frequencies are supported.

Reason for change

Payment frequency can be expressed in days, months, or years.
The next-generation CFE supports separate principal and interest frequency. •
If principal and interest payment dates differ, expected offset balance must be derived on principal payment dates to accrue interest for a broken period.
The old formula can produce incorrect output when a beginning or ending stub period exists, or when a schedule or absolute payment pattern is used.

Formula changes

ALM 8.x: Expected Offset Balance_previous * [1 + ((Growth Percentage / 100) * (Payment Frequency in months / 12))]

ALM Cloud Service: Expected Offset Balance_previous * [1 + ((Growth Percentage / 100) * ((Accrual End Date - Accrual Start Date) / 365))]

15 Maturity date prior to as-of date

ALM 8.x behavior

For non-schedule instruments, when Maturity Date is less than or equal to the as-of date, the instrument is not processed.
For schedule instruments, the highest payment date is treated as the maturity date and the maturity date on the instrument is ignored.
When all schedule dates are before the as-of date, the instrument is not processed in ALM or FTP remaining term, but it is processed in FTP standard term.

ALM Cloud Service behavior

If Current Balance is greater than zero and Maturity Date is less than or equal to the as-of date, Maturity Date is set to As-of Date + 1.
If Current Balance is zero, Maturity Date is less than or equal to the as-of date, and the calculation date range is Origination to Maturity or Last to Next Reprice Date, CFE generates cash flows using Original Balance or Last Reprice Date (LRD) Balance.

Reason for change

The old treatment creates inconsistency between schedule and non-schedule instruments.
If current balance is not zero, ignoring the instrument can cause reconciliation issues.
Some instruments originate and mature in the same month. Transfer Pricing customers may need to generate transfer rates for these cases using the standard-term method.

16 Origination-to-maturity cash flow on origination date

This difference applies to fixed-rate instruments with interest in advance.

ALM 8.x behavior

When interest timing type is Advance, CFE generates cash flow on the origination date for Simple Interest (700) and Level Principal (820).
For Payment Schedule and Payment Pattern, CFE expects the origination-date payment to be explicitly supplied or configured.
If the payment is not explicitly supplied or configured, interest for the period from Origination Date to the first payment date in the schedule or pattern is not generated.

ALM Cloud Service behavior

For Payment Schedule and Payment Pattern, CFE generates cash flow on the origination date even when the origination date payment is not explicitly provided.

Reason for change: Bring consistency to CFE across all amortization types.

17 Transfer Pricing duration: interest cash flow on reprice date

ALM 8.x behavior

When cash flow is calculated for Transfer Pricing, interest cash flow FE 430 is not calculated on a reprice-only event. On that event, only reprice balance is used to calculate duration. On other days, both interest and principal cash flow are used.

ALM Cloud Service behavior

Interest for the broken time period on the next reprice date is calculated and used for market value and duration calculations.

Reason for change: Make CFE logic consistent.

18 Cash flow of residual account types

ALM 8.x behavior

When account type is other asset/liability, non-interest income/expense, or unallocated interest income/expense, only one cash flow is calculated on maturity date.
The cash flow equals current balance.
Interest is not calculated.
Non-interest income and expense are reported under FE 430 and FE 435 in the process cash-flow table even though they are not interest cash flows.

ALM Cloud Service behavior

Level Principal (820), Simple Interest (700), and behavior patterns can be used to amortize balances for these account types.
New output measures for non-interest income and expense, FE 455 and FE 457, are reported at instrument level.

Reason for change

Customer demand
Bugs 28237682 and 24960945

19 Interest rate option

19.1 Sign of interest cash flow

ALM 8.x behavior

When Leg Type is 1 (Pay), interest cash flow has a negative sign.
Market value also becomes negative, which can create issues in BI reports.

ALM Cloud Service behavior

Interest cash flow is positive. Leg Type is used to identify inflow or outflow.

Reason for change

ER 25413593: SELL Cap Floor populated with negative sign.
BI uses account type and Leg Type to classify numbers as inflow or outflow, so a negative sign is not required.

19.2 Amortizing interest rate option

ALM 8.x behavior

The engine supports Amortization Type 700 (Simple Interest).
If Amortization Type of Cap/Floor is 820, the engine treats it as 700 and does not log a message.
If Amortization Type of Cap/Floor is 100 or 500, the engine does not treat it as Cap/Floor. Instead, the instrument amortizes like a loan, and no message is logged.

ALM Cloud Service behavior

In addition to Simple Interest (700), Level Principal (820) can be used for interest rate options.

Reason for change

Customer requirement.
ER 25808098: Cash flows for amortizing interest rate options - Cap/Floor.

20 Repricing

20.1 Interest rate on repricing

ALM 8.x behavior

Forecasted interest rate assigned to an instrument on repricing is derived from the time bucket in which the reprice date falls.
The same rate is applied to all reprice events within the bucket.
This applies to instruments with Adjustable Types Other Adjustable and Repricing Pattern (Indexed).

ALM Cloud Service behavior

Linear interpolation is performed on the reprice date when the date falls between the beginning and ending monthly forecast periods.
The interpolation produces a unique interest rate for a reprice date.
This applies to instruments with Other Adjustable and Repricing Pattern (Indexed) adjustable types.
For floating-rate instruments, interpolation is not performed. The forecasted rate of the relevant forward month is used directly.

Reason for change

Customer requirement
Improve calculation accuracy. Using one rate for all reprice events within a bucket reduces accuracy when the bucket spans multiple months.

20.2 Floating rate - reprice date

ALM 8.x behavior

Repricing of floating-rate instruments, Adjustable Type 50, is shown on Income Simulation bucket start dates.
This behavior occurs regardless of whether the IRC interest rate changed.
If Teaser End Date is greater than the as-of date, repricing occurs on Income Simulation bucket start dates after Teaser End Date.

ALM Cloud Service behavior

The first reprice occurs on As-of Date + 1 day. Subsequent reprices occur at one-month intervals through 360 months.
If Teaser End Date is greater than the as-of date, the first reprice occurs on Teaser End Date. Subsequent reprices follow forward-term start dates at monthly intervals.

Reason for change

Teaser End Date was previously ignored.
Rate forecasting replaces the time-bucket model with 360 forward months.

20.3 Repricing pattern - blended rate

ALM 8.x behavior

When Reprice Method is Flat and Balance Tier is defined, a weighted interest rate is used to calculate cash flow.
For Flat repricing with Balance Tier, Fully Indexed Gross Rate (FE 320) and Fully Indexed Net Rate (FE 330) are calculated even though IRC is not used to determine interest rate.
When Reprice Method is Indexed and Balance Tier is defined, IRC, IRC Term, and Rate Set Lag are taken from Balance Tier, but Weighted Margin, Rate Cap Life, and Rate Floor Life are used.
When processed with Model with Gross Rate and Net Margin Code is Fixed Net Rate, FE 120, FE 430, and related financial elements are incorrect. This is a known bug.

ALM Cloud Service behavior

When Reprice Method is Flat and Balance Tier is defined, the interest rate of the balance tier applicable to the account is used. The applicable tier is determined by Current Balance within the defined balance range.
For Flat repricing, FE 320 and FE 330 are not produced because interest rate is not linked to IRC.
When Reprice Method is Indexed and Balance Tier is defined, margin, rate cap life, and rate floor life from the relevant balance tier are used instead of weighted values.

Reason for change

For Flat repricing with Balance Tier, weighted-rate requirements can be met through Adjustable Type 300, Tiered Balance Interest Rate. This allows one account to have multiple interest rates in any combination of fixed and adjustable tiers.
Fully Indexed Gross Rate and Fully Indexed Net Rate are not relevant when interest rate is not linked to IRC. Related financial elements such as periodic cap effect rate and life cap effect rate are also not relevant. •
For Indexed repricing with Balance Tier, the change improves logic consistency. Adjustable Type 300 can assign multiple IRC and related attributes to a single account.
Correction of Bug 31309765.

20.4 Repricing balance - interest in advance

ALM 8.x behavior

For Level Principal, other adjustable rate, interest-in-advance instruments, repricing balance equals beginning principal balance.
Interest is calculated on the balance after principal payment and prepayment.
If payment and reprice occur on the same day, repriced interest is effectively applied to the lower balance, but FE 250 shows beginning balance before principal payment and prepayment. The same behavior applies to Period Cap Balance and Life Cap Balance.

ALM Cloud Service behavior

For these instruments, Repricing Balance equals Ending Principal Balance.

Reason for change

If payment and reprice occur on the same day, repriced interest effectively applies to the lower balance.
Interest is calculated on the balance after principal payment and prepayment.

20.5 Multiple reprice instruments

ALM 8.x behavior

Many conditions are checked to identify a multiple-reprice instrument, and calculation follows a separate code flow.

ALM Cloud Service behavior

A multiple-reprice instrument is not specifically identified. The event type, such as reprice, payment, or another event, determines the calculation. On a reprice-only event, CFE calculates interest and accrues it until the next payment event.

Reason for change

Conditions used to identify multiple-reprice instruments are complex and can lead to errors.
Bring uniformity to calculation logic.
Improve auditability.

21 Negative amortization

21.1 Discontinue FE650 negative amortization interest

ALM 8.x behavior

FE 650, Negative Amortization Interest, is calculated for negative amortization instruments.

ALM Cloud Service behavior

FE 650, Negative Amortization Interest, is not calculated.

Reason for change

The measure does not have a functional use.

22 Pay equivalent compounding convention

ALM 8.x behavior

In most cases, interest rates are not adjusted for pay-basis differences between the pricing-index quote basis and the payment frequency of the account assigned to the index.
Some instruments, including Canadian mortgages, use a convention where interest rates are adjusted. In that case, Pay Equivalent Compounding Convention should be set to Semi-Annual Quoting Convention.
For other accounts, the convention should be set to Do Not Adjust.
The attribute is defined in ALM Product Characteristics at product-currency level.

ALM Cloud Service behavior

The attribute is expected at instrument level rather than product-currency level.

Reason for change

If applicable, the quoting convention is always used for an instrument. Portfolio-level preference is not required for current business.