2. FpML 4.xFpML 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)

3. FpML 4.xFpML 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

4. FpML 4.xFpML 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 Corrections use same message type as original but later sequence number isCorrection element indicates a correction Every operation has a consistently named retraction message

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

6. FpML 4.xFpML 5 Contract Notifications have no response messages Cant 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