[h_mcallister]

Hi, these properties (issue date, first accrual date) sound like reference data relating to the bond, rather than contractual properties of the option as such – so probably should be modelled as properties of the bond underlyer. The Bond type in FpML does contain a number of optional reference data items (e.g. issuerName, seniority, couponType, couponRate …), however the dates you mention are not currently supported.

You are welcome to propose these Bond properties for addition to the Standard, but that may not help with your immediate requirement. Are you able to add these as local extensions to the Bond type e.g. in a private extension namespace?

I don’t recommend re-using existing elements e.g. relevantUnderlyingDate, other than for their intended purpose.

Best regards,
Harry

• This reply was modified 8 years, 7 months ago by h_mcallister.
• This reply was modified 8 years, 7 months ago by h_mcallister.

[h_mcallister]

Hi Roma,

dealtCurrency is an optional extension to the FxSingleLeg model, allowing the message producer to express their view on which is the “dealt” currency in an FX Spot/Forward trade. The element takes enumerated values (ExchangedCurrency1, ExchangedCurrency2), so as to restrict the choice to the currencies exchanged in the trade.

As far as the concept is relevant to a FX Swap, then I agree that the values on the near and far legs would be inverted with respect to each other, so as to reference the *same* currency on each leg.

As far as I am aware, no official guidance was published on the use of dealtCurrency in Fx Swaps – this may be an omission in the specification.

Best regards,
Harry

[h_mcallister]

Hi, FpML versions are not discontinued, as such. FpML has a current version (5-8 at the time of writing, soon to transition to 5-9) – but this simply represents the latest state of development of the standard. Implementers can (and do) remain using older versions while these continue to meet their functional requirements. Indeed, some industry utilities offer the ability to interact with their services at multiple FpML versions, depending on the user’s preference.

In your case the decision on when to upgrade to 5-8 (or 5-9) will likely be driven by your functional requirements, and the requirements of any clients/consumers of FpML with whom you interact. If you don’t need functionality offered in a later version of FpML, or if this is not supported by the consumers of FpML which you publish, then there is no immediate need to upgrade.

Ideally it should be possible to accept upgrades within a FpML major version series without undue impact. If message consumers adopt appropriate safeguards with respect to forward compatibility, then you should be able to avoid the need to upgrade all parts of your system architecture in lock-step. It may be preferable to build relatively frequent minor upgrades into your process, than to perform a rare but disruptive “big bang” upgrade when forced by new functional requirements.

Best regards,
Harry

[h_mcallister]

Hi Yoong,

Yes, front and back stubs can be represented in the same message, by specifying both firstRegularPeriodStartDate and lastRegularPeriodEndDate. stubPeriodType should be regarded as an optional extra – I suggest omitting it in the case where both front and back stubs exist.

Best regards,
Harry

• This reply was modified 8 years, 9 months ago by h_mcallister.

[h_mcallister]

Hi,

USI/UTI are represented in FpML using the “issuer” form of partyTradeIdentifier i.e. containing issuer and tradeId elements. Interpretation as USI or UTI is (for better or worse) controlled by the choice of issuerIdScheme value:

UTI: issuerIdScheme=”http://www.fpml.org/coding-scheme/external/issuer-identifier”

USI: issuerIdScheme=”http://www.fpml.org/coding-scheme/external/cftc/issuer-identifier”

A FpML submission can contain both USI & UTI by creating an instance of partyTradeIdentifier for each, with their respective issuer elements appropriately qualified using the issuerIdScheme.

[h_mcallister]

Hi YC,

That’s not what the answer at #1760 implies.

FpML supports both front and back stubs, represented by firstRegularPeriodStartDate and lastRegularPeriodEndDate respectively. As the previous answer states, the length of the stub (short or long) can be calculated by comparing the calculationPerodFrequency (length of a regular period), with the duration of the stub (interval between effectiveDate and firstRegularPeriodStartDate, or lastRegularPeriodEndDate and terminatonDate).

The stubPeriodType element can be used to signal the stub length for convenience, in the case where there is only one stub, but is not a substitute for [first|last]RegularPeriod[Start|End]Date.

Hope that helps (?)

Harry McAllister
Chair, FpML IRD WG

• This reply was modified 8 years, 9 months ago by h_mcallister.
• This reply was modified 8 years, 9 months ago by h_mcallister.

[h_mcallister]

Hi Alex,

Meant to reply to your post a few days ago – looks like you already have the answers you need. Anyway here goes …

In principle, the effective date and initial notional are “historical facts” reflecting the external reality of the contract confirmed with your counterparty. From this point of view, the initial (i.e. original) notional remains the same regardless of the current notional at a given point in time.

However a trade management system may manage versioning as a linked series of trade records, each commencing at the start date of current period (as at the date of the business event which triggers creation of the version). In this case, each successive version is naturally represented with effective date and initial notional as per the “current” period – as you say, a forward looking view of the trade which avoids the problem of past cash attributed to expired periods.

Both views of the trade are valid – it depends on the purpose they are used for. For example you may need to be access the initial version of the trade (with original effective date & notional) for external confirmation of a post-trade event such as a novation.

Regardless of which approach you take, the initial notional should always be consistent with the effective date of the trade version.

[h_mcallister]

Hi Vitalina,

I think you are referring to Cleared Physical Settlement for swaptions … (?)
This is supported by the swaption/physicalSettlement block (in choice with cashSettlement). This contains a mandatory clearedPhysicalSettlement boolean flag, and optional predeterminedClearingOrganizationPartyReference. The clearedPhysicalSettlement flag indicates whether the swaption is intended to exercise into a cleared swap, while the party reference allows the clearer for the resulting swap to be identified (if known).

So the clearer for the swaption should be identified in the context of the trade as usual e.g. by producing partyTradeInformation/relatedParty with partyRole ‘ClearingOrganization’), and the clearer for the resulting swap (physically exercised underlyer) should be identified via swaption/physicalSettlement as described above.

Please let me know if this answers your question …

Best regards,
Harry McAllister
Chair, FpML IRD-WG

• This reply was modified 9 years, 1 month ago by h_mcallister.
• This reply was modified 9 years, 1 month ago by h_mcallister.
• This reply was modified 9 years, 1 month ago by h_mcallister.

[h_mcallister]

Hi Jonathan,

Oversight, for sure; the Architecture may be due an overhaul but 3.0 is the latest iteration, so should appear on the Current page.

Thanks,
Harry

[h_mcallister]

Hi, I have to disagree with the statement that the “floating leg should be also settled in [a] different currency” in this case. Example ird-ex29 represents a cross-currency swap paying fixed on KRW against 3M USD Libor. The fixed leg is non-deliverable, settling in USD; the floating leg settles in the currency of its notional i.e. USD also – this is not an unusual arrangement. Given that the [i]settlementProvision[/i] applies (only) to the stream in which it appears in the cross-currency case, producing [i]settlementProvision[/i] under both streams in the single-currency case is a consistent approach. Indeed this may be easier for both message producer and consumer, as there is no requirement to check whether local settlement provisions also apply to the “other” leg. In general, FpML usage for IR swaps avoids referencing across streams, and repetition of information within streams is tolerated for ease of processing (e.g. calculation period dates, payment dates, notional amount …). Best regards, Harry

[h_mcallister]

Hi Nelya, No: the decompounding formula might be used to calculate the applicable rate for a stub on a swap fixed leg – but in this case decompounding is simply the rate calculation method, not a contractual feature of the trade. The trade is matched/confirmed/reported on the stub rate value, not the formula used to derive it. Best regards, Harry McAllister Chair, FpML IRD-WG

[h_mcallister]

Hi Alex, I agree with your interpretation; fx fixing for notional exchange typically occurs at or immediately before the payment date, consistent with the example description. The FpML sample implies otherwise, and is therefore incorrect. * We might also expect the [i]cashflows[/i] block to contain [i]principalExchange[/i] elements, to illustrate usage in this type of swap. We’ll look to have this fixed, probably in the New Year now. Best regards, Harry McAllister

[h_mcallister]

Hi Alex, The solution to your dilemma hinges on the definition of a stub period. A stub exists only in relation to a following/preceding schedule of (one or more) regular periods. The swap described above comprises a single, irregular period – firstRegularPeriodStartDate makes no sense in the context as there are no subsequent regular periods. In this case, it is appopriate to specify the calculationPeriod-, payment- and (where relevant) reset- frequencies as “1T”, similar to the convention for single period OIS swaps. In answer to your final questions: (1) No, IRD-16 is not applicable here; (2) Yes, it is correct to omit firstRegularPeriodStartDate, because there are no subsequent regular periods; (3) No, this would be inconsistent and a mis-representation; (4) Yes, we should specify calculationPeriodFrequency – and other relevant frequencies – as 1T. Best regards, Harry McAllister Chair, IRD-WG

[h_mcallister]

This looks like a use case for the onBehalfOf element, indicating that the message sender is performing the function on behalf of another party. [Apologies for the late response – just saw this post]

[h_mcallister]

Hi Gagan, No: we are saying that we normally expect the [i]businessDayConvention[/i] in [i]calculationPeriodDates[/i] and [i]resetDates[/i] to be the same. It is quite possible to specify unadjusted period dates for accrual (i.e. [i]calculationPeriodDatesAdjustment/businessDayConvention[/i]=NONE), with adjusted dates for payment (e.g. [i]paymentDatesAdjustments/businessDayConvention[/i]=MODFOLLOWING). Please see my earlier post on a related issue at the link below (I think you commented on the thread). Best regards, Harry http://www.fpml.org/dev/modules/newbbex/viewtopic.php?viewmode=thread&topic_id=155&forum=4&post_id=355#355

[Author]

Posts