Context Layer in Banking: Why Customer Context Needs Pace, Purpose Limitation and an Expiry Date

A context layer in banking is the layer that gives an AI agent, at the right moment, exactly the customer context it needs for a task and is allowed to use – no more and no less. We described how this layer is built in principle, and why the golden record is not enough, in part 2 of our series on the agentic experience platform. This article goes one step further, into operations. Context changes at different speeds, it is tied to purposes and it has to be forgettable. Banks that do not model this as data end up with an agent that knows a lot but uses outdated or unauthorised information.

Context is not a record but a structure with four speeds

Customer context consists of layers that change at different speeds, and each layer needs its own freshness rules. Scott Brinker named "context" the 2026 martech word of the year. In "The State of Martech 2026", he describes context as a composite of many parts moving at very different time scales and applies the pace layering model to marketing and AI (Scott Brinker, chiefmartec, May 2026). Pace layering comes from architectural theory: slow layers provide stability, fast layers carry change.

Applied to a bank, this gives four layers. At the bottom are products, terms and rules, which change over months. Above that is the customer relationship, with contracts, consents and preferences, which changes over weeks. Next comes the occasion, such as a house move, a complaint or a maturing term deposit, which develops over days. At the top is the moment itself: the ongoing conversation, the last message, the screen open in the app. A context layer that treats all four layers with the same freshness is either too slow for the moment or too expensive for the rules.

Permission and purpose belong in the context, not next to it

An agent may only see context whose purpose fits the current task – which is why consent and purpose have to be attached to the context object as data. The GDPR requires personal data to be collected for specified, explicit and legitimate purposes and not further processed in a manner incompatible with those purposes (GDPR, Art. 5(1)(b)). If a customer objects to direct marketing, her data may no longer be processed for that purpose (Art. 21(3)). Consent can be withdrawn at any time, and withdrawing it must be as easy as giving it (Art. 7(3)).

In a classic architecture, this information sits in a consent system that campaigns query before sending. An agent, however, does not work in campaigns but in conversations, and it reassembles context within seconds. If permission and purpose are not attached to the context object itself, the agent sees the information about the house move but not that it may only be used for service. Large vendors have recognised the problem. Oracle's "AI Agent Memory", presented in October 2026, is explicitly described as a "governed memory core" with the isolation and governance that production agents require (Oracle Developers Blog, October 2026). For banks, though, governance at storage level is not enough. They need purpose limitation for each context element.

Illustration: AI-generated, hypothetical example.

Hypothetical example: A customer moves house in October and reports the new address in the app. In the same week, he objects to marketing by email. Two days later he calls because a direct debit to his old address has bounced. The adviser's assistant shows the move, the returned direct debit and the objection – but no offer for home contents insurance, even though the model would rate it as relevant. The adviser sorts out the direct debit and, at the end, only asks whether anything else is open. The customer and the bank are invented.

Forgetting is a function of the context layer

Whatever an agent may no longer know, the context layer has to remove actively – from memory, summaries and derived attributes. The GDPR requires erasure when data are no longer necessary for their purpose or when consent has been withdrawn (Art. 17). It also requires data to be accurate and kept up to date (Art. 5(1)(d)). For agents, this creates a new obligation. It is not only the source record that has to be deleted, but also the summary of an old conversation that an agent stored in memory, and a derived attribute such as "interested in mortgage financing".

In practice, every context object carries an expiry date and a deletion rule. Moment context expires after the conversation. Occasion context expires once the occasion is closed. Relationship context follows retention periods and consents. Derived attributes point to their sources and fall away when a source falls away.

A context object in practice

A usable context object describes not only what is known, but also where it came from, what it is for, how long it is valid and who may see it. The table below shows the minimum fields, using the house move from the story above.

The ACCELERAID AI Context Layer follows this principle: it gives an agent only the context it may read for a given purpose, makes consents, objections and the available contact budget queryable at the moment of decision, and logs every access in an audit-proof way. An objection takes effect immediately. Processing runs in an ISO 27001-certified data centre in Frankfurt, and on-premise deployment is available on request. How consents themselves are managed properly is covered in our article on GDPR consent management in AI banking.

Three checks for your own context layer

Whether a context layer is ready for operations shows in three simple tests. First: a customer objects to marketing. How many minutes until no agent sees any marketing attribute for this customer? Second: an occasion is closed. Does its summary disappear from the agents' memory, or does it resurface in a conversation three months later? Third: an auditor asks why an agent used a particular piece of information. Can you show, for every context element, which source it came from and which purpose allowed it?

If the only answer today is "the campaign engine checks that", you have context for campaigns, but not yet for agents.

Five takeaways

1. A context layer in banking gives an agent the customer context it needs for a task and is allowed to use, not everything the bank knows.

2. Context has four speeds – rules, relationship, occasion, moment – and each layer needs its own freshness rule; Scott Brinker describes this pace layering in "The State of Martech 2026".

3. Purpose and permission belong to every context object as data, because the GDPR requires purpose limitation, withdrawal and the right to object to marketing, and agents reassemble context within seconds.

4. Forgetting is a function: erasure also covers conversation summaries and derived attributes, not just the source record.

5. Three tests show operational readiness: time until an objection takes effect, disappearance of closed occasions, and a provenance trail for every context element used.

Illustrations: 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.