Screening vs Transaction Monitoring

Screening and transaction monitoring are often placed next to each other in a bank's financial-crime architecture, but they do not answer the same question and they should not be designed as if they do. Screening generally compares a person, organisation, payment party, vessel, location, goods description or other data element against reference information or defined restrictions. Transaction monitoring generally evaluates activity, relationships and behaviour to identify patterns that may warrant review for money laundering, terrorist financing, fraud, proliferation financing or other financial-crime concerns.

That distinction is useful, but it is not an absolute global rule. Banks use the words screening and monitoring differently. Some firms call continuous customer rescreening "ongoing monitoring". Some describe real-time payment scenarios as transaction monitoring even when they can intervene before execution. Some screening platforms incorporate behavioural or network signals, while some monitoring platforms consume sanctions, PEP or adverse-media indicators as contextual features. The safest way to distinguish the controls is therefore not by the software label but by the question being asked, the authority behind the decision, the data used, the timing required and the outcome that can lawfully follow.

A second distinction is equally important. A screening alert is not the same as a confirmed sanctions match, and a monitoring alert is not the same as suspicion. Alerts are prompts for review. A sanctions-screening alert may ultimately be a false positive, a true identity match that is outside the relevant prohibition, or a match requiring an action under applicable law. A transaction-monitoring alert may close with a reasonable explanation, lead to a broader investigation, contribute to a suspicious transaction/activity report where the local legal threshold is met, or support some other risk-management action. Treating every alert as a legal conclusion is one of the fastest ways to create customer harm and poor control evidence.

FATF provides the global AML/CFT framework, including ongoing customer due diligence and scrutiny of transactions under Recommendation 10, suspicious transaction reporting under Recommendation 20, targeted financial sanctions under Recommendations 6 and 7, and separate enhanced measures for politically exposed persons under Recommendation 12. Those standards are implemented through national or regional law and supervisory frameworks. The operational consequence for a bank therefore depends on the legal entity, jurisdiction, sanctions regime, product, payment route and facts. OFAC requirements in the United States, UK financial-sanctions rules, EU restrictive measures and other national regimes cannot simply be collapsed into one universal blocking rule.

A practical mental model

The simplest mental model is to ask five questions.

What is the control trying to discover? Screening usually asks whether a subject is the same as, connected to, or captured by reference information or a restriction. Transaction monitoring usually asks whether activity or relationships are unusual, inconsistent with known information, or indicative of a risk scenario.

What evidence does it need? Screening often relies heavily on identity attributes, aliases, dates of birth, registration numbers, addresses, ownership information, vessel identifiers, list metadata, programme scope and transaction-party data. Monitoring often relies on transaction history, customer profile, peer behaviour, counterparties, channels, devices, products, geographies, velocity, sequence, value and network relationships.

When must the decision be made? Some payment screening is synchronous because a bank must determine whether a transaction can proceed before execution. Customer screening may occur at onboarding, on periodic or event-driven rescreening, or when lists change. Transaction monitoring can be batch, near-real-time, streaming or pre-execution depending on the risk and product. There is no safe universal rule that "screening is real time and monitoring is after the event".

Who has authority to decide the outcome? A screening analyst may resolve identity and applicability, but legal interpretation, sanctions escalation or specialist approval may be required for difficult cases. A monitoring analyst may close or escalate an alert, but suspicious reporting, account restriction, exit or disclosure decisions often sit with separate authorised roles under local policy and law.

What can lawfully happen next? A sanctions case may lead to release, rejection, blocking/freezing, reporting or another treatment depending on the applicable regime and facts. PEP or adverse-media findings normally inform risk assessment and enhanced due diligence rather than operate as sanctions prohibitions. Monitoring may lead to closure, enhanced investigation, requests for information, enhanced due diligence, scenario feedback, suspicious reporting where the legal threshold is met, or consideration of restrictions through a separately governed process.

That five-question model is more reliable than trying to memorise product labels.

Screening is broader than fuzzy name matching

Name matching is the most visible part of screening, but a mature screening control has several layers. First, the bank must know what reference data or restriction it is implementing. For sanctions this can include official designation data, programme metadata, aliases and identifiers. For customer risk processes it may include PEP data, internal watchlists or adverse-media sources. These data sets are not legally equivalent. A sanctions designation may create a legal prohibition or asset-freeze obligation under an applicable regime; a PEP classification generally triggers enhanced risk management and due diligence; adverse media is information that requires assessment of reliability and relevance.

Second, the bank must decide which customer, account, party or transaction fields are in scope. Customer screening may involve the customer, beneficial owners, controllers, directors, authorised signatories and other connected parties according to policy and law. Payment screening may involve debtor and creditor names, agents, addresses, remittance information, ultimate parties or other message elements where relevant. Trade-related screening can involve vessels, ports, goods descriptions and counterparties. The correct field set depends on the product and the applicable control, not on a universal list of fields.

Third, the bank must resolve identity. A similar name is not enough. Reviewers may need dates of birth, nationality, address, registration number, passport or national identifier, vessel IMO number, corporate ownership or other attributes to distinguish the person or entity. Fuzzy matching helps find candidates despite spelling variation, aliases and transliteration, but similarity scores are only part of the evidence.

Fourth, where a true identity relationship is established, the bank must assess applicability. A listed person can be relevant differently under different regimes. Ownership and control rules differ. Sectoral restrictions may prohibit certain activities without requiring a full asset freeze. Licences, exemptions or authorisations may apply. The relevant legal entity and jurisdictional nexus matter. A global bank therefore needs programme-aware decisioning rather than a single sanctioned=true flag.

Transaction monitoring is broader than threshold rules

Transaction monitoring is also frequently oversimplified. A rule such as "cash deposit above X" is only one possible detection technique. Monitoring can combine customer-profile expectations, velocity, transaction sequences, peer comparisons, counterparty networks, product behaviour, geography, device information, merchant data, payment references, risk indicators and previous investigations. The purpose is to identify activity that merits examination, not to prove criminality automatically.

FATF's ongoing due-diligence framework expects financial institutions to scrutinise transactions through the course of the relationship so that activity is consistent with what the institution knows about the customer, the customer's business and risk profile, including source of funds where necessary. How a bank implements that expectation depends on its risk, products, size, data and local regulatory framework. FATF does not prescribe one vendor, one algorithm or one universal set of thresholds.

A good monitoring control therefore begins with a risk hypothesis. What behaviour would matter, and why? Which data would show it? At what point would it become unusual enough to review? What legitimate behaviour can look similar? Which customers or products need different calibration? What evidence should an analyst see? What outcome is the control intended to support? Those questions produce more defensible scenarios than copying generic thresholds across all segments.

Monitoring can operate at different speeds. A monthly scenario may be appropriate for some long-horizon typologies. A streaming scenario can be appropriate for rapid mule activity or instant-payment fraud. A pre-execution control may use behavioural intelligence to delay or challenge a payment. None of those timing choices changes the fundamental need to define the legal and operational authority for the resulting action.

Screening, PEP checks and adverse media are not the same control

Banks frequently place sanctions, PEP and adverse-media checks in one screening platform. That is operationally convenient, but the outputs should not be treated as legally equivalent.

Sanctions screening is intended to help identify exposure to restrictions imposed by relevant authorities. Where a legal prohibition applies, the bank must follow the applicable regime's requirements, which may include asset freezing, blocking, rejection, reporting or other measures. The precise action cannot be inferred from a name hit alone.

PEP identification supports the enhanced risk measures required under AML/CFT frameworks. FATF Recommendation 12 requires additional measures for foreign PEPs and risk-sensitive treatment of domestic/international-organisation PEPs as implemented locally, including senior-management approval and reasonable measures concerning source of wealth and source of funds in relevant cases. PEP status is not itself evidence of wrongdoing and should not be represented as a sanctions designation.

Adverse media can identify information relevant to customer risk, investigations or enhanced due diligence. Its value depends on source credibility, recency, relevance, identity resolution and whether allegations have been substantiated. A weak article about a person with a common name should not be allowed to produce the same operational consequence as an official designation.

A well-designed case interface therefore shows the type of alert, source, authority or provenance, identity evidence, risk meaning and permitted decision path. This prevents a reviewer from treating every red banner as the same kind of fact.

Timing: design from the decision deadline

Timing should be derived from the control objective rather than from the label screening or monitoring.

For an outbound payment that must be checked before execution, the screening service may have milliseconds or seconds within the payment-orchestration path. The architecture needs latency budgets, timeout behaviour, high availability, queue management and a safe degraded-mode strategy. The bank must decide in advance what happens if the screening service is unavailable; simply "failing open" or "failing closed" without legal, scheme, operational and customer-impact analysis is not a sound design.

For customer rescreening after an official list update, the bank needs controlled ingestion of the new data, validation, activation, prioritisation and rescreening of relevant populations. The expected implementation speed depends on applicable law, supervisory expectations, risk and the nature of the change. Claims such as "all lists must be loaded intraday everywhere" should be avoided unless that requirement can be tied to a specific regime or policy.

For transaction monitoring, timing should reflect the typology. Rapid pass-through mule activity may need near-real-time detection. Structuring may require aggregation across days. Trade-based laundering can require documents and transaction history over a longer period. Private-banking concerns may emerge from changes over months. A monitoring programme that uses one processing cadence for every risk will either create unnecessary noise or detect important activity too late.

Data architecture: common sources, different uses

Screening and monitoring often rely on the same core banking and payment data, which creates a strong case for shared data quality and lineage even when the decision logic remains distinct.

Customer master data can provide legal name, trading name, previous name, date of birth, incorporation date, nationality, country of registration, identifiers and addresses. Beneficial-ownership data connects legal entities to natural persons and other corporate owners. Payment messages provide debtor, creditor, agents, amount, currency, purpose, remittance and identifiers. Channel systems can provide device, session and authentication signals. Trade systems add goods, vessel, port and document information. Case systems add previous alerts, investigations and decisions.

Screening typically needs stable identity resolution and current reference data. Transaction monitoring needs accurate histories, timestamps, relationship context and consistent event semantics. Both controls can fail because of the same upstream defect. If a customer name is truncated in a channel, sanctions screening may miss a candidate while monitoring loses a reliable entity key. If beneficiary identifiers are not carried across payment transformations, a network scenario may fragment one counterparty into several apparent parties. If ownership data is stale, customer screening and network analysis can both misrepresent risk.

For a business analyst or architect, this is why data lineage is a control requirement rather than documentation decoration. The design should show source system, business meaning, transformation, normalisation, enrichment, control use, decision output and retention. It should also define what happens when a required field is missing or unreliable. A control that silently replaces missing data with blanks and still reports "screened successfully" creates false assurance.

Matching and entity resolution

Screening engines usually combine exact and approximate techniques. Exact identifiers can provide strong evidence where the identifier itself is reliable. Names require handling of spacing, order, punctuation, aliases, transliteration, cultural naming patterns and spelling variation. Corporate names introduce legal suffixes and trading names. Vessels may change names or flags while retaining persistent identifiers such as IMO numbers.

A match score should be interpreted as a technical measure of similarity, not as a legal verdict. Thresholds determine which candidates are presented for review, and tuning them creates a trade-off between missed candidates and review volume. The right threshold depends on the data, population, language, list quality and bank risk. Testing should include known positives, challenging transliteration examples, common-name negatives and data-quality edge cases.

Entity resolution is equally important in transaction monitoring. The same beneficiary may appear through multiple accounts, aliases or identifiers. Without resolution, a bank can miss network concentration and split velocity across artificial identities. But over-aggressive resolution can merge unrelated people and create false network suspicion. Both disciplines therefore need confidence scores, evidence and reversible decisions rather than hidden deterministic merges.

Ownership and control

Ownership illustrates why screening and monitoring must interact.

A customer may not itself appear on an official list, but a relevant owner or controller may create sanctions implications under the applicable regime. The bank needs verified ownership information, effective dates and the correct legal test. Ownership thresholds and control concepts are not globally identical, so architecture should not hard-code one percentage as a universal rule.

Monitoring can help reveal relationships that static KYC data misses. Payments to connected entities, shared contact details, common devices, common counterparties or repeated fund flows can indicate that the declared structure no longer explains the observed network. Those findings do not automatically create a sanctions conclusion. They can, however, trigger KYC refresh, ownership investigation or specialist sanctions review.

The reverse handoff also matters. A confirmed ownership or sanctions finding can enrich transaction monitoring so that investigators can assess connected accounts, historical activity and network exposure. The control objective is not to merge the two functions but to ensure that important intelligence crosses the boundary with provenance intact.

From alert to case: preserve semantics

Many banks use a common case-management platform for screening and monitoring. That can be efficient if the workflow preserves the meaning of each alert.

A screening alert should capture what was screened, the reference source, list version, matching fields, score or rule, candidate record and any contextual attributes used for identity resolution. The reviewer should record whether the alert is a false positive, unresolved potential match, confirmed identity or another policy-defined outcome, followed by applicability assessment where required. The final payment/customer action must be supported by the relevant legal or policy basis.

A transaction-monitoring alert should capture the scenario, triggering transactions, lookback period, customer profile, relevant risk factors and the reason the activity exceeded the detection logic. Investigation should test plausible explanations, gather additional evidence and document why the activity is or is not suspicious under the applicable framework. A suspicious transaction/activity report should be filed only when the local reporting threshold and governance requirements are met.

The terms hit, match, alert, case, suspicion, block, freeze, reject, restriction and report should therefore have defined meanings. Using them interchangeably is dangerous. A dashboard that counts "matches" but actually includes unresolved algorithmic candidates can materially misstate sanctions exposure. A monitoring metric that calls every alert "suspicious" can misrepresent the purpose of the control and contaminate downstream decisions.

Consequence design: separate detection from authority

One of the strongest design principles in financial-crime systems is to separate detection from authority to act.

Screening may generate a candidate in milliseconds, but the action depends on identity, programme scope, ownership/control, jurisdiction and any applicable licence or exemption. Some regimes require funds or economic resources to be frozen where the relevant legal conditions are met. Other restrictions prohibit only particular activities. Some transactions may be rejected rather than blocked under a specific regime. The system should therefore expose the applicable authority and decision reason instead of translating every positive screening event into the same status.

Transaction monitoring similarly detects activity that needs review; it does not automatically authorise account closure or freezing. A bank may have contractual, regulatory or risk-management rights to restrict services in particular circumstances, and separate fraud or legal authorities can permit urgent interventions. Those decisions should be governed explicitly. The existence of an AML alert alone should not be presented as the legal basis.

This separation protects customers as well as the bank. It reduces wrongful restrictions, makes escalation transparent and creates an audit trail showing not merely that the system raised a concern but why the institution took the action it did.

How the controls hand off

The strongest programmes treat screening and monitoring as connected controls with explicit handoffs.

A sanctions investigation can identify accounts, counterparties or historical transactions that require broader network review. A monitoring investigation can uncover an undeclared beneficial owner or associated entity that should be rescreened. Fraud teams can identify mule accounts whose counterparties merit AML review. KYC refresh can reveal a new director or controller requiring screening. Adverse-media review can identify allegations that change customer risk and monitoring intensity without creating a sanctions prohibition.

Each handoff should answer four questions: what fact is being transferred; how reliable is it; what does the receiving team need to do; and how will completion be evidenced? Without those fields, "refer to sanctions" or "send to AML" becomes an operational dead end.

Shared case links are useful, but copied conclusions are not. A monitoring investigator should be able to see that sanctions screening confirmed a particular identity and understand the source, while still applying the monitoring team's own test to behavioural evidence. A sanctions reviewer should be able to see ownership facts discovered by an AML case without treating the AML suspicion itself as proof that a restriction applies.

Practical example 1: a payment name alert

A corporate customer sends a cross-border payment to a new supplier. The beneficiary name is similar to a designated entity, and the payment-screening engine generates an alert.

The first task is identity resolution, not an assumption that the payment is prohibited. The reviewer compares the candidate's identifiers, address, country, registration details and aliases with the payment information and any customer-supplied evidence. If the beneficiary is clearly a different entity, the alert can be closed as a false positive according to policy, with enough evidence to support future suppression where appropriate.

If identity remains plausible, specialist escalation may be needed. If identity is confirmed, the bank assesses the applicable sanctions regime, jurisdictional nexus, ownership/control issues, payment purpose and any relevant licence or exemption. The final action follows that analysis and the law applicable to the bank.

Transaction monitoring may still be relevant even if the sanctions alert is false. The new supplier, unusual corridor or payment pattern could be inconsistent with the customer's expected activity. That would be a separate behavioural question with separate evidence and outcome.

Practical example 2: rapid pass-through activity with no screening match

A newly opened personal account receives credits from multiple unrelated parties and rapidly sends most funds onward to several beneficiaries. None of the parties matches a sanctions list or internal watchlist.

Screening has done exactly what it was designed to do: no relevant reference-data candidate was identified. That does not mean the activity is low risk. A monitoring scenario can identify the velocity, many-to-one and one-to-many pattern, short holding period, new-account context and deviation from expected use.

An analyst reviews the transactions, customer profile, counterparties, device information and any known scam or mule intelligence. The activity may have a legitimate explanation, or it may justify escalation. If suspicion meets the applicable local reporting threshold, a SAR/STR process can follow. If fraud intelligence indicates imminent customer harm, separate fraud controls may intervene more quickly. The absence of a screening match does not reduce the need to understand the behaviour.

Practical example 3: a PEP customer

A prospective customer is correctly identified as a politically exposed person. That result should not be treated as a sanctions hit.

The bank applies its PEP framework: identify the relevant PEP relationship, perform the enhanced measures required by applicable law and policy, understand source of wealth and source of funds where required, obtain relevant approvals and establish appropriate ongoing monitoring. The customer's transactions may later be monitored more closely because the risk assessment justifies it.

If the same individual is also designated under a sanctions regime, that is a separate fact requiring sanctions analysis. Keeping the two facts separate in the data model prevents a PEP status from accidentally triggering a blocking workflow and prevents a sanctions designation from being diluted into ordinary enhanced due diligence.

Practical example 4: instant payment with behavioural risk

A customer initiates an instant payment to a new beneficiary shortly after a device change. The beneficiary account has recently received funds from several customers who reported scams. There is no sanctions match.

A bank may use behavioural fraud or AML intelligence before execution to challenge, warn, delay or reject the transaction where the product rules, legal framework and bank authority permit. That is still a form of monitoring or decisioning, despite occurring in real time. The example shows why timing alone cannot define the boundary.

The design must make clear whether the intervention is driven by fraud prevention, AML risk management, sanctions, scheme rules or another authority. The customer message should correspond to the actual reason where disclosure is permitted. Internal records should preserve the distinction because later complaints, investigations and regulatory reviews may depend on it.

Monitoring scenario design and tuning

A monitoring scenario should have a traceable rationale from risk to data to decision. A useful design record explains the typology or risk hypothesis, target population, required fields, calculation logic, lookback period, thresholds or model features, exclusions, alert content, review steps and intended outcome. It should also document known limitations.

Threshold tuning should use evidence rather than alert-volume targets alone. Lowering thresholds simply to create more alerts can overwhelm analysts without improving risk coverage. Raising thresholds only to meet a service-level target can suppress genuine risk. Tuning should consider alert quality, investigation outcomes, missed-risk testing, customer segments and operational capacity together.

Model-based monitoring adds governance needs around training data, explainability, validation, drift, bias and change control. A model score should not become an unexplained proxy for suspicion. Investigators need enough information to understand why activity was surfaced and to test alternative explanations.

Screening tuning has a different emphasis. The bank needs to understand false-positive rates, missed-match risk, transliteration performance, field quality, list coverage and suppression governance. A suppression rule should be specific enough that a future change in identifying information can re-open the comparison instead of permanently hiding a genuinely changed risk.

Testing: prove the control, not only the code

Testing should demonstrate that each control works from source data through final outcome.

For screening, positive tests can use controlled test records representing exact matches, aliases, transliterations, partial data and ownership cases. Negative tests should include common names and legitimate near matches. List-update testing should prove that new data is ingested, activated and applied to the intended population. Payment testing should cover all relevant message paths, including repairs, returns, retries and transformed messages where fields can be lost.

For transaction monitoring, testing should confirm population completeness, scenario calculations, time windows, aggregation, thresholds, peer-group assignments and alert content. Back-testing and targeted lookbacks can help assess whether known examples would have been detected. Negative testing should prove that legitimate high-volume or unusual-but-explainable behaviour is not systematically converted into excessive alerts.

End-to-end tests should also cover handoffs. If monitoring discovers a new beneficial owner, can the KYC and screening processes receive the fact and rescreen? If screening identifies a true designated relationship, can investigators find connected historical activity where policy requires it? If a reference feed fails, is the outage visible? If a monitoring feed is late, does the system report incomplete coverage rather than silently processing partial data?

For business analysts, acceptance criteria should be written in business outcomes rather than only technical responses. "API returns HTTP 200" is not enough. The criterion should state which party fields were screened, against which effective list version, what decision was produced, how the reviewer sees the evidence and how the downstream payment status reflects the approved disposition.

Metrics that should not be mixed

Both controls need management information, but blended metrics can hide problems.

Screening metrics can include reference-data update status, screening coverage, alert volumes, potential-match ageing, true-match outcomes, false-positive rates, payment-hold duration, service availability and unresolved high-priority cases. These should be segmented enough to reveal list, business, corridor or system issues.

Monitoring metrics can include population coverage, scenario execution status, alert volumes, conversion to investigation, ageing, case quality, reporting outcomes, repeat alerts, data-quality exceptions and scenario performance. A low alert-to-SAR/STR conversion rate is not automatically bad; it may reflect a deliberately sensitive control, weak tuning or a change in risk. Interpretation matters.

Do not compare analysts simply on "alerts closed per hour" across both disciplines. A sanctions identity-resolution case and a complex laundering investigation are different units of work. Productivity targets that ignore complexity encourage superficial closures and can distort risk decisions.

Governance and three lines

First-line businesses and operations usually own important source data, customer journeys and payment processes. Financial-crime operations may perform screening and monitoring review. Second-line compliance or financial-crime risk functions set policy, interpret regulatory expectations, challenge control design and oversee effectiveness according to the bank's governance model. Internal audit provides independent assurance. Exact ownership varies by institution, but decision rights should be explicit.

Change governance matters because screening and monitoring depend on external and internal change. A new sanctions programme, change in ownership interpretation, new payment rail, new product, new customer segment, ISO 20022 migration, vendor upgrade or data-model change can alter control effectiveness. Change impact assessments should ask which fields, populations, rules, lists, scenarios, workflows and evidence stores are affected.

Regulatory change should be mapped to the legal entities and jurisdictions actually in scope. A U.S. OFAC change may be directly binding for some entities or transactions and relevant indirectly to others; an EU restrictive measure applies through EU law and its jurisdictional reach; UK requirements have their own legal basis. Global policy can set a common control framework, but local legal mapping must determine mandatory outcomes.

Failure modes worth looking for

A screening programme can fail even while the engine is technically available. The wrong parties may be screened. List updates may be delayed. Names may be truncated upstream. Ownership data may be stale. A fuzzy threshold may miss transliteration variants. Reviewers may close candidates without enough identity evidence. A valid licence may not be recognised. The case record may not show which list version was used.

Monitoring can fail through missing transactions, broken aggregation, stale customer profiles, thresholds copied across inappropriate segments, excessive false positives, backlog growth, poor case narratives or scenarios that never evolve as criminal behaviour changes. A scenario can also work technically while the upstream population excludes an entire product or legal entity.

Shared failures are especially dangerous. If customer identifiers are inconsistent, both screening and monitoring can fragment the same person. If case-management statuses are ambiguous, both teams can believe the other owns an escalation. If change governance treats a payment-field migration as purely technical, both controls can lose critical data simultaneously.

The strongest control environment therefore tests not only engines but interfaces, ownership, data lineage, decision authority and operational capacity.

Mini case study: one payment, two different questions

Consider a medium-sized manufacturer that has banked with the institution for six years. Its expected activity is domestic procurement plus occasional European supplier payments. It initiates a large payment to a newly added overseas supplier.

At payment screening, the beneficiary's name produces a candidate against a sanctions record. The screening process examines identity attributes and determines that the supplier is not the listed entity: different registration number, different address, different ownership and a documented commercial history. The payment is released from the sanctions hold. That is a screening outcome.

Separately, transaction monitoring notices that the payment is far larger than the customer's previous cross-border activity, goes to a new corridor, follows two recent incoming transfers from unrelated companies and is described with unusually vague remittance text. Those facts do not make the payment prohibited. They justify understanding whether the behaviour fits the customer's business.

The investigator reviews invoices, counterparties, customer profile, funding sources and prior activity. The manufacturer provides a new distribution contract explaining the commercial change, but one incoming funder is unrelated to the transaction and cannot be explained adequately. The investigation expands to that counterparty network. Depending on the resulting evidence and local law, the case may close, trigger enhanced due diligence or reach the suspicious-reporting threshold.

The important lesson is that the sanctions false positive did not "clear" the AML risk, and the AML concern did not turn the supplier into a sanctions match. One payment generated two legitimate control questions with different evidence and potentially different outcomes.

What good looks like

A mature bank can explain the screening-monitoring boundary without relying on product names. It knows which risks each control addresses, which populations and fields are covered, which authorities govern final actions, where data comes from, how alerts are investigated, how handoffs work and how effectiveness is tested.

Its systems preserve provenance. A reviewer can see why an alert was created, what reference data or scenario version was used, which facts supported the decision, who approved the outcome and what happened downstream. PEPs, adverse media, sanctions and behavioural alerts are distinguishable even when they share a case platform.

Its architecture supports different timing needs without turning them into dogma. Synchronous payment controls are fast because the product requires speed. Long-horizon monitoring can aggregate patiently because the typology requires history. Real-time behavioural controls exist where risk justifies them. Customer rescreening can be triggered by events and list changes. No team assumes that one clock defines an entire discipline.

Most importantly, the bank understands that detection is the start of a decision, not the decision itself. Screening candidates require identity and applicability analysis. Monitoring alerts require investigation. Legal and customer actions follow the applicable authority and evidence. Keeping those stages clear makes controls more accurate, easier to test and easier to explain to regulators, auditors, customers and the bank's own technology teams.

References and further reading

• Financial Action Task Force (FATF), The FATF Recommendations: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
• Basel Committee on Banking Supervision, Sound management of risks related to money laundering and financing of terrorism: https://www.bis.org/bcbs/publ/d505.htm
• Wolfsberg Group, Sanctions Screening Guidance: https://wolfsberg-group.org/resources/28/
• Wolfsberg Group, Statement on Effective Monitoring for Suspicious Activity, Part II: Transitioning to Innovation: https://wolfsberg-group.org/resources/202/
• European Banking Authority, Guidelines on internal policies, procedures and controls to ensure the implementation of Union and national restrictive measures: https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/anti-money-laundering-and-countering-financing-terrorism/guidelines-internal-policies-procedures-and-controls-ensure-implementation-union-and-national
• US Treasury Office of Foreign Assets Control, A Framework for OFAC Compliance Commitments: https://ofac.treasury.gov/media/16331/download?inline
• Federal Financial Institutions Examination Council, BSA/AML Examination Manual: https://bsaaml.ffiec.gov/manual

These sources should be read together with the law, sanctions programme, FIU reporting rules and supervisory guidance applicable to the bank's legal entity, customer, product and transaction. None of the references above creates one universal global workflow for screening or monitoring.

Operational deep dive: match engines, list governance and applicability review

The base chapter separates screening from transaction monitoring by control objective rather than by product label. This deep dive looks inside a screening pipeline and shows where technical matching ends and a bank's legal or policy decision begins. It is deliberately jurisdiction-neutral. Actual sanctions obligations, implementation deadlines, ownership and control tests, licensing rules and reporting duties must be mapped to the legal regime that applies to the bank and the activity.

Reference-data ingestion is a control in its own right

A screening engine cannot detect information it has not received. The first control layer is therefore reference-data governance: identifying authoritative sources, receiving updates, validating them, preserving effective dates and making approved versions available to the screening service. Official sources vary widely. Some authorities provide structured files and APIs; others publish web pages, notices or documents that vendors normalise into commercial feeds. A bank using a vendor feed still needs to understand the provenance of the data and how quickly material changes become operational.

The service-level expectation should be derived from applicable law, supervisory guidance, risk and the bank's operating model rather than from a universal claim that every designation must be loaded within the same number of minutes. What matters is that the institution has a documented process for identifying relevant changes, implementing them in a controlled way, detecting failures and escalating delays that could create sanctions exposure.

Useful controls include source reconciliation, file-integrity checks, record counts, rejected-record reporting, effective-date validation and independent confirmation that the production engine is actually using the intended version. A dashboard that says a list file was downloaded is weaker than evidence that the new records were parsed correctly, activated and applied to the relevant screening population.

Normalisation prepares data; it does not decide identity

Names arrive in different scripts, orders, abbreviations and transliterations. Organisations have legal suffixes, trading names and historic names. Addresses can be incomplete. Dates can be formatted differently. Screening systems therefore normalise information before comparing it: case folding, punctuation treatment, tokenisation, transliteration, alias expansion and field standardisation can all improve candidate generation.

Normalisation should be explainable and reversible enough for investigation. If a system transforms Muhammad, Mohammed and other variants into similar matching forms, the reviewer still needs access to the original bank data and the original reference record. Otherwise the transformation that helped detection can destroy the evidence needed to decide whether the parties are the same.

Transliteration deserves particular attention because one script can map to several Latin spellings. The correct response is not necessarily one globally low threshold. Banks normally need testing by relevant language, customer population and data quality. Known positive examples can test sensitivity; common-name negatives can test review burden. Changes should be controlled and measured rather than made simply to reduce alert volume.

Matching creates candidates, not legal conclusions

Exact comparison is valuable where reliable unique identifiers are available. Fuzzy or approximate techniques are useful where names or addresses vary. Modern screening systems often combine several fields and rules into a candidate score. Whatever technique is used, the score indicates similarity under the configured model. It does not by itself establish that the customer or payment party is the designated person, and it does not determine which legal consequence applies.

A practical review hierarchy starts with strong identifiers where available: registration numbers, document numbers, dates of birth, place of birth, nationality, address, ownership details and other attributes. A name-only candidate often needs more corroboration than a candidate supported by multiple independent identifiers. Conversely, one conflicting attribute should not always close a case automatically; the reliability of each attribute matters. A date of birth copied from an old source can be less reliable than a current official registration number.

The bank should document which attributes can support clearance, which require escalation and which are merely contextual. That prevents different reviewers from applying personal standards to the same evidence.

Identity resolution and applicability are separate decisions

This separation is one of the most important controls in sanctions operations.

Identity resolution asks whether the bank's subject is actually the same person, entity, vessel or other object as the reference record. Applicability asks what the relevant legal or policy framework requires if that identity or relationship is established.

The second question can be more complex than the first. A confirmed listed party may be subject to different restrictions under different programmes. Some measures require asset freezing; others restrict particular financing, securities, services or sectors. Ownership and control can extend restrictions to entities that do not themselves appear on a list, but the test differs across regimes. General or specific licences, exemptions and authorisations can change what is permitted. The bank's legal entity, currency, location, persons involved and payment route can all affect jurisdictional nexus.

A good case workflow therefore does not jump directly from match=true to block. It records identity evidence, relevant programme, legal basis, ownership/control reasoning where relevant, licence or exemption analysis, decision authority and final operational treatment.

Sanctions, PEP and adverse-media matching need different semantics

Many banks use one vendor or user interface for several screening types. The technology can be shared; the meaning should not be.

A sanctions candidate is assessed against a legal restriction and the implementing framework applicable to the bank. A PEP result identifies political exposure for AML/CFT risk management and enhanced measures; it is not a sanctions prohibition merely because it came from the same engine. Adverse-media results are information that must be assessed for identity, source quality, relevance and recency. Internal watchlists can serve several purposes and need their own governance, retention and appeal rules.

The case schema should preserve a field such as screening_type or equivalent so downstream systems never infer legal meaning from a generic alert status. Decision codes should also remain distinct. False positive sanctions candidate, confirmed PEP, adverse media relevant, and internal watchlist escalation are different outcomes and should not collapse into one match value.

Customer screening and payment screening use different moments

Customer screening can occur at onboarding, before activation, periodically, when material customer data changes, when reference data changes, or at other risk-based events. OFAC, for example, explicitly recommends a risk-based approach and recognises that frequency can vary with the organisation's business and sanctions risk. Other jurisdictions and supervisors have their own expectations.

Payment screening operates within payment processing and must be designed around the point at which a bank still has the ability and legal authority to act. For a real-time or instant rail, that may demand a very low-latency service and clear timeout behaviour. For a batch product there may be a different decision window. Correspondent payments can expose several institutions in sequence, each applying its own controls and legal obligations.

The design should show exactly where screening happens in the payment lifecycle: channel capture, payment hub, pre-booking, pre-release, correspondent gateway, clearing interface or another point. It should also show what payment status is used while a candidate is reviewed and how the transaction resumes or terminates after an authorised decision.

Rescreening needs effective dates and population control

When reference information changes, a bank may need to rescreen customers or other populations according to the applicable framework and policy. The rescreening design should answer:

• which population is in scope;
• which version of customer data is used;
• which reference-data change triggered the run;
• whether only changed records or the full population is processed;
• how potential matches are prioritised;
• how duplicate alerts are controlled without suppressing materially changed cases; and
• how completion is evidenced.

Effective dating is particularly important. An investigation may need to reconstruct what the bank knew on a historical date. Preserving list version, customer version, matching configuration and decision timestamp makes that possible.

Ownership and control require evidence, not a universal percentage

Screening a corporate customer only by legal name can miss exposure created through owners or controllers. The customer-data model should therefore preserve ownership relationships, percentages where relevant, control relationships, effective dates and evidence sources.

The legal test must be jurisdiction-specific. It is unsafe to encode one percentage threshold and describe it as the global sanctions standard. Some regimes have explicit ownership tests, some include control concepts, and aggregation approaches can differ. Difficult cases need legal or specialist interpretation supported by the underlying ownership graph.

Technology can assist by traversing ownership chains and identifying where a designated or restricted party appears. But the engine should return the relationship path and data used, not merely a red flag. Reviewers need to see why the entity was surfaced and which rule produced the result.

Vessel, aircraft and trade screening require domain identifiers

Maritime and aviation screening illustrates why name matching alone is insufficient. Vessel names and flags can change. Persistent identifiers such as an IMO number can provide stronger continuity where available. Ownership, operator, manager, flag, port calls and trade documentation can add context.

Behavioural indicators such as AIS gaps or ship-to-ship transfers can be useful risk signals, but they are not automatically sanctions violations. Legitimate operational explanations exist. Those indicators normally require corroboration with vessel identity, route, ownership, cargo, counterparties and the applicable restriction.

Goods screening is similarly contextual. A keyword appearing in an invoice does not establish that a controlled item is present or that a transaction is prohibited. Classification, destination, end user, end use, licensing and export-control rules may be relevant. Banks need processes that recognise the limit of their visibility rather than pretending a payment message contains technical product information it does not carry.

List-change surge management

Large designation packages can create operational surges. A resilient programme plans for them without assuming every alert can be processed identically.

Surge procedures can include additional reviewer capacity, priority rules for stronger identity candidates, specialist escalation availability, communication with payment operations and enhanced management information. Prioritisation must not change the substantive legal test. It should help the bank sequence work while preserving evidence and approval requirements.

Post-event review can compare volumes, ageing, disposition quality, false-positive patterns and any service degradation. The purpose is not to celebrate alert throughput but to determine whether control effectiveness held under stress.

Screening model testing

Testing should answer whether the control can find relevant candidates and whether operations can resolve them correctly.

Technical tests can cover exact identifiers, aliases, transliterations, reordered names, common-name negatives, punctuation, missing fields and changed customer data. Population tests can confirm that all intended customers, accounts, payment types or message paths are included. Reference-data tests can prove that updates move from source to production without silent record loss.

Operational tests should examine reviewer evidence, escalation, decision authority and downstream payment/customer status. A technically perfect fuzzy score is of little value if the case interface hides the date of birth needed to clear a false positive or if a release decision never reaches the payment engine.

Back-testing can use known listed records or controlled synthetic examples. Missed-match testing should be documented and fed into tuning. False-positive reduction should be treated as optimisation subject to sensitivity safeguards, not as a target that justifies lowering detection quality.

Boundary with transaction monitoring

The screening pipeline can enrich monitoring without replacing it. A confirmed sanctions relationship can prompt historical network analysis. Repeated screening false positives can identify data-quality problems. A monitoring investigation can discover an undeclared owner who should be screened. Fraud intelligence can identify counterparties that become internal watchlist candidates under governed criteria.

The handoff should preserve provenance. Monitoring should know whether it received a confirmed identity, a potential match or merely an adverse-media signal. Screening should know whether an ownership fact came from verified KYC evidence or an investigative hypothesis still being tested.

This discipline protects both controls from circular reasoning. A monitoring case should not treat a weak screening candidate as proof of criminal behaviour, then feed that suspicion back to screening as corroboration of the same candidate. Independent evidence must break the loop.

BA and architecture acceptance criteria

For a screening capability, useful acceptance criteria go beyond the API returns a result.

A test should prove that the correct subject fields were sent, the intended reference-data version was active, transformations were traceable, candidate evidence was visible, the reviewer could record identity and applicability separately, the authorised decision reached the downstream product, and the complete audit trail could be reconstructed.

Failure-mode criteria are equally important. What happens when the list feed is late? When the screening service is unavailable? When the case system cannot create an alert? When the payment times out? When a customer record lacks a mandatory identifier? The approved fallback should be explicit and tested under production-like conditions.

The final design principle is simple: matching is a detection service; legal applicability and customer or payment action are governed decisions. Keeping those stages separate makes screening safer, more explainable and easier to integrate with transaction monitoring without confusing the two disciplines.

Advanced practice: tuning both disciplines without conflating them

The base chapter and screening deep dive establish the boundary between reference-data screening and behavioural monitoring. This supplement focuses on tuning, capacity, metrics and outsourcing. The central rule is that neither discipline should be optimised by alert volume alone. Tuning must protect the control objective, reflect the applicable legal or regulatory framework and remain explainable to reviewers, model validators, auditors and supervisors.

Screening-threshold management

Screening thresholds influence how many candidate matches are presented for review. Lower thresholds may improve sensitivity but can create large false-positive populations; higher thresholds may improve precision but can miss spelling, transliteration or data-quality variants. The bank therefore needs evidence-based calibration rather than a single global score.

Useful test sets include known or controlled positive examples, common-name negatives, aliases, transliterations, reordered names, missing fields and identifier conflicts. Results should be segmented by relevant script, customer population, product and data source where those factors materially affect performance. A threshold that performs well on Latin-script retail names may perform differently on another population.

A missed candidate in a test is a control weakness to investigate; it should not automatically be described as a legal breach. Whether a real-world miss constitutes a violation depends on the applicable obligation, facts and jurisdiction. Likewise, a false positive is not merely an efficiency problem if it causes repeated payment delays or customer restrictions without adequate evidence.

Tuning governance should record the reason for the change, test population, before-and-after performance, approval, effective date and rollback plan. Large sanctions-list changes or sudden volume shifts may justify temporary operational measures, but emergency tuning should not silently become the permanent configuration.

Monitoring tuning and effectiveness

Transaction-monitoring tuning begins with the risk hypothesis. The bank should know which behaviour it intends to detect, which population is in scope and what legitimate behaviour can look similar. Alert conversion can be informative, but it is not a universal measure of effectiveness. A low conversion rate can reflect poor tuning, a deliberately sensitive scenario, weak customer segmentation, stale profiles or a change in underlying risk.

Scenario review should therefore combine several forms of evidence: alert quality, case outcomes, missed-risk or lookback testing, data coverage, customer segmentation, backlog effects, investigator feedback and known limitations. Where statistical or machine-learning models are used, validation should also address discrimination, calibration, stability, data drift, explainability and segment performance appropriate to the model's purpose.

Retiring a noisy scenario is safe only when the bank understands what risk coverage will replace it or why the risk no longer requires that control. Otherwise alert reduction can masquerade as improvement while creating an unmeasured detection gap.

Backlog and capacity

Backlogs matter because they delay risk decisions, but the correct service level depends on the control and product. A payment-screening queue associated with an executing transaction may need urgent review because the payment is waiting for a decision. A periodic customer-rescreening queue can have a different deadline. Transaction-monitoring cases can also vary widely: an urgent mule or fraud-linked pattern may need rapid review while a long-horizon typology may tolerate a longer investigation window.

Capacity models should therefore use workload by control type, complexity and timing rather than one average handling time. Useful inputs include arrival volume, peak patterns, reviewer skill, escalation demand, expected case complexity, payment-system operating hours, scenario cadence and known event surges.

Twenty-four-hour staffing is not a universal requirement for every screening team. It may be necessary where the bank operates products, payment rails or legal obligations that require continuous decisioning. Other institutions may use follow-the-sun teams, on-call specialists, automated holds or different operating windows. The design must match the service being controlled.

Queue prioritisation should be explainable. Payment cutoffs, strength of identifying evidence, customer impact, risk indicators and legal urgency can all matter, but a blended score should not obscure why one case was reviewed before another. Management information should make aged high-priority cases visible rather than showing only total backlog.

Metrics that respect the boundary

Screening metrics can include reference-data update status, population coverage, alert volume, false-positive patterns, unresolved potential matches, payment-hold duration, rescreening completion, service availability and data-quality exceptions. No single metric proves effectiveness. For example, reducing false positives is useful only if sensitivity remains adequate.

Monitoring metrics can include scenario execution status, population coverage, alert volumes, alert-to-case conversion, case quality, ageing, SAR/STR outcomes where relevant, repeat alerts, data-quality exceptions and scenario-review findings. Reporting rates should be interpreted cautiously because the threshold for suspicious reporting is a legal and investigative judgement, not a productivity target.

Boundary metrics are also valuable. These can measure alerts routed to the wrong workflow, handoffs awaiting action, customer-impacting decisions lacking the expected approval, or cases where the source control cannot be identified from the record. Such metrics reveal architecture and operating-model defects that separate screening and monitoring dashboards may miss.

Reviewer productivity without perverse incentives

"Alerts closed per hour" is a dangerous universal target. A simple false-positive screening candidate and a complex behavioural investigation are not comparable units of work. Even within one control, cases differ in complexity.

Productivity should be balanced with quality. Screening review can be sampled for identity evidence, correct reference data, applicability reasoning and final disposition. Monitoring review can be sampled for investigation scope, use of customer context, treatment of alternative explanations, escalation logic and narrative quality. Rework and overturned decisions can provide additional signals.

The aim is not to make analysts slow. It is to avoid incentives that reward easy closures, discourage escalation or encourage shallow narratives.

Outsourcing and vendor governance

A bank can outsource technology or operational activities, but accountability for compliance does not disappear simply because a vendor performs part of the process. Contracts and oversight should be tailored to the service.

For screening technology, due diligence can cover authoritative-source coverage, update handling, matching behaviour, transliteration support, service availability, security, change management, auditability and exit arrangements. For monitoring technology, focus can include scenario flexibility, data integration, model governance, investigation workflow, explainability, testing support and retention of historical evidence.

Operational outsourcing introduces reviewer competence, access control, confidentiality, quality assurance, escalation and business-continuity considerations. The bank should be able to reconstruct how an outsourced decision was reached and should retain sufficient control over material configuration and policy choices.

Bundling screening and monitoring under one vendor can be efficient, but the contract and architecture should still preserve separate service levels and decision semantics where required. A common outage affecting both controls is a concentration risk worth testing.

Shared data governance without logic merger

Identity, payment and relationship data can be shared safely when each control's needs are explicit. Screening may prioritise high-quality identity attributes and current reference data. Monitoring may need longer transaction histories, relationship networks and behavioural context. The same customer identifier can support both.

Change governance should assess both consumers. A normalisation change that improves screening matching could unintentionally remove information useful to monitoring. A monitoring enrichment that increases processing time should not be inserted into a synchronous payment-screening path without latency analysis.

Shared incident management is similarly important. If a payment feed loses beneficiary addresses, screening and monitoring can both be affected differently. The incident record should identify which controls lost which information, what compensating measures were used, how long the gap lasted and whether retrospective review is required.

Model and rule change control

Changes to thresholds, algorithms, scenarios, suppressions or list-handling logic should follow controlled release practices. A useful change record includes business rationale, risk assessment, test evidence, approver, affected populations, implementation date, monitoring plan and rollback criteria.

For screening, suppression rules deserve special care because they can permanently hide recurring candidates. A suppression should depend on stable differentiating attributes and should be invalidated when material identity data changes. For transaction monitoring, scenario exclusions deserve similar scrutiny because broad exclusions can create silent population gaps.

Production monitoring after release should look for unexpected shifts in volume, match distribution, alert quality or downstream case behaviour. A change that passed functional testing can still behave differently on live data.

Practical governance decision

Imagine a bank proposing one central "financial crime tuning committee" for both controls. That can work if the committee contains the right specialists and preserves separate decision criteria. The sanctions specialist should be able to challenge a name-matching threshold using list and identity evidence. The AML monitoring specialist should be able to challenge a scenario threshold using behavioural coverage and investigation outcomes. Data, technology, operations and model-risk representatives can provide shared oversight.

What should not happen is a single target such as "reduce alerts by 20 percent" being imposed across both disciplines without evidence that risk coverage is preserved. Volume reduction is an operational outcome, not a control objective.

The mature approach is to tune each control on its own terms, then govern the shared data, technology and capacity dependencies together. That produces efficiency without sacrificing the distinctions that make the controls defensible.

Practice close: checklists and acceptance criteria

This supplement converts the chapter into delivery artefacts for business analysts, architects, developers, testers and control owners. The objective is not to force screening and transaction monitoring into separate technology stacks. It is to prove that each control preserves its own purpose, evidence, authority and outcome even when infrastructure is shared.

BA checklist before accepting the design

Start with the control objective. For every alert type, the requirements should state what question is being asked. A sanctions-screening candidate needs identity and, where relevant, applicability analysis. A PEP result supports enhanced AML/CFT measures. An adverse-media result requires source and relevance assessment. A transaction-monitoring alert requires behavioural investigation. A generic requirement saying only "financial-crime alert will be reviewed" is not precise enough.

Define the population and data. Screening requirements should identify which customers, connected parties, payment fields, vessels, goods or other subjects are in scope and which reference sources are used. Monitoring requirements should identify the transaction population, customer profile, history, network, channel and enrichment data needed by the scenario or model. Shared data should have common lineage, but the business meaning used by each control should remain explicit.

Define timing from the product and obligation. A synchronous payment check needs a different service level from a periodic customer rescreening run. A rapid mule scenario needs a different monitoring cadence from a long-horizon trade-finance review. Avoid acceptance criteria that state "screening must always be real time" or "monitoring is always post-event".

Define decision authority. Requirements should distinguish alert generation, identity resolution, investigation, legal or policy applicability, suspicious reporting, customer restriction and payment action. The system should not infer authority from an alert colour or score.

Define outcomes with business meaning. Release, hold, reject, block/freeze, close, escalate, enhance due diligence, file report and restrict service should each have a defined owner and precondition under the bank's applicable framework. Not every institution or jurisdiction will use every outcome in the same way.

Useful acceptance criteria

Strong acceptance criteria are observable and traceable. Examples include:

• When a controlled sanctions test record is screened, the case shows the reference source, version, matched fields and original customer or payment data used for the comparison.
• When a reviewer clears a false-positive payment candidate, the authorised release reaches the payment engine and the audit trail records reviewer, time, evidence and decision reason.
• When a monitoring scenario fires, the case shows the triggering transactions, lookback period, scenario version and relevant customer profile rather than only a risk score.
• When an AML investigation discovers a new beneficial owner, the handoff to KYC/screening preserves the evidence source and relationship path; the receiving team records whether rescreening was performed.
• When a required feed is incomplete, the control reports a coverage exception rather than reporting successful processing of a partial population.
• When a reference list or scenario configuration changes, the effective version is reconstructable for a historical case.

Avoid invented universal performance thresholds in requirements. A target such as 99.9% of sanctions alerts resolved within 15 minutes is meaningful only if the bank has a product, legal and operational basis for that target. The correct threshold belongs in the institution's approved service-level and risk framework.

Data acceptance criteria

For screening, test identity attributes as well as names. Confirm that aliases, transliterations, registration numbers, dates of birth, addresses and other relevant identifiers survive source-system transformations. Where a field is absent, the case should show that absence rather than silently substituting a value.

For monitoring, test completeness across all intended products and legal entities. Confirm timestamps, currency conversion, transaction direction, counterparty identifiers and reversal/return semantics. Aggregation tests should prove that the same activity is not double counted after replay and is not lost when messages are repaired or reprocessed.

Where both controls use a shared party master, test entity-resolution behaviour carefully. Over-merging two people can produce false screening and network conclusions; under-merging one person across aliases can hide exposure from both controls.

Workflow and handoff tests

A shared case platform should route each alert to the correct workflow without losing its meaning. Test at least four cases:

1. a sanctions name candidate that is a clear false positive;
2. a sanctions candidate that requires specialist applicability review;
3. a behavioural monitoring alert with a reasonable explanation; and
4. a monitoring case that discovers a new identity or ownership fact requiring KYC or screening action.

For each case, verify source, evidence, decision authority, downstream action and audit trail. Handoff testing should prove receipt and completion, not merely creation of an email or task.

Staffing and competency

Screening and monitoring can share foundational financial-crime training, but specialist competencies differ. Screening reviewers may need strong identity-resolution skills, sanctions-programme knowledge and understanding of ownership/control concepts. Monitoring investigators may need transaction reconstruction, hypothesis testing, network analysis and narrative writing.

Cross-training is valuable for handoffs. A monitoring analyst should understand why a sanctions candidate cannot be treated as suspicion by itself. A screening analyst should understand why an AML investigation may uncover new identity or ownership facts relevant to screening. Cross-training should improve boundary literacy without assuming every reviewer is automatically authorised or competent to make every specialist decision.

Red-team and challenge scenarios

Testing should include ambiguous cases where the boundary can be confused.

A payment to a party in a high-risk corridor but with no sanctions candidate should test whether staff avoid inventing a sanctions restriction and instead consider the relevant AML or risk context. A confirmed PEP result should test that the system routes to the PEP/EDD process rather than a sanctions block. A transaction-monitoring case involving a newly discovered owner should test that the ownership fact reaches screening without the investigator's suspicion being treated as proof of sanctions applicability.

A sanctions candidate with a high name score but conflicting identifiers should test whether reviewers use corroborating attributes instead of equating score with identity. A real-time behavioural fraud control should test that the organisation can intervene under its fraud authority without mislabelling the action as sanctions screening simply because it happens before payment execution.

Failure-mode testing

Control testing is incomplete until dependencies fail.

For screening, simulate reference-feed delay, matching-service outage, case-creation failure and missing party data. Confirm the approved fallback and escalation. For monitoring, simulate late transaction feeds, duplicated events, missing customer profiles and scenario execution failure. Confirm that coverage gaps are visible and that retrospective processing or review is initiated where required.

For shared infrastructure, simulate an identity-service outage and observe both controls. The incident record should identify which populations and decisions are affected rather than assuming one generic financial-crime outage status is sufficient.

Metrics for sign-off

Technical sign-off should include evidence that the intended population is covered, required assets resolve, audit trails are complete and control-specific workflow states are functioning. Operational sign-off should confirm reviewer access, escalation routes, business continuity and management information. Compliance or financial-crime risk sign-off should confirm that decision logic reflects the applicable policy and jurisdictional framework.

Do not use alert-count reduction as proof of success. A release that produces fewer alerts may have improved precision or may have reduced sensitivity. The sign-off pack should show why the change is acceptable.

Final delivery questions

Before a BA closes a screening-monitoring requirement, the team should be able to answer these questions clearly:

• What exact risk question does the control ask?
• What population and data does it use?
• What triggers it and when does it run?
• What evidence does a reviewer receive?
• Who is authorised to decide the outcome?
• Which downstream action can follow, and under what basis?
• How is the decision reconstructed later?
• What happens when data or a dependent service fails?
• How does information move to adjacent KYC, fraud, sanctions or AML controls?
• How do we know the control remains effective after production change?

If those answers are explicit, shared technology can support both disciplines safely. If they are not, separating the user interface alone will not fix the underlying control ambiguity.

Masterclass: the merged queue that confused two control questions

This composite case illustrates a recurrent design risk rather than describing one named institution. A bank combined sanctions-screening alerts and AML transaction-monitoring alerts in one operations queue because both were labelled "financial-crime alerts". The technology consolidation looked efficient, but the operating model failed to preserve the different questions, evidence needs, decision authorities and timing requirements behind the alerts.

Why the merger initially looked sensible

Both teams used customer data, payment data and a case-management platform. Both reviewed alerts and recorded outcomes. Management therefore expected cross-trained staff to move between queues and absorb peaks in demand. A shared dashboard reported total alerts opened, alerts closed, average handling time and backlog.

The problem was not the shared platform. The problem was that the operating model treated the work items as interchangeable. The queue did not show whether an item was a sanctions candidate requiring identity and applicability analysis, a PEP or adverse-media review, or a behavioural monitoring alert requiring an investigation. Priority logic blended unrelated scores. Reviewers were measured mainly on throughput. Decision codes were generic enough that match, escalate and close meant different things to different teams.

The screening failure

A payment-screening candidate concerning a cross-border beneficiary entered the same backlog as monitoring alerts. The payment had been placed on hold according to the bank's policy while the candidate was reviewed. Because the queue priority did not reflect the payment's processing deadline, the case aged longer than intended.

When a reviewer finally opened it, the case file showed a high fuzzy-name score but little structured identity information. The reviewer had to search other systems for registration details and address data. The candidate ultimately proved to be a false positive, so no sanctions prohibition applied. The customer impact came not from an unlawful payment but from avoidable delay created by weak queue design and poor evidence presentation.

That finding mattered. It showed why it is inaccurate to say every screening alert requires blocking or freezing. Here the correct outcome was release. The control failure was operational: the bank had not provided the right evidence and prioritisation to resolve the candidate within its approved payment process.

The monitoring failure

In the same merged queue, a monitoring scenario identified unusual rapid pass-through activity in a newly opened account. A reviewer accustomed to screening workflows treated the alert as though a positive detection required an immediate customer restriction. The account was restricted before the separate investigation and restriction-governance steps defined by bank policy had been completed.

The later investigation found genuinely concerning activity and the case progressed through the bank's AML process. That did not retrospectively make the initial workflow correct. The institution needed to show the authority, evidence and approval supporting each customer-impacting action at the time it was taken. A monitoring alert was evidence to investigate, not a universal legal basis for one standard action.

Root cause: semantics were lost in the common platform

The post-incident review found that several design choices had removed important context:

• the source control was hidden behind a generic alert type;
• sanctions programme and list-version metadata were not prominent;
• monitoring scenarios did not display the behavioural hypothesis clearly;
• queue priorities mixed payment urgency with AML risk scores;
• reviewers shared decision codes even though the outcomes meant different things;
• management information averaged unlike work into one handling-time metric; and
• handoffs to legal, sanctions specialists, AML investigations and customer-restriction governance were not explicit.

None of those defects required separate technology stacks to fix. They required the shared stack to preserve control semantics.

The remediation model

The bank kept its common data platform and case-management user interface but separated the decision paths.

Screening alerts carried a clear screening type, reference source, list version, matched fields, identity evidence, programme information and payment status. Reviewers resolved identity first and, where relevant, escalated applicability questions to the appropriate sanctions or legal authority. Payment priority reflected the product's processing window and the bank's approved control design.

Monitoring alerts carried the scenario name, triggering transactions, lookback period, customer profile, contextual risk factors and investigation hypothesis. Reviewers could close, expand or escalate the case according to AML procedures. Suspicious reporting and customer restrictions followed their own authorised processes instead of being encoded as automatic consequences of the alert.

PEP and adverse-media reviews were also separated semantically even when they appeared in the same interface. A confirmed PEP classification did not trigger a sanctions disposition. Adverse-media information was graded for source quality and relevance rather than treated as a designation.

Better metrics after separation

The bank stopped using one productivity measure for all alert types.

For payment screening it monitored candidate ageing, payment-hold duration, list-update status, false-positive patterns, unresolved high-priority cases and service availability. For transaction monitoring it monitored scenario execution, population coverage, alert ageing, investigation quality, conversion patterns, data-quality exceptions and reporting outcomes. The two sets could still appear on one executive dashboard, but they were not averaged into a number that concealed deterioration in either control.

Quality assurance also changed. Screening QA sampled identity resolution, reference-data use, applicability evidence and final action. Monitoring QA sampled investigative reasoning, use of customer context, alternative explanations, escalation quality and narrative sufficiency. Shared standards such as auditability and evidence provenance remained common.

Why shared infrastructure can still be the right design

The lesson is not that screening and monitoring must live in separate applications or departments. Shared identity services, payment-data platforms, network data, case tooling and intelligence distribution can reduce duplication and improve consistency.

The requirement is that shared infrastructure must not erase differences in purpose and authority. A common case system should support different workflows. A common customer-data service should preserve lineage. A common alert dashboard should expose source and meaning. A common API should not force every control into one generic risk_status that downstream systems cannot interpret safely.

For architects, the design question is therefore: where can infrastructure be shared without sharing decision logic that should remain distinct?

What the BA should capture

A business analyst reviewing a proposed consolidation should map each control across the same dimensions:

1. the risk or legal obligation being addressed;
2. the population and data elements in scope;
3. the trigger and timing requirement;
4. the evidence the reviewer needs;
5. the decision authority;
6. the permitted outcomes;
7. the downstream system actions;
8. the escalation path;
9. the management information; and
10. the audit evidence retained.

If two controls differ materially across those dimensions, the shared platform needs separate workflow configuration even if it presents one visual interface.

Testing the remediated design

The bank tested the new model with paired scenarios.

In the screening test, a near-name sanctions candidate had to place the payment into the correct review status, show the reference record and identity attributes, allow a documented false-positive decision and release the payment only after the authorised outcome reached the payment engine.

In the monitoring test, unusual account behaviour had to generate an alert with the correct transaction history and customer context, allow the investigator to request additional information, and prevent the alert status itself from being interpreted downstream as a sanctions block or account-freeze instruction.

A third test deliberately created a handoff: the monitoring investigation discovered an undeclared corporate owner. The fact, evidence source and relationship path had to reach KYC and screening so that the new owner could be assessed without converting the AML investigator's suspicion into a sanctions conclusion.

The durable lesson

The merged queue failed because the organisation optimised the common word alert instead of the underlying control meaning. The remediation succeeded when the bank preserved distinct questions inside shared infrastructure.

Screening candidates need identity resolution and, where relevant, legal or policy applicability analysis. Transaction-monitoring alerts need investigation of behaviour. PEP and adverse-media results have their own risk meaning. Customer or payment actions follow the authority applicable to the facts, not the colour of an alert banner.

That distinction is the operational boundary this chapter is intended to make memorable.

2026 boundary clarifications: screening and monitoring are different controls, not opposite clocks

The most useful distinction between screening and transaction monitoring is the question the control is trying to answer, not a rigid rule that one always happens before a transaction and the other always happens afterwards. That timing shortcut is convenient for teaching, but it becomes unsafe when translated directly into requirements, operating procedures or system architecture.

Screening compares a person, organisation, vessel, account, payment field, goods description or other relevant data against defined external or internal reference information. Sanctions lists are the clearest example, but customer due diligence may also use politically exposed person data, internal watchlists and adverse information. Those sources do not all carry the same legal effect. A sanctions designation may create a legal restriction under a particular regime; a PEP result normally creates a risk factor and enhanced due-diligence question rather than a prohibition; adverse media is information to assess, not a legal verdict. A well-designed bank therefore records what source produced the result, what programme or policy applies, which legal entity and jurisdiction are in scope, and what decision authority is required.

Monitoring for suspicious activity asks a different question: does the customer, account, payment pattern or wider network show behaviour that warrants further examination? Modern monitoring can combine transactions with customer attributes, counterparties, devices, geographies, network links, fraud intelligence and other information. The Wolfsberg Group's 2024 and 2025 work deliberately uses the broader expression monitoring for suspicious activity because effective detection is no longer limited to periodic rules scanning transaction history. Some controls operate in batch, some near real time and some before execution. The clock therefore depends on the risk, rail, product and control objective.

This distinction matters because a bank can otherwise build the wrong control twice. A payment-screening service designed like a retrospective AML scenario engine may be too slow to support a time-critical sanctions decision. A suspicious-activity control designed as if every alert were a sanctions match may create unjustified customer restrictions and weak investigations. Yet the correct answer is not to declare that all screening is instantaneous and all monitoring is retrospective. Customer screening can occur at onboarding, periodically and when lists or customer information change. Transaction monitoring can be real time or pre-event where the institution has designed a preventive control and the applicable framework permits or expects intervention.

A better mental model: question, authority, timing and outcome

For every control, four fields should be explicit.

Question. Is the control trying to identify a match to defined reference data, or is it trying to identify suspicious or unusual behaviour? Some controls may use both kinds of information, but one primary control objective should be stated.

Authority. What law, regulation, sanctions regime, supervisory expectation, scheme rule or internal risk policy gives the bank authority or responsibility to act? This prevents a screening score or monitoring alert from being mistaken for legal authority by itself.

Timing. At what point is the information actionable? Wolfsberg's sanctions-screening guidance notes that transaction screening should focus on records necessary to the movement of value and on a point where detection is actionable to prevent a sanctions violation. It also explains that not every transaction in every context necessarily requires identical real-time screening. Monitoring, meanwhile, may need historical depth but can also support immediate intervention for particular high-risk patterns.

Outcome. What can the control legitimately cause? A potential screening match usually causes review or a temporary hold according to policy. It is not automatically a confirmed sanctions exposure. A monitoring alert usually causes triage or investigation. It is not automatically suspicion, criminality or a reportable event. Final actions depend on the relevant legal test, facts, policy and decision authority.

That four-part model is safer for analysts and architects because it converts vague labels into testable requirements.

Screening is not one control family with one legal consequence

Banks often use the word screening for several activities that need different treatment.

Sanctions screening seeks to identify potential exposure to restrictions under applicable sanctions regimes. Even here, a name match is only the start. The reviewer must determine whether the matched subject is actually the listed person or entity, whether ownership or control rules bring an unlisted entity into scope, whether the bank or transaction has the necessary jurisdictional nexus, what restriction applies, and whether an exception, exemption or licence is relevant. Blocking, freezing, rejecting, returning, permitting or reporting are therefore legal and factual conclusions, not direct outputs of a similarity score.

OFAC's rules illustrate the point for US sanctions, while OFSI's guidance illustrates it for UK sanctions. Those frameworks must not be presented as globally interchangeable. OFAC administers US sanctions programmes and recommends risk-based sanctions compliance. OFSI's UK general guidance, updated in May 2026, repeatedly directs users to the specific UK legislation and facts that apply. A global bank normally needs a jurisdiction and legal-entity matrix rather than one universal sanctionsAction rule.

PEP screening is different. A PEP match is generally relevant to corruption risk, source-of-wealth understanding, approval and enhanced monitoring under the applicable AML/CFT framework. It does not mean the person is sanctioned or has committed a crime. The system should not reuse sanctions outcome codes such as BLOCKED or FROZEN merely because the matching technology is shared.

Adverse-media screening is different again. Search results can be stale, duplicated, low quality, mistranslated or about another person with a similar name. Source credibility, recency, relevance, seriousness and identity resolution matter. The result is an input to due diligence or investigation, not a substitute for it.

Internal watchlists may represent confirmed fraud intelligence, exited relationships, law-enforcement information received under restrictions, internal investigation findings or other bank-defined concerns. Their permitted uses depend on purpose, privacy, confidentiality, data-retention and local-law constraints. Architecture should preserve the provenance and permitted use of each list rather than flattening everything into one generic risk flag.

Monitoring is broader than traditional transaction monitoring

Traditional transaction monitoring commonly applies scenarios to account or payment activity and generates alerts for review. That remains important, but it is not the whole monitoring problem. FATF Recommendation 10 requires ongoing due diligence, including scrutiny of transactions during the relationship to ensure they are consistent with the institution's knowledge of the customer, business and risk profile, including source of funds where necessary. FATF Recommendation 20 addresses reporting where the institution suspects or has reasonable grounds to suspect that funds are criminal proceeds or related to terrorist financing. Local law determines the precise reporting test, form, deadline and scope.

The practical consequence is that an alert is evidence of a detection rule firing, not evidence that the reporting threshold has been met. Analysts must examine context, obtain information where appropriate, test alternative explanations, link related activity and document why the case is closed or escalated. Some jurisdictions and products permit or require immediate protective measures for certain risks; others separate AML suspicion from the legal authority to restrict a customer's funds. Requirements must state the local basis rather than assuming a universal freeze-on-alert model.

Modern monitoring increasingly combines customer and transaction information. The Wolfsberg Group's 2024 Statement on Effective Monitoring for Suspicious Activity emphasises outcomes and encourages institutions to move beyond narrow automated transaction monitoring. Its 2025 follow-up on responsible innovation adds transition and validation, balancing model risk with financial-crime risk, and explainability. For technology teams this means a monitoring design should be evaluated on risk coverage and useful outcomes, not simply alert volumes or the number of rules configured.

Timing: why the pre-event/post-event shortcut fails

Payment sanctions screening is often time critical because the bank may need to identify and resolve a potential sanctions issue before completing a transfer. But customer sanctions screening also occurs outside payment execution: at onboarding, when customer data changes, when lists change, and through periodic or event-driven rescreening. Insurance, securities, trade finance and other products have additional lifecycle points where sanctions exposure can arise.

Monitoring has equally varied clocks. A structuring scenario may need weeks of history. A mule-account control for instant payments may need a decision in milliseconds or seconds. A post-event network analysis may discover linked accounts months after the first transaction. A fraud-to-AML handoff may require rapid review because criminal proceeds are leaving immediately even though the ultimate suspicious-transaction decision needs a fuller investigation.

Therefore architecture should store timing as a control property: execution_stage, decision_deadline, maximum_hold, fallback_mode, review_sla, and post_event_reassessment are more useful than assuming the word screening or monitoring determines the clock.

False positives mean different things

A screening false positive usually means the compared subject is not the listed or otherwise relevant person, entity or object despite a sufficiently similar match. Common drivers include common names, transliteration differences, incomplete identifiers and weak source data. Tuning focuses on matching logic, list quality, data normalisation, identifiers and reviewer decision support.

A monitoring false positive is less binary. An alert can be correctly generated because activity met a scenario condition yet still close after investigation because the activity is reasonably explained. Calling every closed alert a false positive can hide whether the scenario correctly identified a risk signal. Better metrics separate technical rule accuracy, alert usefulness, investigation conversion, typology coverage and final reporting outcomes.

That distinction matters for governance. Lowering a sanctions-screening threshold and raising a transaction-monitoring threshold are not equivalent tuning actions. Each changes a different risk trade-off and should be validated against different test populations.

Handoffs without conflation

Screening and monitoring should exchange information without becoming one control. A confirmed or material sanctions finding may trigger network review to identify connected exposure. An AML investigation may uncover a beneficial owner or counterparty that should be screened or rescreened. Fraud investigations may identify mule accounts that become relevant to AML monitoring. Trade-document review may reveal ownership, routing or goods information that changes sanctions analysis.

The handoff should preserve provenance. A useful event contains the originating control, underlying evidence, date and time, customer or transaction identifiers, legal or policy context, confidence, required action, deadline and receiving owner. The receiving team should not have to infer whether a field called riskHit=true represents a fuzzy name match, a confirmed designation, an AML alert, a fraud case or adverse media.

What architects should separate and what they can share

Separation is needed where the decision logic or authority differs. Sanctions list ingestion, matching, applicability review and legally governed disposition should not be collapsed into a generic AML scenario engine. Monitoring scenario management, behavioural models, peer groups, case investigation and suspicious-activity decisioning need their own governance.

Shared infrastructure is still valuable. Both controls can use common customer master data, legal-entity and beneficial-ownership graphs, payment-message stores, reference-data services, data-lineage tooling, identity resolution, workflow platforms and audit logging. The design goal is shared facts, distinct decisions.

A shared case platform should therefore preserve different state machines. A screening case might move through potential match, identity resolution, applicability assessment, legal escalation and disposition. A monitoring case might move through alert triage, scope expansion, evidence gathering, hypothesis assessment, decision and reporting. Common UI components are fine; common semantics are not.

BA and testing implications

Requirements should avoid statements such as “all sanctions hits are blocked”, “all monitoring is post-event”, “all PEPs require the same treatment”, or “all suspicious activity must be reported immediately”. Replace them with scoped statements naming the regime, entity, product, decision point and authority.

Testing should cover positive, negative and ambiguous cases. Screening tests need exact and fuzzy matches, aliases, transliteration, identifiers, ownership/control scenarios, list updates, delistings, licences or exceptions where relevant, service failure and duplicate-alert suppression. Monitoring tests need known typologies, legitimate high-activity customers, peer-group differences, data gaps, delayed feeds, scenario changes, case linkage, suppression logic and explainability. Boundary tests should prove that a potential sanctions match does not automatically become a confirmed legal action and that a monitoring alert does not automatically become a suspicious-transaction report.

Operational tests should include time pressure without inventing one universal SLA. Instant-payment screening, batch rescreening and complex ownership review have different clocks. Monitoring of fast-moving scam proceeds may require near-real-time intervention, while a complex corporate network investigation may legitimately take longer under controlled case management.

Practical mini case: one payment, two controls

A corporate customer sends a cross-border payment to a new supplier. Payment screening returns a fuzzy name match on the beneficiary to a designated person. At the same time, the customer's recent activity shows an unusual increase in payments to several new counterparties in the same corridor.

The sanctions-screening team first resolves identity. The beneficiary's date of birth and address do not align with the listed person, and additional identifiers support a false-match conclusion. The payment is not treated as prohibited merely because the fuzzy score crossed the alert threshold. The reviewer documents the list version, compared identifiers and disposition.

Separately, the monitoring signal remains relevant. The corridor change, new counterparties and increased value are compared with the customer's expected business profile, invoices, ownership information and historical activity. The fact that the sanctions alert closed does not make the behaviour low risk. The monitoring team may close the case with a credible business explanation, request additional information, expand the investigation or reach the applicable suspicious-reporting threshold depending on the facts and jurisdiction.

The same payment therefore produces two legitimate control questions and potentially two different answers. That is the boundary the system must preserve.

Sources used for this clarification

• Financial Action Task Force, The FATF Recommendations, updated June 2026: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
• Wolfsberg Group, Sanctions Screening Guidance: https://wolfsberg-group.org/resources/legacy/53
• Wolfsberg Group, Statement on Effective Monitoring for Suspicious Activity, Part I: Moving Beyond Automated Transaction Monitoring: https://wolfsberg-group.org/resources/general/168
• Wolfsberg Group, Statement on Effective Monitoring for Suspicious Activity, Part II: Transitioning to Innovation, published 27 August 2025: https://wolfsberg-group.org/resources/195/202
• US Treasury Office of Foreign Assets Control, A Framework for OFAC Compliance Commitments: https://ofac.treasury.gov/media/16331/download?inline
• US Treasury Office of Foreign Assets Control, Compliance Hotline and sanctions match guidance entry point: https://ofac.treasury.gov/ofac-compliance-hotline
• UK Office of Financial Sanctions Implementation, UK financial sanctions general guidance, updated 12 May 2026: https://www.gov.uk/government/publications/financial-sanctions-general-guidance/uk-financial-sanctions-general-guidance

Knowledge check and glossary

Use these questions to test whether the screening-monitoring boundary is understood without turning useful distinctions into universal legal rules.

What does screening usually ask? Whether a person, entity, payment party, vessel, goods description or other data element is the same as, connected to, or captured by reference information or a defined restriction. A candidate match still needs identity resolution and, where relevant, applicability analysis before the final action is known.

What does transaction monitoring usually ask? Whether activity, relationships or behaviour are unusual, inconsistent with what the bank knows, or indicative of a risk scenario that merits review. A monitoring alert is an investigative prompt, not proof of money laundering or another offence.

Is screening always real time? No. Payment screening can be synchronous where a decision is required before execution. Customer screening can also occur at onboarding, periodically, after data changes or when reference information changes. The required speed comes from the control objective, product and applicable framework.

Is transaction monitoring always post-event? No. Monitoring can be batch, streaming, near-real-time or pre-execution. Fraud and mule-risk controls on instant payments are common examples of behavioural decisioning before settlement. Timing alone does not define the discipline.

Does a high sanctions match score mean the payment must be blocked? No. A score measures similarity under the configured matching logic. The bank still needs to establish identity and determine what the relevant sanctions programme and jurisdiction require. The outcome may differ depending on the facts, programme, licence or other legal considerations.

Is a PEP result a sanctions match? No. PEP status generally leads to enhanced AML/CFT measures under the applicable framework. It is not by itself a sanctions prohibition or evidence of wrongdoing.

What is the role of adverse media? Adverse media provides information that may affect customer risk, enhanced due diligence or an investigation. Its value depends on identity, source credibility, relevance and recency. It should not be treated as equivalent to an official sanctions designation.

Can screening and monitoring share technology? Yes. They can share customer data, payment data, identity services, case-management interfaces and intelligence platforms. The key is to preserve different control purposes, workflows, evidence and decision authorities where those differ.

Why is data lineage important to both? Screening needs to know which original identity or payment fields were compared and which reference version was used. Monitoring needs to know which transactions, profiles and transformations produced the behavioural signal. Without lineage, neither decision can be reconstructed reliably.

How should ownership findings move between controls? If an AML investigation discovers a new owner or controller, the verified ownership fact can be handed to KYC and screening. The receiving function should assess it under its own legal and policy framework rather than treating the investigator's suspicion as proof of sanctions applicability.

Can a sanctions finding feed monitoring? Yes. A confirmed designated relationship can support network or historical-activity analysis. Monitoring can use the fact as context while still assessing behaviour separately.

What should happen when a screening service is unavailable? The bank should follow an approved fallback designed for the specific product, legal obligations and customer impact. There is no universally correct fail open or fail closed answer for every control.

What should happen when monitoring data is incomplete? Coverage gaps should be visible and governed. The bank may need to delay a run, use compensating controls, reprocess data or perform retrospective review depending on the significance of the gap and the approved control design.

How should thresholds be tuned? Screening thresholds should be tested for sensitivity and false positives using relevant identities, scripts and data quality. Monitoring thresholds or models should be tested against the risk hypothesis, population, alert quality, outcomes and missed-risk evidence. Alert-volume reduction alone is not proof of improvement.

What makes a handoff effective? The receiving team knows the fact being transferred, its source and reliability, the requested action and how completion will be confirmed. An email saying "please review" without evidence or ownership is not a robust handoff.

Can a transaction-monitoring alert automatically justify an account freeze? Not as a universal rule. Customer restrictions must follow the authority and governance applicable to the bank, product, facts and jurisdiction. A monitoring alert can contribute evidence but should not be represented as a universal legal basis by itself.

Does a false-positive sanctions alert mean the AML risk is clear? No. It means the particular screening candidate did not establish the screened relationship. The transaction or customer can still present behavioural, fraud, KYC or other financial-crime concerns.

What should BA acceptance criteria prove? Population coverage, correct data, reference/scenario version, reviewer evidence, decision authority, downstream action, audit trail, failure handling and handoff completion. A technical response code alone is not sufficient evidence that the financial-crime control works.

Why should management not combine every alert into one productivity metric? Screening candidates and behavioural investigations can have different complexity, timing and evidence requirements. A single throughput metric can encourage cherry-picking or shallow review and conceal deterioration in one control behind performance in another.

Glossary for delivery teams

Screening: comparison of customer, transaction or other data with reference information or defined restrictions to identify candidates requiring review or action under the relevant framework.

Transaction monitoring: analysis of activity and relationships to identify patterns or behaviour that merit review for financial-crime risk.

Screening alert / candidate: a technical result indicating that configured matching logic found sufficient similarity or another screening condition. It is not automatically a confirmed identity or legal prohibition.

Identity resolution: assessment of whether the bank's subject is actually the same person, entity, vessel or other object as the reference record.

Applicability review: assessment of what a confirmed identity or relationship means under the sanctions programme, jurisdiction, ownership/control rules, licences, exemptions and other relevant facts.

PEP: politically exposed person. PEP status is an AML/CFT risk factor requiring measures defined by the applicable framework; it is not synonymous with a sanctioned person.

Adverse media: public information about alleged or established misconduct or risk that may inform due diligence or investigation after source and identity assessment.

Scenario: defined monitoring logic expressing a risk hypothesis through data, calculations, thresholds or model features.

False positive: a screening or monitoring alert that, after review, does not represent the risk condition the control was designed to identify. The reason should be documented rather than assumed from closure alone.

Handoff: controlled transfer of a fact or case between functions with provenance, requested action, ownership and completion evidence.

Suppression: governed logic preventing a previously understood screening candidate from repeatedly alerting where stable differentiating evidence supports it. Suppressions should be invalidated when relevant data changes.

Coverage gap: a population, data or processing failure that prevents the control from operating as designed. Coverage gaps should be visible, assessed and remediated rather than hidden inside successful job status.

Control provenance: evidence showing which source data, reference data, scenario/model version and rules contributed to an alert and decision.

Customer-impacting action: a payment or relationship action such as hold, reject, freeze, restrict or exit. Its authority should be explicit and should not be inferred solely from the existence of an alert.

References and further reading

The sources below are public authorities and industry guidance used for this chapter. Jurisdiction-specific material is labelled and should not be treated as a universal legal rule.

Global AML/CFT standards and monitoring practice

• Financial Action Task Force (FATF), The FATF Recommendations: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
• Basel Committee on Banking Supervision, Sound management of risks related to money laundering and financing of terrorism: https://www.bis.org/bcbs/publ/d505.htm
• Wolfsberg Group, Statement on Effective Monitoring for Suspicious Activity, Part II: Transitioning to Innovation: https://wolfsberg-group.org/resources/202/
• Wolfsberg Group, Sanctions Screening Guidance: https://wolfsberg-group.org/resources/28/

European Union restrictive-measures controls

• European Banking Authority, Guidelines on internal policies, procedures and controls to ensure the implementation of Union and national restrictive measures: https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/anti-money-laundering-and-countering-financing-terrorism/guidelines-internal-policies-procedures-and-controls-ensure-implementation-union-and-national

The EBA material is specific to the European Union framework and should be applied with the relevant EU and national legal requirements. The amended Guidelines apply from 30 December 2025.

United States sanctions and BSA/AML examination material

• US Treasury Office of Foreign Assets Control, A Framework for OFAC Compliance Commitments: https://ofac.treasury.gov/media/16331/download?inline
• US Treasury Office of Foreign Assets Control, Compliance Hotline and potential-match guidance entry point: https://ofac.treasury.gov/ofac-compliance-hotline
• Federal Financial Institutions Examination Council, BSA/AML Examination Manual: https://bsaaml.ffiec.gov/manual
• Federal Financial Institutions Examination Council, Office of Foreign Assets Control examination procedures: https://bsaaml.ffiec.gov/manual/OfficeOfForeignAssetsControl/01_ep
• Federal Financial Institutions Examination Council, Appendix K: Customer Risk Versus Due Diligence and Suspicious Activity Monitoring: https://bsaaml.ffiec.gov/manual/Appendices/12

United Kingdom material

• UK Office of Financial Sanctions Implementation, UK financial sanctions general guidance: https://www.gov.uk/government/publications/financial-sanctions-general-guidance/uk-financial-sanctions-general-guidance
• UK Financial Conduct Authority, Financial Crime Guide: https://handbook.fca.org.uk/handbook/fcg

These references should be read together with the law, regulations, sanctions programme, FIU reporting rules and supervisory guidance applicable to the bank's legal entity, customer, product and transaction. A name-screening alert, PEP result, adverse-media result or transaction-monitoring alert does not by itself establish the legal consequence; the applicable framework and evidence determine the final action.