Anonymizing FIX logs without breaking them: BodyLength, CheckSum and the five traps

When a counterparty requests a log, the first step is to remove sensitive information such as client IDs, account numbers, and names. A simple find-and-replace method can be used, but it can inadvertently disrupt the session because FIX messages include two integrity fields that depend on the exact byte sequence. The BodyLength field (9) specifies the number of bytes after the SOH (Start of Header) character up to the next SOH before the 10= field.

The CheckSum field (10) is the sum of each byte from the 8= field through the same SOH, modulo 256, and written as three digits. Altering 1=ACC-77812 to 1=ACCT_1 will corrupt both fields, causing the receiving engine to reject or drop the message. To compute the new values, start with the SOH character (0x01), create an encoder object for UTF-8 encoding, and map each [tag, value] pair into a string format, excluding fields 8, 9, and 10.

The finalize function combines all these components to generate a complete FIX message, ensuring that the BodyLength and CheckSum fields remain accurate. The five common pitfalls to avoid are counting bytes, not characters, using consistent tokens for mapping, recalculating length-prefixed fields when modifying data, and handling repeating groups carefully, as they often contain sensitive information.

SafeFIX, a free tool for up to 100 lines, provides a browser-based solution that anonymizes accounts, IDs, names, and free text while maintaining token maps and recomputing the 9 and 10 fields for every message. A synthetic log generator, fix-iso20022-samples, is available for testing any anonymization method.