Mastercard First-Party Trust: The 2026 Liability Shift Most Merchants Are Missing
Visa CE 3.0 and VAMP got the spring headlines. Mastercard quietly built the same liability flip on its side of the network. Here is what to know and how to qualify.
Mastercard’s First-Party Trust program shifts liability on first-party (friendly) fraud chargebacks when a merchant submits enhanced transaction data. The required fields, IP, device, geolocation, account history, the rendered order, and delivery confirmation, are almost identical to what Visa’s Compelling Evidence 3.0 asks for. One captured evidence record per checkout, paired with your carrier-side delivery feed, can qualify a merchant for both, on both halves of the network.
Picture this: a customer places a Mastercard order on your site in March. The product ships, tracking confirms delivery, the email receipt opens twice. Six weeks later, the cardholder calls their bank and says, “I never authorized this charge.” Your acquirer sends you a Mastercard reason code 4837 chargeback. You have the tracking number. You think you have the win. You lose anyway, because the issuer never had a reason to weigh anything against the cardholder’s claim. The reason code is “no authorization,” not “no delivery.”
That gap, between what you can prove and what the network actually weighs, is the entire point of Mastercard’s First-Party Trust program.
The Mastercard program nobody told you about
If you spent April reading about Visa lowering the VAMP threshold to 1.5%, you were paying attention to half of the card market. Mastercard ran a parallel play at almost the same time, and the merchant press barely covered it.
First-Party Trust (FPT) is Mastercard’s response to the same problem Visa is attacking with Compelling Evidence 3.0. First-party fraud is the fastest-growing dispute category in 2026. Cardholders dispute legitimate transactions, retain the goods or service, and the merchant loses the funds and the inventory. The 2026 Merchant Risk Council Global eCommerce Payments and Fraud Report puts first-party misuse at 36% of all global fraud cases, with 64% of merchants reporting a meaningful year-over-year increase.
FPT addresses the imbalance by giving merchants who submit enhanced data a structural advantage: their evidence gets scored against the cardholder’s claim before the chargeback is finalized. Done right, the dispute closes in the merchant’s favor without representment, and the liability shifts to the issuer.
Program
First-Party Trust (FPT)
Mastercard’s first-party fraud liability shift, the parallel to Visa CE 3.0.
Primary trigger
Reason code 4837 and related first-party fraud claims
“No authorization given” disputes are the largest covered category.
Mechanism
Enhanced data submitted at auth or in dispute response
Mastercard scores the data against the cardholder’s claim before chargeback finalization.
Coverage
US live, APAC and EU rolling 2025–2026
Availability depends on your acquirer’s activation in your region.
Why has FPT flown under the radar? Two reasons. Visa’s announcement was paired with a hard threshold drop (VAMP from 2.2% to 1.5% on April 1, 2026), which forced merchants to act. FPT did not come with a stick. It came with a quiet carrot, which is harder to sell to a finance team. The second reason: Mastercard’s data ask sits inside the developer and rules documentation, not in the press release. The headline says “first-party fraud protection.” The substance is six bullet points in a rules PDF.
What “enhanced data” actually means
This is where most articles wave their hands. Mastercard’s published guidance and B2B blog framing of FPT center on six categories of transaction enrichment. Each maps to data that already exists in the checkout, if you are capturing it.
None of these are exotic. They are the spine of any session-level evidence record. The work is not collecting them. The work is packaging them into a single, time-stamped, tamper-evident record that the acquirer can submit at the moment a dispute is screened.
One captured record, two networks covered
The strongest commercial argument for First-Party Trust is not what it does on its own. It is what one captured evidence record can do across both networks at once. Visa CE 3.0 emphasizes prior good transactions and device intelligence. Mastercard FPT places more weight on account history, geolocation, and rendered-order verification. The fields overlap by roughly four-fifths.
Compelling Evidence 3.0
Reason code 10.4 (first-party fraud)
- Two prior, undisputed transactions with the same cardholder, IP, device, or shipping address
- Rendered order page evidence
- Device intelligence: IP, user agent, fingerprint
- Delivery confirmation for physical goods
- Account-to-cardholder linkage
First-Party Trust Program
Reason code 4837 (no cardholder authorization)
- IP address at authorization
- Device characteristics and fingerprint
- Geolocation at purchase
- Account or login history with the merchant
- Rendered order including items and shipping address
- Delivery confirmation
A session-level capture at checkout produces IP, device, geolocation, the rendered order, the consent click, and the linkable account context. Pair it with delivery confirmation from your carrier feed and you have the inputs both programs score on. The reason codes differ. The reason code arguments differ. The underlying evidence does not.
This is the practical case for thinking about evidence as infrastructure rather than as a dispute-response file. If the capture happens once, at the moment that matters, both networks can score it later. If the capture has to be reconstructed from logs and order tables when a dispute lands, neither program gives you the lift you were counting on.
How the liability shift triggers in practice
The mechanics matter, because “submit enhanced data” sounds passive. It is not. The shift triggers at a specific moment in a specific flow.
Liability shift flow
Authorization
Merchant captures IP, device, geolocation, rendered order, consent click.
Enhanced data submitted
Acquirer attaches enhanced data to the auth message or holds it for dispute screening.
Dispute filed
Cardholder claims no authorization. Issuer triggers reason code 4837.
FPT screen
Mastercard scores enhanced data against cardholder claim.
Liability shifts
Dispute closes pre-representment. Liability moves to the issuer.
Two things to notice. First, the merchant’s work happens before the dispute, not after. By the time reason code 4837 lands in your dispute queue, the data either exists or it does not. There is no “let me go find that screenshot” recovery move. Second, the liability shift happens at stage 5, but it is determined by what got captured at stage 1. The acquirer is just the messenger.
This is the same lesson we wrote about for 3D Secure. Authentication is one signal at one moment. The defensible record is everything the cardholder did and saw during the transaction, captured once and retained.
A four-step checklist to qualify
If you are reading this with your dispute team in mind, here is the operational path.
Confirm activation with your acquirer
FPT availability depends on your acquirer’s region and integration status. Ask your acquirer or processor whether FPT is live for your MID and what their enhanced-data submission path is (real-time auth flag, post-dispute file, or both).
Audit what you are already capturing
Walk the six FPT fields (IP, device, geolocation, account history, rendered order, delivery confirmation) against your current data stack. Most checkouts have four of six already. The two that usually go missing are the rendered order as the customer saw it and the consent acknowledgment with a tamper-evident timestamp.
Close the rendered-order and consent gap
Capture the page the way the consumer saw it, with items, totals, shipping address, and terms acknowledged, at the moment of authorization. This is the field most dispute responses fail on, because order-table records reconstruct what was billed, not what was shown.
Test the cross-network play
Map your captured data set to both Visa CE 3.0 and Mastercard FPT requirements side by side. One evidence record from checkout, paired with your existing carrier delivery feed, should cover both. If a checkout-side field qualifies for one network and not the other, fix the capture, not the response template.
Most merchants who built a CE 3.0 evidence packet in April assumed the Mastercard side of their dispute volume was a separate project. It is not. Mastercard’s FPT data ask overlaps Visa’s CE 3.0 ask by roughly four-fifths. The teams that win on both networks treat enhanced data as a single capture problem at the checkout layer, not two compliance projects at the dispute-response layer. The smart play is to capture the evidence once, before the dispute lands, not to rebuild it on demand for each network’s reason code.
Frequently asked questions
What is Mastercard First-Party Trust?
Mastercard First-Party Trust (FPT) is a program that shifts liability on first-party (friendly) fraud chargebacks when a merchant submits enhanced transaction data, either at authorization or in the dispute response. It is the Mastercard analog to Visa Compelling Evidence 3.0 and covers Mastercard reason code 4837 and related first-party fraud claims.
How is FPT different from Visa CE 3.0?
Both programs reward merchants for submitting richer evidence on first-party fraud disputes, but they live on different networks, use different reason codes, and define enhanced data slightly differently. Visa CE 3.0 emphasizes prior good transactions and device intelligence. Mastercard FPT places more weight on account history, geolocation, and shipping confirmation. A single checkout-side evidence record can cover both because the underlying fields overlap heavily.
Do I need a new tool to qualify for FPT?
Not necessarily. You need the enhanced data fields available at the time of dispute response. If your checkout already captures session-level evidence (IP, device, geolocation, the rendered order page, the customer’s affirmative click on terms, and a post-purchase confirmation), you have most of the inputs. The work is packaging that data into the dispute response in the format Mastercard’s program expects.
Does FPT apply to all Mastercard chargebacks?
No. FPT is targeted at first-party (friendly) fraud claims, primarily reason code 4837 and related conditions where the cardholder claims they did not authorize a transaction. It does not apply to genuine third-party fraud, EMV liability-shift disputes, or product-and-service quality disputes (4853 and similar).
When does FPT take effect?
FPT launched in the United States and continues a multi-region rollout into APAC and EU markets through 2025 and 2026. Coverage in your acquiring region depends on which Mastercard markets have activated the program with your acquirer. Confirm activation status with your acquirer or processor before relying on FPT as a primary dispute defense.
What evidence does Mastercard FPT actually want?
Mastercard’s enhanced-data ask centers on six fields: IP address at authorization, device characteristics and fingerprint, geolocation at purchase, account or login history with the merchant, the rendered order including items and shipping address, and delivery confirmation. The merchant’s affirmative-consent acknowledgment of terms and the post-purchase email receipt round out a defensible record.
Turn every checkout into an FPT-ready record
Evidora captures court-ready evidence of every checkout interaction. One line of code. Retain what matters, expire what does not, produce a reproduction the moment a Mastercard 4837 or Visa 10.4 inquiry arrives.
See how it works →