Who Owns the Conversation Between My Agent and My Bank?
When two agents remember an exchange differently, both sides need evidence of what crossed the boundary and what happened next.
The detail that changed on the way
Imagine a client asks her personal agent to contact her bank before a mortgage deal expires.
She gives it permission to share the current balance, an estimated property value and the monthly payment she wants to stay below. Her agent sends the request. The bank’s agent returns a few indicative options, and the client decides she would like to speak to somebody.
During the call, the relationship manager says: “Given that you expect your income to fall next year…”
The client stops them. She never agreed to share that. Her personal agent knows she has been considering a career break, but the instruction was to keep that context private and use it only to set the monthly-payment limit.
The bank’s record is different. It says the customer expects a lower income.
Perhaps her agent disclosed too much. Perhaps the bank’s agent inferred it from the payment constraint. Perhaps an integration translated one field into another, or a person added a note after reading the case. Both systems have logs, but neither can show the client and the bank one plain record of what crossed the boundary.
This is the ownership question inside agent-to-agent banking: when the two sides remember an exchange differently, who can prove what was requested, disclosed, relied upon and approved? A transcript controlled by one party would not settle much.
A log tells one side’s story
In When My Agent Talks to My Bank, I described two independent forms of intelligence meeting under explicit permissions. In The Relationship Manager’s New Inbox, I moved to the bank side and asked what should reach a person.
This is the third part of that model: the small shared record created at the boundary.
The client’s agent will need its own private history. It may record the client’s instruction, the personal context it used and the reasons it decided not to disclose something. The bank needs a separate operational record covering its policies, internal searches, checks and decisions. Neither party should receive the other’s private reasoning simply because their agents exchanged a message.
But consequential exchanges need something in the middle: a matching receipt that both parties can inspect and verify, rather than a combined database or one side’s screenshot.
The distinction matters because internal logs answer different questions. The client-side log may prove what the agent intended to send. The bank-side log may prove what its system processed. A shared receipt records what both systems acknowledged at the boundary, before either side added its own interpretation.
NIST’s current agent work is already pushing on the underlying machinery. Its AI Agent Standards Initiative includes interoperable protocols, authentication and identity infrastructure for multi-agent interaction. A related NCCoE project is examining identification, authorisation, auditing, non-repudiation and the tracking of data flows. That work is still developing, but the direction is useful: an agent needs a verifiable identity, a principal it acts for and authority that can be checked.
For a banking relationship, I think it also needs a receipt.
What the receipt should say
The receipt should be fairly boring. That is a compliment.
For any exchange that changes permission, moves new personal information, influences eligibility or advice, triggers a human decision or initiates an action, it should answer a short set of questions:
- Which client, bank and agents took part?
- Which mandate allowed the exchange, and when does it expire?
- What was requested, in terms a person can understand?
- Which facts or documents crossed the boundary?
- Where did those facts come from, and how current were they?
- What was withheld or outside the permitted purpose?
- What did the receiving side say it would use the information for?
- Which response, decision or action followed?
- Did a person approve anything, and in what role?
- Has any part of the record since been challenged or corrected?
Some of that can be machine-readable. It has to be, if agents are going to use it. The same record also needs a human view that does not require a security engineer to interpret event codes at the moment a client is already unhappy.
This should not mean copying every source document into another permanent archive. A receipt may name a document version and retain a verifiable fingerprint rather than store the document itself. It can say that a verified income range was disclosed without retaining the private material used by the client’s agent to establish it. The evidence should be sufficient for the purpose, with retention tied to that purpose and any genuine recordkeeping obligation.
FINRA’s 2026 oversight report highlights the risks of agents exceeding their intended authority, making multi-step outcomes difficult to trace and mishandling sensitive information. It asks firms to consider how they track agent actions and decisions. A boundary receipt would not solve those risks by itself, but it would give the client and the institution the same starting point when a particular exchange matters.
Consent gives us part of the shape
There is already a useful precedent in consent records.
ISO/IEC TS 27560 specifies a structure for recording consent to personal-data processing, providing a receipt to the person, exchanging consent information between systems and managing it through its lifecycle. It is narrower than the relationship record I am describing, and it is marked for revision, but it establishes an important product idea: permission should not exist only as an internal flag held by the organisation asking for it. The person should receive evidence too.
An agent exchange needs to go further than “consent granted.” The later disagreement may be about the scope of the request, the exact fact disclosed, the source version used, the purpose stated by the bank or whether a human approved the next step. A consent receipt can show that a door was opened. A relationship receipt should also show what passed through it.
That does not make both sides jointly entitled to everything surrounding the exchange. My bank may need to retain regulated records that my agent cannot edit. My agent may use private context that the bank has no right to inspect. The shared part is deliberately smaller: the acknowledged boundary event and its status.
Correction is part of the transaction
The mortgage example becomes more useful once the client can challenge the record.
Suppose the receipt shows that her agent shared only the payment ceiling. The “expected lower income” entry was created later by the bank as an inference. The correction is not to pretend the inference never happened. It is to label it accurately, mark it as disputed where necessary and stop it quietly travelling into another product conversation as though the client disclosed it herself.
If the receipt instead shows that her agent sent the statement, the client has a different problem. She needs to see which permission was relied upon, revoke or narrow it for future exchanges and understand where the information has already been used.
Correction therefore should not behave like editing a shared document until both sides like the wording. The original event remains part of the evidence. A correction is appended, attributed and propagated to the workflows or recipients that relied on the incorrect fact.
There is an established principle here too. Article 16 of the EU GDPR gives people a right to rectify inaccurate personal data. Article 19 requires rectification, erasure or restriction to be communicated to recipients under the conditions set out in the regulation. Agent-to-agent banking will create new technical records, but a correction still has to reach the systems and people that used the wrong information.
There will be difficult cases. Facts can be corrected. Opinions and inferences may need to remain, but they should be labelled with their source and author rather than presented as something the client said. Some disputes will require a human owner, a deadline and a clear route into the bank’s existing complaint or data-rights process.
The receipt is where that repair begins.
Do not preserve the whole conversation
The obvious overreaction is to record everything.
Every prompt, private memory, model response, retrieved document and internal reasoning step could be copied into a permanent shared archive in the name of auditability. That would make the relationship easier to investigate by making it much more intrusive to have in the first place.
It would also confuse two different jobs. An institution may need internal technical evidence to investigate why its agent behaved in a particular way. That is an audit and replay problem. The relationship receipt has a narrower purpose: prove the consequential facts that crossed between the parties and the authority attached to them.
The shared record should therefore omit private chains of thought, unrelated context and raw material that never left either side. Routine low-risk exchanges may need only a short-lived acknowledgement. A new disclosure, changed mandate, advice input, approval or completed action deserves more. Retention should grow with consequence, not with how chatty the agents were.
There is no good reason to turn an always-available relationship into an always-growing surveillance file.
The relationship needs a memory both sides can challenge
So who owns the conversation between my agent and my bank?
The legal position will vary by jurisdiction and record type. As a product rule, neither side should control a complete, editable version of the exchange.
My agent should remain responsible for my private context, instructions and permissions. The bank should remain responsible for its advice, controls, decisions and internal evidence. For consequential exchanges between them, both sides should retain the same verifiable receipt, subject to the legal and recordkeeping duties that apply to each.
That receipt does not need to reveal everything. It needs to let either side answer a few ordinary questions later: What did I ask? What did you receive? What were you allowed to do with it? What happened next? Who accepted responsibility? Has anything changed?
If agents become the primary way that a banking relationship prepares work, these disagreements will not be rare edge cases. They will be part of running the relationship.
We should not ask a client and a relationship manager to compare two technical logs and guess which history is true. The relationship should remember enough to be challenged and repaired, while leaving the rest of each side’s private life where it belongs.
Sources
- NIST: AI Agent Standards Initiative, created 17 February 2026 and updated 14 August 2026.
- NIST NCCoE: Software and AI Agent Identity and Authorization, draft-project status
reviewing commentswhen checked on 22 August 2026. - FINRA: GenAI — Continuing and Emerging Trends, part of the 2026 Annual Regulatory Oversight Report published 9 December 2025.
- ISO/IEC TS 27560:2023: Privacy technologies — Consent record information structure, published August 2023 and marked for revision.
- EU GDPR: Articles 16 and 19, covering rectification and notification to recipients.