Visa Compelling Evidence 3.0: What Changes on October 24, 2026

Visa's 10.4, Other Fraud – Card-Absent Environment dispute condition was around long before the remedy that now decides so many of these cases. Visa compelling evidence 3.0 (CE3.0) took effect on April 15, 2023, and it did one thing: it made a 10.4 dispute invalid - not just contestable - when the merchant could show two prior undisputed transactions on the same card. On October 24, 2026, four days from today, the pool of prior transactions widens. They no longer have to come from your own store.

That's the headline everyone's repeating. The footnote underneath it decides whether the change is worth a thing to you - and it sits in the same rulebook, three tables later.

Key takeaways

• Four days out. Disputes processed on or after October 24, 2026 run the revised text at §11.7.5.3 and §11.7.5.6 of the Visa Core Rules and Visa Product and Service Rules, April 18, 2026 edition. Anything processed through October 23 runs the old wording.
• Prior transactions may now come from one or more merchants, as long as the same card - or a payment credential associated with it, like a token - was used.
• The evidence bar hasn't moved. Two priors, 120–365 days before the dispute date, two matching core data elements with one of them IP address or device ID/fingerprint, and no active fraud report or dispute on the priors. CE3.0 still applies to 10.4 and nothing else.
• One footnote caps the expansion: an acquirer may submit only transaction data it accepted and processed. Other merchants' purchases count in pre-arbitration only if those merchants sit on your acquirer.
• A CE3.0-qualified TC40 comes out of your VAMP ratio, subject to when Visa pulls the extract. Timing, not effort, decides.

What actually changes on October 24, 2026

The change lands in two places in the rulebook: the invalid-disputes rule for 10.4, and the pre-arbitration processing requirements for the same condition. Three things move.

Prior transactions can come from more than one merchant. Here's the shape of it. A cardholder buys from you in July and disputes that charge in October. Under the text in force through October 23, your defense needs two older, undisputed purchases made at your store. From October 24, the prior purchases can sit anywhere the same card - or a token tied to that card - was used: a March purchase at one merchant, a May purchase at another. Your disputed charge gets defended with the cardholder's earlier, undisputed buying history elsewhere. Note the direction, because it gets flipped constantly: your transaction is the one under attack, and the priors are the evidence. They just don't have to be yours anymore.

The purchase order number route widens - and that is all it does. A purchase order number is not a matching data element and never was. In the rules it stands in for the detailed description of the merchandise or services in the evidence packet. Through October 23, that swap is limited to e-commerce transactions processed with Visa Secure under ECI 7 and a valid CAVV. From October 24, 2026, a valid TAVV from Visa Token Service or a valid Match Key from Visa Intelligent Data Exchange also qualifies the transaction for the swap. Read that precisely: the CAVV, the TAVV or the Match Key is what lets a PO number stand in for the description. None of the three replaces a PO number, and none of them is one of your two core matching elements. If your packet is short a PO number, a TAVV doesn't fill the hole.

User ID gains agentic checkout. The customer account or login ID element now explicitly covers log-in IDs issued by an Agentic Payment Provider alongside your own site or app. If an AI agent completes the purchase, the login that authenticated the session is still a nameable element.

Now the footnote. Table 11-31, footnote 5 of the same edition, carrying the same October 24 stamp, states that an acquirer must only submit transaction data accepted and processed by that acquirer. Pre-arbitration is where a 10.4 actually gets decided, and it's filed by your acquirer, not by you. So the theoretical pool is only ever as wide as your acquirer's own book. A prior purchase at a merchant on a different acquirer cannot be submitted, however cleanly the identifiers would have matched.

Which makes this a question about your acquirer's plumbing rather than about your paperwork. Put two questions in writing this week: Will you search across merchants on your own book for qualifying priors on disputes processed from October 24? And what share of my 10.4s did you take to pre-arbitration last quarter? If the answers are vague, plan as though nothing changed.

The CE3.0 evidence bar, in plain terms

Strip the terminology and CE3.0 is a matching exercise. You're proving the person who disputed is the person who bought - and that they had a track record of buying.

Visa's CE3.0 acquirer readiness deck sets out four conditions. All four must hold:

1. At least two prior transactions with the same cardholder, each at least 120 days old and no older than 365 days, calculated from the dispute date.
2. At least two of the core data elements match between the disputed transaction and each prior one.
3. One of those two matches must be either the IP address or the device ID/fingerprint. Two soft matches - user ID plus shipping address - don't clear the bar.
4. No active fraud report and no active fraud dispute on the prior transactions.

Two practical consequences follow, and merchants hate both. The 120-day floor means your newest customers have no defense at all; a first-month chargeback is a straight loss. The 365-day ceiling means your archive has a shelf life. Data you didn't capture 14 months ago cannot be manufactured now - and the rule change doesn't touch either number.

The four core data elements

Core data element	What it is	What it means for you
User ID / account log-in ID	The customer's identifier in your system - account number, username, email-linked log-in	Easy to match across two purchases, but it can't be one of your two "anchor" matches
IP address	The IP address recorded at the time of authorization	One of the two anchor elements. Capture the full address at every authorization, not just signup
Shipping address	The address tied to the transaction	For digital goods and subscriptions this often doesn't exist - which is exactly why CNP merchants lean on the next row
Device ID / fingerprint	A stable device identifier or a fingerprint built from several attributes	The other anchor element. Visa treats device ID and fingerprint as one element even when you hold both

The Visa rules require device IDs of at least 15 characters and fingerprints of at least 20 characters derived from at least two properties. Treat those as design targets for your capture layer, and check your last authorization payload against them before you rebuild anything.

The data to capture now, field by field

The October change rewards merchants whose records already hold the identifiers. Four days won't build that. What follows is the order of work and the fields that matter, so you can see exactly where your gap is.

Capture checklist

Field	Capture it at	Why it matters for a 10.4 dispute	Minimum standard
Full IP address	Every authorization request	Anchor match #1; without it you need device data on both prior transactions	Full IPv4/IPv6, never truncated, with UTC timestamp
Device ID or fingerprint	Checkout and account log-in	Anchor match #2, and the fallback when a customer's IP shifts between mobile networks	Persistent, stable across sessions; fingerprint built from multiple attributes
Account / user ID	Account creation, then every auth	Second matching element; carries the "same person" argument	Stored on the transaction record, not only in the CRM
Card token, CAVV / TAVV, or IDX Match Key	Authorization response	Survives card reissue and ties a re-enrolled card to the original. From October 24, 2026, the CAVV, TAVV or Match Key on an ECI 7 transaction is what qualifies it for the purchase-order-number swap	Persisted with the transaction, not just the order
Billing and shipping address	Authorization (AVS)	Match element where it exists; strongest for coaching and physical-goods hybrids	Street-level, not just ZIP
Amount, currency, ARN, UTC timestamp	Settlement file	You cannot assemble a pair without a defensible transaction trail	Same record shape across all gateways
Delivery or entitlement log	Your product system	Proves the cardholder received value; supports the narrative, not a core element	Timestamped access, download or lesson completion
Terms and consent acceptance	Signup, with IP + timestamp	Backs the "they knew it was recurring" argument in pre-arbitration	Versioned terms, capture date, capture IP
Cancellation and refund history	CRM / billing platform	Kills the "I never signed up" story when it shows the cardholder used the account	Any refund issued, any cancellation attempt, with dates
Prior-transaction clean status	Ask your processor	Condition 4: the pair you submit must have no active TC40 or dispute	Request a TC40 check before you file

Retention window

CE3.0 needs a prior transaction up to 365 days old measured from the dispute date, and a dispute can land months after the sale - the issuer has 120 calendar days from the transaction processing date to raise a 10.4. Add the two and 13 months is the floor for keeping full transaction records: IP, device value, user ID, card token, AVS result, ARN. Keep the cardholder-identifying fields for as long as you keep the customer relationship.

Storage is cheap; a lost reverse-engineering project after a dispute wave is not. If your gateway rotates logs on a 90-day cycle, that's the first thing to fix, and nothing else on this page will help until you do.

How a won 10.4 dispute keeps your VAMP ratio down

Visa's Acquirer Monitoring Program fact sheet defines the ratio simply: fraud TC40s plus disputes TC15, divided by settled transactions TC05. An acquirer portfolio goes Above Standard at 50 bps and Excessive at 70 bps; merchant-level thresholds differ by region and product, and the current numbers live in that fact sheet.

The line that matters to you sits in the exclusions: Visa excludes TC40 fraud qualified for Compelling Evidence 3.0, contingent on the timing of the data extract. Every 10.4 you win with CE3.0 is a TC40 that can stop counting against you - and a TC40 you never get to write off is what eventually drags you into a monitoring conversation with your acquirer.

The extract-timing catch

"Contingent on the timing of the data extract" is doing heavy lifting. Visa samples on a cycle. A dispute that resolves after the extract doesn't help that period's number, however clean your evidence. Same story for disputes resolved through pre-dispute solutions - excluded, again contingent on extract timing.

The working rule: the VAMP benefit accrues to merchants who file early and get a decision inside the cycle. Pre-arbitration gives the acquirer 30 days from the dispute processing date, and the issuer 30 more to respond. Miss the window and the TC40 stands.

Also worth knowing before you assemble anything creative: CE3.0 gives you one attempt at the pre-arbitration questionnaire. There's no second submission if you fumble the pair.

Order Insight and CE3.0 aren't the same thing

Visa Order Insight CE3.0 gets used as one phrase in a lot of merchant threads; they're two products doing different jobs. Order Insight is the pre-dispute route - you share order details so the issuer can see the transaction in context before a dispute is even raised. CE3.0 is post-dispute evidence. Order Insight is cheaper when it works, because a dispute that never happens costs you nothing. CE3.0 is the fallback when the customer calls their bank anyway. Run both, and don't assume one covers for the other.

Vertical notes: where 10.4 disputes actually come from

Subscriptions and continuity. You have a structural advantage: rebills are natural prior transactions. The trap is picking a pair that includes a disputed or refunded charge - condition 4 kills it. Log IP and device on every renewal authorization, not just signup, or your anchor matches thin out after the first month.

Dating. Mobile IPs move constantly, so treat device fingerprint as your primary anchor and accept that IP will often mismatch on cellular. Where a customer verifies a new device after a legit upgrade, log the change event; a matching fingerprint with a documented device add reads very differently from a bare mismatch.

Adult. Volume and dispute rates here make clean prior pairs harder to find, and anonymous checkout limits what user ID you can hold. Two moves: keep entitlement and viewing-session logs with timestamps and IP, and make sure your privacy notice and consent capture actually cover storing device data - defensible evidence gathered sloppily is a liability, not an asset.

Digital goods. The core elements are thin unless you instrument them. Capture delivery timestamps, download or activation events and the email domain used at purchase, and pair that with the IP and device capture at checkout. An activation tied to a fingerprint is often the difference between a matched pair and a generic "customer used it" claim.

Coaching and education. Higher tickets, longer cycles, and a decent share of disputes that are really buyer's remorse dressed as fraud. Your strongest pair is usually signup plus a later module login, both with the same user ID and device. Add intake forms, cohort records and LMS attendance to the narrative - none of it counts as a core element, all of it helps the pre-arbitration reviewer understand the relationship.

Your 30-day action plan

Four days is not enough time to rebuild a capture layer. It's more than enough time to find out whether one exists.

This week: four days, four moves

1. Today - pull your last 10.4 and read the packet. Did it contain two priors at all? If your processor filed none, that's the finding, and it's worth more than any policy document you could write before Saturday.
2. Tomorrow - check one authorization payload against the checklist above. Most merchants discover the gateway holds the IP and device value and the CRM never receives them. If that's you, you have a one-field fix, not a platform migration.
3. By October 22 - send the two questions in writing about your acquirer searching its own book across merchants, and about its 10.4 pre-arbitration volume. You want the answer on record before the rule takes effect, not after your first post-change dispute.
4. Before October 24 - confirm your ECI 7 transactions actually return a CAVV, TAVV or Match Key. The purchase order number route runs on those values, and they're generated on the network side; if nobody has looked, nobody knows.

The 30 days after

Days 1–7: fix capture at authorization. Get IP, device ID/fingerprint, user ID and the card token persisted to the transaction record itself. Push from the gateway postback, not from a client-side event that fails on iOS. Then retrieve one record from 14 months back to prove the archive goes deep enough.

Days 8–14: run a dry run. Pick a real settled transaction older than 120 days, build the packet your acquirer would need, and send it to your processor's risk contact with one question: Would this pass your CE3.0 review? You'll learn more in an hour than from a month of reading rules.

Days 15–21: lock the operational side. Confirm who files pre-arbitration, how fast they're notified, how you'll be asked for evidence, and what your 30-day clock looks like in practice. Put a named owner on it. If your contract blocks you from seeing dispute notices fast enough to file, that's a renegotiation point - the same conversation you'd have about rolling reserves explained for high-risk merchants, since dispute volume drives both your reserve and your leverage.

Days 22–30: close the loop with numbers. Score every 10.4 from the changeover by outcome and by filing date, so you can see whether your packets qualify and whether they land before the extract. That scoreboard is what tells you, inside a quarter, whether your acquirer's answer in step 3 was true.

CE3.0 applies only to 10.4. A goods-not-received or not-as-described dispute gets nothing from it, and no amount of IP matching changes that - those need delivery evidence and a different argument entirely.

Where Find a Processor fits

The October change is decided on your acquirer's side of a wall you can't see over. Two processors can quote near-identical rates and handle a 10.4 completely differently: one has a risk team that searches its own book, files pre-arbitration inside the window and knows what a device fingerprint pair looks like; the other routes everything to a queue and lets the clock run.

That's the gap we work in. One conversation with Find a Processor puts your business in front of a portfolio of processors that actively want what you sell - card-not-present merchants in dating, adult, digital goods, coaching, travel, telemedicine, crypto-adjacent and other high-risk verticals - selected on dispute operations rather than on a "we support high risk" badge on a homepage. We sit in on the application, the pricing, the reserve and the contract terms, and we put the CE3.0 questions to each processor before you sign: does the risk team search its own book for priors, who writes the pre-arbitration response, how fast does a 10.4 reach me, and what happens to my reserve when dispute volume spikes.

Before you sign anything, read how to compare high-risk processor offers - those questions apply directly to CE3.0 handling. If you're mid-crisis rather than mid-search, start with what to do when your processor froze your account. If a decline or shutdown brought you here, the playbook for a merchant account after a decline or shutdown covers rebuild sequencing, and the MATCH list guide covers the worst case.

FAQ

Does the October 24, 2026 change mean I can win a 10.4 with other merchants' data instead of my own? From October 24, 2026 the rules let qualifying priors come from one or more merchants, provided the same card or an associated payment credential was used. But in pre-arbitration your acquirer may submit only transaction data it accepted and processed. So other merchants' purchases count there only if those merchants are on the same acquirer. Since pre-arbitration is where a CE3.0 dispute is actually decided, plan on your own records and treat cross-merchant history as an upside your acquirer may or may not be able to reach.

What exactly counts as a prior transaction? A settled transaction on the same card - or a token tied to it - dated at least 120 days and no more than 365 days before the dispute processing date, with at least two core data elements matching the disputed charge, one of them IP or device, and no active fraud report or dispute on it.

Why must one match be the IP address or the device ID/fingerprint? Because those are the elements that tie a transaction to a device and a connection rather than to a typed-in detail. Visa's CE3.0 deck is explicit: two of the four elements must match, and one of those two has to be IP or device.

What does "no active fraud report or dispute" mean for my prior transactions? The two priors you submit must be clean - no open TC40 fraud report and no open fraud dispute on them. If either prior has one, pick a different pair. Get a TC40 check before filing, because you often can't see this downstream.

Does winning a 10.4 dispute really remove the TC40 from my VAMP ratio? Per Visa's VAMP fact sheet, TC40 fraud qualified for Compelling Evidence 3.0 is excluded from the ratio, contingent on the timing of the data extract. Qualified is the operative word - the packet has to clear Visa's bar, and the exclusion only lands with an extract that falls after the decision.

Is the removal automatic? The exclusion is a function of qualification and extract timing, not something you can force. Track your disputes by reason code and month so you can see whether resolutions are landing ahead of the cycle or behind it.

How long do I have to file? Visa's CE3.0 material gives the acquirer 30 days from the dispute processing date to submit the pre-arbitration response, and the issuer 30 days to answer. You also get exactly one attempt at the questionnaire, so vet the pair before anyone clicks submit.

Does the October change move the filing window for a 10.4? No. An issuer still has 120 calendar days from the transaction processing date to raise the dispute. The 120-day figure inside CE3.0 is the minimum age of a qualifying prior transaction - a different number measuring a different thing.

Does CE3.0 help with goods-not-received or not-as-described chargebacks? No. It's tied to the 10.4 card-absent fraud condition. Those other dispute categories need delivery evidence and a different argument entirely.

What if my acquirer says they don't do CE3.0 submissions? That's a fit problem, not a paperwork problem. Ask what share of 10.4 disputes they contest, who writes the response, and how fast notice reaches you. If the answers are thin, that's a reason to look at alternatives - a conversation that overlaps with comparing processor offers.

Do I still need Order Insight if I have CE3.0? Yes, if you can get it. A dispute that never opens costs you nothing, while a 10.4 you win still ate time and fees. A CE3.0-qualified TC40 is excluded from the ratio subject to extract timing, so the case for Order Insight is the cost and the customer relationship rather than the ratio. The two are complements.

Is this legal advice? No - it's operational guidance for merchants working through Visa's published rules. Get professional advice on your own contracts and merchant agreement.

Sources

• Visa Core Rules and Visa Product and Service Rules, April 18, 2026 edition - §11.7.5.3 invalid disputes for condition 10.4, §11.7.5.4 and Table 11-29 (120-day filing window), §11.7.5.6 and Table 11-31 footnote 5 (acquirer may submit only data it processed), Table 11-28 footnote 5 (365-day age ceiling), Summary of Changes p. 48 (October 24, 2026 effective date, multi-merchant prior transactions, purchase-order-number substitution for ECI 7 with CAVV/TAVV/Match Key, agentic log-in IDs).
• Visa Acquirer Monitoring Program (VAMP) fact sheet - ratio definition, CE3.0 TC40 exclusion, extract-timing condition, portfolio thresholds.
• Visa Compelling Evidence 3.0 acquirer readiness deck - April 15, 2023 effective date, 120–365 day window, four core data elements, anchor match requirement, clean prior transaction condition, 30-day and one-attempt rules.

Ready to check the other side of the table?

Send us your vertical, monthly card-not-present volume, average ticket and current dispute picture, and we'll come back with processors whose risk teams can actually use what you capture - plus the exact questions to put to each one before you sign. Talk to Find a Processor.