AI-Ready Enterprise Payments: Why ACI + IBM Z Matters

Payments don’t fail gracefully. When a core authorization path slows down or a fraud model starts throwing false positives, the result isn’t “a little friction.” It’s outages, revenue loss, regulatory heat, and angry customers.

That’s why the ACI Worldwide and IBM expansion—bringing BASE24-eps and ACI Proactive Risk Manager to IBM Z as native 64-bit applications, with further support planned for IBM’s latest platform generation—matters beyond the press-release vibe. This isn’t just “modernization.” It’s a practical blueprint for how AI in payments infrastructure should evolve: high-volume transaction processing, real-time fraud decisioning, and hybrid-cloud control that regulators can actually live with.

This post is part of our AI in Payments & Fintech Infrastructure series, where we focus on what really changes operations: model performance, latency budgets, concentration risk, and the messy realities of integrating AI into systems that can’t blink.

The real bottleneck in AI payments: infrastructure, not algorithms

If you want an honest take: most institutions don’t struggle with finding AI. They struggle with running AI where the money moves.

Real-time fraud detection and transaction routing aren’t like BI dashboards. They have hard constraints:

• Latency ceilings: approvals often need to happen in tens of milliseconds end-to-end.
• Always-on reliability: “four nines” isn’t enough for many rails.
• Auditability: you don’t get to shrug when regulators ask why a payment was blocked.
• Security boundaries: fraud signals include sensitive identity and behavioral data.

So when ACI talks about performance, resiliency, and scalability—and IBM Z shows up in the conversation—it’s because AI value only materializes when you can deploy models and decision logic inside the transaction path without destabilizing it.

Why IBM Z keeps showing up in serious payments conversations

IBM Z (mainframe) platforms remain common in global banking because they’re engineered for high-throughput, fault-tolerant transaction processing with strong security primitives. In plain language: if you’re processing massive volumes and you can’t afford downtime, it’s a rational place to run the “heart” of payments.

That matters for AI because fraud systems are increasingly expected to:

• score every transaction (not just a sample),
• do it in real time, and
• adapt quickly as fraud patterns shift.

Infrastructure that can run those workloads consistently is the difference between “AI pilots” and production outcomes.

BASE24-eps on Z: speed and resiliency for the authorization layer

Answer first: putting BASE24-eps closer to the core compute layer improves the odds that high-volume authorization and routing stays fast, stable, and governable as channels expand.

BASE24-eps has long been positioned as a standard for acquiring, routing, switching, and authorization across card and non-card transactions. In large environments, these engines aren’t just transaction processors—they’re coordination systems for multiple networks, channels, and back-end dependencies.

Here’s what changes when institutions modernize the payment engine with AI in mind:

Transaction routing is becoming an AI problem

Routing used to be deterministic: pick the network, pick the path, apply rules. Now it’s increasingly probabilistic and optimization-driven:

• Which route is most likely to succeed right now?
• Which option minimizes cost without increasing fraud exposure?
• What’s the expected impact of a soft decline versus retry logic?

That’s not science fiction. It’s what happens when you combine real-time telemetry (network response codes, acquirer performance, channel health) with decisioning logic. Even if you don’t call it “AI,” the stack starts behaving like an AI system: ingest signals, score outcomes, choose actions.

PCI 4.0 readiness isn’t paperwork—it’s an operating constraint

The source notes BASE24-eps being PCI-SSF certified for PCI 4.0. That matters because many AI initiatives in payments fail at the compliance layer. If your fraud stack requires broad data access, you can accidentally expand your compliance scope and your risk.

A cleaner approach is to:

• keep sensitive card data and authorization processing in tightly controlled environments,
• pass tokenized or minimized signals to models where possible,
• and design fraud decisioning so you can explain outcomes without exposing raw data.

In practice, payments teams that win with AI treat compliance as a design input, not a final review step.

Proactive Risk Manager: incremental learning is the fraud feature that matters

Answer first: the most valuable fraud models aren’t the fanciest—they’re the ones that adapt fast without breaking operations.

ACI Proactive Risk Manager (PRM) highlights incremental learning and the ability to respond to suspect activity in real time across channels including card transactions, instant payments, cash activity, and even cryptocurrency transactions.

That cross-channel view is exactly where fraud is headed in 2026: scams don’t respect product boundaries. A compromised identity will hit cards, faster payments, and account access in the same day.

Incremental learning vs. “monthly model refresh”

A common anti-pattern: teams retrain models on a schedule (monthly/quarterly), then celebrate “model improvements,” while fraudsters change tactics weekly.

Incremental learning—done correctly—means the system can update understanding from fresh patterns without waiting for a full retrain cycle. Operationally, that can reduce the “fraud gap” window where attackers exploit new behaviors.

But here’s the stance I’ll take: incremental learning is only worth it if your governance is tight. You need controls that answer:

• What changed in the model behavior?
• Did false positives spike for a particular segment?
• Can we roll back safely?
• Are we drifting because fraud changed—or because data quality degraded?

If you can’t answer those, you don’t have adaptive AI. You have an incident waiting to happen.

Fraud decisioning must optimize three things at once

Fraud leaders don’t just optimize for “catch rate.” They’re balancing:

1. Loss reduction (stopping true fraud)
2. Customer experience (minimizing false declines and unnecessary step-ups)
3. Operational cost (case volumes, manual review, contact center impact)

The best AI fraud systems are explicit about trade-offs. They use segmentation and policy overlays so the bank can say: “We’re stricter here, smoother there.”

A practical pattern that works:

• Use AI models to generate risk scores + reason codes.
• Apply business rules for policy constraints (e.g., regulatory, VIP handling, geographies).
• Route borderline decisions into step-up authentication rather than hard declines.
• Feed outcomes back into the learning loop with label discipline (confirmed fraud vs. suspected fraud).

This is where enterprise-grade platforms earn their keep: the “plumbing” matters as much as the model.

Hybrid cloud isn’t a compromise—it’s the only realistic operating model

Answer first: hybrid cloud is increasingly the default for regulated payments because it reduces concentration risk and keeps critical workloads under stronger operational control.

The source calls out regulator and central bank pressure—particularly in Europe—around public cloud concentration risk. That’s not theoretical. Institutions are being pushed to demonstrate resilience strategies that avoid single-provider dependencies for critical infrastructure.

This shifts architecture decisions:

• You may still use public cloud for elasticity, analytics, experimentation, and developer velocity.
• But core transaction processing and the most sensitive decisioning may remain on platforms engineered for predictable performance and high assurance.

OpenShift on Z: the point is portability with guardrails

Red Hat OpenShift on Z is positioned as a way to run containerized workflows on IBM Z while still supporting hybrid models.

The important angle for AI in fintech infrastructure is this: portability is how you avoid painting yourself into a corner.

In real programs, teams often want:

• a consistent container platform,
• policy-driven deployment patterns,
• workload placement choices (on-prem, private cloud, public cloud),
• and the ability to move components without rewriting everything.

You won’t move your entire payments stack overnight, and you shouldn’t try. Portability lets you modernize in slices:

• keep the high-volume payment engine stable,
• modernize fraud decisioning interfaces via APIs,
• add new AI services (device intelligence, scam detection, behavioral biometrics) where they fit,
• and centralize observability so you can detect model drift and latency regressions early.

What “AI-enhanced enterprise payments” should look like in 2026

Answer first: the winners will run AI where it counts—inside the decision path—while proving control to regulators and maintaining uptime.

If you’re planning your 2026 roadmap, here are the patterns I’d prioritize based on what we’re seeing across the market.

1) Treat latency as a product requirement

Fraud teams love richer signals. Payments teams love predictable performance. You need both.

Set explicit budgets:

• maximum scoring time per transaction
• maximum added network hops
• fallback behavior if the fraud service is degraded

If the fraud system goes down, do you fail open, fail closed, or degrade with step-up? Decide before you need it.

2) Build “explainability by design,” not as an afterthought

Regulators and internal model risk teams will increasingly expect clear explanations.

Operational best practice:

• store decision metadata (score, top drivers, policy rules triggered)
• keep an auditable record of model versioning
• separate model output from policy decisions so you can justify the final action

3) Reduce fraud by targeting scams, not just transactions

The fastest-growing pain point for many institutions is authorized push payment scams—where the customer initiates the transfer.

Traditional card-style fraud controls aren’t enough. You need:

• payee risk scoring
• mule account detection
• behavioral anomalies (new device, unusual session patterns)
• friction strategies that stop scams without breaking legitimate real-time payments

4) Modernize in layers, not rip-and-replace

A realistic modernization sequence I’ve found works:

1. stabilize the core payment engine
2. standardize APIs and event streams
3. add AI decision services with tight SLOs
4. expand cross-channel fraud views
5. automate feedback loops and governance

This is where partnerships like ACI + IBM matter: they’re aimed at institutions that can’t pause the world to “transform.” They need evolutionary change that still moves the needle.

A quick self-check for banks and PSPs evaluating this direction

If you’re a CIO, payments head, or fraud leader, these questions cut through vendor noise:

1. Can we score transactions in real time without breaching latency SLOs?
2. Do we have a tested failure mode when fraud services degrade?
3. Are we over-dependent on one public cloud provider for critical rails?
4. Can we prove model governance—versioning, drift monitoring, rollback?
5. Do we see customers across channels, or only per product silo?

If you’re shaky on two or more, you don’t need “more AI.” You need a stronger AI-ready payments architecture.

Where this partnership fits in the bigger AI payments story

ACI’s move to bring BASE24-eps and Proactive Risk Manager to IBM Z as native 64-bit applications—paired with a hybrid-cloud path via OpenShift, and platform evolution focused on enhanced AI integration—signals a clear direction: AI belongs in the core, but it has to be controlled, resilient, and compliant.

That’s the through-line of this whole series. AI in payments isn’t a chatbot project. It’s infrastructure work. It’s decision science under pressure. And it’s measured in milliseconds and basis points, not demos.

If you’re mapping your 2026 priorities, focus on one outcome: making real-time decisions safer without making the system fragile. What part of your stack is most likely to break first—fraud scoring, routing, or cloud dependency?