Nobody Will Ask Whether the Software Got the Dispute Right. They Will Ask What It Filed, to Whom, and When

The question your finance team gets is not "was the deduction wrong."

It is: show me what was filed, which retailer it went to, on what evidence, and at what time.

Those are four questions and they need four records. A brand running eleven retailer relationships and a few thousand chargebacks a quarter does not need software that argues well. It needs software that can be asked, months later, by somebody who was not in the room, to produce a packet, a timestamp and a recipient.

That is an audit question, and it is not a quality question.

What is already in place

The dispute path is deliberately uninteresting. The same chargeback, the same documents and the same retailer profile produce the same packet, because the rules are code rather than judgement and the packet is generated from them. Calling file again on a chargeback that already has a packet returns the existing one and writes nothing, so there is never a second version of the truth.

That last row is the one to interrogate, because it is the mechanism this post is actually about.

Outbound events are signed. The signature is an HMAC-SHA256 over the exact request body, sent in the x-disputek-signature header as sha256= followed by the hex digest, alongside the event name, a delivery ID and an ISO timestamp. Your receiving system can recompute it from the raw bytes and its own secret and refuse the payload if it does not match. The secret is generated when the endpoint is created, not chosen by you. There are three events you can subscribe to: an analysis finishing, a chargeback changing, and a test ping.

Each delivery writes a row before the request leaves and updates it afterwards: the payload, the event, a status of pending, delivered or failed, the number of attempts, the last error, and the time it landed. Retries are four attempts with one-second, ten-second and sixty-second gaps and a ten-second timeout, so a hung receiver is cut off instead of retried forever.

Two details in that path are worth more than they look. Redirects are never followed, because a 302 pointed at an internal address would walk past the destination check. And the destination is re-validated before every attempt, not once at setup: a hostname that resolved publicly when you created the endpoint has to still resolve publicly at sixty seconds. The code also names its own residual risk in a comment, the guard resolves the name and the HTTP client resolves it again, so a name that rebinds between the two could still reach a private address.

What is missing, stated plainly

Three gaps. None of them should reach you in a sales conversation.

An actor, but not a log. A dispute records the uid of the account that last moved it, and a generated packet records the account that generated it. So "who filed this" has an answer, and it is not "your account." Two things it is not: the uid identifies the authenticated account rather than a named person inside a company, and the field is overwritten on the next move, so it answers "who last acted" and not "what happened, in what order." An append-only event log is what answers the second question. That is the missing piece here.

No tamper evidence. The delivery row is inserted, then updated in place to delivered or failed. The payload is stored, and the signature is recomputed from that payload and the endpoint secret, but the signature itself is not kept beside it, and the endpoint that lists deliveries returns the outcome rather than the body. The log is good evidence of what happened. It is not yet evidence that cannot be edited.

Lineage by relation, not by hash. An analysis points at the dataset it came from, and the dataset holds the raw document text. That is a usable chain of custody. It is not a cryptographic statement that these are the bytes a person reviewed.

Durable, tamper-evident storage of what was assembled and filed is a later conversation. It is not in the product today and this post is not going to pretend otherwise.

Why the protocol is where this gets solved

The buyers who ask the hard version of this question work in industries that already regulate the answer.

The Model Context Protocol's Financial Services Interest Group, initial charter 2026-06-25, facilitated by Bloomberg and Saxo Bank, is chartered around tamper-evident, portable records of what a tool call did, under what authority and against which policy, plus data lineage, provenance and attestation, with enforcement handled through an Interceptors working group. That is this post's problem statement, written by people who answer to regulators rather than by us.

The specification release of 2026-07-28 tightened the transport in the same direction: mandatory Mcp-Method and Mcp-Name header routing, cacheable list results, and a twelve-month minimum deprecation window. The deprecation window is the part that matters to you. A tool-call record whose field names move every two quarters is a reconstruction project, not a record.

So ask for the trail as protocol rather than as a toggle in somebody's settings screen. One honest note on our own side: the server we publish exposes three tools: a health check, a chargeback list and a document upload. It does not file disputes. Filing happens in the dashboard and the API, where the packet, the findings and the lifecycle transition are written. When a filing tool does go out over the protocol, the record question gets answered at the layer everybody now has to speak.

The sober version

An audit trail is not a compliance badge, and the profession that cares most about this said so first.

AICPA Peer Review Board guidance dated 2026-05-14 tells reviewers of SOC 2 work to pull roughly five engagements from different audit firms and compare them for identical risk assessments, control designs, sample sizes and testing procedures. Identical is nonconforming and can trigger a deficiency finding. The client-side version of the same test is blunter: compare any five of the reports and they are all exactly the same, with a different client logo on it.

The reasoning transfers without effort. A signed delivery log is evidence of what happened; it is not a substitute for controls somebody can inspect. The real test is whether you can walk from a single filed dispute back to a control, a rule version and a person, and whether the record is complete enough that a missing entry means something. An append-only ledger that turns out to be three timestamps and a generated ID fails that test, and you should say so.

That paragraph cuts against us as much as for us, which is the only reason to believe the rest of it.

The narrow position

A tool that files disputes should be the most boring thing in your stack. Deterministic, signed, timestamped, replayable, and visible to the person who has to answer for it. Not clever. Boring in the sense that you can draw the whole mechanism on a whiteboard and nothing on the whiteboard changes next quarter.

That is the standard, not a feature list. Where we sit against it: our packets are deterministic and signed, and a dispute records which account last moved it. What we do not have is the fourth item, replayable needs an append-only log, and a mutable "last changed by" field is not one. Two of five, honestly counted.

If you are drawing that whiteboard this month, two pieces usually go missing. The packet contents: what each retailer's document list actually requires. And the loop the packet sits in, which is the same six steps at eleven retailers, thirty days at Walmart, 48 business hours at Home Depot.

A dispute you cannot prove you filed is a dispute you filed on time and cannot prove. Those are the two windows that close while you are still assembling the evidence.