1.3.1 Defining a Charge Class

A class is a specific type of component that you can build with certain attributes. You can build a charge class, for instance, with the attributes of a specific type of charge, such as Charges for amending the terms of a loan, or Charges for provision of services.
When building a charge class, you define certain attributes such as:
  • The module in which you use the class
  • The charge type (whether borne by the counterparty or by the bank)
  • The association event
  • The application event
  • The liquidation event
  • The default settlement currency
  • The default charge rule
You can define the attributes of a charge class in the Charge Class Maintenance screen.

To capture details of charge class maintenance screen

Specify the User ID and Password, and login to Homepage.

  1. On the Homepage, type LFDCHGCE and click next arrow.
    The Charge Class Maintenance screen is displayed.

    Note:

    The fields which are marked in asterisk red are mandatory fields.

    Figure 1-3 Charge Class Maintenance



  2. You can enter below details in this screen. For information on fields, refer to the field description table.

    Table 1-5 Charge Class Maintenance

    Field Description
    Class Code Before defining the attributes of a charge class, you should assign the class a unique identifier, called the Class Code and briefly describe the class. A description helps you easily identify the class.
    Module A charge class is built for use in a specific module. As a charge component is applied on different basis amounts, in different modules.

    Note:

    The Basis Amount Tags available depends on the module for which you build the class.
    Charge Type The charges or fee that you levy is recovered, typically, from the counterparty involved. Therefore, when building a charge class, you indicate the charge to be of a Counterparty, Third Party and Their Charges type. The following example illustrates how a charge could be of a Credit type.

    Example

    You are buying a bond issued by the central bank, on behalf of the government. The central bank levies a processing charge on the instrument.

    When defining a charge class, you indicate the charge type to be Credit. This means that you bear the charge.

    Third-party Type If a charge component that you associate with a product is of third party type, indicate it in the Third Party Type field.
    Debit/Credit Charges are considered either as inflow or outflow based on Debit type/Credit Type flag at charge class level.
    Add/Subtract If you choose to include the charge component in the net value, you should indicate if the charge component is to be added, while calculating the net consideration amount, or subtracted.
    SWIFT Qualifier You can report the charge component of a contract in the SWIFT messages that you generate. To do this, identify the component, when building it in the Charge Class Maintenance screen, with the appropriate SWIFT code.

    Example

    Assume you buy securities from a counterparty. The different components of the deal are:
    • The value of the securities USD 50,000.
    • The applicable tax USD 1000.
    • The accrued interest USD 1500.
    • The applicable charge USD 50.

    Result

    If you choose the Net Consideration option, and decide to add the charge component to the value of the deal (and deduct the tax involved), the net value of the deal is: USD 50,550.

    If you choose the Net Consideration option, and decide to subtract the charge component from the value of the deal (and deduct the tax involved), the net value of the deal is USD 50,450.

    If you do not choose the Net Consideration option and choose to deduct the tax component, the value of the deal is USD 50,500. The charge component is not included.
    Defining the Events and the Basis Amount A contract goes through different stages in its life cycle, such as:
    • Initiation
    • Amendment
    • Rollover and so on
    Each of these stages is referred to as an Event in Oracle Lending.
    At any of these events, you can choose to apply a charge or fee. When defining a charge class, you should specify the following.
    • Association Event
    • Application Event
    • Liquidation Event
    The event at which you like to associate a charge component to a contract is referred to as the Association Event. At this event, no accounting entry (for the charge component) is passed.
    The event at which the charge component is actually calculated is referred to as the Application Event. The charge or fee is liquidated at the Liquidation Event that you specify.

    The basis on which interest, charge, fee, or tax is calculated is referred to as the Basis Amount. (A charge or fee can be on the basis of the loan amount, for instance.) The different basis amounts, available in a module, are associated with a unique tag. When building a charge component, you have to specify the tag associated with the Basis Amount. When charge or fee is calculated for a contract, the basis amount corresponding to the tag is taken up automatically.

    Derivation of the Charge Rule While defining a charge class you can indicate whether the class should have a default charge rule or whether the appropriate rule is to be derived on the basis of the transaction count.

    If you enable this option you need to identify various transaction limits for a Charge Class, Module, Customer Group, Customer, and Account combination and associate the charge rule which is to be applied when customer transactions within a group exceed the specified limit. In addition, you are not allowed to specify the Default Charge Rule. Typically, you need to enable this option while building charge classes for the CF module.

    Note:

    You are not allowed to enable this option while defining a charge class meant for the LD module.
    Reset Frequency and Reset Basis Month If you have indicated that the charge rule is to be derived on the basis of the transaction count, you must specify the Reset Frequency.

    The reset frequency indicates the frequency at which the transaction count that is tracked at the charge component and account level is to be reset. You can specify the required frequency.

    Note:

    If you choose the monthly, quarterly, half-yearly, or yearly frequency the transaction count is reset on month-ends. However, in the case of quarterly, half-yearly, or yearly reset cycles you must identify the basis month that need to be considered for arriving at the date on which transaction count needs to be reset by choosing the Default Charge Rule.
    You can link a charge rule that you have defined to the charge component that you are building. When you link a rule to a component, the attributes that you have defined for the rule defaults to the component.
    To recall, a charge rule identifies the method in which charge or fee of a particular type is to be calculated. A rule is built with, amongst others, the following attributes.
    • The charge currency
    • Whether the charge or fee is to be a flat amount or calculated on a rate basis
    • The minimum and maximum charge that can be applied
    • The tier or slab structure on which the charge is to be applied
    • The customer and currency restrictions and so on.
    The charge component to which you link a rule acquires these properties. Charges for the product with which you associate a charge component is calculated, by default, according to the rule linked to the component. However, when processing a contract, you can choose to waive the rule altogether.
    When building a charge class, you can choose to allow the amendment of the rule linked to it, in the following conditions.
    • You can choose to allow amendment after the association event.
    • You can choose to allow amendment after the application event.
    • You can choose to allow amendment of the charge amount
    Settlement currency Charges or fees levied on a contract are settled in the Settlement Currency that you specify for the charge class associated with the product (under which the contract is processed). However, when processing a contract, you can choose to settle the charge in another currency.
    Including a component in SWIFT messages You can report the charge component of a contract in the SWIFT messages that you generate. To do this, identify the component, when building it in the Charge Class Maintenance screen, with the appropriate SWIFT code.

    Example

    You like to report the details of the corporate actions that you perform on a customer portfolio, over SWIFT. Assume you like to report the charge component (amongst others) in the message that you send your customer.

    Each component is identified in SWIFT with a unique code. When building the component Charges for provision of services, in the Charge Class Maintenance screen, you can enter its SWIFT Code.

    In the SWIFT Qualifier field, you should enter CHAR.
    SWIFT Charges While building a charge class for the Loans module you can indicate the charge application treatment for handling incoming funds transfers which need to be repaired.
    If you want to apply the repair charge fee for the customer, you need to maintain the preference for collecting repair charges. The options available are.
    • SWIFT: The charge is levied on the bearer of the charge. The bearer is determined from field 7A.
    • Repair: The charge component is collected from the Remitter.

    Note:

    The repair charges that you have defined are applied on all incoming messages involving the module. In case you do not specify the charge type; the repair fee is collected from the beneficiary of the bank.
    Allow Rule Amendments If you like to allow the amendment of a rule for a charge component, indicate this by selecting the Allow Rule Amendment option.
    Amendment Options When you associate a charge component with a product, you can choose to allow the amendment of the rule linked to it, under the following conditions.
    • You can choose to allow amendment after the association event.
    • You can choose to allow amendment after the application event.
    • You can choose to allow amendment of the charge amount.
    Default Waiver The charge component to which you link a charge rule acquires the properties defined for the rule. Charges for contracts (maintained under the product with which you associate the class you are building) are calculated, by default, according to the rule linked to the component. However, when maintaining a product, you can choose to waive the rule altogether. If you want to indicate that the charge rule must be deemed as waived by default, select this option.
    Consider for Discount Accrual While defining a charge class for either the loans or the bills module, you can indicate whether the charge component is to be considered for discount accrual on a constant yield basis.

    If you select this option the charge received for the component is used in the computation of the constant yield and subsequently amortized over the tenor of the associated contract.

    Accrual Required If you select this option, the charge received for the component is accrued based the constant yield and subsequently amortized over the tenor of the associated contract.
    Propagation Required Select this option to indicate that the charge collected from the borrower must be passed on to the participants of the contract.
    Net Consideration The sum of the different components of a contract determines the net value of the contract. You can indicate that a charge component should be taken into account when determining the net value of a contract by choosing the Net Consideration option.
    Charge Statement Required You can indicate whether the details of charges that are booked under the charge class should be displayed in the charge statement that is sent to the customer.
  3. In Charge Class Maintenance screen, you can enter below charge related details while building a charge class. For information on fields, refer to the field description table.

    Table 1-6 Charge Details

    Field Description
    Charge Mode The charging mode can be any one of the following:
    • Online – charges can be liquidated as and when you are processing a transaction. The charge entries are booked while saving the transaction. The accounting entries are picked up from the product involving the transaction to which the charge component is linked.
    • Deferred – Such charges are collected and liquidated at the end of a specified period. If you choose to defer the entries, the entries are posted as per the charge frequency defined for the charge class. The accounting entries are picked up from the Role-to- Head/Event Class linked to the charge class.
    • Periodic – periodic charges are collected from customer accounts at a specified periodicity.
    • Ad-hoc - There may be occasions when you may need to apply specific charges on a customer account. You can use the ad-hoc charging feature for such charging.
    You can define charge classes specific to each type of charging mode.

    Note:

    Online, periodic, and ad-hoc charges cannot be consolidated. In case of deferred charges you can also choose to consolidate charges across modules. Deferred charges are stored at the Charge Class level. Liquidation of these charges is done on the basis of the charge liquidation frequency that you specify.
    For deferred, periodic, and ad-hoc charges, you must associate the Role-to-Head and Event classes with the Charge Class. Since it is not possible to associate the relevant Role-to-Head and Event classes at the time of creating a new charge class you can follow the sequence of operations given below.
    • Create a new charge class without specifying the Role-to-Head and Event classes.
    • Authorize the class. This creates the relevant accounting roles and amount tags.
    • Define the Role-to-Head and Event classes using the accounting roles and amount tags.
    • Associate the relevant Role-to-Head and Event classes by amending the Charge class and authorize the amendment.
    Charge Class Priority You can specify the sequence in which charges should be liquidated when the charging mode is deferred or periodic by assigning a priority with each class that you define. Lets assume you have defined five charge classes for FT module and assigned different priorities to them. During liquidation charges are liquidated in the order of priority.

    Deferred and Periodic charges are liquidated through the Charge Liquidation batch function, which should be executed both at BOD and EOD. Refer to the section titled End of Day Processing for Charges for information on the end of day processing for the sub-system.

    Charge Frequency If you prefer the Deferred or Periodic mode of charging you have to indicate the frequency at which charges are to be debited to the customer’s charge account. You can select any of the frequency listed below.
    • Daily
    • Monthly
    • Quarterly
    • Half-yearly
    • Yearly
    The frequency that you specify applies to all accounts to which the component applies. You are not allowed to change the charge frequency at the product level.
    Charge Liquidation Day You can choose to liquidate charges either during EOD on the last working day of the period or during BOD of the first working day of the new period. If you have selected the Monthly, Quarterly or Yearly as the charge frequency, liquidation is performed only during month-ends.

    The option is not applicable for Online and Ad-hoc charges.

    Charge Liquidation Value Day The value date of the charge entry can either be on the first calendar day of the next period or it can be on the first working day of the next period.

    This option is applicable only when for deferred consolidation (entry or component level) charges.

    Basis Month When the charging mode is Deferred or Periodic you have to identify the basis month for charge liquidation if the selected frequency is Quarterly or Yearly. In case of a quarterly frequency, the subsequent quarters are calculated based on the basis month that you specify. In case of a Yearly frequency, the charge liquidation is performed in the month that you select.
    Consolidation Basis The consolidation basis indicates whether consolidation is to be performed for all currencies (involved in transactions linked to the product) or only for the account currency of the transaction.

    You are allowed to specify the consolidation basis only if you have indicated that charges should be consolidated either at the entry level or at the component level.

    If the basis is Account Currency, the charge is consolidated only if the charge currency is same as the charge account currency. If the basis is All Currency, charges are consolidated irrespective of the charge amount currency and charge account currency.
    Charges are consolidated at the following levels.
    • Module
    • Branch
    • Account
    • Component
    • Charge Currency
    The system generates a new transaction reference number for posting the consolidated entries.
    If you prefer not to consolidate deferred charges, the accounting entries are posted with the same reference and event sequence number as of the contract when the charge liquidation event is triggered. To facilitate this you need to associate the charge liquidation (CLIQ) event with the product using the charge class.
    Online or Non-consolidated charges are stored in the following sequence:
    • Branch
    • Account
    • Module
    • Component
    • Transaction reference number
    • Event sequence number
    Refer to the topic titled Maintaining Charge Class details for consolidating Charges across modules for additional information on this feature.
    You can also specify the following detail.
    • Charge Consolidation Type

      When the charge mode is deferred you can choose to indicate whether charges should be consolidated across modules. If you opt to consolidate charges you can indicate whether the consolidation should be performed at the Entry level or at the Component level.

      Example

      The following deferred charges are outstanding for a customer account.
      Charge Component Reference Number Charge Currency Amount
      CHG1 100L100030010001 USD 1000
      CHG1 100L100030010002 USD 800
      CHG1 100L100030010003 USD 600
      CHG1 100L100030010004 USD 500
      The balance in the customer account is USD 1900.

      Case I – You choose not to consolidate charges

      The following entries are posted.
      • Debit - Debit
      • Account - Account
      • USD 1000 - USD 800
      For the other records, the system creates individual blocks on the customer based on the accounting entry setup.

      Case II – Entry-level consolidation

      If you select the entry-level consolidation option the following entries are posted to the account.
      • Debit
      • Account
      • USD 1800
      For the other charge records, the system may create individual blocks on the customer based on the accounting entry setup.

      Case III – Charge consolidation

      No entries are posted to the account.

      For all the charge records, the system creates a single block on the customer account based on the accounting entry set up.