# The payment is only one decision Canonical: https://www.meshqu.com/blog/agentic-payments-connected-decisions What Mastercard RiskX taught me about agentic payments, payment fraud and why evidence, authority and judgement need to stay connected. Published: 2026-10-16T12:00:00.000Z *What a day at Mastercard's RiskX event taught me about payment fraud, agentic payments and the work around a transaction.* I came back from Mastercard's RiskX event in London on Thursday with one line written twice in my notebook: get the right data at the right time. It came up in two very different sessions. The first was about connected commerce, where the aim is for payments to fade into the background. A good payment is like good Wi-Fi: you only think about it when it drops. The second was about fraud, and the speakers described the opposite trend. Scams now start on social media and dating apps, well before a bank sees any payment. Criminals know where the gaps between payment rails are and move money through them. Both sessions left me with the same thought. Hiding a payment doesn't make the decisions around it matter less. With agentic payments, where an AI agent pays on someone's behalf, the person may not see the payment at all. The question I've been thinking about since is this. As more of this work is handed to colleagues, software and AI, what needs to stay connected so people can still understand a decision, challenge it and change course? ## A fraud check answers one question One speaker described how a bank's payment fraud detection models flag money mule accounts by how fast money comes in and goes out. Criminals noticed. They now wait longer before moving it. Any check that's good at one narrow question gets worked around eventually. Checks still matter. You just need to know what each one tells you, and what it leaves out. Confirmation of Payee is a good example. [Pay.UK's guidance](https://www.wearepay.uk/what-we-do/overlay-services/confirmation-of-payee/faqs/) lists four results: a match, a close match, no match, and a check that couldn't be done. It also says the service doesn't guarantee a fraudulent payment will be caught. Speakers described merchants getting similar exact or partial results from systems that format data differently. A matching name tells you the name matched. If the next system treats that as "this payment is safe", the result has been passed on but its meaning hasn't. Agent purchases raise a similar question: what was the agent allowed to do? [Mastercard's Verifiable Intent](https://www.mastercard.com/global/en/news-and-trends/stories/2026/verifiable-intent.html), announced with Google on 5 March 2026, is built to keep evidence of that. Its specification ties an agent's actions to the limits a person set, and its [security model](https://verifiableintent.dev/spec/security-model/) treats evidence for a dispute and deciding who's liable as separate things. I think that's right. Someone asked on Thursday who pays when it goes wrong, and evidence alone can't answer that. Each piece of evidence answers a specific question. Knowing which question, and what else the decision needs, is most of the job. ## Agentic payments and the work around the transaction [NatWest published research](https://www.natwest.com/content/dam/natwest/corporates/pdfs/agentic-payments-report.pdf) this year that shows the tension. Across the financial tasks it tested, 66% of people wanted AI to research options and make recommendations, and 12% wanted it to decide and act for them. In NatWest's words: "When an agent acts, particularly in a financial context, it is not always clear where responsibility sits." I don't read that as people being scared of AI. They want to know who's accountable. The same question applies to plenty of work that has nothing to do with payments. A transaction usually sits inside a longer process, and the question comes up at every handoff. **A fraud investigation.** A reviewer decides whether new information is enough to close an alert, or whether a scam victim's [reimbursement claim](https://www.meshqu.com/app-fraud) needs more work. A useful handoff says which signals they looked at, what they weren't sure about and why they decided as they did. The next team shouldn't have to guess all that from a case status. **Invoice funding.** Reading an invoice's amount and due date is one task. Working out which evidence makes it eligible for funding, how discrepancies were handled and who signed off an exception is another. The [payment approval](https://www.meshqu.com/payments) that follows needs that reasoning, not a document marked as processed. **A software release.** Tests passed against one version, then the release candidate changed. Someone now has to decide whether those results still cover what they're about to ship. The rules, evidence and stakes differ in each case. The common thread is that the reasons behind a decision need to reach whoever acts next, whether that's a colleague, a piece of software or an AI-assisted system. Often the hardest handoff is between two people on the same team. ## What supported it then? Is it enough now? There are two questions here that are easy to mix up. What supported the original decision? And does that still hold for what someone wants to do now? [The Mills Review](https://www.fca.org.uk/publications/corporate-documents/mills-review), written for the FCA Board, makes this point about [AI agents](https://www.meshqu.com/ai-decision-governance). The challenge, it says, is "no longer simply whether the customer consented, but whether the agent's action can be shown to fall within a valid, live and properly scoped delegation of authority." Valid, live and properly scoped. Three separate questions, and a signature alone can't settle them. Here's an example. An invoice is approved for funding on Monday. On Wednesday a corrected version arrives. Monday's record still shows what was known and decided at the time, but it says nothing about Wednesday's document. You shouldn't edit the record to make it look as if Monday's decision saw the correction. You also shouldn't treat Monday's approval as permission for whatever comes next. Standards already make this distinction. The [W3C's Verifiable Credentials model](https://www.w3.org/TR/vc-data-model-2.0/) separates checking that a credential is genuine from whether its claims are true, includes validity periods and status, and expects whoever relies on a claim to apply their own rules. Keep the record of what happened, and keep thinking about what should happen next. ## A history that improves the next decision An audit trail tells you what happened. I'd judge it by whether it helps the next person. Can they avoid rebuilding the case, see what's still open, and tell when an earlier approval doesn't cover what they're about to do? There's a risk here too. [Barclays Private Bank's 2026 outlook](https://privatebank.barclays.com/content/dam/privatebank-barclays-com/en-gb/private-bank/documents/insights/2026/ai-mid-year-outlook/AI_Mid-Year_Outlook_2026_The_Productivity_Paradox.pdf) describes "cognitive surrender" as "the point at which people stop evaluating the answer altogether and simply adopt the machine's judgement as their own." It happens with people as well as machines. A confident sign-off from a colleague can stop you checking just as easily. Reuse good work, but still ask whether it's genuine, whether it applies and whether it's enough for what you're doing. An assessment isn't the outcome, either. Approving an invoice doesn't mean the money moved, and approving a release doesn't mean it worked. When you can link those later facts back to the decision, a team can learn from them. [Marc Priestley](https://www.speakersassociates.com/speaker/marc-priestley/), who worked as a McLaren mechanic through the 2000s, gave the best example of the day. He described how the team made debriefs a habit: recording decisions and events across a whole season, then going back over them to work out how to do things better next time. In 2007 Lewis Hamilton lost the championship by a single point. In 2008 he won it, also by one point. In Priestley's telling, that habit of going back over the season was part of how the team found the difference. ## Start where somebody already needs help Some people will want to jump straight to connecting whole industries. A session on adopting AI suggested a better order, in two phrases I wrote down: experiment before you accelerate, and trial within a boundary. Start with one handoff. Find a point where someone struggles to work out what was checked, why an exception was accepted or whether an earlier assessment still holds, and make that easier inside the process they already use. Then check two things. Can the next person act without redoing the original investigation? Can they tell when a fresh check is needed? Sharing between teams, and later between organisations, can come after that. It will still need permissions, agreed meanings and a reason to trust the source. ## Control that shows up when it matters None of this means an approval screen for every action. Routine work should stay out of the way, which is what the connected-commerce speakers were asking for. But when something is unresolved, the evidence has changed or an exception needs a judgement call, the person who gets interrupted should understand why and be able to act on it. It matters for the people a decision affects, too. One session looked at the language scammers use and how it leaves victims feeling ashamed. [Victim Support's guidance on talking to people affected by fraud](https://www.victimsupport.org.uk/talking-to-victims-of-fraud/) warns against blaming them. A good record should help someone understand and challenge what happened. It shouldn't just give an organisation a passed check to point to. That's what I took away from RiskX. The payment is one decision. The people relying on all the others need enough to act with confidence, and the willingness to think again when something changes. --- *Sam Carter is the founder of MeshQu.* ## Reference notes Public sources were checked on 16 October 2026. Observations from the event are my paraphrase of my own notes, not quotations from speakers. Marc Priestley is the only speaker named. The fraud, invoice-funding and release scenarios are illustrations, not customer case studies or legal guidance. 1. Pay.UK, [Confirmation of Payee FAQs](https://www.wearepay.uk/what-we-do/overlay-services/confirmation-of-payee/faqs/), undated; response categories and detection limits. A published analogue; it doesn't identify the service discussed at the event. 2. Mastercard, [When AI starts buying for you, trust becomes the product](https://www.mastercard.com/global/en/news-and-trends/stories/2026/verifiable-intent.html), 5 March 2026. The announcement predates the October event. 3. Verifiable Intent Working Group, [Specification overview](https://verifiableintent.dev/spec/) and [Security Model and Threat Analysis](https://verifiableintent.dev/spec/security-model/), version 0.1-draft; security model sections 2.4–2.5. 4. W3C, [Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/vc-data-model-2.0/), Recommendation, 15 May 2025; introduction, terminology, validity period and status sections. The then-and-now argument is my process-design interpretation. 5. Victim Support, [The power of language when talking to victims of fraud](https://www.victimsupport.org.uk/talking-to-victims-of-fraud/), 27 March 2023. 6. NatWest, [*Agentic Payments and the Rise of Delegated Commerce*](https://www.natwest.com/content/dam/natwest/corporates/pdfs/agentic-payments-report.pdf), 2026, p. 5. Survey of UK consumers; see the report's methodology page for samples and dates. 7. Sheldon Mills, *The Mills Review: AI and the future of retail financial services*, independent review commissioned by the FCA Board, July 2026, p. 144 (Annex VII). [FCA review page](https://www.fca.org.uk/publications/corporate-documents/mills-review). Recommendations to the FCA, not adopted policy. 8. Barclays Private Bank, [*AI Mid-Year Outlook 2026: The Productivity Paradox*](https://privatebank.barclays.com/content/dam/privatebank-barclays-com/en-gb/private-bank/documents/insights/2026/ai-mid-year-outlook/AI_Mid-Year_Outlook_2026_The_Productivity_Paradox.pdf), July 2026, p. 42, where the term is credited to Shaw and Nave (2026). 9. Speakers Associates, [Marc Priestley speaker profile](https://www.speakersassociates.com/speaker/marc-priestley/), accessed 16 October 2026: McLaren F1 mechanic 2000–2009, including Lewis Hamilton's 2008 championship season. The description of his RiskX talk is my paraphrase.