Charges

The Charge Property Class differs from other Currency Specific classes in that it includes the Currency attribute. This defaults to the currency of the record and specifies the currency in which the charge is defined and applied.

Specifying the currency in a separate attribute allows for the following capabilities:

• Charging in a currency different from that of the arrangement (that is, with charges defined in a currency which is different than the record’s currency) For example the product charges may be defined in USD, for arrangements in all currencies, but a different set of charge tariffs may be defined for contracts in different currencies but also in USD. So a GBP contract may attract a charge of 10 USD and a EUR contract may attract a charge of 20 USD.
• Default Currency charging – In this (optional currency) case a currency need not be specified in the ID of the record and the user has to set the currency attribute explicitly. Any arrangement which is in a currency for which a currency specific record has not been defined uses this default record and calculates or applies the charge in the currency specified in the currency attribute.
• The calculated charge should be converted to the arrangement currency at the prevailing mid-rate (stored on the CURRENCY table) when applied.

Charge Type can be further classified as follows:

Fixed Amount Charge

To define a fixed charge amount, user needs to set the value in the Charge Type attribute to FIXED and enter the amount of the charge in Amount. Fixed Amount attribute becomes mandatory when the value is designated as FIXED.

Calculated Charge

For a Calculated charge amount, user needs to set the value in the Charge Type attribute to CALCULATED and define the calculation in the following attributes:

Calculation Threshold

• User can specify that a charge can only be calculated if an amount threshold is surpassed. The threshold amount is of the same base type (that is, Activity Amount, Balance, Activity Count) as the base type for which the charge is being calculated and is defined in Calc Threshold
• Rounding Rule attribute - Allows the user to define the rounding rule for the calculated charge amount. The rule can be, round the charge amount either upwards or downwards or natural. Has to be a valid record in EB.ROUNDING.RULE.

Free Amount

• An amount which is deducted from the total calculated charge subject to any minimum and maximum which may be specified is defined in Free Amount.
• Handoff Charge attribute – Possible values are
  • YES - system hands over the charge amount to settlement account
  • NO or NULL continues the existing flow.

The Tier Groups attribute allows for either a single charge calculation (select NONE) or for the definition of multiple tiers of charge calculations (select BAND or LEVEL)

• Level - a product can be defined which can calculate a charge differently depending on the amount level. A single charge calculation can be selected and applied based upon the amount.
  • An example using the following tiers:

  Tier Level	Charge (in percentage)
  10,000	1
  20,000	0.75
  Above 20,000	0.50

  • A base value of 5,000 attracts a charge of 1 percentage of 5,000 = 50.00
  • A base value of 15,000 attracts a charge of .75 percentage of 15,000 = 112.50
  • A base value of 25,000 attracts a charge of .5 percentage of 25,000 = 125.00

• Band - It results in a blended charge calculation. This is similar to Level tiers, but allows for the charge calculation of each tier to be applied to the portion of the amount that falls within the tier.
  • An example using same tiers as above:

• A base value of 15,000 attracts a charge of 1 percentage of 10,000 = 100.00
• A base value of 5,000 attracts a charge of 1 percentage of 5,000 = 50.00
• Plus .75 percentage of 5,000 = 37.5 
• Total of = 137.5
• A base value of 25,000 attracts a charge of 1percentage of 10,000 = 100.00
  • Plus .75 percentage of 10,000 = 75.00
  • Plus .5 percentage of 5,000 = 25.00
  • Total of = 225.00
• Tier Groups (Bands and Levels) – it is possible to define complex tiers which are mixed groups of Bands and Levels.
• Any number of tier groups is possible. User can define these groups by using a combination of Tier Group and Calc Tier Type. Each Tier Group is treated as a high level tier, if the Tier Group is level, only the detail in Calc Tier Type from the tier group in which the base value falls can be used in the calculation. If the Tier Group is band, the detail from all tier groups that cover the base value is used in the calculation..
• The value of the tiers defined in Tier Amount within each tier group should increase, only the final tier in the final tier group should specify the remainder calculation detail.

Example

Tier Group 1

Tier Type	Tier Level	Charge (in percentage)
LEVEL	10,000	1
LEVEL	20,000	.75

Tier Group 2

Tier Type	Tier Level	Charge ( in percentage)
BAND	30,000	.25
BAND	40,000	.20
BAND	Above 40,000	.15

When the Tier Group structure is LEVEL:

• A base value of 15,000 results in a charge of .75 percentage of 15,000 = 112.50
• A base value of 25,000 results in a charge of .25 percentage of 25,000 = 62.50
• A base value of 50,000 results in a charge of .25 percentage of 30,000 = 75.00
  • Plus .20 percentage of 10,000 = 20.00
  • Plus .15 percentage of 10,000 = 15.00
  • Total = 110.00

When the Tier Group structure is BAND:

• A base value of 15,000 results in a charge of .75 percentage of 15,000 = 112.50
• A base value of 25,000 results in a charge of .75 percentage of 20,000 = 150.00
  • Plus .25 percentage of 5,000 = 12.50
  • Total = 162.50
• A base value of 50,000 results in a charge of .75 percentage of 20,000 = 150.00
  • Plus .25 percentage of 10,000 = 25.00
  • Plus .20 percentage of 10,000 = 20.00
  • Plus .15 percentage of 10,000 = 15.00
  • Total = 210.00

Temenos Transact supports the following three calculation types defined in Calc Type for each tier defined.

• Flat Charge – the user specifies an amount that is charged for the tier. This type of charge is only applicable for ‘Level’ tiers.
• Percentage Charge – a percentage of the base value can be calculated.
• Unit Charge – the base value is multiplied by the number of units.

The charge amount entered is expressed either as a flat amount, a percentage, or an amount per unit.

Related attributes are:

• Default Values (Calculation)>Tier Type>Calc Type
• Default Values (Calculation)>Tier Type>Charge>Rate
• Default Values (Calculation)>Tier Type>Charge>Amount

Charge minimums and maximums can be specified in two ways:

• Tier Level – the user can specify a minimum and/or maximum charge amount for each tier defined. These rates are defined in Tier Min Charge and Tier Max Charge.
• Overall – the user can specify overall minimum and/or maximum charges through the user of two Periodic Attributes. EB.ROUNDING.RULE to override the currency specified method.

Related Attributes are:

• Default Values (Calculation)>Tier Type>Tier>Min Charge
• Default Values (Calculation)>Tier Type>Tier>Max Charge

• Tier Amount attribute : allows the user to define the threshold amount for each tier. If more than one tier is defined then values in this attribute have to be in ascending order. This attribute is mandatory except for the last tier.
• Tier Count attribute: When charges are to be calculated based on activity count, this attribute acts as threshold for the number of times an activity is performed. Calculation based on Tier Count is linked to definition in AA.SOURCE.CALC.TYPE file. If the source balance for a charge is linked to a record in AA.SOURCE.CALC.TYPE which has the definition Source Type set to ACTIVITY and Calc Type set to COUNT, then those charges are eligible to be calculated based on activity count.
• Validation Rules
  • It is possible to specify either Tier Amount or Tier Count. Both cannot be specified simultaneously.
  • Tier Count should be defined in ascending order.
  • Last multi value of Tier Count should be blank.
• Tier Exclusive attribute - When this is set to YES, Tier Amount or Count or Term is reduced to its next least number for calculation of Tier Amount.
• Tier Term attribute - This is allowed (set as YES) only for limit managed by AA.(For Example, Accounts Product Line)
  • Refer limit can be set only for level tier type, when Refer Limit is set as YES:
    • If the transaction amount is less than the limit amount then charge amount specified in the level1 is collected.
    • If the transaction amount is greater than the limit amount then the charge amount specified in the level2 is collected.

• Refer Limit attribute - allows the user to designate a value as Day, Week, Month, or Year. The last value in the multi-value set must be null and values should be in ascending order in the multi-value set.
• Min Chg Amount attribute - allows the user to define the minimum charge amount that is compared to the system calculated charge amount. If the charge calculated is less than the minimum amount set, then based on the waive setup attribute, either the minimum charge amount is applied or waived.
• Min Chg Waive attribute - Minimum charge waive depends on the Min Chg Amount attribute value.
  • If minimum charge waive is set as YES, then if charge amount is less than minimum charge amount, charge is waived.
  • If minimum charge waive is not set then if charge amount is less than minimum charge amount then min charge amount is collected as charge.
• Cancel Period attribute - allows the user to define a period of days within which you can cancel the charge. Value in this attribute is considered as calendar days.
• Accrual Rule attribute - accepts only a valid record from EB.ACCRUAL.PARAM. Determines the amortization start and end dates while creating EB.ACCRUAL record. Input is allowed only when the charge is set to amortize.
• Internal Booking attribute – Income or expense is posted to internal account category specified in accounting condition instead of PL categories.

• Adjust Type attribute - allows the user to specify the type of adjustment being done on charge amount. Allowed values are:
  • Adjust – Adjusting the final charge amount.
  • Override – Overriding the final charge amount with a different amount.
  • Waive – Waiving the charge altogether.
• Adjust Amount attribute - allows the user to specify the discount or mark up amount that need to be applied to the calculated charge amount.
  • For example, for a debit charge, if the calculated charge amount is $100 and discount amount is specified as $25 then the final charge amount is $75 i.e. $100 - $25. For a credit charge, the final amount is $125.
  • Validation Rules
    • Allowed input only when Adjust Type is ADJUST.
    • Mutually exclusive with Adjust Percentage.
    • If the amount specified is greater than the calculated charge amount, then the entire charge is discounted.
• Adjust Percentage attribute - allows the user to specify the percentage by which the calculated charge amount is to be reduced or increased.
  • Validation Rules
    • Allowed input only when Adjust Type is ADJUST.
    • Mutually exclusive with Adjust Amount.
• Adjust Reason attribute- allows the user to specify the reason for adjustment. Must be a valid record from the AA.ADJUSTMENT.REASON virtual table.
• Adjust Expiry Date attribute - allows the user to specify the date on which any discretionary user adjustment is no longer applied, and the arrangement resumes its standard charge processing. This is a relative date, allowing to the user to an expiry such as R_START + 2Y.

The routines can be further classified as follows:

Charge Routine

• Certain types of charging are more complex than the options available. In such case, a user-defined routine can be specified to determine the charge amount.
• AA.LOCAL.CALC.CHARGE.AMOUNT routine is attached to the Charge Routine attribute to calculate the charge amount for early redemption activity. This attribute is optional and should be a valid record in EB.API.
• This API can be enhanced with different calculation methods as per the requirement of the customer. The sample calculation method to apply charge is calculated as below. Interest is calculated on the amount being withdrawn for the current period and the interest amount is levied as charge amount.
• Sample calculation method:
  • Principal Amount – 10000
  • Interest Period Start date - 1st June 2010
  • Interest Period End date - 15th June 2010
  • Current Date - 10th June 2010
  • Withdrawal Amount – 4000
  • Day basis – E
  • Interest Rate - 6%
  • Charge Amount = (4000 * 10 * 6%) / 365 = 5.47
• In this case tolerance is set in Activity Restriction then charge is calculated on base amount and not on withdrawal amount. Base amount in this case is the difference of the withdrawal amount and the tolerance percentage.
• Assuming a rule break charge with 15% tolerance for repayment is set, the base amount becomes the difference of (REPAYMENT.AMOUNT - TOLERANCE % AMOUNT) which is (4000-1500) = 2500. In our example, interest can be calculated on the base amount of 2500.
• Tolerance can be set in Activity Restriction.
• Related attribute Default Values (Calculation)>Adjustment Routine

Adjustment Routine

• This attribute enables the user to define a routine to apply adjustment logics on a calculated or fixed charge amount as required by the user. This is an optional attribute and must be a valid record in EB.API.
• New charge amount returned by this routine is considered as the final charge amount.
• The routine attached in this attribute is triggered for all charge calculation and thus if charge adjustment has to happen for specific activities, specific charge type, specific activity date then logic has to be written for those cases based on the incoming values.
• This API is invoked for New Arrangement, Issue Bill, Makedue, and Capitalise Activities for Accrual type of charge and hence the API needs to address it as such.
• If adjustment has to happen at the time of scheduled capitalisation then API should have logic to adjust the charge amount for Issuebill and Capitalise Activities.
• If it returns 0 in the NEW.CHARGE.AMOUNT when calculated during an issue bill, then it results in the bill not being raised at all.

• Where the account has been set as a Memo Account (BALANCE.TREATMENT in ACCOUNT property set to MEMO), any Charge Property in the account is treated as a Memo Charge.
• Accrual or Amortization is not be supported for these types of charges.
• It is still possible to specify capitalization or make due frequencies for such Interest.
• During Make Due processing, it triggers the settlement of such Memo charge between the settlement account and a counter booking account (please see Settlement Property class for more details)

It is possible to allow arrangement to be suspended even if interest is being capitalised. This can be achieved with the PROPERTY.TYPE>SUSPEND.

AA.CHARGE.DETAILS

• This is a central file used to maintain activity or rule based charge details for an arrangement. This file has two purposes.
  • Maintains history of charges applied for an arrangement.
  • Gives information needed for the system to raise charge bills.

• During Charge Capitalisation, if the account has insufficient funds to capitalise the charge, the pending amount is invoiced to the customer. System retries the invoiced charge automatically at regular intervals using Transaction Cycler facility
• Alt Payment Method attribute in AA Payment Type is set as CAP AND INV. This indicates that bill amount has to capitalised for the funds (based on settlement rules) and invoiced for the unrealised balance.
• For Activity Charge, Scheduled Charge, Rule Break Charge when charge is set to Capitalise and Payment Type indicates Alt Payment Method attribute as CAP AND INV, the pending amount for settlement after capitalisation is invoiced to the customer.
• Settlement Condition can be set as Full, Partial or None to indicate if account is fully debited irrespective of the balance available, partially debited for the available amount or not debited at all when full funds are not available respectively. The pending charge amount, which is invoiced, is moved to INV<CHARGE>
• Recycling conditions can be set to retry capitalising the invoiced charges using Rc Type and Rc Condition in Settlement Condition.

• Before we do the proof and publish for that product, user needs to ensure the allocation rule is configured for the below events
• Following is the list of events released from core.

• CAP.AND.INV is allowed for aging similar to other DUE Bills.
• When an Arrangement is suspended then balances are moved to INVSP.
• Balances are cleared as part of RESUME INVSP.

The AA application allows the user to calculate, apply and amortize charges which are settled by or to the customer. The Non Customer Facing Charge(NCFC) functionality allows the user to raise internal or non-customer facing charges at contract or arrangement level. However, these NCFC need to be amortised.

To define a fee or cost as a NCFC property, the charge Property Type should be set as NON CUSTOMER.

• As NCFC are internal to the bank,
  • They cannot be set to capitalise or deferred.
  • An internal account or internal PL accounting head needs to be specified in the Accounting condition of the product.
  • The type of bill raised is, Internal
• NCFC can be either made due or set as payable.
• The Internal Booking Account attribute allows the user to define the Internal Account/Account Class/PL category against which the due/pay type NCFC need to be settled. This step is mandatory if the product involves a NCFC property.

  

Example

A loan is created and fully disbursed. There are two customer facing and three non customer facing charges associated with the loan product and linked to the disbursement activity.

In the arrangement overview, the NCFC are showcased separately. The user can modify the composite screen to hide this overview if necessary.

• For NCFC, the bills generated are of the type Internal.
• Account balance is impacted only by the customer facing charges which are capitalised. There is no impact due on account balance due to NCFC.
• NCFC are settled from the internal booking account. The statement of the internal booking account is shown below.

  

Activity Charges defines the charges that needs to be applied when an activity is triggered on the arrangement. The event which has to trigger the rebate charge can be defined at the product level. On triggering this event, the rebate is credited to the customer.

Rebate could be paid to the customer by using Payout Rules definition. In the following screenshot, LENDING.PAYOUT Payout Rules record for lending is illustrated.

In this illustration, an arrangement is created with rebate facility. View the Arrangement created for USD 50000 with values set in Settlement Instructions for Payout Account

The illustration below displays the activity log and bill generated for Rebate(Pay Charges) in Bill Details.

Bill Details

Contract wise Balances of the arrangement showing the Pay balances (Rebates)

• During charge-make-due or capitalise, the payable charge details are passed to AA.ACCRUAL.DETAILS.HANDOFF routine such that it updates EB.ACCRUAL record with negative sign for pay charge.
• Accounting entry generated is as follows
  • During due activity
    • Dr ACC<CHARGE>
    • Cr PAY<CHARGE>
  • During capitalise activity
    • Dr ACC<CHARGE>
    • Cr CUR<CHARGE>

The ACC balance is amortized by the core accounting during COB.

To support rebate amortisation, the following AC.EVENT record is created and attached to the AC.ALLOCATION.RULE for charges.

• CHARGE-MAKE.DUE-PAY-AMORT
• CHARGE-ACT.MAKE.DUE-PAY-AMORT
• CHARGE-ACT.CAPITALISE-PAY-AMORT
• CHARGE-CAPITALISE-PAY-AMORT
• CHARGE-ACT.CAPITALISE -PAY
• CHARGE-CAPITALISE-PAY

  

Property Type field is set as CREDIT for NEWARRFEE charge property to support rebate processing.

View the AC Balance Type. PAYNEWARRFEE (Payable Charge) created for NEWARRFEE Charge Property

The Accounting Property Class defines the links between external transactions and the action(s) to be performed on an arrangement. The PAY action has been defined under the DEBIT.CHARGE Allocation Rule and the Amortization period is set. The Accrue field is set as AMORT and Amort Period as 1W for NEWARRFEE Charge Property.

The Reporting Property Class is used for reporting definition in IFRS. This primarily controls the IFRS cash flows applicable for the arrangement. This Property is added to the product in order to generate the EB.CASHFLOW record.

Once an arrangement has been created an EB.ACCRUAL record is created as per definition set for the amortisation process. Each record shows certain information like the daily accrual to date and the start and end date of accrual.

View the EB.ACCRUAL record after COB Process.