Data Quality, Integrity and Lineage

1. Why This Topic Matters

Every AML control that relies on technology – customer screening against sanctions and PEP lists, transaction monitoring, customer risk rating, suspicious activity reporting and regulatory reporting – is only as good as the data feeding it. Regulators around the world (FinCEN, OCC, FCA, MAS, BaFin, the EBA and others) have repeatedly cited poor data quality as a root cause of AML programme failures. Enforcement actions have fined institutions hundreds of millions for monitoring systems that missed transactions because customer records were incomplete, account types were mis-coded, or data feeds silently dropped records.

For the CAMS exam, this topic sits inside the Data Onboarding and Screening Technology domain. The examiner expects you to understand that an institution cannot demonstrate an effective risk-based AML programme unless it can show that (a) the data entering its systems is accurate and complete, (b) the data is protected from unauthorised or accidental change, and (c) the institution can trace where every data element came from and how it was transformed. These three ideas are Data Quality, Data Integrity and Data Lineage.

2. Key Definitions

Data Quality – the degree to which data is fit for its intended purpose. In AML, 'fit for purpose' means it allows the screening engine, monitoring scenarios and risk models to work as designed. The commonly cited dimensions are:
• Accuracy – the data correctly reflects the real-world fact (e.g. the customer's true date of birth).
• Completeness – all required fields are populated (no blank nationality, missing beneficial owner, or absent SWIFT originator information).
• Consistency – the same fact is represented the same way across systems (the customer is 'high risk' in the KYC system and also in the monitoring system).
• Timeliness – data is current and available when needed (yesterday's sanctions list update is loaded before today's screening run).
• Validity / Conformity – data follows the required format and business rules (country codes in ISO format, dates in a standard format).
• Uniqueness – no duplicate customer records that split activity and defeat aggregation thresholds.

Data Integrity – the assurance that data remains accurate, complete and unaltered throughout its lifecycle, from capture through storage, transfer, processing and archiving. Integrity is about protection against corruption, unauthorised modification, truncation during transfer, and loss. Controls include access controls, audit trails, reconciliation and checksums/hash totals.

Data Lineage – the documented 'life story' of a data element: where it originated (source system or form), every system it passed through, every transformation, filter, mapping or enrichment applied, and where it ended up (the screening engine, the monitoring scenario, the SAR). Lineage answers the question 'How did this value get here, and can we prove it?'

3. How It Works in Practice

a) Data onboarding into AML systems
Core banking, payments, trade finance, wealth management and card platforms each generate data. This data is extracted, transformed and loaded (ETL) into a data warehouse or directly into the screening and transaction monitoring systems. At each hop there is a risk: a field may not be mapped, a product code may be unrecognised and dropped, a currency may be mis-converted, or a whole feed may fail without anyone noticing.

b) Data quality controls
• Data profiling at onboarding to understand field population rates, value ranges and anomalies.
• Validation rules at the point of entry (mandatory fields, format checks, look-up tables).
• Data quality dashboards and KPIs – percentage of records with missing nationality, number of duplicate customers, number of rejected records per feed.
• Exception management – rejected records go to a queue for remediation rather than silently disappearing.
• Periodic data remediation projects (often required by regulators after a finding).

c) Data integrity controls
• Reconciliation – comparing record counts and control totals between source systems and the AML system after every load ('did 1,000,000 transactions leave the core system and 1,000,000 arrive in monitoring?').
• Completeness and accuracy testing – sampling transactions end-to-end to confirm values match.
• Access controls and segregation of duties – only authorised staff can change reference data such as risk ratings, thresholds or list configurations.
• Audit trails / logs – every change to data or configuration is time-stamped and attributed.
• Change management – changes to feeds, mappings or scenarios go through testing and approval.

d) Data lineage controls
• A data dictionary defining each field, its business meaning, its source and its permitted values.
• Source-to-target mapping documents showing how each field is transformed.
• Lineage tooling (often part of data governance platforms) that visualises flows.
• Lineage supports model validation – validators must know exactly what data a monitoring scenario uses to judge whether it is working.
• Lineage supports regulatory examinations and audits – the institution can evidence that all in-scope products and channels are actually feeding the monitoring system.

e) Governance
Data governance frameworks (frequently aligned to principles such as BCBS 239 for risk data aggregation) assign data owners (business accountability), data stewards (day-to-day quality) and data custodians (IT). Senior management and the board must receive reporting on data quality because it is a prerequisite for an effective AML programme.

4. Why Poor Data Undermines AML Controls – Examples to Remember

• Screening: If a customer name is truncated or stored in the wrong field, fuzzy matching against the OFAC SDN list may fail – a true sanctions hit is missed (a false negative). Conversely, poor data creates excessive false positives, overwhelming analysts.
• Transaction monitoring: A new product launched without mapping its transaction codes means an entire activity stream is never monitored. A mis-coded country field means a 'high-risk jurisdiction' scenario never triggers.
• Customer risk rating: Missing occupation, PEP status or beneficial ownership causes customers to default to a low-risk category and escape enhanced due diligence.
• Aggregation and structuring detection: Duplicate customer records split cash deposits across identities so that the aggregated amount never crosses the reporting threshold.
• Regulatory reporting: SARs/STRs and CTRs built on wrong data are themselves deficient and may constitute a separate violation.
• Reliance on third parties / outsourcing: When screening or monitoring is outsourced, the institution remains responsible and must verify the vendor's data integrity.

5. The Relationship with Model Risk Management and Tuning

Transaction monitoring and screening systems are models. Model validation (conceptual soundness, ongoing monitoring, outcomes analysis) explicitly includes an assessment of data inputs. Threshold tuning and above/below-the-line testing are meaningless if the underlying data is incomplete, because the sample being tested does not represent true activity. Exam questions often link 'data quality' to 'model validation' and 'independent testing' – remember that the first step of any validation or tuning exercise is to confirm data completeness and accuracy.

6. Exam Tips: Answering Questions on Data Quality, Integrity and Lineage

Tip 1 – Look for the root cause. Many scenario questions describe a symptom: alerts dropped suddenly, a sanctions hit was missed, a customer was rated low risk despite being a PEP. The CAMS answer is usually the upstream data problem (a feed failure, an unmapped product, a missing field), not 'the analyst made a mistake' or 'increase the threshold'.

Tip 2 – Distinguish the three terms precisely.
• If the question is about data being wrong, missing or inconsistent → Quality.
• If it is about data being altered, corrupted, lost in transfer or changed without authorisation → Integrity.
• If it is about tracing the source and transformations or demonstrating to a regulator where data came from → Lineage.

Tip 3 – Favour preventive and systematic controls over one-off fixes. When asked for the 'best' or 'most effective' action, choose answers such as implementing reconciliation controls, validation rules at point of entry, a data governance framework, or documenting source-to-target mappings, rather than 'manually review the affected alerts' (which is a remediation step, not a control).

Tip 4 – Remember the regulator's perspective. Regulators expect institutions to prove that all relevant products, customers and channels are feeding monitoring and screening. The ability to evidence this comes from lineage documentation and reconciliation reports. An answer that emphasises documentation and evidence is often the correct one.

Tip 5 – Connect data to the risk-based approach. A risk assessment and customer risk rating are only valid if based on complete and accurate data. If a question asks why a risk assessment is unreliable, consider whether the data supporting it is deficient.

Tip 6 – New products, systems and acquisitions are classic triggers. Whenever a scenario mentions a merger, a new core banking system, a new product line, a new channel or a vendor change, think: 'Has the data been mapped and tested into the AML systems?' A data gap after a system change is a favourite exam scenario.

Tip 7 – Independent testing and audit should include data testing. If asked what an internal audit of transaction monitoring should cover, include end-to-end data completeness and accuracy testing, not just alert disposition review.

Tip 8 – Watch for 'first step' wording. If the question asks what should be done first when implementing or validating a monitoring or screening system, the answer is typically to confirm the data sources and verify data completeness/accuracy (data profiling and reconciliation) before tuning scenarios or configuring thresholds.

Tip 9 – Eliminate distractors. Wrong options frequently include: lowering thresholds to compensate for missing data, relying on the vendor's assurance alone, accepting the IT department's statement without reconciliation, or deciding that a problem is 'immaterial' without analysis. The CAMS answer requires the compliance function to verify and document.

Tip 10 – Ownership. Although IT builds the feeds, the compliance/AML function must understand and take ownership of the data its systems rely on, and senior management must be informed of material data deficiencies. Answers that place sole responsibility on IT or on a vendor are usually incorrect.

7. Quick Revision Summary

• Data Quality = accurate, complete, consistent, timely, valid, unique – fit for purpose.
• Data Integrity = protected from unauthorised change, corruption or loss across the lifecycle – reconciliation, access controls, audit trails.
• Data Lineage = documented path from source to use – data dictionary, mapping documents, lineage tools – essential for validation and regulatory evidence.
• Poor data → missed sanctions hits, unmonitored activity, wrong risk ratings, defective reports → enforcement action.
• Data checks come first in system implementation, model validation and tuning.
• Governance: data owners, stewards, custodians; compliance ownership; board reporting.
• In exam scenarios, trace symptoms back to upstream data causes and choose systematic, documented, preventive controls.