IBS RegTech Labs publishes technical assessment of AI/ML in IBM Safer Payments
The payments fraud industry has a messaging problem. Every conference, every vendor pitch, every RFP response now leads with artificial intelligence. Machine learning is presented as the answer to faster attacks, higher volumes, and evolving fraud typologies. The assumption is rarely questioned.
Our new white paper questions it directly.
The premise is simple.
IBM Safer Payments is not a rules engine waiting to be rescued by AI. It is a deterministic profiling platform that computes behavioral features in real time across arbitrary entity relationships — any indexed attribute to any other, at sub-millisecond latency, against an in-memory transaction history. Card to merchant. Account to device. IBAN to IBAN. Originator through intermediary chains to the final beneficiary. These relational profiles are dynamic, lookback-adaptive, and deployable to production within hours of an analyst defining them.
This is not what most people picture when they hear „rules-based.“ And that gap between perception and reality is costing the industry money.
What the field evidence shows.
The white paper draws on deployment data from some of the largest payment processors in the world. STET, the French interbank processor, has publicly reported fraud reductions exceeding EUR 200 million with false-positive ratios approaching 1:1 — results achieved through the deterministic engine, not through layering ML on top. FIS reported a 72% reduction in fraud with a 90% reduction in false positives. SIBS, the Portuguese processor, achieved a 70% fraud reduction at a 1:3 false-positive ratio across cards and real-time payments.
These are not laboratory benchmarks. They are production outcomes at nation-scale volumes and our own experience with T1 banks and national payment processors confirms the same facts.
Where the paper takes a position.
We argue that the deterministic engine’s superiority in this domain is structural, not incidental. Payment fraud is characterised by extreme class imbalance, rapid pattern evolution, strict explainability requirements, and sub-millisecond latency constraints. Each of these characteristics favours deterministic logic over statistical models.
ML models need months of labeled data to learn a new attack pattern. A fraud analyst using the Safer Payments profiling engine can define a new behavioral variable and deploy a countermeasure in hours. ML models produce scores that cannot be decomposed into specific decline reasons for a cardholder dispute. Deterministic rules produce complete audit trails. ML retraining cycles run weeks to months. Rule updates happen continuously.
This does not mean ML is without value. The paper identifies specific, well-scoped scenarios where machine learning provides genuine incremental lift: anomaly detection baselines that catch deviations too subtle for explicit rules, long-view behavioral models trained on months of data to complement short-cycle rule updates, and feature discovery through random forest importance analysis that guides manual rule refinement.
The highest-value ML capability in the platform, in our assessment, is the cognitive rule generator. It learns from labeled historical data but produces human-readable decision rules — not opaque scores. The machine learns; the analyst validates; the production system executes transparent logic. This is ML that stays within the architectural philosophy of the platform rather than working against it.
The LLM question.
Every stakeholder evaluating fraud technology in 2026 is asking about large language models. The paper addresses this head-on.
LLMs cannot operate in the real-time transaction decision path. The constraints are structural: inference latency in hundreds of milliseconds versus sub-millisecond SLAs; stochastic outputs incompatible with deterministic audit requirements; per-inference costs that are orders of magnitude higher than the entire scoring cluster at nation-scale volumes.
In March 2026, IBM introduced the MCP Server for Safer Payments — a secure interface that enables LLM-based AI agents to query the platform’s APIs for alert triage, investigation acceleration, case summarisation, and reporting. The agents consume Safer Payments intelligence. They do not override its decisions.
This is the architecturally correct integration pattern. LLMs as productivity tools for the analysts who manage the fraud operation — not as replacements for the engine that runs it. IBM’s own framing is explicit: analyst augmentation, not replacement.
Why We Wrote This
IBS operates as an IBM Platinum Partner specialising in fraud management and regulatory compliance across the MEA and EU regions. We implement and optimise Safer Payments for Tier 1 banks and national payment processors. The conversations we have daily with fraud directors, CISOs, and compliance heads increasingly begin with a procurement mandate that includes „AI/ML capability“ as a checkbox requirement.
That checkbox is not wrong. But it is incomplete. The more useful question is: what is the detection architecture, how does it handle the structural constraints of payment fraud, and where does ML fit within it?
This paper provides a framework for answering those questions. It covers the deterministic engine architecture, embedded and external ML capabilities, a cost comparison between profiling-first and ML-first approaches, a decision framework for when to deploy ML, and a technical assessment of LLM applicability grounded in the MCP Server announcement.
It is written for fraud prevention professionals, solution architects, IT decision-makers, and compliance stakeholders who need to move past the marketing layer and evaluate what actually works in production.