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

FpML-IM-Custodian Technical Teleconference 2009-02-25 minutes

Attendees:
Robert Stowsky - BrookPath
Randy Magdaluyo - State Street
Lucio Iida - BGI
Irina Yermakova - ISDA
Marc Gratacos - ISDA
 
 
Agenda and minutes:
  • Update on payment components work for FpML contract messages : 
    • Marc and Lucio exploring technical alternatives.
      • The approach is to add an optional repeatable <paymentDetails> structure as a peer of <contract>, <novation>, <party> that can provide additional details on a specific payment.
      • The <paymentDetails> would have an @href attribute that references the associated <payment> @id.
        •
      • The CalculationDetails is a candidate FpML type for the <paymentDetails> structure and content.  It includes the optional structures below: 
        • <grossCashflow> contains payment direction, currency amount, type (with default scheme http://www.fpml.org/coding-scheme/cashflow-type-2-0.xml)
        • repeatable <observationElements> includes prices or rates of the underlyer components
        • <calculationElements> includes calculation ingredients like notional, floating index, underlyers, periods, conventions
      • All enhancements would be optional, so they would be backward compatible, and will probably be available in FpML 4.6.
      • Lucio to provide usage samples.
      • Marc to provide graphic structure snapshots.
      • We will review ongoing work in the next meeting.
    • Once changes are agreed we will prepare a proposal document for the Coordination Committee.
  • Discussion on Messaging Patterns document prepared by Andrew Jacobs for the FpML Modeling Task Force (MTF) group:
    • The MTF is rationalizing FpML to remove inconsistencies, support processes better, identify message gaps, among other objectives.
      • Target releases are FpML 5.0 and forward.
      • MTF has asked for feedback from this WG on the document, particularly on the Correlation proposal.
    • We focused on the following sections of the document:
      • Advice vs Notification
        • Question: Any need for a response to contract notifications?  i.e. do we need to support the advice pattern?
          • The response is not to be confused with acknowledgement of receipt (e.g. a SwiftNet ACK).
          • The response is really a functional acceptance of the notification.
        • There were no objections to new response messages, but it was stated that implementations would require business justification.
      • On Behalf Of
        • Question: On behalf of which party in the contract notification does the recipient (custodian,administrator) need to act?  It may not be readily clear to the message recipient.
        • The proposed structure would provide this information.
        • There were no objections to this.
      • Identity
        • Question: Is there a need to render the primary contractId in a specially designated field?
        • In SwiftNet Derivatives implementations the practice is to use the contractIdScheme="http://www.swift.com/coding-scheme/contract-id" for the primary contractId.
        • The group did not feel that a separate id field is necessary.  Members will study this further.
      • Correlation
        • The proposal adds correlation ids to identify the process the messages relate to.  The ids will have associated sequence numbers.
        • It may result in the removal of conversationId, currently being used tactically to identify the contract lifecycle event.
        • The feedback from the group was positive because it separates message sequencing from contract versioning via separate message elements.
      • Message gaps  (this is in the "Gap With 4.5 Model" section, not "Reporting" as I stated).
        • ContractAmended is listed for the explicit notification of bilaterally agreed changes to contracts.  The SwiftNet CUG agreed to exclude it from the message suite because systems supported cancel / rebook.  It is not clear this approach is friendly to all systems.  Feedback will be requested in the ISITC OTC and SwiftNet Derivatives UG.
        • Also listed in this section are new explicit "Modification" notifications to correct erroneous messages.  The current tactical solution is to send a corrected notification of the same type with the same conversationId and a higher contract version number.
    • We agreed to seek wider feedback on these MTF proposals for FpML 5.0 from the SwiftNet Derivatives UG and ISITC OTC WG.
  • Marc gave the tentative FpML release roadmap:
    • FpML 4.6 - summer 2009
    • FpML 4.7 - Dec 2009
    • FpML 5.0 Recommendation - end of summer 2009
  • Review the Discussion Topics  section of the ISITC document on CDS credit events:
    • The document  "Thread 4311 - Conference Call to discuss recent OTC Market event.pdf" was provided by Randy.
    • Marc provided a creditEventNotice message sample.   creditEventNotice is used by one party to notify the counterparty about the event and sources of information.  No economic details can be provided in it.
    • At the ISITC Dec conference custodians asked IMs to alert them of credit events, even if they have access to this information.
    • We agreed CDS Index credit events do not imply actual partial/full terminations of the notional amount.
    • Marc will ask the FpML CDWG for any FpML developments around credit events.
  • Next meeting - Mar 11 noon Eastern.
Please let me know of any errors/omissions.
 
Thanks
Lucio Iida
Principal
Design and Development Technologist

TEL 415 597 2288
CELL 415 717 9261
FAX 415 618 1667
lucio.iida@xxxxxxxxxxxxxxxxxx

Barclays Global Investors 400 Howard Street San Francisco, CA 94105