| partyReference | PartyReference | Reference to a party. | Party. | | 1-1,
mre,
mfr | |
| accountReference | AccountReference | Reference to an account of the party. | Party's account. | | 0-1,
ncf | |
| relatedParty | RelatedParty | This may be used to identify one or more parties that perform a role within the transaction.
If this is within a partyTradeInformation block, the related party performs the role
with respect to the party identifie by the "partyReference" in the partyTradeInformation
block.
| | | 0-∞,
ncf | This is not used in messages to the repository. |
| reportingRole | ReportingRole | Identifies the role of this party in reporting this trade (e.g. originator, counterparty). | | | 0-1,
ncf | This is not used in messages to the repository. |
| relatedBusinessUnit | RelatedBusinessUnit | Provides information about a unit/division/desk etc. that executed or supports this
trade
| | | 0-∞,
ncf | This is not used in messages to the repository. |
| relatedPerson | RelatedPerson | Provides information about a person that executed or supports this trade | | | 0-∞,
ncf | This is not used in messages to the repository. |
| isAccountingHedge | xsd:boolean | Specifies whether the trade used to hedge a risk for accounting purposes for the specified
party. (TODO: do we need to distinguish between asset and liability hedges?)
| | | 0-1,
ncf | This is not used in messages to the repository. |
| category | TradeCategory | Used to categorize trades into user-defined categories, such as house trades vs. customer
trades.
| | | 0-∞,
ncf | This is not used in messages to the repository. |
| executionDateTime | ExecutionDateTime | Trade execution date time, for example as provided by a central execution facility.
Normally this refers to the original execution time of the trade, not the execution
time of any post-trade events that may have affeted it. However, in the case of a
post trade event that reports the new version of the trade (for example, the novation
trade in an novation event, or the amended trade in an amendment event), the execution
date time may contain the time that the newly created or modified trade was created
or modified.
| | | 0-1,
ncf | This is not used in messages to the repository. |
| timestamps | TradeProcessingTimestamps | Allows timing information about a trade to be recorded. | | | 0-1,
ncf | This is not used in messages to the repository. |
| intentToAllocate | xsd:boolean | Specifies whether the trade is anticipated to be allocated. | | | 0-1,
ncf | This is not used in messages to the repository. |
| allocationStatus | AllocationReportingStatus | Specifies whether the trade is anticipated to be allocated, has been allocated, or
will not be allocated.
| | | 0-1,
ncf | This is not used in messages to the repository. |
| intentToClear | xsd:boolean | Specifies whether the trade is anticipated to be cleared via a derivative clearing
organization.
| | | 0-1,
ncf | This is not used in messages to the repository. |
| clearingStatus | ClearingStatusValue | Describes the status with respect to clearing (e.g. Submitted, Pending, Cleared, RejectedForClearing,
etc.)
| | | 0-1,
ncf | This is not used in messages to the repository. |
| collateralizationType | CollateralizationType | Specifies whether this party posts collateral. For Recordkeeping, the collateralization
type refers to collateral that is posted by this firm, and One-Way is not meaningful.
In other words, if the collateralization type is Full, this trade is fully collateralized
by this party. For Transparency view, the options include Full, Partial, Uncollateralized,
and One-Way.
| Collateralization type. | Method of collateralization of trade obligations. | 0-1,
ncf | This is not used in messages to the repository. |
| reportingRegime | ReportingRegime | Allows the organization to specify which if any relevant regulators or other supervisory
bodies this is relevant for, and what reporting rules apply.
| Reporting regime. | | 0-∞,
mre | |
| Choice begin |
| Branch1 |
| endUserException | xsd:boolean | Specifies whether the trade is not obligated to be cleared via a derivative clearing
organization because the "End User Exception" was invoked. If a relatedParty block
with a role of ClearingExceptionParty is present, that related party indicates which
party is claiming the end user exception.
| | | 0-1,
ncf | This is not used in messages to the repository. |
| Branch2 |
| endUserExceptionDeclaration | EndUserExceptionDeclaration | Claims an end user exception and provides supporting evidence. If a relatedParty block
with a role of ClearingExceptionParty is present, that related party indicates which
party is claiming the end user exception.
| | | 0-1,
ncf | This is not used in messages to the repository. |
| Choice end |
| nonStandardTerms | xsd:boolean | | | | 0-1,
mfr | Trade concluded without Master agreement |
| offMarketPrice | xsd:boolean | Indicates that the price does not reflect the current market. For example, in a credit
trade where the two counterparties are not of equal credit standing, there is no initial
margin and one party pays collateral to the other in the form of an add-on to the
price (say a price that would otherwise be 100 at the market is struck at 105 to include
the collateral, resulting in a very off-market looking price.)
| | | 0-1,
ncf | This is not used in messages to the repository. |
| largeSizeTrade | xsd:boolean | Specifies whether the sender of this trade considers it to be a large notional trade
or block trade for reporting purposes, and thus eligible for delayed public reporting.
Normally this will only be applicable for off-facility trades.
| | | 0-1,
ncf | This is not used in messages to the repository. |
| executionType | ExecutionType | Used to describe how the trade was executed, e.g. via voice or electronically. | | | 0-1,
ncf | This is not used in messages to the repository. |
| executionVenueType | ExecutionVenueType | Execution venue type | Execution venue type | | 0-1,
afr | This is not used in messages to the repository. |
| verificationMethod | VerificationMethod | Used to describe how the trade was or will be verified, e.g via a confirmation facility,
via private electronic service, or via written documentation. This affect the timing
of real-time reporting requirements. This field is provisional pending detailed confirmation
of the data requirements, and may not be included in subsequent working drafts.
| | | 0-1,
ncf | This is not used in messages to the repository. |
| confirmationMethod | ConfirmationMethod | | | | 0-1,
ncf | This is not used in messages to the repository. |