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

FpML-BP meeting tomorrow June 27

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.
**************************************************************************************************************************
--- Begin Message --- 
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

Attachment: port_rec_data_standards.xls
Description: port_rec_data_standards.xls

Attachment: fpml-asset-4-2.xsd
Description: fpml-asset-4-2.xsd

Attachment: fpml-enum-4-2.xsd
Description: fpml-enum-4-2.xsd

Attachment: fpml-generic-4-2.xsd
Description: fpml-generic-4-2.xsd

Attachment: fpml-shared-4-2.xsd
Description: fpml-shared-4-2.xsd

Attachment: fpml-valuation-base-4-2.xsd
Description: fpml-valuation-base-4-2.xsd

Attachment: generic_product.jpg
Description: generic_product.jpg


--- End Message ---
--- Begin Message --- 
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

Attachment: Confirmations-FpML4.3.zip
Description: Confirmations-FpML4.3.zip

Attachment: ATT69584.txt
Description: ATT69584.txt


--- End Message ---