AI in Banking | Customer Brain 2/5: The Architecture

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

A Customer Brain for banks is not a single model, nor is it a new name for a customer data platform. It is a composite architecture that connects data, meaning, memory, decisions, policies and actions under control. As part 1 of this series explains, Customer 360 provides the customer view. A Customer Brain adds the ability to interpret a situation and act within explicit boundaries.

This distinction matters when planning the architecture. Teams that start with the LLM optimise the visible answer early and the system’s reliability late. Banks should instead begin with sources, identities, permitted purposes and decision points. A language model may be one component, but the LLM is not the Brain.

1. Multi-source data: sources retain authority

A Customer Brain needs data from several systems, such as customer master data, accounts and products, transactions, digital interactions, campaign responses, service cases and consent records. These inputs should not be copied into a shared context without control. Each source needs a defined owner, quality status, freshness indicator and permitted purpose.

The architecture must also distinguish a system of record from derived information. A core system may hold the authoritative product status, while a model derives a probability of churn. The two must not receive the same truth status. Provenance, timing and the transformation path need to remain traceable.

2. Identity: the right person in the right context

Identity resolution links records without merging identities prematurely. In addition to customer numbers, household relationships, powers of attorney, company roles, devices or anonymous digital sessions may matter. Matching rules should be labelled as deterministic or probabilistic and remain reviewable.

In banking, “same customer” does not mean “same permission”. One person may be a retail customer, a company representative and an authorised user of another account. Permissible context depends on role, purpose, channel and time. Authorisation therefore belongs in the identity and access layer, not as a final check in the user interface.

3. Semantics and relationships: giving data business meaning

Semantics translate technical fields into banking concepts. They define what “active usage”, “onboarding complete”, “complaint open” or “contact permitted” means in practice. Relationships connect customers, products, events, cases, channels and policies.

This does not necessarily require one graph database. What matters is a consistent semantic model that makes relationships explicit and queryable. It needs versions, definitions and accountable owners. Without this layer, a model can produce fluent language while confusing distinct business meanings.

4. Four types of memory

A Customer Brain does not need “more storage”. It needs separate memory functions with different retention periods and controls:

• Working memory holds the short-term context of a task: the current question, relevant transaction, active case and steps already taken. It should be small, purpose-bound and time-limited.

• Semantic memory contains relatively stable knowledge: product definitions, business terminology, permitted process variants or curated knowledge articles. Sources and validity must be visible.

• Episodic memory records relevant events in a customer relationship, such as a service contact, complaint, offer or outcome. Not every event merits permanent retention.

• Procedural memory describes how to perform a task correctly: checks, approvals, escalation paths and channel rules. It is versioned process knowledge rather than free-form recollection.

This separation supports data minimisation. European data protection authorities state that processing personal data in AI models requires a specific legal basis and case-by-case assessment; a privacy policy alone does not establish that people could reasonably expect such use (EDPB Opinion 28/2024). Memory therefore needs deletion schedules, correction paths, purpose limitation and access controls.

5. Reasoning: evaluating options, not inventing truth

The reasoning layer combines current signals, retained context and business logic. It may use rules, statistical models, optimisation and an LLM. Its job is to assess possible explanations or actions, not to fill gaps in the facts.

A sound decision record therefore contains more than the output. It also captures sources used, model version, uncertainty, excluded options and the triggering event. Where risk is high or evidence is weak, reasoning should end in escalation rather than an automated action.

6. Policy layer: permission before execution

The policy layer checks whether a proposed action is allowed. Its controls include consent, purpose limitation, role permissions, contact policies, product eligibility, suppression lists, risk limits and human approvals. Policies should be versioned and testable artefacts, not merely prose embedded in a prompt.

Controls must be use-case specific. The EU AI Act explicitly classifies systems used to evaluate creditworthiness or establish the credit score of natural persons as high-risk (EU AI Act, Annex III). For deployers of high-risk systems, Article 26 includes competent human oversight, monitoring and retention of automatically generated logs for at least six months unless other law requires longer (AI Act, Article 26). A service notification and a credit decision therefore require different controls.

7. Agents: bounded responsibility, not autonomy

Agents coordinate steps within a defined assignment. An agent may retrieve context, prepare a recommendation, initiate a policy check or pass an approved action to a target system. It should only see the tools and data required for its role.

This keeps accountability visible. Each agent needs a documented purpose, permitted tools, input and output formats, stop conditions and human hand-offs. An LLM may support language or planning. It does not replace identity, the policy layer, the system of record or the audit trail.

8. Actions: where risk becomes real

A recommendation only has an effect when executed. Actions might create a CRM task, send a service message, present a next best action, suppress a channel or hand a case to an employee. Write access requires stronger controls than read access: approvals, idempotency, amount or frequency limits, reversal options and complete logging.

The vendor context also matters for banks. For cloud outsourcing, BaFin expects robust audit rights, equivalent rights throughout subcontracting chains and an exit strategy tested against concrete alternative providers (BaFin supervisory notice on cloud outsourcing). Those requirements belong in the operating architecture, not only in the procurement contract.

9. Feedback: learning under supervision

Feedback connects outcomes to the next decision. It includes delivery, response, completion, rejection, complaint, human correction and unexpected side effects. Not every feedback signal should automatically change a model. Teams must first determine whether it concerns data quality, a policy, a model, a process or the action itself.

A controlled closed loop separates measurement, evaluation and change. Model updates, new policies and expanded agent permissions pass through testing and approval. “Learning” then does not mean uncontrolled self-modification.

Build the target architecture in stages

The architecture should be tested through a bounded use case. A disciplined starting point defines sources, identity, memory, decisioning, policy, permitted action and success measure in advance. Teams can then observe where people intervene, which data are missing and where rules are too coarse.

Acceleraid can be placed in this target model as a controlled customer-activation layer. Its documented scope connects customer and transaction signals with segmentation, predictive decisioning, triggers and personalised activation. That can form part of the execution path, but it is not a claim that Acceleraid currently delivers a complete Customer Brain with shared memory, an ontology and autonomous agents. The existing article on the intelligence layer provides further context on the relationship between CDPs, predictions and agents.

A Customer Brain is therefore not created by selecting a particularly capable model. It is created through well-defined transitions: from authoritative data to identity and meaning, from meaning to bounded memory, from reasoning to policies, and from approved actions to observable feedback. Those transitions are what make the architecture suitable for a bank.

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.