Transaction screening is becoming the control point for instant payments

At a glance

What this is: Feedzai argues that transaction screening has become the front-line control for instant payments, because sanctions volatility and real-time settlement now collide inside the same workflow.

Why it matters: This matters to IAM and financial crime practitioners because the same governance problem appears in identity systems: if decisioning happens too late, the control becomes an after-the-fact record rather than a preventive gate.

By the numbers:

• US authorities issued $940 million in AML and sanctions violation penalties in 2025.
• The Faster Payments Council anticipates that between 70 and 80% of all US institutions will be receiving instant payments by 2028.
• The Faster Payments Council says that 30-40% of all financial institutions will be able to send instant payments.
• In the EU, payments must settle in 10 seconds, as required by the European Central Bank.

Context

Transaction screening is the real-time check that compares payment instructions, counterparties, and related data against sanctions, watchlists, and internal risk indicators before money moves. As instant payments become the default and sanction lists shift multiple times a day, the control has to decide inside the settlement window, not after it.

That creates a governance problem that looks familiar to identity teams: the control is only useful if it can act at the same speed as the transaction or access decision it is meant to govern. Legacy workflows built for batch review create delay, false positives, and a growing compliance gap.

Key questions

Q: What breaks when transaction screening cannot keep pace with instant payments?

A: The control stops being preventive and becomes reactive. Payments may settle before sanctions exposure is identified, while outdated screening rules also generate false positives that slow legitimate activity. The result is a governance gap: the institution cannot prove it screened the transaction at the required speed or with the required accuracy.

Q: Why do real-time sanctions controls need faster list updates than legacy AML workflows?

A: Because sanctions environments change faster than batch processes can absorb. If list ingestion lags by days, the institution may screen against stale data and miss newly restricted parties or locations. Faster update cycles reduce the window in which the control is operating on yesterday's risk picture.

Q: How can teams tell whether transaction screening is actually working?

A: Look for low false-positive rates, rapid list refresh, consistent audit trails, and a clear distinction between blocked, frozen, and approved transactions. If analysts spend most of their time clearing noise or cannot explain a decision in review, the control is functioning as a volume filter rather than a risk control.

Q: Should banks prioritise real-time screening or transaction monitoring first?

A: Real-time screening comes first when the risk is sanctions exposure at the point of settlement. Monitoring remains essential for behavioural detection over time, but it cannot stop a prohibited payment before execution. When settlement windows shrink, prevention has to be stronger than retrospective detection.

Technical breakdown

How real-time transaction screening works inside instant payment rails

Transaction screening starts as soon as the payment instruction is created and converts message data into a format that can be checked against sanctions and watchlists. The engine then compares names, addresses, BICs, jurisdictions, and related attributes, often using ISO 20022 structures, before a payment is allowed to settle. The architectural challenge is timing: the control has to resolve risk while the transaction is still pending, not after funds have left the account. That makes data quality, matching logic, and workflow orchestration part of the control surface, not just implementation details.

Practical implication: Design screening so the risk decision happens before settlement finality, not as a downstream review step.

Why false positives rise when matching logic stays rigid

Legacy screening tools often rely on narrow name matching and overly sensitive rules because they are tuned to avoid misses rather than to optimise precision. In real-time payments, that creates alert overload, slows operations, and pushes analysts into repetitive clearance work. The problem is not simply too many alerts. It is that unstructured payment data, inconsistent transliteration, and incomplete beneficiary details make exact matching a poor fit for modern flows. Holistic matching widens the signal set by combining names, locations, dates, and contextual attributes, which reduces noise without removing the obligation to investigate genuine risk.

Practical implication: Tune matching logic around precision and explainability, not just sensitivity, or operations will drown in avoidable alerts.

What explainable AI changes in sanctions and AML governance

Explainable AI matters here because compliance teams need to justify why a transaction was flagged, cleared, or escalated. In practice, that means the screening model must produce human-readable rationale, preserve the audit trail, and support validation by internal and external reviewers. Without that transparency, speed alone does not satisfy governance. The system can be fast and still be unacceptable if analysts cannot show why a decision was made, how the model handled ambiguous data, or whether the workflow aligned with regulatory expectations for review and recordkeeping.

Practical implication: Require decision logs and explanation outputs that let analysts defend both positive and negative matches during audit and review.

Threat narrative

Attacker objective: The attacker objective is to move funds through the payment system before the institution can reliably identify sanctions exposure or freeze the transaction.

1. Entry occurs when a payment instruction arrives with names, locations, or counterparties that could match sanctioned entities or high-risk jurisdictions.
2. Escalation happens when legacy screening cannot keep pace with volatile lists or real-time settlement, allowing risky transactions to pass or creating excessive false positives that delay legitimate payments.
3. Impact is either regulatory exposure from missed sanctions violations or operational friction from blocking too many valid transactions, both of which weaken the control's credibility.

Breaches seen in the wild

• Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Transaction screening has become a decision-time control, not a back-office compliance task. The article shows that the effective control point now sits inside the payment workflow itself, because the transaction may settle in seconds. That changes how governance should be designed: the system must decide while data is still forming, not after a case is opened. For practitioners, the control boundary has moved upstream into orchestration and message quality.

Compliance lag is the real governance failure, not just poor list management. The article's three-to-four business day delay in updating sanctions data is more than an operational inconvenience. It means institutions may screen against stale policy while payment rails and geopolitical risk change in near real time. That is a control freshness problem, and it should be treated as a governance defect with direct regulatory consequences. Practitioners should measure freshness, not just coverage.

Explainability is now part of the control, not a reporting extra. If a screening engine cannot justify why a payment was blocked or cleared, the institution does not have a governable control, only a fast one. This matters across AML, sanctions, and adjacent identity workflows because regulators increasingly expect evidence that the logic works as designed. Practitioners should treat rationale generation as an auditable control requirement.

Identity resolution is the hidden dependency inside transaction screening. Payment screening depends on resolving who is who across names, locations, and counterparties, which makes it adjacent to identity verification governance even when it sits inside a financial crime stack. Bad identity resolution turns sanctions controls into noisy pattern matching and weakens the trust basis for every downstream decision. Practitioners should align screening with stronger identity data governance.

What this signals

Decision freshness is the new control metric. In real-time payments, the value of a screening engine depends less on whether it knows the rule set and more on whether it can apply the current rule set before settlement closes. Institutions should therefore treat update latency, match rationale, and queue time as operational risk indicators, not just IT metrics.

The broader governance lesson is that compliance tooling is converging with identity and risk orchestration. Screening, verification, case management, and audit evidence now need to function as one control plane, otherwise speed gains in payments will simply shift risk into another part of the workflow.

For practitioners

• Define the screening decision boundary before settlement Map exactly when a payment can be approved, flagged, frozen, or rejected so the control acts before funds move, not after review closes.
• Shorten sanctions list update cycles Replace manual download and transformation steps with automated ingestion and validation so list changes are applied in hours, not business days.
• Re-tune matching to reduce false positives Move beyond rigid name matching and use multi-attribute scoring for names, jurisdictions, addresses, and contextual fields.
• Make explanations audit-ready by default Preserve the score, rationale, analyst action, and final disposition for every flagged transaction so auditors can trace the full decision path.

Key takeaways

• Transaction screening is moving from a back-office AML check to a real-time control embedded in payment execution.
• The biggest operational risk is not only missed sanctions exposure but also stale data, false positives, and decision latency.
• Institutions need faster list ingestion, stronger identity resolution, and auditable explanations if they want instant payments without weakening compliance.

Related NHI Mgmt Group resources: Ultimate Guide to NHIs · GLBA Safeguards Rule Guide · KYB and Business Identity Verification Guide · Compliance Automation Buyer's Guide

Key terms

• Transaction Screening: Transaction screening is the process of reviewing payments and transfers for suspicious patterns, policy breaches, or compliance concerns. Automated screening uses rules and machine learning to flag unusual activity, maintain audit trails, and reduce the workload of manual review teams without removing governance oversight.
• False Positive: A false positive is a scanner result that looks like a secret but is not actually sensitive. In secret governance, false positives matter because they consume analyst time, weaken trust in alerts, and can delay response to the findings that truly change exposure and access risk.
• Sanctions List Volatility: Sanctions list volatility is the rapid and frequent change in restrictive measures, watchlists, and related entities that screening controls must absorb. When update cycles lag behind these changes, institutions screen against stale policy and increase the chance of either missed violations or unnecessary blocking.
• Explainable AI: Explainable AI is the practice of making an AI system’s decisions understandable to the people who have to review, validate, or rely on them. In financial services, that means producing explanations that can support compliance, model validation, customer communications, and audit, not just technical curiosity.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle control. It is designed for practitioners who need to connect identity assurance to broader security and compliance programmes.