Checksum integrity check

The BodyLength field, or tag #9 indicates the record length of the message. The record length of the message can be verified by counting the number of characters in the message that follows tag #9, up to and including the delimiter that precedes the Checksum field, or tag #10. The record length is enforced as a component rule on the FIX type trees, which means that any FIX message in which actual record length is not consistent with the value found on tag #9 fails FIX type tree validation.

The Checksum field, or tag #10, indicates the checksum of the message, and can be verified by summing the binary value of each character from the BeginString field, or tag #8 (starting from ‘8=’), up to and including the <SOH> character immediately preceding the tag #10 field. This checksum is then transformed into a modulo 256 number and compared against the tag #10 value.

This is enforced not as part of the FIX type tree component rules but as a separate step by using utility maps that are shipped with the pack. This is due to the complexity of enforcing the checksum algorithm as a component rule in a type tree and varied implementation requirements as to when to enforce the checksum digit verification against a FIX message.

The WebSphere Transformation Extender Pack for FIX provides utility maps that can be used to perform checksum integrity check. The following maps are available as part of the map source, fix_checksum.mms, under the following folder:

install_dir\packs\fix_vn.n.n\checksum

Information about the utility maps can be found in The checksum subdirectory documentation that is provided here. Examples on how to use the utility maps as part of validating the checksum can be found on all the example maps converting FIX to FIXML under the install_dir\packs\fix_vn.n.n\examples folder. Examples on how to use the utility maps to populate the Checksum field, or tag #10 can be found on all the example maps converting FIXML to FIX under the \examples folder.