Vendor Due Diligence in One Prompt: Validating Payees Before You Wire

Most of the money a company loses to fraud does not leave through a hack. It leaves through a payment the company approved on purpose, to a payee that looked right. The invoice matched a real vendor, the amount was plausible, and the only thing wrong was a routing number that belonged to someone else. Vendor due diligence catches that before the wire goes out, while catching it still costs nothing.

This post is a playbook for running those checks in one prompt. On Meow, an AI agent can take a payment request, find the saved payee, pull its open bills, validate the routing number against the Federal Reserve directory, confirm the account can receive an ACH, and screen the counterparty against sanctions lists, then hand a clean summary to a person for the final yes. Here is what each check does, and what it stops.

Where Vendor Payments Go Wrong

Before the checks make sense, it helps to name the failures they are built for. Four account for most of the money that goes astray.

Wrong routing number: a digit is transposed, an old account is reused after the vendor switched banks, or someone pastes the number for the wrong entity. The payment either bounces days later or lands in a stranger's account, and recovering it depends on a bank's goodwill.

Spoofed invoice and business email compromise: an attacker who has watched a real billing thread sends an invoice that looks legitimate with one change: new remittance instructions. The FBI calls business email compromise one of the most financially damaging online crimes, and the mechanism is almost always a quiet swap of the bank details on a bill you were already expecting.

A sanctioned counterparty: the payee, or a party behind it, appears on a sanctions list. Paying for it is not a customer service problem. It is a violation the bank and the account holder are both responsible for avoiding.

A duplicate bill: the same invoice gets entered twice, or a vendor sends a reminder the accounts payable inbox treats as a fresh charge. Nobody is defrauding anyone. The money still leaves twice, and clawing back the second payment turns into weeks of email.

None of these are exotic. Every one is visible before the send if someone looks. The point of putting an agent in front of the payment is that it looks every time, at every field, without getting bored on the four hundredth bill.

Vendor Due Diligence in One Prompt: The Check Sequence

The workflow starts with a plain request. You tell the agent to pay a vendor, or to clear this week's approved bills, and before it proposes moving anything it runs the same sequence. Each step can stop the payment.

Find the saved payee: the agent looks up the payment contact already on file rather than trusting the details on the incoming document.

Check outstanding bills: it pulls what this vendor is actually owed, so the amount is matched against a real open balance, not just asserted by an invoice.

Validate the routing number: it checks the nine-digit number against the Federal Reserve's directory of participating institutions to confirm the bank is real and the number is current.

Confirm ACH capability: it verifies the receiving account can accept the payment type you intend to send.

Screen the counterparty: the payee and its details are run against sanctions lists through the partner bank before anything is queued.

The agent then presents one summary: who is getting paid, how much, against which bill, on which verified account, with any flag it raised. That summary is what a person approves or rejects. Nothing moves until they do. The rest of this post walks through the individual checks.

Finding the Saved Payee and Its Open Bills

The first defense against a spoofed invoice is refusing to take payment details from the invoice. A saved payee is a record the business built once and verified once: the vendor's legal name, bank account, routing number, and payment terms. When asked to pay a vendor, the agent works from that stored contact, not the details printed on whatever document just arrived.

That single habit neutralizes the most common attack. If an emailed invoice carries a routing number that does not match the saved payee, the agent surfaces the discrepancy instead of following the new instructions. A change to a payee's bank details becomes an event a human has to confirm through a known channel, not a field that updates itself because a PDF says so.

Pulling the open bills does the second job. The agent matches the requested amount and invoice number to an outstanding balance. If the invoice has already been paid, or the amount does not line up with any open bill, that is the duplicate-payment catch. The vendor's real ledger position, not a document's arrival, decides whether a payment is due.

Validating the Routing Number Against the Fed Database

A US routing number is not a random string. It is a nine-digit ABA number with structure: the first four digits map to a Federal Reserve routing symbol, the next four identify the institution, and the last is a check digit computed from the other eight. A transposed digit usually breaks the check digit, and a made-up number rarely maps to a real bank.

The authoritative reference for which numbers are live is the Federal Reserve E-Payments Routing Number Directory, the same source financial institutions use to confirm participants. The agent checks the routing number on the payment against that directory and reads back what it finds: the institution the number belongs to, and whether it is a current, participating routing number.

This is where a swapped number stops being invisible. A routing number that fails the check digit, or that resolves to a bank in a different state than the vendor you think you are paying, is a flag the agent raises before the payment is queued rather than a mystery the receiving bank explains a week later.

Confirming ACH Capability

Validating that a routing number is real is not the same as confirming the account can receive the money the way you plan to send it. The number provided might be the vendor's wire routing number when you intend to send an ACH. Those are different numbers at many banks, and using the wrong one is a common reason a payment fails after you thought it was done.

The agent confirms that the receiving account can accept the payment method before the send, so the mismatch is caught up front instead of surfacing as a return two or three days later. A returned payment is not only a delay. It restarts the approval and reopens the window during which a fraudster can slip in with corrected instructions.

Screening the Counterparty

The last check is the one with legal weight. US persons and businesses are prohibited from transacting with parties on the sanctions lists administered by the Office of Foreign Assets Control, and the obligation is strict: intent does not excuse it. Screening the payee is a requirement the bank enforces on every transaction, not optional diligence.

On Meow, that screening runs through the partner bank as part of the payment, and the agent surfaces the result in its summary. The public reference is the Treasury's own tool, the OFAC Sanctions List Search, which checks a name against the Specially Designated Nationals list and the other consolidated lists. A hit, or a strong likelihood of one, stops the payment and routes it to a human. A sanctions question is exactly the kind of decision a person and a compliance process should own, not a model acting alone.

A Spoofed Routing Number, Caught

Here is the before and after, on one bill. A company works with a fabrication vendor it has paid monthly for two years. An email arrives that looks like the usual invoice: same logo, same layout, the expected amount. One line is different. The remittance section carries a note that the vendor has changed banks, with a new routing number and account number, and asks that this month's payment go to the new details.

Without the checks, this is how the money leaves. The invoice looks right, the amount is right, the accounts payable clerk updates the payee and sends a wire. Three days later the real vendor asks where its payment is. The money is gone, and recovery begins with a phone call to a bank that is under no obligation to help.

With the checks, this is what happens instead. The agent is asked to pay the bill. It pulls the saved payee and sees that the routing number in the email does not match the one on file. It validates the new number against the Fed directory and finds it belongs to a bank in a different state from the one the vendor has always used. It flags both facts and holds the payment. A person reads the flag, calls the vendor on the phone number already on file, not the one in the email, and learns the vendor never changed banks. The wire is never sent. The catch cost one phone call, because the discrepancy surfaced before the send instead of after it.

The Human Approval Gate

Every check above ends at the same place: a person approving a specific payment. The agent's role is to make that approval well-informed and fast, not to remove it. It gathers the payee, the bill, the validated routing number, the ACH confirmation, and the screening result, and presents them together so the approver sees a complete picture instead of a bare payment button. The gate is enforced by design, not by policy. By default the agent cannot move money. The account holder turns on each capability explicitly, wires on or off, ACH on or off, card issuance with caps, and every agent-initiated payment routes back to a human for approval through Claude, SMS, Telegram, or the Meow dashboard. Account and routing numbers are never exposed to the model. The agent does the diligence. The human owns the send.

Frequently Asked Questions

What is vendor due diligence before a payment? It is the set of checks a business runs to confirm a payee is real, current, and safe to pay before money leaves the account: verifying the vendor's saved payment details, matching the amount to an open bill, validating the routing number against the Federal Reserve directory, confirming the receiving account can accept the payment, and screening the counterparty against sanctions lists. The goal is to catch a wrong or fraudulent payment while catching it is still free.

How does an AI agent validate a routing number? It checks the nine-digit number against the Federal Reserve's E-Payments Routing Directory, the authoritative record of participating institutions, and confirms the number is current and maps it to a real bank. Because a valid routing number has a computed check digit and a structure tied to a specific institution, the agent can flag a transposed digit or a number that resolves to a bank inconsistent with the vendor.

Can this stop business email compromise? It stops the most common version of it. Business email compromise usually works by changing the bank details on an invoice you were already expecting. Because the agent pays from the saved payee on file rather than the incoming document, a changed routing number becomes a flag a human confirms through a known channel instead of an instruction that quietly executes. The FBI's guidance on business email compromise describes the same countermeasure: verify any change to payment details before acting on it.

Who runs the sanctions screening? The partner bank does, on every transaction. The payee and its details are screened against the sanctions lists administered by the Office of Foreign Assets Control, including the Specially Designated Nationals list. The agent surfaces the result, and a potential match stops the payment and routes it to a human rather than being resolved by the model.

Does the agent send the payment on its own? No. By default the agent has zero ability to move money. The account holder turns on each capability explicitly and sets the caps, and every agent-initiated payment routes back to a person for approval through Claude, SMS, Telegram, or the Meow dashboard. The agent validates. A human gives the final approval.

How does it catch a duplicate bill? By checking the vendor's outstanding bills instead of trusting the arriving document. The agent matches the requested amount and invoice number against what the vendor is actually owed. If the invoice has already been paid or the amount does not correspond to an open balance, the agent flags it before queuing anything.

What if the vendor really did change banks? Then the check turns a silent edit into a deliberate confirmation. The agent flags that the routing number changed since the last payment and holds the send. A person verifies the new details with the vendor through a channel already on file, updates the saved payee, and approves. A legitimate change costs one confirmation. A fraudulent one is stopped at the same step.

A Note on Meow

Meow does not replace an accounts payable process or an approver's judgment, and it is not designed to. What it adds is a payment layer where the diligence runs automatically and consistently: an agent that finds the saved payee, checks the open bills, validates the routing number against the Federal Reserve directory, confirms ACH capability, and screens the counterparty through the partner bank, then hands a person a clean summary and waits. That boundary is the product working as intended: the checks are automated so nothing gets skipped, and the decision stays with a human so nothing gets sent that should not.

The Bottom Line

A payment that goes to the wrong account is cheap to prevent and expensive to recover. Running vendor due diligence in one prompt puts the checks in front of the send and keeps the final approval with a person. Open an account at meow.com.

Meow Technologies is a financial technology company, not a bank or FDIC-insured depository institution. Banking services are provided by Grasshopper Bank, N.A.; Member FDIC. The FDIC's deposit insurance coverage only protects against the failure of an FDIC-insured bank.