17 CHANGES IN THIS VERSION

17.1 Changes compared to FpML 5.3 WD #1

• In multiple views:
  • Added support for modeling people (such as employees) and business units within parties, and added detail to the partyTradeInformation block to allow their role within a transaction to be recorded. (This is still in progress and may be adjusted in a future draft.)
  • Added several fields to the partyTradeInformation to support SDR reporting (these are mostly needed for recordkeeping view, but are available in other views as well. Fields include "collateralized" indicator, a "boardOfDirectorsApproval", field, and a verificationPurpose field. Also renamed confirmationType to confirmationPurpose. (This is still in progress and may be adjusted in a future draft.)
  • Adjusted the "attachment" element in "documentation" to support multiple attachments per trade.
  • Interest Rate Derivatives:
    • (Excluding Transparency view) Implemented IRD WG proposal to incorporate the new Supplement to the 2006 ISDA Definitions relating to physical settlement of swaptions.
• Confirmation:
  • Within ClearingStatus->ClearingStatusItem complex type, added an optional 'reason' element within to explain the reported clearing status value to message consumers.
  • Reverted the maximum cardinality of onBehalfOf to 0..1 in Confirmation view. Rationale: The Business Process Working Group formally voted in favor of reverting the cardinality of onBehalfOf in Confirmation view to 0..1 since the use case for more than 1 onBehalfOf has not been established.
  • Within RequestEventStatus->EventIdentifier and EventStatusItem->EventIdentifier complex types, the Business Process Working Group decided to deprecate the sequence number to avoid misuse as sequence number does not make sense in this context.
• The following issues have been resolved:
  • http://www.fpml.org/issues/view.php?id=1073
  • http://www.fpml.org/issues/view.php?id=1070
  • http://www.fpml.org/issues/view.php?id=1063

View PDF for details on schema changes

View PDF for details on validation rules changes

View SCHEME DEFINITIONS for details on coding schemes changes

• Interest Rate Derivatives:
  • (Excluding Transparency view) Implemented IRD WG proposal to incorporate the new Supplement to the 2006 ISDA Definitions relating to physical settlement of swaptions.
• Message Framework:
  • Added a requestRetransmission message to allow a part of a portfolio or a report to be requested again.
  • Added an optional "parentCorrelationId" to allow the parent process of a nested process to be recorded.
  • Enhanced the requestEventStatus message to support additional event identifiers, and to allow the business process to be specified.
  • Added support for modeling people (such as employees) and business units within parties, and added detail to the partyTradeInformation block to allow their role within a transaction to be recorded. (This is still in progress and may be adjusted in a future draft.)
  • Added several fields to the partyTradeInformation to support SDR reporting (these are mostly needed for recordkeeping view, but are available in other views as well. Fields include "collateralized" indicator, a "boardOfDirectorsApproval", field, and a verificationPurpose field. Also renamed confirmationType to confirmationPurpose. (This is still in progress and may be adjusted in a future draft.)
  • Adjusted the "attachment" element in "documentation" to support multiple attachments per trade.
• Confirmation:
  • Reverted the maximum cardinality of onBehalfOf to 0..1 in Confirmation view.
  • Within ClearingStatus->ClearingStatusItem complex type, added an optional 'reason' element within to explain the reported clearing status value to message consumers.

None.

• Reporting and Business Process:
  • Added two new views, "Transparency" and "Recordkeeping", to support public and nonpublic reporting into swaps data repositories (SDRs).
  • Trade and Termination Events
    • Added the optional "originatingEvent" element to generic messages when the event is a new Trade. This element allows the sender to provide additional explanation as to why the new trade was created. Also added a corresponding coding scheme.
    • Added the optional "terminatingEvent" element to generic messages when the event is a Termination. This element allows the sender to provide additional explanation as to why the new trade was terminated. Also added a corresponding coding scheme.
  • Consent Negotiation
    • Added the optional "requestedAction" element to indicate why consent is being sought, and a corresponding coding scheme.
    • Added documentation to describe how the consent negotiation messages can be used to request consent for clearing a trade.
  • Maturity Notification
    • Added a new message that can report on trades that have matured. This can be used for options that have expired or any trade that has passed its final event and can be removed from the active portfolio.
  • Message Framework:
    • Correlation IDs and sequence numbers have been made optional for initial requests and notifications.
    • Increased the maximum multiplicity of correlation IDs to 2 to allow services to return their own correlation ID to correspond to the submitter's correlation ID.
    • Allowed exception messages to include the original message as unvalidated XML.
    • Allowed acknowledgement messages to include the original message as unvalidated XML.
    • Added enhancements to better report trade amalgamation (netting, compression).
    • Added enhancements to handle portfolio requests (portfolio-type business processes).
  • Business Process:
    • Added a "Clearing" Event as an available event type in clearing messages.
    • Allowed tradeReferenceInformation (IDs and trade information) to be reported in place of full trade/event details in a number of messages
    • Enhanced the clearing status message to allow information about which parties are affecting status (e.g. pending approval to clear)
    • Added the ability to record valuation information (quotes) for many event messages
    • Added the "TradeReferenceInformationUpdate" process to allow identifying information such as trade IDs to be updated for existing trades.
    • Provide more examples of consent messages for clearing, with additional details.
    • Allowed acknowledgment messages for most event requests to contain summary information such as trade IDs, to allow acknowledgers to supply additional identifying information about trades.
    • Updated partyTradeInformation to include all fields from recordkeeping view (as optional).

None.