A trader denies placing an order and the order log holds only a timestamp - what must an audit entry contain to settle the dispute?

## Reframe the question before answering it A repudiation control is not judged by whether a log line exists. It is judged by whether it would persuade a **third party who was not present** - a counterparty, an internal investigator, a regulator, a court - months or years later. That framing generates every requirement below, and it is the framing a senior interviewer is listening for. ## The fields that settle a dispute **Who.** An authenticated principal that resolves to one person or one service, with the authentication context attached: which credential or factor, which session, which login event. `order created` names nobody. `desk-trading-svc` names nobody either - a shared or service identity converts a good log into an unattributable one, and no amount of extra fields recovers that. **What.** The action and all parameters that matter to the dispute. "An order was created" is compatible with any order; the disputed facts are instrument, side, quantity, price, account and any modification or cancellation that followed. Log the request as submitted, not a summary generated afterwards. **When.** Trustworthy, synchronised time, recorded unambiguously (UTC with offset, not the local time of whichever host happened to serve the request). Clock drift is the classic way an otherwise good trail becomes arguable, because sequence between two systems can no longer be established. **Where and how.** Source address, device or session identifier, the API or UI path used, and a correlation identifier that ties this entry to the rest of the request's trail. This is what lets you reconstruct a story rather than present one isolated line. **Under what authority.** Which role or entitlement the action was permitted under, and the authorization decision itself. "Allowed because the principal held trader-desk-3" answers a different and often more important question than "the action happened". **What not to include.** Credentials, tokens, full card numbers and unnecessary personal data do not strengthen evidence and turn the evidence store into a breach target. Record identifiers and, where the payload itself is sensitive, a hash of the payload rather than the payload. ## Custody: who could have produced this entry? This is the question that separates a real answer from a field list. A record proves something only against parties who could not have made it up. - An entry written by our order service and stored in a database the trading desk's own administrators control is weak against a claim of internal fabrication or deletion. Ship it, continuously, into a store under separate administrative control, and keep it there for at least the dispute and regulatory window. - An entry protected by a **message authentication code with a shared key** proves only that *someone holding the key* produced it. If the server and client share it, or the server both signs and verifies, it establishes integrity but not attribution - it is not non-repudiation. - A **digital signature over the order made with a private key only the trader controls** is the strong form: verification uses the public key, so a third party can check it without trusting us, and we could not have manufactured it. That is why the strongest non-repudiation designs push signing out to the acting party rather than keeping it server-side. ## Evidence produced by the party who might dispute it The mirror-image failure appears in a mobile in-app purchase: the client posts `purchase completed` and the server records the claim verbatim. That entry can never be non-repudiable in either direction - it was generated inside territory the customer controls, so it neither proves the customer bought anything nor proves they did not. The fix is structural, not better logging: obtain a receipt signed by a party neither side controls and verify it server-side, then keep the verified receipt as the record. **Evidence must originate outside the control of the party it is used against.** ## Non-repudiation is never absolute Expect the pushback: "my credentials were stolen". No log answers that on its own. What it does is move the argument from *was it this account* to *was it this person*, which is why the strength of authentication at the time matters to the evidence value - a step-up factor, a bound device, a signed confirmation. Corroboration helps too: the session that created the order, the device it came from, the sequence of surrounding actions. Non-repudiation raises the cost and implausibility of denial; it does not produce metaphysical certainty, and claiming it does is a red flag in an interview. ## Retention and retrievability An entry you cannot retrieve within the dispute window is not evidence. Retention has to exceed the realistic period in which disputes appear (in trading, years, driven by regulation), the storage has to survive schema and system migrations, and someone has to be able to answer a targeted "show me everything principal X did on this order" query without a rebuild project. Design that access path deliberately - it is the moment the whole control either pays off or does not.