FpML Issues Tracker
closed
Feature
Always
Feedback and Suggestions
SBoroditsky
mgratacos
Summary
We are working on a FTP drop of FpML formatted contract messages and have an issue with more than one FpML document in a single file due to multiple declarations of the same party (i.e. the partyid="party1" appears more than once in the file).
Is there a recommended way to handle batch transfer of contract documents or is this type of optimization not supported (i.e. each message must be sent and processed individually rather than in a batch)?
Notes:
mgratacos
01/27/10 3:41 pm
I’ve seen different ways to handle this. Some people append an additional identifier to the id attribute value to make it unique through the batch file. For example, to append the trade id value. In the first trade of your example,, 1234 being the tradeId value, which should be unique across multiple trades.
Some people use the same value as the partyId element value (1234) and the code is smart enough to remove duplicate parties.
BrianLynn
01/27/10 6:58 pm
Best practice is to track the parties that are needed in the file and ensure that each party is generated only once. The party id attributes need to be unique; this can be done using a firm-specific identifier or by generating a unique ID value (could just be a sequential number).
All parties appear in the file after all position or trade records, so by the time you are writing out the parties, you know which ones you need.
A number of firms have implemented this so this approach is known to be implementable.
h_mcallister
01/28/10 1:03 pm
Here is a simple stylesheet which implements Marc’s suggestion of appending a unique suffix to the @id (please see batch.party.id.xsl, attached) – I use the ordinal position of the FpML document in the batch file to guarantee uniqueness (tradeId is okay only if you are certain that it cannot be repeated within the batch document).
The stylesheet is based on the identity transformation; the identity behaviour is modified for instances of partyReference/@href and party/@id, which are suffixed to guarantee uniqueness. Note that the new id/href value is based only on the properties of the referenced/identified party, not on the original id/href values – so you could create an entirely new id/href scheme if desired, while maintaining the original referential integrities.
Marc & Brian both mentioned the possibility of eliminating duplicate parties, which is a reasonable aim. The FpML DataDocument allows multiple trades to be included in a single message, followed by a collection of (preferrably unique) parties – however FpML does not provide a structure to support mixed processing semantics on multiple trades (e.g. TradeExecution, TradeExecutionModified, TradeExecutionCancelled).
Best regards,
Harry McAllister