Real-time transaction screening is a controlled decision service. It receives a transaction, applies relevant intelligence and policy, produces a decision, and preserves evidence of why that decision was made. Buying a risk dataset or a broad monitoring suite does not by itself establish that this end-to-end service exists.
This report integrates a detailed screening study, its factual-corrections memo and an expanded August 2026 briefing. Supplier and institutional names have been removed. Historical regulatory findings, vendor claims and cost estimates are retained with their original status. The conclusion is that comparable layers must be evaluated separately, then tested together using the buyer’s own data and failure scenarios.
Three products are often confused
A screening engine compares transaction or customer attributes with relevant lists and risk indicators. A risk-intelligence dataset supplies information about sanctioned parties, politically exposed persons and other risk categories. A transaction-monitoring platform looks for behavioural patterns across time and relationships. A broad supplier may offer several of these, but the functions remain distinct.
The corrections memo matters because the original screener had treated products from these different layers as direct equivalents. This synthesis preserves the correction rather than repeating the category error. The relevant shortlist depends on whether the buyer needs an engine, data, monitoring, case workflow or an integrated combination.
Evaluate distinct control layers separately before testing the whole service
| Layer | Core output | Principal evaluation question |
|---|---|---|
| Risk intelligence | Structured risk information and updates | Is coverage timely, sourced and appropriate? |
| Screening engine | Match or decision candidates | Does matching detect relevant variants within the latency requirement? |
| Policy orchestration | Permit, hold, reject or escalate instruction | Are actions consistent with the applicable policy? |
| Investigation workflow | Reviewed case and rationale | Can analysts resolve and evidence decisions efficiently? |
| Behavioural monitoring | Patterns across activity and relationships | Does it identify risk that a single-message screen cannot? |
Define what “real time” means
Engine response time is only part of the customer journey. Data normalisation, list retrieval, policy checks, network transit, case handling and downstream execution can dominate the total. A supplier benchmark measured inside its engine is not an end-to-end payment commitment.
Define the start and end events. For example, the clock may start when a payment instruction enters the bank and stop when a controlled release or hold decision is returned. Measure median and upper-percentile latency under normal and peak load. Include list updates and failover rather than testing only a warmed-up steady state.
The historical material repeated a supplier claim of throughput above 85 million records per day. That is a useful test hypothesis, not proof of performance on a different dataset and policy configuration. Record size, matching complexity, hardware and audit logging can change throughput substantially.
Figure 01 · Conceptual framework
The transaction-screening decision path
Exact-name performance is not enough
The August 2026 source cited a regulatory review in which participating firms detected approximately 90% of exact sanctioned names but only 75% of minor variations. These are historical findings as reported in the research, not a current compliance benchmark. Their significance is the gap between a clean demonstration and the messy names that appear in production.
Test transliteration, abbreviations, spacing, punctuation, titles, honorifics, reordered names and incomplete information. Include addresses and identifiers where policy permits their use. A matching system should be assessed across the scripts and languages present in the institution’s actual activity.
Do not use a single threshold without examining the distribution of outcomes. Tightening a threshold can reduce analyst workload while increasing missed matches. Loosening it can overwhelm operations. The acceptable balance depends on policy, risk and evidence, not a supplier’s preferred demonstration setting.
False positives need a controlled denominator
Let (TP) be true positives, (FP) false positives and (FN) false negatives in a defined test set. Precision and recall are
Precision describes how many flagged cases are relevant; recall describes how many relevant cases are detected. Neither should be replaced by a broad accuracy number in a highly imbalanced dataset. A low-risk transaction population can make a weak detector appear accurate.
The source materials discussed a public historical banking case reporting two to four times more true-positive risk and more than a 60% reduction in alert volumes after an analytical change. Those are reported case outcomes, not a transferable guarantee. They also concerned a broader monitoring context and should not be relabelled as a pure real-time sanctions-screening result.
That distinction is central. Good evidence for one control function can inform a procurement discussion, but it cannot prove performance in a different function with different data and decisions.
Figure 02 · Qualitative comparison
Three product types often confused
| Approach or concept | What it contributes | What still matters |
|---|---|---|
| Transaction screening | Checks a payment or transaction as it occurs | Latency and failover policy affect execution |
| Customer screening | Checks parties during onboarding and review | Identity context and ongoing changes matter |
| Monitoring | Looks for patterns across activity | Its observation horizon differs from a single payment |
List management is part of the control
A screening engine is only as current and coherent as the information it receives. Official lists, commercial intelligence, internal restrictions and approved exceptions need controlled ingestion and versioning. The institution should know which list version was used for each decision.
Updates require more than replacing a file. The system must handle additions, removals, corrections and changes in identifiers. It should record when updates became available, when they were ingested and when they became effective in production. An apparent screening failure may originate in a delayed list update rather than matching logic.
Approved exceptions need ownership and expiry. A permanent “good party” entry can become a blind spot if the underlying relationship changes. Review processes should retain the rationale and ensure that exceptions do not silently override new risk information.
Failure policy must be explicit
What happens if the engine times out, the data feed is unavailable or the downstream system cannot receive the decision? A vague promise of high availability does not answer these questions. Each failure mode requires a controlled response consistent with the institution’s policy.
Possible responses include holding activity, routing to an alternative service or invoking a documented manual process. The choice depends on transaction type and risk. The system should not silently release transactions because a technical component failed.
Test degraded operation and recovery. A backlog may accumulate during an outage; clearing it can produce a second overload. Retried messages need stable identifiers so the same payment is not processed inconsistently. Audit records should survive the incident and allow the institution to reconstruct which decisions were made under degraded conditions.
Figure 03 · Conceptual framework
What happens when the screening service fails?
How the parts connect
- Screening dependency unavailablePath APermitted controlled continuity
- Screening dependency unavailablePath BRisk requires a hold
- Permitted controlled continuityReviewAuditable recovery
- Risk requires a holdReviewAuditable recovery
A meaningful proof of concept
Use a version-controlled test set containing representative transactions, known positives, difficult variants and challenging negatives. Agree how the labels were established and preserve a separate validation set. Suppliers should not tune exclusively to the examples used for final acceptance.
Test data normalisation, matching, policy action, investigation and evidence as one chain. Include peak volumes, list updates, component failure, retry behaviour and recovery. Compare total investigation effort alongside detection, because a marginal improvement in matching can still create a large operational burden.
The historical expanded briefing proposed weighting detection effectiveness at 25% and performance/resilience at 20%, with other weights for intelligence, integration, workflow, governance and economics. These are source procurement suggestions, not universal rules. Mandatory control failures should not be offset by a high score elsewhere.
Commercial comparisons should include the full service
Traditional arrangements may combine licences, throughput or volume charges and annual maintenance. The sources mentioned maintenance around 18–22% of licence value in some cases. Cloud services may charge by records, checks, active customers or capacity. These measures are not directly comparable without a common workload.
Add risk-data subscriptions, implementation, interfaces, historical retention, model tuning, parallel operation, infrastructure and analyst effort. A low unit screening fee may produce a high cost per resolved case if matching quality is poor. A high-performing engine can still be uneconomic if integration and operating responsibilities are underestimated.
Model the volume curve. Peaks, batch rescreening, new jurisdictions and longer retention can change the cost materially. Contract terms should address data access, update commitments, service boundaries, incident support and exit evidence.
Market-size estimates are not interchangeable
The historical research assembled screening-related market estimates ranging from about USD 1.36 billion to USD 3.1 billion for different base years and definitions, with forecasts extending into the 2030s. It also quoted a separate incremental-growth estimate for a broader period. These are not observations of one consistently defined market.
One estimate may include screening software, another wider sanctions compliance and another services. Regional shares and cloud shares can also use different populations. Averaging the figures would create false precision. The useful conclusion is that demand was expected to grow, while the exact revenue pool depended on scope.
For procurement, the more actionable question is which operating costs and control failures the proposed service changes. A market forecast does not establish that a particular supplier meets the institution’s requirements.
The historical value-migration call
The earlier study argued that value and margin were moving away from basic matching engines toward higher-quality risk data and contextual analytics. It also expected established platforms to retain their core system-of-record role while some incremental spending moved to entity resolution, AI-assisted review and new detection capabilities. This was a forecast of gradual pressure around the edges, not a prediction of immediate incumbent displacement.
The argument remains historical and conditional. Better matching, explainability and reliable high-volume operation can still be valuable. Public-list aggregation may become easier to reproduce, while maintaining accurate contextual intelligence and defensible evidence remains difficult. The buyer should therefore distinguish the part of a service that is becoming more substitutable from the part that still solves a demanding control problem.
This distinction also changes negotiation. A bank might retain a core engine while replacing a data source or adding an analytical layer. It should test whether the new component improves the complete decision, not simply whether it produces more signals. Extra context can increase false confidence if identity matching is weak or the investigation process cannot interpret it.
The source did not disclose reliable product-level margins for every supplier. The direction-of-value thesis should therefore not be converted into an exact margin forecast. Its practical contribution is to make the buyer examine where the differentiated capability actually sits.
The decision standard
Retain the test configuration with the result. Matching thresholds, list versions, data cleaning and hardware can all affect performance. A supplier’s improved score is not comparable with its earlier score if those conditions changed without documentation. The institution needs to know which improvement came from the product and which from the test design.
The complete screening service should produce an explainable decision within the required time, using the correct information and policy, while remaining controlled under failure. Product names are an unreliable shortcut to that capability. A risk dataset, a specialist engine and a broad monitoring suite can coexist because they solve different parts of the problem.
The buyer should preserve those distinctions, test the whole path and retain evidence of the trade-offs. That produces a more credible decision than a universal vendor ranking or an unqualified promise to reduce false positives.
