Trading chart on a display

Audit trails

When timestamps lie: reading sync logs with skepticism

Audit trails feel authoritative because they are precise. Precision is not the same as truth. Sync logs often record when a system noticed an event, not when the economic event occurred.

Three clocks in one story

User device time, application server time, and ledger posting time rarely agree. A mobile confirmation stamped 23:58 KST may land in a UTC server log as the next day and in the ledger on the next business day. Your working paper should name which clock each field uses.

Queues delay honesty

Message queues and retry logic can stamp “processed” hours after “received.” If you sample on processed time alone, you will miss items that were economically in-period but operationally delayed. Prefer dual timestamps when the vendor exposes them; when they do not, document the gap as a system limitation.

Soft evidence still needs a label

When you cannot prove exact timing, say so. “Evidence limited to processed_at; source event time unavailable in export contract v3” is more useful than a false sense of certainty. Reviewers can work with named gaps. They struggle with silent ones.

Practical habit

Add a timestamp dictionary to every export contract: field name, clock source, timezone, and whether daylight rules apply. It is unglamorous. It prevents half of the “why doesn’t this match?” threads we see in office hours.

Continue with the cutoff module in our course listing, or ask the desk via contact.