The Future of AI in Payments: From Observer to Participant

contact@corebaseit.com (Vincent Bevia) — Sat, 04 Jul 2026 20:00:00 +0200

Most of what ships today under the label “AI in payments” is an advisory layer. It scores a transaction for fraud, ranks a queue of alerts, or summarizes why an approval rate dropped. It observes the payment flow and hands a signal to a human or a rules engine, but it does not move money and it does not sit inside the authorization decision. That boundary is deliberate, and it is the reason the current generation of payment AI has been safe to deploy.

The shift worth watching is what happens when AI crosses that boundary. Two moves are already in early production: AI that initiates payments on a user’s behalf (agentic commerce), and AI that operates the rails on the acquiring side (autonomous routing, retries, and switching). Both turn the model from an observer into a participant. This post is about what that change requires, what stays deterministic, and why the constraints that governed advisory AI get harder once the system can act.

The baseline: AI as a risk observer

It is worth being precise about where AI already earns its place, because the forward-looking argument only makes sense against that baseline. In the fraud layer, machine learning wraps around the authorization path rather than entering it: it scores, explains, and prioritizes, while EMV, tokenization, and the networks own the actual approve-or-decline. I covered that pipeline and its latency and explainability tradeoffs in AI in POS and payments, and the operational use cases (merchant copilots, decline explanation, analyst assistance) in where AI really fits in POS and e-commerce payments.

The common thread in both is that AI stays advisory. The human, or a deterministic policy layer, still owns the decision. Everything that follows is about what changes when that ownership shifts.

Agentic commerce: AI that initiates the payment

The first move is on the buyer side. Instead of a person tapping a card or clicking checkout, a software agent completes a purchase under a delegated mandate: find the item, agree the price, and pay within limits the user set in advance.

The important architectural point is that this does not require a new payment rail. It rides on the tokenization infrastructure that already exists. A wallet transaction never transmits the real Primary Account Number; it uses a device-bound token (a DPAN) issued and managed by a Token Service Provider, as the POS Architecture book covers in Chapter 20. An agent payment extends the same idea: the agent operates against a constrained, policy-bound credential — an ephemeral token with a spending cap, a merchant scope, and an expiry — rather than a raw card number. I wrote about how tokens replace PANs across the chain in payment tokenization; agentic commerce is largely a governance layer stacked on top of that mechanism.

This also fits the direction payment initiation was already heading. The book frames it as “the payment is the API call itself”: modern gateways expose initiation through authenticated APIs, so the difference between a human-triggered call and an agent-triggered one is the identity and the mandate behind the call, not the plumbing underneath it. Several industry groups announced agent-payment protocols during 2025 to standardize exactly this mandate-and-constraint layer. The names and status of those protocols are moving quickly, so treat any specific one as something to verify against current specifications rather than a settled standard.

The honest limitation: delegation is where the risk concentrates. A fraud score that is wrong produces a bad recommendation. An agent that is wrong produces a bad transaction — a real authorization against a real credential. That is why the useful version of agentic commerce is not “let the model buy things.” It is a constrained credential, an auditable mandate, and a spending policy that the agent cannot exceed, with the model choosing within those limits rather than defining them.

Autonomous operations: AI that runs the rails

The second move is on the acquiring side. The book describes closed-loop AI that adjusts routing paths, retry strategies, and acquirer switching from live telemetry. This is AI as an operator rather than an initiator: it does not touch the cardholder, but it changes how transactions flow through the platform.

The value here is concrete and tied to workload, not novelty. Payment operations teams already watch approval rates, decline reasons, BIN-level behavior, and routing performance across acquirers, and they already retry and reroute when something degrades. Doing that well at scale is an information-overload problem before it is an intelligence problem. A system that correlates the signals and proposes “the drop is concentrated in one BIN range and started after yesterday’s routing change” gives the team a better starting point, which is the same amplifier-not-replacement framing I keep returning to in AI as an amplifier, not a replacement.

The danger is the closed loop. An automated retry or reroute is a state change with money attached. Without idempotency and reconciliation discipline, an over-eager retry loop is how you turn a transient network blip into a duplicate charge. The failure modes I described in double charging and the state-transition thinking in reversals, refunds, and chargebacks become preconditions, not nice-to-haves, before you let a model act on the operational path.

The constraints get harder, not easier

When AI advises, a wrong output costs a bad suggestion. When AI acts, a wrong output costs a transaction, a dispute, or a compliance finding. The three constraints that already shaped advisory payment AI tighten as a result.

Latency stops being only about scoring speed. An advisory model has to return a signal inside the authorization window. An initiating agent has to plan, price, and commit within a flow a user is waiting on, and an operating agent has to react to telemetry fast enough to matter but slowly enough to avoid oscillating. The deterministic authorization path still runs on its own budget — the roughly two-to-three seconds of a card payment do not get more forgiving because an agent is involved.

Explainability moves from useful to load-bearing. “Because the model said so” was already a weak answer for a fraud decline; it is untenable when the model spent money or rerouted a live transaction. Automated decisions that significantly affect a person already carry obligations under GDPR Article 22, and payment-relevant AI is likely to fall under high-risk-system rules such as the EU AI Act and governance frameworks like the NIST AI Risk Management Framework, both of which the book flags as emerging architectural requirements. The practical consequence is that an agent action needs an audit trail — what mandate authorized it, what constraints applied, what the model chose and why — as a first-class output, not a log line.

Accountability becomes an architecture question. The model does not carry liability; the merchant, acquirer, or issuer does. So the design has to keep a human or a deterministic policy layer as the accountable owner of the boundary the agent operates inside. AI chooses within limits; it does not set them.

What stays deterministic

None of this reaches into the cryptographic core, and that is the point. EMV cryptogram generation, the CAPK trust anchors, tokenization, HSM-held keys, and PIN handling stay deterministic and governed. An ARQC is either valid or it is not, and the reason chip cards resist cloning (EMV ARQC) has nothing to do with a model’s confidence score. AI does not get a vote on whether a cryptogram verifies.

This is the same layering the fraud case already established, extended one step further. Deterministic security controls answer whether the instrument is authentic, the cryptogram is valid, and the issuer can authorize. The AI layer — now able to initiate and operate — answers whether this action is within mandate, whether this behavior looks normal, and whether this route is performing. The two answer different questions, and keeping them separate is what makes it safe to let the second one act at all.

Where this leaves payment AI

The near-term future of AI in payments is not a smarter fraud model, though that work continues. It is AI stepping from the sidelines into the flow: initiating constrained purchases for users, and operating the rails for acquirers. The enabling infrastructure — tokenization, API-native initiation, streaming telemetry — is largely already in place, which is why this shift is closer than the marketing usually is.

The gating factor is not capability. It is confidence. Letting a model act on real money is an accountability and governance problem first, and a modeling problem second. The teams that get value from this will be the ones that treat mandates, constrained credentials, idempotency, and auditable explanations as the design, not as controls bolted on afterward. Fluent is not the same as finished, and for payment AI, capable is not the same as trusted enough to act.

References

V. Bevia, POS Architecture (book), Chapter 20, “Future Trends in Payment Acceptance” — digital wallets and DPAN tokenization, API-native and Web3 payments, autonomous operations, and AI/regulatory (EU AI Act, NIST RMF) architectural impact.
Regulation (EU) 2016/679 (General Data Protection Regulation), Article 22, “Automated individual decision-making, including profiling.”
Regulation (EU) 2024/1689 (EU Artificial Intelligence Act), high-risk AI system provisions. Confirm current effective dates and scope against the published text.
NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023.
Agent-payment protocols announced across the industry in 2025 (for example, agentic commerce and agent-payment mandate specifications). Names, sponsors, and status are changing quickly; verify against the current specifications before relying on any single one.

Agentic-Commerce on Corebaseit — POS · EMV · Payments · AI · Telecommunications