September 22, 2016

ISDA has published FpML 5.9 Recommendation

ISDA Press Release The International Swaps and Derivatives Association, Inc. (ISDA) today published the recommendation for Financial products Markup Language (FpML) version 5.9. The latest version of FpML – an open-source standard for the exchange of information for the electronic dealing and processing of derivatives – focuses on regulatory reporting. This comes in response to several regulatory developments, including the US Securities and Exchange Commission’s security based swaps reporting requirements and further clarification on the reporting obligations with the European Union’s revised Markets in Financial Instruments Directive and associated regulation (MIFID II/MIFIR). Version 5.9 also incorporates amendments made to the reporting treatment of cleared derivatives made by the US Commodity Futures Trading Commission. On top of this, the new recommendation includes improvements and updates to coding schemes and examples of how they can be applied to further increase data quality. Other changes comprise the addition of new interest rate, foreign exchange and securities (repo) products within pre-trade process functionality, such as credit limit checking. In addition, support for equities has expanded with the inclusion of equity volatility swaps. The below details the complete list of changes in version 5.9 compared to version 5.8. Changes compared to FpML 5.8 Recommendation#2
  • Equity Derivatives:
o    Added support for Equity Volatility Swaps under ISDA 2011 and 2002 Definitions.
  • Pre-trade Products:
o    Added back ETTF/FpML-FIX Collaboration Working Group models for Interest Rate Swap and Credit Default Swap. Added additional elements following the requirements to support Pre-trade and Credit Limit Check processes. o    In addition, to fully support Credit Limit Check and other Pre-trade processes, number of IRD (FRA, Swaption), FX (FX Flexible Forward, Vanilla and Digital Options, Variance and Volatility Swaps, Accruals and Targets) products were added in Pretrade view. o    Added support for Repo product.
  • Regulatory Reporting:
o    Added support for SEC SBSR rules. o    ESMA MiFID II Technical Standards
  • Added fields to support post-trade events - see PartyTradeInformation/TransactionClassification.model.
  • Added support for algorithms.
o    ESMA EMIR RTS Clearing obligation - changed the mandatorilyClearable field to an FpML-defined Boolean type based on a coding scheme including “true”, “false” and “X”. o    ESMA EMIR RTS - Fields  have been added to close gaps:
  • Reporting level - ESMA requires an indication whether the report is done at trade or position level. A new field was added in tradeSummary/reportingLevel.
  • Index factor - ESMA requires the factor to apply to the Notional to adjust it to all the previous credit events in that Index series. A new field was added in tradeSummary/indexFactor to be used for Credit Derivatives.
  • Commodity time duration -  A new field was added in SettlementPeriods/timeDuration to represent load delivery intervals.
  • Added support for “WD” (weekdays) and “WE” (weekend) in applicable days for commodities. The values represent the days of the week of the delivery, for commodities energy.
  • Added ability to specify credit seniority of the trade.
o    Added an example to illustrate support for CFTC Clearing ("Amendments to Swap Data Recordkeeping and Reporting Requirements for Cleared Swaps"). o    Enhanced tradingEvent to handle non-currency notionals. o    Enhanced ValuationReportRetracted - Added a lightweight partyTradeInformation to valuationReportRetracted to support retraction of the trade in dual-sided reporting scenarios. This allows to clarify which party has the ESMA obligation. o    Predetermined Clearing – Added examples to illustrate the use of predeterminedClearingOrganizationPartyReference. Support for predetermined clearing was added in version 5.8. o    Joint and Several Liability – Defined a default coding scheme for groupType (partyGroupTypeScheme with default URIhttp://www.fpml.org/coding-scheme/party-group-type and initial value JointAndSeveralLiability) o    Pricing Context – Further expanded and clarified the usage of pricingContext under the contexts of a recordkeeping submission, and of real-time public reporting. o    An extensive cleanup of examples and coding schemes has been completed to improve data quality and better reflect actual usage at trade repositories.
  • Business Process:
o    Added support for barrier and digital option events. o    Added back the additionalEvent business event as an extension point for all messages. This was already present in all 5.x versions but was omitted in error in version 5.8. o    Made the withdrawal business event available to most of the business processes but clearing. o    Added back ETTF/FpML-FIX Collaboration Working Group models for Interest Rate Swap and Credit Default Swap. Added additional elements following the requirements to support Pre-trade and Credit Limit Check processes. o    In addition, to fully support Credit Limit Check and other Pre-trade processes, number of IRD (FRA, Swaption), FX (FX Flexible Forward, Vanilla and Digital Options, Variance and Volatility Swaps, Accruals and Targets) products were added in Pretrade view. o    Added support for Repo product. Incompatible changes compared to FpML 5.8 Recommendation#2
  • Reporting:
o    Removed the deprecated nonSchemaProduct from the schema to avoid any confusion with the existing genericProduct.
  • Pre-trade:
o    Made the FxAccrualRegionBound.model within FxAccrualRegion required for most of the views. o    Added back the ETTF/FpML-FIX Collaboration Working Group models for Interest Rate Swap and Credit Default Swap that were omitted in error in version 5.5. This results in non-backward compatible changes in the pre-trade view that should be viewed as fixes of existing flaws in the schema since the models were too loose for these products.
  • Equity Derivatives:
o    Schema tightening - Certain structures were tightened to make the schema less ambiguous and improve guidance for implementers. This results in non-backward compatible changes that should be viewed as fixes of existing flaws; as such, changes should not invalidate any existing, meaningful document.
  • Within CalculationFromObservation type: Instead of sequence, create a mandatory choice of [InitialLevel and initialLevelSource] and initialLevelSource. The first branch would be used only for AgreedInitialPrice. If initiallevel is present this would infer AgreedInitialPrice, initialLevelSource= AgreedInitialPrice can be optionally provided for clarity. The second branch would be used for elections other than AgreedInitialPriceprice.
  • Within extraordinaryEvents type, deprecated tenderOffer Boolean element in favor of using just tenderOfferEvents. Documented the tenderOfferEvents usage, as “If tenderOfferEvents is NOT provided, No Tender Offer is applicable. If provided, Tender Offer is applicable, all events within EquityCorporateEvents type are turned on and the consequences must be provided.
  • Within EquityValuation, grouped into an optional choice elements: futuresPriceValution and optionsPriceValuation. Rationale: they should be mutually exclusive as they both answer the same question.
  • Renamed ClassifiedPayment to ClassifiablePayment. Rationale: one can choose not to classify it. Note: under FpML guideline, it is considered a backward compatible change. The change affected products: CorrelationSwap, VarianceSwap, VolatilitySwap.
FpML is the industry standard for derivatives and complex products. A Recommendation is the final step in the development process of a version. The latest version of the open-source standard is available on the FpML website: www.fpml.org. More information on the timing of future versions can be found in the FpML roadmap: http://www.fpml.org/roadmap.pdf.