Part of our complete guide to negative news screening for Swiss banks. This post is the deep dive on transaction monitoring vs negative news screening; the guide covers the end-to-end picture.
Two systems, two budgets, two vendor categories, and the same word in both: "monitoring". The conflation costs procurement teams real money. A bank shopping for transaction monitoring sometimes ends up running a proof of concept against a screening tool, or vice versa. The reverse also happens: a compliance team that needs better screening evidence buys a transaction monitoring upgrade that does not solve the problem.
This post separates the two cleanly, identifies where they actually hand off to each other, and is honest about where NNSFlow sits in that picture.
Two different problems
Transaction monitoring answers: of the millions of payments flowing through this institution today, which ones look anomalous enough to investigate?
Negative news screening answers: for this specific entity, in front of me right now, what does the open record say about them, and how do I capture that record so the decision is defensible in five years?
The first is statistical, ongoing, and operates on data the bank already owns. The second is investigative, event-driven, and operates on data the bank does not own (news archives, registries, sanctions lists, web search). The systems built to solve them look different because the problems are different.
Transaction monitoring: ongoing pattern detection
A transaction monitoring system ingests the bank's own payment data (SWIFT, SIC, internal ledgers, card flows) in close to real time. It applies rules and statistical models to flag payments that fit one of several anomaly patterns: structuring just below reporting thresholds, sudden velocity changes, geographic risk patterns, round-amount sequences, atypical counterparty behaviour, and so on. The output is an alert, attached to a transaction or a small cluster, sitting in a queue for an analyst to triage.
The regulatory hook in Switzerland is the Anti-Money Laundering Act (AMLA / GwG, SR 955.0), in particular Article 6 on the special duties of clarification. AMLA Art. 6 requires financial intermediaries to clarify the economic background and purpose of a transaction or business relationship when it appears unusual (unless its lawfulness is clear) or when there are indications that assets stem from a crime, are linked to a criminal organisation, or serve the financing of terrorism. The clarification duty in Art. 6 is the legal target an institution's monitoring function is sized against.
The FINMA Anti-Money Laundering Ordinance (AMLO-FINMA, SR 955.033.0) operationalises the monitoring expectation: every institution has to maintain a system that detects increased-risk transactions and business relationships, calibrate its parameters to its actual risk profile, and document the calibration. FINMA's Risk Monitor returns to monitoring quality almost every year as a recurring focus of supervisory attention.
The shape of a monitoring system is therefore:
- Data source: the institution's own transactional data, ingested continuously.
- Cadence: ongoing. Alerts surface within hours of the underlying transaction in a well-tuned setup.
- Output: alerts on transactions or transaction clusters.
- Vendor category: Actimize, FircoSoft, SAS, Hawk:AI, ThetaRay, Quantexa, ComplyAdvantage, and similar names. The category is established, the systems are heavyweight, and they own a substantial budget line.
Monitoring is necessary but not sufficient. An alert by itself does not satisfy AMLA Art. 6. The clarification work happens after the alert lands.
Negative news screening: event-driven investigation
A negative news screening (NNS) system takes a specific entity, at a specific moment, and produces a captured, defensible record of what the open record said about that entity at that time. The trigger is usually an event: onboarding a new client, a periodic review, a regulatory request, or a transaction monitoring alert that needs Art. 6 clarification (more on the handoff below).
The data the NNS system operates on is not the bank's own data. It is third-party content: web search results (often via a SerpAPI-type provider), commercial news archives, court records, registries, sanctions lists, PEP lists, and adverse media databases. The output is not an alert. The output is an evidence record (snapshots, hashes, analyst notes, structured decision rationale) that has to survive a ten-year retention floor under AMLA Art. 7 and meet the reconstruction bar under AMLO-FINMA Art. 22. Our breakdown of Swiss AML evidence rules goes through what those obligations actually require in practice.
The shape of an NNS system is therefore:
- Data source: third-party content fetched at investigation time, captured as snapshots not links.
- Cadence: event-driven. An investigation runs from minutes to a few days, not continuously.
- Output: an evidence record (snapshots, annotations, structured reasons, four-eyes approval, audit log).
- Vendor category: this category is messier. Some institutions build it themselves, some use tools intended for adjacent purposes (e-discovery, OSINT), some buy adverse media data feeds without a workflow on top, and a smaller number buy a purpose-built NNS platform. NNSFlow is in the last group.
The regulatory hook for NNS specifically is the same Art. 6 clarification duty (the output of monitoring) plus the evidence obligations: AMLA Art. 7 (retention), AMLO-FINMA Art. 22 (reconstruction by a knowledgeable third party), and FINMA Circular 2023/1 Ch. IV.D (data integrity and availability for critical AML data). Substance and citations in our Swiss AML evidence rules post.
Where they overlap: the handoff
The cleanest mental model is that monitoring detects and screening clarifies. Most institutions run them as two separate systems with a defined handoff in between.
The most common handoff path:
- The transaction monitoring system raises an alert on, say, a counterparty payment that fits a high-risk pattern.
- An analyst triages the alert. If the alert needs Art. 6 clarification (most non-trivial ones do), the analyst opens an investigation in the screening / case management system, referencing the alert ID and the entity in question.
- The screening system runs its searches, captures evidence, and produces a structured record (decision, reason codes, four-eyes approval, audit log).
- The decision flows back: the alert is closed in the monitoring system with a reason that points at the screening case ID, and the screening case is locked and archived under the bank's retention policy.
The same handoff happens in reverse less often, but it does happen: adverse news on an existing client triggers a screening investigation, which surfaces a question about transaction history, which gets answered by going back into the monitoring system and the bank's own ledgers. (Our four-eyes approval architecture post covers how the approval step itself sits in the screening side of the handoff.)
The handoff is the integration point that matters for procurement. Three things have to be right for it to work:
- Alert intake: the screening system has to accept an alert reference (alert ID, monitoring system, alert reason) and store it with the investigation. Otherwise the audit trail breaks at the handoff.
- Entity reference: both systems need to point at the same entity. Inconsistent client-master IDs are where this falls apart in practice; a 2024 acquisition target is one entity in the monitoring system and three entities in the screening system. Resolving that takes work.
- Audit trail across both records: an examiner asking "why did this alert close" has to be able to walk from the alert, to the screening case, to the captured evidence, to the four-eyes approval, to the final decision, without a missing link. If the link from alert to case is informal (an email, a Jira ticket), the reconstruction obligation under AMLO-FINMA Art. 22 starts to fray.
Where they don't overlap: data, cadence, audit trail
Despite the workflow handoff, the systems are not fungible. The table below summarises the substantive differences.
| Dimension | Transaction monitoring | Negative news screening | | --- | --- | --- | | Data source | Bank's own transactional data | Third-party content (web, news, registries, lists) | | Cadence | Ongoing, near real-time | Event-driven, per-investigation | | Output | Alert on a transaction or cluster | Evidence record on an entity | | Detection mode | Statistical / rules-based | Search + analyst judgement | | Storage shape | High-volume time-series + alert queue | Per-investigation snapshots and annotations | | Audit trail | Alert lifecycle + tuning history | Evidence chain + four-eyes approval | | Primary regulatory hook | AMLA Art. 6 (clarification trigger) | AMLA Art. 7 + AMLO-FINMA Art. 22 (retention + reconstruction) | | Reportable upstream | SAR / MROS report under AMLA Art. 9 | Same SAR pathway, but originating from the investigation record |
Two practical consequences of the differences:
Volume profiles are opposite. Monitoring systems are sized for millions of transactions a day and tens of thousands of alerts a year. Screening systems are sized for hundreds to low thousands of investigations a year, each with deep evidence per case. A vendor that demos beautifully on one volume profile can be wrong for the other.
Audit trails do not interchange. A monitoring system's audit trail is about why this alert was raised, how the model was tuned, who closed it, and on what reason code. A screening system's audit trail is about what evidence was captured, by whom, what they concluded, who approved the conclusion, and what state the evidence was in at write-time. The evidence-chain post covers the write-time integrity story specifically. The two trails serve different parts of the same examination.
What this means for tooling decisions
Three rules of thumb that hold up in procurement:
Buy monitoring and screening as separate systems, integrated by contract. The handoff is a contract: alert ID, entity ID, decision return path, audit-trail join key. Specifying that contract carefully is more valuable than buying a single vendor that claims to do both. Single-vendor "all-in-one" platforms tend to do one of the two well and the other as a thin add-on; the add-on is usually the one that will not survive an examination.
Score vendors on the integration, not just the feature list. The question to ask a screening vendor is not "do you do screening?". It is "what does your alert intake look like, what entity-resolution guarantees do you give, and how does your audit trail join to my monitoring system's?". The question to ask a monitoring vendor is roughly the mirror image.
Keep the audit-trail identifier stable across the handoff. If your monitoring alert ID is the join key, lock its format and lifetime before you sign either contract. Migrating either system later will break the join unless this is in place from day one. (The same principle applies to vendor migrations more broadly, covered in our vendor due diligence post.)
For institutions running an air-gapped or no-egress deployment (Swiss private-bank profile), the integration question gets more pointed: the screening system has to be able to operate without internet egress, or with strictly controlled egress, or the air-gap story breaks at the first investigation. Our air-gap deployment post covers the failure modes specifically.
Bottom line
Transaction monitoring and negative news screening are different products solving different problems with different data and different audit trails. They share a workflow handoff and a regulatory parent (AMLA), and they get conflated in procurement because both involve the word "monitoring". They should be evaluated separately, bought separately, and integrated through a documented handoff contract.
NNSFlow is on the screening side of that handoff. The product is a negative news screening and investigation evidence platform: it accepts an entity (with optional alert context), runs the searches, captures the evidence with write-time integrity, walks an analyst through a structured investigation, takes the four-eyes approval, and produces a record built to AMLA Art. 7 retention and AMLO-FINMA Art. 22 reconstruction standards. It does not ingest payment flows, it does not run anomaly detection, and it does not replace a transaction monitoring system. We integrate with one; we are not one.
If you are mid-procurement and trying to draw the line between the two, we are easy to reach. The honest answer about which side of the line a particular requirement falls on is more useful than a vendor pitch that pretends the line is not there.
