4 questions to test whether a financial crime compliance platform is actually AI-native

In our State of Financial Crime 2026 survey of 600 senior compliance decision-makers, 93% are currently using, piloting, or evaluating a vendor AI solution for customer screening. The number is almost as high for transaction monitoring at 87%. What’s clear to see is that AI has stopped being a competitive feature in compliance. It’s the baseline.

That changes the question compliance leaders are asking. “Does this vendor use AI?” is no longer a useful filter; every vendor will say yes. The useful question is which of those AI claims describe an architecture built for AI from the data layer up to enable effective financial crime risk management, and which describe AI features stitched onto a rules-based platform that predates them.

The distinction matters in two places where it is increasingly hard to fake: when a new typology emerges, and the system has to adapt without waiting for a release cycle, and when a regulator asks for a defensible explanation of a decision the model made in milliseconds, and the effectiveness of the decision. Bolted-on AI struggles in both. AI-native architecture is designed for both.

The pressure is not theoretical. Less than two-thirds of organizations (59%) have a fully established AI assurance program for effectiveness, auditability, and model governance; the rest are still building one. At the same time, 43% of compliance leaders rank explainability of AI features and outputs among the top three criteria when choosing an AI vendor. The regulatory floor is rising under the entire AI compliance market faster than most organizations can build the governance underneath it.

Vendors that built their detection engines around rules and added AI later cannot meet the rising floor by improving the AI layer alone. The architectural assumption underneath the rules engine, that humans write the logic and the system executes it, was never compatible with adaptive models or agentic workflows. Bolting AI onto a rules engine produces a system that uses AI; AI-native architecture produces a system designed around AI from the data layer up.

Four questions separate one from the other. Use them on every vendor that claims AI-native compliance.

1. Is AI the detection layer, or a scoring layer on a rules engine?

The most common bolted-on architecture runs a traditional rules engine as the primary detector and applies AI models on the back end to score, prioritize, or suppress the alerts the rules engine produces. That arrangement keeps the rules engine as the canonical source of truth for risk, with AI acting as an alert-management layer.

AI-native architecture inverts the relationship. The models are the detector. They ingest customer data, transaction data, payment data, sanctions lists, and adverse media, and they produce a risk decision directly. Rules can still operate alongside the models for specific regulatory mandates that require deterministic logic, but they are not the primary signal. 

The test for buyers: ask the vendor what produces the first risk score in their system. If the answer describes a rules engine producing the alert and AI scoring it afterward, the architecture is bolted on. If the answer describes models producing the decision directly from a unified data graph, the architecture is AI-native.

2. Does the model adapt as typologies evolve, or wait for human retraining?

Financial crime typologies do not wait for quarterly release cycles. Authorized push payment (APP) fraud, rapid mule-account chains, and money laundering-as-a-service have all emerged or evolved inside windows shorter than most vendors’ model refresh cadence. A system that depends on human rule-writing or scheduled model retraining will always lag behind the threat it is supposed to detect.

AI-native architecture treats model adaptation as a continuous process. Detection models retrain on incoming data, surface new patterns, and update scoring without a vendor release. Predictive machine learning (ML) and large language models (LLMs) are designed for this kind of adaptation; rules engines are not. 

The test for buyers: ask how long it takes from the moment a new typology is observed in production data to a measurable improvement in detection. If the answer involves a release cycle, an analyst writing rules, or a model refresh planned for next quarter, the architecture is not adapting fast enough for the threat landscape.

3. Can the AI act on alerts, or only flag them?

Detection that produces alerts and stops there leaves the architecture’s heaviest cost in place: the analyst review queue. Most of the operating costs in compliance are not detection-related. It is the work that happens after detection, on alerts that turn out to be false positives or low-risk true positives. A system that only flags moves the alert from the rules engine to the analyst; it does not change what the analyst has to do.

AI-native architecture extends from detection into agentic remediation. AI agents pull context from the customer record, the transaction history, sanctions and adverse media coverage, and the platform’s risk graph; they score the alert, execute the remediation playbook, and close the case with an audit trail. Cases that require human judgment escalate with the full context already attached. Done well, this automates up to 95% of routine remediation, so analysts focus on the alerts that move the regulatory needle rather than those that consume the day. 

The test for buyers: ask whether the AI generates alerts that humans resolve, or resolves alerts that humans review only when escalated. The difference is the operating model.

4. Is explainability part of the architecture, or a separate reporting layer?

Explainability is no longer an add-on. 43% of compliance leaders rank it in their top three vendor selection criteria, and 41% of organizations have yet to fully establish an AI assurance program, a gap that compounds the risk of running AI in production without architectural-grade governance. A bolted-on AI layer typically provides explainability through a separate reporting module that reconstructs the reasons a decision was made after the fact. The reconstruction is often incomplete, and it never holds up cleanly when a regulator asks why a model behaved differently for two similar cases.

AI-native architecture treats explainability as a property of the model output rather than a downstream report. Every decision carries its rationale: the data inputs used, the feature weights applied, the policy logic invoked, and the human review path, if any. The audit trail is the system’s natural product, not an export. 

The test for buyers: ask to see the audit record for a decision the vendor’s system has made in a customer environment, end-to-end. If the vendor points to a separate reporting module, explainability is bolted on. If the audit record is the model’s working artifact, the architecture is AI-native.

What this means for vendor selection

These are the questions the largest payments platforms are asking when evaluating compliance vendors, because the gap between AI-native and bolt-on AI is widening in production, not narrowing.

This is the architecture Marqeta is building on. As the modern payments platform for global innovators, including Block, Uber, and DoorDash, Marqeta processed nearly $400 billion in annual payments volume in 2025.  Marqeta is deploying the full ComplyAdvantage Mesh platform to embed risk intelligence, screening, and transaction monitoring directly into its payment decisioning layer. Mesh runs more than 80 specialized AI models across screening, monitoring, and risk scoring, with agentic AI handling investigation and remediation of routine alerts and explainability built into every decision.

“Our AI-native risk decisioning, dynamic schema architecture, and agentic capabilities are built to operate at the cutting edge of speed and scale,” said Vatsa Narasimha, CEO of ComplyAdvantage. “Marqeta is an undeniable powerhouse in the payment space, operating at that same edge, and we are providing it with a robust full-stack compliance solution for the FinTechs and on-demand platforms it supports.”

The market has moved past the AI-or-not question. The next question distinguishes compliance platforms architected around AI from those with AI added on top. The first scales with the businesses it serves, adapts as typologies evolve, and explains every decision it makes. The second does some of those things in some conditions. As real-time payments, agentic operating models, and rising regulatory expectations compound, that gap is not closing. The compliance platforms that hold up under this pressure will be the ones built around AI from the start, not the ones that added AI to what they already had.