Ask a bank's contact-centre agents which question they hear most, and the answer is rarely about fees or branch hours. It is "why was my card declined?" The answer depends entirely on the client's own account: an expired card, a daily limit, a merchant category the client has switched off, a fraud rule, an insufficient balance. Public content cannot answer it.
So the second capability a bank assistant needs is context about the person it is talking to. This is also the point where a well-meaning design can go badly wrong, because the easy way to give a model account context is to let it ask for whatever it wants. Chapter 3 is about the harder, correct way: the bank's own code decides whose data may be fetched, fetches a narrow slice of it, and gives the model only what that question needs.
Where we are in the case study
Impala Bank is fictional, and its systems and figures are illustrative. In Chapter 2 Impala launched Ask Impala to 5% of app users. It answered only from about 420 approved public pages, redirected account questions to the app, and handed off to the contact centre with the transcript attached. Clients' most frequent complaint about it was that it could not explain a declined card.
The client is already signed in, so use that
Impala's clients use the banking app with biometric sign-in on a registered device. That sign-in is the strongest identity signal the bank has, and it is already trusted for far riskier things than a chat.
The key design decision was that Ask Impala would never establish identity itself. It would not ask for an ID number, a date of birth or a one-time PIN in the conversation. Questions about a client's own account would only ever be answered inside the signed-in app, where the session already proves who the client is.
That decision did three things at once. It reused the bank's existing, tested authentication rather than inventing a weaker one in a chat window. It removed any reason for a client to type a secret into a conversation, which kept the anti-fraud message from Chapter 2 simple and absolute. And it settled the WhatsApp question: WhatsApp stays a public-question channel, and anything about an account moves into the app through a link. WhatsApp is enormously convenient, and many South African banks offer services on it, but proving identity in a messaging thread is a harder problem than Impala needed to solve in its third chapter.
The model never holds the key
Here is the part that separates a safe design from an unsafe one. When a signed-in client asks a question, Ask Impala receives the question and a reference to the session. It does not receive the client's credentials, and it cannot choose which client's data to fetch.
When the assistant needs account context, it calls the bank's account service, which takes the client's identity from the session, not from anything the model or the client typed. If a client writes "show me the transactions on account 1234 5678", the account number in that sentence is ignored. The service answers for the signed-in client only, and only for the accounts that client holds.
This matters because a language model can be persuaded. A cleverly worded message, or text hidden in content the assistant reads, can try to steer it into asking for something it should not. If the model decides whose data to fetch, a successful persuasion becomes a data breach. If the bank's code decides, a successful persuasion produces, at worst, a strange request that the service refuses. The prompt-injection problem does not go away, but its blast radius shrinks to what the signed-in client could already see.
Context is a slice, not a dump
The second decision was how much context to give. The tempting answer is everything: load the client's profile, accounts and recent transactions into the conversation so the model can answer anything. Impala rejected that for three reasons.
Privacy. POPIA's minimality condition asks that personal information processed be adequate, relevant and not excessive for the purpose. A question about a declined card does not need the client's home-loan balance or their salary deposits. This is a plain-language reading, not legal advice, and Impala's privacy office made the actual determination.
Accuracy. Long, cluttered context makes models worse at finding the relevant fact, not better. A declined-card question answered from a focused record of the decline event is more reliable than one answered from six months of transactions.
Exposure. Everything placed in the model's context may end up in logs, traces and evaluation datasets. The less goes in, the less has to be protected later.
So account context arrived as small, purpose-shaped slices. For a declined card: the time, merchant name, amount and a decline reason category, with card numbers masked to the last four digits. For a debit-order question: the creditor's name, the amount and the date. Nothing else.
Decline reasons need translating, and some must not be
Impala's card platform recorded decline reasons as codes. Some translate naturally into client language: card expired, daily limit reached, online purchases switched off, insufficient funds. Others do not, and must not.
When a transaction is declined by a fraud rule, telling the client "our fraud system flagged this because of the merchant's location and the amount" would teach a fraudster exactly how to avoid the rule next time. So the account service mapped every decline code into one of two groups: reasons the client may be told, with approved wording and the next step ("your card's online purchases are switched off; you can switch them on under Card settings"), and reasons that produce a neutral message and a route to a person ("we need to check this transaction with you; tap here to speak to us").
The model never saw the raw code for the second group. It only saw "requires human follow-up". That is not distrust of the model. It is the same principle as the session: decisions about what may be disclosed belong in the bank's rules, not in a model's judgement of the moment.
What the assistant may remember
With identity comes the temptation to remember things across conversations. Impala kept memory deliberately thin in Chapter 3: the context for a conversation lived only for that conversation and was not written to any long-term store. If the client came back the next day, the assistant fetched fresh context again.
That costs a little latency and avoids a whole class of problems: stale facts, remembered data that the client never expected to be kept, and retention obligations for a new store nobody planned. Our Memory Is an Architecture Decision series covers when long-term memory is worth its cost. For a bank's third chapter, it was not.
Testing whose data is visible
The new tests for this chapter were not about answer quality. They were about isolation. The team built a set of synthetic test clients and tried, systematically, to make the assistant reveal one client's data to another: by quoting another account number, by pasting text that claimed to be from the bank, by asking the assistant to "switch to" a different profile, by asking about accounts the test client did not hold.
Every one of those attempts had to fail at the account service, regardless of what the model did. The tests checked the service's responses, not the model's wording, because the model's wording is not the control. If you take one thing from this chapter, take that: test the boundary where it is enforced, not where it is described.
Key points
Reuse the strongest identity you already have. Account questions are answered only inside the signed-in app, never by asking for secrets in chat.
The session decides whose data is fetched. The model passes a reference; the bank's code applies identity, and anything the client types cannot widen it.
Context is a slice shaped to the question. Minimal, masked fields improve privacy, accuracy and exposure at once.
Some reasons must not be explained. Fraud-rule declines produce a neutral message and a route to a person.
Test isolation at the enforcement point. Cross-client attempts must fail in the account service, whatever the model says.
Next: Chapter 4, Separate public knowledge from private account data. All chapters are on the series page.
How CloudNala can help
We help teams connect an assistant to customer data without handing the model the keys: identity taken from existing sessions, context shaped to each question, disclosure rules kept in code, and isolation tests that prove one customer cannot see another's data. We start from the questions your customers actually ask and the systems you already run.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Production Readiness Review or write to us at consult@cloudnala.co.za