Listen To Our Podcast🎧
What is the difference between transaction screening and transaction monitoring?
Transaction screening checks a payment for sanctions risk while the institution can still stop it. The Wolfsberg Group's guidance on sanctions screening says it should run at a point where a transaction can be stopped and before a potential violation occurs. Transaction monitoring looks across transactions, customer behaviour and customer attributes for activity that may be suspicious, usually after one or more payments have already happened. You need both, because they answer different questions at different points in the payment lifecycle.
The difference shows up in system design. A sanctions check that runs only after settlement cannot prevent the payment. An AML monitoring rule that blocks every unusual payment in real time turns a pattern-detection control into a blunt payment filter. In both cases the control objective should set the data, the timing, the action and the person accountable for the decision.
This guide is for MLROs and Heads of Payments deciding where each control belongs. It covers a boundary model, the EU instant payments rule that moved part of sanctions screening off the payment itself, an architecture, test cases and metrics. It draws on Wolfsberg Group guidance, OFAC guidance, EBA guidelines and Regulation (EU) 2024/886 as they stood on October 14, 2026. It is a practical reading of those texts, not legal advice.
- Separate the two control objectives.
- Place each control in the payment lifecycle.
- Apply the EU instant payments rule correctly.
- Test alerts and evidence handoffs.
- Measure each control on its own scorecard.
Request a transaction screening walkthrough
Transaction screening checks a payment for sanctions risk while it can still be stopped. Transaction monitoring looks across transactions and customer behaviour for suspicious activity, usually after payments happen. For in-scope euro instant credit transfers, EU law replaces the per-transaction targeted-sanctions check with customer verification at least daily. You need both controls, each with its own evidence and human decision.
How do the two controls divide the work?
We use a four-stage model to keep the two controls apart: stop, observe, investigate and decide. Each stage has one job and one owner.
- Before settlement, the payment instruction passes through Transaction Screening while it can still be held, rejected or returned. A possible match goes to a sanctions analyst, who decides whether the payment is released, rejected or escalated. A settled payment still reaches Transaction Monitoring as part of the customer's wider activity. Transaction Monitoring opens an investigation when a pattern needs one, and the investigation goes to the MLRO or an authorised investigator, who records the disposition and any next action within delegated authority. The four-stage model is stop, observe, investigate and decide; each stage has one job and one owner.
The payment instruction passes through Transaction Screening while it can still be held, rejected or returned under applicable rules and institution policy. A possible match from Transaction Screening goes to a sanctions analyst, who decides whether the payment is released, rejected or escalated.
A settled payment still reaches Transaction Monitoring as part of the customer's wider activity. Transaction Monitoring reviews transactions and customer activity over time and opens an investigation when a pattern needs one. The investigator connects the alert to customer, counterparty, account, device and prior-case evidence. The investigation goes to the MLRO or an authorised investigator, who records the disposition and any next action within delegated authority.
Both controls need a human decision point, but the time available and the legal consequence differ. This is a FluxForce editorial framework. It is not a legal standard, and it does not replace the rules that apply to your institution, payment rail or jurisdiction.
What is transaction screening?
Transaction screening is a sanctions control that checks payment data against approved lists and related rules. Wolfsberg describes it as screening used to identify transactions involving targeted individuals or entities. It is distinct from customer or name screening, which looks for targeted individuals or entities during onboarding and over the life of the relationship.
The control examines the fields present in a payment message or connected record. Wolfsberg notes that party names matter for list-based sanctions programmes, addresses matter for geographic programmes and help separate true matches from false ones, and bank identification codes can matter for both. Amounts, dates and transaction reference numbers have no screening relevance. Depending on the payment type and your risk assessment, the fields to screen may include:
- originator and beneficiary names, including the remitter and beneficiary;
- agents, intermediaries and the banks involved, with their BICs and other routing codes;
- addresses, countries, cities and other geographic terms;
- vessels, including IMO numbers, and trade parties where relevant;
- free-text fields such as the payment reference or the stated purpose of the payment; and
- other data your policy or an applicable rule requires.
Its defining feature is that it can still act. Wolfsberg tells institutions to focus screening at a point in the transaction where detecting a sanctions risk is still actionable to prevent a violation, and certainly before any commitment to move funds is executed. Screening cross-border payments before completion is common practice and is what Wolfsberg calls screening in real time. Wolfsberg also says real-time screening of domestic payments may be unnecessary for institutions subject to the same local regulatory requirements, including local sanctions and KYC rules when onboarding clients.
In the EU, the EBA guidelines on restrictive measures, which apply from 30 December 2025, say that PSPs should screen transfers of funds before making the funds available to the payee, except in the instant-payment cases covered by Article 5d. They also say PSPs should screen all parties to a transfer against applicable restrictive measures. The design question is therefore where your institution can still handle a sanctions concern lawfully and operationally, rather than whether every payment gets a real-time screen.
Screening also depends on what the message carries. The Wolfsberg Payment Transparency Standards note that an intermediary bank can only be expected to screen in real time the information included in the message. Address data needs to be good enough to identify the location of the parties for sanctions screening and for AML monitoring.
A screening alert is not proof that a payment is prohibited. OFAC's FAQ on assessing name matches, last updated on September 9, 2026, notes that many potential matches identified through screening are false positives. It recommends that organisations assess all the information available and make a risk-based decision about the match under their own policies, risk profile and any applicable regulator guidance. For list, match and review design in more depth, see our sanctions screening guide.
What is transaction monitoring?
Transaction monitoring analyses activity for signs that may need an AML or financial-crime investigation. The EBA's ML/TF risk factors guidelines say an effective monitoring system relies on up-to-date customer information and should let the firm reliably identify unusual and suspicious transactions and transaction patterns. Monitoring looks for things a single payment screen cannot see: money moving rapidly through several accounts, activity that does not fit the customer's profile, linked counterparties, structuring or a change in behaviour.
It can run in real time, after the fact or both. The EBA asks firms to decide which transactions they will monitor in real time and which they will monitor ex-post. As part of that, firms decide which high-risk factors, or combinations of them, will always trigger real-time monitoring. Firms with high transaction volumes should consider an automated monitoring system, and every firm should review flagged transactions without undue delay. Some patterns only become meaningful after several events, which is why so much monitoring runs after the payment has gone.
The Wolfsberg Group treats transaction monitoring as one part of a wider practice it calls monitoring for suspicious activity (MSA). In its statement on effective monitoring for suspicious activity, it explains that it chose the broader term because customer behaviour and attributes, considered together with transactions, give better insight into potentially suspicious activity. Wolfsberg calls transaction monitoring a sub-set of MSA, which might also include ongoing customer due diligence. It also says the input data should include transactional data, customer static data and internal reference lists, plus behavioural information such as device ID and IP address where that is proportionate to the risk.
That is why an AML investigation usually needs more than a payment message. It needs the customer profile, ownership, prior alerts, counterparties and some account of why the activity changed. Our guide to payment transaction monitoring covers how those scenarios work across payment activity.
A monitoring alert is not a legal conclusion either. It is a prompt to investigate. The MLRO or an authorised investigator decides whether the facts support escalation, account action or a report through the institution's approved process.
How do transaction screening and transaction monitoring compare?
The two controls differ in objective, timing and decision path.
| Question | Transaction screening | Transaction monitoring |
|---|---|---|
| Primary objective | Detect sanctions or prohibited-party risk in a payment | Detect suspicious activity and financial-crime patterns |
| Unit of analysis | Payment message, parties and related transaction fields | Transactions plus customer, account and relationship context over time |
| Typical timing | Before settlement, or before the point where the payment can no longer be stopped | During or after activity, depending on the scenario and the action |
| Common trigger | Possible name, entity, identifier or geography match | Rule, model or investigator signal showing unusual behaviour or a known typology |
| Immediate action | Hold, reject, return or route for review under policy | Open an alert, investigate, monitor more closely or apply an approved intervention |
| Human owner | Sanctions analyst, payment operations and sanctions officer | AML investigator, financial-crime team and MLRO |
| Evidence needed | Payment fields, list entry, identifiers, match rationale and disposition | Customer profile, transaction history, counterparties, linked alerts and findings |
| Failure if misplaced | The payment settles before anyone reviews the match | A pattern goes unseen, or ordinary activity is blocked without enough context |
The same payment can touch both. A cross-border transfer can pass sanctions screening because no valid match exists, then contribute to a monitoring alert because it is one leg of a rapid pass-through pattern across linked accounts.
Where does each control stop a payment?
Transaction screening is built to reach a decision while the payment can still be stopped. Transaction monitoring can support a pre-payment intervention, but only when the scenario, the data and your policy justify it. Our piece on real-time sanctions screening for payments covers the pre-settlement control in more detail.
- The payment instruction moves to data validation, where the institution checks format, authority and the data available. After data validation, Transaction Screening checks the relevant payment fields against approved sanctions data and passes its result to the payment policy route, which decides whether the payment can proceed, needs an analyst or must be held. The payment policy route sends the payment to settlement, rejection, return or hold, depending on the result and the rail. After settlement, Transaction Monitoring analyses the event with wider history and connected activity. A confirmed match leads to an immediate freeze and a stopped transfer under the EBA guidelines, and a technical failure needs a defined fail-safe route.
A practical payment path has five handoffs:
- The payment instruction moves to data validation, where the institution checks format, authority and the data available.
- After data validation, Transaction Screening checks the relevant payment fields against approved sanctions data.
- Transaction Screening passes its result to the payment policy route, which decides whether the payment can proceed, needs an analyst or must be held.
- The payment policy route sends the payment to settlement, rejection, return or hold, depending on the result and the rail.
- After settlement, Transaction Monitoring analyses the event with wider history and connected activity.
The screening result should never bypass policy. A low-confidence match may need an analyst. A confirmed match needs the response your sanctions procedure and the applicable law require. Under the EBA guidelines, when a PSP's analysis confirms the match is a designated person or entity, the PSP should immediately freeze the funds and stop the transfer. A technical failure needs a defined fail-safe route. OFAC's framework for compliance commitments expects internal controls that can identify, interdict, escalate, report where appropriate and keep records of activity that may be prohibited. Write down who can release, reject or escalate a payment and how the reason is recorded.
Monitoring needs its own action map. Some alerts open a case after settlement. Some lead to closer observation. A smaller set may support a hold or a customer contact before settlement, where the institution has defined authority, enough evidence and a rail that allows it.
A shared vendor interface should not erase this line. One product can run both controls and still keep separate objectives, data, thresholds, queues and decision records.
Key insight: the question to ask of any screening design is "where is the last point we can still stop this payment, and does the check run before it?" The question for monitoring is different: "what context do we need to see the pattern, and who acts on it?" Mixing the two questions is how institutions end up with screens that run too late and monitoring rules that block too much.
What changes for euro instant payments?
For euro instant credit transfers, EU law has moved part of sanctions screening off the individual payment. Regulation (EU) 2024/886 added Article 5d to the SEPA Regulation, Regulation (EU) No 260/2012. It requires payment service providers (PSPs) that offer instant credit transfers to verify whether any of their payment service users (PSUs) are persons or entities subject to targeted financial restrictive measures.
- Each new or amended EU listing triggers PSU verification immediately, and the PSP repeats that verification at least once every calendar day. The stated aim of the PSU checks is to stop listed persons initiating instant credit transfers and to freeze funds sent to their accounts immediately. During execution of an instant credit transfer, the payer's and payee's PSPs must not run that targeted-sanctions check on the payer or payee on top of PSU verification. The instant credit transfer still reaches transaction monitoring, because the ban leaves Union AML and counter-terrorist-financing duties in place. Other restrictive measures, national measures and transfers outside the euro instant rule keep the screening model your policy and applicable law require. Confirm product scope with sanctions counsel.
Each new or amended EU listing triggers PSU verification immediately, and the PSP repeats that verification at least once every calendar day. During the execution of an instant credit transfer, the payer's PSP and the payee's PSP must not run that targeted-sanctions check on the payer or payee on top of the PSU verification. Article 5d says PSPs had to comply by 9 January 2025.
The recitals explain why. Transaction-based screening flagged a very high number of credit transfers, and the large majority of flagged transactions turned out not to involve listed persons or entities. Because of the nature of instant credit transfers, PSPs could not verify those flags within the short time limit, so the payments were rejected. The stated aim of the PSU checks is to stop listed persons initiating instant credit transfers and to freeze funds sent to their accounts immediately. The EBA reads the first subparagraph of Article 5d(2) as prohibiting the screening of SEPA instant payment transactions against the EU targeted financial sanctions list.
There is a narrow exception worth knowing. The EBA cites a European Commission clarification: where a listed person is named in the payment details and the PSP cannot check those details through its daily screening of its own clients, checking the payment details for that purpose is not prevented by Article 5d(2).
Three limits matter for control design:
- The rule covers targeted financial restrictive measures, meaning asset freezes and bans on making funds available. Other restrictive measures fall outside that obligation. The ban on the per-transaction check is without prejudice to actions PSPs take to comply with national restrictive measures and with EU measures that are not targeted financial sanctions.
- The same ban is without prejudice to Union law on the prevention of money laundering and terrorist financing. The instant credit transfer still reaches transaction monitoring, because the ban leaves Union AML and counter-terrorist-financing duties in place.
- The recital ties the obligation to PSPs sending or receiving instant credit transfers in euro. For other transfers of funds, the EBA guidelines still expect screening before the funds are made available to the payee. Wires, card payments and payments in other currencies keep whatever screening model your policy and applicable law require.
In practice, for this payment type the stop point moves from the transaction to the customer record. Your screening design has to show that the PSU checks run daily and on every list change, that the payment flow does not add the prohibited per-transaction check for in-scope payments, and that the AML monitoring and other sanctions controls still run. Confirm the scope for your own payment products with sanctions counsel.
Why can screening pass while monitoring alerts?
A sanctions screen can correctly clear a payment that is suspicious for another reason. Screening looks for transactions involving targeted individuals or entities. Monitoring looks at customer behaviour and attributes alongside transactions to find activity that may be suspicious.
Four examples:
- A beneficiary has no sanctions match but receives similar transfers from many unrelated customers and moves the funds out within minutes.
- A customer sends several payments just below an internal review threshold to connected counterparties.
- A mostly dormant account starts sending cross-border transfers through new routes.
- Several customers share a device, address or beneficiary network, and the pattern only appears when their activity is connected.
None of these proves money laundering. They show why a one-payment list check cannot replace monitoring.
The reverse also holds. Monitoring may see ordinary behaviour while a new designation creates a screening issue the next morning. The EBA expects PSPs to set trigger events when customer screening must always take place, and a new or changed designation is one of them. Sanctions lists need their own update, testing and escalation controls. OFAC has seen organisations fail to load SDN List updates into their screening software, leave out identifiers such as SWIFT Business Identifier Codes, or miss alternative spellings of prohibited countries or parties.
Why can't monitoring replace sanctions screening?
Monitoring is not a safe substitute for a control that has to act before funds move. A pattern may appear too late, and the monitoring data may not include every sanctions-relevant field in the payment message.
Sanctions review also has its own match problem. The analyst compares names and identifiers, works out whether the listed party is the party in the payment, checks any relevant licence or exemption, and follows the sanctions procedure. OFAC does not confirm potential matches or false positives for organisations. It expects them to make risk-based determinations.
A defensible sanctions review records:
- the exact list source and its version at the time of screening;
- every payment field that contributed to the alert;
- the matching and the conflicting identifiers;
- why the alert was cleared or escalated;
- the person, or the approved rule, that made the disposition; and
- the final payment action and its timestamp.
These records support testing and audit. OFAC describes audits as checking for inconsistencies between documented processes and day-to-day operations. Good records also help you find repeat false matches. Wolfsberg describes suppression rules or "Good Guys" lists as one way to manage common false positives, and expects a documented rationale for risk-based decisions such as screening rules. A suppression rule without that rationale can hide a true match.
OFAC's identify, interdict, escalate, report and keep records sequence is a useful checklist for the screening side. The exact design still has to follow the laws and supervisory expectations that apply to you.
How should alerts move between teams?
Screening and monitoring should share evidence without collapsing into one queue. The receiving team needs the original purpose of the alert, the source data and the decision already made.
- A screening case that ends in a release passes its evidence, match rationale and reviewer decision to the monitoring case when the counterparty matters to an AML pattern. When an investigation turns up a previously hidden party, intermediary, vessel, location or alias, the investigator sends it for sanctions screening. The monitoring case goes to the MLRO, who decides whether the combined evidence warrants further action or a report. Information from closed case investigations and SAR/STR filings then feeds back into the monitoring platform. Each handoff should carry the evidence, match rationale, timestamps and reviewer decision along with the alert status.
A screening case that ends in a release passes its evidence, match rationale and reviewer decision to the monitoring case when the counterparty matters to an AML pattern. That handoff also makes sense when repeated spelling or routing changes suggest someone is trying to evade the screen, when several counterparties share identifiers that only show up across cases, or when the same customer generates repeated alerts across different payment types.
The handoff runs the other way too. When an investigation turns up a previously hidden party, intermediary, vessel, location or alias, the investigator sends it for sanctions screening. The monitoring case goes to the MLRO, who decides whether the combined evidence warrants further action or a report. Information from closed case investigations and SAR/STR filings then feeds back into the monitoring platform, which Wolfsberg suggests as a way to help detect future risk.
Send the evidence, match rationale, timestamps and reviewer decision along with the alert status. If the second team gets only a status, it has to rebuild the case and may misread why the first control acted. For how sanctions screening and SAR filing share data pipelines, see our piece on where AML sanctions screening overlaps with SAR filing.
How should you tune each control?
Tune screening for match quality and sanctions risk. The EBA puts the screening trade-off plainly: calibration should be neither so sensitive that it causes a high number of false positive matches nor so insensitive that designated persons go undetected. Tune monitoring for typology coverage, investigative value and customer impact. Do not force one threshold philosophy onto both.
For Transaction Screening, review:
- field coverage by payment type;
- list selection and update latency;
- transliteration, aliases and identifier handling;
- alert quality by field and by list;
- suppression rules and their documented rationale;
- decision time against the rail's action point; and
- release, reject and escalation records.
For Transaction Monitoring, review:
- the purpose and risk statement behind each scenario;
- data completeness and time order;
- alert-to-case and case-to-report outcomes;
- activity missed in quality testing;
- customer friction caused by interventions;
- investigator handling time; and
- whether case feedback changes future detection.
A high alert count does not show that a control works, and a low one does not show that it fails. Wolfsberg notes that common monitoring metrics such as typology coverage, alert and case volumes, alert productivity and alert-to-SAR/STR ratios focus on the quantity rather than the usefulness of the information provided. Start testing from defined risks and labelled cases. Then check whether the control found the right activity in time and gave the reviewer enough evidence.
Keep separate scorecards for the two controls, and do not publish vendor or internal performance figures without a fixed population, period, definition and reviewer. Compare products on the same test cases before you compare their claims.
What should implementation teams test?
Test the two controls separately, then test the handoff between them.
- The screening test set uses exact, close and false matches, aliases, changed spellings, missing fields, non-Latin names, geographic terms, stale lists and outages, plus euro instant PSU verification tests. The monitoring test set uses time-ordered activity covering ordinary behaviour, known suspicious patterns, sparse history and connected accounts. Results from both feed the shared workflow tests, which check queue ownership, duplicate alerts, evidence transfer, overrides, audit history, rollback and the kill switch. The shared workflow tests go to governance review, where compliance, payments and technology owners look at the results together. Governance review approves thresholds, automated routes and kill-switch procedures before production rollout.
Transaction Screening test set
Use payments with exact matches, close matches, false matches, aliases, changed spellings, missing fields, non-Latin names, geographic terms and stale-list conditions. Add outage and delayed-update tests, and confirm what the payment system does when the screening service returns no answer. For euro instant credit transfers, add tests that show PSU verification runs after each list change and that no per-transaction targeted-sanctions check runs on in-scope payments.
Transaction Monitoring test set
Use time-ordered customer activity covering ordinary behaviour, known suspicious patterns, sparse history, connected accounts, new counterparties, rapid movement, closed alerts and confirmed cases. Stop future information leaking into earlier decisions. The EBA also expects firms to run regular ex-post reviews on a sample of all processed transactions, whatever their level of automation, to spot trends and to test and improve the monitoring system.
Shared workflow tests
Results from the screening test set feed the shared workflow tests, and so do results from the monitoring test set. Check queue ownership, duplicate alerts, evidence transfer, maker-checker controls where required, overrides, audit history, privacy access, rollback and the kill switch. Confirm that a screening release does not suppress a later monitoring alert, and that a monitoring alert does not quietly change a sanctions disposition.
The shared workflow tests go to governance review, where compliance, payments and technology owners look at the results together. Governance review approves thresholds, automated routes and kill-switch procedures before production rollout.
- Screen a payment before the last point it can still be stopped.
- Monitor patterns across activity, customers and context, usually after the payment.
- For in-scope euro instant credit transfers, verify customers daily and on every list change instead of screening each payment.
- Keep sanctions and AML queues, thresholds and decision records separate.
- Your sanctions analyst or MLRO keeps the defined decision.
Conclusion
Start with the payment lifecycle, not the software menu. Mark the last point where each payment type can still be stopped, then put Transaction Screening before it, or, for in-scope euro instant credit transfers, on the customer record at least daily and on every list change. Work out what activity and context you need to see suspicious patterns, then place Transaction Monitoring where it has enough evidence to do that job.
The test is the same for both. Each control should find the risk it owns, act within the time it has and leave a record an authorised reviewer can defend to an examiner. If you are weighing how much of the screening queue an agent should handle, our Transaction Screening page shows how holds, releases and list versions are recorded.
Request a transaction screening walkthrough
Frequently Asked Questions
About the author
Sahil Kataria
Founder and CEO of FluxForce
Share this article