AI in Banking | Customer Brain 3/5: Data and Governance

AI in Banking · Customer Brain Series · Part 3 of 5

Bank data turns a general customer architecture into a system with exceptional obligations. A card authorisation, an address change, a complaint note and an estimated churn probability may appear in the same customer context. They are still not the same. Each has a different origin, meaning, sensitivity and permissible use. Mixing them in a single “brain” does not produce better decisions. It creates a risk zone that is difficult to examine.

For banks, the architecture therefore does not start with a model. It starts by separating information types, documenting provenance and asking which purpose justifies which use. Predictions, policies and actions come afterwards.

Six information types, six distinct roles

A controllable system should distinguish at least six classes:

• Fact: a verified state from an authoritative system, such as an active card agreement or a registered contact channel.

• Event: a time-bound observation, such as a declined card payment, an abandoned onboarding step or a newly opened service case.

• Prediction: a model-based estimate, such as a higher probability of declining card use. It is not proof of intent.

• Policy: a business, legal or operational constraint, such as a contact exclusion, an approval threshold or the priority of an unresolved complaint.

• Experience: a documented outcome from earlier interventions, for example that a service handover proved more helpful than a sales message in a specific context.

• Action: a measure that was executed—or deliberately withheld—with its time, channel, approval and outcome.

This separation has practical consequences. Treating a prediction as a fact creates false certainty. Retaining an event without a time horizon allows a temporary situation to distort later decisions. Turning experience into a general rule without recording segment, timing and test design may teach the system little more than yesterday’s campaign habits.

Lineage is the foundation of explainability

Every data element that influences a decision needs lineage: source system, collection time, transformation steps, accountable owner, quality status and permitted use. A prediction also needs the model version, feature timestamp, calculation time and validity window. A policy needs a version, approval, scope and exception path.

This makes a recommendation traceable in reverse. The bank can establish whether a next best action rested on a current fact, a short-lived event, an uncertain prediction or a binding policy. Without that distinction, an audit trail can be technically complete while remaining unintelligible to the business.

Lineage must not end at the model boundary. When a signal flows into a decision and then into a channel, the chain should extend to execution: which data was used? Which policy removed an option? Who or what approved the action? Which message left through which channel and when? Which outcome returned to the system? Only then can an error be corrected without shutting down everything around it.

Purpose limitation needs technical enforcement

The privacy question is not merely whether a bank holds the data. The relevant question is whether it may use that data for this particular purpose. The European Data Protection Board stresses that AI models involving personal data are not automatically anonymous; legal basis and actual anonymity require case-by-case assessment (EDPB Opinion 28/2024). A privacy notice alone does not create a reasonable expectation for every later AI use.

That leads to concrete technical guardrails:

1. Purpose tags: data and derived features carry permitted purposes, retention periods and exclusions.

2. Access by role and task: a service team receives the context required for the case, not automatic access to marketing, risk or wealth data.

3. PII protection before model access: identifiers are removed, masked or tokenised where the use case does not need clear-text identity. Prompts and outputs are checked for personal information.

4. Minimised context packages: a model receives only the fields and documents required for the task at hand.

5. Separation of decision and execution: a recommendation does not become a message automatically. Channel rules, consent, suppression and approval are checked again immediately before action.

6. Deletion and correction: derived features, intermediate stores and outcome logs are included in deletion and rectification processes.

Situations that suggest financial strain demand particular restraint. They must not become freely available sales signals. Use requires a narrowly defined service or protection purpose, strict permissions and, often, human review. A probabilistic interpretation must never be treated as a settled personal characteristic.

DORA, GDPR, the AI Act and BaFin govern different risks

These regimes should not be compressed into a generic “compliance” label. The EDPB Opinion 28/2024 notes possible additional legal requirements for solely automated decisions with significant effects. The AI Act classifies specific functions: creditworthiness assessment and credit scoring of natural persons are named as high-risk in Annex III, while fraud detection is excluded from that particular category (EU AI Act, Annex III). A retention signal and a credit decision therefore require different control levels.

DORA addresses digital operational resilience, including ICT third-party risk. Financial entities must maintain a register of their contractual arrangements with ICT third-party providers; the EBA explains the harmonised reporting templates and group-level treatment (EBA DORA FAQ). Architecturally, vendors, subcontractors, data locations, critical dependencies, exit paths and recovery arrangements must be documentable from the outset.

BaFin addresses ICT risk in the use of AI across the full lifecycle, from data acquisition and development to operation and retirement, with particular attention to third-party risk (BaFin guidance on ICT risks in AI use). Its supervisory notice on cloud outsourcing also requires robust audit and access rights; merely confirming that a certificate exists is generally insufficient (BaFin supervisory notice).

Precise guardrails therefore mean: use-case classification before development, data and model inventories, versioned policies, least-privilege access, encryption in transit and at rest, tested recovery, a third-party register, defined retention, continuous monitoring, documented exception handling and an action path that can be disabled. “DORA compliant” or “BaFin validated” is not a credible blanket product promise; the specific configuration and operating model determine the answer.

Keep the activation layer deliberately bounded

In this architecture, Acceleraid can make customer and transaction data usable for predictive decisioning, triggers, next best action and controlled activation. It does not replace core banking, a data lake, the privacy organisation or model risk management. Nor does it imply that Acceleraid currently delivers a finished Customer Brain, a knowledge graph or organisation-wide shared memory.

The sensible starting point is a bounded use case with known sources, one permissible action and a measurable impact hypothesis. The architecture must show what was fact, event, prediction, policy and experience. Only while that chain remains intelligible can bank-data intelligence become operationally trustworthy. The article on dynamic banking engagement platforms explains how such an activation layer can sit between core systems and customer dialogue.

The complete Customer Brain series

Lead article: The Customer Brain roadmap · Part 1: Customer 360 is not enough · Part 2: Architecture · Part 3: Data and governance · Part 4: Retention loop · Part 5: Maturity model

Illustration: AI-generated. AI-assisted content: We use AI technologies and automated agents in the creation of our articles, including from Microsoft, Google, OpenAI, Anthropic and other providers. Topics, editorial direction and final approval remain with our team.