Practical Vocabulary for Analysts and BAs

Financial crime is full of ordinary-looking words that carry very specific meanings inside a bank. Alert, hit, match, case, blocked, suspicious, report, customer, beneficiary, risk, evidence and escalation all sound simple until two teams use the same word for different things. At that point, vocabulary stops being a language problem and becomes a control problem.

A business analyst may write “the payment must be blocked when there is a sanctions hit.” A developer may implement that literally. The screening vendor may use hit to mean only that a fuzzy-matching threshold was crossed. Operations may use blocked to mean “temporarily stopped for review,” while the sanctions legal team uses blocked to mean a legally required asset freeze under a particular regime. One short sentence can therefore create a serious defect: a false positive may be frozen as if it were a confirmed legal prohibition, or a genuine freeze may be modelled as a reversible workflow hold.

This chapter builds a working vocabulary for people who design, operate, investigate, test and govern financial-crime controls. It is deliberately practical. The objective is not to create a universal dictionary, because no universal dictionary exists. FATF sets international standards, but countries implement them through different laws and institutions. A U.S. Suspicious Activity Report, a UK suspicious activity report and an FIU disclosure in another jurisdiction may all sit in the same broad family while differing in thresholds, forms, filing channels, confidentiality rules and legal consequences. Sanctions terms are even more sensitive to the applicable legal regime.

The safest mental model is therefore: define the object, define the stage, define the decision authority, define the jurisdiction, and define the evidence. A good requirement should let a reader answer all five.

Why vocabulary is part of control design

In a mature financial institution, financial-crime work is distributed across customer onboarding, KYC utilities, screening engines, transaction-monitoring platforms, fraud systems, payment hubs, case-management tools, trade-finance systems, data lakes, reporting platforms, relationship teams, operations, compliance, sanctions specialists, MLRO functions, legal teams, internal audit and external authorities. No single team sees the entire chain.

Vocabulary is what joins those systems and teams together. If a source system sends screening_match=true, the receiving system needs to know whether that means algorithmic similarity, analyst-confirmed identity, or a legal determination that the party is subject to a restriction. If an investigator closes a case as false_positive, the next team needs to know whether the false positive relates to identity, behaviour, a data-quality defect, a duplicated alert, or an inapplicable legal regime. If management information reports “blocked payments,” leaders need to know whether the metric includes operational holds, regulatory freezes, fraud stops and technical rejects.

This is why terminology should be treated as a controlled part of the domain model. A useful vocabulary tells people not only what a term means, but also what it does not mean. It records the authoritative source, the owning function, the system representation, the permitted status transitions and any jurisdiction-specific interpretation.

For example, high risk and suspicious should not be synonyms. High risk usually describes exposure that justifies stronger controls. Suspicion is a conclusion reached under the applicable reporting framework after facts and context are considered. A high-risk customer may have entirely explainable activity. A low-risk customer may perform a transaction that creates suspicion. Conflating the terms can lead to discriminatory treatment, defensive reporting and poor prioritisation.

Likewise, red flag and alert are different objects. A red flag is an indicator or pattern that may matter. An alert is a work-generating output of a control. One alert may be triggered by several red flags; one red flag may be considered within a broader model without ever creating a standalone alert.

The vocabulary also matters for customer impact. A payment may be held, repaired, rejected, returned, cancelled, recalled, blocked or frozen. These words have different causes, owners and consequences. The customer-facing message should not expose confidential investigation logic, but the internal record must be precise enough to reconstruct what happened.

The control-chain mental model: from fact to outcome

The easiest way to organise financial-crime language is to place terms along a control chain.

At the beginning are facts and context: customer identity, beneficial ownership, account history, device information, payment parties, amounts, currencies, countries, merchant data, trade documents, IP addresses, prior alerts, sanctions-list data and external intelligence. These are observations, not conclusions.

Next come indicators and detection outputs. A red flag may be observed. A monitoring scenario may trigger. A screening engine may produce a candidate similarity. A fraud model may assign a score. A human may submit an internal referral. Each of these is a reason to look more closely, not proof of wrongdoing.

The third stage is triage and case formation. The institution decides whether the signal can be resolved quickly or requires a managed investigation. Related alerts may be grouped. Additional data may be requested. The case acquires an owner, priority, service level, evidence set and decision trail.

The fourth stage is analysis and decision. An investigator assesses identity, behaviour, expected activity, ownership, transaction purpose, source of funds, counterparties, legal restrictions and other context. Depending on the control, the decision may concern identity resolution, sanctions applicability, suspicion, customer risk, fraud liability or the permissibility of a payment.

The final stage is action and record. The outcome may be release, enhanced due diligence, continued monitoring, internal escalation, customer restriction, rejection, freezing, account exit, a regulatory disclosure, a sanctions report, law-enforcement contact, or simply a documented closure with no further action. The outcome should be traceable to the evidence and decision authority.

The control chain prevents a common design error: storing a conclusion in a field that actually contains an earlier-stage signal. is_sanctioned=true should not be populated merely because a name-matching algorithm generated a candidate. suspicious=true should not be set because a transaction exceeded a threshold. fraud=true should not be used for every disputed card transaction. Systems should preserve the difference between observation, detection, assessment, decision and action.

For a BA, this becomes a requirement-writing discipline. Instead of “system flags suspicious transactions,” write what creates the signal, what data is evaluated, what object is created, who reviews it, what evidence is available, what statuses are permitted, and what downstream action follows each disposition.

Risk, inherent risk, residual risk and risk appetite

Risk is a broad concept: exposure to an uncertain event and its consequences. In financial crime, institutions often assess the risk that customers, products, services, channels, countries or transactions could be misused for money laundering, terrorist financing, proliferation financing, sanctions evasion, fraud or other illicit activity.

Inherent risk is commonly used to describe the level of risk before considering the effectiveness of controls. Residual risk is the risk remaining after relevant controls are considered. These are risk-management constructs rather than universally defined legal terms, so a bank should document its own methodology.

Risk appetite expresses the nature and level of risk an institution is willing to accept or retain within its strategy and legal obligations. It never authorises conduct that is prohibited by law. A bank cannot decide that its “appetite” permits sanctions violations or non-compliance with mandatory suspicious-transaction reporting. Risk appetite operates within the boundaries of legal and regulatory requirements.

Customer risk rating is an institutional assessment used to determine the intensity of due diligence, monitoring and governance. The rating may consider customer type, ownership, products, geographies, channels, transaction profile and other factors. It is not a finding that the customer is criminal.

FATF’s current Recommendations, amended through June 2026, continue to centre the risk-based approach and explicitly emphasise proportionality. The international standard expects measures to correspond to identified risk rather than treating every customer or transaction identically. Local law determines how that principle is implemented.

For requirements, avoid a generic field called risk. Use a more precise structure such as customerRiskRating, sanctionsRiskIndicator, countryRiskBand, transactionRiskScore, modelScore, riskFactorReasonCode and effectiveDate. A single integer passed between systems may conceal materially different concepts.

Red flag, indicator, typology and risk factor

A red flag is an observation or pattern that may indicate heightened concern and deserves context. It is not proof of money laundering, terrorist financing, sanctions evasion or any other offence. FATF and many national authorities publish red-flag indicators to help institutions recognise patterns that may warrant further review.

An indicator is a broader term for a fact or signal with potential relevance. Some institutions use indicator and red flag interchangeably; others reserve red flag for higher-priority concerns. Either approach can work if the taxonomy is documented.

A typology describes a method, pattern or technique by which illicit activity may be carried out. Mule-account networks, trade-based laundering through manipulated invoices, misuse of shell companies, rapid movement through multiple accounts, sanctions evasion through intermediaries and ransomware conversion chains are examples of typological patterns. A typology is a model of behaviour; it is not a verdict about an individual transaction.

A risk factor is an attribute that influences an assessment of exposure. High-risk geography, non-face-to-face onboarding, complex ownership or a cash-intensive business model may be risk factors. A risk factor can justify stronger controls without becoming a red flag in every case.

These distinctions matter in model design. A monitoring scenario may be built to detect a typology. The scenario may evaluate multiple risk factors. When thresholds are met, it creates an alert containing several indicators. The investigator then decides whether the facts are explainable or suspicious. That sequence is much clearer than saying “the typology detected money laundering.”

Scenario, rule, threshold, model and score

A scenario is a defined detection use case. It usually represents a behaviour or risk pattern the institution wants to identify, such as rapid movement of incoming funds, structuring-like cash behaviour or activity inconsistent with the customer profile.

A rule is executable logic. A scenario may be implemented by one rule or many rules. Rules can be deterministic, such as “amount above X and country in Y,” or can combine multiple conditions.

A threshold is the value at which logic changes state: an amount, count, velocity, similarity percentage, time window or score. Thresholds should be governed because poorly tuned thresholds can either flood operations with noise or miss material risk.

A model is broader analytical logic that may use statistical methods, machine learning, network analytics or other techniques. A model can produce a score, but the score is not automatically a legal or investigative conclusion. Score semantics must be explicit: does 0.92 mean probability, similarity, ranking percentile, model confidence or an institution-specific composite?

A BA should never accept a requirement such as “score over 80 is suspicious” without understanding how the score is created and what decision it is intended to support. Suspicion is generally a human or legally governed institutional judgement; a score can inform that judgement.

Screening, monitoring and surveillance

Screening generally compares parties, names or other attributes with reference data such as sanctions lists, PEP datasets, adverse-media sources or internal watchlists. The central question is often identity or list relevance: is this person, entity, vessel, bank, address or other data element the same as, or sufficiently similar to, a known subject?

Transaction monitoring examines behaviour, patterns and relationships. The question is usually behavioural: does this activity differ from expected behaviour or resemble a known risk pattern strongly enough to warrant review?

Ongoing monitoring under CDD is wider than transaction monitoring. It can include keeping customer information current, understanding changes in ownership or activity, reviewing transactions against knowledge of the customer and refreshing risk assessments.

Surveillance is used differently across institutions. In markets businesses it may refer to conduct or market-abuse surveillance. In some financial-crime contexts it is used more generally for monitoring. Because the term is overloaded, requirements should specify the exact control.

The Wolfsberg Group’s 2024 and 2025 statements on effective monitoring for suspicious activity are useful because they frame monitoring as a broader outcomes-based capability rather than a narrow set of static transaction rules. In 2025 Wolfsberg highlighted responsible transition, model-risk versus financial-crime-risk balance and explainability when institutions adopt more advanced analytics. That reinforces a vocabulary point: transaction monitoring engine, monitoring programme and suspicious activity decision are not the same thing.

Hit, candidate, match, false positive and true match

The word hit is especially dangerous. A vendor may call every record above a similarity threshold a hit. An analyst may use the same word only after confirming identity. An operations user may understand it as “the customer is sanctioned.” These are three different states.

A safer screening vocabulary is:

A candidate or potential match is an output that requires identity resolution. The engine has found sufficient similarity between screened data and reference data to create work.

A false positive means review established that the screened subject is not the relevant listed or watchlisted subject. The evidence might be a different date of birth, nationality, registration number, address, vessel IMO number or other reliable discriminator.

An unresolved potential match means the available data is insufficient to conclude either way. That is different from a true match and different from a false positive.

A true match generally means the screened party has been identified as the same party as the reference record. But even a true identity match does not always answer the legal question. Some lists carry blocking restrictions; others carry sectoral, activity-based or other restrictions. Jurisdiction and transaction context still matter.

A confirmed sanctions restriction is therefore a later legal/compliance determination that the applicable sanctions rule affects the customer, asset or transaction. Good systems keep identity resolution and legal applicability as separate decision objects.

This separation improves testing. A test case can establish that the matching algorithm generates a candidate for an alias; another can establish that date-of-birth evidence resolves it as false; another can confirm that a genuine identity match routes to sanctions specialists; and another can test the appropriate legal outcome under a specific regime.

Alert, event, referral, task and case

An event is something that happened: a payment was initiated, a customer changed address, a list was updated, a device was enrolled, a cash deposit was posted, or a transaction was returned.

An alert is a control-generated prompt for review. An alert should normally record the triggering logic, source data, timestamp, related customer or transaction and version of the rule or list that generated it.

A referral is commonly a human-originated escalation into a financial-crime process. A branch employee, payment investigator, fraud analyst or relationship manager may notice something that automated controls did not detect and create a referral.

A task is a unit of work. Tasks may sit inside an alert or case: obtain ownership evidence, review five transactions, contact the relationship team, perform secondary sanctions analysis, or obtain approval.

A case is a managed container for investigation. It can link multiple alerts, customers, accounts, transactions, counterparties, documents, notes, decisions and reports. The word case should not automatically imply suspicion. Some banks create a case for every alert; others create a case only when triage identifies a need for deeper investigation.

A case status describes workflow, not the risk conclusion. OPEN, PENDING_INFORMATION, UNDER_REVIEW and CLOSED are workflow states. NO_CONCERN, ESCALATED, SUSPICIOUS, TRUE_MATCH or REPORT_FILED are dispositions or decision outcomes. Mixing the two into one status field creates awkward state machines and poor auditability.

An alert disposition explains how the alert was resolved: false positive, expected activity, duplicate, data-quality issue, escalated to case, or another bank-defined reason. Closure reasons should be sufficiently granular to support tuning and quality assurance without encouraging analysts to select convenient generic codes.

Review, triage, investigation and disposition

Triage is the initial prioritisation and resolution step. The purpose is to identify obvious false positives, duplicates, low-information items and urgent risk, and determine what requires deeper work.

A review is a neutral term for examination. It may be narrow or deep. Requirements should specify the expected scope rather than assuming “review” is self-explanatory.

An investigation is a structured examination of facts and relationships intended to answer defined questions. In an AML case, that may mean reconstructing activity, comparing it with the customer profile, identifying counterparties, reviewing prior alerts, considering source of funds and documenting whether suspicion is formed. A bank investigation is not the same as a criminal investigation by law enforcement.

A disposition is the recorded outcome of a review or investigation. Good disposition design separates the conclusion from the action. “No suspicion” is a conclusion. “Close case” is an action. “Suspicion formed” is a conclusion. “File report” may be an action subject to jurisdictional rules and approval.

Escalation means transferring an issue to a person or function with greater authority, expertise or responsibility. It should not be used as a vague synonym for “send an email.” The escalation should identify the trigger, destination, expected decision, service level and evidence package.

Unusual, unexplained and suspicious

Unusual means activity differs from what is expected or typical. Unusual activity can be legitimate.

Unexplained means the institution does not yet have a satisfactory explanation. That may be because information is missing, contradictory or not credible. Unexplained activity may justify further enquiry without automatically becoming suspicious.

Suspicious is a more consequential judgement. The exact legal threshold and wording are jurisdiction-specific. Under the FATF standard, Recommendation 20 requires financial institutions that suspect, or have reasonable grounds to suspect, that funds are proceeds of criminal activity or related to terrorist financing to report promptly to the FIU. FATF’s Interpretive Note also states that suspicious transactions, including attempted transactions, should be reportable regardless of amount. Countries implement this standard through domestic legislation, so teams should not copy one jurisdiction’s threshold or filing terminology into a global policy as if it were universal.

The United States illustrates why localisation matters. FinCEN’s SAR rules and FAQs use formulations such as a financial institution knowing, suspecting or having reason to suspect specified circumstances, together with sector-specific thresholds and timing rules. Those details are U.S. rules, not a global definition of suspicion.

The language used in investigation notes should therefore separate fact from inference. “Customer received 14 credits from unrelated individuals within two hours” is a fact. “Activity is inconsistent with stated salary profile” is an analytical comparison. “Pattern is consistent with possible mule activity” is a hypothesis. “Suspicion formed under local policy” is a governed decision. Writing all four as “customer laundering money” is inaccurate and potentially harmful.

Predicate offence, proceeds of crime and money laundering

A predicate offence is an underlying criminal offence that generates proceeds which may then become the subject of money laundering. Fraud, corruption, drug trafficking, tax crimes, human trafficking and cyber-enabled offences can be predicate offences depending on the applicable legal framework.

Proceeds of crime are assets or value derived directly or indirectly from criminal activity as defined by law. The concept is wider than cash. It can include account balances, property, securities, virtual assets, goods or other economic value.

Money laundering concerns the handling, conversion, transfer, concealment or other dealing with criminal proceeds under applicable law. Operationally, a bank should not require investigators to prove the exact predicate offence before recognising laundering risk. Financial institutions detect patterns and report suspicion; law enforcement and courts determine criminal liability.

The phrase placement, layering and integration is a useful teaching model for money laundering, but it is not a mandatory three-step sequence present in every case. Modern laundering may move digitally without an obvious cash-placement stage, and criminal proceeds may remain inside commercial or virtual-asset ecosystems. Requirements should therefore detect relevant behaviours rather than force every investigation into three boxes.

Terrorist financing and proliferation financing

Terrorist financing is not simply “money laundering for terrorism.” Funds can be legitimate or illegitimate in origin; the concern is their intended use, recipient, network or purpose under the applicable framework.

Proliferation financing concerns financing connected to proliferation of weapons of mass destruction and related targeted financial-sanctions risk. FATF’s Recommendation 7 addresses targeted financial sanctions related to proliferation, while Recommendation 1 requires risk assessment and mitigation of potential breach, non-implementation or evasion of such targeted sanctions. Domestic laws can impose additional sanctions and export-control obligations.

For systems, do not collapse AML, terrorist-financing, proliferation-financing, sanctions and fraud decisions into one financialCrimeFlag. They can share data and case-management infrastructure, but they have different legal triggers, reporting routes, confidentiality obligations and operational actions.

KYC, CDD, EDD and KYB

KYC — Know Your Customer is a broad industry expression. It can refer to the entire process of identifying, verifying and understanding a customer.

CDD — Customer Due Diligence is more precise in the FATF framework. It covers identifying and verifying the customer, identifying and taking reasonable measures to verify beneficial ownership, understanding the purpose and intended nature of the relationship, and conducting ongoing due diligence. Local rules determine exact requirements.

EDD — Enhanced Due Diligence refers to stronger or additional measures where higher risk or specific legal obligations require them. EDD should answer the identified risk; it is not simply a request for more documents.

KYB — Know Your Business is a common industry term for due diligence on legal entities and business customers. It may include registration, legal form, activities, ownership, controllers, authorised persons, expected flows, counterparties, geographies and evidence of legitimate operations. KYB is usually part of the broader CDD framework rather than a separate global legal category.

Periodic review is a scheduled refresh of customer information and risk. Event-driven review is triggered by a meaningful change or new information, such as ownership changes, unusual activity, sanctions-list updates or adverse information.

Customer, legal person, legal arrangement and beneficial owner

A natural person is an individual human being. A legal person is an entity recognised by law, such as a company or foundation. A legal arrangement, such as certain trusts, may not have separate legal personality but can still hold or control assets through its parties.

A beneficial owner is the natural person or persons who ultimately own or control a customer or on whose behalf a transaction is conducted, according to applicable standards and law. FATF’s glossary and Recommendations 24 and 25 provide the international framework, while jurisdictions define detailed identification and verification rules.

A shareholder is not automatically the beneficial owner. A director is not automatically the beneficial owner. An authorised signatory has authority to act but may have no ownership. A nominee may hold a formal position on behalf of another person. A controller may exercise influence through voting, appointment rights, contracts or other means.

A robust ownership model records direct and indirect relationships, percentages where relevant, type of control, evidence source, effective dates and historical changes. This is essential because sanctions ownership and control tests can differ between regimes; one global percentage rule is unsafe.

Sanctions: listed, designated, restricted and prohibited

Listed means a party appears on a sanctions or restriction list. Designated usually refers to a formal legal designation under a sanctions authority. The exact consequences depend on the list and regime.

Restricted is broader. A person, entity, sector, instrument, service, vessel, good, territory or activity may be restricted without being subject to a full asset freeze.

Prohibited means the relevant activity is not permitted under the applicable legal rule unless an exemption or authorisation applies. A prohibition can arise from the nature of the activity even when no listed person is present.

This is why “not on the list” is never a complete sanctions conclusion. Ownership rules, sectoral measures, geographic restrictions, service prohibitions, trade controls and other measures can matter.

Hold, interdict, block, freeze, reject, return and release

These terms must be handled with care because some are operational and some can have specific legal meaning.

A hold is commonly an internal temporary state that stops processing while information or a decision is pending. A hold should have an owner, reason, start time, permitted duration or escalation logic, and release authority.

Interdict is often used operationally for a payment stopped by a screening or sanctions control. It is not a universal legal term.

Block and freeze can be legal terms. Under U.S. OFAC guidance, blocking means freezing property in which a blocked person has an interest within U.S. jurisdiction; title is not transferred to the U.S. government, and dealings are prohibited unless authorised. Other sanctions regimes use their own statutory language and reporting rules.

Reject can mean a payment or transaction is not processed and is sent back or refused. Under OFAC, for example, some prohibited transactions are rejected when there is no blockable interest. That U.S. distinction must not be universalised.

Return is a payment-flow action that sends funds back after a payment has been received or settled according to the relevant payment-rail rules. A payment return is not necessarily a sanctions rejection.

Release means a hold is removed and processing continues. Release does not mean the customer has been declared “safe”; it means the specific control no longer prevents that action.

A good payment data model therefore separates paymentStatus, screeningStatus, sanctionsDecision, fundsAvailabilityStatus and regulatoryReportingStatus. Otherwise a UI may show BLOCKED without anyone knowing whether funds are legally frozen, temporarily held or technically unavailable.

Seized, restrained, frozen and confiscated

Frozen property is generally prevented from being moved or dealt with under a legal or regulatory power. Ownership may remain unchanged.

Restrained is a legal term used in some criminal or asset-recovery frameworks to prevent disposal of property pending proceedings.

Seized generally means authorities have taken control or possession under legal power.

Confiscated or forfeited generally means property has been permanently taken following the applicable legal process.

These are not interchangeable. A bank normally implements freezing or restraint instructions; it does not decide that a customer’s property is confiscated. Requirements should preserve the issuing authority, legal instrument, effective time, assets in scope and release mechanism.

Fraud, scam, authorised payment and mule activity

Fraud is a broad category of deception or unlawful conduct for financial gain. A bank’s fraud taxonomy may distinguish card fraud, account takeover, impersonation, application fraud, merchant fraud and many other types.

A scam often involves deceiving a victim into making or enabling a payment. In an authorised push-payment scam, the customer may technically authorise the payment instruction while being manipulated. Payment authorisation therefore does not mean the transaction was genuinely intended in the ordinary sense.

A mule account is an account used to receive or move illicit funds on behalf of criminals. The account holder may be complicit, recruited, coerced or deceived. A mule suspicion should not automatically be described as proven criminal participation.

Fraud and AML teams often see different parts of the same event. Fraud focuses on customer harm, authentication and payment recovery; AML focuses on criminal proceeds and networks. A fraud-to-AML referral transfers relevant intelligence without assuming that every fraud alert requires an AML case.

Payment party vocabulary: who is actually moving value?

Payment terminology is a frequent source of defects because channel language, customer language and ISO 20022 language are not always the same.

The debtor is the party that owes the money in the payment context. The debtor account is the account from which funds are taken. The creditor is the party to whom money is due, and the creditor account is the receiving account.

An ultimate debtor or ultimate creditor can identify the party behind the immediate debtor or creditor. These fields are important when a payment is made by or through an intermediary on behalf of someone else.

The originating bank, debtor agent, creditor agent, intermediary agent and correspondent bank describe financial institutions performing different roles in the payment chain. A correspondent bank provides services to another financial institution; an intermediary may sit in a particular payment route without being the customer’s bank.

The everyday terms sender and receiver are convenient but ambiguous. The sender could mean the customer initiating the instruction, the sending bank or the technical message sender. The receiver could mean the beneficiary, receiving bank or message endpoint. Requirements should use formal role names where the distinction matters.

Beneficiary is widely used in business language for the party receiving value. In ISO 20022 credit-transfer messages, creditor is the formal party role. A sanctions rule that says “screen beneficiary” should specify which message parties and related data elements are actually included.

Payment identifiers: transaction, instruction and message are different objects

A payment instruction is a request to move value. A payment is the business transaction being executed. A message is the data container used to communicate an instruction or status. One payment can generate many messages.

An EndToEndId is intended to identify a payment end-to-end within the relevant ISO 20022 context. A UETR is a unique end-to-end transaction reference used in SWIFT gpi/CBPR+ contexts to trace a payment across institutions. A transaction ID, clearing reference, message ID, case ID and alert ID are different identifiers.

This matters in financial-crime investigations. If an alert stores only the message ID, investigators may fail to link a returned payment or subsequent investigation message to the original economic transaction. A canonical data model should retain all relevant identifiers and their relationships.

Booking means recording an entry in the bank’s ledger or account system. Settlement is the discharge of obligations between institutions or parties through transfer of funds or assets. A transaction can be screened before booking, after booking, before settlement, after settlement or at several points depending on the payment architecture.

Structured data, narrative and enrichment

Structured data is information held in defined fields, such as name, date of birth, country code, account number or organisation identifier. Structured fields support consistent validation and matching.

Unstructured data or narrative is free text. Remittance information, case notes and trade descriptions can contain valuable context but are harder to validate and interpret reliably.

Enrichment adds context from another source: customer risk rating, beneficial ownership, geolocation, device intelligence, sanctions reference data, transaction history or external intelligence. Enrichment should preserve provenance. A case reviewer should be able to tell which value came from the original payment and which was added later.

Normalisation transforms data into a consistent representation, such as case folding, punctuation removal or address standardisation. Transliteration converts text from one script into another representation. Both can improve screening, but they can also introduce collisions or information loss.

A requirement saying “normalise name before screening” is incomplete. It should state what transformations are permitted, whether the original value is retained, how non-Latin scripts are handled, and how the transformed value appears in evidence.

Exact matching, fuzzy matching and similarity score

Exact matching requires the compared values to meet a defined equality rule. Even “exact” may involve normalisation, so the rule should be explicit.

Fuzzy matching allows variation. Algorithms may consider edit distance, token order, phonetics, transliteration, aliases or other features.

A similarity score measures closeness according to the algorithm. It is not inherently a probability that the person is sanctioned. Calling it “confidence” can be misleading unless the model has been calibrated to support that interpretation.

A threshold determines when a candidate is generated or prioritised. Lower thresholds often increase recall but create more false positives; higher thresholds may reduce workload but increase miss risk. Tuning should be evidence-based and controlled.

False positive rate, precision, recall and related model metrics have technical meanings. Operational teams should avoid using “false positive” loosely to mean “an alert I did not like.” In screening, false positive generally refers to a candidate resolved as not being the target. In monitoring, a closed alert may be better described as “no suspicion identified” unless a formal labelled ground truth exists.

Data lineage, provenance, quality and coverage

Data lineage describes how data moves from source through transformations into a control and downstream record. A bank should be able to answer: where did this field come from, what transformed it, when was it captured, which version was used, and where else is it sent?

Provenance focuses on origin and history. In a case, provenance distinguishes customer-provided information, system-generated data, analyst-created notes and third-party intelligence.

Data quality includes completeness, accuracy, validity, consistency, timeliness and uniqueness. A screening engine cannot compensate for a missing beneficiary name. A transaction-monitoring model cannot detect cash structuring if relevant cash fields never reach it.

Coverage means the scope of customers, products, transactions, geographies and risk patterns actually addressed by the control. A monitoring platform may be technically healthy while missing an entire product feed. “System is up” is not the same as “control coverage is complete.”

For BAs and testers, source-to-control reconciliation is a core financial-crime requirement. Expected input counts, rejected-record counts, late-file handling, transformation rules and completeness controls should be testable.

Evidence, supporting documentation and audit trail

Evidence is information used to support a decision. It can include transaction records, KYC documents, ownership information, customer explanations, public records, internal system data, screening-list information and communications.

Supporting documentation is evidence retained with or linked to a decision or regulatory report. The required retention and disclosure rules depend on jurisdiction. FinCEN, for example, has specific U.S. guidance on SAR supporting documentation and retention. That should not be assumed to apply globally.

An audit trail records what happened: who viewed or changed data, what decision was made, when it was made, which evidence was available and which rule or list version applied. Auditability is not the same as logging everything. The record must be understandable and retrievable.

A decision rationale explains why the evidence supports the conclusion. “Reviewed and okay” is not a useful rationale. A stronger rationale states the concern, relevant facts, disambiguating evidence, policy or legal rule, and resulting decision without unnecessary speculation.

A useful conceptual progression is raw fact → anomaly or indicator → corroboration and context → governed decision. That progression is deliberately not a legal formula. Suspicion can arise from one highly significant fact or a combination of weaker signals, and jurisdictions apply different statutory language. Its purpose is to stop teams from treating an alert as if it were already a final conclusion.

Escalation, approval and decision rights

Escalation transfers an issue for decision or specialist input. It should be triggered by defined conditions: unresolved sanctions identity, material customer risk change, possible PEP, suspicion, legal uncertainty, time-critical payment impact or policy exception.

Approval is a formal decision by an authorised role. Approval should be distinguished from consultation. A sanctions lawyer providing interpretation is not necessarily the person who operationally approves a payment. An MLRO may own suspicious-activity reporting decisions in one jurisdiction, while responsibilities differ elsewhere.

Four-eyes control means a second authorised person reviews or approves an action. It does not automatically mean the second person performed an independent investigation. The control objective should be clear.

A decision right states who has authority to decide. This is critical for workflow design. If a first-line analyst can close a low-risk false positive but only a sanctions specialist can release a certain potential match, the system should enforce that difference.

SAR, STR, disclosure and FIU

SAR commonly means Suspicious Activity Report. STR commonly means Suspicious Transaction Report. Different jurisdictions use different terms and forms; neither acronym should be treated as universally preferred.

Under FATF Recommendation 20, the international standard is that financial institutions report suspicious transactions promptly to the country’s Financial Intelligence Unit (FIU) when the relevant suspicion threshold is met. FATF Recommendation 29 describes the FIU as the national centre for receiving and analysing suspicious transaction reports and other relevant information and disseminating the results of its analysis.

The Egmont Group similarly describes FIUs as national centres for receiving and analysing suspicious transaction reports and relevant money-laundering, predicate-offence and terrorist-financing information, and for disseminating analysis results. FIU organisational models differ: administrative, law-enforcement, judicial or hybrid.

A regulatory report is broader than an SAR/STR. Sanctions blocking reports, frozen-asset reports, large-cash reports, cross-border reports and other disclosures may be required under separate laws. Calling every external filing a “SAR” creates serious design problems.

A reporting decision should be separate from report status. REPORT_REQUIRED or NO_REPORT may reflect a decision. DRAFT, APPROVED, FILED, ACKNOWLEDGED, REJECTED_BY_PORTAL and AMENDED describe the lifecycle of the filing artifact.

Suspicion reports, regulatory reports and the filing lifecycle are three different vocabularies sharing one page.

Confidentiality, tipping off and need-to-know language

Financial-crime information can have special confidentiality rules. Many jurisdictions restrict disclosure that a suspicious-transaction report has been or will be filed. The exact offence or prohibition—often discussed using the phrase tipping off—depends on local law.

A system should therefore avoid using customer-visible reason codes such as SAR_FILED, AML_SUSPICION_CONFIRMED or LAW_ENFORCEMENT_REFERRAL. Internal case data should be access-controlled according to role and need.

Need to know is an access-governance principle, not an excuse to hide necessary control information from legitimate users. Product design should identify which fields can be shown to payment operations, customer service, relationship managers, compliance, legal and auditors.

Information barrier describes controls restricting information flow between functions or individuals where legal, market-conduct, investigative or confidentiality requirements justify separation.

False positive, false negative and quality assurance

A false positive is a control output indicating concern when the target condition is not actually present. The exact definition depends on the control and availability of ground truth.

A false negative is a missed target condition: the control did not alert when it should have. False negatives are much harder to measure because unknown illicit activity cannot be counted directly.

Quality assurance (QA) checks whether work was performed to the required standard. Quality control (QC) may be used for more immediate checking of individual outputs. Institutions use these terms differently; the operating model should define them.

Validation is an independent or appropriately governed assessment of whether a model or control performs as intended. For advanced analytics, validation can include conceptual soundness, data, performance, limitations and change governance.

Tuning changes thresholds, rules or model parameters to improve performance. Tuning is not merely “reduce alerts.” The objective is to improve effective risk detection while controlling operational noise and avoiding unjustified customer impact.

Backlog, ageing, SLA and prioritisation

A backlog is unresolved work waiting for action. Backlog size alone does not describe risk. A thousand newly created low-priority alerts may be less dangerous than ten time-sensitive sanctions cases approaching legal deadlines.

Ageing measures how long an item has remained in a state. Age should normally be measured from a clearly defined timestamp: alert creation, assignment, first review or escalation.

An SLA — service-level agreement is a defined target for service performance. In control operations it may be an internal target, contractual commitment or regulatory expectation. Teams should not label every deadline an SLA. A statutory filing deadline is a legal deadline, not simply a service level.

Priority determines the order of work. It should consider risk, urgency, customer impact, legal deadlines, payment value, typology and other factors. A priority score should be explainable enough for operations to understand why work moved ahead of other items.

Control, procedure, policy and standard

A policy states principles, obligations and management expectations.

A standard often defines mandatory minimum requirements derived from policy. Organisations vary in their document hierarchies.

A procedure describes how people perform work.

A control is a measure designed to prevent, detect or respond to risk. A screening engine is part of a control; the control also includes data, rules, people, decisions, governance, testing and evidence.

A control objective explains what the control is intended to achieve. A control activity is the action performed. A control owner is accountable for design and operation according to the bank’s governance model.

For a BA, “implement AML control” is too vague. Good requirements identify the control objective, in-scope population, trigger, data, logic, workflow, decision authority, evidence, exceptions, reporting and assurance.

The BA object model: entities, events, signals, decisions and evidence

A practical financial-crime domain model can be built around five categories.

Entities are the subjects: natural person, legal entity, legal arrangement, account, payment, card, device, vessel, merchant, bank, address or virtual-asset wallet.

Events are things that happened: onboarding, ownership change, payment initiation, cash deposit, login, list update, adverse-media event, alert creation or case closure.

Signals are outputs indicating potential relevance: risk factor, red flag, screening candidate, monitoring alert, fraud score or manual referral.

Decisions are governed conclusions: identity resolved, sanctions restriction applies, EDD required, suspicion formed, no suspicion, customer exit approved, payment release authorised.

Evidence supports decisions: source data, documents, list records, transaction history, customer explanations, analysis notes, approvals and audit logs.

This model prevents a common anti-pattern in which every object is represented as a “case.” It also makes event-driven architecture easier. A payment event can generate a screening signal; the signal can create an alert; the alert can be attached to a case; the case can produce a decision; the decision can generate a regulatory-report event.

Canonical statuses and why verbs matter

Status design is vocabulary expressed as software.

Consider a sanctions screening workflow. NEW → MATCHED → BLOCKED → CLEARED is poor design because matched could mean algorithmic similarity or analyst confirmation, while blocked could mean an operational hold or legal freeze. A clearer workflow might be:

CANDIDATE_CREATED → TRIAGE → IDENTITY_UNRESOLVED → SPECIALIST_REVIEW → FALSE_POSITIVE / TRUE_IDENTITY_MATCH

The legal decision can then be separate:

APPLICABILITY_REVIEW → NOT_RESTRICTED / RESTRICTED / AUTHORISED_EXCEPTION / LEGAL_ADVICE_REQUIRED

And the payment action separate again:

HELD → RELEASED / REJECTED / RETURNED / FROZEN

Not every bank needs three separate state machines, but the conceptual separation should be preserved. It makes retries, repairs and audit much easier.

Verbs matter too. Detect means identify a signal. Determine means reach a conclusion. Approve means authorise. Report means communicate to an authority or another function. Freeze means apply a restriction to assets. Reject means refuse processing. Avoid using “validate” for all of these.

Requirements that sound clear but are not

“Screen all payments against sanctions lists.” Which payments? At what lifecycle stage? Which parties and fields? Which lists and legal entities? What happens when list data is unavailable? Are historical payments re-screened after a list update? What is the treatment of aliases, ownership and non-list restrictions?

“Create an alert when activity is suspicious.” Is suspicion an input or the investigator’s outcome? If the system creates the alert first, the trigger should be a defined indicator, rule or model score.

“Block the customer on a true match.” Does this mean freeze assets, prevent new products, disable digital access, stop a payment, or place an internal restriction? Which legal regime and which connected accounts are in scope?

“Send SAR to regulator.” Which FIU or authority? Which legal entity files? What threshold, form and deadline apply? Who approves? Is the report confidential? What acknowledgment must be stored?

“Close false positives automatically.” False positive in which control? What evidence is used? Is auto-clear permitted for exact discriminator mismatch? How is model drift monitored? What happens when reference data changes?

Good financial-crime requirements expand these statements into testable decisions without embedding jurisdiction-specific legal assumptions into global core logic.

Architecture: preserve semantics across systems

A screening engine, payment hub and case system often use different data models. The integration layer must not flatten meaning.

Suppose the screening vendor sends:

status = MATCH

The integration contract should explain whether this represents a machine candidate or an analyst-confirmed result. If it is only a candidate, map it to something like SCREENING_CANDIDATE, not SANCTIONS_MATCH_CONFIRMED.

Canonical schemas should carry source, semantic type, effective time, decision state, jurisdiction, rule/list version, actor, reason code and evidence reference where relevant.

Event names should also be disciplined. PaymentScreeningCandidateCreated is clearer than SanctionsHit. SanctionsRestrictionDetermined is clearer than CustomerBlocked. SuspicionDecisionRecorded is clearer than AMLConfirmed.

This vocabulary supports idempotency and replay. If a payment is re-screened after a list update, the system can create a new screening assessment linked to the prior one rather than overwriting history.

Testing vocabulary: test what the term actually means

A tester should challenge semantics before writing test cases.

For a screening candidate, test that similar names generate review work. For a false positive, test that reliable discriminators support closure and the rationale is retained. For a true identity match, test specialist routing and separation from legal applicability. For a freeze, test that funds cannot be moved where the relevant legal rule requires it and that reporting/evidence obligations are invoked according to the configured jurisdiction.

For an alert, test creation, deduplication, priority, data completeness and linkage. For a case, test grouping, ownership, state transitions, evidence retention and approval.

For suspicion, avoid a deterministic test such as “transaction over 10,000 must be suspicious.” Instead test the decision workflow, evidence availability, configured legal threshold, approval and reporting path.

For data lineage, reconcile source and target populations. For list updates, test effective dates, failed ingestion, rollback, rescreening and version traceability.

For customer impact, test what the customer sees. Confidential SAR or sanctions-investigation information should not leak into generic payment-status text.

Mini case study: one payment, many meanings

Consider a corporate customer, Northshore Components Ltd, which normally pays established European suppliers. It initiates a USD payment to a newly added trading company in another jurisdiction for “industrial equipment.” The beneficiary name resembles an alias on a sanctions dataset, and the payment route involves a U.S. correspondent.

The screening engine generates a candidate because the similarity threshold is met. At this stage there is no confirmed sanctions match. The payment platform places the instruction in an operational hold state so value does not move while the candidate is reviewed.

The analyst compares the beneficiary’s legal name, registration number, address and ownership with the reference record. The names are similar, but the registration number and country differ. If reliable evidence establishes that they are different entities, the screening candidate can be disposed as a false positive, and the payment may be released subject to other controls.

Assume instead that additional data confirms the beneficiary is the listed entity. That is a true identity match. The next question is legal applicability: which sanctions regime applies to the bank entity, correspondent route and transaction? What restriction does the designation impose? Is there an ownership or control issue? Is an exemption or licence relevant? Only after that analysis can the institution determine whether it must freeze, reject, refuse, report or take another action.

Now add another fact. Transaction monitoring shows that the customer has made six similar payments through newly created intermediaries in two weeks, far outside its expected profile. That creates a separate monitoring alert. The sanctions decision and AML investigation may be linked but are not identical.

The investigator reviews invoices, customer profile, prior counterparties, ownership, payment messages and explanations. The invoices contain inconsistent descriptions and the customer cannot explain the sudden route change. Those are red flags and unexplained facts. The investigator forms a documented suspicion under the bank’s local policy and applicable law. An authorised reporting function decides to file the required SAR/STR with the relevant FIU.

The case now contains multiple object types: payment, screening candidate, identity decision, sanctions applicability decision, monitoring alert, investigation, suspicion decision, regulatory report and payment action. Calling all of this “an AML hit” would destroy the meaning needed by every system and team involved.

Failure modes caused by poor terminology

The most obvious failure is premature conclusion: a candidate becomes a true match, an alert becomes suspicion, or a risk factor becomes evidence of wrongdoing.

Another is legal leakage across jurisdictions. A global system hard-codes U.S. “block versus reject” terminology and applies it to legal entities governed by different sanctions rules. The technology works exactly as built, but the concept is wrong.

A third is status collision. One BLOCKED flag is reused for fraud holds, sanctions freezes, account restrictions and technical stops. Nobody can tell which team owns release.

A fourth is data overwrite. A later analyst decision replaces the original engine result. Audit cannot reconstruct what information the bank had at the time of the decision.

A fifth is metric distortion. Management sees a 95% “false-positive rate” without knowing whether the metric describes screening candidates, transaction-monitoring closures or adjudicated ground truth.

A sixth is customer harm. Frontline staff see “suspicious customer” when the actual state is “EDD pending,” creating inappropriate treatment or tipping-off risk.

A seventh is control blind spot. Teams say “all transactions are monitored,” but one product feed is excluded. The word all masks a coverage gap.

Vocabulary governance is therefore not bureaucracy. It is a low-cost way to prevent design, operational, legal and reporting errors.

A practical glossary for delivery teams

The table is a starting point, not a substitute for the bank’s controlled glossary. Each institution should add local legal definitions, product terms, system fields and data owners.

Writing better case notes

Good case notes separate what happened, what was checked, what was found, what it means, and what was decided.

A weak note says: “Suspicious beneficiary. Checked and cleared.”

A stronger note would say that the payment-screening engine generated a candidate because the beneficiary name was similar to a designated entity; the analyst compared registration number, address and country; two independent identifiers did not match the listed entity; the candidate was therefore resolved as a false positive under the bank’s sanctions-screening procedure; the payment hold was released by the authorised role. The stronger note does not need to be long, but it creates an auditable chain.

AML investigation notes should use the same discipline. Instead of “customer structuring,” record the observed transaction pattern, expected profile, relevant thresholds or behaviour, customer explanation, corroborating or contradictory evidence, and the resulting suspicion decision.

Avoid definitive criminal labels unless established and relevant. “Possible scam proceeds,” “activity consistent with mule typology” or “unexplained rapid pass-through activity” are more accurate than “customer is a money mule” when the bank only has indicators.

A BA checklist before accepting a financial-crime term

When a requirement contains a loaded term, ask what object it describes, who owns the definition, at what lifecycle stage it applies, whether it is legal or operational, which jurisdiction governs it, what evidence establishes it, what status changes it permits, what downstream actions follow, what the customer can see, and what must be retained for audit.

If the term is hit, ask whether it means machine candidate or confirmed identity.

If it is blocked, ask whether it means operational hold, account restriction or legal freeze.

If it is suspicious, ask who has authority to reach that conclusion and under which law/policy.

If it is report, ask which authority, form, deadline and confidentiality regime.

If it is customer, ask whether the data subject is the account holder, legal entity, beneficial owner, authorised person or payment party.

If it is transaction, ask whether it means business payment, ledger entry, message or clearing instruction.

That discipline turns vague language into testable design.

What good acceptance criteria look like

Weak acceptance criterion: “System must generate sanctions hit accurately.”

Stronger: “When a payment party’s screened name exceeds the configured matching threshold against an in-scope sanctions reference record, the screening service creates a candidate containing the original party data, normalised comparison value, reference-record identifier, list version, matching score/attributes, timestamp and payment identifier. Candidate creation does not set a confirmed-sanctions flag. The payment enters the configured review hold state until a permitted disposition is recorded.”

Weak: “AML alerts should be closed quickly.”

Stronger: “Each monitoring alert records creation time, priority, scenario version, related customer and transactions. Ageing is measured from alert creation. Alerts exceeding the configured service target are surfaced in management information and escalated according to priority. Statutory reporting deadlines, where applicable, are tracked separately from internal service targets.”

Weak: “File SAR if suspicious.”

Stronger: “When an authorised investigator records a suspicion decision under the configured legal entity and jurisdiction, the case is routed to the responsible reporting role with required evidence and local filing metadata. The external report remains a separate object with draft, approval, filing and acknowledgment states, and confidentiality controls prevent report status from appearing in customer-facing channels.”

The stronger examples are longer because control meaning has been made explicit. They are also easier to build, test and audit.

Quality questions for architects and developers

Can the system distinguish source observation from analyst decision? Can historical decisions be reconstructed using the data, list, rule and model versions available at that time? Are payment and screening statuses separate? Can one case link several alerts without losing their individual dispositions? Can a customer have multiple risk assessments over time? Can ownership relationships be effective-dated? Can report confidentiality be enforced by role? Can legal-entity and jurisdiction context travel with the decision? Can data lineage show missing or transformed fields? Can the system process a list update safely if downstream services are unavailable?

A technically elegant platform that cannot answer these questions may still be a weak financial-crime control.

Quality questions for testers and QA

Can you prove that a candidate is not presented as a true match? Can you test false-positive evidence using strong discriminators? Can you demonstrate that a true identity match does not automatically force one sanctions outcome across every regime? Can you trace one payment through hold, review and release? Can you show that a legal freeze cannot be released by an unauthorised user? Can you reconcile all in-scope transactions from source to monitoring? Can you verify that a report’s filing status never appears in customer communication? Can you reproduce the rationale and source evidence after a rule or list changes?

Testing vocabulary is not cosmetic. A test case that uses the wrong term may assert the wrong behaviour.

Ten principles to remember

Financial-crime language becomes safer when teams remember a few principles.

A signal is not a conclusion. Risk is not suspicion. A list candidate is not automatically a true identity match. A true identity match is not automatically the same as legal applicability. A hold is not necessarily a freeze. A payment return is not necessarily a regulatory rejection. An alert is not a case. A case is not a report. A report is not proof of a crime. And a global standard is not the same thing as one country’s implementing law.

Those distinctions may look academic until a real payment is stopped, a customer is restricted, a regulatory report is filed or an auditor asks why a decision was made. At that point, precise language is operational evidence.

Final takeaway

The best financial-crime platforms do not merely contain controls; they preserve meaning.

A bank should be able to follow the story from source data to indicator, from indicator to alert, from alert to case, from case to decision, and from decision to action or report. Every step should have a clear owner, timestamp, reason, evidence and jurisdictional context.

For analysts and BAs, vocabulary is therefore part of architecture. The words used in requirements become fields, statuses, events, buttons, dashboards, operating procedures and customer outcomes. If the words are ambiguous, the control becomes ambiguous. If the language is precise, teams can still disagree about a decision, but they will at least be disagreeing about the same thing.

References and further reading

• Financial Action Task Force (FATF), The FATF Recommendations, amended June 2026: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
• Financial Action Task Force (FATF), FATF Glossary: https://www.fatf-gafi.org/en/pages/fatf-glossary.html
• Financial Action Task Force (FATF), Guidance on Politically Exposed Persons (Recommendations 12 and 22): https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Peps-r12-r22.html
• Egmont Group, Financial Intelligence Units: https://egmontgroup.org/about/financial-intelligence-units/
• Egmont Group, About the Egmont Group: https://egmontgroup.org/about/
• Wolfsberg Group, Statement on Effective Monitoring for Suspicious Activity — responsible transition framework, 27 August 2025: https://wolfsberg-group.org/news/the-wolfsberg-group-publishes-its-second-statement-on-effective-monitoring-for-suspicious-activity/
• U.S. Financial Crimes Enforcement Network (FinCEN), Frequently Asked Questions Regarding the FinCEN Suspicious Activity Report: https://www.fincen.gov/resources/frequently-asked-questions-regarding-fincen-suspicious-activity-report-sar
• U.S. Financial Crimes Enforcement Network (FinCEN), Frequently Asked Questions Regarding Suspicious Activity Reporting Requirements, 9 October 2025: https://www.fincen.gov/resources/statutes-regulations/guidance/frequently-asked-questions-regarding-suspicious-activity
• U.S. Financial Crimes Enforcement Network (FinCEN), Suspicious Activity Report Supporting Documentation: https://www.fincen.gov/resources/statutes-regulations/guidance/suspicious-activity-report-supporting-documentation
• U.S. Department of the Treasury, Office of Foreign Assets Control (OFAC), FAQ 9 — blocked property: https://ofac.treasury.gov/faqs/9
• U.S. Department of the Treasury, Office of Foreign Assets Control (OFAC), FAQ 36 — blocking and rejecting transactions: https://ofac.treasury.gov/faqs/36
• UK Office of Financial Sanctions Implementation (OFSI), UK financial sanctions general guidance: https://www.gov.uk/government/publications/financial-sanctions-general-guidance/uk-financial-sanctions-general-guidance
• UK Office of Financial Sanctions Implementation (OFSI), Reporting information to OFSI — what to do: https://www.gov.uk/guidance/suspected-breach-of-financial-sanctions-what-to-do

Deep practitioner expansion: turning vocabulary into requirements, data and safe operational states

A glossary becomes valuable when it changes delivery behaviour. Financial-crime terminology should be reflected consistently in requirements, APIs, database fields, workflow states, user interfaces, management information and test cases. If the written definition says “potential match” but the API returns sanctioned=true before an analyst confirms the identity, the system is teaching a stronger legal conclusion than the control has actually reached.

Define nouns before verbs

Before a team designs workflow actions, it should define the business objects.

A party is not necessarily the same as a customer. A customer has a relationship with the bank; a party can be a beneficiary, beneficial owner, director, correspondent bank or other participant without being a direct customer.

An account is not the same as a relationship. One customer can have many accounts, products and legal-entity relationships.

A transaction is not always the same as a payment instruction. An instruction can generate several processing and ledger events.

A screening alert is not the same as an investigation case. Several alerts can belong to one case.

Defining these nouns first prevents workflow design from mixing fundamentally different objects.

Party versus customer versus user

Digital channels make this distinction important.

The customer is the person or entity holding the banking relationship. The user is the person operating the channel. A corporate treasurer may be a user authorised to act for a corporate customer. A beneficial owner can be a party related to the customer without having channel access.

Fraud, AML and entitlement controls use these identities differently.

A data model that stores only one “customer name” field cannot represent these relationships accurately.

Customer ID versus party ID

Many large banks have several identifiers for the same real-world person or entity because relationships were created in different legal entities or legacy systems.

Financial-crime platforms should understand the distinction between a local customer identifier and a broader party or enterprise identifier.

Entity resolution may link records that appear to represent the same person, but the link should preserve confidence and provenance. The bank should not merge customers merely because names are similar.

Relationship

A relationship connects two business objects.

Examples include:

• customer owns account;
• person controls company;
• director manages company;
• user is authorised for account;
• customer pays beneficiary;
• two customers share device;
• company is respondent bank of correspondent.

Financial crime is often visible in relationships rather than isolated records. Therefore relationship type, start/end dates and source evidence are important data.

Event

An event is something that happened at a point in time.

Examples include onboarding, login, beneficiary creation, payment initiation, sanctions-list update, alert creation, customer-risk change or law-enforcement request.

Event-based architectures can improve investigation because analysts can see sequence: password reset → new device → new beneficiary → large payment → fraud complaint.

Sequence can be more informative than any single fact.

State versus event

A state describes the current condition of an object. An event records a change or occurrence.

For example, payment_status = held is a state. payment_held_at 10:32 because sanctions review opened is an event.

Good systems retain both. The current state supports operations; event history supports audit and investigation.

Risk factor versus risk driver

A risk factor is information associated with risk, such as geography, industry or PEP status.

A risk driver explains why a particular customer or activity received its assessed risk level.

The distinction is useful because customer-risk scores should expose meaningful drivers rather than only a final number.

For example, “High risk because complex ownership + high-risk geography + correspondent product” is more actionable than “Risk score 83.”

Indicator versus typology

An indicator is an observed feature that may be relevant.

A typology is a broader pattern describing how financial crime may operate.

Repeated small inbound credits are an indicator. A mule-account typology may combine unrelated inbound senders, rapid onward movement, new device, cash-out and links to other accounts.

Monitoring scenarios often translate typologies into combinations of measurable indicators.

Detection versus decision

A detection identifies something for review.

A decision determines what the bank will do.

This distinction should be visible in architecture.

A screening engine detects a potential name match. A case workflow resolves identity and legal applicability. A transaction-control service enforces the decision.

Collapsing detection and decision into one black box can make audit and override governance difficult.

Decision versus action

A decision and the resulting operational action can also be distinct.

Decision: the applicable sanctions restriction requires an asset freeze.

Action: freeze account, block payment, report to authority.

One decision can generate several actions, each with its own execution status.

This matters because a case can be decided correctly while operational enforcement fails. The bank needs to monitor both.

Action status

Financial-crime systems should record whether required actions completed successfully.

Examples:

• account restriction requested;
• restriction applied;
• report prepared;
• report submitted;
• authority acknowledgement received;
• customer exit initiated;
• customer exit completed.

A case should not necessarily be considered fully complete just because the decision was recorded.

Potential match versus confirmed match

A potential match is a detection result. A confirmed match is a resolved identity conclusion.

For sanctions, a further question can remain: does the relevant legal regime apply to the transaction or entity?

Therefore some operating models distinguish:

1. name/identifier potential match;
2. identity confirmed or rejected;
3. legal applicability assessed;
4. required action determined.

This staged model prevents screening logic from making legal conclusions it is not designed to make.

False positive versus non-match

A false positive normally means the system generated an alert that review determined was not the target or concern.

A non-match can mean the screening engine never generated an alert.

Those outcomes should not be conflated in analytics. False-positive rates measure the burden of generated alerts; non-match populations measure screened transactions that did not cross alert thresholds.

True positive terminology

In analytical contexts, teams sometimes use true positive to mean an alert correctly identified relevant risk.

In sanctions operations, true match is often clearer for identity matching.

In transaction monitoring, “true positive” can be ambiguous because an alert may be useful without proving crime. Teams should define the term carefully before using it as a KPI.

Suspicious versus unusual

Unusual means activity differs from expected behaviour or peer patterns.

Suspicious is a stronger judgement reached after considering context under the applicable legal and policy threshold.

Unusual activity can be completely legitimate.

A monitoring system should therefore not label every anomaly as suspicious.

Explainable versus proven

An analyst may conclude that activity is explained based on credible evidence. That does not mean the bank has proven the customer’s entire economic activity is lawful.

The case decision is limited to the evidence and question under review.

Precise wording prevents case notes from making claims beyond the bank’s knowledge.

Customer statement versus verified fact

A customer can say that funds came from property sale. That is a customer statement.

A sale agreement, bank statement and registry evidence can support verification.

Case systems should allow analysts to distinguish what the customer asserted from what the bank independently verified.

This improves evidence quality.

Source of information

Every material fact should have a source where possible:

• customer declaration;
• official registry;
• identity document;
• bank transaction data;
• commercial database;
• media source;
• law-enforcement request;
• internal fraud intelligence.

Source quality influences how much weight the investigator should place on the fact.

Confidence

Analytical systems increasingly attach confidence to entity resolution, matches or classifications.

A confidence score should not be presented as certainty. The bank should define what the score means, how it was produced and what decisions it can support.

For example, an 85% entity-match confidence is not the same as 85% probability that a customer committed financial crime.

Rule version and model version

Every material detection should be traceable to the rule or model version that generated it.

This matters after tuning. If a regulator asks why an alert did not generate in March, the bank must know which thresholds and model parameters were active in March rather than rerunning the transaction through today’s configuration and assuming the result is equivalent.

List source versus list provider

Sanctions data can originate from an official authority but be distributed through a commercial provider.

The bank should distinguish the authoritative source from the data provider that normalises and distributes it.

This helps investigate list-update delays and data discrepancies.

Effective date versus ingestion date

A designation can have a legal effective time and a later system ingestion time.

Both should be recorded. The gap between them can be operationally important.

Similarly, a customer-risk change can be legally or operationally effective at one time and technically propagated to another system later.

Real-time versus near-real-time

Teams frequently use “real-time” loosely.

Real-time often implies processing in the transaction path with immediate or near-immediate outcome.

Near-real-time can mean processing within seconds or minutes after an event.

The architecture requirement should specify the actual latency expectation, not rely on the label.

Batch

Batch means items are processed as a group at scheduled or triggered intervals.

Batch is not automatically outdated or weak. Many controls can operate effectively in batch where the risk does not require immediate intervention.

The control design should match the risk and settlement speed.

Hold versus pending

A hold should indicate that processing is deliberately prevented pending a condition or decision.

Pending can simply mean processing has not completed yet.

If the UI uses the same status for both, operations may not know whether manual action is required.

Reject versus decline

Banks may use these words differently.

A decline often describes a risk or business decision not to authorise a transaction. A reject can describe technical or scheme-level refusal.

The exact internal terminology should be defined by product and rail.

What matters is that systems do not treat the words as universal synonyms without context.

Freeze versus restriction

A freeze can carry a specific legal meaning under sanctions or court orders.

A restriction is a broader bank control that can prevent some account activities for many reasons.

Using “freeze” for an internal risk restriction can cause serious misunderstanding in customer service and regulatory reporting.

Exit versus closure

Customer exit is a governed decision to end a relationship.

Account closure is the operational action that terminates an account.

A customer can have several accounts and products, so relationship exit may require multiple operational closures and settlement of balances.

The case should distinguish decision from execution.

De-risking versus risk-based exit

De-risking often refers to broad withdrawal from categories of customers or sectors without sufficiently granular risk assessment.

A risk-based exit is a customer-specific or exposure-specific decision that residual risk cannot be managed within law and appetite.

The distinction matters in policy and management information.

Remediation versus retrospective review

Remediation corrects a weakness or affected data/customer population.

A retrospective review looks back at historical activity to assess whether past control failure may have missed risk.

A remediation programme may require both: fix the control and review the period when it was ineffective.

Lookback

A lookback is a retrospective review over a defined historical period, often after a control deficiency.

The scope should define population, dates, methodology, thresholds, QA and reporting.

Lookbacks can be resource intensive and should be governed like major investigations.

Back-testing

Back-testing applies a control or model to historical data to assess performance.

It is not the same as a regulatory lookback, although both use past data.

Back-testing is often part of model or scenario validation; lookbacks can be remediation obligations.

Tuning

Tuning changes thresholds, matching parameters or other configuration to improve control performance.

Tuning should be risk based and documented.

“Reduce alerts by 30%” is not a sufficient tuning rationale without evidence that detection effectiveness is preserved.

Calibration

Calibration sets or adjusts model parameters based on data and desired performance within approved methodology.

Banks use the term differently; internal model-governance definitions should apply.

Validation

Validation is independent or appropriately segregated assessment that a model or control is conceptually sound, correctly implemented and performing as intended.

Validation is different from ordinary user acceptance testing.

UAT versus control testing

User acceptance testing checks whether a system meets business requirements before release.

Control testing assesses whether a control is appropriately designed and/or operating effectively.

A feature can pass UAT and still be a weak control if the requirement itself was incomplete.

Design effectiveness versus operating effectiveness

Design effectiveness asks whether the control, if performed as designed, can address the risk.

Operating effectiveness asks whether it actually operates consistently in practice.

A perfect design with 40% execution failure is not an effective control.

Preventive versus detective timing

The label should reflect when the control acts.

A sanctions screen before release is preventive. A monitoring scenario identifying activity the next day is detective. A post-event account restriction can be corrective or preventive for future activity.

The same technology can support several control types depending on timing.

Materiality

Materiality describes significance. It can reflect legal exposure, financial impact, customer harm, transaction volume, duration or control importance.

Materiality is context dependent. A small-value terrorist-financing indicator can be highly material despite low monetary amount.

Severity versus priority

Severity describes impact or seriousness.

Priority describes how urgently work should be handled.

They often correlate but are not identical. A severe issue with strong temporary mitigation may have different immediate priority from a rapidly developing operational incident.

SLA versus ageing bucket

An SLA is a defined service expectation. An ageing bucket is a reporting category, such as 0–2 days or 3–5 days.

An item can be in the oldest ageing bucket but still within a long SLA, or breach a short regulatory deadline while appearing in a normal operational bucket.

Dashboards should make the distinction visible.

Manual review versus human-in-the-loop

A manual review can mean a human performs most of the analysis.

Human-in-the-loop usually means automated decisioning includes a defined point where a person reviews, approves or overrides.

The design should state what the human is expected to judge and what evidence the system provides.

Human override versus exception

A human override changes a system outcome within approved authority.

A policy exception permits departure from a requirement under governance.

They are not automatically the same. An analyst may override a fraud score within normal procedure without creating a policy exception.

Machine learning terminology

Financial-crime teams should be careful with AI terms.

A model can assist prioritisation, anomaly detection, entity resolution or narrative support. The use of AI does not change the underlying legal accountability.

Terms such as “AI confirmed suspicious” should be avoided unless the bank has explicitly defined and governed such decision authority. In most cases, the model produces a signal or recommendation, while an accountable process makes the decision.

Explainability

Explainability means users and reviewers can understand material factors influencing an analytical result to the level needed for its use.

The appropriate depth depends on the model and decision. A sanctions analyst needs to understand why two names matched. A regulator reviewing customer-risk scoring may need visibility into factor weights and overrides.

Data drift and model drift

Data drift means the characteristics of input data change over time.

Model drift describes deterioration or change in model performance as patterns evolve.

Financial-crime analytics should monitor both, particularly where customer behaviour or criminal typologies change rapidly.

Entity resolution

Entity resolution links records believed to represent the same real-world person or entity.

It can use name, address, date of birth, identifiers, devices and other data.

Incorrect merging can contaminate investigations; missed merging can hide networks. Confidence and provenance matter.

Network link versus relationship evidence

A graph can show two accounts share an address or device. That is a network link.

It does not automatically prove that the customers know each other or participate in the same criminal network.

Analysts should verify the meaning of the link before drawing conclusions.

Taxonomy versus ontology

A taxonomy classifies objects into categories.

An ontology describes entities and the relationships between them.

Financial-crime platforms often need both: a taxonomy of alert types and a relationship model connecting customers, accounts, payments and parties.

BAs do not need academic terminology, but they should understand whether they are classifying things or modelling how things relate.

Canonical data model

A canonical model provides a common representation used across systems.

For financial crime, a canonical payment or party model can reduce repeated field mapping. It should not erase source-specific detail needed for legal or investigative use.

Canonical does not mean “throw away the original.”

Data enrichment

Enrichment adds information to an existing object.

Examples include country risk, PEP status, beneficiary-bank details or network features.

The system should distinguish source data from enrichment so investigators know which fields came from the customer and which were derived later.

Derived feature

A derived feature is calculated from other data, such as transaction velocity over 24 hours or number of new beneficiaries in seven days.

Derived features should have documented logic and time window because they can materially affect analytical results.

Golden record versus investigation view

A golden record is an authoritative representation of a customer or object.

An investigation view may intentionally show several conflicting source values because discrepancies can themselves be relevant.

Investigators should not always see only the cleaned master record if source differences matter to the case.

Redaction versus masking

Redaction permanently or presentation-wise removes information from a disclosed document.

Masking hides or obscures data for certain users while retaining the underlying value.

Access and disclosure requirements should specify which is intended.

Need-to-know

Need-to-know access limits sensitive information to users who require it for their role or case.

Suspicious reports, law-enforcement requests and sanctions investigations can require stronger access controls than normal customer data.

Role-based access alone may not be enough; case-level restrictions can be needed.

Maker-checker

Maker-checker requires one user to initiate a change and another authorised user to approve it.

It is a common segregation-of-duties pattern for high-risk changes such as payment release, rule configuration or customer restriction.

Four-eyes principle

The four-eyes principle is a broader concept requiring at least two appropriately authorised people to participate in a decision or action.

Maker-checker is one implementation of it.

Reconciliation

A reconciliation proves that two populations or values align and identifies breaks.

For financial crime, a monitoring-feed reconciliation can compare payment source transactions with transactions received by the monitoring platform.

Reconciliation is one of the most effective controls against silent data loss.

Completeness versus accuracy

Completeness asks whether all required records or fields are present.

Accuracy asks whether the values are correct.

A dataset can be complete but inaccurate, or accurate for the records present while missing 10% of transactions.

Financial-crime data controls need both.

Timeliness

Timeliness asks whether data arrives soon enough for the control purpose.

A sanctions list received two days late can be complete and accurate but operationally ineffective.

A transaction feed arriving after a regulatory reporting deadline is also too late.

Control evidence versus business evidence

Business evidence supports the underlying customer or transaction decision: contract, invoice, identity document.

Control evidence proves the bank performed the required control: screening timestamp, approval record, QA result.

Investigations can need both.

Audit evidence

Audit evidence should be sufficiently reliable and retrievable for independent review.

Screenshots can be useful but are often weaker than system-generated logs because they may not show full context or provenance.

Where possible, controls should generate structured evidence automatically.

Semantic versioning of business rules

Even when a bank does not use software-style semantic versioning, business rules should have explicit versions.

A monitoring rule changed on September 1 should be distinguishable from the August rule. Analysts reviewing old alerts should know which logic generated them.

This reduces confusion during validation and regulatory review.

Common-language pattern for requirements

A strong financial-crime requirement normally states:

Actor or system + trigger + data + control + decision/state + evidence + exception path.

Example:

“When a payment contains a beneficiary name change after an earlier sanctions-screening result, the payment service shall invalidate the prior screening decision, submit the updated configured party fields for rescreening, keep the payment in refer state until a valid result is returned, and retain both screening events in the audit trail.”

This structure forces precision.

Data dictionary discipline

Every important data field should have a definition, format, source, owner and allowed values.

Fields such as risk_status, sanctions_status and case_status are too vague without definitions.

A good dictionary prevents different systems from assigning different meanings to the same label.

API contract discipline

API responses should carry precise statuses.

For example, a screening service might return CLEAR, POTENTIAL_MATCH, ERROR, NOT_SCREENED rather than a boolean passed=true/false. The richer contract lets downstream systems distinguish a clean result from a technical failure.

Similarly, a fraud service should distinguish APPROVE, DECLINE, REFER, CHALLENGE rather than a single risk score unless downstream logic is explicitly responsible for the decision.

Error state versus risk state

A system error is not a financial-crime decision.

If screening times out, the result should be ERROR or UNAVAILABLE, not CLEAR.

This distinction is critical to fail-safe behaviour.

Unknown versus not applicable

Unknown means the value should exist but is not known.

Not applicable means the field does not apply to the object.

Mixing these states creates data-quality blindness. An unknown beneficial owner should not be treated as if beneficial ownership is not applicable.

Null versus zero

The same principle applies to numeric data.

A missing transaction count is not the same as zero transactions. A missing ownership percentage is not 0% ownership.

BAs should specify null semantics for important risk data.

Operational naming test

Before approving a label, ask whether a front-line colleague, investigator, developer, auditor and regulator would interpret it the same way.

If not, either change the term or add a clear definition.

Practitioner checkpoint

Financial-crime terminology is mature when the same concepts appear consistently across policy, workflow, data and user interfaces; ambiguous words are qualified; system errors are separated from risk decisions; legal conclusions require the appropriate evidence; and every important state has a defined owner and transition.

Precise language is not bureaucracy. It is one of the cheapest controls a bank can build.

Practice exercise — work through this before reading on.

Practitioner exercises: use the vocabulary before you build

The quickest way to test whether a team really understands financial-crime language is to give it an ambiguous sentence and require the team to turn it into a precise operational statement.

Exercise 1 — “The AML hit blocked the payment”

Questions to resolve:

• Was the detection from sanctions screening, transaction monitoring or fraud?
• Was it a potential match or a confirmed match?
• Was the payment held pending review, rejected, blocked or frozen?
• Which legal entity processed it?
• Which sanctions regime or policy applied?
• Who made the decision?
• What evidence and list version were used?

A precise statement might become: “Payment sanctions screening generated a potential name match. The payment remained in refer status until the sanctions analyst resolved the alert. After identifier review confirmed a false positive, the authorised user released the payment. The screening result, list version, analyst rationale and release timestamp were retained.”

That statement can be designed, tested and audited.

Exercise 2 — “The customer is suspicious because they are high risk”

The statement incorrectly merges risk and suspicion.

A better version could be: “The customer is rated high risk because of complex ownership and geographic exposure. Enhanced due diligence and enhanced monitoring apply. A separate investigation will determine whether observed activity creates suspicion under the applicable reporting standard.”

Exercise 3 — “The transaction passed AML”

There is normally no single universal AML pass.

Clarify whether the payment passed sanctions screening, fraud decisioning and account restrictions, and whether post-transaction monitoring can still generate an alert later.

The corrected operational language could be: “The payment completed the preventive controls required before release. It remains in scope for ongoing transaction monitoring.”

Exercise 4 — “Close the case and unblock the customer”

Clarify whether closing the investigation automatically removes an account restriction. It may not. The restriction can have a separate owner, legal basis or action status.

The workflow should model case disposition and operational restriction as separate but linked objects.

Vocabulary acceptance criteria

Before a financial-crime term enters a global product, require these acceptance criteria:

1. The term has one documented core meaning.
2. Jurisdiction-specific meanings are identified where relevant.
3. The data owner and system of record are defined.
4. Valid states and transitions are defined.
5. Customer-facing wording is assessed separately from internal wording.
6. The term does not imply guilt or legal status beyond the evidence.
7. API and database values use the same semantic model.
8. Test cases verify both happy path and ambiguous/error states.
9. MI definitions use the same meaning as operational systems.
10. Historical versions remain interpretable after terminology changes.

Final distinction map

The following distinctions should become instinctive for an analyst or BA:

• high risk ≠ suspicious;
• red flag ≠ proof;
• alert ≠ case conclusion;
• potential match ≠ true match;
• screening ≠ transaction monitoring;
• fraud authorisation ≠ payment legitimacy;
• PEP ≠ prohibited customer;
• hold ≠ freeze;
• reject ≠ return;
• report filed ≠ crime proven;
• legal entity ≠ banking brand;
• original data ≠ normalised data;
• workflow state ≠ legal outcome;
• decision recorded ≠ action successfully executed;
• system error ≠ clean result.

Final takeaway

Precise terminology is a control mechanism. It prevents systems from overstating conclusions, prevents operations from acting on ambiguous states, prevents BAs from writing untestable requirements and helps investigators explain decisions clearly to audit, supervisors and authorities.

The strongest financial-crime platforms use the same language from policy through data model, API, workflow, user interface, management information and assurance.

When the words are precise, ownership and evidence become easier to design. When the words are vague, the ambiguity eventually appears as a control defect.

Chapter 10 Masterclass — Vocabulary as Requirements, Data and Control

Vocabulary becomes operational risk when one word is allowed to describe several different states. A strong BA, analyst or product owner does not only know definitions. They make sure the definitions survive into requirements, APIs, database fields, workflow states, user interfaces, management information and tests.

If a policy says potential match but an API sets sanctioned=true before an analyst resolves identity and legal applicability, the technology has silently converted a detection signal into a legal conclusion.

Never design around “AML check”

“AML check” is too vague to be a usable requirement. It may mean identity verification, sanctions screening, PEP screening, customer-risk assessment, transaction monitoring, fraud analytics, source-of-funds review or manual investigation.

Instead of:

Perform AML check before payment.

Write:

Before release, screen the configured payment parties and data elements required by the applicable sanctions-control design against the current approved screening data set; route unresolved potential matches to the authorised review queue and retain the screening event, list state, disposition, decision evidence and user/service identity.

The second statement can be designed, tested and audited.

The core object model

A practical financial-crime platform should distinguish its nouns before designing actions.

Party — a real-world person, organisation or other entity represented in data.

Customer — a party or organisation with a relationship to the bank.

User — a person or technical identity acting through a channel or system.

Relationship — a typed link between objects, such as person controls company or customer owns account.

Account/product — the financial relationship or service used.

Instruction — an order or request to perform an action, such as a payment instruction.

Transaction/event — something that occurred and can be placed in time.

Indicator/red flag — a fact or pattern that may be relevant to risk.

Alert — a generated prompt for review.

Case — a managed work container linking evidence, alerts, parties and decisions.

Decision/disposition — the conclusion reached for the question under review.

Action — what the bank does because of the decision.

Regulatory outcome — filing, authority notification or other external outcome where applicable.

If the data model uses one table called aml_case for all of these, ambiguity will eventually appear in workflows and reporting.

Event → indicator → alert → case → decision → outcome

These stages should not be collapsed.

A payment event occurs.

A rule identifies an indicator or combination of features.

The control generates an alert.

The alert may be linked to an existing case or create a new one.

An investigator reaches a decision/disposition based on facts and applicable policy.

That decision can create one or more operational outcomes and, separately, a regulatory outcome.

Examples:

• alert closes with no escalation;
• case remains open because several alerts are still under review;
• suspicion is formed and a report is filed;
• relationship review begins independently of the filing decision;
• an applicable sanctions restriction leads to the legally required operational action and any separate authority-reporting obligation;
• fraud decision declines one payment while AML monitoring continues on the receiving account.

This staged model protects the bank from turning every signal into an accusation.

Risk is not suspicion

This distinction is foundational.

Risk determines control intensity and governance.

Suspicion is a judgement reached under an applicable legal/policy framework after relevant facts are considered.

A PEP can be high risk and entirely legitimate. A low-risk customer can behave suspiciously. A customer from a higher-risk geography is not automatically suspicious.

Therefore avoid fields such as suspicious_customer = true merely because risk_rating = high.

Detection is not decision, and decision is not action

A sanctions engine may detect name similarity. An analyst/specialist may determine whether the party is the listed subject. A further assessment may determine legal applicability. An operational service then enforces the required action.

These are separate concepts:

Detection — something requires review.

Identity disposition — the party is or is not the relevant target.

Legal/risk decision — applicable requirements and facts determine what must happen.

Operational action — payment held/rejected, account restricted, report submitted, customer review initiated, etc.

A control can reach the correct decision and still fail if the downstream action is not executed. Action status therefore deserves its own lifecycle.

Potential match, false positive and true match

Use precise screening language.

Potential match — screening similarity is sufficient to require review.

False positive — review determines the subject is not the relevant target.

True/confirmed match — review establishes the relevant identity according to the bank’s process.

Avoid using hit without qualification. It is often interpreted differently by developers, analysts and business users.

Even a confirmed identity may still require separate assessment of the relevant regime, ownership/control, nexus, licence or transaction facts before the operational action is known.

Unusual is not suspicious

An unusual event differs from expected behaviour or peer patterns. Suspicion is a stronger judgement.

Anomaly detection can be useful, but a machine-generated anomaly should not be labelled suspicious=true unless the bank has deliberately defined and governed that outcome.

The same principle applies to AI: an AI-generated prioritisation or recommendation does not remove the accountable human/process decision unless governance explicitly establishes that authority.

Payment-state vocabulary

Payment projects frequently fail because operational and financial-crime states are mixed.

Pending — processing has not completed.

Held/referred — processing is deliberately paused pending a decision.

Declined — a bank/risk decision does not permit the transaction to proceed in the relevant process.

Rejected — often a technical, validation, bank or scheme refusal depending on the rail; define it locally.

Returned — value/instruction progressed and is sent back according to the relevant payment process.

Recall requested — recovery/reversal has been requested; recovery is not guaranteed.

Blocked/frozen — may carry specific legal meaning under sanctions or court orders; do not use as generic synonyms for “under review.”

A mobile UI, payment hub, screening platform and investigation system may need different state vocabularies connected through an explicit mapping.

Customer-state vocabulary

Do not mix risk rating with relationship state.

Possible independent dimensions are:

Risk rating: low / medium / high or the bank’s approved scale.

CDD state: not started / in progress / complete / refresh due / overdue.

Relationship state: onboarding / active / restricted / exit approved / closing / closed.

Screening state: clear / potential match / under review / resolved.

Investigation state: no case / case open / awaiting information / decision pending / closed.

Reporting state: not applicable / assessment pending / filing approved / submitted / acknowledged, with strict access controls where required.

One giant customer_status field cannot safely represent all of these.

Source of funds versus source of wealth

Source of funds explains where specific money comes from.

Source of wealth explains how broader wealth was accumulated.

A property-sale contract and bank credit may support the source of funds for one transaction. Career history, business ownership, investments and inheritance can support source of wealth.

If one upload category is called SOF_SOW, analysts and reporting cannot reliably tell which question the evidence answers.

Ownership versus control

Direct shareholder, indirect shareholder, beneficial owner, controller, director, trustee, settlor, beneficiary and authorised signatory are not interchangeable roles.

Requirements should model the relationship type and effective period. For sanctions and AML, a person may be relevant because of control even without the largest direct ownership percentage.

Customer statement versus verified fact

A customer saying “the funds are proceeds of property sale” is a customer statement.

A reviewed sale agreement, registry entry and bank transaction can support verification.

Investigation systems should preserve source and verification status rather than converting all entered information into “fact.”

Useful evidence attributes include:

• source;
• collection date;
• effective date;
• verifier;
• verification method;
• confidence/reliability where used;
• linked object/case;
• expiry or refresh requirement.

Rule version, model version and list state

Historical reconstruction requires temporal precision.

A case should be able to answer:

• which rule/scenario/model version generated the alert;
• which parameters or thresholds were active;
• which sanctions-list state was used;
• when the source data became effective;
• when the system ingested it;
• which configuration was active at decision time.

Re-running an old transaction through today’s model is not evidence of what happened historically.

Error state is not risk state

A technical timeout must never masquerade as a clean risk result.

For example, a screening service contract should distinguish:

• CLEAR;
• POTENTIAL_MATCH;
• ERROR;
• UNAVAILABLE;
• NOT_SCREENED where relevant.

A Boolean passed=true/false cannot safely distinguish a clean result from a service failure.

Likewise, UNKNOWN is not the same as NOT_APPLICABLE, and NULL is not the same as zero.

These are small data-design distinctions with major control consequences.

Controlled vocabulary governance

Critical terms should be governed like data standards.

For each term, maintain:

• preferred term;
• precise definition;
• object/domain to which it applies;
• allowed values;
• synonyms to avoid or map;
• jurisdiction/scheme qualification where relevant;
• source/owner;
• effective date/version;
• systems/interfaces using it.

Examples of terms requiring governance include case, alert, match, customer, party, beneficial owner, suspicion, hold, freeze, return, restriction, risk acceptance, control failure and regulatory report.

When a term changes, impacted APIs, reports, UI labels and test cases should be assessed.

Canonical model does not mean erase the source

A canonical model can make integration easier by giving parties, payments and cases common structures. But investigation often depends on original values.

Preserve:

source value — exactly what upstream supplied;

normalised value — transformed into a consistent technical representation;

enriched value — added by internal/external services;

derived feature — calculated from other facts;

display value — user-friendly representation.

Those categories should not be silently overwritten into one field.

Requirement pattern: actor + trigger + data + decision + state + evidence + exception

A strong requirement usually states seven things.

Actor/system — who/what performs the control?

Trigger — what starts it?

Data — which information is evaluated?

Decision/control — what question is answered?

State/outcome — what happens next?

Evidence — what is retained?

Exception path — what happens when the control cannot complete normally?

Example:

When an authorised payment-repair user changes a beneficiary field that is configured as material to sanctions screening, the payment service shall invalidate the prior screening completion state, retain original and amended values with user and timestamp, resubmit the configured screening fields, prevent release while the new screening result is unresolved, and retain both screening events and dispositions.

That is a testable requirement. “Rescreen when needed” is not.

Requirement anti-patterns

“System should support AML.”

Too broad. Name the actual control and outcome.

“If risky, block customer.”

Conflates risk rating, decision authority and operational/legal restriction.

“Sanctions hit = true.”

Conflates detection with identity/legal disposition.

“Case closed when report submitted.”

May be false: operational actions, relationship review or authority follow-up can remain open.

“All alerts must be reviewed in real time.”

Undefined latency and likely inappropriate for controls intended to operate post-event.

“Store audit trail.”

Does not define which events, attributes, actors or historical values must be retained.

API contract example

A screening response should expose enough semantic information for downstream systems to behave safely. A conceptual contract might include:

• screeningEventId;
• paymentVersion;
• status = CLEAR | POTENTIAL_MATCH | ERROR | NOT_SCREENED;
• candidateCount;
• listStateId;
• screenedAt;
• requiresHumanReview;
• decisionId once resolved;
• disposition once resolved;
• operationalAction separately;
• reasonCode;
• evidenceReference.

The names are illustrative. The important point is semantic separation.

Acceptance tests should test meaning, not only code

Include tests that prove:

• a potential match is never displayed as a confirmed match;
• high-risk customer is not automatically labelled suspicious;
• held payment is not shown as final rejection;
• returned payment remains distinguishable from rejected instruction;
• screening timeout cannot produce a clean result;
• unknown beneficial-owner data is distinguishable from not applicable;
• source-of-funds and source-of-wealth evidence remain separate;
• customer risk rating and relationship state are independent;
• one case can link multiple alerts and transactions;
• alert closure does not automatically close a wider case;
• suspicious-report information is access restricted;
• rule/list/model version is reconstructable historically;
• repaired payment retains original values and new screening event;
• operational action failure remains visible after a correct decision;
• customer-facing wording does not expose protected investigative rationale.

Practice exercise — work through this before reading on.

BA exercise — repair the vocabulary

Rewrite these statements into precise requirements:

1. “Block any high-risk customer.”
2. “AML check failed.”
3. “Sanctions hit found.”
4. “Case is closed after SAR.”
5. “Payment rejected for review.”
6. “Beneficial owner missing means N/A.”
7. “AI says suspicious.”
8. “All transactions monitored in real time.”
9. “Fraud alert and AML alert are the same case.”
10. “Customer is cleared forever after screening.”

For each, identify which nouns, states, decisions, evidence and time dimensions are missing.

Practice exercise — work through this before reading on.

BA exercise — design the state machine

Design a sanctions-referred payment lifecycle with at least these concepts:

payment processing state, screening event state, candidate-match review state, legal/disposition state, operational action state and customer-facing state.

Test whether your model can represent all of these without contradiction:

• screening service unavailable;
• potential match under review;
• false positive resolved and payment released;
• true match identified but legal applicability still being assessed;
• payment held while licence evidence is checked;
• operational restriction requested but not yet applied;
• final rejection/return;
• later authority reporting completed.

If one status field cannot represent the scenario, that is expected — the correct answer is usually multiple related state dimensions.

Reconstruction acceptance criterion

For every material financial-crime control, consider a requirement like:

An appropriately authorised reviewer shall be able to reconstruct the source data, rule/model/list version, system decisions, human decisions, evidence, overrides, operational actions and timestamps that produced the historical outcome, subject to applicable retention and access rules.

That one principle improves auditability across onboarding, screening, monitoring, investigations, payments and regulatory reporting.

Masterclass takeaways

• Precise vocabulary is a control, not editorial polish.
• Define objects before designing workflows.
• Separate event, indicator, alert, case, decision, action and regulatory outcome.
• Separate risk from suspicion, detection from judgement, and judgement from execution.
• Temporary operational states must not masquerade as legal conclusions.
• Errors, unknowns and not-applicable states require explicit semantics.
• Controlled vocabulary should be governed across policy, APIs, UI, MI and test cases.
• Historical reconstruction requires versioned rules, data and decisions.
• A strong BA requirement names trigger, data, decision, state, evidence and exception path.

Educational note: terms such as suspicious activity report/suspicious transaction report, block, freeze, reject, return, beneficial owner and PEP can have jurisdiction- or scheme-specific legal meanings. Always use the definitions applicable to the relevant bank legal entity, regulatory framework and payment rail.

Further worked cases and independent practice

Use these explanations to apply the chapter's concepts. Read the lesson first, then allow additional time for the exercises and diagram interpretation. Exercise time is additional to the reading estimate.

Why precise words matter

Financial-crime delivery fails when words that sound similar are treated as interchangeable. A red flag is not an alert. An alert is not a case. A potential sanctions match is not a confirmed identity match. A confirmed identity match is not automatically the same as a legal block or freeze. Unusual activity is not automatically suspicious activity. Customer restriction, payment hold, sanctions freeze and account closure are different states with different causes and consequences.

For analysts and BAs, terminology is part of the control design. If requirements say "block suspicious payments" without defining who decides suspicion, what block means, how long it lasts and whether the action is legal or policy-based, developers will fill the gaps themselves. That creates inconsistent behaviour and weak auditability.

Practice exercise — work through this before reading on.

State-model exercise

Design the lifecycle for a sanctions screening alert. Suggested states might include generated, triaged, false positive, potential match, escalated, confirmed identity match, legal applicability review, released, rejected, blocked/frozen and externally reported. Do not assume all organisations use those exact labels. The exercise is to define the meaning, entry condition, exit condition, decision owner and evidence for every state.

Then design a separate AML alert lifecycle: generated, triaged, escalated to case, investigation in progress, closed without suspicion, suspicion formed, report decision, filed, supplemental report and post-report monitoring. Compare the two lifecycles. They may share case-management technology while remaining legally different.

"Hit" is usually too vague

Teams often use "hit" to describe anything from a fuzzy name similarity to a confirmed sanctions match. That word can hide important distinctions. A search engine may produce a candidate. An analyst may decide the candidate is a possible identity match. Additional identifiers may confirm the identity. Legal analysis may then determine whether the applicable regime restricts the party, entity or property. Each step has different evidence.

Requirements should therefore describe the actual object. "Screening candidate" is clearer than "hit." "Potential match pending analyst resolution" is clearer than "positive." "Confirmed designated-party identity under UK sanctions screening" is clearer still, while the final operational disposition should state the legal basis and action.

Alert, case and investigation

An alert is commonly a system-generated or operational prompt for review. A case is a controlled work item that can group alerts, customers, transactions and evidence. An investigation is the analytical activity performed within or across cases. One case can contain several alerts. One network investigation can involve several customers, each with separate relationship decisions.

This matters for data design. If every alert automatically becomes an independent case, investigators can lose network context and duplicate work. If many customers are collapsed into one case without separate decision records, customer-level actions become hard to audit.

Risk factor, red flag and suspicion

A risk factor influences the likelihood or impact of financial-crime exposure. A red flag is a fact or pattern that may be relevant to possible financial crime. Suspicion is a judgement formed under an applicable legal and policy framework after considering evidence. A threshold crossing is not, by itself, suspicion.

A bank can therefore classify a customer as high risk without suspecting wrongdoing. It can also form suspicion about a customer previously rated low risk because new behaviour and evidence change the picture.

Hold, reject, return, block and freeze

A hold is a temporary pause while the bank decides what to do. A reject means the payment instruction is not accepted or processed according to the relevant rule or decision. A return sends value back through an applicable payment process after prior movement or acceptance. A block or freeze under sanctions can represent a legal restriction on dealing with property or funds. The exact legal terminology and mechanics differ by regime.

Systems should never use one status called BLOCKED to mean all four. A temporary fraud hold should not appear in regulatory reporting as a sanctions freeze. A returned payment should preserve the reason and link to the original transaction.

Practice exercise — work through this before reading on.

Case-writing exercise

Rewrite each weak statement into evidence-based language.

"Customer is a money launderer." Better: describe the transaction pattern, ownership, unexplained economic purpose and why suspicion was formed.

"Sanctions hit confirmed." Better: state which party matched, identifiers used, list source/date, ownership or control analysis, applicable regime and resulting legal decision.

"False positive." Better: state why the candidate was resolved as a different person or entity, using date of birth, nationality, registration number, address or other identifiers.

"Customer is high risk because offshore." Better: describe specific geographic, ownership, product and behaviour factors and the control response.

Practice exercise — work through this before reading on.

Data dictionary exercise

For ten terms—customer, party, account, transaction, payment, alert, case, match, suspicion and report—write a one-sentence business definition, a unique identifier, key relationships and lifecycle owner. Then identify where the terms are currently overloaded in the organisation. This simple exercise can expose major architecture problems.

For example, "party" may include customer, beneficial owner, director, beneficiary, payer and intermediary. A customer is a party with a relationship to the bank, but not every party is a customer. That distinction matters for sanctions screening and payment investigations.

Final terminology test

Explain the difference between unusual and suspicious; alert and case; candidate and confirmed identity match; fraud hold and sanctions freeze; customer risk and transaction behaviour; source of funds and source of wealth; legal ownership and control; regulator and FIU; screening and monitoring; and rejection and return.

The learner should be able to use each term in a requirement or case note without creating ambiguity. In financial crime, precise vocabulary is not academic polish. It is part of the control.

References and further reading

• FATF — The FATF Recommendations, amended June 2026: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html

• FATF — Recommendations topic overview: https://www.fatf-gafi.org/en/topics/fatf-recommendations.html

• Basel Committee on Banking Supervision — Anti-money laundering and counter-terrorist financing, January 2026: https://www.bis.org/committees/bcbs/basel-consolidated-guidelines/module/afs/10

• Wolfsberg Group — Financial crime risk management resources: https://wolfsberg-group.org/resources

• Wolfsberg Group — Guidance on the Risk-Based Approach, June 2026: https://wolfsberg-group.org/resources/195/205

Educational note: many financial-crime terms have jurisdiction-specific legal definitions. The vocabulary in this chapter is designed for consistent banking delivery and must be mapped to applicable local law and policy.

• SWIFT — ISO 20022 standards information: https://www.swift.com/standards/iso-20022

• Institute of Internal Auditors — current Statements of Position, including Three Lines governance and assurance guidance (2026): https://www.theiia.org/en/resources/statements-of-position/

Educational note: the glossary is a banking delivery framework. Where a term has a specific legal definition in the relevant jurisdiction, that legal definition and the bank’s approved policy take precedence.