The next BPWG meeting will be on Wednesday June 27 from 10:30 to 11:30
New York Time.
Agenda
------
1. Review of actions
IY to propose a message or messages for responding to a
request or a notification, with the ability to:
- indicate that the message was received (but not necessarily processed)
- indicate that the message was processed successfully.
MG Check with validation Working group on rationale for not
including validation rules for product type scheme.
2. Generic product (see updates from Brian)
3. Confirmation Choreography (Steve Ross-Talbot; see email with
materials sent by Steve. Please review them before the meeting)
4. AOB
Call details:
US: 1 888 481 3032
UK: 0 800 904 7961
Intl: 1 617 801 9600
Code: 8682747
Best Regards,
Marc
**************************************************************************************************************************
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 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.
**************************************************************************************************************************
Date: 11 June 2007 14:13:36 BDT
Subject: FpML-BP Generic product
I've updated the generic product model as discussed at the last BPWG
meeting:
- removed riskType
- changed party references to pairs (buyer/seller, payer/receiver)
I've also reviewed the non-product fields and have identified the gaps and
proposed some possible solutions. See the attached spreadsheet for details.
Below are the non-product gaps that I identified and some solutions:
Field
Comment
Suggested solution
Underlying Booking Branch - Party A
Distinct from legal entity
Add to partyTradeInformation or add to party'
Underlying Booking Branch - Party B
Distinct from legal entity
Add to partyTradeInformation or add to party'
Book / Portfolio / Department
Distinct from legal entity
Add to partyTradeInformation or add to party'
Date of signing of CSA
We have a CSA field
Add to documentation
Free text for any relevant comments
This has been proposed previously for FpML and rejected
Add to partyTradeInformation
Assignment Original Trade Date /Novation Date
We have tradeDate in tradeHeader, but usage in the case of a novation is a
little unclear.
Add novationDate to Scheduled events? Allow multiple trade dates?
Stepping Out Party
We can do this with the novation message, but not with the
position/constituent/trade structure
Add to partyTradeInformation?
MeasureType
We may need to add a measureType for system NPV
New measureType
<port_rec_data_standards.xls>
<fpml-asset-4-2.xsd>
<fpml-enum-4-2.xsd>
<fpml-generic-4-2.xsd>
<fpml-shared-4-2.xsd>
<fpml-valuation-base-4-2.xsd>
<generic_product.jpg>
Date: 7 June 2007 08:33:47 BDT
Subject: FpML-BP Updates choreography including RequestTradeMatch
Enclosed is a zip file for the choreography project for confirmations
(as before) corrected with RequestTradeMatch.
Take a look at the html in the src/choreography/html folder and see
what you think.
Questions and issues to consider:
1. Is this correct? If not what is wrong with it?
2. Identity - xsi:type + tradeIdentifier + version
Is this correct? The choreography can support multiple and
different identities as single or composite keys.
What is important is to locate or bind these identities in the
message to the ChannelType. You can see this in
the choreography. We do need identities because without them one
cannot monitor what is going on at all.
With a choreography one has the possibility of monitoring against
plan (the choreography description) which
is a stronger form of monitoring.
What about allocations? How do they relate to trades? How do we
distinguish between them and the underlying trade?
3. +ve ack as opposed to none
There are none in this model. Should it be supported? Do we need
two models on for +ve ack and one for no ack?
4. Confirmations for other business events
Only for new's and maybe amendments, what about increase/decrease/
novation etc? If we can agree to this process then
what about doing the rest? How do we deal with things that might
happen as opposed to things that have happened.
5. What artifacts from a choroegraphy suite are desirable for the
standard (i.e. to be included)?
The model itself in various forms (BPMN, UML, WS-CDL, HTML)?
Scenarios that have been validated against the model (i.e.
sequence diagrams)?
Does the HTML textual version need to be changed - to add more or
less - to be included directly in the
documentation?
These are some of my questions/issues at the moment. I am sure there
will be others from Matthew and Brian in due course
as well as from many others.
Cheers
Steve T
<Confirmations-FpML4.3.zip>
<ATT69584.txt>