A customer has submitted the information needed to open a bank account. Identity documents are valid. Screening has run. Customer data is available. Yet the KYC case remains open.
The operating question is simple: why is this customer still not cleared?
The answer may sit across the customer record, identity documents, screening results, risk policy, workflow status and approvals. No single dataset is enough. The problem is not access to data. It is the assembly of the right business context around the case.
That is the step-up from a data product to a context data product. Data products make trusted facts reusable. Context data products make a business situation reusable for AI and decision workflows.
IN BRIEF
- Data products remain the foundation. They organise trusted data around an entity or domain.
- Context data products add the relationships, current state, rules, evidence and controls needed to understand a situation.
- The value appears when several AI workflows repeatedly reconstruct the same context.
- The goal is not another data platform. It is a reusable way to assemble context from existing products and source systems.
Data products and context data products solve different reuse problems.
Data productContext data productDesigned aroundEntity or domainSituation, task or decisionRetail KYC exampleCustomerCustomer + KYC caseCore questionWhat do we know?What is happening, and why?AddsQuality, semantics, ownershipRelationships, state, rules, evidence, controlsTypical reuseAnalytics, applications, AIAI assistants, agents, decision workflows
Exhibit 1: The step-up is from a trusted entity to a trusted business situation
Data products solved the first reuse problem
Data products addressed a familiar issue. Teams should not repeatedly clean, reconcile and redefine the same business data.
A customer data product, for example, can provide a governed view of identity, profile, relationships and agreed definitions. It combines trusted attributes with quality controls, ownership and a standard way to consume the data.
Its core question is: “What do we reliably know about this customer?”
KYC exposes the next reuse problem
KYC is not only a customer-data question. It is a case question.
Assume the customer product says the customer is a UAE resident and a business owner. The document product shows valid identity documents. Screening returns a possible PEP match. The workflow shows that compliance review is still pending.
The reason for the delay becomes visible only after those pieces are connected to one KYC case. The system must also know which policy applies, which check is outstanding, and what the user is allowed to see or do.
A data product describes the entity. A context data product describes the situation around the entity.
A KYC context data product has five practical building blocks
Each block is reusable. Not all of the underlying data needs to be copied into a new store.
Building blockRetail KYC exampleRole in the context1 AnchorCustomer + KYC caseDefines the business situation being evaluated2 Trusted factsIdentity, profile, documents, riskReuses governed data products and authoritative sources3 Relationships + stateDocument links, screening result, approval statusShows how the pieces connect and what is true now4 Applicable rulesKYC policy, risk triggers, required checksEstablishes what applies to this case5 Evidence + controlsSource, timestamp, permissions, human approvalMakes the result traceable and safe to use
Exhibit 2: Practical building blocks of a context data product
The context product should assemble, not centralise
A context data product should not become another KYC database. Some context can be prepared. Some should be retrieved from the authoritative system when the workflow runs.
Prepared contextRuntime contextCustomer relationshipsDocument metadataPolicy indexesStable reference dataLatest screening resultCurrent case statusLatest risk assessmentOutstanding approval
The objective is reliable context assembly. It is not centralisation. This distinction keeps the context layer smaller, fresher and easier to operate.
Why AI makes this step more important
An AI assistant can retrieve a KYC policy. That does not tell it why this customer is still pending. It also needs the relevant customer facts, latest screening state, applicable rule, pending action and evidence.
The same context can then support several workflows: onboarding, periodic KYC refresh, compliance review, relationship-manager support and customer service.
If each AI team reconstructs the same relationships, rules and controls, the enterprise has recreated the duplication that data products were designed to remove. Only one layer higher.
Context data products extend the existing data-product model
Source systemsrecordGoverned datastandardiseData productsreuse factsContext productsreuse contextAI workflowsreason / act
Context products depend on good data products. They do not replace them.
When is a context data product justified?
Not every AI workflow needs one. The useful test is repetition.
- Several workflows need the same cross-domain context.
- Teams repeatedly rebuild the same relationships or policy logic.
- Current operational state must be combined with governed data.
- Evidence and access controls need to remain consistent across applications.
If one workflow needs the context, keep it local. If the same context keeps reappearing, productise the repeated part.
What Leaders should take away
- Do not start with an enterprise-wide context platform.
- Review a small portfolio of AI workflows and identify the business context they repeatedly reconstruct.
- Keep trusted domain facts in data products. Productise only the repeated context around decisions and tasks.
The enterprise AI question is therefore becoming broader than “Do we have the data?” The next question is whether the organisation can assemble the right context, for the right situation, with the right evidence and controls.
Data products make enterprise facts reusable. Context data products make those facts usable in a live business situation.
A practical starting point
Take two or three priority AI workflows. Map the data products, source systems, rules and live state they require. The repeated context is the candidate for reuse. The output should be a focused engineering scope, not a new enterprise-wide data programme.
