Why your AFC team needs a data strategy before software

The sequence is familiar. A firm selects a transaction monitoring platform, negotiates commercial terms, appoints an implementation partner and begins the programme. Several months in, a pattern emerges. The data the platform requires is not where it needs to be. Customer records are inconsistent. Account attributes are missing or stale. Ownership structures were captured at onboarding and never maintained. The implementation slows. Timelines extend. Expectations shift. Eventually, the platform gets the blame.

The platform is rarely the problem. The data problem was there before the platform arrived.

‍

What AFC data failures look like

AFC programmes depend on data in ways that are easy to underestimate from a distance. Screening depends on accurate legal names, aliases, dates of birth or incorporation, ownership structures and connected parties. Transaction monitoring draws on customer type, expected activity, geography, industry, product usage and current risk rating. Case management relies on complete transaction history, prior investigation outcomes and documented CDD. And governance rests on a clean, traceable audit trail from source data through to the final decision.

When any of those data foundations are weak, the controls built on them are weak. A monitoring rule calibrated to a customer's stated expected activity will misfire if that expected activity was set at onboarding three years ago and never updated. A screening match that should have been detected will be missed if the name on the sanctions list and the name in the customer record are formatted differently. Neither failure is a system error. Both are data errors.

The problem compounds when data is siloed across systems. A customer's KYC record, transaction history, prior alerts and case notes may sit in four separate platforms. Analysts work from partial pictures. Investigators reach conclusions without access to context that exists in the organisation but is not visible to them. The AFC function does its best with what it can access.

‍

What a data strategy for AFC actually contains

A data strategy is not a commitment to improving data quality. It is a set of specific decisions about five things.

The first is what data is required. For each AFC control, whether screening, transaction monitoring, customer risk assessment or investigations, the programme needs to specify what data inputs are needed, at what level of completeness and accuracy, and where that data comes from. This sounds obvious. It is rarely documented.

The second is how quality is maintained. Data quality degrades over time unless there are active mechanisms to prevent it. That means defining what quality means for each data asset, measuring it against that definition, and having a clear process for identifying and resolving quality failures. This is a specific process with named accountabilities and a defined standard for each asset.

The third is data ownership. This is the most commonly absent component of AFC data governance. Saying "the data team owns the data" simply names a dependency. Real ownership means someone in the AFC function is accountable for the quality of the data their controls rely on. Without that accountability, no one will notice when it degrades. And it will degrade. Customer records go stale. Ownership structures change. Products and geographies expand without corresponding updates to the data model.

The fourth is lineage. Being able to trace a decision, whether a match, a case closure, a SAR or a risk assessment, back to the source data that supported it is increasingly a regulatory expectation rather than a good-practice aspiration. When a regulator asks where the data came from and whether it has been modified, the firm needs a specific, documented answer. Lineage is the infrastructure that makes that answer possible.

The fifth is access governance. AFC teams should be able to query the data they need without opening a ticket to an engineering team and waiting days for a response. How access is structured, meaning who can access what, under what conditions and with what audit trail, is an AFC concern as much as an IT one. Engineering queues that sit between the AFC function and its own data are a control risk.

‍

The sequencing argument

Most firms treat data strategy as something that happens during implementation. The platform is selected, the implementation begins, and data gaps surface as a discovery activity. That sequence has a predictable outcome. Implementation slips, scope narrows, and the programme never quite reaches the capability it was sold on.

The right sequence runs in the opposite direction. Data strategy is the work that should happen before vendor selection, because the strategic and financial case for a platform depends on the data environment it will operate in. A firm with clean, accessible, well-governed data and clear ownership has a different set of requirements, and a different risk profile for implementation, than a firm that needs to build that infrastructure first.

A platform selection made without understanding the data environment is a guess. Some guesses work out. Most produce the familiar pattern of implementation, then data gaps, then delays, then recrimination.

Data strategy is the precondition, and it cannot be deferred. The AFC function that treats its data as a core operational capability, owned, governed, measured and maintained, will consistently outperform the one that treats data as someone else's problem and waits to find out what the platform requires.

‍