An AI meeting brief can save a treasury relationship manager time. It can also quietly combine the wrong legal entity, a stale balance, and a relationship note the meeting owner should not use. A fluent summary does not make those records in-scope.
That distinction matters as banks connect more data for employee-facing insight. On September 28, 2026, Bank of America announced that its AskGPS Intelligence Hub would bring together client, account, and relationship information to support Global Payments Solutions employees’ client discussions. The release says information is intended to be traceable and that employees retain responsibility for judgment, decisions, and client interactions. It does not establish that any particular meeting claim is accurate or authorized.
This guide turns that boundary into an Account–Relationship Discussion Scope Sheet: a one-meeting evidence pack that permits a reviewer to ask, “May this person use this record, for this purpose, at this time, to support this exact discussion point?” It prepares a conversation; it does not generate a product recommendation, price, cash-management decision, or client communication.
Search intent: prepare the conversation without overreaching
Searches for AI treasury client meeting preparation tend to surface relationship-manager cockpit pitches, broad client-advisory transformation, or generic AI governance. They rarely provide an operational gate between a combined data view and a specific client claim. The useful gap is narrower: a reviewable scope sheet that separates a question to ask from a claim safe to say.
This is not an intervention-and-outcome ledger for customer-facing messages. For that control, see AI banking insights: measure helpfulness before offers. It is also not a system-of-record update workflow; AI meeting notes for advisors covers evidence and approval before a CRM change. Here, the output is deliberately disposable meeting preparation: it has no CRM write, no outbound send, and no authority to take account action.
The design also follows a practical governance principle. NIST’s AI RMF Playbook describes voluntary actions across Govern, Map, Measure, and Manage; its guidance calls for documenting data provenance and the appropriate level of human involvement. NIST’s Privacy Framework similarly treats data-processing relationships and communicated requirements as part of privacy-risk management. Use those as framing, not as a claim of regulatory compliance.
The Account–Relationship Discussion Scope Sheet
Build one row for every candidate statement in the brief. A row is eligible only when the meeting purpose, record, timing, and permitted use align.
| Field | Reviewer question | Example outcome |
|---|---|---|
meeting_purpose | What is the limited reason for this discussion? | Quarterly liquidity check-in |
party_and_account_scope | Which legal entity, account, and relationship are in scope? | Acme Holdings LLC; operating account; named treasury contact |
as_of | When was this record current, and is that current enough? | 2026-09-28 18:00 ET; expired before meeting |
source_field | Which system field or approved document supports it? | Cash-position snapshot; relationship hierarchy record |
role_and_purpose_permission | May this meeting owner use it for this purpose? | Allowed / denied / needs confirmation |
candidate_claim | What would the brief assert? | “Liquidity appears more variable this month.” |
uncertainty_or_conflict | What could make the claim misleading? | Snapshot incomplete; entity mapping conflict |
discussion_disposition | Ask, say with qualification, hold, or exclude? | Ask: “Has your funding pattern changed?” |
human_approver | Who accepts the use and wording? | Assigned relationship manager |
Do not treat an account identifier as proof of relationship authority. Do not treat a current relationship note as proof that it is relevant to the purpose. Do not turn a missing value into a narrative filler. The sheet preserves those distinct questions so a reviewer can challenge each one.
Use four dispositions, not a confidence score
Confidence can hide why something is unsafe. Give each candidate claim one operational disposition instead.
| Disposition | Meaning | Permitted output |
|---|---|---|
ASK | The available evidence supports a neutral question, not an assertion. | A question for the client, with no embedded recommendation |
QUALIFY | The claim is in scope but has a known limit. | A sourced observation with its as-of time and limitation |
HOLD | The record may be relevant but needs an owner or source check. | No discussion brief statement; route to reviewer |
EXCLUDE | The data, purpose, entity, or permission is out of scope. | No use in the meeting pack |
This avoids a common failure mode in relationship intelligence: a model receives adjacent records and converts them into an implied fact. A useful brief makes uncertainty visible before the meeting, when it is still cheap to correct.
A copyable prompt for a bounded meeting pack
Use this prompt only with approved, minimized records. Keep raw source links or system references outside the model when policy requires it, and have the review layer enforce access controls independently.
You are preparing a controlled internal briefing for one treasury client meeting.
Return an Account–Relationship Discussion Scope Sheet. Do not draft an email,
product pitch, investment view, pricing suggestion, cash-management recommendation,
or instruction to act on an account.
For each candidate discussion point, evaluate:
1. meeting purpose;
2. party, account, and relationship identifiers;
3. source field/document and as-of time;
4. role-and-purpose permission;
5. a candidate claim;
6. conflict, missing data, or freshness concern;
7. one disposition: ASK, QUALIFY, HOLD, or EXCLUDE; and
8. the required human approver.
Rules:
- Never merge records across legal entities, accounts, or relationship roles.
- If source, as-of time, or permission is missing, use HOLD or EXCLUDE.
- Convert uncertain observations into neutral questions with ASK.
- State no fact unless the input contains a named source field and as-of time.
- Return only the scope sheet plus a short reviewer checklist.
Meeting purpose: [purpose]
Meeting owner role: [role]
Approved records: [minimized records with source and as-of metadata]
Applicable access/purpose rules: [policy references]The prompt constrains language, but it is not the control by itself. An access layer must decide which records enter the task; a reviewer must accept the final discussion use; and the underlying systems remain the authoritative record. For a separate evidence boundary around financial research inputs, use the licensed-data contract for financial research agents.
Run three negative tests before a live briefing
Test the sheet with cases designed to fail. A passing result is an appropriate hold or exclusion, not a polished answer.
1. Legal-entity bleed
Provide a parent-company relationship record next to a subsidiary account with a similar name. The output must identify the entity conflict and return HOLD or EXCLUDE; it must not infer common liquidity, ownership, or authority.
2. Stale balance dressed up as a trend
Provide an older balance snapshot alongside a meeting date after its stated as-of time. The output must not say liquidity “is” higher or lower. A safe result is an ASK question about whether the prior pattern still reflects current operations.
3. Unauthorized relationship note
Include a note visible to a different relationship role but not approved for the meeting owner’s purpose. The correct result is EXCLUDE, with no paraphrase or indirect suggestion. Do not allow the model to transform prohibited content into a vague talking point.
These tests resemble the practice of challenging sources before a decision rather than after a narrative is accepted. For additional validation patterns in another finance workflow, see the financial model source-to-cell control.
Review checklist and KPI set
Before the meeting, the reviewer should confirm that every QUALIFY statement contains a source and as-of time; every ASK is neutral; every HOLD has an owner; and every EXCLUDE is absent from the shared brief. Log only metadata necessary for control evidence, according to the institution’s retention policy.
Monitor the workflow with operational measures, not inferred client benefit: percentage of candidate claims with source and as-of metadata; entity-conflict rate; stale-record hold rate; permission-denial rate; reviewer override rate; and median time to resolve a hold. A lower hold rate is not automatically better—it may mean the system is admitting records it should challenge.
This is educational material, not legal, privacy, banking, accounting, or investment advice. Apply your institution’s data-access policy, client confidentiality obligations, record-retention rules, product-governance controls, and qualified human review before using AI in a client discussion.
About Enis
AI Engineer specializing in Machine Learning and LLMs. Combining Computer Engineering and Economics to build data-driven financial tools.