Migrating from FpML 4.x Contract Messages

Message Comparison FpML 4.x FpML 5 10 message types: ContractCreated ContractCancelled ContractIncreased ContractIncreasedCancelled ContractPartialTermination ContractPartialTerminationCancelled ContractFullTermination ContractFullTerminationCancelled ContractNovated ContractNovatedCancelled New messages proposed for: Amendments Non-negotiated changes Full terminations not used by CUG Based on ‘Contract’ payload Messages proposed for each of the same operations Except full and partial terminations combined into one message Includes amendments and non-negotiated changes Based on ‘Trade’ payload Consistent with other business process (i.e. Confirmation) FpML 4.x FpML 5

Correlation & Sequencing ‘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 And Retractions 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 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 4.x FpML 5

Trade vs Contract 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

Message Flow Contract Notifications have no response messages Can’t indicate success or failure SWIFT network can only provide delivery receipt New messages have both negative and positive responses Could be omitted by implementers if necessary FpML 4.x FpML 5