FpML-FXWG-Legacy Fwd: RE: [fpml-fx] Notes from Steven Lord

["Danielle Cauthen" <dcauthen@xxxxxxxx>]

--- In fpml-fx@xxxxxxxxxxxxxxx, steven.lord@... wrote:

I think the problem with cashSettlement is alot down to IRD taking a 
generic term and using it in a IRD specific way (we did the same 
thing 
with swap [sorry]) - I know that at the standard committee this was 
raised a while back and there was a feeling that some re-naming may 
be 
required. Also remember if we get namespaces (when we move to 
schema - 
the architecture group should be issuing their recommendation on 
this 
this month) then IRD and FX could use swap and cashSettlement freely 
as 
they would have their own namespace.  In the meantime I think this 
should be thrown up to the co-ord group. We may find that the IRD 
cashSettlement element needs to be renamed in FpML 3.0
 
Steven
 
-----Original Message-----
From: rick.schumacher 
Sent: 13 December 2001 16:24
To: fpml-fx
Cc: rick.schumacher; Lord, Steven
Subject: RE: [fpml-fx] Notes from Steven Lord


Justin,
 
This looks very good ... I'm very impressed with the quick 
turnaround.
 
I agree with all of this at a conceptual level, but I have a couple 
of 
minor issues related to tag names:
 
1. netOrSSISettlement.  I always thought that a trade could be 
eligible 
for netting, could be tagged as having a standard settlement 
instruction, or could use standard settlement and also be eligible 
for 
netting.  Couldn't we do something like:
 
    settlementInstructionStyle -- references 
settlementInstructionStyleScheme (I am open to a better name for 
this, 
by the way)

values could be NET, STANDARD, NETANDSTANDARD, and if we wanted to, 
we 
could also have something called SPECIFIC when specific instructions 
are attached (but this last one isn't necessary)

 
2. I'm not sure if I like the term "cash" (although I could live 
with 
it).  Actually, I never really liked the term "cashSettlement" 
either, 
because the actual settlement isn't defined (because it's not known 
at 
this point), but rather the terms of the potential cash settlement 
are 
what are being defined.  Perhaps we want something very specific, 
like 
"cashSettlementTerms"?  But again, I'm not sure if that term is any 
better.
 
Rick
 
 

-----Original Message-----
From: Oglethorpe, Justin [IT] [mailto:justin.oglethorpe@...]
Sent: Thursday, December 13, 2001 10:42 AM
To: 'fpml-fx@xxxxxxxxxxxxxxx'
Cc: 'Steven.Lord'
Subject: RE: [fpml-fx] Notes from Steven Lord


As discussed at our teleconference this pm, here is a proposal for 
how 
we
might avoid having empty elements with no attributes. Please review 
and 
send
comments.

Thanks and regards,
Justin.

Justin Oglethorpe
+44 (0) 20 7508 3852 (desk)

This message is confidential and the property of Citigroup. It may 
also
be privileged or otherwise protected by work product immunity or 
other
legal rules. If you have received it by mistake please let us know by
reply and then delete it from your system; you should not copy the
message or disclose its contents to anyone.


-----Original Message-----
From: Rick Schumacher [mailto:rick.schumacher@...]
Sent: 13 December 2001 13:54
To: fpml-fx@xxxxxxxxxxxxxxx
Subject: [fpml-fx] Notes from Steven Lord


Steven and Justin have done quite a bit of work on the documentation 
this
week.  I will be sending the documentation later today, once I've 
reviewed
it and determined the best way of sending out 3MB of info ... I'll 
probably
just send directly to your email accounts as opposed to via Yahoo, 
since
Yahoo has 1MB file transfer size limit.

As Steven has been incorporating our work into the FpML Version 2.0 
(to
create 3.0), he has uncovered a lot of detailed items.  See notes 
from
Steven below from earlier today.


Attached are the corrected documents (ironed out another bug in the 
script!). This is looking great - you guys have managed alot of 
products !

When you have first cuts of FX Product Architecture and the 
additional 
schemes let me have them and I'll re-run the scripts.

I have reviewed the DTD and my comments are below. They are split in 
two - things that I have changed (as it was clear the change had to 
be 
made) and things to consider.

Changes Made
1. I've put the elements into alphabetical order to be consistent 
with 
the previous standards.
2. averageRateObservationDate changed to be of type 
FXAverageRateObservationDate
3. averageRateObservationSchedule changed to be of type 
FXAverageRateObservationSchedule
4. beneficiary changed to be of type Routing
5. beneficiaryInformation changed to be of type 
BeneficiaryInformation
6. binaryPayout changed to be of type FXOptionPayout
7. currency1SideRate changed to be of type SideRate
8. currency2SideRate changed to be of type SideRate
9. correspondentInformation changed to be of type Routing
10. fxAmericanTrigger changed to be of type FXAmericanTrigger
11. fxAverageRateOption changed to be of type FXAverageRateOption
12. fxBarrier changed to be of type FXBarrier
13. fxBarrierOption changed to be of type FXBarrierOption
14. fxOptionPremium changed to be of type FXOptionPremium
15. fxSwap changed to be of type FXSwap
16. intermediaryInformation changed to be of type 
IntermediaryInformation
17. observationDate changed to be of type date
18. observationEndDate changed to be of type date
19. observationStartDate changed to be of type date
20. observedRates changed to be of type ObservedRate
21. primaryRateSource changed to be of type InformationSource
22. routingAddress changed to be of type Address
23. routingExplicitDetails changed to be of type 
RoutingExplicitDetails
24. routingId changed to be of type RoutingId
25. routingIds changed to be of type RoutingIds
26. routingIdsAndExplicitDetails changed to be of type 
RoutingIdsAndExplicitDetails
27. secondaryRateSource changed to be of type InformationSource
28. sideRates changed to be of type SideRates
29. splitSettlement changed to be of type SplitSettlement
30. streetAddress changed to be of type StreetAddress
31. triggerCondition changed to be of type FXOptionPayout
32. Fixed typo on cutNameScheme (was cutnameScheme)

Things to Ponder
1. Alot of element / entities are pre-pended by FX - in general we 
did 
not prepend with IRD in the ird standard. I think where possible we 
should avoid this since with a move to schema name-spaces may be 
introduced which will highlight elements as FX. Pre-pending with FX 
also, prevents (at least hinders) a move to the shared component DTD 
at 
a later stage.
2. There is an element averageRateDecimalPlacePrecision - could the 
dtd 
re-use the element 'precision'
3. netSettlement is an empty element without any attributes. Is this 
needed ?
4. The element observedRates contains the entity FpML_ObservedRate - 
the element is plural and entity singular is this correct ?
5. payoutCurrency does not define a currencyScheme, should it ?
6. physical is an empty element without any attributes. Is this 
needed 
? (this is a comment I mailed previously - put it here for 
completeness)
7. postalCode - do we want some sort of scheme here that indicates 
the 
type of 'postal code' eg - UK Postal Code, US zip code ??
8. routingIdCode should have a scheme defined for it. This means 
that 
routingIdCodeType is not needed. The scheme URI defines the type.
9. routingIdCodeType (see pt8) seems redundant - the scheme 
definition 
should be placed on the routingIdCode element
10. standardSettlementInstruction is empty with not attributes - is 
it 
needed (same point as 3 & 6 above).
11. state does not have a scheme defined. Should one be defined ? 
Whenever a element is of type string we should consider whether a 
scheme should be defined. In general we should otherwise it's just 
free 
form text that cannot be validated which is not ideal in a standard.
12. FpML_FixingDateTime - I think this should be changed to 
FpML_DateTime and the elements within it changed from fixingDate to 
date and fixingTime to time - this way it is re-usable. The use in 
this 
case would be defined by the containing element - thus an element 
fixingDateTime would be of type DateTime. This should probably 
extend 
FpML_BusinessCenterTime - the type 'time' in fpml does not include 
timezone thus this entity as is does not really define time 
correctly.
13. FpML_Fixing - this should be made FX specific as this is a FX 
fixing as opposed to a rate fixing. Thus perhaps FpML_FXFixing. I 
could 
envisage in some hybrid product an entity FpML_Fixing that would be 
a 
choice of fixing type (ie fx, rate, bond yield etc..)
14. FpML_ObservedRate - does this need a time element ?
15. FpML_Fixing and FpML_FXRate have initial common element of 
currency1, currency2 and quoteBasis - is it possible / sensible to 
pull 
this out into a common base entity - such an entity would appear to 
have mean in that it seems to specify an FX Rate. The entity 
FpML_FXRate seems to define a rate and the actual value. In IRD 
terms 
an equivalent split would be the definition of a floating rate 
compared 
to an entity that gave the rate and it's value.

Sorry for the long mail - somehow I just kind of got engrossed in 
it !!

I think now we need to work from the attached DTD. If you want to 
make 
it easier to work on you can insert at the top of it the import of 
the 
shared DTD. This means you can then edit the fx dtd directly in a 
tool 
and validate it.

Steven



To unsubscribe from this group, send an email to:
fpml-fx-unsubscribe@xxxxxxxxxxxxxxx



Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/ 




Yahoo! Groups Sponsor	
ADVERTISEMENT
	
 	

To unsubscribe from this group, send an email to:
fpml-fx-unsubscribe@xxxxxxxxxxxxxxx



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 




Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the 
contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities 
or 
related financial instruments.

--- End forwarded message ---



-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe fxwglegacy youremail@address
To view archives: http://www.fpml.org/_wgmail/_fxwglegacymail/threads.html