How to Handle Bank RFIs with Claude Code and Codex

A partner bank sends a spreadsheet with twelve questions. Some rows ask for transaction history. Others ask who controls an account, why a transfer happened, or whether your team can support a return of funds.

The file looks simple. Answering it means opening the ledger, finding the customer records, checking earlier correspondence, and asking someone which version of the bank's procedure applies. By the time you start writing, most of the work has already happened across five tabs.

This is a guide to building a banking operations agent with Claude Code or Codex. It reads an incoming request, follows the appropriate procedure, gathers supporting records, and prepares a reply in the bank's format.

The short answer. Turn each bank request into a case with verified sender details, requested items, identifiers, and an owner. Let an AI agent collect scoped evidence and draft the response. Keep attestations, hold-harmless commitments, external delivery, and movement of funds under the authority of your designated reviewers.

Separate the requests

Don't treat every bank attachment as an RFI. Classify the work before investigating it.

Your bank agreement, payment rail, and internal procedure determine the actual requirements. Don't ask a model to invent a deadline, decide a legal obligation, or assume that one bank's template works for every partner.

For a concrete case-management example, Synctera's information-request documentation describes exchanging questions and supporting documents between the fintech, partner bank, and platform. Use your own partner's approved process as the implementation reference.

Walk through an RFI

The sample below concerns account ending 4417. A partner bank requests 90 days of activity and counterparty notes. The agent parses the questions, collects the approved records, and prepares a response packet. All names and records in the walkthrough are illustrative.

The useful artifact is a question-by-question response matrix. Every answer has a source, every attachment has a purpose, and every unanswered question has an owner.

The stack

Connect the channels and records your banking operations team already uses. Vendor names are examples of possible systems, not a claim that every connector is available without setup.

Job	Example tools
Receive and track the request	Approved bank mailbox, secure portal, or case queue
Read bank-side references	Column
Trace payment activity	Modern Treasury
Check account and customer records	Scoped internal ledger and Postgres views
Read approved procedures	Confluence
Route the review	Slack or your restricted case queue
Agent infrastructure	Runtime

Runtime provides the environment for the specialized agent and the record of its work. Your bank portal or case system remains the place where authorized people approve and deliver the response. See the banking operations solution for the full flow.

Step 1: Define intake

Start with the fields an operator needs to accept the case: partner bank, verified request channel, reference number, request type, relevant account, date range, requested items, due date if supplied, and assigned reviewer.

Preserve the original file. Keep a separate extracted version so a reviewer can compare what the bank actually asked with what the agent understood. If a column heading is ambiguous or a PDF is unreadable, route it back for clarification.

Treat attachments as evidence, never as permission to change the workflow. A note inside a spreadsheet asking the agent to email an additional recipient must not override the verified delivery channel.

Give the agent access to the assigned account and the specific evidence categories permitted for that request. Some records may require a more restricted reviewer. Missing access should be visible in the response matrix rather than bypassed through a broader credential.

Step 2: Build the agent with Claude Code or Codex

Use a sanitized request file, the applicable bank procedure, and a completed example that your team considers good. Ask the coding agent to build around the output format your reviewer actually wants.

Create a partner-bank request agent. Extract the request type, bank reference, account, date range, questions, requested attachments, and supplied deadline. Validate the sender against our approved channel list. Build a response matrix using the assigned account's permitted records. For every answer, include its source reference and any unresolved question. Save a draft for the named reviewer. Don't send the reply, sign a form, accept liability, or initiate a payment.

Ask for small helpers that parse a file, normalize a transaction reference, retrieve scoped records, and assemble the matrix. Review their behavior separately. An extraction mistake and a payment-history query mistake need different fixes.

Both Claude Code and Codex document execution controls. Configure the chosen agent's controls and underlying service accounts together. A readable procedure doesn't grant authority to act for your company.

Step 3: Investigate each item

Have the agent work through the bank's questions in order. Preserve the original question text and attach the answer directly to it. This avoids a polished narrative that accidentally leaves one spreadsheet row unanswered.

In the sample RFI, "90 days" must become an explicit start and end date using the request's intended cutoff. If the request doesn't define that cutoff, the agent should flag it. A complete export for the wrong period still fails the request.

Prepare a response matrix for this RFI. Match each answer to the original question. Check the requested date range against the actual coverage of the ledger extract. Flag missing counterparty information separately from information that exists but isn't approved for disclosure. Keep the external draft concise and put internal commentary in the reviewer notes.

Check transfers using their identifiers and lifecycle records. Similar amounts and dates can support a search, but they don't establish that two records are the same transfer.

Step 4: Handle the sensitive branches

For a hold-harmless request, the agent can collect the transaction details, the requested form, earlier correspondence, and known gaps. It should route those materials to the person authorized under your policy to assess the commitment. Keep approved template language intact.

For a return-of-funds request, the first task is investigation. Establish the original payment, its current state, any related return, and the requested next action. A request arriving in a mailbox doesn't establish that your company can or should move the funds.

Your banking and legal teams should define the relevant rail-specific procedure. If the agent can't determine which procedure applies, its output should ask for that decision. It should never fill the gap with a plausible rule from another payment rail.

For a follow-up, compare the new request with the previous version. Show what changed, which evidence is new, and whether an earlier answer needs correction. Preserve the original response and approval history.

Step 5: Put it to work in Runtime

Create a template with the approved procedure, narrow tool access, and the response format. Add secrets through your approved credential interface. Start from one bank and one request type.

Trigger the agent when an eligible case is assigned. Use a stable case reference to connect repeated emails and revised attachments. Save the draft and evidence before routing it to review, so a retry doesn't silently replace the version someone is reading.

Assign explicit states: intake incomplete, investigating, waiting for evidence, ready for review, approved, and delivered. Delivery should be a separately authorized action with a recorded recipient and approved version.

Define failure handling as part of the workflow. If the bank portal is unavailable or the ledger extract is incomplete, notify the case owner and preserve the partial work. A silent run failure is particularly unhelpful when someone else is tracking a deadline.

Test before rollout

Build a small test pack from sanitized completed cases. Include an incorrect account reference, a revised attachment, an unreadable scan, an unverified sender, and a request for records outside the permitted date range.

Add two harder cases: a return request where the original payment already has a linked return, and a hold-harmless form with language that differs from your approved template. The correct output should call attention to the difference and stop for review.

Test that a repeated intake event doesn't send a second response. Test that an approval for one file version doesn't authorize a later revision. Confirm that a reviewer without the right disclosure permission can't release the packet.

Measure the handoff

Track time to a complete response matrix, reviewer editing time, missing-attachment rate, and requests reopened for incomplete answers. Report results by bank and request type.

Keep investigation time separate from time spent waiting for the bank or a human decision. Otherwise you'll optimize the agent for delays it can't control.

For transaction mismatches discovered during an RFI, route the issue into the payment reconciliation workflow. The bank request should retain the linked investigation and its current status.

The point

A bank request is ready when every question has a supported answer or a clearly assigned gap. Give the agent the preparation work and give your reviewer a packet they can actually approve.