A relationship manager’s day runs on context. Before a client meeting they want the current exposures, the open service cases, the last three conversations, the product that renews next quarter and the policy that governs its pricing. That context is scattered across CRM, core banking, credit systems, document management and email. Assembling it by hand takes time the relationship manager would rather spend with the client.
An AI assistant that assembles the briefing is one of the most requested use cases in commercial and private banking. The obvious design is also a problem. Index everything the bank knows about a client, let the relationship manager ask anything, and you have built a system that ignores one of the oldest controls in banking: the information barrier.
What the assistant should do
The useful scope is narrower than “ask anything”, and it is mostly preparation and follow-up:
- Pre-meeting briefings: exposures, limits, recent transactions of note, open cases and upcoming renewals, drawn from systems of record.
- Correspondence summaries: what was promised, what is outstanding, what the client last raised.
- Policy and product answers: eligibility rules, pricing guidelines and documentation requirements, retrieved from internal manuals with citations.
- Follow-up drafting: call notes, CRM updates and internal referral requests, which the relationship manager reviews before anything is saved or sent.
What it should not do is give advice, set prices or send anything to a client on its own. Those remain with the relationship manager and the bank’s existing approval chain. Obligations such as suitability assessment stay with the firm whatever tool assembles the paperwork.
Why a shared index breaks the wall
Banks that combine lending, advisory, capital markets or research functions separate people who hold inside information from people who do not. The EU Market Abuse Regulation recognises this in Article 9. A legal person holding inside information is not presumed to have used it where it has adequate and effective internal arrangements that keep that information from the people making the relevant decisions. The FCA Handbook describes Chinese walls in SYSC 10.2. In the US, Section 15(g) of the Securities Exchange Act requires broker-dealers to maintain written policies designed to prevent misuse of material non-public information.
These arrangements were designed around people, folders and systems. A retrieval index cuts across all three. Consider what happens when an assistant indexes the corporate client’s document space without regard to function:
- A coverage banker on the public side asks “anything I should know before meeting Client X?” The top retrieved passage comes from an M&A team’s draft engagement memo.
- The model does exactly what it was built to do: it summarises the passage, adds a citation and delivers it helpfully.
The barrier has been breached, and nothing looks broken. No access-denied error was raised, because the index never knew a wall existed. The same thing can happen more quietly through a shared semantic cache, a common log store that support staff can search, an evaluation dataset built from real queries on both sides, or a model fine-tuned on mixed material.
Designing the barrier into the assistant
The design principle is simple to state: the assistant must never know more than the person using it is allowed to know. In practice it takes six controls.
1. Classify sources by side of the wall at ingestion. Private-side, public-side and above-the-wall (compliance, legal) should be derived from the entitlements of the source systems, not assigned by hand. Hand labels drift. The approach is the same one described for permission-aware private RAG.
2. Separate the sides physically, not just logically. Metadata filters are the right tool for scoping a relationship manager to their own client book. For the wall itself, separate indexes, caches and model contexts per side mean a filter bug cannot become a barrier breach. This mirrors department-level data isolation, with a regulator behind it.
3. Bind retrieval to identity, never to the prompt. Entitlements come from the authenticated session and are applied server-side. A user who asks the assistant to “also check the deal team’s folder” should get nothing, and the attempt should be logged.
4. Drive wall crossings from the compliance record. When compliance brings someone over the wall, the crossing has a scope and an end date. The assistant’s access should be derived from that record, limited to the named matter, and removed when the crossing closes. Our note on offboarding people from an AI platform covers the same revocation problem from a different direction.
5. Keep restricted-list checks inside compliance. If the assistant must avoid discussing certain names, let it call a compliance-owned check that returns allowed or not allowed without the reason. Do not load the watch list into the assistant’s context. The list is confidential in its own right.
6. Partition everything derived from queries. Caches, logs, evaluation sets and any tuning data inherit the side of the wall they came from. A semantic cache keyed only on query similarity will happily serve a private-side answer to a public-side question.
Client confidentiality inside the wall
The barrier is not the only boundary. Within the public side, a relationship manager should see their own book, joint-coverage clients and whatever their role grants, not every client of the bank. Coverage changes often: clients move between bankers, teams restructure, people leave. Entitlements should follow the coverage system, not a snapshot taken at ingestion.
Audit that surveillance can use
Compliance and surveillance teams will ask two questions of any system that touches inside information: who saw what, and under which entitlement? The assistant’s trace should record, for each response, the requesting user, the entitlements applied, the passages retrieved and their source systems, and the output. That record should be queryable by surveillance, not buried in application logs. AI agent observability sets out what such a trace contains.
Why this belongs on premises
A relationship manager’s prompts contain client names, exposures and, on the private side, potential inside information. So do the retrieved passages, the embeddings of those passages and the logs. Sending any of that to an external model API puts barrier-sensitive material in a third party’s systems and logs. Running the assistant inside the bank’s own infrastructure keeps the wall and the data it protects in one place. That is the pattern described in our guide to on-premise AI for financial services.
How VDF AI fits
VDF AI runs inside the bank’s environment, with role-based permissions applied per agent and per tool. Private RAG enforces permission checks at query time against the caller’s identity, and department-specific agents can be given separate knowledge sources. Every retrieval, tool call and output is recorded in an audit trail. The barrier policy itself stays with compliance. The platform supplies the enforcement points and the evidence.
Sources and further reading
- Regulation (EU) No 596/2014 (Market Abuse Regulation) — see Article 9 on legitimate behaviour
- FCA Handbook — SYSC 10.2 Chinese walls
- 15 U.S. Code § 78o — Section 15(g), prevention of misuse of material non-public information
- SEC OCIE — Staff Summary Report on Examinations of Information Barriers
- AI Agents for Credit Memo Preparation and Risk Summarization
- AI Agents for KYC and AML Investigation Workflows
Planning an AI assistant for relationship managers? Talk to us about building one your compliance team can sign off.