ISDA has published FpML 5.10 Second Working Draft

The International Swaps and Derivatives Association, Inc. (ISDA) has published the Second Working Draft for Financial products Markup Language (FpML) version 5.10. Changes compared to the FpML 5.10 First Working Draft include:

Regulatory Reporting

• • Reporting Redesign [Recordkeeping View]
    • Background: The FpML Regulatory Reporting Working Group has been studying lessons learned from 5 years of use of FpML for regulatory reporting. It has identified a number of issues that have been reported with FpML for this purpose, and is working on some proposals to address these issues. Please see the "FpML Regulatory Redesign" paper at http://www.fpml.org/latest_news/fpml-publishes-a-discussion-paper-fpml-for-regulatory-reporting-design-improvement-ideas/for more detail.
    • In this working draft we include a preliminary design of a new, simplified regulatory reporting message that the working group is working on, for comment from a broader audience. The working group cautions that this message is work in progress, and may be changed extensively prior to publication, moved to a future version of FpML, or removed entirely.
    • ISDA invites the industry to review a first draft of the messages included in Recordkeeping view of FpML 5.10 WD#2. Stakeholders are encouraged to participate in the discussions taking place in the FpML Reporting Working Group.
    • Please return any comments on these new formats to rptwgchair@fpml.org.
    • Benefits of the simplified reporting messages include:
      • Simplified message/data representation
      • Simpler trade and event structure
      • Much closer to regulatory requirements
      • Clearer handling of reporting-regime specific information
      • Simpler, well-defined message flow for adding and removing jurisdictions to/from reporting
      • Improves data quality
    • The redesigned effort reduces complexity and results in a simpler message more aligned with what regulators are looking for. A more flexible reporting standard enables firms to become more agile and adapt to regulatory demands and changes. The new format benefits existing users of FpML.
    • Examples and documentation
      • See documentation section "3. Business Process Architecture Specification" subsection "3.3.1 Reporting Redesign"
      • See [Recordkeeping View]\reg-report-full-product - New reporting format with full product representation
      • See [Recordkeeping View]\reg-report-flat-product - New reporting format with flattened product economics
      • See [Recordkeeping View]\reg-report-events - New reporting format showing valuation reporting, withdrawal and acknowledgement
      • See [Recordkeeping View]\reg-report-samples - Source FpML examples used to generate new reporting format
      • See the examples in Recordkeeping view in folders "reg-reporting-full-product" (new message formats but containing the existing full FpML product representation) and "reg-report-flat-product" (new message formats with flattened product economics).
      • Note that a handful of Commodities examples are still being worked on and may not validate against the schema. This will be fixed in the next draft.
      • The FpML RPTWG has also developed demonstration XSLT scripts for converting from existing FpML formats (which are contained in folder "reg-report-samples") to the other formats, at least for the product types and variations in the sample set. These scripts can be accessed from the FpML SVN repository or via the FpML regulatory reporting working group. If the working group eventually publishes the new formats as part of the standard, it is expected that these scripts would also be published.

• ESMA MiFID II Support

• • Reporting Regime - added regime-specific party roles
    • Provides support for RTS 22 Fields # 11-20 Buyer/Seller
    • This provides the ability to represent roles e.g. Buyer/Seller in a regime-specific way.
    • See [Recordkeeping View]\ex-170
  • Algorithm - updated representation leverages existing person as an algorithm (i.e. algorithm modeled as a pseudo-person)
    • Provides support for RTS 22 Fields # 57 “Investment decision within firm” and # 59 “Execution within firm”
    • deprecated: partyTradeInformation/algorithm - The algorithm element introduced in version 5.9 is currently marked as deprecated in WD2 (in favor of using a relatedPerson pointing to a party/person with a coding scheme that indicates it is an algorithm.)
      • In the next draft (LCWD), the algorithm element will reverted (i.e., set as not deprecated as there was no official decision from the group to deprecate). Guidance for developers on which representation to use is being developed.
    • See [Recordkeeping View]\ex-170
  • Trade Identification - cleaned up examples to specify combinations of UTI/USI, UTI only, and USI only scenarios (see ex-140, 140b, 142b)
  • Added support for Credit Index Factor and Seniority.
    • added indexReferenceInformation/seniority
    • added indexReferenceInformation/indexFactor
    • deprecated: productSummary/seniority
    • deprecated: productSummary/indexFactor
    • See [Recordkeeping View]\products\record-ex03-cds-emir-index-seniority-factor.xml
  • [Confirmation View] Added a Warrant underlyer to underlyingAsset
    • In the context of MIFID II and transaction reporting (and for internal messaging) there have been requests to cover warrant transactions in FpML.
    • See documentation under "5. Cross-Asset Product Architecture" subsection "5.5 Underlying Asset"
    • See [Confirmation View]\business-processes\execution-advice\msg-ex68-execution-advice-warrant.xml
  • Extended exchange traded future and option models
    • Added a proposal to extend the future and option underlying asset models in the recordkeeping view, to support reporting of reference data about exchange traded instruments as required under RTS 22 of the MiFID II/MiFIR regulation. The intention is to facilitate use of the instrumentTradeDetails product model in MiFIR reporting workflows. The principal use case is to support population of fields 42-56 under the RTS, where ISIN is not available or where the instrument is traded on a non-EEA venue.
    • See documentation under "5. Cross-Asset Product Architecture" subsection "5.4 Underlying Asset"

Syndicated Loan (Confirmation View)

• • Loan Trading Notifications
    • In FpML 5.10, comprehensive coverage of loan trading notifications is introduced. The core enhancements to messaging architecture include:
      • The ability to convey information in relation to all loan trade lifecycle events.
      • Addition of a tasks-based model (similar to the event-based model) which allows the communication of responsibilities in relation to tasks which are prerequisites to the loan trade settlement.
    • The working group believes that the basis for the loan trading notifications is designed flexibly, to anticipate future loan trading market needs.
  • Loan Bulk Servicing Notification
    • In FpML 5.10, the concept of a bulk servicing notification is introduced. This notification allows the combination of multiple servicing events into a single notification.
  • Loan Party Profile Notification
    • In FpML 5.10, the ability to convey loan party profile details, including contact information and settlement instructions, is introduced.

 

Incompatible changes compared to FpML 5.8 and 5.9 Recommendations

• Syndicated Loan (Confirmation View)
  • paymentDetails has been renamed to eventPayment affecting the following messages:
    • accrualOptionChangeNotification, accruingFeeChangeNotification, accruingFeePaymentNotification, accruingPikPaymentNotification, facilityNotification, facilityRateChangeNotification, lcNotification, loanContractNotification, nonRecurringFeePaymentNotification, prepaymentNotification, rolloverNotification
  • rolloverNotification/rollover now wraps elements (maturityContracts, currentContracts, baseRateSet, borroing, commitmentAdjustment, interestCapitalization, interestPayment, repayment).
    • This also affects the rolloverNotificationRetracted which allows the inclusion of the same content found in the rolloverNotification (The loanwg may make corrections in 5.10 LCWD)
  • These changes break backward compatibility with the rolloverNotification introduced in FpML 5.8. Rationale: the changes better reflect market usage and provide increased design flexibility. There are no known implementations of the 5.8 or 5.9 loan messages. The loanwg believes the impact of making these changes is minimal.

The Second Working Draft is available on the FpML website in the Specifications section at: http://www.fpml.org/spec/fpml-5-10-2-wd-2 More information on the coverage and timing of future versions can be found in the FpML roadmap: http://www.fpml.org/roadmap.pdf Please send us any comments by filling in the form at http://www.fpml.org/issues The FpML Team