FpML - Financial products Markup Language - ISSUES

0001082: review rule shared-19

Review if rule is still current or if it needs to be updated.

See related issues.

0001081: review rule shared-29: need to use also account element

Rule shared-29 (not published yet) compares buyerPartyReference/@href and sellerPartyReference/@href

The rule can be seen in the attached image.

We need to check if this rule should also compare the account fields and check what context the rule should have.

0001071: Multiplicity of onBehalfOf element

Email from Lyteck:

Request from the BPWG/RPTWG to develop a new messaging rule to handle the Multiplicity of the onBehalfOf field – the BPWG evaluated and approved a request from the RPTWG to allow multiple on-behalf-of elements in a message to an SDR.

We wrote down an action to ask the VALWG.

- “>> We discussed developing a validation rule (e.g., A maximum of 4 onBehalfOf elements should only occur in novation flows. In other cases the number of fields should at most be 2).”

- The BPWG agreed to increase the cardinality of onBehalfOf from 0..1 to 0..4 globally for all the messages in 5.3 WD1 (The draft should be available for review by the Coordination Committee by the end of September). Up to 4 parties may be involved in a transaction, in the case of a novation.

- In 5.2 and earlier, the field is currently used in the following message types: ResponseMessage, NotificationMessage, NonCorrectableRequestMessage, CorrectableRequestMessage, CorrectableRequestMessageMediated

- Background: This topic had been discussed at the BPWG forum in the past there were some concerns that making a global change would make the usage of this field unclear. At the time the discussion resulted in a localized change (the multiplicity of the onBehalfOf field was set to 0..2 in select messages of type CorrectableRequestMessageMediated). These original concerns may have been raised at a time where OTC transactions were mainly bilateral. This is gradually changing in the new landscape where SEF, SDR, DCO and other central services may transact on behalf of the parties.

I think we may need two complementary rules (suggested drafts shown below) for further guidance from the VALWG:

msg-5 (Mandatory)
English Description:
Context: messages that contain onBehalfOf (derived from base types noted above)
If the message contains a novation element, the maximum number of onBehalfOf fields must be 4.

msg-6 (Mandatory)
English Description:
Context: messages that contain onBehalfOf
If the message does not contain a novation element, the maximum number of onBehalfOf fields must be 2.

0001042: Description of ird-12

Rule ird-12 states:

ird-12 (Mandatory)
English Description:
Context: CalculationPeriodDates (complex type)
The frequency specified in calculationPeriodFrequency must divide the precisely. This means that by stepping through the period from the start date at the specified frequency, it must be possible to reach the end date.

What does happen with stubs? Shouldn't the rule include the cases with stubs?

0001080: NotionalStepRule/stepFrequency has incorrect type

In NotionalStepRule (type of notionalStepParameters), element stepFrequency has type Period. This type should be reserved for non-recurring intervals e.g. date offsets. The type of stepFrequency should be amended to Frequency.

Also: annotation for stepFrequency should be *amended* to:

The frequency at which *notional* step changes occur. This frequency must be *an integer multiple* of the stream calculation period frequency.

0001078: Missing Inflation Publication Codes

Hi

I did not notice any main publication code for Statitistics South Africa and Central Statistics Office Ireland. Can these be added next update?

Statistics South Africa = "STSA" ?
Central Statistics Office Ireland - "CSOI" ?

Thanks

(From forum http://www.fpml.org/dev/modules/newbbex/viewtopic.php?topic_id=126&forum=2)

0001077: Two index id elements defined

in the fpml-cd-5.3 working draft 1 and 2 xsd's the indexid is described twice. see below

A CDS index identifier (e.g. RED pair code).

A CDS index identifier (e.g. RED pair code).

0001076: No schema annotation in OptionExercise, OptionExpiry & DeClear

Top-level elements in types OptionExercise, OptionExpiry & DeClear have no annotation in the schema (see: fpml-business-events-5-x.xsd). This should be corrected in the 5-2 & 5-3 Recommendations, and retrospectively in 5-1.

Also: elements exerciseIn[NotionalAmount|NumberOfOptions|Number OfUnits] are documented in terms of "the fixed amount by which the option should be exercised". This implies an instruction, or statement of intent, to exercise the option at some point in future. However in some use cases, e.g. executionAdvice, the message is reporting the historical fact of exercise. Suggest more neutral wording would be appropriate e.g "amount by which the option is exercised".

An observation: the naming of the exerciseIn- elements is unfortunate - the "In" seems both unintuitive and redundant. Was this done by back-formation from "changeIn-" NotionalAmount etc.? Acknowledged, this is too late to change now.

0001029: Review of FX Validation Rules for new CrossRate component

FX WG has proposed a very informal notation for new rules to address the relationship between currencies in quotedCurrencyPair and the currencies inside the crossRate structures (http://www.fpml.org/_wgmail/_fxwgmail/msg00140.html).

Context: exchangeRate[crossRate]
There exists exactly one crossRate having either currency1=quotedCurrencyPair/currency1 or currency2=quotedCurrencyPair/currency1

Context: exchangeRate[crossRate]
There exists at exactly one crossRate having either currency1=quotedCurrencyPair/currency2 or currency2=quotedCurrencyPair/currency2

Context: crossRate
currency1 != currency2

Context: crossRate[currency1!=quotedCurrencyPair/currency1][currency1!=quotedCurrencyPair/currency2]
currency1=sibling::crossRate/currency1 or currency1=sibling::crossRate/currency2

Context: crossRate[currency2!=quotedCurrencyPair/currency1][currency2!=quotedCurrencyPair/currency2]
currency2=sibling::crossRate/currency1 or currency2=sibling::crossRate/currency2

FX WG is looking for help with reviewing the proposed informal notation for the new rules http://www.fpml.org/_wgmail/_fxwgmail/msg00140.html and formulating it into a correct FpML validation rules.

0001075: 2 untyped elements: RequestPortfolio\asOfDate RequestPositionReport\asOfDate

In fpml-reporting-4-9.xsd RequestPositionReport\asOfDate has no type.

In fpml-reconciliation-4-9.xsd RequestPortfolio\asOfDate has no type.

Presume xsd:date is wanted in both cases.

0001074: review Context of msg rules

Need to review context and text of msg rules.

Use the context colleciton() and document() generally means that the description of a rule needs to be updated.

colleciton() and document() are Xquery function. They should be documented better.

0001072: Inconsistent use of plural form in values of asset-class coding scheme

Values of coding scheme asset-class-1-0 (http://www.fpml.org/coding-scheme/asset-class-1-0.xml) mix singular and plural forms inconsistently e.g. Credit, ForeignExchange; but InterestRate*s*, Equit*ies*, Commodit*ies*.

The singluar form is preferred and should be used consistently:
Credit, InterestRate, ForeignExchange, Equity, Commodity.

0001069: Change in the use of Product elements

Reviewing the 5.2 schema I noticed that the abstract Product element has been modified and the documentation associated with the elements has been changed. I don't believe the changes where necessary to match the requirements of the proposed regulation.

1. It is not necessarly to add an explicit element to contain the asset class it could easily have been accommodated as a referencing an specific asset class scheme.

As the world's regulators are unlikely to agree on a universal scheme there will always need to be an explicit schema associated with each code and its is not more difficult to generate and process ...

InterestRate

.. as it is ..

InterestRate

2. A UPI will only contain a subset of the data fields that define a derivative product therefore two similar but different products may end up with the same UPI code. The original usage of the element was that it allowed specific products to be identified. Using this element for a non-specific UPI seems counter intuitive to me. The UPI is more a product type code and should be also be stored in a element with a suitable qualifying scheme URL.

It is entire possible that some other regulators will combine the concepts of asset class and product type into a single structured code value (as in the CFI).

I would this to see the 5.2 and 5.3 product models reverted to thier old design and the usage of their elements better documented.

0000503: NovationMatched message missing definition

fpml-matching-status.xsd(7):

0001064: ClearingStatus clearingStatusItem model

[Per Last Call Working Draft - July 29, 2011 (build 3)]
The ClearingStatus message model is confusing:
- is it the status of clearing as a whole or specific item(s) within clearing that is the subject matter? The wording clearingStatusItem suggests the latter; the specification documentation the former.
- clearingStatusValue is unusual naming - without an associated clearingValueType
- statusAppliesTo - Annotated definition: “Reference to parties currently in this status, e.g. parties for which we are awaiting approval.” There is no ‘we’ in a party neutral message. Current state or future state? Either there is one state at a point in time that is recognised by all parties, or every party can have its own status at a point in time. Generally it is quite unclear as to how this is meant to be used.

0000995: Documentation for Future Multiplier

The definition of //element(*, Future)/multiplier in the documentation is uncler.

I have seen it confused with period Multiplier, price Multipliers and even when used correctly to multiply contract numbers, the calculation isn't always correct.

Element multiplier IS-A xsd:positiveInteger which is documented as "Specifies the contract multiplier that can be associated with the number of units".

The data type is correct, but the description is unclear. The purpose of a multiplier is to add leverage - as one example, take the contract specification for the E-mini S&P 500 on the CME, where the multiplier is 50 times the synthetic ( futures price ) of the Index

http://www.cmegroup.com/trading/equity-index/us-index/e-mini-sandp500_contract_specifications.html

Contract Size $50 x E-mini S&P 500 futures price

Please see attached example of Dollar Future on the BMF ( Brazil ) exchange which uses the public extensions to FpML Andrew Parry wrote, so you have for example as a natural way of representing the scale of the transaction.

NB - Andrew Parry contributed to the analysis of this.

0000927: ird-14 needs to handle relative dates

ird-14 handles effectiveDate but not relativeEffectiveDate

The rule today is:
"
Context: CalculationPeriodDates (complex type)
terminationDate/unadjustedDate gt effectiveDate/unadjustedDate
"

We can either put a guard on the context to limit the rule to effectiveDate, or we can also evaluate the relativeEffectiveDates

With a guard:
"
Context: CalculationPeriodDates (complex type)[exists(effectiveDate)]
terminationDate/unadjustedDate gt effectiveDate/unadjustedDate
"

Handling just the relativeEffectiveDate would be:
"
Context: CalculationPeriodDates (complex type)[exists(relativeEffectiveDate)][not(exists(relativeEffectiveDate/dayType))]
terminationDate/unadjustedDate gt (id(relativeEffectiveDate/dateRelativeTo/@href) + interivalDuration(relativeEffectiveDate/periodMultiplier, relativeEffectiveDate/period))
"
The guard [not(exists(relativeEffectiveDate/dayType))] is necessary because we cannot do dayType calculations. We should check with Harry the rule applies before dayType calculations, not afterwards as I am unsure of this.

The two cases (relativeEffectiveDate and effectiveDate), could be combined into one rule.

-----Original Message-----
From: valwg@fpml.org [mailto:valwg@fpml.org] On Behalf Of Christian Nentwich
Sent: 21 April 2009 10:06
To: valwg@fpml.org
Subject: Re: FpML-VAL cd-26 unhandled case

Matthew,

if the rules need to be complete with respect to optionality, you'll
find quite a few others where this is not the case - because they were
not originally written with that in mind.

For example ird-14:

terminationDate/unadjustedDate gt effectiveDate/unadjustedDate

A swap might have a relativeEffectiveDate instead of effectiveDate...
Anybody got a fine tooth comb handy?

Christian

0001058: Commodity coding scheme issues

- quantityFrequencyScheme - attribute name is inconsistent with scheme name (commodityFrequencyScheme)
- The following coding schemes are missing from http://www.fpml.org/coding-scheme:
- commodityOilProductTypeScheme
- commodityExpireRelativeToEventScheme
- commodityPayRelativeToEventScheme
- deliveryPointScheme
- gasQualityScheme

0001012: The 5-x Confirmation View Validation rules ref-10, ref-30, ref-32 need new invalid test-cases

The 5-x Confirmation View Validation rules ref-10, ref-30, ref-32 need new invalid test cases:
the existing invalid cases have the following issues:
- invalid-ref-10-01 (currently used in requestValuationReport message)
- invalid-ref-30-01 (currently used in valuationDocument message)
- invalid-ref-32-01 (currently used in fx product )

0001013: 5.0 Reporting View Validation Rules

The following validation rules were removed from Confirmation View and will be added to the Reporting View once the validation rules for Reporting View are created:
- ref-14, ref-15, ref-16, ref-17 – in reconciliation
- ref-18 – in mktenv
- ref- 19, ref-22, ref-23, ref-24, ref-36 - in valuation and riskdef
- ref- 20, ref-21 - in riskdef
- ref- 31 - in mktenv and riskdef
- ref- 37- in valuation, mktenv and riskdef

0001053: Inconsistent element definitions

In the MultipleExercise complex the type of the minimumNumberOfOptions element is xsd:nonNegativeInteger while the type of maximumNumberOfOptions element is NonNegativeDecimal.

I suspect the maximum value should also be a xsd:nonNegativeInteger.

Any comments?

0000815: fx-12 needs defining completely

The current fx-12 leaves a large amount to interpretation:

"
fx-12 (Mandatory)
Context: FxAverageRateOption (complex type)
[exists(averageRateObservationSchedule)]
The values of observedRates/observationDate should match the calculated schedule dates derived from parameters defined within the averageRateObservationSchedule element and the business day calendar implied by fixingTime/businessCenter.
"

The rule must define: "match", "calculated schedule date", the derivation process in "derived", and the calculation in "implied".

At the moment it is more of a comment than a rule.

0000532: Make rate observation representation for FX and IRD consistent.

Modeling change recommendation: As part of FX rate structuring, attempt to make rate observation representation for FX and IRD consistent.

0001026: Normalizing all FpML payment types

Coordination Committee has agreed on 2010-10-19 teleconference that it is important for FpML shared payment types to be normalized (to re-use NonNegativePayment type that includes payer/receiver direction, paymentDate and paymentAmount). Since it is a non backward compatible change, the proposal is to deprecate all payment structures in favor of normalized ones. Alternatively, (assuming nobody is using 5.0 yet) make the change within the existing types.

0000997: Refactor ExerciseProcedure type

Between FpML 4.2 and 4.3 two additional optional elements where added to ExerciseProcedure to support bond options namely limitedRightToConfirm and splitTicket. The new elements appear as valid content within the Swaption product even though they are not appropriate.

I would like to use the original portion of this class in the refactored 5.0 FX products and propose to reinstate the ExerciseProcedure as it was in 4.2 and create extension from it called BondOptionExerciseProcedure type for use in bond options.

This will remove the two bond option specific elements from Swaption. We might like to make the same change in the 4.x series