Separate account work from customer support
A support assistant can explain where to find a statement or summarize published account terms. A banking agent becomes operationally relevant when it works with account-specific information or prepares an action for a financial system. Define the input and output before comparing providers: a statement summary, a list of unexplained debits, or a proposed payment instruction are each different deliverables.
This guide uses a fictional company, Larch Studio, that wants to investigate a $2,400 supplier payment. The company has an invoice, an accounting entry and a bank status record. Its first task is to establish what happened to that payment. The task does not require creating another payment, changing a beneficiary or giving the agent access to every company account.
Keep the distinction in your evaluation brief. “Answer questions about business banking” is too broad to test. “Find the status and reference for payment LARCH-24 from the authorized account and show the underlying evidence” gives the agent an observable task and gives a reviewer something concrete to check.
Four banking actions with different permissions
Scroll the table to compare all columns.
| Action | Input | Output | Permission boundary |
|---|---|---|---|
| Read | Permitted statement or payment-status record | Referenced explanation with timestamp | No instruction or beneficiary change |
| Prepare | Approved business request and verified beneficiary | Versioned payment proposal | No release authority |
| Approve | Specific proposal and supporting evidence | Decision by the authorized approver | Approval tied to unchanged fields |
| Execute | Valid approval and permitted connection | Provider instruction reference and status | Only the defined account, amount and action |
Treat documentation access as documentation access
J.P. Morgan's public MCP page describes a server for searching and retrieving Payments Developer Portal documentation and finding related material. It does not describe that server as a tool for reading your business balances or sending payments. A developer assistant may use it to understand an integration; that does not supply account authority. [1]
This distinction matters because the same protocol name can appear beside very different tools. A documentation tool retrieves published pages. An account-data tool reads records available to an authenticated customer. An execution tool submits an instruction. Ask the provider to identify the actual tools, environments and permission requirements for your task instead of inferring money movement from an MCP logo.
For Larch, documentation retrieval helps the integration team understand a status endpoint if the relevant banking product provides one. The live investigation still needs a legitimate connection to the company's payment records. If that connection is unavailable, the agent should report the missing evidence rather than fill the gap with a status guessed from general banking knowledge.
Map the permitted route to the bank
The access diagram is a recommended architecture for the evaluation, not a claim that every bank supplies these components. The agent requests a defined tool action; a policy layer checks the request; the bank connection uses its own credentials and permissions. The application records the outcome and sends unresolved states to an authorized reviewer.
Decide which accounts the task can access, which fields it needs and whether it may retain documents. A payment investigation might need an instruction reference, amount, currency and status timestamp. It should not need unrestricted access to payroll attachments. Narrowing the data scope also makes the review manageable: the operator can see which record supports the conclusion.
Credentials belong to the integration boundary. The language model does not need to print an access token into its explanation or copy it into a transcript. Give the agent a tool with a defined operation and a structured result. Treat a tool failure as a failure to obtain evidence, not as evidence that a payment failed.
A controlled route to account evidence
- Agent request
Ask for a named operation and provide the permitted record reference.
- Policy check
Verify scope, account access and any required approval.
- Bank connection
Use the provider-supported authenticated operation.
- Evidence record
Retain the returned reference, status and observation time.
- Reviewer
Investigate missing or conflicting evidence before another financial action.
Design the investigation around conflicting evidence
Suppose Larch's accounting entry says paid, while the available bank record says submitted. The agent should display both states with their sources and timestamps. It should not silently choose the more reassuring label. The reviewer can then ask whether the accounting entry was created when the instruction was prepared or after the bank confirmed its result.
Add a delayed response to the test. If the status request times out, the correct output may be “status unavailable; last confirmed state submitted.” This is a useful financial answer because it preserves the uncertainty. Automatically preparing a replacement payment at that point would introduce a second task and a possible duplicate instruction.
Also include a currency mismatch and a similar reference belonging to another account. Matching the amount alone is weak evidence for identity. Require the agent to show the relevant account, currency and stable reference before it concludes that a bank record belongs to the supplier payment under investigation.
If the provider does not expose the status detail needed for the decision, record that as an integration gap. A well-written explanation cannot compensate for absent account evidence. The next step may be a manual bank inquiry, rather than broader model access.
Keep preparation and release separate
A later phase might allow the agent to prepare a payment instruction for Larch. Specify the permitted payer account, verified beneficiary, amount, currency and purpose. A reviewer should see those fields together, with the invoice and the exact version of the proposed instruction. A free-text approval that cannot be connected to a version is hard to interpret after a change.
For this recommended workflow, a changed beneficiary invalidates the earlier approval. The agent returns the proposal for review and does not replace the bank details automatically. Apply the same reasoning to changes in amount, currency or payer account. These recommendations define the pilot's boundary; they do not claim that a particular bank enforces every check for you.
Check how your chosen bank connection represents rejection, acceptance and a later status update. The integration should retain the bank's actual status rather than collapsing every response into success. When the provider's documentation is unclear, ask for a supported explanation before designing an automatic follow-up action.
Evaluate a small banking pilot
Begin with a read-only task across a deliberately limited set of copied records. Ask the team to label the expected outcome for each case: confirmed, unresolved, conflicting or outside scope. Record missing evidence and incorrect conclusions separately. A high completion count is unhelpful if the agent hides the cases that require a bank operator.
Then test permission loss. Remove the connection during a run and confirm that the agent stops relying on it. Check that a retry does not quietly expand account scope or submit an instruction that was previously only a draft. Assign one person to restore access and another, where your policy requires it, to authorize payment release.
The output of this pilot is a decision about one workflow: whether the available data, tool permissions and review process support it. It is not a general endorsement of autonomous banking. Use the business-account guide for a beneficiary-change example and the control checklist to assign the remaining integration questions.