minOccurs not defined for observationWeight in fpml 5.11 schema

[Saoussen.ayed]

Hi All,

We’re using FPML 5.11 and started validating our messages.

We faced issue with observationWeight:

Expected element ‘observationWeight@http://www.fisglobal.com/FpML-5/confirmation’ before the end of the content in element rateObservation@http://www.fisglobal.com/FpML-5/confirmation

While checking the schema, no minOccurs is defined for observationWeight:

<xsd:element name=”observationWeight” type=”xsd:positiveInteger”>
<xsd:annotation>
<xsd:documentation xml:lang=”en”>The number of days weighting to be associated with the rate observation, i.e. the number of days such rate is in effect. This is applicable in the case of a weighted average method of calculation where more than one reset date is established for a single calculation period.</xsd:documentation>
</xsd:annotation>
</xsd:element>

It’s defined for all the other tags part of rateObservation, but not the obeservationWeight.

When checking on the fpml site (https://www.fpml.org/spec/fpml-5-5-4-tr-1/html/reporting/schemaDocumentation/schemas/fpml-ird-5-5_xsd/complexTypes/FloatingRateDefinition/rateObservation.html) it shows minOccurs as 0.

Could you please clarify if the schema is missing minOccurs as 0 or it’s expected to set set it to default value (1) ?

The main issue being that we don’t receive this tag at all from CCP, it’s not even defined in their specification.

Thank your very much for your help on this !

[iyermakova]

Hello Saoussen,

You are correct. The elements’ minOccurs is set to “1” by default.
So, if you do not see minOccurs in the element observationWeight, then minOccurs=1 [swap/swapStream/cashflows/paymentCalculationPeriod/calculationPeriod/floatingRateDefinition/rateObservation/observationWeight].

That said, FpML has different namespaces that define a different business requirement: Confirmation, Recordkeeping, Transparency, Reporting, Pretrade and Legal views.

For example:
Confirmation view: used for confirming the precise details of contracts and post-trade business events. It has a very detailed product representation capturing the details needed for a transaction confirmation.

Recordkeeping view: used for reporting the Primary Economic Terms of derivative transactions to Swaps Data Repositories from entities including market participants, execution platforms, and clearing or confirmation services. This view is intended to have similar characteristics to the FpML “confirmation view” product representation, i.e. a very detailed product representation capturing the details needed for a transaction valuation; it may not include all documentation and legal terms.

Etc. You can read a summary on FpML views here – https://www.fpml.org/spec/fpml-5-11-8-rec-1/

The link you picked to demonstrate the optionality of the observationWeight element is for Reporting view.

Reporting view: used for reporting trading and business activities and positions (including as part of STP flows), as well as processes such as reconciliation. This view has a loose product representation; it requires key economic information such as the notional, key dates, and parties, but leaves other information optional.

So, depending on the FpML view (FpML schema set) you pick, the optionality of the elements might differ. Looking at the namespace you provided, you are using the Confirmation view, where observationWeight is a mandatory element. Your CCP must be using different than Confirmation view, if element observationWeight is optional.

Regards,
Irina Yermakova

• This reply was modified 3 years, 11 months ago by iyermakova.
• This reply was modified 3 years, 11 months ago by iyermakova.

[Saoussen.ayed]

Hi Irina,

Thanks for your reply.

Indeed, when I refer to https://www.fpml.org/spec/fpml-5-11-8-rec-1/html/confirmation/schemaDocumentation/index.html, I see observationWeight as minOccurs 1.

However, when I dig it”s definition, it seems applicable only when more than 1 resetDate is applicable. the resetDate element is defined as minOccurs=0.

that’s why I’m not sure why the observationWeight is the only element inside rateObservation to be expected as minOccurs 1.

I’ll reach out to CCP on this. But I would really appreciate if you can provide an explanation why it was made as minOccurs 1.

Thank you very much !

Saoussen

[iyermakova]

Hello Saoussen,

We are currently reviewing the issue with swap/swapStream/cashflows/paymentCalculationPeriod/calculationPeriod/floatingRateDefinition/rateObservation/observationWeight field.
It seems that the FpML Architecture Working Group is in agreement that within RateObservation complex type, observationWeight element should be optional and adjustedFixingDate – required (see FpML examples). Although, the element adjustedFixingDate cannot be made required (because this would be a backward incompatible change), the group considering making observationWeight optional, documenting that in absents of this element, it defaults to 1.
I will let you know on the AWG’s decision.

Regards,
Irina Yermakova

[Saoussen.ayed]

Thanks for your reply Irina !
It’s clear now and we’ll wait for the final decision.
For now, we’ve manually modified the schema to allow validating our messages.

Kind Regards,
Saoussen

[iyermakova]

Hello Saoussen,

The Standards Committee approved the change, making swap/swapStream/cashflows/paymentCalculationPeriod/calculationPeriod/floatingRateDefinition/rateObservation/observationWeight field optional.

We started the update of FpML versions. Please find the first FpML version that was published with the fix: https://www.fpml.org/spec/fpml-5-5-11-rec-3/

It might take a while to update 5-11 recommendation.

Regards,
Irina Yermakova

[Author]

Posts