Show TOC

Background documentationFields of the Trade Repository Object

 

You use the fields of the trade repository object to create messages to be sent to a trade repository.

Since each trade repository has its own rules governing the creation of messages, the number of fields listed here is greater than the number of fields that would be derived from the technical description for EMIR.

The following table provides an overview of the fields of the trade repository object. For each field, you can see the corresponding field under EMIR, the meaning of the field or the expected values, and how the field is filled by the delivered implementations BADII_TLR_TARO_FILL_CONTENT and BADII_TLR_TARO_FILL_DER_CNT.

Note Note

  • And since each trade repository has its own regulations, you can add more fields and use a BAdI to fill them with values. (To do this, you need to create your own BAdI implementation.) However, you can also use the derivation tools to change how the fields are filled so that the requirements for the relevant trade repository are met.

  • You can also use these fields to create trade repository messages using a different legal basis to EMIR. Given that a different legal basis may require different fields, you can add these fields and use a BAdI to fill them with values, or you can use the derivation tools to change how the fields are filled so that the requirements for the relevant trade repository are met.

  • Mandatory Fields in the Delivered Implementation:

    In the delivered implementations, the check methods of the BAdIs check whether the following fields are filled. If one of the mandatory fields is not filled, the trade repository object acquires the status 02 Incompletely Created.

    • External Trade ID or Interim Trade ID

      (See also: External Trade ID and Interim Trade ID)

    • Counterparty ID and the related ID type

    • Other counterparty ID and the related ID type

    • The Domicile Not in Validity Area of LB field must be filled.

    • If the broker ID is specified, the relevant identifier must also be filled.

    • If the beneficiary ID is specified, the relevant identifier must also be filled.

    • If the ID of the clearing party is specified, the relevant identifier must also be filled.

    • If the ID of the central counterparty is specified, the relevant identifier must also be filled.

End of the note.

Field in the Trade Repository Object

Field in EMIR

Meaning (Acc. to EMIR)

Data Filling

By delivered BAdI implementations

Administrative Data

The values in these fields are filled by SAP. You cannot change these field values.

However, all of the fields can be used for the creation of trade repository messages.

Company Code

Internal Data

Identifying a TARO Uniquely in the System

From Transaction Data

Transaction

Internal Data

From Transaction Data

Trade Repository

Internal Data

The trade repository is derived on the basis of the settings made in the Customizing activity Define Settings for Trade Repositories.

TARO Number

Internal Data

TAROs for a financial transaction are numbered sequentially.

External Trade ID

Table 2, Section 2b, Field 8

A unique ID at the European level, delivered from the reporting company.

If there is no unique ID, a unique code needs to be generated and agreed upon with the counterparty for that transaction.

Value from the financial transaction, Administration tab in the Trade Repository Reporting area.

You can fill the field by using the BAdI FTR_TR_DEFAULT_TRADE_ID (BAdI: Default Value for External Trade ID in Financial Transaction) or enter the value manually in the financial transaction.

Interim Trade ID

The interim trade ID is used to uniquely identify a financial transaction. You can use it in messages to the trade repository as long as no external trade ID has been officially agreed upon.

If you want this field to be filled, you need to allow use of interim trade IDs in the Customizing activity Define Settings for Trade Repositories in Customizing for Trade Repository Reporting.

The system determines interim trade IDs as follows:

  • If you use the business partner ID type FS0007:

    Characters 7–16 of the LEI (of the company code), the company code, and the transaction number are combined to produce the interim trade ID

  • If you use a different business partner ID type:

    Business partner ID of the company code, the company code, and the transaction number are combined to produce the interim trade ID

The system determines the interim trade ID when the transaction is saved.

Note Note

The business partner ID is read from the business partner master data of the business partner that represents the company code. You can assign business partners to company codes in the business partner data (in the Counterparty role) on the Control Data tab in the Partner Is Company Code area.

End of the note.

Planned Send Date

Internal Data

The planned send date is derived from the action type of the TARO:

Action Type -> Date

10 -> Contract date (from table VTBFHAZU, field DVTRAB)

20 -> Contract date (from table VTBFHAZU, field DVTRAB)

30 –> Key date of the valuation/security

35 –> Key date of the valuation/security

40 -> System date

50 -> Final maturity date

60 -> System date

80 –> Contract conclusion date for the transaction contract; if the contract conclusion date falls before the sending start date for the trade repository, it is set as the sending start date

Sending Date

Internal Data

Filled with the date on which the TARO switches to the status Sent or on which the TARO was created.

Status

(of the TARO)

Internal Data

A TARO can have the following status:

  • 01 Created

  • 02 Incompletely Created

  • 03 Sent

  • 04 Send Failed

  • 05 Rejected

  • 06 Rejection Accepted

  • 07 Accepted

  • 08 Obsolete

  • 09 Reconciled

  • 10 Reconciliation Failed

  • 20 Invalid

See also: Status Management for Trade Repository Objects

Action Type

Section 2i, Field 58

  • N = New

  • M = Change

  • E = Error

  • C = Deletion/Termination

  • Z = Compression

  • V = Valuation Update

  • O = Other

The action type explains the cause for a trade repository object:

  • 10 New

    The TARO reports a derivative for the first time.

  • 20 Change

    The TARO reports a change for a derivative that has already been reported.

  • 25 External Trade ID

    TARO reports the external trade ID by

    External Trade ID and Interim Trade ID

  • 30 Valuation

    The TARO reports the current market value of a derivative.

  • 35 Security

    The TARO reports the current value of the security for a financial transaction or the current value of the security portfolio.

  • 40 Error

    The TARO is used when an error (such as an entry error) has occurred and the transaction needs to be deleted at the trade repository.

  • 45 Notice

    The TARO is used when a novation has been performed. The previous transaction is declared as terminated.

  • 50 Termination at Term End

    The TARO reports the end of a financial transaction upon maturity.

  • 60 Premature Termination

    The TARO reports a premature termination of the financial transaction.

  • 70 Compression

    Not supported

  • 80 Backloading

    The TARO is created by the backloading function.

  • 90 Invalid

    The TARO is created during import if there is no TARO for an incoming message.

The BAdI implementation derives from the action type which format tree ID is used in the Data Medium Exchange Engine (DMEE) for the XML message:

  • For the action types 10, 20, and 25, the format tree ID TARO_XT is used.

  • For the action type 30, the format tree ID TARO_VU is used.

  • For the action type 35, the format tree ID TARO_CU is used.

  • For the action types 40, 45, 50, and 60, the format tree ID TARO_TT is used.

  • For the action type 80, the format tree ID TARO_BK is used.

Comment

Internal Data

Not filled

In the TARO Monitor, you can enter a comment for the TARO.

Investment

Internal Data

Not filled

In the TARO Monitor, you can upload a file for the TARO.

Contract Conclusion Date

Internal Data

From Transaction Data

Time of Contract Conclusion

Internal Data

From Transaction Data

Product Type

Internal Data

From Transaction Data

Transaction Type

Internal Data

From Transaction Data

Created By

Internal Data

From Transaction Data

Creation Date

Internal Data

From Transaction Data

Last Changed By

Internal Data

From Transaction Data

Last Changed On

Internal Data

From Transaction Data

Last Changed At

Internal Data

From Transaction Data

Origin of Processing

Internal Data

Filled with the trade with which the table entry was changed

Origin of First Entry

Internal Data

Filled with the trade with which the table entry was filled for the first time

Trade Repository: Error Code

Trade Repository: Description Error Code

Sending Date

Internal Data

Trade Repository Object Sent At

Internal Data

Content Data

Counterparty Data

Mark-to-Market Value of the Contract

Table 1, Field 17

Mark-to-Market Value or Mark-to-Model Value of the Contract Test

The system reads the values from table VTVBAR.

Here you can enter the MtM value manually using transaction JBNPV or calculate it using transaction TPM60.

Currency of the Mark-to-Market Value

Table 1, Field 18

Currency of the Mark-to-Market Value

Last Valuated On (UTC)

Table 1, Field 19

First Created On date of last valuation for the contract available in table VTVBAR.

Last Valuated At (UTC)

Table 1, Field 20

Time for the date of the last valuation

Last Valuation Type

Table 1, Field 21

Specifies how the mark-to-market value is determined:

M = Mark-to-Market

O = Mark-to-Model

Always filled by the system with M.

Collateralization

Table 1, Field 22

Provides information about whether collateralization has occurred.

U = Without Collateralization

PC = Partially Collateralized

OC = One-Sided Collateralization

FC = Fully Collateralized

Always U = Without Collateralization

Collateral Portfolio

Table 1, Field 23

Y = Yes

N = No

Not filled

Collateral Portfolio Code

Table 1, Field 24

Unique code for the collateral portfolio

Not filled

Collateral Value

Table 1, Field 25

Total Value of Collateral

Not filled

Collateral Currency

Table 1, Field 26

Currency of the Collateral Value

Not filled

General Data

Counterparty

Contains the ID of the counterparty for the financial transaction.

This field is used to read the unique ID (such as the BIC or LEI) from the business partner data. This ID is then stored in the derived content data (see under Derived Content: Other Counterparty).

Note Note

In the Customizing activity Define Settings for Trade Repository, you specify which unique ID is selected.

End of the note.

Broker

Contains the ID of the broker for the financial transaction.

This field is used to read the unique ID (such as the BIC or LEI) from the business partner data. This ID is then stored in the derived content data (see under Derived Content: Broker ID).

Clearing Member

Filled with the internal ID of the counterparty for all financial transactions that have the clearing status Cleared.

This field is used to read the unique ID (such as the BIC or LEI) from the business partner data. This ID is then stored in the derived content data (see under Derived Content: Clearing Member ID).

Central Clearing Partner

Not filled by SAP.

If you want to fill this field, you need to enter the internal ID of the central clearing partner to apply this field in the derivation of the unique ID, such as the BIC or LEI, which is then stored in the derived content data (see under Derived Content: Central Clearing Partner ID).

External Action Type

The external action type, corresponding to its trade repository reporting legislation, such as EMIR, may possibly be required to distinguish reports to your trade repository.

You must maintain relevant fields for mofications with an action type other than M in Customizing under Define Settings for Trade Repositories under the new dialog structure node Fields for Separate Modification.

You assign the (internal) action type and the external action type to each field.

As the External Action Type field is part of the TARO content, you can use the monitor to assign or change it.

Trade repositories that report modifications to ESMA are divided into three subtypes:

  • Action type = M, all modifications of a derivative contract reported earlier

  • Action type = V, update or change collateral information, for example, for ESMA/EMIR, all changes of the field

    • Collateralization (COLLATERILISAT),

    • Collateral Portfolio (COLLAT_PORTF)

    • Collateral Portfolio Code (COLLAT_PORTF)

  • Action type = O, other changes to the reported message

Action Type Details

User-Defined Text Field

Latest Error Message

External Account

Contract Type Data

Taxonomy

Table 2, Section 2a, Field 1

Derives the value from the settings made in the Customizing activity Define Settings for Trade Repository under Enter Taxonomies for Product Classifications.

Product ID 1

Table 2, Section 2a, Field 2

Filled with the value of the superordinate product classification type of the product classification type assigned in the activity Define Settings for Trade Repository.

If you have assigned a product classification that does not have a superordinate product classification type, the value of the assigned product classification type is entered in the field.

Product ID 2

Table 2, Section 2a, Field 3

Filled with the value of the product classification type assigned in the activity Define Settings for Trade Repository.

If you have assigned in this activity a product classification type that does not have a superordinate product classification type, no entry is made in this field.

Underlying

Table 2, Section 2a, Field 4

Not filled

Notional Currency 1

Table 2, Section 2a, Field 5

Filled with the currency of the outgoing side (if one exists).

Otherwise, the field is filled with the transaction currency.

Notional Currency 2

Table 2, Section 2a, Field 6

Filled with the currency of the incoming side (if one exists).

Otherwise, the field is not filled.

Settlement Currency

Table 2, Section 2a, Field 7

Currency of the cash settlement flow

Transaction Data

Asset Class

Not a field in EMIR, but may be required by trade repository

Derives the asset class from the product type, the transaction type, and the trade repository from the settings made in Customizing for Treasury and Risk Management. Here you define the product classifications under Transaction Manager -> General Settings -> Information System -> Trade Repository Reporting -> Define Product Classifications. You then assign product types to the defined product classifications. In the activity Define Settings for Trade Repository, you assign the relevant product classifications to the trade repositories.

Venue of Execution

Table 2, Section 2b, Field 10

This field is filled with the stock exchange (table VTBFHAPO, field RHANDPL) if one of the following conditions is filled:

  • The contract type of the transaction is 2 = Securities.

  • The product category of the transaction is 700 = Futures.

  • The product category of the transaction is 750 = Listed Options.

If the RHANDPL field is not filled in these cases, the XOFF field is filled.

For all other contract types and product types, the field is filled with XXXX.

Compression

Table 2, Section 2b, Field 11

Not filled

Price

Table 2, Section 2b, Field 12

Filled with the security price (percentage-quoted or unit-quoted) of the financial transaction.

Price Quotation

Table 2, Section 2b, Field 13

Filled with % for percentage-noted security prices or with SRUNIT for unit-noted security prices.

Notional Amount

Table 2, Section 2b, Field 14

Filled with the payment amount of the financial transaction.

Price Multiplier

Table 2, Section 2b, Field 15

Filled with 1.

Quantity

Table 2, Section 2b, Field 16

Filled with 1.

Advance Payment Amount

Table 2, Section 2b, Field 17

Filled with the payment amount of another flow that was paid in advance.

Currency of Advance Payment Amount

Table 2, Section 2b, Field 17

Currency in which the advance payment was made.

Delivery Type

Table 2, Section 2b, Field 18

Specifies how the contract was fulfilled:

C = Cash Settlement

P = Physical Exercise

O = Optional for Counterparty

Derived from "Settlement" indicator.

Execution Date (UTC)

Table 2, Section 2b, Field 19

Filled with the date on which the contract is concluded for the financial transaction (UTC).

Execution Time (UTC)

Table 2, Section 2b, Field 19

Filled with the time at which the contract is concluded for the financial transaction (UTC).

Validity Date

Table 2, Section 2b, Field 20

Filled with the start of the term for the financial transaction.

Maturity Date

Table 2, Section 2b, Field 21

Original maturity of the financial transaction (not the date of a premature termination/notice of the transaction)

Filled with the end of the term for the financial transaction.

Termination Date

Table 2, Section 2b, Field 22

Termination date of the contract. If the termination date is the same as the maturity, this field remains empty.

Filled with the OTC termination date.

Settlement Date

Table 2, Section 2b, Field 23

Filled with the exercise date.

OTC Notice Date

Master Agreement Type

Table 2, Section 2b, Field 24

Filled with the value in the Master Agreement field (on the Administration tab).

Master Agreement Version

Table 2, Section 2b, Field 25

Refers to the year of the master agreement version.

The year is read from the master agreement data.

Delegation

  • If you set this indicator to Y, you report the financial transaction for yourself and for your counterparties.

    For intragroup transactions, for example, only one counterparty reports to the trade repository. This reduces the number of messages reported to the repository. Your trade repository must be set up for this type of report.

  • If you set this indicator to N, you report the financial transaction only for yourself.

The standard implementation fills the field with N.

Nominal Currency

Is filed with the currency of the payment amount

Risk Mitigation/Reporting Data

Confirmation Date (UTC)

Table 2, Section 2c, Field 26

The date of the confirmation or counterconfirmation, depending on which is the latest.

Confirmation Time (UTC)

Table 2, Section 2c, Field 26

Time relating to the date of the confirmation

Confirmation Means

Table 2, Section 2c, Field 27

Specifies whether and how the contract was confirmed:

Y = Non-electronically confirmed

N = Non-Confirmed

E = Electronically confirmed

If the confirmation date is not filled, this field is filled with the value N; otherwise, E is entered for the confirmation.

Clearing Data

Clearing Obligation

Table 2, Section 2d, Field 28

Specifies whether the reported contract is subject to the clearing obligation.

Y = Yes

N = No

Derived from the clearing status of the financial transaction.

If the status is 0 Not Relevant for Clearing, the field is filled with the value N; otherwise, with the value Y.

Cleared

Table 2, Section 2d, Field 29

Y = Yes

N = No

Derived from the clearing status of the financial transaction.

Accepted = Y

Clearing Date (UTC)

Table 2, Section 2d, Field 30

Time when the clearing partner accepted clearing.

Date when the clearing partner accepted clearing.

Clearing Time (UTC)

Table 2, Section 2d, Field 30

Time when the clearing partner accepted clearing.

ID of the Central Counterparty

Table 2, Section 2d, Field 31

BIC or LEI of the Central Counterparty

Not filled

Intragroup

Table 2, Section 2d, Field 32

Specifies whether the transaction is an intragroup transaction.

Y = Yes

N = No

Filled with the value Y if a mirror transaction (reference type MIR) exists. Otherwise, the field is filled with the value N.

Interest Data

Fixed Rate of Leg 1

Table 2, Section 2e, Field 33

Filled with the percentage of the condition.

Fixed Rate of Leg 2

Table 2, Section 2e, Field 34

Filled with the percentage of the condition.

Daily Calculation of Fixed Rate Leg 1

Table 2, Section 2e, Field 35

Filled with the interest calculation method of the condition of the financial transaction Leg 1.

Daily Calculation of Fixed Rate Leg 2

Table 2, Section 2e, Field 35

Filled with the interest calculation method of the condition of the financial transaction Leg 2.

Payment Frequency of Fixed Rate Leg 1

Table 2, Section 2e, Field 36

Filled with the payment frequency of the condition in months or days.

Payment Frequency of Fixed Rate Leg 2

Table 2, Section 2e, Field 36

Filled with the payment frequency of the condition in months or days.

Variable Interest Payment Frequency Leg 1

Table 2, Section 2e, Field 37

Filled with the payment frequency of the condition in months or days.

Variable Interest Payment Frequency Leg 2

Table 2, Section 2e, Field 37

Filled with the payment frequency of the condition in months or days.

Variable Interest (Adjustment) Frequency Leg 1

Table 2, Section 2e, Field 38

Filled with the payment frequency of the interest adjustment condition in months or days.

Variable Interest (Adjustment) Frequency Leg 2

Table 2, Section 2e, Field 38

Filled with the payment frequency of the interest adjustment condition in months or days.

Daily Calculation of Variable Interest Leg 1

Table 2, Section 2e, Field 35

Filled with the interest calculation method of the condition of the financial transaction Leg 1.

Daily Calculation of Variable Interest Leg 2

Table 2, Section 2e, Field 35

Filled with the interest calculation method of the condition of the financial transaction Leg 2.

Floating Rate of Leg 1

Table 2, Section 2e, Field 39

Reference Interest Rate of Condition Leg 1

Floating Rate of Leg 2

Table 2, Section 2e, Field 40

Reference Interest Rate of Condition Leg 2

Internal Daily Calculation of Fixed Interest Leg 1

Internal Daily Calculation of Fixed Interest Leg 2

Internal Daily Calculation of Variable Interest Leg 1

Internal Daily Calculation of Variable Interest Leg 2

Foreign Currency Data

Currency 2

Table 2, Section 2f, Field 41

Filled with the following currency.

Exchange Rate 1

Table 2, Section 2f, Field 42

Filled with the spot rate of the transaction.

Forward Rate

Table 2, Section 2f, Field 43

Filled with the forward rate of the transaction.

Exchange Rate Basis

Table 2, Section 2f, Field 44

The currency pair leading currency / following currency is displayed.

Commodity Data

Commodity Base

Table 2, Section 2g, Field 45

Identifies the type of the underlying commodity:

AG = Agricultural

EN = Energy

FR = Freight

ME = Metals

IN = Index

EV = Environmental

EX = Exotic

The system fills this field with data from the commodity master data (transaction FCZZ). The value for the commodity base is derived from the commodity category of the relevant commodity.

001 Metals -> ME

002 Base Metals -> ME

003 Inferior Metals -> ME

004 Grains -> AG

005 Oilseeds -> AG

006 Livestock -> AG

007 Softs -> AG

008 Energy -> EN

009 Electricity -> EN

010 Gas -> EN

011 Oil -> EN

012 Weather -> EV

Commodity Details

Table 2, Section 2g, Field 46

Details of the particular commodity beyond field 45.

Agricultural Economy

GO = Grains/Oilseeds

DA = Dairy

LI = Livestock

FO = Forestry

SO = Softs

Energy

OI= Oil

NG = Natural Gas

CO = Coal

EL = Electricity

IE= Inter-Energy

Metals

PR = Precious Metals

NP = Non-Precious Metals

Environment

WE = Weather

EM = Emissions

The system fills this field with data from the commodity master data (transaction FCZZ). The value for the commodity base is derived from the commodity category of the relevant commodity.

001 Metals -> NP

002 Base Metals -> NP

003 Inferior Metals -> NP

004 Grains -> GO

005 Oilseeds -> GO

006 Livestock -> LI

007 Softs -> SO

008 Energy -> EL

009 Electricity -> EL

010 Gas -> NG

011 Oil -> OI

012 Weather -> WE

Delivery Location

Table 2, Section 2g, Field 47

Not filled

Interconnection Point

Table 2, Section 2g, Field 48

Not filled

Load Type

Table 2, Section 2g, Field 49

Not filled

Delivery Start Date

Table 2, Section 2g, Field 50

Not filled

Delivery Start Time

Table 2, Section 2g, Field 50

Not filled

Delivery End Date

Table 2, Section 2g, Field 51

Not filled

Delivery End Time

Table 2, Section 2g, Field 51

Not filled

Contract Capacity

Table 2, Section 2g, Field 52

Not filled

Unit of Measure

Table 2, Section 2g, Field 53

Not filled

Price Time Interval Quantities

Table 2, Section 2g, Field 54

Not filled

Option Data

Option Type

Table 2, Section 2h, Field 55

Displays whether the contract is a put or a call.

Derived from the "Put/Call" indicator set for the financial transaction:

  • 1 Put -> P

  • 2 Call -> C

Option Style

Table 2, Section 2h, Field 56

Provides details about how the option is exercised:

A = American

B = Bermudan (multiple exercise times)

E = European

S = Asian

Derived from the option style of the financial transaction:

1 European -> E

2 American -> A

Strike Currency

Table 2, Section 2h, Field 57

Filled with the strike currency.

Strike Price

Table 2, Section 2h, Field 57

Filled with the strike amount of the option.

Derived Business Partner Data

Counterparty ID

Table 1, Field 2

Identifier of the reporting company

LEI or BIC or an interim entity identifier or a client code

Not filled by SAP

Counterparty ID Identifier

The abbreviation specifies which ID code applies.

Examples:

  • LEI

  • BIC

ID of the Other Counterparty

Table 1, Field 3

Identifier of the other business partner LEI or BIC or an interim entity identifier or a client code

LEI, BIC, and so on, of the counterparty

Note Note

In the Customizing activity Define Settings for Trade Repository, you specify which unique ID is selected.

End of the note.

Other Counterparty ID Identifier

The abbreviation specifies which ID code applies.

Examples:

  • LEI

  • BIC

Counterparty Name

Table 1, Field 4

Not filled

Counterparty Domicile

Table 1, Field 5

Not filled

Corporate Sector of the Counterparty

Table 1, Field 6

Not filled

Counterparty Financial Sector

Table 1, Field 7

Display whether the reporting company is a financial or non-financial counterparty (NFC).

F = Financial Counterparty

N = Non-Financial Counterparty (NFC)

Not filled

Broker ID

Table 1, Field 8

If the broker involved is not a business partner.

Filled when the transaction has a partner in this role assigned on the Partner Assignment tab.

Identifier of the Broker ID

The abbreviation specifies which ID code applies.

Examples:

  • LEI

  • BIC

ID of the reporting entity

Table 1, Field 9

If the entity that is required to report has delegated communication of the message to a third party, this field must be filled with the LEI or the BIC of the reporting entity.

Not filled

Identifier for the ID of the reporting entity

The abbreviation specifies which ID code applies.

Examples:

  • LEI

  • BIC

Clearing Member ID

Table 1, Field 10

If the reporting entity is not a clearing member, the LEI or BIC of the relevant clearing member needs to be entered here.

The system fills this field with the counterparty of the financial transaction (= counterparty of the clearing account) for all financial transactions for which clearing has been performed.

Identifier of the Clearing Member ID

The abbreviation specifies which ID code applies.

Examples:

  • LEI

  • BIC

Beneficiary ID

Table 1, Field 11

LEI or BIC of the party subject to the rights and obligations arising from the contract when this party is not a counterparty of this contract.

Not filled

Identifier of the Beneficiary ID

The abbreviation specifies which ID code applies.

Examples:

  • LEI

  • BIC

Trading Capacity

Table 1, Field 12

Specifies whether the reporting business partner has concluded the financial transaction as the principal (P) or as the agent (A).

Always filled with P.

Counterparty Side

Table 1, Field 13

Specifies whether the contract is a buy or a sell.

  • B = Buy

  • S = Sell

This field is filled on the basis of the value of the transaction category of the financial transaction:

  • 100 = Buy -> B

  • 200 = Sell -> S

  • 300 = Issue: Placement -> B

  • 400 = Issue: Buyback -> B

  • 500 = Close Transaction -> S

  • 600 = Forward -> B

Domicile Not in Validity Area of Legal Basis

Table 1, Field 14

Specifies whether the other counterparty is domiciled outside the EU.

Y = Yes

N = No

Filled with N when the country of the other counterparty is a member state the EU. Otherwise, the field is filled with the value Y.

To fill the field, the system applies the settings made in the Customizing activity Assign Countries to Legal Basis.

Linked to Commercial Activity

Table 1, Field 15

Provides information about whether the transaction is linked directly with exercising the commercial activity or whether it is purely a financial transaction.

If the reporting entity is a financial counterparty, the field must remain empty.

Y = Yes

N = No

Filled with Y in the case of financial transactions for which the Risk Mitigation indicator is set (on the Administration tab in the financial transaction). Otherwise, the field is filled with the value N.

Clearing Threshold

Table 1, Field 16

Provides information about whether the reporting company is above or below the clearing threshold.

Y = Above

N = Below

Not filled

Derived Content Data

You can use the derived content data structures for your own fields. You can fill the fields using the BAdI and the derivation tool provided.