Vendor Bank Detail Changes: No New Account Paid Until It Is Verified

The request that looks routine is the one to slow down

A vendor writes to say its bank has changed and asks for future payments to go to a new account. Most of these requests are genuine. The fraudulent ones are written to look exactly like them. The AP team's control is a rule order: the sender has to match the vendor's domain on file, a signed letter has to be in the file, and a callback to the phone number already on record has to confirm the change. A request that fails a rule is held or rejected, and only held or rejected requests get an escalation tier.

Requests arrive in Outlook, usually forwarded by the buyer who manages the vendor. Vendor records live in Salesforce, signed letters in Box, the callback log in Google Drive, and security posts its alerts in Slack. When an alert lands days after a request was reviewed, someone has to work out what that request should be now. The easy mistakes are to change the status and keep the old reason, or to re-check only the rule the alert mentions when the whole order needs to run again.

Who works in the room

Ada is the room's default agent and leads every thread about a request. The review report and the watchlist route to Nova, which the guidelines name as the second reader. Fin owns outbound mail, and Ada hands off by mentioning Fin with the request ID, the vendor ID and the approved reason. Each agent turn that reads a request or proposes a change keeps a step-by-step record of what it read, so the trail behind any decision can be shown to an auditor.

The life of a change request

Requests move through the same order every week, and every stage ends with a person.

When a callback or a fraud alert arrives late

Most updates touch very little. A callback log entry for two vendors re-runs those two requests and leaves the others as they are, because a status change on a request nobody called about is noise the AP manager then has to undo. Ada reads the update, names the requests it reaches and proposes changes only for them.

A fraud alert is different. Once security confirms a spoofed sender, the request goes back through the whole rule order from the top. The sender check now fails, so the request is rejected for that reason, whatever its letter or callback showed, and the tier follows from the new disposition. The reply to the buyer who forwarded the request goes on the thread it came in on. Spoofed requests often quote a vendor name or ID that is slightly off, so the reply states the corrected vendor ID from Salesforce and the new reason. Nothing goes to the address that asked for the change.

What the checks catch

• A request still held for a pending callback after security confirmed the sender was spoofed
• A callback made to the phone number in the request rather than the number already on file
• A callback log update applied to every pending request instead of the two it names
• An escalation tier set on an approved request, where only held or rejected requests carry one
• A reply that quotes the vendor ID from the request instead of the corrected ID on record

What stays with people

• Approving every bank detail change before Salesforce is updated and before any payment uses the new account
• Making each callback, which an AP specialist does by phone
• Confirming fraud, which belongs to security
• Sending every reply and confirmation Fin drafts

Integrations in this workflow

Kylon is not a vendor master or a payments system, and it replaces neither. It sits across the mailbox, the vendor records and the evidence files the AP team already uses, and holds the coordination between them.

• Box
• Gmail
• Google Drive
• Outlook
• Salesforce
• Slack

• Salesforce holds the vendor records and each change request, with its disposition, reason and tier
• Outlook is where change requests arrive, and where replies to the forwarding buyer wait as drafts a person sends
• Box holds the signed bank letters on vendor letterhead
• Google Drive keeps the callback log, the change control rules, the review report and the watchlist
• Gmail carries a fresh confirmation to the vendor contact already on file, never to the requesting address, as a draft a person sends
• Slack is where security posts fraud alerts and AP specialists post callback results

Where to start

A single week of open requests is a good first cycle. Connect the Salesforce vendor object and the AP mailbox in Outlook, and point Ada at the Box folder of signed letters and the callback log. Then write one rule into the room guidelines: no bank detail changes in Salesforce until the callback to the number on file is logged and the AP manager approves the change in the thread.

“The letter was perfect. That is why the sender check comes first.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.