Regulatory Compliance
Updated On 06 February 2025 | Min(s) read
Related topics:
Disclaimer

Introduction to Obligor Objects

The Obligor Objects (OX) module is designed to support the structural component of the regulatory requirements associated with the following to provide the basis for assessing contagion:

  • European Banking Association (EBA)
  • Banking Commission of Central Africa (COBAC)

The Capital Requirements Regulation (CRR) Regulation (EU) No 575/2013 established the definition for a default obligor. This is used for the Internal Ratings Based (IRB) and Standard approach (SA) to measure the credit risk in regulatory capital calculation.

The EBA resolved to harmonise the supervisory approaches across the European Union (EU), after identifying the areas that IRB showed extreme flexibility in its application.

In Sept 2016, the EBA and RTS published the following:

  • EBA – Final guidelines on the definition of default.
  • RTS – Materiality threshold of credit obligations that are past due.

Following are the links to the guidelines and RTS relating to Regulation (EU) No 575/2013:

a) https://eba.europa.eu/documents/10180/1597103/Final+Report+on+Guidelines+on+default+definition+%28EBA-GL-2016-07%29.pdf/004d3356-a9dc-49d1-aab1-3591f4d42cbb

b) https://eba.europa.eu/regulation-and-policy/credit-risk/regulatory-technical-standards-on-materiality-threshold-of-credit-obligation-past-due

The key guidelines of the above regulations that define the scope of the functionalities available in the Obligor Objects module are as follows:

Key Regulatory Guidelines

Functionality Offered
A joint obligor, is a specific set of individual obligors that have a joint credit obligation towards an institution. The joint obligor must be treated as a separate obligor and not linked to the individual obligors.

A unique identity is assigned to a joint obligor to facilitate their identification of default.
Applying the definition of default at obligor level.
  • The Obligor Objects module handles a joint obligor, independent from the underlying individual obligors.
  • The Provisioning module (PV) in Temenos Transact, holds the logic to perform asset and customer classification, with which the definition of default is applied on both individual and joint obligors.
  • In the absence of PV module, an external system can provide the default assessment results.
Institutions that decide to apply the definition of default for retail exposures at the obligor level need to specify the rules in detail, when handling joint credit obligations and default contagion, between exposures in their internal policies and procedures.   The PV module or an external system identifies the default details that the Obligor object holds along with the contagion results. Hence, it provides the default status of all the obligors (including the default by contagion) for the following purposes:
  • Standard Provisioning
  • Regulatory capital calculations

The Obligor Objects module is the foundation of the overall solution, which include:

  • Default assessment of individual and joint obligors independently.
  • Contagion effect on default in the case of retail exposures.

It supports the provisioning and regulatory capital requirement calculations. The following diagram shows the overall solution (supported by Obligor Objects), aimed at meeting the regulatory requirements as mentioned above.

OX and JX Flow

  • Customer - The transact provides the ability to create and maintain records within the CUSTOMER application, enabling the storage of static details of the customer.
  • Customer Group - Different customers can be grouped based on specific purpose and with different types of relation such as family, friends, director and more.
  • Contracts - One or more financial contracts can be created for one or multiple customers (joint owners).

When a customer, either individually or jointly, has a loan contract or an overdraft account opened, the CUSTOMER.ACTIVITY table is updated with the list of accounts and financial contract information.

When a new financial contract is created for the customer or group of customers, the details from CUSTOMER.ACTIVITY and CUSTOMER.GROUP acts as a trigger for the creation of obligor objects.

The following types of obligor objects are created based on the underlying customers:

  • Individual obligor - A single obligor (person or entity) who is contractually liable for the loan obligation.
  • Joint obligor - Joint Obligor refers to two or more individual obligors who are jointly and severally liable for the repayment of a credit obligation.
  • Relational obligor - Individual or joint obligors who are grouped together based on defined relationships for a specific purpose.

The Obligor Parameter controls the process, with rules to determine the type of obligor: Individual/Joint/Relation, products in transact that are part of the obligor processing, default equivalent classification and default frequency.

The Obligor Details record stores the contract information, default status and the links to the underlying members for joint obligors.

The Provisioning Module (PV) performs the classification process to assess each contract based on certain criteria and defined rules to assign a risk classification based on the perceived risk. A list of risk classification can be defined with the indication of the unique risk level.

The criteria could be any attribute from the contract or customer record, example, the days past due from the contract, or residence or sector based on which the obligor is assessed.

To apply the definition of default rules based on materiality threshold (for example, EBA Rules) the RX module is required.

The obligor risk classification from PV module is loaded into the OX.OBLIGOR.DETAILS table. These details could be loaded from an External source if the PV module is not used. When the risk classification details are loaded into the obligor details, the Obligor objects will be flagged for default based on the risk classification.

The table also holds addition details relating to Definition of Default Rules (RX) such as the past due amount, total exposure amount, days past due, unlikeliness to pay indicator and more.

The PV module creates a separate record for a joint obligor in PV.CUSTOMER.DETAIL and assigns risk classification at customer level independent of the underlying individual obligors. The risk classification is performed on the joint obligor and its default status is updated in the corresponding record in the OX.OBLIGOR.DETAILS table.

The system automatically assigns a record id of such record for a Joint obligor.

Contagion is a situation, where the default of one obligor influences the default of another obligor and relates to the rules regarding the treatment of joint credit obligations and related clients in the retail exposure class.

The Default through Contagion functionality is part of the JX module and works only if the Obligor Objects (OX) module is available. Read the JX module for more information.

The contagion process is applied either on a defaulted individual obligor or a defaulted joint obligor with the objective of identifying the contaminated obligors. The Contagion details are recorded in OX.OBLIGOR.DETAILS with the contagion date, contagion class, the contagion status.

The Obligor Parameter controls the contagion process to determine the type of contagion and the applicable contagion rule and the contagion frequency.

A mechanism is built to load the Contagion details for all the contaminated Individual and Joint obligors with the risk classifications back into the PV Module. The classification details of the contaminated objects are updated into new contagion related fields

This is an extension of the PV Module if the JX Module is installed.

The IFRS 9 staging and ECL calculation (impairment) and standard provisioning consumes the obligor assessment and contagion details from PV. The same details are also fed to the external systems for Risk weighted Assets calculations based on the below order.

  • To use the contagion classification from the contagion process if any
  • To use the manual classification if any
  • To use the automatic classification from the contract and customer classification

Illustrating Model Parameters

This sections allows the user to view the below Model Parameters:

S.No. Parameter Description
1 OX.OBLIGOR.PARAMETER

This table allows the user to configure the creation and maintenance of Obligor Objects.

  • Obligor Api – The user must enter a value in this field to determine the process for Individual or Joint Obligor.
  • Product – Users can select the products available in the system from the drop-down.
  • Product Cat Start and Product Cat End – The range of category codes can be specified here for obligor processing.
  • Product Line and Product Grp – Users can specify the AA Product Line or AA Product Group, if the Product is AA.
  • Data Inherit Rule or Data Inherit Api– Users can specify the rule or API to determine the reference customer for Joint Obligor.
  • Def Equi Class – Users can specify the classifications that need to be considered as default.
  • Default Status Freq – Users can enter a suitable frequency for updating the default status of obligors.
  • Default Status Api – Users can attach an API to this field, if Provision (PV) module is not installed to get the default status.
  • Cust Sector Type – Identifies customer types based on the sector range defined.
  • Cust Class Sector Start and Cust Class Sector End – Define the start and end range for customer sector type.
  • Default Customer Type – Defines the customer sector type if customer sector is not in the defined sector ranges.

Illustrating Model Products

Model Products are not applicable for this module.

Copyright © 2020- Temenos Headquarters SA

Contact Us

knowledge@temenos.com

Published on :
Sunday, March 23, 2025 1:44:19 PM IST