The Ten Categories in an AML Technology Stack

A bank can buy one platform with ten modules and still operate ten different controls. The boundaries matter because each control uses different data, timing, evidence, and decision authority. Procurement becomes clearer when the stack is mapped by control purpose instead of supplier packaging.

The ten categories below are an editorial taxonomy for comparing technology. They are not a regulatory classification. The FATF Recommendations describe risk-based measures and outcomes that jurisdictions implement in their own frameworks; they do not require these ten software categories or one architecture.

Detection and risk decisions

1. Transaction monitoring

Transaction monitoring examines activity across transactions and time to identify patterns that merit review. Inputs can include customer, account, counterparty, channel, and transaction data. Rules, statistical methods, machine learning, or a combination can generate alerts.

Monitoring is broader than testing a payment against a sanctions list. The Wolfsberg monitoring statement places traditional transaction monitoring within a wider practice of monitoring for suspicious activity, which can combine customer behavior and attributes with transactions. Buyers should ask which data and risks are actually covered, how missed data is detected, and how outcomes feed back into the control.

2. Customer risk rating

Customer risk rating organizes assessed risk factors into a customer-level result used to guide due diligence and ongoing treatment. Relevant factors may include customer type, geography, products, delivery channels, ownership, and observed activity, depending on policy and law.

The system should show source data, factor values, logic, overrides, version, and change history. A risk rating is not proof that a customer is suspicious. It is a governed input to risk-based decisions.

Screening controls

3. Customer and entity screening

Customer and entity screening compares people and organizations with reference data during onboarding and the relationship lifecycle. It can cover sanctions, PEPs, adverse media, internal lists, or other defined risk domains. Entity resolution uses names and available identifiers to produce candidates for review.

This category describes the matching and workflow layer across multiple screening purposes. It should not erase the different meaning of each source domain.

4. Sanctions screening

Sanctions screening seeks potential exposure to designated people, entities, vessels, locations, or other targets under applicable sanctions regimes. The Wolfsberg sanctions guidance distinguishes customer screening from transaction screening and describes both as controls within a wider compliance program.

List scope, update handling, ownership rules, matching configuration, investigation, escalation, and evidence all affect the result. Screening helps manage sanctions risk; it does not decide legal status without analysis of the relevant regime and facts.

5. PEP screening

PEP screening identifies people who may fall within an applicable politically exposed person definition, along with related persons where required. PEP status normally triggers risk-based measures; it is not an allegation or a sanctions designation.

Procurement needs include definitions by jurisdiction, role and date history, family and close-associate relationships, source provenance, dispute handling, and a workflow for enhanced due diligence. Buyers should prevent PEP data from being treated as a binary prohibition list.

6. Adverse-media screening

Adverse-media screening finds public reporting that may be relevant to financial-crime risk. The FCA’s Financial Crime Guide includes press reports, court judgments, non-governmental-organization reports, and commercial due-diligence providers among possible risk-information sources. It also identifies ignoring sustained criminal allegations from reputable sources as poor practice. That supports public reporting as a potential risk input; it does not prescribe this product category or one screening workflow.

From an editorial buyer-evaluation perspective, useful evidence would show whether a system preserves the article source and date, links the correct subject, categorizes the risk, handles duplicates and corrections transparently, and supports human review. These are procurement criteria, not regulator-mandated features. Sentiment or a keyword hit should not become an unexplained customer decision.

7. Payment screening

Payment screening evaluates payment messages and related parties against sanctions or other defined reference data, often before processing completes. The input can include originators, beneficiaries, banks, free text, locations, vessels, and other message fields depending on the payment type and policy.

Latency, message parsing, field treatment, hold and release controls, list updates, and repair workflows are central. Payment screening does not replace behavioral monitoring: a transaction can be suspicious without naming a listed party.

Investigation and identity

8. Case management

Case management organizes alerts, referrals, evidence, tasks, decisions, approvals, reporting handoffs, and feedback. It is the system of work around investigation. It may link records or help prioritize queues, but that does not make it the source of every detection.

Buyers should focus on lineage, access control, audit history, evidence export, queue governance, quality review, and migration. Productivity measures need a quality measure beside them; closing cases faster is not a useful outcome if reasoning becomes weaker.

9. KYC and identity verification

KYC and identity-verification technology collects and checks identity evidence for people and organizations. Components can include document checks, non-documentary sources, biometric holder binding, business registries, ownership collection, and exception review.

FATF’s Digital ID guidance recommends understanding the assurance, technology, architecture, and governance of a digital identity system and judging whether it is appropriate for the risk. A document scan alone does not establish every required customer fact.

10. Screening data providers

Screening data providers collect and distribute sanctions, PEP, adverse-media, ownership, enforcement, or related reference information. Their output becomes an input to matching and decisions.

For procurement, buyers can assess source authority, identifiers, relationships, language, history, update time, correction process, deduplication, and provenance instead of relying on a record count. This is editorial evaluation guidance. Buyers should distinguish an official source record from a provider’s enrichment or editorial conclusion.

How the categories connect

Identity verification establishes or supports customer attributes. Screening compares those attributes with reference data. Customer risk rating combines relevant factors under policy. Transaction monitoring evaluates activity over time. Payment screening acts on message content and parties. Case management brings alerts and evidence into governed decisions. Data providers supply part of the reference layer.

The connections need explicit contracts: identifiers, field meanings, timestamps, versions, error states, and reconciliation. A suite can reduce integration work, but it can also hide boundaries. Separate products can provide specialist depth, but they increase dependency and change coordination. Neither model is inherently correct.

Procurement implications

Build a control-and-data map before a product map. For every category, record the accountable owner, decision, inputs, outputs, timing, evidence, downstream consumer, and fallback. Then identify overlaps and gaps. Ask whether one vendor module performs a control or only supplies data, workflow, or an analytic used by that control.

Evaluate shared capabilities once but validate control-specific behavior separately. Common identity, permissions, audit, integration, security, and reporting services can be efficient. Screening update latency, monitoring coverage, identity assurance, and case evidence still need their own acceptance tests.

Evidence limitations

Product names and boundaries change. A supplier may place the same capability in several modules, and an institution may combine categories differently. Public documentation often shows supported functions but not implementation quality, source coverage, or performance on a buyer’s data. This taxonomy helps frame questions; it cannot establish regulatory sufficiency or product effectiveness without institution-specific evidence and testing.