From: owner-colwg@xxxxxxxx [mailto:owner-colwg@xxxxxxxx] On Behalf Of richard.barton@xxxxxxxxxxxxxxxx
Sent: Wednesday, May 12, 2010 11:24 AM
To: colwg@xxxxxxxx
Subject: FPML-CWG FW: [fpml-coord] FW: Collateral rounding vs FpML <rounding> definition
From: harry.mcallister@xxxxxxxxxxxxxxxxx [mailto:harry.mcallister@xxxxxxxxxxxxxxxxx]
Sent: Wed 5/12/2010 6:55 AM
To: coord@xxxxxxxx
Cc: Richard Barton
Subject: Re: [fpml-coord] FW: Collateral rounding vs FpML <rounding> definition
Hi Richard,
I'm not convinced that the Rounding type would support the proposed extended definition. The existing interpretation of Rounding is clear:
<rounding>
<roundingDirection>Nearest</roundingDirection>
<precision>5</precision><!-- interpreted
as precision (decimal places) -->
</rounding>
At first glance, the proposed usage is also
clear:
<rounding>
<roundingDirection>Nearest</roundingDirection>
<precision>500000</precision><!-- readily
interpreted as an amount (not probable as a number of decimal places)
-->
</rounding>
but intermediate cases
might be ambiguous ...:
<rounding>
<roundingDirection>Nearest</roundingDirection>
<precision>10</precision><!-- is this a
currency amount, or a rather precise decimal value? -->
</rounding>
I don't think it would be safe to leave the
interpretation to context, if only for the reason that it makes automated
processing all the more difficult. We could add an extra element to the type to
help disambiguate the usage, but that negates the original intention to avoid
creating a new type.
Instead of
overloading the Rounding type, I would recommend the approach used in the case
of partial & multiple exercise, where the minimum exercisable notional
amount is represented by minimumNotionalAmount, and the unit multiple by
integralMultipleAmount (see: fpml-shared-4-x.xsd, also diagram
below).
We could add an optional
transferMultipleAmount element (or similar) immediately following the
minimumTransferAmount. Where present, the element specifies the rounding
amount for transfer (e.g. 500000); if absent, no rounding constraints apply. The
element could be placed in an optional sequence with the roundingDirection,
so that the direction must always be specified when the element is present.
Then an instance would look something like:
<segregatedIndependentAmount>
<minimumTransferAmount>1000000</minimumTransferAmount>
<transferMultipleAmount>500000</transferMultipleAmount>
<roundingDirection>Nearest</roundingDirection>
</segregatedIndependentAmount>
Best regards,
Harry
__________________________________________________________________________
Harry
McAllister | Information Architect | Fixed Income Architecture |
BNP Paribas
4R223 | 10 Harewood Avenue | London NW1 6AA
tel:
+44 (0)20 7595 3416 | email : harry.mcallister@xxxxxxxxxxxxxx
| Internet
richard.barton@xxxxxxxxxxxxxxxx Sent by: coord@xxxxxxxx 12/05/2010 00:47
|
|
All:
The Collateral WG would like to reuse the existing <rounding> element in the collateral messages it is in the process of defining for FpML 5.1. However, the current FpML definition is not a perfect fit, although the concept of rounding is similar.
The Working Group would like to seek advice from the Coordination Committee on the possible reuse/expansion of the rounding structure.
--
Collateral Rounding
In the “margin call” collateral message there is a Rounding data field that could possibly be modeled using FpML <rounding> element. However, the current FpML definition is not a perfect fit. Instead of creating a new type, could the current definition be expanded in the specification?
Say the collateral to be posted is $10.2M (10,200,000). The margin call issuer party wants to specify that the amount should be rounded to the nearest $500,000. The margin call receiver would process the message and round the collateral to be posted to $10,000,000.
<segregatedIndependentAmount>
<minimumTransferAmount>1000000</minimumTransferAmount>
<rounding>
<roundingDirection>Nearest</roundingDirection>
<precision>500000</precision> <!-- can the rounding definition be expanded? -->
</rounding>
</segregatedIndependentAmount>
In this example, the precision of 500,000 captures a whole amount (as opposed to a number of decimals, as currently defined in FpML). The following are examples of expected calculations based on various rounding values:
- Total Collateral $10,200,000 (rounding = $500,000) -> $10,000,000
- Total Collateral $10,200,000 (rounding = $100,000) -> $10,200,000
- Total Collateral $10,160,000 (rounding = $100,000) -> $10,200,000
- Total Collateral $10,160,000.25 (rounding = $100,000) -> $10,200,000
However, In FpML 4.7, <rounding> defines <precision> in terms of decimal places:
<xsd:complexType name="Rounding">
<xsd:annotation>
<xsd:documentation xml:lang="en">A type defining a rounding direction and precision to be used in the rounding of a rate.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="roundingDirection" type="RoundingDirectionEnum">
<xsd:annotation>
<xsd:documentation xml:lang="en">Specifies the rounding direction.</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="precision" type="xsd:nonNegativeInteger">
<xsd:annotation>
<xsd:documentation xml:lang="en">Specifies the rounding precision in terms of a number of decimal places. Note how a percentage rate rounding of 5 decimal places is expressed as a rounding precision of 7 in the FpML document since the percentage is expressed as a decimal, e.g. 9.876543% (or 0.09876543) being rounded to the nearest 5 decimal places is 9.87654% (or 0.0987654).</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
Please note that rounding direction would be either Up, Down or Nearest.
Thanks, Richard
This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory.
This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory.
___________________________________________________________ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is prohibited. Please refer to http://www.bnpparibas.co.uk/en/information/legal_information.asp?Code=ECAS-845C5H for additional disclosures.