[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FpML-BP Meeting Minutes 2012-01-27



Please find the minutes for the January 27 meeting.

 

Attendees

1.                   Brian Lynn (Global Electronic Markets) – Chair

2.                   Andy Maynard (State Street)

3.                   Clare Gehrhardt (DTCC)

4.                   Dibyendu Majumdar (LCH)

5.                   Harry McAllister (BNPP)

6.                   Henri Pegeron (MarkitSERV)

7.                   John Booth (MarkitSERV)

8.                   Neil Actor (Sungard)

9.                   Niranjana Sharma (CME Group)

10.               Shawn Kelly (ARK EDI Solutions)

11.               Simone Milani (LCH)

12.               Sudipto Haldar (Morgan Stanley)

13.               Irina Yermakova (ISDA)

14.               Marc Gratacos (ISDA)

15.               Lyteck Lynhiavu (ISDA)

Apologies

·         Sreedhar Segu (Credit Suisse)

 

Summary

 

1. Feedback from FpML Standards Committee

Deliverables & timeframe for FpML 5.3. The publication of the LCWD is delayed a week to accommodate tweaks to the transparency/recordkeeping views stemming from the final CFTC part 43 and 45 regulations. (the RPTWG has not received all the analysis yet.) The TR and final REC are still on track for March and April as outlined in the FpML roadmap.

 

Client Clearing and Allocation messages enhancements (MarkitServ Proposal)

Brian circulated a proposal from MarkitServ email 1/25 “additional Industry Reqs for FpML 5”. The proposal was presented to the Standards Committee which agreed to republish FpML 5.1 REC and 5.2 REC to incorporate the changes. Henri presented the business case to the group. There were no objections to these relatively non-intrusive changes. Firms understood that reopening published Recommendations is not best practice and should be avoided. Going forward enhancements should be made to current, open versions.

>> ISDA will implement the Client Clearing and Allocation messages enhancements. ISDA will republish 5.1 REC and 5.3 REC (Action # 1)

 

2. Forward compatibility feature in FpML 5.x

We’ve republished recommendations on a number of occasions already. Brian noted that FpML 5.x contains a version compatibility feature designed to help firms handle multiple versions simultaneously. The FpML confirmation view namespace for example, i.e., http://www.fpml.org/FpML-5/confirmation, is shared between versions 5.0, 5.1, 5.2, 5.3…  This loose coupling enables:

o        Backward compatibility: an instance document created in 5.1 will validate without any changes against the 5.3 schema

o        Forward compatibility: an implementation running 5.1 can validate instances developed using 5.3 schema, as long as these instances don’t use any of the new 5.3 features.

A firm can potentially migrate to new versions of the schema without changing the instance documents or new versions of instance documents without changing the schema. >> We’ll schedule another discussion and possibly develop guidelines implementers can follow (longer term action).

 

3. Review of Action Items

1.     Feedback on the messaging mapping table between version 4.9 and 5.3. Marc reported no feedback received.

 

2.     Party Role Scheme – LCH was to complete an analysis and present findings/suggestions. Dibyendu noted that the task proved very difficult.

>> Dibyendu agreed to circulate any LCH party roles that are not included in the existing spreadsheet for further group review (Action # 2)

 

3.     ClearingStatus message – Brian suggested improved annotations for the clearingStatus message. Feedback was positive. >> We will ask Steve Turner from JPMorgan who submitted the issue http://www.fpml.org/issues/view.php?id=1064 to review the improved clearingStatus annotations (Action # 3)

 

4.     Implementer-specific version – Brian revised the implementationSpecification proposal as earlier agreed. We discussed the following confirmation/changes.

§  Simone confirmed only one occurrence is enough.

§  We’ll rename the version attribute to versionScheme so to match the complex type name ImplementationSpecificationVersion i.e., <version implementationSpecificationVersionScheme=…>

>> Brian will finalize the implementationSpecification structure (Action # 4) 

 

4. Proposal to add a set of Service Notification Messages in 5.3 (see Brian’s email 1/27 “Service Notificiation, updated clearing status message annotations”).  Brian developed a new proposed service notification message, for a service to provide status information /advisories to users of the service. This was requested by LCH. Feedback was positive. We discussed refinements to the model.

-          Delete timestamp. The existing message creationTimestamp is sufficient.

-          Only one occurrence of status, processingStatus, advisory is needed. We can consider multiple occurences later, if needed.

-          Rename reasonCode to category

-          Add optional effectiveFrom / effectiveTo

 

The new message, using an advisory payload will look like this:

<serviceNotification>

  <header>

    <messageId messageIdScheme="http://www.clearingservice.com/message-id">oct456a789b</messageId>

    <sentBy messageAddressScheme="http://www.clearingservice.com/partyId">clear1</sentBy>

    <creationTimestamp>2012-01-21T11:15:00Z</creationTimestamp>

  </header>

  <correlationId correlationIdScheme="http://www.clearingservice.com/corrId">1234</correlationId>

  <serviceName>Clearco CDS Clear Service</serviceName>

  <advisory><!-- occurence 1 -->

    <category>Availability</category>

    <description>We will be closed Jan. 23 for Chinese New Year.</description>

    <effectiveFrom>2012-01-23T00:00:00Z</effectiveFrom><!-- optional, date/time -->

    <effectiveTo>2012-01-24T00:00:00Z</effectiveTo><!-- optional -->

  </advisory>

  <!--delete <timestamp>2012-01-21T11:12:00Z</timestamp>-->

</serviceNotification>

 

-          Remove processing prefix in children of the processingStatus payload:

  <processingStatus>

    <cycle>EndOfDay</cycle>

    <event>ProcessingCompleted</event>

  </processingStatus>

 

>> Brian will revise the serviceNotification message as discussed (Action # 5) 

 

 

5. Action from RPTWG – There was a request from Sreedhar at the RPTWG to consider adding acknowledgement messages for retraction messages in Transparency/Recordkeeping views. Deferred. We did not have time to discuss. Brian briefly indicated this was general to all the retraction and to any status messages for a business process.

 

Action Items

1.       ISDA will implement the Client Clearing and Allocation messages enhancements. ISDA will republish 5.1 REC and 5.3 REC

2.       Party Role Scheme – Dibyendu agreed to circulate any LCH party roles that are not included in the existing spreadsheet for further group review

3.       We will ask Steve Turner from JPMorgan who submitted the issue http://www.fpml.org/issues/view.php?id=1064 to review the improved clearingStatus annotations

4.       Brian will finalize the implementationSpecification structure

5.       Brian will revise the serviceNotification message as

 

 

Next Meeting: Friday February 10, 2011

 

References

·         January 27 meeting invitation




The information contained in either this email and, if applicable, the attachment, are confidential and are intended only for the recipient. The contents of either the email or the attachment may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, or distribution is prohibited and may be unlawful. If you have received this communication in error, please notify us by e-mail at isda@xxxxxxxx <mailto:isda@xxxxxxxx> then delete the e-mail and all attachments and any copies thereof. This communication is part of an ISDA process and is not intended for unauthorized use or distribution.