More Than Money Back: Reimagining Payment Disputes at Monzo

🧐 What Exactly Is a Payment Dispute?

A dispute is when a customer asks Monzo to refund a card payment. This usually happens when they don't recognise a transaction, received faulty goods, or were double-charged. It's often confused with fraud, where a payment is made by a criminal without the customer's knowledge, or the customer is unwittingly being manipulated by a fraudster. When we accept a dispute from our customers, we’ll look to recover the money on their behalf. This is a lengthy process, known as a chargeback.

Introduction

Over the past 18 months, our disputes team set out to transform a typically painful and bureaucratic process into one that customers can trust. We've cut dispute reports by around half, delivered multi-million-pound savings, and won a Mastercard award for our chargeback performance.

We got there with two core strategies. First, stopping false disputes using machine learning and smart product friction. Second, cutting preventable dispute volume by giving customers more trust, clarity, and autonomy when something goes wrong.

This post is about why we rebuilt the process, what tech we used, and how a small team pulled it off.

Disputes are already painful, so why make them bureaucratic?

For years, the payment dispute process across the industry has been a battle against bureaucracy: fixed claim categories, strict evidence rules, and a multi-stage back-and-forth between banks and merchants that can run for weeks or months, all while the customer waits with their money gone and no clear update. But for Monzo, this was more than a poor user journey. It was a problem of scale:

• Global scale: Chargeback volumes are forecast to hit 337 million transactions by 2026, a 42% increase in just three years!

Global scale: Chargeback volumes are forecast to hit 337 million transactions by 2026, a 42% increase in just three years!

• Monzo scale: In 2025, around one in ten customers raised a claim with us, representing tens of millions of pounds in disputed payments and multi-million-pound operating costs. This was high relative to the industry average.

Monzo scale: In 2025, around one in ten customers raised a claim with us, representing tens of millions of pounds in disputed payments and multi-million-pound operating costs. This was high relative to the industry average.

• Inefficiency: 80% of our handling time went on claims with less than a 40% chance of success.

Inefficiency: 80% of our handling time went on claims with less than a 40% chance of success.

This meant tens of millions of pounds worth of payment disputes, most of them low-value, tying up customer time on cases where we can't help. We saw a clear opportunity to apply Monzo’s magic: tackling problems with tech to elevate the customer experience.

We approached it in four steps: stop the false claims, automate the genuine ones, recover the fixable rejections, and then move upstream to the reporting journey itself.

Step 1: Stopping the false claims

Before we could create a smooth experience for genuine customers, we needed to isolate the noise. A significant portion of that noise was first party fraud (or 'friendly fraud'), where a customer knowingly disputes a legitimate charge in an attempt to get free goods or extra money. We needed to make our process less attractive to false reports while not putting up blockers for genuine disputes.

Smart friction

First, we experimented with introducing a cool-off screen in-app. When users attempted to raise a dispute immediately after a transaction, we prompted them to wait and contact the merchant first. This simple friction point successfully filtered out impulse disputes and those that could be resolved independently. This allowed for faster refunds for those customers, because they could go directly to the merchant, and freed up our capacity to help with complex cases.

Next, we targeted our highest volume disputers: those who may unknowingly be committing first party fraud. Here, we showed them a tailored warning screen, educating them about what first party fraud is, and the potential consequences of submitting fraudulent claims.

Automatic fraud detection

Next, we built an ML model to detect first party fraud, triggering further investigation from our Expert team. Protecting genuine customers came first: wrongly flagging a real claim is far more damaging than any single missed case, so the model had to be precise above all else.

To build our model, we needed labelled data on what first party fraud looked like, which we didn't have. So we developed a set of rules (a heuristic). When a case hit those rules, we flagged it as a suspicious claim and routed it to one of our Expert investigators to label it. We fed those labels back to refine the rules, work out what data we actually needed, and eventually train the ML model. The technique itself isn't new: putting a human in the loop to generate labels is common practice. The key takeaway is the mindset: you rarely start with clean data, so the fastest path is often to build a cheap way to create it, not to wait for it to appear.

With our data pipeline established, we began to build the model. This came in two parts: the first was working out which features to use (a feature is a signal in the data that helps the model predict whether a claim is genuine), and the second was training the model on those features and checking how well it performed.

Once complete, we released the model into production to triage cases to our Expert investigators with close oversight from Risk and Operations in a genuinely cross-functional effort.

The result

A significant drop in dispute forms, an award from Mastercard and a major shift in who was reporting: away from dishonest reports, towards legitimate or misguided customers. These were customers who aren't attempting fraud, but are confused by a complex process and unsure how to navigate it.

Step 2: Improved automated decisions

After reducing the noise and freeing up operational capacity, we turned to the other side of the problem: getting customers their money back without unnecessary friction. We already had a model that could decide some disputes automatically, the problem was that it was built on an old architecture and hadn't been trained in over 2 years. This meant we couldn't trust its decisions, so we chose to rebuild it.

We moved it onto our modern ML architecture and retrain it on fresh, high-quality data.

Automating a decision means choosing how confident we need to be before we act. Set the bar too low and we get calls wrong. Set it too high and unnecessary cases fall to manual review, which costs time and money. We had to balance cost, risk, and customer experience to land in the right place.

The result is a modern auto-decision model that approves the clear-cut genuine claims automatically, and hands everything else to a human to review. It only acts when the evidence is strong; anything uncertain or borderline goes to our Customer Operations team.

That means that customers with a strong case get their money back fast, without waiting on a manual review. And every case the model handles is one less for our Customer Operations team, freeing them to focus on the complex disputes that genuinely need a human.

Step 3: Helping customers build the best possible claim

With false claims filtered out and more accurate automated decisioning, we turned our attention to customers who need more support when creating their claim.

We saw that the majority of reports that were reviewed by our team were being rejected on first review. This showed us that we could do a better job at building cases with our customers, so that we can resolve their claim first time. We approached this with 3 changes:

• Improving the questions we ask

Improving the questions we ask

• Making it easy to add missing evidence

Making it easy to add missing evidence

• Stripping out unnecessary claims

Stripping out unnecessary claims

Improving the questions we ask

We investigated our highest volume dispute reporting journey, and updated the questions we asked our customers around a number of new principles. We asked customers what they bought upfront, removed unnecessary questions, and paired each description with a relevant evidence request. This had the aim of building a great case with the customer, while keeping friction to a minimum.

Making it easy to add missing evidence

Sometimes our team will review a submitted report, and need more info. We identified that the process for getting this was harder than it needed to be, so we built a system that lets our Customer Operations team reach out to customers, prompting them to improve their evidence as easily as possible.

How it works:

• When reviewing a dispute, if someone in customer operations spots missing evidence, they can request it directly within our back-office system.

When reviewing a dispute, if someone in customer operations spots missing evidence, they can request it directly within our back-office system.

• This triggers an in-app notification, showing the customer exactly what evidence is missing and why.

This triggers an in-app notification, showing the customer exactly what evidence is missing and why.

The customer uploads the missing evidence, which we automatically attach to their original case.

Stripping out unnecessary claims

We also noticed a pattern of customers submitting disputes for transactions that had already been declined or accidentally raising duplicate claims. In the past, these would sit in a queue only to be rejected hours later.

We decided that the best experience here is to save the customer that effort entirely. We introduced pre-submission validation that checks the transaction state before the dispute form loads and immediately informs the customer.

This prevents the frustration of filling out a form destined for rejection and provides immediate reassurance.

The result? We are already seeing rejected disputes drop from ~70% to ~50%. Our Customer Operations team now spends less time processing rejections and more time resolving complex cases.

Step 4: Meeting customers before they even report

Steps 1 to 3 fixed how we handle a dispute once it lands. But over the last six months we went after the bigger prize, the very top of the funnel: the moment a customer spots a payment they're unsure about and has to decide what to do. This is where our two squads, Disputes and Fraud Response, joined forces.

The problem: we ask customers to diagnose themselves

When something looks off, we ask the customer to make a decision before they've told us anything. Did you make the payment or did someone else? Goods not received, or not as described? Most people don't think in these categories. They just want it sorted.

That creates three problems:

• We route people to the wrong place. Customers guess which form fits, get funnelled into a rigid flow that might not match what actually happened, and end up misrouted or rejected because it was never the right type of claim to begin with.

We route people to the wrong place. Customers guess which form fits, get funnelled into a rigid flow that might not match what actually happened, and end up misrouted or rejected because it was never the right type of claim to begin with.

• We hide the context we already have. When a customer taps a confusing payment, we could show them their history with that merchant, whether it's a subscription, or how they authenticated it. Instead we push them straight into a report.

We hide the context we already have. When a customer taps a confusing payment, we could show them their history with that merchant, whether it's a subscription, or how they authenticated it. Instead we push them straight into a report.

• We don't explain what we need. People don't realise which evidence matters until they're halfway through a form, then they're stuck without the right screenshots. That means incomplete reports and rejections we could have avoided.

We don't explain what we need. People don't realise which evidence matters until they're halfway through a form, then they're stuck without the right screenshots. That means incomplete reports and rejections we could have avoided.

What we did: answer the question before it becomes a claim

Instead of asking customers to self-diagnose, we started giving them what they needed to work it out for themselves. A few of the things we shipped:

• A context panel on the payment itself: what we know about it, the history with that merchant, how it was authenticated, and plain-English explanations for the things that confuse people most, like delayed payments and subscriptions.

A context panel on the payment itself: what we know about it, the history with that merchant, how it was authenticated, and plain-English explanations for the things that confuse people most, like delayed payments and subscriptions.

• Subscriptions routing. A significant chunk of dispute claims are subscription-related, but we were asking "who made this payment?" which left customers unsure whether it was a dispute or fraud, and what to do about it. We built a dedicated flow asking what actually happened: forgot to cancel, cancelled but still charged, don't recognise the charge.

Subscriptions routing. A significant chunk of dispute claims are subscription-related, but we were asking "who made this payment?" which left customers unsure whether it was a dispute or fraud, and what to do about it. We built a dedicated flow asking what actually happened: forgot to cancel, cancelled but still charged, don't recognise the charge.

• Adaptive routing by payment type. Different payment types have different common problems. A card payment, a bank transfer, an ATM withdrawal: each has its own set of typical issues. We built routing that adapts the questions customers see based on how they paid, so they're answering questions that make sense for their specific transaction, not generic categories. The result was fewer misrouted claims, because we were asking about the right problems from the start.

Adaptive routing by payment type. Different payment types have different common problems. A card payment, a bank transfer, an ATM withdrawal: each has its own set of typical issues. We built routing that adapts the questions customers see based on how they paid, so they're answering questions that make sense for their specific transaction, not generic categories. The result was fewer misrouted claims, because we were asking about the right problems from the start.

• Expectation-setting upfront: A "before you start" screen telling customers what we'll ask, what evidence helps, and what happens next, giving them a clear moment to stop if reporting isn't what they actually need.

Expectation-setting upfront: A "before you start" screen telling customers what we'll ask, what evidence helps, and what happens next, giving them a clear moment to stop if reporting isn't what they actually need.

• An LLM evidence check at submission that spots low-quality uploads and prompts the customer to fix them before the case reaches a human. We guard against false positives carefully: the check only flags uploads that genuinely lack the context we need, and it always gives customers a chance to override or resubmit rather than rejecting their claim.

An LLM evidence check at submission that spots low-quality uploads and prompts the customer to fix them before the case reaches a human. We guard against false positives carefully: the check only flags uploads that genuinely lack the context we need, and it always gives customers a chance to override or resubmit rather than rejecting their claim.

We didn't guess, we ran experiments

We ran a series of experiments across both squads, and just as importantly, we let them tell us when we were wrong.

Our first instinct was to let customers describe the problem in their own words and use an LLM to route them from there. It didn't work the way we hoped: the free text customers gave us just wasn't rich enough to route reliably. But we learned from it: it pushed us to pivot from "tell us what happened" to "here's what we know, here's what we think the problem might be."

We learned a similar lesson when we showed customers more information about their payment. Highly tailored context for one narrow scenario worked brilliantly, but barely moved the overall numbers because it reached too few customers. Generic context shown to everyone worked a lot better. Every experiment, the wins and the misses, sharpened where we invested next.

The impact

We ran 15 experiments in 6 months (!) and measured each on its own. But we also wanted to know what it all added up to. So from the very start we set aside a control group: a set of customers who didn't get any of the changes so we always had a fair comparison. That tells us the impact of our work.

• 11% fewer fraud investigations for each customer, due to fewer people reporting things that were never problems in the first place.

11% fewer fraud investigations for each customer, due to fewer people reporting things that were never problems in the first place.

• 9% fewer misrouted claims, where a problem with something you bought gets reported as fraud by mistake, and 6% fewer reports that were always going to be turned down. Better questions, landing people in the right place.

9% fewer misrouted claims, where a problem with something you bought gets reported as fraud by mistake, and 6% fewer reports that were always going to be turned down. Better questions, landing people in the right place.

• ±25% less wasted effort behind the scenes: the evidence check alone cut manual review work by roughly 26% and follow-up messages to customers by 28%.

±25% less wasted effort behind the scenes: the evidence check alone cut manual review work by roughly 26% and follow-up messages to customers by 28%.

The bigger takeaway: give customers context instead of a quiz, and they make better decisions for themselves. That is better for both Monzo and our customers.

What’s next?

The dispute experience is already far better than it was 18 months ago. We think we have only just scratched the surface. There is still a big opportunity to improve how this feels for customers, and we’re not stopping.😀

One avenue we want to explore: a future where reporting a dispute feels like a conversation with someone who already knows the context, meets you where you are, and guides you clearly through what's needed.

Whether you prefer to type, speak, or walk through structured steps, the system will adapt to you, not the other way around.

Interested in a career at Monzo?

That's the last 18 months for disputes in a nutshell! I think this is a great example of how we tackle problems here at Monzo: with great tech, strong product thinking, and always driven by data. If you're interested in working at Monzo, we are hiring for Engineers and Engineering Managers, and don't forget to check out our careers page for a full list of all our open roles 🚀