schemas.fpml-schemas.fpml-doc-5-9.xsd Maven / Gradle / Ivy
The name of the algorithm.
The category of the function of the algorithm. The related
individual performs the role specified in this field for the base party. For example, if the
role is "Trader", the related person acts acts or acted as the base party's trader.
A type describing a role played by an algorithm in one or more
transactions. Examples include roles such as TradingDecision, RoutingDecision. This can be extended to
provide custom roles.
Unique ID for the allocation. Multiple allocation trade IDs are
provided to allow for the use of USI/UTI representations along with party-specific trade
identifiers.
The party and/or account to which this trade is being allocated.
The fractional allocation (0.45 = 45%) of the notional and
"block" fees to this particular client subaccount.
The notional allocation (amount and currency) to this
particular client account.
Code that describes what type of allocation applies to the trade. Options
include Unallocated, PreAllocation, PostAllocation.
The allocations for a single side of a trade.
A pointer style reference to one of the parties to the trade,
defined elsewhere in the document. The party referenced has requested its position in the trade
to be allocated to several other parties or accounts.
A specific approval state in the workflow.
The type of approval (e.g. "pre-clearing credit").
The current state of approval (.e.g preapproved, pending approval,
etc.)
The full name or identifiying ID of the relevant approver.
A pointer style reference to a party defined elsewhere in the
document. The party referenced has approved the specified item (e.g. trade or allocation).
A pointer style reference to a party defined elsewhere in the
document. The party referenced was approved for the specified item (e.g. trade or allocation) by
the approving party (if specified).
An identifer for a specific appoval, to allow the approval to be
identified and tracked.
An approval identifier allocated by a party. FpML does not define the
domain values associated with this element.
A type that qualifies the type of approval.
The current status value of a clearing request.
Code that describes what type of collateral is posted by a party to a
transaction. Options include Uncollateralized, Partial, Full, One-Way.
A type used to represent the type of mechanism that can be used to confirm
a trade.
A contact id identifier allocated by a party. FpML does not define the
domain values associated with this element.
A type defining a contract identifier issued by the indicated party.
A pointer style reference to a party identifier defined elsewhere
in the document. The party referenced has allocated the contract identifier.
Where the legal activity is to agree a contract of variation then
the business process should be to modify a contract. This is a contract in its own right and not
a version of a previous contract. Where the business process is to replace and supersede a
contract then you have a new contract and a contract version should not be used.
A contract id which is not version aware.
A contract id which is version aware.
This element corresponds to the Credit Event Notice Delivered Under
Old Transaction and Deemed Delivered Under New Transaction under the EXHIBIT C to 2004 ISDA
Novation Definitions.
This element corresponds to the Notice of Publicly Available
Information Delivered Under Old Transaction and Deemed Delivered Under New Transaction under the
EXHIBIT C to 2004 ISDA Novation Definitions.
This element corresponds to the Notice of Intended Physical
Settlement Delivered Under Old Transaction under the EXHIBIT C to 2004 ISDA Novation
Definitions.
A credit arrangement used in support of swaps trading.
A type defining a content model that is backwards compatible with older
FpML releases and which can be used to contain sets of data without expressing any processing intention.
Indicates which party (and accounts) a trade is being
processed for.
The root element in an FpML trade document.
An arbitary grouping of trade references (and possibly
other portfolios).
The abstract base type from which all FpML compliant messages and documents
must be derived.
Records supporting information justifying an end user exception under 17
CFR part 39.
What arrangements will be made to provide credit? (e.g. CSA,
collateral pledge, guaranty, available resources, financing).
Allows the organization to specify which categories or
characteristics apply to it for end-user exception determination. Examples include
"FinancialEntity", "CaptiveFinanceUnit", "BoardOfDirectorsApproval".
Allows the relevant transaction level categories or characteristics
to be recorded for end-user exception determination. Examples include
"BoardOfDirectorsApproval", "HedgesCommercialRisk".
Allows the organization to specify which if any relevant regulators
it is registered with, and if so their identification number. For example, it could specify that
it is SEC registered and provide its Central Index Key.
A type describing the entity of a party, for example Financial,
NonFinancial etc.
A type defining the trade execution date time and the source of it. For use
inside containing types which already have a Reference to a Party that has assigned this trade execution
date time.
Identification of the source (e.g. clock id) generating the
execution date time.
A type used to represent the type of market where a trade can be
executed.
A type used to represent the type of market where a trade can be
executed.
Provides supporting evidence when a party invoked exception to not execute
the trade on facility such as SEF and DCM even though the particular product is mandated to execute on a
SEF.
Reason for not executing the trade on SEF or other facility.
Allows the organization to specify which categories or
characteristics apply to it for end-user exception determination. Examples include
"FinancialEntity", "CaptiveFinanceUnit", "BoardOfDirectorsApproval".
Allows the relevant transaction level categories or characteristics
to be recorded for end-user exception determination. Examples include
"BoardOfDirectorsApproval", "HedgesCommercialRisk".
Allows the organization to specify which if any relevant regulators
it is registered with, and if so their identification number. For example, it could specify that
it is SEC registered and provide its Central Index Key.
The economics of a trade of a multiply traded instrument.
The FpML asset description for the asset.
A description of how much of the instrument was traded.
The price paid for the instrument.
The value, in instrument currency, of the amount of the
instrument that was traded.
A structure describing the amount of an instrument that was traded.
The (absolute) number of units of the underlying instrument that
were traded.
The monetary value of the security (eg. fixed income security) that
was traded).
A structure describing the price paid for the instrument.
The date interest started accruing for the accrued interest
calculation on an interest bearing security.
The date when a distribution of dividends or interest is deducted
from a securities asset, or set aside for payment to the original bondholders. From the ex-date,
any dividends that are owing on the security are paid to the original owner. As a consequence of
this, on the ex-date, the securities price typically drops by the amount of the distribution
(plus or minus any market activity).
Whether the accrued interest in included when the trade settles.
("true" means accrued interest is not included when the trade settles.)
A structure describing the value in "native" currency of an instrument that
was traded.
The net and/or gross value of the amount traded in native
currency.
The data type used for link identifiers.
A structure including a net and/or a gross amount and possibly fees and
commissions.
Net and/or gross amount.
How a notional is to be reported for this reporting regime. E.g. for ESMA
EMIR, it would be Nominal or Monetary Amount
A type that an identifier for an order.
A type that an order's identifier(s).
A characteristic of an organization used in declaring an end-user
exception.
Indicator as to the type of transaction in accordance with Articles
20(3)(a) and 21(5)(a) of Regulation (EU) 600/2014.
A type defining additional information that may be recorded against a
package of trades.
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.
Used to categorize trades into user-defined categories, such as
house trades vs. customer trades.
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.
Allows timing information about a trade to be recorded.
Specifies whether the trade is anticipated to be allocated.
Specifies whether the trade is anticipated to be allocated, has
been allocated, or will not be allocated.
Specifies whether the trade is anticipated to be cleared via a
derivative clearing organization
Describes the status with respect to clearing (e.g.
AwaitingAcceptance, Pending, Accepted, Rejected, etc.)
Used to describe the type of venue where trade was executed, e.g
via an execution facility or privately.
Summary information about a trade package.
A type that describes what thpe of package this is, e.g. Butterfly.
A type that specifies the classification of a party.
A pointer style reference to a party identifier defined elsewhere
in the document. The party referenced has the classification in the associated
"entityClassification" element below.
Indicates the category or classification or business role of the
organization referenced by the partyTradeInformation with respect to this reporting regime, for
example Financial, NonFinancial etc.
A type to represent a portfolio name for a particular party.
A pointer style reference to a party identifier defined elsewhere
in the document. The party referenced has allocated the trade identifier.
A type containing a code representing how two parties are related, e.g.
Affiliated, Intragroup, None.
A type defining one or more trade identifiers allocated to the trade by a
party. A link identifier allows the trade to be associated with other related trades, e.g. trades
forming part of a larger structured transaction. It is expected that for external communication of trade
there will be only one tradeId sent in the document per party.
A link identifier allowing the trade to be associated with
other related trades, e.g. the linkId may contain a tradeId for an associated trade or
several related trades may be given the same linkId. FpML does not define the domain
values associated with this element. Note that the domain values for this element are
not strictly an enumerated list.
The trade id of the allocated trade. This is used by
the block trade to reference the allocated trade.
The trade id of a resulting trade (beta or gamma trade)
that resulted from this trade during a clearing or similar operation (e.g. prime
brokerage).
The trade id of the block trade. This is used by each one
of the allocated trades to reference the block trade. This element can also represent
the trade id of the parent trade for N-level allocations. In the case, this element is
only used to model N-level allocations in which the trade acts as block and allocated
trade at the same time. This basically means the ability to allocate a block trade to
multiple allocation trades, and then allocate these in turn to other allocation trades
(and so on if desired).
The trade id of the trade(s) upon which this was based, for
example the ID of the trade that was submitted for clearing if this is a cleared trade,
or of the original trade if this was novated or cancelled and rebooked, or the list of
trades that were netted or compressed together in the case of a compression event. The
originatingEvent will explain why the trade was created; the existence and number of
originatingTradeId elements should correspond to the originatingEvent, and they should
be interpreted using that field. If the trade is inside a business event structure (such
as a novation or a compression event) this element shuld not be populated; instead the
event shoudl be used to represent the other trades.
Deprecated: The USIs of the components of this trade, when
this trade contains a strategy.
A type containing multiple partyTradeIdentifier.
A type defining party-specific additional information that may be recorded
against a trade.
Identifies that party that has ownership of this information. For
shared trade information, this will reference the originator of the date (for example, an
execution facility or clearinghouse).
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.
Identifies the role of this party in reporting this trade (e.g.
originator, counterparty).
Identifies the unit/division/desk etc. that executed or supports
this trade
Provides information about a unit/division/desk etc. that executed
or supports this trade
Provides information about a person that executed or supports this
trade
Provides information about an algorithm that executed or otherwise
participated in this trade this trade
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?)
Used to categorize trades into user-defined categories, such as
house trades vs. customer trades.
Identifies the person or persons who assumed the role of trader for
this trade. New implementations are encouraged to use the relatedPerson structure instead.
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.
Allows timing information about a trade to be recorded.
Specifies whether the trade is anticipated to be allocated.
Specifies whether the trade is anticipated to be allocated, has
been allocated, or will not be allocated.
Specifies whether the trade is anticipated to be cleared via a
derivative clearing organization
Describes the status with respect to clearing (e.g.
AwaitingAcceptance, Pending, Accepted, Rejected, etc.)
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.
Provides a name, code, or other identifier for the collateral
portfolio to which this belongs.
Allows the organization to specify which if any relevant regulators
or other supervisory bodies this is relevant for, and what reporting rules apply.
Specifies whether the trade is not obligated to be cleared
via a derivative clearing organization, i.e. wehter there is an exemption from clearing.
For historical reasons this is called "end-user exception", but this may be used to
indication any exception from normal clearing mandates caused by the type of the
partiees or their relationship, such as inter-affiliate trades. If a relatedParty block
with a role of ClearingExceptionParty is present, that related party indicates which
party is claiming the end user exception.
Specifies a reason that the trade is exempted from a
clearing requirement. This exemption may be an end-user exception, or another type such
as in inter-affiliate trade.
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.
Indicates that the trade has price-affecting characteristics in
addition to the standard real-time reportable terms. The flag indicates that the price for this
trade is not to be construed as being indicative of the market for standardised trades with
otherwise identical reportable terms.
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.)
Describes why the price of this trade does not reflect the current
market price. For example, the trade may have been traded off-market as part of a termination or
compression operation.
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.
Used to describe how the trade was executed, e.g. via voice or
electronically.
Used to describe the type of venue where trade was executed, e.g
via an execution facility or privately.
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.
Used to describe how the trade was confirmed, e.g via a
confirmation facility, via private electronic service, or via written documentation. This
affects the process flow for confirmation messages. This field is provisional pending detailed
confirmation of the data requirements, and may not be included in subsequent working drafts.
Specifies whether this trade is a result of compression activity.
Provides classification of the transaction being reported
Used to report whether the trade is in dispute
A type defining a content model for a calculation rule defined as
percentage of the notional amount.
A percentage of the notional amount.
A reference to the notional amount.
A type representing an arbitary grouping of trade references.
The name of the portfolio together with the party that gave the
name.
An arbitary grouping of trade references (and possibly other
portfolios).
The reason a trade is exempted from a clearing mandate.
The data type used for portfolio names.
The reason a trade's price does not reflect the current market price.
Deprecated: A type defining a USI for the a subproduct component of a
strategy.
Indicates which product within a strategy this ID is associated
with.
Summary information about the product that was traded. This is intended
primarily for trade reporting by TRs.
An ID assigned by a regulator to an organization registered with it. (NOTE:
should this just by represented by an alternate party ID?)
How a Boolean value is to be reported for this regulator. Typically "true"
or "false", but for ESMA "X" is also allowed, to indicate not supplied.
A value that explains the reason or purpose that information is being
reported. Examples might include RealTimePublic reporting, PrimaryEconomicTerms reporting, Confirmation
reporting, or Snapshot reporting.
Provides information about how the information in this message is
applicable to a regulatory reporting process.
Identifies the reporting regime under which this data is
reported. For example, Dodd-Frank, MiFID, HongKongOTCDRepository, ODRF
Identifies the specific regulator or other supervisory body
for which this data is produced. For example, CFTC, SEC, UKFSA, ODRF, SFC, ESMA.
Identifies the specific regulator or other supervisory body for
which this data is produced. For example, CFTC, SEC, UKFSA, ODRF, SFC, ESMA.
Identifies the role of this party in reporting this trade for this
regulator; roles could include ReportingParty and Voluntary reporting.
The reason this message is being sent, for example Snapshot, PET,
Confirmation, RealTimePublic.
Whether the particular trade type in question is required by this
regulator to be cleared.
Whether the particular product must be executed on a SEF or
DCM. See to Dodd-Frank section 723(a)(8).
Specifies whether the party invoked exception to not execute
the trade on facility such as SEF and DCM even though the particular product is mandated to
execute on a SEF.
Provides supporting evidence when a party invoked exception to
not execute the trade on facility such as SEF and DCM even though the particular product is
mandated to execute on a SEF.
Indicates whether the counterparty exceeds the volume threshold
above which trades are required to be cleared.
Indicates the category or classification or business role of
the organization referenced by the partyTradeInformation with respect to this reporting
regime, for example Financial, NonFinancial etc.
Indicates the category or classification or business role of a
trade party with respect to this reporting regime, for example Financial, NonFinancial,
Dealer, Non-Dealer, LocalParty, etc.
Indicates how the parties to the trade (the counterparties) are
related to each other with respect to this reporting regime, e.g. Affiliated, Intragroup, etc..
Reports a regulator-specific code for the action associated with
this submission. Used, for example, to report the ESMA action type.
Reports that this trade was executed prior to the enactment of the
relevant reporting regulation.
How the notional amount should be reported for the reporting
regime. For example, for ESMA MiFIR it would be Nominal or MonetaryAmount.
A type containing a code representing the level at which this is reported
(e.g. Trade or Position)
A type containing a code representing the role of a party in a report, e.g.
the originator, the recipient, the counterparty, etc. This is used to clarify which participant's
information is being reported.
A short sale concluded by an investment firm on its own behalf or on behalf
of a client, as described in Article 11.
A type defining a group of products making up a single trade.
Provides distinct identification for a component of a
strategy.
Indicates which product within a strategy represents the
premium payment.
Associates trade identifiers with components of a strategy.
A reference to a party trade ID. If there are multiple trade IDs
for a single component (e.g. USI, UTI, party-specific identifier), create a single
"strategyComponentIdentifier" with a reference to the component, and multiple
tradeIdentifierReferences, one referencing each applicable identifier.
A reference to a component of the strategy (typically a product).
Provides information about a regulator or other supervisory body that an
organization is registered with.
The type or meaning of a timestamp.
A type defining an FpML trade.
The information on the trade which is not product specific, e.g.
trade date.
Other fees or additional payments associated with the trade, e.g.
broker commissions, where one or more of the parties involved are not principal parties involved
in the trade.
Identifies that party (or parties) that brokered this trade.
The party referenced is the ISDA Determination Party that specified
in the related Confirmation as Determination Party.
The party referenced is specified in the related Confirmation as
Barrier Determination Agent.
The party referenced is the ISDA Hedging Party that specified in
the related Confirmation as Hedging, or if no Hedging Party is specified, either party to the
Transaction.
Defines collateral obiligations of a Party
Defines the definitions that govern the document and should include
the year and type of definitions referenced, along with any relevant documentation (such as
master agreement) and the date it was signed.
Identification of the law governing the transaction.
"Short-form" representation of allocations in which the key block
economics are stated once within the trade structure, and the allocation data is contained in
this allocations structure.
A container for approval states in the workflow.
A scheme used to categorize positions.
A type used to record the details of a difference between two business
objects/
The type of difference that exists.
An indication of the severity of the difference.
The name of the element affected.
XPath to the element in the base object.
The value of the element in the base object.
XPath to the element in the other object.
Value of the element in the other trade.
Element(s) that are missing in the other trade.
Element(s) that are extraneous in the other object.
A human readable description of the problem.
A type defining trade related information which is not product specific.
The trade reference identifier(s) allocated to the trade by the
parties involved.
Additional trade information that may be provided by each involved
party.
Information about the trade package if any that the trade
originated from.
The trade date. This is the date the trade was originally executed.
In the case of a novation, the novated part of the trade should be reported (by both the
remaining party and the transferee) using a trade date corresponding to the date the novation
was agreed. The remaining part of a trade should be reported (by both the transferor and the
remaining party) using a trade date corresponding to the original execution date.
If the trade was cleared (novated) through a central counterparty
clearing service, this represents the date the trade was cleared (transferred to the central
counterparty).
A type defining a trade identifier issued by the indicated party.
A pointer style reference to a party identifier and
optionally an account identifier defined elsewhere in the document. The party referenced
has allocated the trade identifier.
A trade identifier accompanied by a version number. In
regulatory reporting views, this should be avoided except for internal mnessaging.
A type defining a trade identifier with a reference to the party that this
trade is associated with.
Allows timing information about when a trade was processed and reported to
be recorded.
When an order was first generated, as recorded for the first time
when it was first entered by a person or generated by a trading algorithm (i.e., the first
record of the order).
The time when an order is submitted by a market participant to an
execution facility, as recorded based on the timestamp of the message that was sent by the
participant. If the participant records this time (i.e. it is in the participant's party trade
information), it will be the time the message was sent. If the execution facility records this
time (i.e. it is in the facility's party trade information), it will be the time the message was
received.
When the public report of this was created or received by this
party. If the participant records this time (i.e. it is in the participant's party trade
information), it will be the time the message was sent. If the execution records this time (i.e.
it is in the facility's party trade information), it will be the time the message was received.
When the public report of this was most recently corrected or
corrections were sent or received by this party.
When the public report of this was first accepted for submission to
a regulator.
When the non-public report of this was created or received by this
party.
When the non-public report of this was first accepted for
submission to a regulator.
When the non-public report of this was most recently corrected or
corrections were received by this party.
When this trade was supplied to a confirmation service or
counterparty for confirmation.
When the most recent correction to this trade was supplied to a
confirmation service or counterparty for confirmation.
When this trade was confirmed.
When this trade was supplied to a clearing service for clearing.
When the most recent correction to this trade was supplied to a
clearing service for clearing.
When this trade was cleared.
When allocations for this trade were submitted or received by this
party.
When allocations for this trade were most recently corrected.
When allocations for this trade were completely processed.
Other timestamps for this trade. This is provisional in
Recordkeeping and Transparency view and may be reviewed in a subsequent draft.
Summary information about the trade.
A generic trade timestamp
Indication as to whether the transaction was executed under a pre-trade
waiver in accordance with Articles 4 and 9 of Regulation (EU) 600/2014.
A characteristic of a transaction used in declaring an end-user
exception.
A reference identifying a rule within a validation scheme.
A type used to represent the type of mechanism that can be used to verify a
trade.
Contract Id with Version Support
The version of the contract id. The contractId is versioned and not
the contract.
Trade Id with Version Support
The version of the trade id. The tradeId is versioned and not the
trade.
Set of attributes that define versioning information.
Indicate which version of the FpML Schema an FpML message adheres to.
This optional attribute can be supplied by a message creator in an FpML
instance to specify which build number of the schema was used to define the message when it was
generated.
The specific build number of this schema version. This attribute is not
included in an instance document. Instead, it is supplied by the XML parser when the document is
validated against the FpML schema and indicates the build number of the schema file. Every time FpML
publishes a change to the schema, validation rules, or examples within a version (e.g., version 4.2)
the actual build number is incremented. If no changes have been made between releases within a
version (i.e. from Trial Recommendation to Recommendation) the actual build number stays the same.
A type to hold trades of multiply-traded instruments such as securities
(e.g., stocks or bonds) or listed derivatives. Typically this will be used to represent the trade
resulting from a physically-settled OTC product where the underlying is a security, for example the
exercise of a physically-settled option.
A strategy product.
The sum that must be posted upfront to collateralize against
counterparty credit risk.
Special credit fee assessed to certain institutions.
A container for approval states in the workflow.
The date of the confirmation executed between the parties and
intended to govern the allocated trade between those parties.
Specifies any relevant parties to the allocation which should be
referenced.
The ISDA calculation agent responsible for performing duties as
defined in the applicable product definitions.
The city in which the office through which ISDA Calculation Agent
is acting for purposes of the transaction is located The short-form confirm for a trade that is
executed under a Sovereign or Asia Pacific Master Confirmation Agreement ( MCA ), does not need
to specify the Calculation Agent. However, the confirm does need to specify the Calculation
Agent City. This is due to the fact that the MCA sets the value for Calculation Agent but does
not set the value for Calculation Agent City.
A group including a net and/or a gross amount.
Value including fees and commissions.
Value excluding fees and commissions.
Value including fees and commissions.
Provides information about a regulator or other supervisory body that an
organization is registered with.
The regulator or other supervisory body the organization is
registered with (e.g. SEC).
The ID assigned by the regulator (e.g. SEC's Central Index Key).
Choice between identification and representation of trade execution.
An element that allows the full details of the trade to be used as
a mechanism for identifying the trade for which the post-trade event pertains
A container since an individual trade can be referenced by two or
more different partyTradeIdentifier elements - each allocated by a different party.
Whether the transaction falls within the scope of activity but is exempted from
reporting under [Securities Financing Transactions Regulation]
Classification of the OTC transaction. Note: Coding scheme definition to
encapsulate: Articles 20(3)(a) and 21(5)(a) of Regulation (EU) 600/2014. e.g.
default="http://www.fpml.org/coding-scheme/external/esma/mifir/otc-classification"
Classification of the pre-trade waiver, if any, that the transaction was executed
under. Note: Coding scheme to encapsulate: Articles 4 and 9 of Regulation (EU) 600/2014. e.g.
default="http://www.fpml.org/coding-scheme/mifir/trading-waiver"
Classification of the transaction as a short sale or not and, if short, of the
type of transaction. Note: Coding scheme to encapsulate: Article 11 of Regulation (EU) 600/2014.
e.g. default="http://www.fpml.org/coding-scheme/mifir/short-sale"
Whether the transaction reduces risk in an objectively measurable way. Only
applicable for commodity derivative transactions.
A list of validation sets the sender asserts the document is valid
with respect to.
© 2015 - 2025 Weber Informatics LLC | Privacy Policy