Data Definitions, Taxonomy and Access

1. Why This Topic Matters

Every AML/CFT technology control — sanctions screening, PEP screening, adverse media screening, transaction monitoring, customer risk rating — is only as good as the data fed into it. The ACAMS CAMS examination increasingly tests whether candidates understand that technology failures are usually data failures. Regulators (FinCEN, OCC, FCA, MAS, HKMA, BaFin and others) have issued enforcement actions where the root cause was not a weak algorithm, but incomplete customer records, inconsistent field definitions across systems, or data that was never mapped into the screening tool at all.

Key reasons examiners and regulators care:
• Model risk: If 'customer type' means one thing in the core banking system and another in the monitoring system, rules and thresholds are applied to the wrong populations.
• Coverage gaps: If a product line, booking entity or payment channel is not onboarded into screening, transactions in that channel are simply never screened.
• Regulatory reporting: SAR/STR quality, lookback reviews and responses to regulators depend on being able to retrieve and trust the data.
• Privacy and confidentiality: Access to sensitive KYC data, SAR information and beneficial ownership records must be restricted; unauthorized disclosure (e.g., tipping off) is a criminal offence in many jurisdictions.
• Auditability: Independent testing (the third line of defense) must be able to trace a data element from source system to alert to case disposition — this is data lineage.

2. What It Is: Core Definitions

Data definitions are the agreed, documented meanings of each data element used by the AML program. They are typically held in a data dictionary or business glossary. A good definition specifies: the name of the field, its business meaning, permitted values or format, the system of record (golden source), the data owner, refresh frequency and any derivation logic. Example: 'Country of Residence' = the ISO 3166 two-letter code of the country where the individual customer is domiciled for tax purposes, sourced from the KYC platform, updated at onboarding and periodic review.

Taxonomy is the hierarchical classification scheme used to organise data consistently. In AML this includes:
• Customer taxonomy — individual, sole trader, corporate, trust, charity/NPO, financial institution, correspondent bank, PEP, etc.
• Product and service taxonomy — retail deposit, private banking, trade finance, correspondent banking, prepaid cards, crypto custody, etc.
• Transaction and channel taxonomy — cash, wire (domestic/cross-border), ACH, card, cheque, mobile, branch, agent.
• Risk taxonomy — geographic risk, customer risk, product risk, channel risk; risk ratings such as low/medium/high; typology labels such as structuring, funnel accounts, trade-based money laundering, human trafficking.
• Alert and case taxonomy — alert source, disposition codes (false positive, escalated, SAR filed), closure reasons.
A consistent taxonomy allows a screening rule written for 'high-risk jurisdictions' to work identically in every system and every jurisdiction of the group.

Data access refers to the governance of who may view, create, modify or extract data, and under what controls. Core principles are: least privilege, need to know, role-based access control (RBAC), segregation of duties, periodic access recertification, audit logging, and compliance with data protection law (GDPR, CCPA, bank secrecy laws, cross-border data transfer restrictions). SAR/STR data in particular is confidential: access is restricted to compliance personnel and disclosure to the subject is prohibited.

Related concepts you must recognise:
• Golden source / system of record — the single authoritative source for a data element.
• Master Data Management (MDM) — the discipline of maintaining a single, consistent view of customers, products and counterparties across systems.
• Metadata — data about data (definitions, formats, lineage, ownership).
• Data lineage — the documented path of data from origin through transformation to consumption.
• Data quality dimensions — accuracy, completeness, consistency, timeliness, validity, uniqueness.
• Data owner vs. data steward vs. data custodian — owner is accountable (usually business), steward manages definitions and quality day to day, custodian (IT) stores and secures it.
• Data mapping / field mapping — matching source fields to target screening fields during onboarding.
• Reference data — standardised lists (country codes, currency codes, industry codes such as NAICS/SIC, sanctions list identifiers).

3. How It Works: Data Onboarding for Screening Technology

Step 1 — Scoping and inventory. Identify every source system, legal entity, product and channel that generates customers or transactions. Build a data inventory. The question to answer: 'What should be screened or monitored, and where does that data live?' Gaps here create silent coverage failures.

Step 2 — Define the data. Agree the data dictionary with business, compliance, IT and model owners. Resolve conflicts (e.g., three systems each have a 'name' field with different formatting). Define mandatory versus optional fields for each screening purpose — sanctions screening needs name, date of birth, nationality, identification numbers and address; transaction monitoring needs amount, currency, counterparty, country of origin/destination, channel and timestamp.

Step 3 — Apply the taxonomy. Map every customer, product and transaction into the standard classification. Legacy codes are translated into the enterprise taxonomy via mapping tables. Where a value cannot be mapped, it must be flagged, not defaulted silently to a low-risk category.

Step 4 — Map and transform. Technical field mapping from source to target. Common issues: truncated name fields, dates in different formats, free-text country fields, missing SWIFT message fields (e.g., originator information in MT103 field 50), encoding of non-Latin scripts, and splitting of combined fields.

Step 5 — Data quality testing and reconciliation. Validate completeness (did 100 percent of transactions arrive?), accuracy (sample back to source), conformity (values match permitted lists) and timeliness (batch windows met). Reconciliation controls compare record counts and totals between source and screening system every run.

Step 6 — Access provisioning. Define roles (analyst, investigator, QA reviewer, model validator, system administrator, auditor). Assign privileges on least-privilege basis. Implement maker-checker for list management and rule changes. Log all access. Restrict SAR-related fields. Address cross-border restrictions — some jurisdictions prohibit customer data leaving the country, which affects centralised group screening.

Step 7 — Governance and ongoing maintenance. Establish a data governance committee or forum, change control for definitions and mappings, periodic access recertification, issue tracking for data quality defects, and independent testing. New products, acquisitions and system migrations must trigger re-onboarding assessments.

Step 8 — Documentation and lineage. Maintain evidence that regulators and auditors can follow: source-to-target mapping documents, data quality reports, access matrices, approval records.

4. Common Failure Scenarios Tested in CAMS

• A bank acquires another institution and migrates customers; the acquired customers' risk ratings are mapped incorrectly, so high-risk customers receive low-risk monitoring thresholds. Root cause: taxonomy misalignment.
• A new mobile payments channel is launched; transactions are stored in a new database that was never connected to the monitoring system. Root cause: incomplete data inventory/onboarding.
• Wire transfers from a correspondent bank arrive with originator name in a free-text field that the screening tool does not read. Root cause: field mapping gap.
• A relationship manager can view SAR filings on his own clients. Root cause: access control failure and tipping-off risk.
• Country field populated as 'UK', 'U.K.', 'United Kingdom' and 'GB' in different systems, so geographic risk rules miss records. Root cause: no standardised reference data.
• Nightly batch fails and transactions are not screened for two days; nobody notices. Root cause: missing reconciliation and completeness controls.

5. How to Answer Exam Questions on This Topic

The CAMS exam uses scenario-based, best-answer multiple-choice questions. Questions about data definitions, taxonomy and access generally fall into these patterns:

Pattern A — 'What is the root cause?' You are given a screening or monitoring failure. Look for the data explanation: a field not mapped, inconsistent definitions, a missing feed, wrong classification. Resist choosing 'the algorithm was weak' or 'staff were poorly trained' when the facts describe data problems.

Pattern B — 'What should be done FIRST?' When implementing or enhancing a screening system, the first step is almost always to understand and define the data: inventory sources, agree definitions, confirm coverage. Tuning thresholds, buying new software or hiring analysts come later.

Pattern C — 'Which control is MOST appropriate?' For access questions, choose answers embodying least privilege, role-based access, segregation of duties, logging and periodic recertification. For data quality, choose reconciliation, validation rules, data ownership and documented lineage.

Pattern D — 'Who is responsible?' Business units own their data; compliance owns the AML requirements and risk taxonomy; IT is custodian of systems and security; internal audit independently tests. Senior management and the board hold ultimate accountability for the program.

Pattern E — Privacy and confidentiality. If a scenario involves sharing customer data across borders or group entities, remember that AML needs must be balanced with data protection law; the correct answer typically involves legal review, data minimisation and lawful basis — not simply 'share everything' or 'share nothing'.

6. Exam Tips: Answering Questions on Data Definitions, Taxonomy and Access

• Think 'data before technology'. If an option addresses defining, inventorying, standardising or validating data, it is frequently the correct or 'first' step.
• Beware of silent defaults. Any answer where unmapped or unknown values default to 'low risk' or are excluded is wrong. Unknown should escalate or be flagged.
• Coverage is a compliance question. If a product, channel or entity is not in the screening system, it is not screened. Answers that confirm end-to-end coverage are strong.
• Standardisation beats customisation. Group-wide consistent taxonomy and reference data (ISO codes, standard risk categories) is preferred over each business unit using its own labels.
• For access questions, apply the four pillars: least privilege, need to know, segregation of duties, and audit trail. The answer containing these principles is usually correct.
• SAR/STR confidentiality is absolute. Any option allowing front-office staff, the customer or unauthorised third parties to see SAR information is wrong because of tipping-off prohibitions.
• Reconciliation is the control for completeness. If the scenario describes missing or unscreened transactions, the fix is source-to-target reconciliation and monitoring of feeds.
• Documented lineage satisfies regulators and auditors. Choose answers that create traceable evidence over those relying on verbal assurance.
• Mergers, migrations and new products are triggers. Expect scenarios where change introduces a data gap; the correct answer involves re-assessing data mapping and taxonomy before go-live.
• Distinguish roles precisely. Data owner (accountable, business), data steward (maintains definitions and quality), data custodian (IT storage and security), model owner (screening rules), independent testing (audit). Questions often hinge on picking the right role.
• Eliminate extremes. Options like 'screen only high-risk customers', 'stop all data sharing' or 'give compliance full admin rights to every system' are rarely correct. The best answer is risk-based, proportionate and governed.
• Read for keywords: 'inconsistent', 'different systems', 'free text', 'legacy', 'migrated', 'new channel', 'not captured' — these signal a definitions, taxonomy or onboarding problem. 'Relationship manager viewed', 'shared password', 'no review of users' — these signal an access control problem.
• Manage your time. Data-related scenario questions can be long; identify the failure type (definition, taxonomy, coverage, quality, access) in the first read, then evaluate options against that type.

7. Quick Revision Summary

• Data definitions = documented meaning, format, source and owner of each field (data dictionary).
• Taxonomy = consistent classification of customers, products, channels, transactions, risks and alerts.
• Access = least privilege, RBAC, segregation of duties, recertification, logging, confidentiality of SAR data, compliance with privacy law.
• Onboarding = inventory, define, classify, map, test, reconcile, provision access, govern, document.
• Root causes of screening failure are most often data gaps, not algorithm weakness.
• Governance (owners, stewards, committees, change control) is what makes data reliable over time.

Master these ideas and you will be able to decode almost any CAMS question in which a screening or monitoring system 'failed to detect' something — because the examiner is usually asking you to find the data problem behind the technology.