[lyteck]

Hello Anil: Apologies for the late answer to your question. The Reporting view and Recordkeeping views have distinct purposes. The Reporting view was developed in FpML 5.0 as a way flexible way for firms to pick and use fields for various applications e.g., 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 moderately loose product representation; it requires key economic information such as the notional, key dates, and parties, but leaves other information optional. The recordkeeping view was developed for regulatory reporting. It is 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. For regulatory reporting you want to use the recordkeeping and transparency views. Apologies once more for the delay. Let us know if you have any additional questions that we would answer promptly. Regards, Lyteck ISDA

[lyteck]

This seems to be correct in 5.3 Recommendation XSD: using http://www.fpml.org/coding-scheme/asset-class Apologies for the delay. Lyteck ISDA

[lyteck]

Hi, Note that it’s the combination of correlationId + sequence number (and not the messageId) that relates messages together and keeps track of their sequence. See http://www.fpml.org/spec/fpml-5-7-4-tr-1/html/confirmation/schemaDocumentation/schemas/fpml-msg-5-7_xsd/groups/CorrelationAndOptionalSequence.model.html if I understand correctly you have multiple processes, say 3 sequential business processes, and you want to keep track of the sequence of all the messages across these processes. As stated, FpML provides fields to track sequences within a process, however, that mechanism is not meant to be used across processes, by design. You could possibly devise a solution where you would embed sequence information in e.g., the messageId but that would be a hack, and unadvisable. FpML provides a parentCorrelationId field which is an optional identifier used to provide a connection between related processes. That was introduced to keep track of main (parent) / sub processes. This additional field may be useful. Hope this helps. Regards, Lyteck ISDA

[lyteck]

Hello Ujjwalan: Apologies for the late answer to your question. The Reporting view was developed in FpML 5.0 as a way flexible way for firms to pick and use fields for various applications e.g., 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 moderately loose product representation; it requires key economic information such as the notional, key dates, and parties, but leaves other information optional. The recordkeeping view was developed for regulatory reporting. It is 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. For regulatory reporting you want to use the recordkeeping and transparency views. Apologies once more for the delay. Let us know if you have any additional questions that we would answer promptly. Regards, Lyteck ISDA

[lyteck]

Averil – thanks for submitting this question. These fields are part of the base Product model (available in all products) and are defined in the schema within the reusable Product.model group. See http://www.fpml.org/spec/fpml-5-7-4-tr-1/html/confirmation/schemaDocumentation/schemas/fpml-shared-5-7_xsd/groups/Product.model.html Note that these are all optional fields and you would use what makes sense for your situation. A classification of the most important risk class of the trade. choose from values defined by the FpML assetClass coding scheme http://www.fpml.org/coding-scheme/asset-class A classification of additional risk classes of the trade, if any. Draw values from the same assetClass scheme. Populate this field with the type of product using the ISDA taxonomy code published at http://www.fpml.org/coding-scheme/product-taxonomy >A product reference identifier. This element is deprecated in favor of the primaryAssetClass. Onto your specific question, how about: Credit Credit:SingleName:ABS:CDSonCDO For an index, you might have Credit Credit:Index:LCDX:LCDX (took these sample values from the FpML product taxonomy scheme based on the published ISDA OTC Derivatives Taxonomies.) Hope this helps. Let me know if you have any additional questions. Regards, Lyteck ISDA

[lyteck]

Hi Kevin, I can’t speak for the clearedDate, but FYI there are discussions in the FpML Regulatory Reporting WG to add more timestamps / add a flexible timestamp structure. I would refer you to this thread: http://www.fpml.org/_wgmail/_rptwgmail/msg00396.html If a concrete proposal came out of this it would likely be implemented in a later draft of FpML 5.2. I would suggest you keep checking the mailing list or participate directly in the reporting working group to get the opportunity to shape the design. This may solve the limitation you see with the clearedDate, I am not sure but I thought I’d mention this related discussion. Apologies for the delay in answering your post. Regards, Lyteck Lynhiavu ISDA

[lyteck]

Hello: The messaging object model document lists all the available messages for a given FpML version. The validation rules related to messaging and business processes can be found in the documentation for a given FpML version > Section 4 (Validation Architecture) > Section 4.1 (Validation Rules) > and look at the links for: 1. Business Process Rules 2. Messaging Rules Best, Lyteck ISDA/FpML

[lyteck]

Hi: Thank you for the good questions. FpML 5.x introduces the concept of views. A view presents a variation of the FpML schema targeted for a particular application. In FpML 5 there are two views: Confirmation and Reporting, as you’ve noted. You would choose one view over another depending on what type of application you’re implementing. – The confirmation view is a strict schema where most elements are mandatory. The product representation in the 5.x confirmation view is the same as in 4.8+ – The reporting view is a looser version of the schema where almost all the elements are optional by design. This is useful in situations where not all elements are known, or requirements vary e.g., reports. You pick and choose which fields you need for your application. – More views maybe added in the future. (these 2 views are derived from a master schema which is also avaiable for download, although that master schema is not meant to be used for direct implementation. One of the views should do the work for your purpose. In 4.8 there’s indeed a merged schema but we haven’t published a merged schema for 5.x. We may consider publishing one. Note that the standard schema (multiple XSD files) and merged schema (one XSD file) should be equivalent, of course. Hope this helps, let us know if anything else. Best, Lyteck ISDA / FpML

[lyteck]

Jamal, The technique described above to create the abcML extension follows W3C schema syntax, hence the same parser that you would use to parse FpML instances would be used to parse your abcML. e.g., Xerces, Saxon just to name a few. Regarding your clearing project, and your particular status example, you might want to look at FpML 5.1 Working Draft 3. There’s a similar status field that was added based on input from major clearing houses. http://www.fpml.org/news/5.1_3rd_announcement.htm (see section 3.3.3.6 of the confirmation view) Best, Lyteck

[lyteck]

Hi Jamal: You might want to extend the FpML schema by creating your own markup language, e.g. abcML. In other words, abcML would contain the custom elements and attributes and only reference the FpML schema (which stays intact and can be upgraded independently). Here’s what the top of your own schema would look like: That should work for your purpose. Best Regards, Lyteck FpML Technical Analyst ISDA Note: What you describe is a common thing companies want to do. We actually have upcoming FpML training courses in London and New York that teach just that -how to create your own extensions- if you are interested. See http://www.isdadocs.org/conf/conf_indexes/index_12-08-10fpml.html or http://www.fpml.org (training section)

[lyteck]

FpML does not provide or intend to provide tags to capture previous/old field values. We believe this is best handled by applications. Your Audit application should load in memory previous versions of the FpML document and present the diff information to the end-user. Using this approach, you gain more flexibility because you can compare version 1 to version 2 to version 5. Also, not storing “previous” unecessary information results in smaller FpML files which can be processed faster. Hope this helps, Lyteck

[lyteck]

The schema (XSD) can be downloaded from: http://www.fpml.org/spec There are many versions of the FpML schema. I suggest you download the latest FpML “Recommendation” (version 4.3) http://www.fpml.org/spec/fpml-4-3-12-rec-1/ The online documentation for the specification contains descriptive information about FpML messages, business processes, and products coverage. Additionally, the schema itself contains annotations (documentation) for FpML elements/types. These annotations should be helpful to complete your mapping (FpML Message <-> your internal table) The FpML Editor/Viewer allows you to build FpML trades/messages using a web interface (instead of using an XML editor and trying to figure out the name of the FpML elements). The GUI effectively hides the complexity of XML coding by labeling fields in plain english, and guiding you through the creation of the FpML trade. I think it can indeed be a good starting point for you to understand FpML (how business data is captured in XML) and parse your message to fill your internal table. The tool is available for free to ISDA members or for a fee at: http://www.fpml.org/tools/editor/index.html Should you be interested, we also have training courses available in New York and London. Although the next one is a few months away: http://www.isda.org/conf/conf-10-20-08fpml.html Good luck. Best, Lyteck – ISDA

[Author]

Posts