Data stored in this table is essential for the proper functioning of new workflows in the new OC module. This captures the local regulator details, repository to which the trades are reported, and Temenos Transact Bank LEI details, etc., OC.PARAMETER is a central parameter table that controls new system-wide OTC transaction operations.

The UTI USI API field holds the user attached API for generating Unique Transaction Identifier (UTI) or Unique Swap Identifier (USI) for each transaction. UTI is used to identify OTC derivative transactions and is therefore same for both counterparties to the trade. The responsibility to generate the UTI is based on the hierarchy logic provided by ISDA. Temenos Transact user can modify the logic when changes to the logic are emphasised by ISDA or regulator.

This table captures the information on the regulators across the world. The regulator information stored in this table defaults data in OC.CUSTOMER and OC.PARAMETER tables.

This table defines and stores static data related to different parties, such as counterparty, clearing member, clearing house etc., and regulatory counterparty classification along with respective Legal Entity Identifiers (LEI). After an OTC trade is executed with the counterparty, the system defaults and stores the data related to the counterparty.

The system determines the UTI generating party based on the regulatory classification of a counterparty. The user can do the following:

• Check if the customer is already available within Temenos Transact.
• Define respective regulator in OC.REGULATOR.
• Define OC.CUSTOMER.

To know more, refer to the user guide of LEI or NCI transaction control validations.

This table has information about the trade repository. A trade repository is a business entity approved by the respective regulator to receive, validate, and store trade-related data from counterparties to a trade (in case of bilateral trades) and from clearing members and central counterparties (in case of cleared trades). They need to provide the required consolidated data to the regulators for risk monitoring, for which purpose only the trade reporting was imposed.

In the case of EU regulatory norms, derivative trades are required to be reported to a trade repository within T+1 time frame. The timelines vary across regulators.

For the trade repository, the user defines the CUSTOMER and OC.CUSTOMER. In OC.CUSTOMER, the user has to define if it is LEI, only then, the same LEI can be populated in OC.TRADE.REPOSITORY.

One of the regulatory requirements is the trading of OTC derivatives on electronic platforms. This table enables the bank to store the valid Swap Execution Facilities (SEF) and the type of interface between the SEF and Temenos Transact system. This facilitates reading and publishing of deals to external trading systems. This table is important when the trades are executed on electronic trading platforms, which needs to move into the reporting data. Further enhancements are required when the banks start to use electronic platforms for OTC trades frequently.

This table stores the static data related to central counterparties and is ideal for cleared trades.

The user defines OC.CUSTOMER with customer type as CLEARING.HOUSE to populate a record within this table.

This table stores information on clearing member details. These details are required when reporting cleared trades.

Clearing member is first defined in OC.CUSTOMER table along with respective clearing house in OC.CLEARING.HOUSE table to populate a record in this table.