Compelling Evidence 3.0: The Data You Must Capture Before the Dispute

Compelling Evidence 3.0 works only when a merchant or acquirer already captured and retained the exact data elements Visa’s own rulebook requires, in the exact format it requires, before the disputed transaction happened. There is no version of this defense that gets assembled after the fact.

Visa Core Rules Section 11.7.5.3, Dispute Condition 10.4: Other Fraud, Card-Absent Environment, lists CE3.0 as one of the ways a dispute is invalid rather than a reason code an acquirer argues around after the fact. The rule states a dispute does not qualify under Condition 10.4 if the same payment credential completed two earlier, undisputed transactions more than 120 calendar days before the disputed one, not exceeding 365 calendar days, and specific identifying data matches between those transactions and the disputed one. That is the entire mechanism. It is not persuasion. It is a data match against a rule.

The data elements, in the exact format Visa requires

The rule does not accept a general sense that “this looks like the same customer.” It names specific fields and specifies their format, and a submission that does not meet the format does not count as a match.

A qualifying submission needs a detailed description of the merchandise or services purchased, for both the disputed transaction and the two prior ones, or for certain tokenized ecommerce transactions, a purchase order number captured through Visa Secure or Visa Token Service instead. Alongside that, at least one of the following has to match between the prior transactions and the disputed one:

• Customer account or login ID: a unique identifier the cardholder used to authenticate on the merchant’s site or app, in clear text, not hashed, and something the cardholder would recognize if shown it.
• Full delivery address: street address, city, state or province, postal code, and country, in clear text, not hashed.
• Device ID: a unique identifier the cardholder can verify, such as an IMEI, at least 15 characters, in clear text, not hashed.
• Device fingerprint: derived from at least two software or hardware properties of the device, at least 20 characters, and this one may be hashed.
• IP address: the cardholder’s public IP address, in clear text, not hashed, in valid IPv4 or IPv6 format.

The clear-text requirement on four of the five elements is not a drafting accident. Visa built this rule to be verified mechanically on the issuer’s side, which means a merchant or acquirer who hashes a login ID or delivery address for internal privacy reasons, without separately retaining a clear-text version for exactly this purpose, has made that data unusable for a CE3.0 submission the day it is needed.

What changes on October 24, 2026

Visa’s own summary of rule changes describes this update plainly: “To further reduce friendly fraud from the ecosystem, Visa is expanding the availability and application of the remedy rule (commonly known as Compelling Evidence 3.0 [CE3.0]) for Dispute Condition 10.4… In addition, the CE3.0 framework will support multi-merchant transactions as evidence to qualify for liability protection.” The rule change touches Section 11.7.5.3 and Section 11.7.5.6 directly.

Three concrete changes land with that effective date, based on the current and forthcoming text of Table 11-28:

The matching transactions no longer have to be at the same merchant. Through October 23, 2026, the two prior undisputed transactions establishing a pattern have to be at the merchant now facing the dispute. From October 24, 2026, the rule reads “used at one or more Merchants in 2 previous Transactions,” which means a payment facilitator or platform that can see a cardholder’s history across its entire merchant base, not just one storefront, gets a materially wider pool of qualifying prior transactions to draw from.

Login IDs now explicitly extend to agentic payment activity. The updated rule adds that the login ID element “also includes login IDs for an Agentic Payment Provider,” which is Visa’s own rulebook acknowledging that a growing share of card-absent purchases are now initiated by an AI agent acting on a cardholder’s behalf rather than the cardholder typing into a checkout form directly.

Device ID and device fingerprint stop being independently stackable. A new footnote states plainly that “device ID and device fingerprint are considered similar data elements” and that an acquirer “is not permitted to supply both in support of a submission and must select another data element instead.” A submission built on the assumption that having both strengthens the case is building on a premise the rule is about to remove.

None of these three changes helps a merchant who was not already capturing the underlying fields. Widening the pool of eligible prior transactions, or adding a new category of login ID, only matters if the login ID, device fingerprint, and IP address were logged against those transactions when they happened.

The retention window is longer than most capture pipelines plan for

Table 11-28’s own footnotes set the real planning horizon: the two prior undisputed transactions have to be more than 120 calendar days before the disputed transaction, but not more than 365 calendar days before the dispute’s processing date. Read end to end, that means a transaction happening today can still need to be matched against disputes filed close to a year from now.

A merchant or platform that retains device fingerprints or login session data for 90 days because that was the retention window someone picked for a fraud-scoring vendor, with no one revisiting it against this specific rule, has already lost the ability to use CE3.0 on a meaningful share of the disputes it will actually face. The gap does not show up until the dispute arrives and the data needed to fight it was already purged on schedule.

Capturing this data creates a second obligation, not a free byproduct

Device IDs, IP addresses, login IDs, and delivery addresses, held in clear text specifically so they can be matched against a future dispute, are not a free operational byproduct. For a business that meets the FTC Safeguards Rule’s definition of a financial institution, this is exactly the category of information the rule calls customer information: “any record containing nonpublic personal information about a customer of a financial institution… that is handled or maintained by or on behalf of you or your affiliates.” The Safeguards Rule’s own guidance is explicit that the definition of financial institution is broader than how most businesses use that phrase, turning on what activities a company performs rather than how it labels itself, and that payment-adjacent activities are squarely within scope.

A covered business has to maintain a written information security program covering, among other required elements, encryption of customer information at rest and in transit, periodic access-control reviews limiting who can see this data, and a schedule for securely disposing of customer information no later than two years after the last legitimate use, unless a legal requirement extends that window. CE3.0’s own retention need, up to roughly 365 days plus the 120-day minimum spacing, sits comfortably inside that two-year ceiling, which means building a CE3.0-ready retention schedule and a Safeguards Rule-compliant disposal schedule is one decision, not two competing ones, as long as someone designs them together rather than independently.

The clear-text requirement on most CE3.0 fields is where this gets genuinely uncomfortable next to a security program’s instinct to hash or encrypt everything by default. The fix is not choosing one requirement over the other. It is storing the field in a form that meets CE3.0’s clear-text match requirement for dispute purposes while encrypting the data store itself and tightly controlling who and what can query it, which is exactly what the Safeguards Rule’s access-control and encryption-at-rest requirements call for in the first place.

What to actually build before the next dispute, not after

Confirm the checkout, login, and delivery flows actually capture all five eligible data elements today, not just the ones a fraud vendor happened to default to. A platform relying entirely on a third-party fraud score without separately retaining the raw device fingerprint and IP address in a form it controls has outsourced the one thing CE3.0 requires it to produce directly.

Set the retention window for this specific data against CE3.0’s own math, 365 days from the transaction to cover the full possible dispute timeline, not against whatever shorter default a fraud or analytics tool shipped with. Confirm the retained fields meet the format Visa specifies: clear text and unhashed for login ID, delivery address, device ID, and IP address, with device fingerprint as the one field the rule allows to be hashed.

If the business processes transactions across more than one merchant or sub-merchant, as a payment facilitator or marketplace does, build the capability to query prior transactions across the whole portfolio once the October 24 change takes effect, not just within a single merchant’s own history. That expanded pool is the single largest practical upgrade in this rule change, and a system still filtering lookups to one merchant ID will not use it.

Confirm with the business’s own counsel or compliance function whether its specific activities meet the Safeguards Rule’s definition of a financial institution, since the answer turns on what the business actually does, not what it calls itself, and the data CE3.0 asks for is exactly the kind of record the rule was built to protect once that threshold is met.

Finally, stop treating device ID and device fingerprint as a belt-and-suspenders pair in a dispute submission once the October 24 change takes effect. Pick the one with the stronger match for a given transaction and submit that, since the rule will no longer credit both.

This is a narrower, more mechanical problem than most chargeback strategy, which is exactly why it gets missed. The question is never whether the rebuttal argument is persuasive. A dispute management function run well treats CE3.0 as a data-engineering requirement that has to be satisfied months before a dispute exists, not a drafting exercise once one lands. The same discipline that keeps fraud and chargeback prevention proactive rather than reactive applies here: the data has to already be sitting in the right format when the dispute notification arrives. For a platform managing this across a large or growing merchant base, that capture and retention design is core merchant management work, not a one-time fraud-team project.

Frequently Asked Questions

What is Compelling Evidence 3.0 in Visa’s dispute rules?

CE3.0 is the common name for the remedy rule under Visa Core Rules Section 11.7.5.3, Dispute Condition 10.4: Other Fraud, Card-Absent Environment. It lets an acquirer defeat a card-absent fraud dispute by showing the same payment credential completed earlier undisputed transactions and that specific data points, such as device ID, device fingerprint, IP address, login ID, or delivery address, match between the disputed and prior transactions.

What changes with Compelling Evidence 3.0 on October 24, 2026?

Visa is expanding CE3.0’s matching transactions from same-merchant only to multi-merchant: the two prior undisputed transactions can now have occurred at a different merchant than the disputed one. The update also adds login IDs for Agentic Payment Providers as an eligible data point and clarifies that device ID and device fingerprint count as similar elements, so an acquirer can submit only one, not both.

Does capturing device and IP data for chargeback defense trigger other compliance obligations?

It can. The FTC Safeguards Rule, which implements the Gramm-Leach-Bliley Act, requires covered financial institutions to maintain a written information security program protecting customer information, including access controls, encryption, and a secure disposal schedule. A business capturing device IDs, IP addresses, and login IDs specifically to support CE3.0 submissions is generating exactly the kind of customer information the rule covers, and should check whether its own activities bring it under the rule’s definition of a financial institution before treating this data as a side effect of running the business rather than a protected category of its own.

Sources: Visa Core Rules and Visa Product and Service Rules, Section 11.7.5.3 and Table 11-28, and the FTC Safeguards Rule: What Your Business Needs to Know.