Dispute evidence workflow — chargeback investigator path

1. The case opens

A chargeback investigator’s first action is to bind the case to a transaction. Card schemes’ dispute-resolution rules — Mastercard’s Chargeback Guide / Mastercom case management [1] (consult the current Mastercard Rules edition for the dispute-cycle definitions in force), Visa’s Dispute Resolution Rules / Visa Resolve Online (VROL) [2] (consult the current Visa Core Rules and Visa Product and Service Rules edition) — have used categorical reason codes for decades and continue to operate on ISO 8583-driven message envelopes (with scheme-specific overlays). ISO 20022 [4] is the message scheme the broader payments industry is migrating towards on credit-transfer rails (SEPA Instant, RTGS, CBPR+), but chargeback intake on card rails today remains ISO 8583 with scheme-specific reference fields. The operational primitive remains: case id ↔ transaction reference.

In an EEI deployment, the operator’s host application set a transaction context (tctx) when it initialised the TRP at the start of the disputed flow. That tctx is in the signed record. It is also in the operator’s authorisation log, the transaction record, the fraud-score row, and the back-office case file. The case file is bound to the EEI corpus by the same key the operator already uses; no new join discipline is introduced.

2. Querying the corpus

Once the investigator has the tctx (or any other key the operator has wired to it), the operator’s dispute system queries the EEI corpus. Typical operator implementations index on tctx; the result is the signed sequence of evidence tokens captured during that transaction — usually several, sometimes many in long flows. The corpus is held by the operator under the operator’s retention policy. EEI does not maintain a separate dispute database.

3. Replay and re-verify

The retrieved tokens go through the 8-step verifier pipeline (see verification-pseudocode) once more, offline against the historical key state. The replay produces:

• Chain integrity — was the recorded sequence intact at the moment it was submitted, and is it still intact now.
• Signature validity — does each record verify under the public key registered for that device at the time of submission.
• Verdict trace — re-running the operator’s policy of-record against the signal stream produces the verdict the operator should have computed at the moment of decision. If it diverges from the verdict the operator’s live system actually produced, that divergence is itself a finding.

A re-verification is what makes the evidence replayable in the dispute sense. The operator is not asked to trust their own historical log — the cryptography re-checks against immutable inputs.

4. Three audience-scoped presentations

The same signed corpus serves three audiences. Each gets a different rendering; the underlying record is identical.

• Investigator. Full signal stream, chain status, verdict trace, the operator’s historical policy snapshot. Sufficient to resolve the case under the scheme’s reason-code rules.
• Cardholder. Redacted summary — device class, time, integrity outcome. No signal-class detail, no internal policy fields, no precise location beyond the dispute-relevant grain. Per POPIA [3] Condition 2 (Processing Limitation, §§9–12) and analogous instruments in the operator’s jurisdiction, the cardholder is shown what they have a legitimate basis to see and no more.
• Regulator (on escalation). A signed bundle: the token sequence, the verifier (or pointer to a reference verifier), the operator’s policy snapshot in effect at the time of decision. The regulator runs the verifier inside their own perimeter — no operator-side service is invoked at audit time.

5. What the cardholder is shown

A common operational question. The minimum useful set:

• The transaction reference and timestamp.
• The device class as registered (model, OS major version) — never the device’s stable identifier in the clear.
• A binary integrity outcome: device-side execution evidence consistent with normal operation / anomalies recorded — case escalated for review.
• A point of contact for further dispute and a reference number tying the cardholder’s view back to the investigator’s view.

The cardholder is not shown signal classes by name. Categorical signal information lives one tier in (investigator-only). This is a deliberate boundary between what is useful for the cardholder and what is operationally sensitive.

6. What dispute does not do

The dispute workflow does not re-decide the case. The case-resolution rules belong to the scheme; the operator’s dispute analyst applies them. Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — provides one input, a signed device-side observation, to a process the operator and scheme jointly run. It does not replace the chargeback procedure or substitute for its rules.

7. Cross-references

• Sibling articles: evidence-token-format, regulator-readable-format
• Architecture: /architecture/evidence-token, /architecture/sovereign-verification
• Theme 5: host-side-correlation
• Buyer flow: /applications/integrity

8. External references

[1] Mastercard. Chargeback Guide and Mastercom case management. mastercard.us/en-us/business/overview/support/rules.html. Cited 2026-04-28.

[2] Visa. Dispute Resolution Rules / Visa Resolve Online (VROL). usa.visa.com/support/consumer/visa-rules.html. Cited 2026-04-28.

[3] Republic of South Africa. Protection of Personal Information Act (POPIA). popia.co.za. Cited 2026-04-28.

[4] ISO. ISO 20022 — Universal financial industry message scheme. iso20022.org. Cited 2026-04-28.