Sunteți pe pagina 1din 4

Understanding Interest Options

Interest accrual options :


INT NXT STMT on ARMR02

N - Do not charge interest Y - Charge interest D - Defer interest if payment made prior to statement G - Accrue and defer interest on new transactions A - Waive all interest based on account balance R - Accrue and defer interest on all new transactions in current cycle P - Waive all interest based on plan balance

Computing interest :

ACCRUAL METHOD on ARMR02

The Interest table (ARMR) contains the parameters for the actual calculation of interest. Four accrual methods are provided for CMS to use in interest calculations ( ACCRUAL METHOD on ARMR02). Interest can be computed: Daily (D) Monthly (A) Monthly ending (E) Balance at end of cycle (B). When interest is computed daily (option D), CMS updates both the aggregate balance and the accrued interest for the plan segment each processing run. On statement date, CMS bills the amount of accrued interest to the account. If interest is computed monthly (options A or E), CMS calculates interest on the statement date and no interest accrues for the plan segment. The aggregate balance and the accrual of interest are not based on the balance of the account. Instead, they are computed based on the balance subject to finance charge for the account. CMS computes this amount using the parameters defined on the Interest table. The current balance of a plan segment is composed of a principal balance plus any interest and fees that were billed to the account and not paid. The Interest table uses a series of switches to define which balance components are used to compute interest. CMS uses the principal balance of the plan segment and adds the amount of any components that do allow interest. If interest is computed on the balance at the end of the cycle (option B), CMS uses the account balance subject to finance charge that is calculated from the Interest table ( INT ON fields on ARMR02). CMS calculates interest on the balance at cycle, using the current interest rate in force on the accounts cycle day. CMS does not take into account any rate changes made during the cycle. The year base must be 360 fixed days ( YEAR BASE on ARMR02 is 2). In addition, interest calculations for debits and credits must begin on the posting date of the transaction (INT START DB and INT START CR on ARMR02 is P) to prevent backdating. CMS uses another parameter on the Interest table, INT START DB, to calculate the balance subject to finance charges. This field defines whether interest on debits is computed from the effective date of the transaction, from the date the transaction is posted, or from the date the transaction is billed. If this option is set to wait until a transaction is billed prior to using for finance charge calculations, CMS reduces the balance subject to finance charges by the amount of purchases made this cycle (current month debits in the plan segment). CMS reduces the balance subject to finance charges anytime a disputed amount exists for the plan segment. A control record parameter does not determine the usage of disputes, since this is regulated. If any amount is disputed, CMS always reduces the balance subject to finance charges by the amount in dispute. Each processing day, CMS uses the parameters mentioned above to compute the balance subject to finance charge (BSFC) for that processing run. If interest is computed monthly, the balance subject to finance charge is added to the aggregate balance of the plan

segment. If interest is computed daily, the balance subject to finance charge is added to the aggregate balance, the interest accrual for the processing run is computed, and the daily accrual is added to accrued interest for the plan segment. When using daily interest, on the statement date CMS bills the amount of interest that was already computed and added to accrued interest. When using monthly interest, CMS computes the amount of interest on the statement date and bills on the same processing run. The system computes interest by calculating an average daily balance subject to finance charge. This is computed by dividing the aggregate balance from the plan segment by the number of aggregate days stored on the Account Base Segment record. If the monthly ending option (accrual method E) is used for interest, the system computes the interest for the cycle on statement day by taking the beginning principal balance and subtracting any cycle-to-date debits. CMS assumes that this result is the average balance When you manually compute daily finance charges for verification, you normally take the balance subject to finance charge, multiply it by the interest rate, divide by the year base, and multiply it by the number of days in the cycle.

Pre-interest and post-interest processing

The CMS Posting program actually executes logic for accruing interest twice. The Preinterest routine is executed prior to posting todays monetary activity. Generally this logic is used when nonprocessing days have occurred as a result of call-cycle billing or month CMS end. This also happens when processing days are skipped because the dates are bumped as is often done in testing. An example of this is when an organization does not process seven days a week. Assume, for example, that Saturday and Sunday are nonprocessing days, and Saturday is month-end. On Friday an account is accrued through Saturday. The pre-interest calculations are executed on Mondays processing run to bring the account current through Sunday prior to posting new activity. In this case, Mondays accruals and aggregates in pre-interest are calculated using the balance of the account as of the last processing run. After pre-interest processing, CMS posts the monetary transactions for today and then performs the post-interest calculations. The balance used for this calculation is the balance after all monetary transactions for the current run. This routine also accrues interest for as many days as needed up to the next processing run. If month-end does not occur during the weekend, the account is accrued through Sunday during Fridays processing, so the aggregate and accrual are updated for three days.

Backdating interest

CMS executes a routine to compute backdated interest when the effective date of the transaction being posted is less than the current processing date and the interest start flag for the transaction is set to effective date. The Interest table contains separate interest start flags for debits and credits, so the values could be different for each. Therefore, CMS can backdate interest for some transactions but not for others. Debit logic modules use the INT START DB flag and credit logic modules use the INT START CR flag. The only exception to this is a payment reversal. Even though payment reversals are debit logic modules, their control for backdating is based on the INT START CR flag. If CMS determines that interest should be backdated, it performs calculations based on how far back the transaction is backdated. If the effective date of the transaction is within the current cycle (less than todays date but greater than the DATE LAST STATEMENT for the account), CMS adjusts current cycle aggregates and, if interest is computed daily, current cycle accruals. If the transaction is backdated into a prior cycle period (the effective date of the transaction is less than the DATE LAST STATEMENT for the account), CMS executes two separate calculations, one for prior cycle and one for current cycle. When adjusting backdated interest for a prior cycle period, CMS generates Interest Adjustment monetary transactions to post to the account. When adjusting for current cycle, the system only updates the aggregates and accruals. Backdate logic for interest is performed as each transaction is posted. If three transactions

post in the same run that all require backdating of interest, the backdate interest routine is executed three times. When CMS executes backdate logic, it computes the adjustments needed through yesterday. Aggregates and accruals for today are completed in the postinterest routine after all transactions are posted.

Deferred interest processing

(* The following discussion does not apply when a value of 4 is entered in the fourth part of the DEFER INT field on the Credit Plan Master screen (ARMC01). When this condition occurs, interest is not calculated, stored, or reported on the balance during the deferral period.) The actual calculation of interest for plan segments with deferred interest is the same as detailed above; however, once computed, CMS handles the interest differently. With normal interest, the computed interest is added to the balance of the account on cycle day. With deferred interest, the computed interest is held and stored (in plan segment deferred interest) until the segment reaches the date to begin interest. Even if the plan segment has deferred interest, the calculations up to the point of interest assessment (generating the monetary transaction to add to the balance) are the same as those for normal interest. If interest is daily, it is accrued throughout the cycle. If interest is monthly, it is calculated on cycle date using the average daily balance. Once CMS knows the amount of interest for the cycle, instead of adding it to the account, CMS adds the amount of interest to the plan segment deferred interest field. A nonmonetary Activity Recap transaction is generated for the amount of deferred interest. CMS also updates the DEF-AGG-NBR-STMTS and DEF-AGG-ADB in the plan segment each cycle the account is in deferment. The number field is increased by one each cycle if the segment uses monthly interest. The number field is also increased by the number of aggregate days (from the Account Base Segment) each cycle if daily interest is used. The AGGREGATE/ADB field is increased by the average daily balance of the account each cycle if monthly interest is used. This field is also increased by the plan segment aggregate balance for the cycle if daily interest is used. These fields are provided for statement disclosure, if needed, at the end of the deferment period to reconcile the total deferred interest that is assessed as a single transaction. Each cycle the account is in deferment, CMS continues this process. The computed interest is accumulated in the deferred interest field on the plan segment and the deferred number of statements and DEFERRED AGGR/ADB is updated. The difference in interest processing occurs when the plan segment expires. Interest deferment for a plan segment can expire because the date to begin interest is today as a result of cancellation for delinquency or cancellation by block code. Interest can also be deferred by days, by cycles, or to a specific date (defined on the Credit Plan Master). When cycle deferment is used, the normal expiration occurs on a cycle date. This creates a clean cutoff for deferred interest since all of the interest for a cycle is either normal interest or deferred interest. When interest deferment is defined as days or to a specific date, or if interest deferment is canceled for an exception reason, the plan segment has a mid-cycle expiration. This does not mean that it will occur exactly in the middle of the cycle, just that it will occur on any day during the cycle period. When a mid-cycle expiration occurs for interest, CMS performs special logic for handling deferred interest. In this situation, CMS records a portion of the cycles interest as deferred interest and a portion as normal interest. Example: Assume an account last cycled on 08/31 and the date to begin interest is 09/15. The interest from 09/01 through 09/14 is interest that occurred during the deferral period. The interest from 09/15 through the next cycle date is regular (normal) interest. For a mid-cycle deferment, CMS must update fields related to deferment on a day other than cycle date. If the account uses daily interest, CMS: Adds the amount of accrued interest to deferred interest and zeros the accrued interest field Adds the plan aggregate balance to the deferred aggregate balance and zeros the plan aggregate balance field

Adds the aggregate days to the deferred aggregate days (it does not reset the aggregate days in the Account Base Segment). For a mid-cycle deferment for a monthly interest plan segment, CMS: Computes the amount of finance charge for the aggregate balance and divides the plan aggregate balance by the Account Base Segment aggregate days to calculate the average daily balance up to this point. CMS uses a daily interest routine to compute finance charges on the average daily balance for the number of days in the aggregate days field. The computed amount of finance charges are added to the plan segment deferred interest field. Adds the computed average daily balance (from above) to the plan segment DEFERRED AGGR/ADB field. Increases the plan segment deferred number of statements by one. Zeros the plan segment aggregate balance. At this time, CMS clears the aggregate and accrual fields and uses the accumulations for normal interest for the rest of the cycle. The total interest for the entire deferral period is in the plan segment deferred interest and is assessed to the account on cycle date. On cycle date, CMS computes interest normally. That is, for a daily interest account, the system bills the amount of accrued interest in the plan segment on cycle date as normal interest. For a monthly interest plan segment, CMS computes the average daily balance on cycle date using the plan aggregate balance divided by the Account Base Segment aggregate days. This average daily balance is used to compute the amount of normal interest. Either way, the amount of regular interest to be billed is posted as one interest transaction. The amount of deferred interest that is billed is posted as a separate transaction

S-ar putea să vă placă și