Transcript Contract vs FpML 5 Trade Message Sequences


10 message types:
◦
◦
◦
◦
◦
◦
◦
◦
◦
◦



ContractCreated
ContractCancelled
ContractIncreased
ContractIncreasedCancelled
ContractPartialTermination
ContractPartialTerminationCancelled
ContractFullTermination
ContractFullTerminationCancelled
ContractNovated
ContractNovatedCancelled

◦ Except full and partial
terminations combined
into one message

New messages proposed for:
◦ Amendments
◦ Non-negotiated changes
Full terminations not used by
CUG
Based on ‘Contract’ payload
FpML 4.x
Messages proposed for
each of the same
operations

Includes amendments
and non-negotiated
changes
Based on ‘Trade’ payload
◦ Consistent with other
business process (i.e.
Confirmation)
FpML 5


‘conversationId’
convention used to
relate messages
Sequencing derived
from contract identifier
versions

Explicit ‘correlationId’
element used to relate
messages
◦ Could be populated with
value currently in the
‘conversationId’

Explicit ‘sequenceNo’
element
◦ Could be populated from
identifier version number
FpML 4.x
FpML 5


Corrections handled by
resending same
message type with
later version
Every message type
has a ‘cancel’ message
to retract
◦ Naming of
ContractCreated and
ContractCancelled
inconsistent with other
messages
FpML 4.x

Corrections use same
message type as
original but later
sequence number
◦ isCorrection element
indicates a correction

Every operation has a
consistently named
retraction message
FpML 5

All the features of contract can be mapped to
trade
◦ See paper for details

No additional information is required
◦ Could use XSLT to map from one to the other

Contract Notifications
have no response
messages
◦ Can’t indicate success or
failure
◦ SWIFT network can only
provide delivery receipt
FpML 4.x

New messages have
both negative and
positive responses
◦ Could be omitted by
implementers if necessary
FpML 5