Show TOC

Component documentationTrade Repository Reporting (TRR)

 

For the purposes of regulating the financial markets, companies are obliged to report their derivative financial transactions to a trade repository, in addition to the central clearing of derivative financial transactions (see also: External Accounts) or in addition to clearing threshold reporting (CTR).

The trade repository reporting functions support you in creating such trade repository messages. Once the process is complete, your trade repository messages are available as a file on the application server for transfer to the trade repository. From the application server, you can also import and interpret incoming messages for the trade repository, and store them in Document Management.

As there are various kinds of trade repository, each having their own regulations for the messages to be sent to them, the functions have flexible settings and can be enhanced in various ways. This is achieved by flexible Customizing, and also the provision of business add-ins (BAdIs) and flexible derivation tool settings for filling the content or derived content field values of the trade repository objects.

An implementation is delivered for each of the BAdIs. You can use these and, by using the derivation tools, correct how the fields are filled or define your own BAdI implementations.

Integration

  • Use of the functions for trade repository reporting is controlled by the authorization object T_TLR_REP (Authorization for Message Type).

  • The messages are created from the fields of the trade repository objects. To create them, you can use the Data Medium Exchange Engine (DMEE), which enables you to create the trade repository messages in XML format.

  • Once created, the trade repository messages are stored in Document Management (CA-DMS).

Features

Creating and Managing Trade Repository Objects as Data Carriers for Messages

After you have made the Customizing settings for Trade Repository Reporting, the system automatically creates or changes one or more trade repository objects whenever a financial transaction that needs to be reported is created or changed.

Note Note

You can also report to the trade repository any transactions that you do not manage in the Transaction Manager. For this, you use the Enter External Transactions function. You use this function to create TAROs for the entered transactions. You then manage such TAROs in the same way as TAROs created within the Transaction Manager.

End of the note.

To create the trade repository object, the system - once a financial transaction has been saved - calls method FILL_CONTENT of the active BAdI implementation of the BAdI BADI_TLR_TARO_FILL_CONTENT Fill Content for Trade Repository Object. The derivation tool is run and then, finally, method CHECK_CONTENT of the BAdI is run. The same occurs for derived content. The system first calls method FILL_DERIVED_CONTENT of the BAdI BADI_TLR_TARO_FILL_DER_CONTENT Fill Derived Content for Trade Repository Objects. Then the derivation tool is run for the derived content, and, finally, method CHECK_CONTENT of the BAdI is run. In this way, the trade repository fields are filled with values. The check program checks the mandatory fields. If all mandatory fields have been filled and no other errors have occurred, the trade repository object is saved with the status 01 Created. Otherwise, it acquires the status 02 Incompletely Created.

The external trade ID is one of the mandatory fields for a TARO. Given that an external transaction may not yet have a unique trade ID at the time when the transaction is reported to the trade repository, you can - the trade repository permitting - initially report the transaction using a unique interim trade ID. Once the external trade ID is known, you need to communicate it to the trade repository. This external trade ID is then used for all subsequent reports. See also: External Trade ID and Interim Trade ID

Note Note

However, the values determined for the derived content data are not saved persistently.

End of the note.

With the function Monitor for Trade Repository Objects (transaction FTR_TARO_MONITOR), you can check the trade repository object created. If you want to change the values determined, you can do so using the following functions:

  • Change Financial Transaction (transaction FTR_EDIT)

    When you save the changes made to a financial transaction, the field values are determined for the trade repository object. When the first TARO had not yet been sent, the current TARO is updated. If the first TARO has already been sent, either one or multiple new TAROs are created, depending on the settings that you have made in Customizing (and depending on how far-reaching the changes are that you have made).

  • You can also manually change the field values of the TARO content by using the function Change Content in the Monitor for Trade Repository Objects (transaction FTR_TARO_MONITOR).

    You can protect fields that have been changed manuallly to prevent their values from being overwritten by the original value. In the case of protected fields, the system notes both the original value of the field before the manual change and the changed value. If an update of the TARO content causes the original value of a protected field to be determined, the field continues to retain the manually changed value. In cases when the update of the TARO content produces a different value to the original value, the system enters the new value in the field.

  • When you have corrected the errors that led to the TARO being created incompletely (for example, you have made changes to the Customizing settings or you have corrected or added data in the master data of the business partner), you can use one of the following functions to update the field values of the TARO:

    • In the Monitor for Trade Repository Objects (transaction FTR_TARO_MONITOR) using the function Complete

    • Using the function Update Trade Repository Objects (transaction FTR_TARO_PROCESS)

  • You use the functions Accept/Reject Clearing (transaction TREA_CLEAR) and Change Counterparty of Financial Transactions (transaction TRTM_CHG_PARTNER) to replace the previous counterparty of a financial transaction with another counterparty (novation) and to create TAROs with which to report the change in counterparty to the trade repository. If, when novation is performed, the financial transaction has not yet been reported to the trade repository (and consequently there is no TARO with the status Sent for this financial transaction), only the existing TARO is updated.

    • If novation occurs as part of central clearing, the system creates a TARO with the action type 45 Termination and a TARO with the action type 10 New, which is used to report the financial transaction with the new business partner.

    • If novation occurs during the function Change Counterparty of Financial Transactions, you can decide whether you send a TARO with the action types 45 Termination or 40 Error. In both cases, the system creates a TARO with the action type 10 New.

    Further, it is possible in both functions to assign a new external trade ID to the financial transaction as part of novation.

  • In the Monitor for Trade Repository Objects, you use the Enter External Transactions function to report to the trade repository any transactions that you do not manage in the Transaction Manager.

If a trade repository would like to receive the current mark-to-market value of the notified financial transactions as well as the collateral values for your financial transactions, in separate messages, you create the necessary trade repository object using the function Update Trade Repository Objects (transaction FTR_TARO_PROCESS).

Sending Trade Repository Objects

Trade repository objects with the status 01 Created and 04 Send Failed can be sent.

You have the option of sending each trade repository message in an individual file to the trade repository or sending multiple messages in combined files. When you choose the Combined Files function in the Monitor for Trade Repository Objects or in the function Send Trade Repository Objects, the system combines into one message all selected trade repository messages that have the same company code, relate to the same trade repository, and use the same format tree. For this, you can restrict the size of the file by specifying the maximum number of messages per file in the send parameters.

When you execute the function, the system first calls the method FILL_DERIVED_CONTENT of BAdI BADI_TLR_TARO_FILL_DER_CONTENT Fill Derived Content for Trade Repository Objects, then the derivation tool for the derived content, and finally method CHECK_CONTENT of the BAdI. The system then calls the BAdI BADI_TLR_TARO_FILE_CREATE Create File Based on TARO Content.

The file generated as well as all files that you have assigned to the TARO as attachments are stored in Document Management.

The BAdI Send File to Trade Repository (BADI_TLR_TARO_FILE_SEND) is now called. The delivered implementation stores the trade repository message (= file) on the application server. However, you can use an implementation of your own to use alternative output channels.

If the send process has been performed successfully, the TARO acquires the status 03 Sent. If errors occurred, the TARO acquires the status 04 Send Failed, and no file is stored on the application server or in DMS.

See also: Send Trade Repository Messages

Importing Incoming Trade Repository Messages

With this function, incoming messages for your trade repository are uploaded from the application server to Trade Repository Reporting, the files are read, and the status of the relevant trade repository object is set accordingly.

Moreover, the imported file is stored in Document Management and assigned to the relevant trade repository object.

When you perform this function, the system call the implementation of the BAdI BADI_TLR_TARO_INBOUND Import Data of Incoming Messages for a TARO.

The system sets the status of the TARO depending on the content of the imported file. It can acquire one of the following statuses:

  • 07 Accepted

  • 05 Rejected

  • 09 Reconciled

  • 10 Reconciliation Failed

See also:

Importing Reports at Period End

You use this function at the end of the period to import reports that you have received from your trade repository. As with the function for importing incoming trade repository messages, the system calls the implementation BADI_TLR_TARO_INBOUND Import Data of Incoming Messages for a TARO. The format-specific details need to be programmed in method GET_REPORTS of the interface IF_TLR_TARO_BADI_INBOUND.

The implementation delivered can import the report D433 Mismatched Fields from REGIS-TR.

Importing Reports at Period End

Storage of Outgoing and Incoming Trade Repository Messages in Document Management (DMS)

All outgoing and incoming trade repository messages are stored in Document Management (DMS). There are settings that you need to make for this in DMS. See also: Customizing Settings in DMS for TRM Documents

Archiving Trade Repository Objects

TAROs for financial transactions in the Transaction Manager are archived together with the financial transactions using the archiving object TRTM_FTR.

The archiving object TRTM_TARO archives TAROs for external transactions as well as TAROs with the following action types:

  • 30 Valuation

  • 35 Collateral

  • 90 Invalid

Note Note

The related trade repository messages stored in Document Management (DMS) are not archived using these archiving objects.

End of the note.

See also:

Alert Monitor

Trade Repository Reporting has also been integrated with the Alert Monitor. You can run checks to ascertain the following:

  • Are there any trade repository objects that have not been sent for a specific number of days (which you specify)?

    The system identifies all TAROs that have had one of the statuses Created, Incompletely Created, or Send Failed for a specific number of days.

  • Are there any trade repository objects that still have errors after being sent since a specific number of days (which you specify)?

    The system identifies all TAROs that have had one of the statuses Rejected or Reconciliation Failed for a specific number of days.

  • Are there any incoming messages from the trade repository that cannot be assigned to a TARO?

    The system identifies all TAROs with the status Invalid.

  • Are any TAROs missing?

    The Alert Monitor establishes the following:

    • Whether TAROs are missing for a specific trade repository that may have been added recently to the settings in Customizing

    • Whether a new TARO has not yet been created for a financial transaction that has been reversed at the trade repository and that needs to be reported again

    • Whether backloading has not yet been performed for backloading-relevant financial transactions.

More Information