schemas.fpml-5-12.confirmation.fpml-confirmation-processes-5-12.xsd Maven / Gradle / Ivy
A message indicating that a request to allocate a trade has been approved by the sender.
A message indicating that a request to allocate a trade has been refused by the sender.
A message describing the approvals currently applied to the trade and their status (e.g. pending, approved, refused).
All of the approvals for a specific trade.
A structure describing a trade registration event that is part of a clearing process.
The original trade or event submitted to the clearing service.
The trades or events generated by the clearing service as a result of clearing.
A message indicating that a clearing request has been acted on and as a result a trade has been cleared.
A message indicating that a clearing request has not been acted on due to a business decision and therefore no trade has been cleared.
A message providing the current status of a clearing request. The Clearing Status message is designed to be sent from the Clearing House to the participants. The message sends the clearing status of the trade or the trade package. It’s a centralized model so there is no perspective.
Describes the status of the clearing process relating to the identified trade.
A message indicating that a confirmation has been agreed by a counterparty.
A message indicating that a confirmation has not been agreed by a counterparty.
A message indicating that a confirmation request has been withdrawn by the submitter.
A structure describing an option exercise event. The optionExercise event supports partial exercise (specify the number of options or amount to exercise), full exercise (use fullExercise flag), as well as the option to request options not to be exercised.
Message for sending matching results. Response message that returns the status of an event that have been submitted for matching.
Defines the confirmation status of a trade or post-trade event (e.g. Matched, Mismatched, Unmatched, Alleged).
Event (trade or post-trade event) asserted by one of the parties.
"Other side's" event (trade or post-trade event) that meets the minimimum matching criteria and is proposed as match to the event that is being asserted.
Event (trade post-trade event) asserted by the "other side's" party.
A message indicating that the sender grants consent for the recipient to perform the requested action.
The type of approval (e.g. "pre-clearing credit").
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 needs to approve the specified item (e.g. trade or allocation).
An identifer for a specific appoval, to allow the approval to be identified and tracked.
A message indicating that the sender does not grant consent for the recipient to perform the requested action.
The type of approval (e.g. "pre-clearing credit").
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 needs to approve the specified item (e.g. trade or allocation).
Defines the structure for a message acknowledging an event request.
A message advising a third party that a trade execution has occurred.
Collateralization block, that holds Regulator specific requirement about the trades' collateralization, is added here to accommodate a technical implementation of SFTR. The change aligns with the established principle that the content in recordkeeping view is now also available in the confirmation view for both functional and technical reasons. The appropriate place for this information is 'regulatoryDisclosure' and 'nonpublicExecutionReport' messages in the Recordkeeping view.
Details of the payments, like amount breakdowns, settlement information.
A message that withdraws an advice to a third party that a trade execution has occurred.
Details of the payments, like amount breakdowns, settlement information.
A message notifying a party that a trade execution has occurred. (Typically this is sent by an execution platform to a participant.)
Collateralization block, that holds Regulator specific requirement about the trades' collateralization, is added here to accommodate a technical implementation of SFTR. The change aligns with the established principle that the content in recordkeeping view is now also available in the confirmation view for both functional and technical reasons. The appropriate place for this information is 'regulatoryDisclosure' and 'nonpublicExecutionReport' messages in the Recordkeeping view.
A message retracting a notification to a party that a trade execution has occurred. (Typically this is sent by an execution platform to a participant.)
A structure describing an option exercise event. The optionExercise event supports partial exercise (specify the number of options or amount to exercise), full exercise (use fullExercise flag), as well as the option to request options not to be exercised.
A message used to notify another party that a trade has matured. This can be used to report, for example, that a swap has passed its final payment and can be removed, or that an option has expired without being executed.
A message requesting that a trade be split among several accounts.
Identifies a related party performing a role within the transaction.
A message withdrawing a request that a trade be split among several accounts.
A message requesting that a trade be cleared by a clearing service.
A structure describing a declear event. The deClear event allows a firm to request that a trade be removed from clearing, or a clearing service to request consent for this, or to report that it has been done.
A message withdrawing a request that a trade be cleared by a clearing service.
A structure describing a declear event. The deClear event allows a firm to request that a trade be removed from clearing, or a clearing service to request consent for this, or to report that it has been done.
The name of the service to which the message applies
The type of change requested for the collateral allocation.
The party paying the margin / issuing the allocation request.
Allocation details
A type that describes the type of collateral allocation action that is requested. The purpose is to allow FCMs to specify how the allocations are to be processed.
A message type defining the start of the confirmation process. The message may be used to request the confirmation of a new trade or any other event supported by FpML such as novation, terminations, amendments, etc.
A structure describing an option exercise event. The optionExercise event supports partial exercise (specify the number of options or amount to exercise), full exercise (use fullExercise flag), as well as the option to request options not to be exercised.
A message requesting that the sender be authorized by the recipient to peform an action.
The reason the consent was requested.
The type of approval (e.g. "pre-clearing credit").
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 needs to approve the specified item (e.g. trade or allocation).
A structure describing a declear event. The deClear event allows a firm to request that a trade be removed from clearing, or a clearing service to request consent for this, or to report that it has been done.
A message withdrawing a request that the sender be authorized by the recipient to peform an action.
The type of approval (e.g. "pre-clearing credit").
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 needs to approve the specified item (e.g. trade or allocation).
A structure describing a declear event. The deClear event allows a firm to request that a trade be removed from clearing, or a clearing service to request consent for this, or to report that it has been done.
A message requesting that an order be executed.
A structure describing an option exercise event. The optionExercise event supports partial exercise (specify the number of options or amount to exercise), full exercise (use fullExercise flag), as well as the option to request options not to be exercised.
A message withdrawing a request that an order be executed.
A structure describing an option exercise event. The optionExercise event supports partial exercise (specify the number of options or amount to exercise), full exercise (use fullExercise flag), as well as the option to request options not to be exercised.
Defines the structure for a message requesting information updates to a trade. The trade reference information should contain at least one trade identifier that the recipient is aware of.
Defines the structure for a message retracting a request to updated information about trade.
Defines the structure for a message indicating that a trade is being changed due to a non-negotiated event.
Describes the details of the change.
Details of the payments, like amount breakdowns, settlement information.
Defines the structure for a message retracting a prior change advice.
The qualified identifiers of the subject trade.
Describes the details of the change being retracted.
Details of the payments, like amount breakdowns, settlement information.
A structure that contains a business event.
Events/Results that are applicable to clearing processes.
This may be used to describe why a trade was terminated.
A structure describing a declear event. The deClear event allows a firm to request that a trade be removed from clearing, or a clearing service to request consent for this, or to report that it has been done.
Defines a model group that allows either details of an event or information about a trade to be provided. Typically this will be used in a response to a request.
Confirmation messages.
The confirmation process starts with the requestConfirmation message. The message may be used to request the confirmation of a new trade or any other event supported by FpML such as novation, terminations, amendments, etc.
A requestConfirmation message may be cancelled using the requestConfirmationRetracted message.
A business acknowledgement message to indicate that the previously sent message was sucessfully processed.
A message sent to inform another system that some exception has been detected.
The confirmationStatus message provides the status of the matching process: matched, mismatched, unmatched, or alleged. It may also provide the best fit trade(s) or event(s) as result of the matching process.
The confirmationAgreed message is sent when the matching process returns a proposed match (trade or event) and the Confirmation Requester agrees with it.
The confirmationDisputed message is sent when the matching process returns a proposed match (trade or event) and the Confirmation Requester disputes it.
© 2015 - 2025 Weber Informatics LLC | Privacy Policy