Forums

FpML Discussion

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 54 total)
  • Author
    Posts
  • iyermakova
    Spectator

    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

    iyermakova
    Spectator

    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

    iyermakova
    Spectator

    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.
    in reply to: Business Center Scheme – Abu Dhabi Securities Exchange #17762
    iyermakova
    Spectator

    Hi Venkatesh,
    FpML Architecture Working Group (AWG) reviewed your request to add Abu Dhabi Securities Exchange to the FpML Commodity Business Calendar coding scheme and agreed to add “ADSM” code for this exchange. The code has been added to https://www.fpml.org/coding-scheme/commodity-business-calendar.

    The AWG also provided the rules for adding exchange codes to FpML coding schemes (e.g. FpML commodity-business-calendar and business-center ):
    “Exchange codes could be added based on the ISO 10383 MIC code [ https://www.iso20022.org/sites/default/files/ISO10383_MIC/ISO10383_MIC.xls%5D according to the following rules:
    1. it would be the acronym of the MIC. If acronym is not available
    2. it would be the MIC code. If the MIC code starts with an “X”,
    3. the FpML AWG will compose the code.”
    The rule will be added to the affected coding schemes.

    Best regards,
    Irina Yermakova

    in reply to: Business Center Scheme – Abu Dhabi Securities Exchange #17468
    iyermakova
    Spectator

    Hi Venkatesh,
    what FpML coding scheme are you looking at? FpML business calendar location coding scheme includes 4-character codes (see the coding scheme – https://www.fpml.org/coding-scheme/business-center )

    Thank you,
    Irina Yermakova

    in reply to: Business Center Scheme – Abu Dhabi Securities Exchange #17463
    iyermakova
    Spectator

    duplicate response

    in reply to: Business Center Scheme – Abu Dhabi Securities Exchange #17460
    iyermakova
    Spectator

    FpML is using 4 characters code for a business calendar location.
    Ex. NYSE – for NEW YORK STOCK EXCHANGE (https://www.fpml.org/coding-scheme/business-center)
    ADSM – is an acronym for ABU DHABI SECURITIES EXCHANGE (source: https://www.iso20022.org/10383/iso-10383-market-identifier-codes). We will propose this code.

    in reply to: Business Center Scheme – Abu Dhabi Securities Exchange #17458
    iyermakova
    Spectator

    We will propose to add ADSS – for Abu Dhabi Securities Exchange

    in reply to: Repo vs SecurityLending #12783
    iyermakova
    Spectator

    Hi tonyjohn456,

    As you said yourself, theoretically Repo could be used for SB/SL due to similar economics, but the Repo model is missing lots of fee structures needed for SB/SL.

    FpML just announced – FpML Cross Asset Class Product Working Group – Call for Participation. The group will further develop and maintain the FpML product architecture [read the announcement HERE]

    You can bring your SB/SL confirmation samples and proposal to extend FpML products to this group, once it starts working.

    Best regards,
    Irina Yermakova

    • This reply was modified 5 years, 10 months ago by iyermakova.
    in reply to: Commodity Options Use Cases #2162
    iyermakova
    Spectator

    Hello, Have a look at the example 41 (http://www.fpml.org/spec/fpml-5-6-3-tr-1/html/confirmation/fpml-5-6-examples-frame.html): – FpML File: com-ex41-oil-asian-barrier-option-strip.xml – Confirm: com-ex41-oil-asian-barrier-option-strip.pdf or send your confirm example to the FpML Commodities WG to review. Regards, Irina Yermakova

    in reply to: #2113
    iyermakova
    Spectator

    “equityExercise” is of type “EquityExerciseValuationSettlement” and is mainly use for the Valuation and Settlement aspect. This element was designed to support Forwards even though there are no exercises in a Forward, including the European exercise. This may have been done to as Synthetic Forwards can be represented through European Options. If you take a look at the eqf-ex01-forward-stock-long-form.xml example, you’ll see that the choice – the European exercise but then the “expirationDate” is the same as the “valuationDate”. Regards, Irina Yermakova

    in reply to: Redefining whole scheme #2076
    iyermakova
    Spectator

    Hello, 1. Currently, you cannot extend FpML Master Schema. You need to pick a specific view (set of schema with specific business process category see which of the messages you need in your work: e.g. reporting, or record-keeping) first and extend that set of schema instead. – If you need just to add annotations in Russian to the existing FpML schema, you could submit your request to FpML to consider. – To properly extend FpML schema, you cannot modify anything in the schema directly. – Extending the FpML schema with additional types and elements is going on in your ABC schema to which you import FpML schema definitions. Your ABC schema will beginning like this: Best regards, Irina Yermakova

    in reply to: NDF settlement rate option #2049
    iyermakova
    Spectator

    Hello Gary, The FX WG reviewed the requirements outlined in the EMTA template and concluded that they will be fulfilled by the long form representation which is expected to be introduced in FpML version 5.4. Regards, Irina Yermakova

    in reply to: 5.3 backward compatiblity with 5.2 #2045
    iyermakova
    Spectator

    Hello, FpML 5.3 is backward compatible with FpML 5.2 within a corresponding schema View (i.e. a new version of the schema should continue to validate old instance documents; in this case the 5.3 Confirmation View schema should validate instance documents created with 5.0, 5.1, and 5.2. Confirmation View) In addition, FpML 5 supports FORWARD compatibility within a corresponding schema View (i.e., an instance document created with a new version of the schema should be schema compatible with an old schema, as long as it uses no features that arent in the new schema; in this case, in the 5.2 Confirmation View schema should validate instance documents created with 5-3 Confirmation View if it uses only features available in the 5.2 schema. Note: – FpML 5.2 includes Confirmation and Reporting schema Views. In FpML 5.3, two additional schema views are added: Transparency (real-time price reporting) and Recordkeeping (non-public SDR reporting) – There are known errata in FpML 5-2 that were corrected in 5.3 with the following incompatible changes: 1. In FpML 5.3 (fpml-doc.xsd), within “DataDocument” complex type: 1.1. Removed “ProcessingIndicator.model”. Rationale: Clean up the model. Added in 5.2 for SDR reporting but unused. 1.2. Removed “priceNotation”. Rationale: it was added in 5.2 to support Dodd Frank reporting, which subsequently was removed from 5-2. In 5-3 “priceNotation” was moved to a different location to avoid confusion, never used it that way. In 5.3, “priceNotation” replaced by the “quote” structure in the public and “nonpublicExecutionReports” 2. In FpML 5.3 (fpml-com.xsd), within CommodityAmericanExercise complex type: 2.1. Added a new container “exercisePeriod” to group “commencementDate” and “expirationDate” elements together. Rationale: Added support for Commodity Option Strip. 3. In FpML 5.3 (fpml-business-events.xsd) within TradeNotionalChange: 3.1. Changed the type of the elements “outstandingNotionalAmount” and “changeInNotionalAmount” from “Money” to “NonNegativeMoney”. Rational: Corrected to resolve some confusion in the examples. 4. In FpML 5.3 (fpml-reporting.xsd) within “TerminatingEventsReport” and “PositionActivityReport” complex types: 4.1. Changed type of elements “fromDateTime” and “toDateTime” from “xsd:date” to “xsd:dateTime”. Rationale: bug correction. Regards, Irina Yermakova

    in reply to: NDF settlement rate option #2044
    iyermakova
    Spectator

    Hello Gary, It looks like the ability to specify an actual settlement rate option in the rateSource field for FX non-deliverable forward and option has been lost. I have opened the issue (see – http://www.fpml.org/issues/view.php?id=1127 ) with the FpML FX Working Group. It is currently under review and will be discussed on their next week call. Thank you, Irina Yermakova

Viewing 15 posts - 1 through 15 (of 54 total)