In section 7 of the April 17 WD of FpML 3.0, there was a proposed change to
the use of scheme defaults:

Here is the text of the proposal:

Quote:
    "The FpML Working Groups are considering removing the scheme default
    attributes from the FpML root element and changing the scheme attributes
    from being #IMPLIED to #REQUIRED. Comments and feedback on this idea are
    encouraged.

    This change is proposed because where scheme default attributes are used
    the meaning of a given node is dependent on the document it is in. This
    means that if part of an FpML document it copied from one document to
    another then it's meaning may change if the scheme default attribute is
    different "
End Quote.


JPMorgan Feedback:

JPMorgan strongly opposes the proposed change.  JPMorgan feels that the
proposed change has the following adverse consequences:
* Greatly increases the size and bulk of messages, particularly for
portfolios of trades
* Reduces the readibility of FpML documents.
* Increases the difficulty of verifying which schemes are used for each
trade, since there is no way to factor out common definitions.
* Makes it more difficult to build efficient processing logic, because
schemes will always need to be verified for each element independently,
rather than defaulted and overridden only as necessary.

JPMorgan does not feel that the stated benefits of the change warrant the
drawbacks.

JPMorgan proposes the following instead:

Add the following directives, or equivalent, to the standard:

1)  In an FpML-compliant document, there must be an scheme definition
available for each element requiring a scheme.  This scheme definition can
be specified, for example, either at the document root level (<FpML> tag)
or for each individual element, or in other ways as may be defined in FpML
in the future.  (For example, by inheritance from a parent document or by
inclusion of/reference to another document).  Implementers are responsible
for validating (at document validation time)  that there is a scheme
definition available for each element requiring a scheme, and reporting an
error if not.  [Comment: as more ways to define schemes are created, a
disambiguation hierarchy/scoping rules should be defined, e.g.
element-level scheme definition supercede document-level definitions which
in turn supercede scheme definitions inherited from a parent document].

2)  When comparing or copying elements that use scheme definitions between
FpML documents, implementers must ensure that the scheme definition are
compatible.  For example, if a source document defines scheme defaults at
the <FpML> root element that are different from those defined in the
destination document's root <FpML> element, the implementer must either
determine that the schemes are equivalent (Equivalency definition TBD), or
set the scheme attribute in all copied nodes to the scheme definition URI
contained in the source document."

[End of proposed additions to the standard].


In general this proposal has more to do with the semantics of how an FpML
document is to be processed than in how it is structured.   Document
processing  is an area the FpML does not currently specify in any detail.
For example, there is little coverage at this point of how to validate an
FpML document, how to compare two documents, etc.  JPMorgan believes that
changing the document structure to "simplify" processing without having
discussed document processing in any detail is premature.  Instead, this
type of change is perhaps better addressed as part of a WG on document
processing (e..g validation, matching).  For example, the definition of
equivalency between two scheme definitions is unclear.  Do the URIs have to
be identical, or do only the contents need to be identical, or do only the
values used in the source need to be defined in the destination?  This
might be a choice that an implementer can make, perhaps associated with
different warning levels.


This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.

Hi,

Further to Guys mail, we in Merrill Lynch have implemented a SwapsWire
feed.  The core part (the translator) is currently being used for some
simple trade capture, so we are already using FpML 1.0.  I have been
supervising technical and archtiectural parts of MLs SwapsWire feed.  We
are still waiting for the messaging part to get sorted out, but that
is another story!

We are in the process of extending this for FpML 2.0 and have the basic
infrastructure in place for it.  We have a use for it internally for
content based routing for the flow business, and I am in negotiations
at a global level to use this for front/back office communication e.g.
confirmation generation.  Again, we have translation work in place and
are leveraging that.

However, we could really do with a push on the credit derivatives side:
if this was somewhere in the spec/in the near future it would have massive
cross business area benefits.

I also concur with Guy about little and not so little differences
between FpML 1.0 and 2.0 which do not retrofit as easily as one would
want eg. it makes them a bit awkward to fit them in exactly the same
architectural framework, but it is possible to do so.

Regards,
Andrew Addison


-----Original Message-----
From: Guy Gurden
To: fpml-irdprod@yahoogroups.com
Cc: fpml-issues@yahoogroups.com; Mike Davies; fpml-coord@yahoogroups.com;
steven.lord@...
Sent: 06/06/2002 05:25
Subject: RE: [fpml-irdprod] FpML 2.0 - Proposal To Move To Recommendation

Steven,

At SwapsWire we are using the FpML 1.0 Recommendation and components
from FpML 2.0.  We currently limit ourselves to the Swap product but are
making extensive use of the FpML 2.0 'earlyTerminationProvision'
component and the associated mandatory components of its sub-components
(e.g. mandatory/optional early termination, european exercise, bermudan
exercise, american exercise, cash settlement).  In the attached Word
document I have identified some minor changes we found necessary which I
think are worth considering for incorporation into the Trial
Recommendation.

I have also raised one issue relating to the inconsistency of naming
between FpML 2.0 and the 2000 ISDA Definitions, i.e. Bermuda (ISDA) vs
Bermudan (FpML).

Regards
Guy

-----Original Message-----
From: steven.lord@... [mailto:steven.lord@...]
Sent: 05 June 2002 15:47
To: fpml-irdprod@yahoogroups.com
Subject: [fpml-irdprod] FpML 2.0 - Proposal To Move To Recommendation


At the last Standards Committee meeting there was alot of feedback of
implementations of FpML 2.0. As a result it being proposed to move FpML
2.0 to Recommendation. Are there any objections from anyone in this
group to such a move ? If so please state the reasons why we should not
move to Recommendation.

Steven

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.





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



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.




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

  <<SwapsWireCommentsOnFpML-2-0-TrialRecV1.doc>>

Steven,

At SwapsWire we are using the FpML 1.0 Recommendation and components from FpML
2.0.  We currently limit ourselves to the Swap product but are making extensive
use of the FpML 2.0 'earlyTerminationProvision' component and the associated
mandatory components of its sub-components (e.g. mandatory/optional early
termination, european exercise, bermudan exercise, american exercise, cash
settlement).  In the attached Word document I have identified some minor changes
we found necessary which I think are worth considering for incorporation into
the Trial Recommendation.

I have also raised one issue relating to the inconsistency of naming between
FpML 2.0 and the 2000 ISDA Definitions, i.e. Bermuda (ISDA) vs Bermudan (FpML).

Regards
Guy

-----Original Message-----
From: steven.lord@... [mailto:steven.lord@...]
Sent: 05 June 2002 15:47
To: fpml-irdprod@yahoogroups.com
Subject: [fpml-irdprod] FpML 2.0 - Proposal To Move To Recommendation


At the last Standards Committee meeting there was alot of feedback of
implementations of FpML 2.0. As a result it being proposed to move FpML 2.0 to
Recommendation. Are there any objections from anyone in this group to such a
move ? If so please state the reasons why we should not move to Recommendation.

Steven

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.





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



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.

Thanks for this.
 
I will update the errata list for the error in example 17. The others
have already been identified and are included in the errata list.
 
These errors will be corrected when FpML 2.0 moves to Trial
Recommendation
 
Steven
 
 
-----Original Message-----
From: james.battle
Sent: 21 December 2001 10:08
To: fpml-issues
Cc: james.battle
Subject: [fpml-issues] Minor errors in example trades


I have noticed the following (minor) errors in the example trades in
the LCWD:
 
- In example 17, the calculationAgentParty is given as
NonExerciseingParty instead of NonExercisingParty.
- quotationRateTypeScheme is specified to be
http://www.fpml.org/spec/2000/period-1-0  i.e. the same as for
periodScheme.
- In example 25, an illegal value of PaymentDate appears in
dateRelativeTo (the coding scheme does not allow this value).
- The examples use the time format hh:mm instead of the documented time
format hh:mm:ss
- In example trades 13, 18 and 26 the value of the observationWeight
element is supplied as the floating-point number 1.0 while
  the type of observationWeight is positiveInteger (causing the example
to fail strict validation in some .NET applications).

regards,
 
James Battle

Yahoo! Groups Sponsor
ADVERTISEMENT



To unsubscribe from this group, send an email to:
fpml-issues-unsubscribe@egroups.com



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.

FpML,

I have quicky glanced at the spec for FpML 2.0. I have skipped the sections on
the actual definition (which I am sure mean lots more to others), but looking at
the schemes and data type sections. Here are some observations that might be
useful:

* Section 9.1.1 - there seems to be an inconsistency that it says at least four
digits for the year, then says years in the range 0001-9999. Could be fixed
either way, but depends on whether you want to create a 10th millenium bug.

* Section 9.2.1 - for the tradeId fields there is a tradeIdScheme, but this has
no values specified. This makes sense since the Ids are self administered, but
it might be worth suggesting that the tradeIdScheme should use something that
makes the tradeIdScheme/TradeId combination globally unique, e.g. using their
domain name in some part. This avoids the case where tradeIdScheme is left
blank, and a number used in the tradeId field (which will quickly fail the
uniqueness test).

That is all I notice at this glance...

Cheers,

Nic.

P.S. It is great to see the Architecture Recommendations being followed -
especially for those of us who worked (and fought) to try and get it right.



-----------------------------------------------------------------
         Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

FpML.org has published FpML 2.0 Last Call Working Draft. This version
incorporates feedback on the FpML 2.0 Working Draft 17th October 2001.

Comments should be submitted by Monday, January 7th 2002 via
fpml-issues@yahoogroups.com

It is anticipated that a Trial Recommendation incorporating any
feedback will be published in January 2002.

A copy of the standard can be obtained from: http://www.fpml.org/spec

Steven Lord
FpML IRD Working Group Chair


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.

FpML.org has published an updated FpML Version 2.0 Working Draft. This
version incorporates feedback on the FpML 2.0 Working Draft 28th August
2001.

It is anticipated that a Last Call Working Draft incorporating any
feedback will be  published in November 2001.

A copy of the standard can be obtained from: http://www.fpml.org/spec.

Steven Lord
FpML IRD Working Group Chair




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.

-----Original Message-----
From: Lord, Steven
Sent: 24 September 2001 11:01
To: Paul.Newton
Subject: RE: FpML2 specification - comments


Hi,

1. FpML_ExerciseFee and FpML_ExerciseFeeSchedule:
The reference here refers to the element notionalSchedule which is of
type FpML_Notional

2. FpML_MandatoryEarlyTermination and FpML_OptionalEarlyTermination:
This is an error in the document. The diagrams are out of date, the dtd
does not include a product reference. I will add this to the errata
list.

3. FpML_CancelableProvisionAdjustedDates:
The spelling of cancelable was a debateably point !! It was agreed to
go with cancelable and cancellation. You have indeed spotted an
inconsistency in the document. I will add to the errata list.

4. FpML_AmericanExercise, FpML_EuropeanExercise, FpML_BermudanExercise:
It's a tough one since depending on it's use it refers to one or more
dates. For instance in EuropeanExercise it referes to one date. In
American and Bermudan where there is no partial or multiple exercise
then there is only one relevant underlying date (though there are
multiple candidates prior to exercise).

5. FpML_Trade:
Good spot. The diagram is out of date. I will add to errata list.

6. use of 'double'
This is an error. They should be decimal. I will add to errata list.

7. The use of the # in hrefs was debated with the Architecture group.
For consistency with schema they were suggesting their removal. The
first set of examples of the FpML 1.0 examples recast however I feel
that they should all be consistent. I will raise this with the group
and try and get a resolution.

8. BulletPayment
It having two bullet payments in the product is an error. This was an
earlier version. It was changed for consistency so that the bullet
payment product was a single bullet payment, multiple ones are
represented as a productStrategy.

9. No product strategy example.
This was specifically excluded as we could not think of a legitimate
example in the IRD world. It was been added to increase flexibility (eg
if a system wants to represent a cancelable swap as a swap and a
swaption) but also with future asset classes in mind - for instance FX
want to be able to represent a fx option and it's associated spot hedge
as a single trade - a product strategy would be used.

These will be dicussed with the working group and decide whether it is
worth pushing out an updated document immediately or whether to leave
these points on the errata list for the moment.

Thanks for your thorough review.

Steven


-----Original Message-----
From: Paul.Newton
Sent: 20 September 2001 09:57
To: Lord, Steven
Cc: Paul.Newton
Subject: FpML2 specification - comments


Hi Steven,

Tried to send this to FpML-discuss but doesn't seem to have gone
through.  But I think you may be the appropriate person to send this to,
if not then bounce it back to me and I'll try to sort out what's
happening with the discussion group.

We've gone through the FpML2 working draft to update our toolkit to the
new version, and as usual it was quite thorough but we would appreciate
clarification of the following details:

FpML_ExerciseFee and FpML_ExerciseFeeSchedule:
   Both have an element "notionalReference" described as:
   "a pointer style reference to the associated notional schedule
   defined elsewhere in the document".
   What is the actual type of the object referred to; is it
   FpML_Notional, FpML_Schedule, FpML_AmountSchedule...?

Same question for FpML_FxLinkedNotionalSchedule and
FpML_PartialExercise

FpML_MandatoryEarlyTermination and FpML_OptionalEarlyTermination:
   Contain an element called "productReference".  What is it? - it's
   shown in the diagram but there is no descriptive text.
   Is it really an href (as with everything else ending with
"Reference")
   and if so, what is the type of the data to which it refers?

FpML_CancelableProvisionAdjustedDates:
   Text says "cancellable" provision, and contains element
   "cancellationEvent" which is of type FpML_CancellationEvent.
   Inconsistent spelling - should it be 1 or 2 L's?

FpML_AmericanExercise, FpML_EuropeanExercise, FpML_BermudanExercise:
   All contain "relevantUnderlyingDate" which is of type
   FpML_AdjustableOrRelativeDates.  Perhaps nit-picking but wouldn't it
   be clearer to use the plural "relevantUnderlyingDates" to be
   consistent with the plural on the type name?

FpML_Trade:
   The descriptive text needs to be updated, it doesn't describe the
   element productStrategy, and this I assume would be an instance of
   FpML_Strategy?

A general note - FpML 2 seems to introduce the use of a type "double" as
well as the previously used type "decimal".  Is this on purpose and if
so what's the distinction?

Examples 1-8 use "#" in hrefs while examples 9-26 don't.  Which should
it be?

Example 28 - bullet payment: the example contains 2 instances of element
"bulletPayment" in the product, but the spec says "exactly one
occurrence", although the subsequent text says "A product to represent
one or more known payments".  Which is it - one or several?

No examples provided using product strategy - this would be useful.

That's about it.  The examples provided were very useful for testing the
FpML2 release of our toolkit which is now available (subject to
refinement as the specification is firmed up).

Paul Newton
Kronos Software Ltd
E-mail: paul@...
Tel +44 20 7739 9272, fax +44 20 7739 5482, mobile +44 7768 166 648


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.

Please see below a note from Steven Lord, Chair of the Interest Rate
      Product Working Group, regarding the publication of the FpML Version
      2.0 Working Draft:

      -------------------------------------------------------------------

      FpML.org has published the FpML Version 2.0 Working Draft. This
      version extends the standard to include interest rate options
      (Swaptions, Caps/Floors) and extends the coverage of swaps (FX
      Resetables, Cancellables, Early Termination Provisions).

      This version has not been released as a Last Call Working Draft and as
      such will be subject to change based on feedback received. It is
      anticipated that a Last Call Working Draft incorporating any feedback
      will be published in November 2001.

      A copy of the standard can be obtained from: http://www.fpml.org/spec.

      Steven


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.

The Scheme URI for the Negative Interest Rate Treatment Scheme listed
in Section 8.2.12 of the FpML 1.0 Recommendation specification is
incorrect.  The correct URI is

http://www.fpml.org/spec/2001/negative-interest-rate-treatment-1-0

This has been added to the FpML Version 1.0 errata list at
http://groups.yahoo.com/group/fpml-issues/files/rec-fpml-1-0-2001-05-
14-errata.html

Guy Gurden
IRD Products WG

This note documents changes introduced between FpML Version 1.0 Trial
Recommendation 25 September 2000 (
http://www.fpml.org/spec/2000/tr-fpml-1-0-2000-09-25) and FpML Version 1.0 Trial
Recommendation 12 March 2001 (
http://www.fpml.org/spec/2001/tr-fpml-1-0-2001-03-12).

The FpML IRD Products Working Group, currently focusing on extending the FpML
product definitions to include interest rate options, has made a number of
changes to the FpML 1.0 Trial Recommendation which are described in this note.
A number of these involve structural changes to the DTD.  For the most part, the
motivation for these changes is to ensure that FpML Version 1.0 can form a solid
foundation to extend both the interest rate product coverage, as well as
accommodate the introduction of new products from other asset classes, for
example, equity derivatives and foreign exchange.

Two main structural changes have been introduced:

-  Within the trade component a product component has been added.  In FpML 1.0
this will contain a single swap or fra component.  The addition of the product
component will provide for cleaner containment as FpML product coverage
increases.

-  The FpML_FixingDateOffset entity, used by the <fixingDateOffset> element in
the swap component and by the <fixingDates> element in the fra component, has
been removed.  It has been replaced with a more reusable entity,
FpML_RelativeDateOffset, which allows a date (or series of dates) to be defined
as a relative offset from another date (or series of dates).  This new entity is
expected to used frequently in FpML Version 2.0.

Other changes of note are:

-  The period Scheme has been extended to include a new value of T (Term).  Term
is defined as the period commencing on the effective date of a stream and ending
on the termination date.  The addition of this value will allow support for the
specification of zero coupon swap structures where the calculation period is
assumed to be the full term of the stream with a single payment at maturity.

-  An optional element has been added for specifying the calculation agent for a
trade.

-  An optional element has been added for specifying how to calculate payments
when a floating rate is negative (either due to a quoted negative floating rate
or by operation of a spread that is subtracted from the floating rate).

-  An additional sample FpML trade has been added illustrating a Fixed/Floating
Overnight Interest Rate Swap (OIS).  The representation is consistent with
Exhibit-IID (Additional Provisions for a Confirmation of a Swap Transaction that
is a Self-Compounding Overnight Interest Rate Swap Transaction) in the 2000 ISDA
Definitions.

-  All references to the XML Schema Working Draft, either by name, URI or URL,
now refer to the 24 October 2000 XML Schema Candidate Recommendation.

-  All FpML-specific datatype constraints have been removed with the exception
of those for the date datatype.  The set of valid literals for each datatype are
now those defined in the XML Schema specification as being its lexical space.

The following is a summary of all the changes affecting the DTD:

1.  Within the entity FpML_Discounting the element <discountDayCountFraction>
has been renamed <discountRateDayCountFraction> (to align it with the ISDA term
of the same name).

2.  The entity FpML_FixingDateOffset has been removed.

3.  Within the entity FpML_FloatingRateCalculation a new optional element
<negativeInterestRateTreatment> has been added.

4.  The entity FpML_SwapStream has been renamed FpML_InterestRateStream.

5.  A new entity FpML_RelativeDateOffset has been defined.

6.  Within the entity FpML_Trade a new element <product> has been added that
contains a <swap> or <fra> element.

7.  Within the entity FpML_TradeHeader a new optional element
<calculationAgentPartyReference> has been added.

8.  dateRelativeToSchemeDefault and negativeInterestRateTreatmentSchemeDefault
attributes have been added to the <FpML> root element attribute list.

9.  A required id attribute has been added to the <adjustedEffectiveDate>
element attribute list.

10.  The <calculationAgentPartyReference> element and associated attribute list
has been added.

11.  The <dateRelativeTo> element and associated attribute list has been added
(used by FpML_RelativeDateOffset entity).

12.  The <fixingDaysOffset> element has been removed (was used by
FpML_FixingDateOffset entity which has been removed).

13.  The <negativeInterestRateTreatment> element and associated attribute list
has been added.

14.  The id attribute on the <resetDates> element is now required.

Other changes to the documentation are:

15.  Working Group Members and Acknowledgements.  Various company names have
been updated.

16.  Section 2.1 Scope.  Minor wording changes in the paragraphs describing what
is outside the scope of the Products Working Group.

17.  Section 2.2 Architecture Framework.  Changed company name from
Extensibility to TIBCO Extensibility.

18.  Section 4.3 FpML_BusinessDayAdjustments.  Added wording under
<businessDayConvention> element relating to a business day convention of NONE.

19. Section 4.3 FpML_InterestRateStream.  As a result of renaming entity (from
FpML_SwapsStream to FpML_InterestRateStream) the entity description has been
changed to make it more generic.

20.  Section 4.3 FpML_Interval.  Added wording under <period> element relating
to population of this element when <periodMultiplier> element value is zero.

21.  Section 4.3 FpML_Offset.  Added wording under <dayType> relating to a zero
day offset.

22.  Section 4.3 FpML_PaymentDates.  Added clarification to <payRelativeTo>
element relating to adjusted dates.  Also added additional usage information to
the <firstPaymentDate> , <lastRegularPaymentDate> and <paymentDaysOffset>
elements.

23.  Section 4.3 FpML_ResetDates.  Added clarification to <resetRelativeTo>
element relating to adjusted dates.  Added text to <resetFrequency> to indicate
how averaging is indicated through the relationship of reset frequency and
calculation period frequency.  Added additional usage information to the
<rateCutOffDaysOffset> element.

24.  Section 4.3 FpML_ResetFrequency.  Added text to entity description to
indicate how averaging is indicated through the relationship of reset frequency
and calculation period frequency.

25.  Section 8.2 Coding Schemes.  Added dateRelativeToScheme and
negativeInterestRateTreatmentScheme Scheme definitions.  Note that these have an
issue year of 2001 in their URI.

26.  Section 9.6 Sample FpML.  Examples have been updated to reflect changes to
the DTD.  Also corrected errata in Example 5; replaced EUR-EURIBOR-TELERATE with
EUR-EURIBOR-Telerate to match upper/lower case mix in the ISDA Floating Rate
Option Definition.

Guy Gurden
IRD Products WG Chair



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.

This e-mail outlines the changes introduced between:

FpML Architecture Version 1.0 Trial Recommendation 25 September 2000 (
http://www.fpml.org/spec/2000/tr-fpml-arch-1-0-2000-09-25)

and

FpML Architecture Version 1.0 Trial Recommendation 21 December 2000 ((
http://www.fpml.org/spec/2000/tr-fpml-arch-1-0-2000-12-21)

The FpML Architecture Version 1.0 Trial Recommendation is a DTD based standard.
However, sections of the document were impacted when XML Schemas moved from a
Working Draft to a Candidate Recommendation.

1.   All references to the XML Schema Working Draft, either by name, URI or URL,
now refer to the 24 October 2000 XML Schema Candidate Recommendation.

2.   Section 4.4, example of equivalent XML Schema: namespace URI updated to
reflect Candidate Recommendation.

3.   Section 4.8, example of equivalent XML Schema: namespace URI updated;
example reworked to use substitutionGroup's and extension syntax -- replacing
    the XML Schema Trial Recommendation syntax.

4.   Section 4.9, example of equivalent XML Schema: similar reworking of
example.

In addition, all three examples have been validated against the XML Schema
Validator listed in the tools section of the W3C Schema page (
http://www.w3.org/XML/Schema).

Robert Silver
FpML 1.0 Architecture Working Group



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co. Incorporated, its
subsidiaries and affiliates.

The National has been reviewing the FpML Trial Recommendation with a view
       to the recommended standard and to extend the standard to meet additional
       requirements for the Bank.  In undertaking this process we have have
       detected what we consider may be a minor omission, in the FRA definition.

       Currently, the FRA template does not provide for the payment date to be
       defined.  In Australia, it is possible that the settlement amount of an
       FRA may not occur on the date that the rate (and hence the settlement
       amount) is fixed.  At National, we have considered extending the FpML
       definition to include an adjustment for payment date.  This, however,
       would mean that there are deals which could not be fully specified by the
       FpML model.  Such a scenario would adversely affect a B2B confirmation.

       If we have missed an element of the definition, then we would be grateful
       for your guidance.  Otherwise, we request that you consider including a
       structure to allow for the specification of a payment date which differs
       from the settlement date of the FRA.

           The National is evaluating FpML as a basis for standard XML
       definitions of  Financial Instruments and is keen to participate in
       dialogue regarding its development.  We would als like to know when is it
       proposed that the FpML - Trial Recommendation will become a Full
       Recommendation?

       Regards
       Max Gillmore
       Project Manager - Global Wholesale Technology Systems Solutions



__________________________________________________________________________
The information contained in this email communication may be confidential. You
should only read, disclose, re-transmit, copy, distribute, act in reliance on or
commercialise the information if you are authorised to do so. If you are not the
intended recipient of this email communication, please notify us immediately by
email to NABpost@... or reply by email direct to the sender
and then destroy any electronic or paper copy of this message.  Any views
expressed in this email communication are those of the individual sender, except
where the sender specifically states them to be the views of a member of the
National Australia Bank Group of companies.  The National Australia Bank Group
of companies does not represent, warrant or guarantee that the integrity of this
communication has been maintained nor that the communication is free of errors,
virus or interference.

This e-mail outlines the changes introduced between:

FpML Version 1.0 Last Call Working Draft 1 June 2000 (
http://www.fpml.org/spec/2000/wd-fpml-1-0-2000-06-01)

and:

FpML Version 1.0 Trial Recommendation 25 September 2000 (
http://www.fpml.org/spec/2000/tr-fpml-1-0-2000-09-25).


DTD Changes
-----------

1. The only changes to the DTD relate to the addition of optional id attributes
to a number of elements.  Further discussion of this can be found at:

http://www.egroups.com/message/fpml-issues/1 and
http://www.egroups.com/message/fpml-issues/2


Changes Resulting from the Publication of the 2000 ISDA Definitions
-------------------------------------------------------------------

2. The 2000 ISDA Definitions were published in July 2000. Where references were
being made in the specification to specific sections of earlier ISDA Definitions
these have been updated to refer to the relevant section in the 2000 ISDA
Definitions.

3. Changes were made to the following coding Schemes as a result of its
publication:

- businessCenterScheme
- dayCountFractionScheme
- floatingRateIndexScheme

Details of the changes are described in the following section.



Coding Scheme Changes
---------------------

4. It was decided to add the date, e.g. /2000/,  into the URIs for all the
FpML-defined coding Schemes.  Note that this does not apply to those external
coding Schemes, without a well-known URI, where FpML assigns a URI as a proxy.

5. Additional business center domain codes were added into the
businessCenterScheme to reflect additional centers defined in the 2000 ISDA
Definitions and additional codes being used by S.W.I.F.T. in their MT340/MT360
messages.

6. The dayCountFractionScheme domain values were aligned with those specified in
the 2000 ISDA Definitions.  The list of domain values in the Last Call Working
Draft had been based on a draft version of the 2000 ISDA Definitions.

7. The floatingRateIndexScheme is now categorized as an external coding Scheme
which does not have a well-known URI.  In this case, FpML assigns a URI as a
proxy to refer to the concept of the external Scheme.  A number of different
proxy URIs have been defined to allow floating rate index code definitions to be
associated with specific definitions and provisions published by ISDA. The
sample FpML trades show examples of how these different URIs should be used.


Documentation Changes
---------------------

8. The definitions of a number of date or schedule elements have been improved
to make it clear either:

a) if the date(s) are unadjusted or adjusted
b) if adjusted, where the adjustments should come from.

Specific elements affected are:

- <firstPeriodStartDate>
- <firstRegularPeriodStartDate>
- <lastRegularPeriodStartDate>
- <firstPaymentDate>
- <lastRegularPaymentDate>
- <firstNotionalStepDate>
- <lastNotionalStepDate>
- <notionalStepSchedule>
- <fixedRateSchedule>
- <spreadSchedule>
- <capRateSchedule>
- <floorRateSchedule>
- <knownAmountSchedule>

9. The description of the FpML_CalculationPeriodDates entity has been changed to
make it clearer that implicit stubs are not allowed.

10. Various errata was corrected including:

a) that identified in: http://www.egroups.com/message/fpml-issues/3
b) occurrence rule for element <floorRate> in entity FpML_FloatingRateDefinition
should have read 'zero or one occurrence'. DTD and DTD diagram had always been
correct.

11. Section 8.2.1 (Coding Schemes - Introduction) was modified to ensure
consistency with the Schemes definition in the FpML Architecture 1.0 Trial
Recommendation.

If you have any questions regarding these changes please post them to the FpML
discussion group (fpml-discuss@egroups.com).

Regards
Guy Gurden
FpML Products Working Group



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.

Tim,

Thanks for pointing out these typos.  They have all been corrected in the FpML
1.0 Trial Recommendation which will be published on the website shortly.

Guy Gurden
FpML Products Working Group



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.

Hi there,
I want to make you aware of typo errors on page 118.
TreatedRate, UnadjustedDate and WeeklyRollConvention
should be
treatedRate, unadjustedDate and weeklyRollConvention
to be conformant with the lowerCamelCase.
Regards,
Tim Mueller-Seydlitz
tms@...

The FpML Products Working Group have considered the issue posted at:
http://www.egroups.com/message/fpml-issues/1.

They have agreed that an 'id' attribute should be present on all FpML 1.0
elements with a content model occurrence rule of 'one or more' (+) and 'zero or
more' (*).  On elements with an occurrence rule of 'exactly one' or 'zero or
one' (?) the presence of the 'id' attribute should be considered on a case by
case basis.  Where the presence of an 'id' attribute on an element is not driven
from the requirement to reference that element from another FpML 1.0 element
(through use of a corresponding 'href' attribute) the 'id' attribute will appear
in the DTD with a #IMPLIED keyword.

Following review of the current FpML 1.0 Working Draft (
http://www.fpml.org/spec/2000/wd-fpml-1-0-2000-06-01/) an 'id' attribute will be
added to the following elements:

<additionalPayment>
<businessCenter>
<calculationPeriod>
<indexTenor>
<linkId>
<otherPartyPayment>
<partyTradeIdentifier>
<paymentCalculationPeriod>
<principalExchange>
<rateObservation>
<step>
<swapStream>
<trade>
<tradeId>

With the exception of the <trade> element, all the elements satisfy the '+' or
'*' occurrence rule described above.

Jonathan Chapman
FpML Products Working Group

It is highly probable that if an FpML product definition is used internally with
an organization the FpML may be embedded within some proprietary XML.  In such
cases it may prove desirable to be able to reference in to the FpML product
definition.

FpML 1.0 provides a basic reference mechanism based on the use of the id and
href attributes.  Currently, the requirement for each id attribute in FpML 1.0
has been driven from a need to reference that id from one or more href
attributes defined within the FpML 1.0 tag set.  For example, the id attribute
on the <party> tag would logically be referenced through href attributes on the
tags <partyReference>, <payerPartyReference>, <receiverPartyReference>,
<buyerPartyReference> and <sellerPartyReference>.

It would seem sensible to extend this concept and allow id attributes to
optionally be specified on additional elements where there may be a requirement
to reference those elements from outside the existing FpML 1.0 tag set.  For
example, consider a case where an FpML trade definition is used for application
integration within an organization.  An application may have a identifier for
each individual stream within a trade, e.g. a simple sequence number such as  1,
2, 3 etc. or a named type - simpleFixed, simpleFloating etc. and may wish to
associate additional information such as a trading book with each stream.  By
adding an id attribute to the swapStream element it would be possible to
reference an individual stream from within a proprietary tag set where
additional stream attributes could be held.

A review of the current tag set would suggest the following elements where there
is arguably a business rationale for allowing an id attribute.  These elements
all have occurrence rules or '*' or '+', i.e. they are repeating elements.
Alternatively, an id attribute could be allowed on any FpML 1.0 element.

additionalPayment
calculationPeriod
floatingRate
otherPartyPayment
partyTradeIdentifier
paymentCalculationPeriod
principalExchange
rateObservation
step
swapStream
trade
tradeId

Guy Gurden
J.P. Morgan



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.