Payment screening and transaction monitoring are entirely separate controls addressing two different types of risk, and treating them as if they were the same, or assuming that one implies the other, is a frequent and costly error. Payment screening checks a transaction against sanctions lists and other watchlists before it is carried out, to prevent a prohibited payment from taking place. According to the Wolfsberg Group’s own guidance on sanctions screening, transaction screening “should be carried out at a point in time when a transaction can be stopped and before a possible breach occurs, certainly before any commitment to move funds is made.” Transaction monitoring is a distinct and continuous process: it examines patterns in a customer’s transaction history after transactions have settled, to detect activity that looks like money laundering even when no single transaction matches a list.
An institution can have a good screening programme and a poor or nonexistent monitoring programme, or the reverse, and each gap results in a different kind of risk. On payment systems that settle irreversibly and in real time, the difference ceases to be merely theoretical.
Ask a compliance team whether they check payments and keep an eye on transactions, and the usual answer is that they do both. Ask what each control specifically picks up, on its own, without reference to the other, and the answers become considerably less precise. That imprecision is typical and it is expensive, because these are in fact different controls, designed to detect genuinely different things and operating at genuinely different stages in a transaction’s lifecycle.
Payment screening runs before a transaction executes and poses a specific, focused question: does this transaction involve a party or jurisdiction we’re required to check against, and if so, halt it. Transaction monitoring runs after a transaction has been carried out and is based on patterns; it poses a broader question, whether activity viewed over time, in the context of what’s known about the customer, looks like money laundering, and by the time an alert fires, the transaction under review has usually already settled. Buying a tool built for one does not give an institution the ability to detect the other. A sanctions screening tool without behavioural monitoring will never identify structuring, layering, or a legitimate-looking account used as a mule, since none of those appear on a watchlist. A transaction monitoring system without real-time screening will eventually flag a suspicious pattern, but by then the specific payment that caused concern is already gone. On instant payment rails, “already gone” isn’t a metaphor. It’s the actual, irreversible state of the funds.
What payment screening actually does
Sanctions screening, per the Wolfsberg Group, an association of major global banks, compares an institution’s customer and transaction data against lists of sanctioned persons, organisations, and places to identify matches. Within that wider category, transaction screening looks at the movement of value specifically, aiming to catch a banned payment while it can still be halted.
Wolfsberg is explicit about timing: transaction screening “must be carried out at a point in time when a transaction can be halted and before a possible breach occurs,” with emphasis on happening “before any commitment to transfer the funds is made.” For cross-border payments, Wolfsberg’s Payment Transparency Standards treat real-time screening, checking a payment against sanctions lists before completion, as common and well-established practice.
It’s intentionally a limited kind of control. It compares specific data fields, names, addresses, bank identifiers, routing details, against specific reference lists. It does not assess whether a transaction fits a customer’s usual behaviour, whether it’s part of a broader pattern, or whether it’s consistent with what the institution knows about that customer’s business. Those are different questions, and payment screening isn’t built to answer them. It answers one question, fast enough to act on the answer before the money moves.
What transaction monitoring actually does
Transaction monitoring asks a different question, on a different timeline, usually from different data. Screening compares a transaction against a fixed list; monitoring compares a customer’s activity against a pattern, whether the customer’s own historical behaviour, known money-laundering typologies, or both, and looks for deviations worth investigating. Wolfsberg’s guidance on monitoring, screening and searching treats these as related but distinct disciplines, framing monitoring as the need “to carry out appropriate monitoring of transactions and customers in order to detect potentially unusual or suspicious activity and transactions, and to report them to the relevant authorities,” an objective that differs from list-matching and, by nature, looks at activity over time rather than at a single transaction.
Structuring shows why this has to be a separate control. A transfer of ₱49,500 has no name on it that would appear on any sanctions list; it’s a completely ordinary, legal transaction. Only when a system looks at a person’s overall behaviour does the pattern become visible: the same amount, just below a threshold, repeatedly sent to related accounts within a short window. Because payment screening, by definition, checks each transaction against a single list, it has no way to detect a pattern that only emerges across many transactions viewed together.
The tradeoff is timing. Because monitoring assesses a pattern rather than checking a fixed list, it generally can’t act before a transaction completes, and its alerts arrive after settlement, sometimes long after. That’s exactly why relying on it as a substitute for pre-transaction screening produces a specific, foreseeable gap.
Why institutions end up with one and assume they have both
The confusion tends not to come from ignorance, but from how these systems get purchased. In vendor evaluations, “AML capability” is often treated as a single line item, with screening and monitoring features shown together in one demo. The institution ends up confident that the platform does something related to sanctions compliance and something related to detecting suspicious activity, without a clear, independently verified understanding of what each function actually covers, where its boundaries lie, or what falls outside both.
Real overlap in the underlying data makes this worse. Both controls typically draw from the same transaction feed, use similar alert interfaces, and report to the same compliance team. From the outside, screening and monitoring can look like two views of the same system, when in fact they’re two entirely different controls, answering two different questions, over two different time horizons.
The practical result only becomes apparent during an examination, not at the time of procurement. When an examiner asks specifically how an institution detects a sanctioned party attempting a transaction, versus how it detects a legitimate-looking customer involved in a laundering pattern, they’re asking about two different controls. An institution that can clearly explain only one, while believing it has covered both, has a deficiency it didn’t know existed until someone asked the more specific question.
Where the gap becomes irreversible
Batch-era payment processing gave screening and monitoring a certain amount of cover. A payment made in the afternoon might not settle until the next night’s cycle, so there were sometimes hours of delay before funds actually moved, and a monitoring alert issued the next morning could still, in some systems, be looking at a transaction that could be reversed or held.
Real-time payment systems remove that delay entirely. In 2025, InstaPay, the Philippines’ real-time payment service, handled 4.7 billion transactions, about 12.9 million a day or 149 every second, and for transfers up to ₱50,000 it cleared and settled them finally and irreversibly, with no overnight period and no batch cutoff. Once a transfer completes, the money has actually moved; there’s no end-of-day reconciliation step that can quietly hold back a flagged transaction. Other real-time infrastructure, including UPI in India, FedNow in the United States, and SEPA Instant in the Eurozone, runs on the same principle: settlement finality achieved in seconds.
The distinction between screening and monitoring stops being theoretical and becomes something that has to be dealt with in practice. When payment screening isn’t genuinely real time, or covers fewer transaction types than the institution believes, a sanctioned or listed party can complete a transfer before it’s checked. When transaction monitoring is the only mechanism catching structuring or layering, the alert arrives after the funds have settled, and often after they’ve moved again. Neither failure is hypothetical. Both are the direct, foreseeable result of treating two controls as if they were one.
Closing the gap
The two controls need to run separately and continuously, each doing the job the other can’t. Fyscal Arcx’s Name Screening module runs real-time checks at onboarding and at the point of transaction against sanctions, PEP, and adverse media data, a pre-execution control acting inside the transaction window rather than after it, in line with what Wolfsberg recommends. Its Transaction Monitoring module runs on its own and in parallel, watching for patterns across a customer’s transaction history, structuring, layering, aggregation across linked accounts and time windows, that a single-transaction screening check can’t see. Because both modules draw on the same underlying case and customer data, an alert from one carries the context the other has already established, so an analyst isn’t reconciling two separate systems to understand a customer relationship. Neither module replaces the other, and neither claims to. That’s the argument this piece has made throughout: an institution needs both controls, each working to its own logic, not one system doing two jobs under one name.