A customer signs in successfully and approves a payment from a familiar device. Every authentication check passes. The money still goes to a fraudster.
The customer may have been persuaded by a convincing impersonation. Or an authorised shopping agent may have initiated a purchase outside the customer’s intended instructions. These scenarios expose a weakness in payment security: knowing who accessed an account does not fully explain whether a particular transaction should proceed.
AI-powered fraud makes that distinction more consequential. The FBI has documented criminals using generated text, fabricated documents, cloned voices, and synthetic video to make financial scams more convincing and easier to scale. Source: FBI warning on generative AI fraud.
For fintech platforms, the response requires several connected controls: timely risk assessment, appropriate authentication, enforceable limits, and evidence of what the customer actually authorised.
Why Static Fraud Rules Miss Context
A fixed rule can identify a known condition: a transfer exceeds a threshold, a country is restricted, or an account has attempted too many payments.
Those controls remain useful. Problems arise when they become the entire decision process.
Consider a hypothetical €450 transfer. Its amount might look ordinary. But the same payment deserves closer attention if it follows an account recovery, goes to a newly added recipient, and occurs alongside several other unusual actions.
A rule evaluating only the amount misses that sequence. Conversely, a large but routine supplier payment may trigger unnecessary friction despite fitting the customer’s established activity.
Real-time fraud detection becomes more useful when it evaluates the transaction alongside relevant account history, device signals, recipient information, and recent behaviour. The objective is to identify combinations that deserve intervention while allowing genuine activity to continue.
What the Evidence Says About AI Fraud Detection
Claims that machine learning reduces fraud losses by 40–60% need a defined baseline. A reduction in losses, an increase in detection, and fewer false alerts are different outcomes.
Visa reports that its enhanced A2A Protect offering has demonstrated over 50% more fraud reduction and over 40% fewer unnecessary alerts. These are vendor-reported results for a specific solution, rather than a universal forecast for every platform adopting AI. Source: Visa A2A Protect announcement.
Mastercard’s research with Financial Times Longitude provides another perspective. In a survey of 300 payment executives, 42% of issuers and 26% of acquirers reported saving more than $5 million from fraud attempts over two years through AI. These self-reported findings support the business case for investment, but do not establish a standard percentage reduction in realised losses. Source: Mastercard payment fraud research.
For an individual platform, the meaningful test is whether a new approach reduces fraud at an acceptable approval rate, customer-friction level, and operating cost.
Real-time scoring also does not mean a model automatically learns safely from every transaction. Models need validated updates, reliable fraud labels, and monitoring for changes in performance.
Agentic Commerce Changes the Meaning of Authorisation
Agentic commerce allows AI agents to search, select, and purchase on a customer’s behalf. In 2026, payment infrastructure is being developed and deployed to support these journeys, although availability and functionality vary by market.
Visa Intelligent Commerce describes agent-specific payment tokens, authenticated customer instructions, and controls that check whether payment requests match those instructions. Mastercard Agent Pay similarly emphasises registered agents, tokenisation, and verified purchase intent. Sources: Visa Intelligent Commerce, Mastercard Agent Pay.
This introduces a new distinction. An agent can be correctly identified and still attempt an action the customer did not authorise.
Suppose a customer permits an assistant to buy office supplies for up to €200. The platform should be able to determine whether that authority covers one purchase or several, when it expires, and what happens if the final price changes.
Useful controls include:
A defined spending budget and validity period.
Restrictions on merchants or purchase categories where appropriate.
Fresh approval when a purchase exceeds the original instructions.
A way to revoke the agent’s purchasing authority.
Records connecting the instruction, payment, and outcome.
These are design requirements for delegated purchasing. Recognising an approved agent is only part of the assessment; its requested action must also remain within scope.
What Still Works: Connect Detection With Transaction Controls
A fraud score is useful only if the platform can act on it before the relevant payment stage completes.
The decision may be to approve, request additional authentication, hold for investigation, or decline. Each response should address the reason for concern.
Authenticate the payment as well as the session
Login authentication establishes access to the account. A sensitive payment may need its own confirmation.
Finhost’s Transaction-Level MFA adds an authentication step to selected payment flows. A customer can initiate a payment on the web, review its details on mobile, and confirm using biometrics or another available method.
The transaction details matter. A generic approval prompt gives the customer little opportunity to notice that the amount or recipient differs from their intention.
A robust implementation should also invalidate the approval if material payment details change. That is an implementation requirement to verify, rather than something to assume from the presence of an MFA screen.
Strengthen account access without treating it as proof of intent
Finhost’s Multi-Factor Authentication & Biometrics addresses the account-access layer of the security journey. When evaluating authentication, teams should assess the strength of the underlying method and its recovery process.
NIST explains that phishing-resistant authentication uses cryptographic mechanisms to prevent authentication to an impostor service. A biometric gesture can unlock such an authenticator, but the gesture alone does not establish the security properties of the complete flow. Source: NIST on phishing-resistant authentication.
Even strong authentication has limits. A genuine customer may approve a payment after being deceived. Where the concern is a scam rather than stolen credentials, the appropriate response may include a targeted warning, a pause, or investigation. Repeating authentication alone may leave the underlying risk unresolved.
Use limits to contain exposure
Limits provide a concrete boundary when detection is imperfect.
Finhost’s Limits Management is relevant to the control layer teams should assess when defining permitted transaction activity. The required configuration depends on the payment product and its risk model.
For agentic commerce, a useful design distinguishes a per-purchase limit from a cumulative budget. An agent making several individually permitted purchases should not be able to exceed the total authority granted by the customer.
Limit increases also deserve protection. A compromised session should not be able to remove the boundary immediately before initiating a risky payment. Teams should determine which changes require fresh authentication, review, or delayed activation.
Adaptive Checks Still Need Firm Boundaries
Adaptive fraud prevention combines contextual assessment with controls that remain explicit.
A model may help determine whether a transaction is unusual. It should not silently override a customer’s spending ceiling or extend an agent’s authority.
A practical decision process can combine:
Contextual risk scoring: Identify suspicious combinations of signals.
Transaction authentication: Confirm the customer’s participation in a sensitive action.
Spending and velocity limits: Restrict exposure over a transaction or period.
Agent permission checks: Keep delegated purchases within authorised scope.
Investigation and feedback: Resolve uncertain cases and improve future decisions.
This also requires a defined response when a risk service is unavailable. The platform should decide in advance which activities may continue, which require another check, and which must wait.
Measure Protection and Customer Friction Together
A lower fraud figure can conceal excessive declines. A higher approval rate can conceal growing losses.
Teams should assess fraud losses relative to payment volume alongside false declines, authentication completion, review delays, and decision latency. For agent-led payments, they should also monitor purchases outside authorised scope and disputes about what the customer permitted.
The goal is a payment journey that can explain its decisions: why this transaction proceeded, why another required confirmation, and why a third stopped.
AI fraud detection can improve that decision-making. Its value depends on the controls surrounding it. As both criminals and legitimate purchasing agents become more capable, platforms need to connect transaction context, customer intent, authentication, and limits at the moment money moves.
Top comments (7)
The authorised fraud framing is the sharpest part. Session signals were built to answer who is on the device, but agentic commerce now asks who set the intent, and that is a different question. Treating limits as containment rather than just policy is underrated too, since they are the last line that still holds when detection misses. Would you put the transaction controls for agent-initiated flows at the issuer or the PSP layer?
I’d put controls at both layers, with different responsibilities.
The PSP or orchestration layer is where I’d check the agent’s mandate: what the customer authorised, the cumulative budget, expiry, and when fresh approval is needed. The issuer should retain independent checks on account risk, available funds, and spending limits.
The key is how those layers connect. An issuer shouldn’t have to infer purchase intent from a valid token alone, and PSP approval shouldn’t bypass issuer controls.
Your containment point is exactly why I’d keep hard limits independent of the fraud score: a low-risk assessment should never expand the agent’s authority.
Keeping the issuer's checks independent of the PSP mandate is the part most agent payment designs get backwards. The mandate proves what the customer authorised, but says nothing about the account behind it, so collapsing one layer into the other just moves the blind spot. The open question I keep coming back to is how mandate metadata reaches the issuer in a form it can actually trust, instead of it having to re-derive intent from the token.
That’s the trust boundary I’d focus on too. I’d want verifiable evidence linking the customer’s authorisation to the specific payment, rather than a mandate reference or valid token alone.
A signed attestation could be one approach, provided the issuer trusts its source and can verify the scope, expiry and transaction binding. A signature alone wouldn’t solve revocation, replay or cumulative-budget enforcement.
Where that evidence cannot be verified, I’d treat intent as unverified and apply a defined fallback, such as fresh customer approval or holding the payment. The issuer’s independent account and risk checks would still apply.
Revocation is the one that quietly breaks most attestation designs. A signature is a point-in-time claim, but the budget it vouches for stays live for the mandate's whole life, so the issuer ends up needing either a revocation feed or a live lookup anyway, which re-introduces the connectivity assumption the attestation was supposed to remove. Replay and transaction binding are the easier half: a nonce tied to the payment instruction plus a short expiry window closes most of it. The fallback list is where the real design tension sits. Holding the payment is safe but slow, and fresh customer approval keeps the human in the loop, though a re-approval prompt that customers start approving routinely is its own attack surface. Where I'd land: unverifiable intent defaults to hold, and re-approval only when the amount or payee changed from what the mandate recorded. Those two changes are exactly what authorised fraud touches, so they're the ones worth the friction.
Thanks for expanding on this. The revocation point makes the trade-off clearer: signed evidence still needs a way to establish whether the mandate remains valid.
Your distinction between holding a payment and requesting fresh approval is useful too, especially given the risk of approval fatigue. Amount and payee changes seem like sensible triggers to consider, alongside the wider transaction context. The fallback needs to address the reason verification failed, while keeping unnecessary prompts to a minimum.
Agreed on the wider context: a payee that's never appeared before is a different risk than a familiar one, even at the same amount. And the failure-reason point is the sharpest addition here. A short expiry window because the attestation couldn't be fetched and a hard stop because a signature didn't verify are two very different responses, and collapsing both into one re-approval prompt throws away the signal that tells you which situation you're in. Good discussion, thanks for pushing on the details.