Bank account verification software: what it stops on a loan payoff

Bank account verification software checks that the account a payment is about to go to is the right one: that it exists, that it belongs to the payee, and that it matches the account the payer already verified. It is sold alongside a wider category of payment-fraud tools that contains two incompatible kinds of product. One watches payments and produces a score, an alert or a case for somebody to look at. The other sits inside the payment process and refuses to let a payment go until a named condition is met. Both are useful; only the second one stops a fraudulent payoff on the afternoon it arrives, because the fraud this category is mostly bought for is not an anomalous payment — it is a perfectly ordinary payment to a slightly different account. Botminds' Drawdown & Payoff Request Processing is an example of the second kind, narrowly scoped to the loan payoffs and draws a funding desk releases.

The examples come from the solution's sample funding desk, on fictional banks, borrowers, accounts and domains. The loss and recovery figures are the FBI's; the supervisory material is linked where it appears.

What does bank account verification software actually do?

Four things get sold under this name, and a buyer who does not separate them will compare products that do not overlap. The first is transaction monitoring: a model scores payments against the customer's history and produces alerts for a team to work. The second is authentication: multi-factor checks, device and session signals, callback-on-login. The third is sanctions and payee screening against lists. The fourth, and the one this page is about, is account verification, which itself comes in two forms. An external check asks a data source whether an account is open and whether the name on it matches the payee. An internal check compares the instruction you have been sent against the instruction you already hold for that payee, and refuses to release while they differ. The external check is useful against a typo or a closed account; on a redirected payoff it can pass, because a criminal can open an account in a name close to the payee's. The internal check is the one a changed account cannot get past.

The OCC's fraud risk principles take a deliberately unexcited view of the category. Software and technology tools "can assist with anti-fraud efforts", it says, and "bank management should consider the cost and value of fraud prevention tools selected, consistent with the bank's overall strategy, complexity, and risk profile", adding that such tools "should evolve and adapt to remain effective against emerging fraud types" (OCC Bulletin 2019-37). Assist is the operative word. The control is the bank's procedure; the software is how that procedure is applied to every payment instead of to the ones somebody had time for.

The supervisors are visibly still working on the payments side of this. In June 2025 the OCC and the other federal banking agencies issued a request for information on payments fraud, "asking stakeholders for feedback on potential actions they may take collectively or independently to help consumers, businesses, and financial institutions mitigate check, automated clearing house, wire, and instant payments fraud" (OCC, Semiannual Risk Perspective, Fall 2025). A buyer should read that as a signal that no product can be bought in the expectation that it settles the question.

One more distinction saves a wasted evaluation. Most products in this category were built for accounts payable, where the instruction is an invoice from a vendor with a long payment history and a predictable amount. A loan payoff is a different animal: it is usually a first and only payment to that payee, the amount is large and unrepeatable, the counterparty is frequently another lender rather than a supplier, and the deadline is a good-through date that costs the borrower a per diem if it slips. A product whose controls assume payment history will have little to say about the payment where history does not exist.

Can account verification stop business email compromise? Scoring is not holding

It can stop the payment; it cannot stop the compromise. The email was sent from a mailbox or a domain outside your bank, to an address outside your bank, and by the time the instruction reaches your desk the attack has already succeeded everywhere it needed to. What remains in your control is the last step: whether the money leaves.

That is why the detection framing fails here. A payoff of $2.85 million from a commercial borrower that pays off loans regularly is not anomalous in amount, timing, channel, counterparty type or purpose. Every feature a monitoring model uses looks normal, because everything about the payment is normal except the twelve digits of the account number. The only signal available is that those twelve digits are not the twelve digits you used last time — and that is a comparison, not a score.

There is also a version of this attack with no lookalike domain in it at all. Where a payee's own mailbox has been compromised, the letter arrives from the genuine address, inside the genuine thread, signed by the person who signed the last one, with the fraudulent account substituted into an otherwise authentic document. Every sender signal is clean, because the sender is real. That case is the reason the comparison against your own record cannot be treated as the backstop behind sender analysis: it is the primary control, and sender analysis is the thing that occasionally catches the lazy version first.

The three places a fraudulent payoff can be caught

Between an email arriving and money settling in a stranger's account there are exactly three opportunities, and they are not equally good. Knowing which one a product occupies is most of the buying decision.

Most products sold against payment fraud occupy the first position, because sender and content analysis can be bolted onto a mail flow without touching the payment process. It is real value and it is the weakest of the three, because the signal it reads is the one a competent attacker controls. The second position requires the product to hold the payee file and see the instruction; the third requires it to be able to stop a button. Each step down that list is harder to integrate and strictly more effective.

Questions to ask any vendor about a changed account

Nine words decide this category: can it stop the payment, and who can unlock it. Everything below is a way of asking those two questions so that a demonstration cannot answer them with a colour.

Why the control has to sit where the request is read

A verification control placed at the payments system is placed too late, and the reason is organisational rather than technical. By the time an instruction reaches the payments system it has been retyped by a person who has already decided it is genuine. The decision was made upstream, in a mailbox, by someone comparing a letter against their memory of the last one.

Put the comparison where the document is read and three things change. The verification happens before anyone has formed a view, so there is no decision to overturn. The four document signals — domain age, spelling distance, reply-to, how the file was produced — are still available, because the original email still exists; at the payments system they are gone. And the person who has to act on the result is the person who has the payee's telephone number and the relationship to use it.

There is an organisational version of the same argument. Where the control lives in a different team's product — payments, or fraud, or security — the funding desk learns of a problem through a message from people who do not know the payee, do not hold the relationship and cannot make the telephone call that resolves it. The handoff costs an hour on a good day, and on a Friday afternoon it costs the cut-off. A control whose resolution path runs through another department is a control with a queue in the middle of it.

This is also the honest answer to "why not just train the staff". Training works on the first letter someone sees and decays against the four hundredth. A comparison performed by software does not get tired at 3:40 p.m., and a lock does not get talked out of its position by a relationship manager who is sure this payee is fine.

Every check green, and the release still requiring two people

The line to read is the one about co-approval. A control that ends at 'all clear' has delegated the last decision to whoever is holding the mouse.

What the law expects of your procedure, not of your software

There is no legal standard for fraud software, and there is one for the procedure it supports. Article 4A of the Uniform Commercial Code, which governs funds transfers, makes a bank's position turn on a security procedure agreed with its customer: where such an agreement exists, an order received in the customer's name binds the customer whether or not it was authorised, if the procedure is a commercially reasonable method of security and the bank accepted the order in good faith and in compliance with it (UCC § 4A-202(b); quoted in full in our guide to bank liability for wire fraud).

Two things follow for a buyer. The object being tested is a procedure, not a product: what your people are required to do, written down, applied consistently and provable afterwards. And compliance with it is part of the test, which means a procedure your desk routinely departs from at 3:50 p.m. is worse than a simpler one it always follows. Software earns its place by making the procedure the path of least resistance rather than an extra step.

Who ends up bearing a loss when the money has gone is a separate and far less comfortable question, and it rarely resolves the way operations teams expect: who loses when a loan payoff goes to a fraudster works through it for a payoff.

Test it before you buy it: three cases to send

Every vendor demonstration shows the catch. Send these three instead, during the evaluation, through the channel your real requests use, and watch what the product does without anybody steering it.

Then ask one question about each result: who could have made the payment go anyway. If the answer is a single person with no second approval and no record of their reason, the product has produced a warning, not a control, whatever the demonstration was called.

What being wrong costs, and who pays it

Business email compromise losses reported to the FBI's Internet Crime Complaint Center reached $3,046,598,558 in 2025, which sizes the category but understates the individual case: reported losses are a floor, and a commercial payoff is at the large end of the distribution. The more useful figure for a buyer is what happens after the money moves, because it is the only part of this story with a measured success rate.

Read the middle bar generously and it is still the wrong thing to rely on. More than half of reported critical-infrastructure losses were frozen in 2025, which is a genuinely good result for a recovery process and a terrible basis for a control: the freeze depends on the victim noticing within hours, on the receiving institution co-operating, and on the money not having moved on. Every one of those is outside your bank. The comparison that takes four seconds before the release is inside it.

What a quarter of this control looks like when somebody asks

The cost of being wrong is also not only the principal. It is the investigation, the relationship with a borrower whose payoff went astray, the examination finding about a control that existed on paper, and the subsequent months in which every payment is slowed because trust in the process has gone.

What Drawdown & Payoff Request Processing covers, and what it leaves alone

It is a control over outgoing instructions on loan draws and payoffs, at the point those instructions are read. The wire instruction guard compares beneficiary, bank, routing and account against the verified payee file and every past payment to that payee from any loan; checks the sender's domain age and spelling, the reply-to and whether the document came from the payee's portal; and locks the release until a call-back is logged. It never dials a number from the request, never unlocks a release itself, and never edits the payee file. Above $1,000,000 a second person approves.

What it is not: it is not an enterprise payments-fraud platform. It does not score transactions, monitor account behaviour, screen inbound payments, watch cards or deposits, or manage a fraud case queue. A bank whose problem is mule accounts or card fraud needs a different product and should not expect this one to help. A bank whose problem is that a payoff letter asked for a new account on a Friday afternoon is looking at the right shape of thing.

The procedure around it is the part worth as much attention as the product: what a call-back has to do to be worth making, and the nine fields and four signals the comparison actually uses. To see the lock, the call-back and the second approval on one afternoon, start from Drawdown & Payoff Request Processing.

Questions people ask

Does bank account verification stop payment fraud on its own?

No. An external check that an account is open and the name matches catches errors and some fraud, but a criminal can open an account in a name close to the payee's, and the check will pass. What stops a redirected payment is a comparison against the account you already verified for that payee, a call-back on a number you already hold whenever anything changes, separation between whoever maintains the payee record and whoever releases payments, and a second approval above a stated amount. Monitoring and authentication sit around those; they do not replace them.

What is the difference between fraud detection and a payment hold?

Detection produces information for someone to act on; a hold removes the ability to act until a condition is met. The distinction matters most at the end of an afternoon, when the information arrives in a queue and the payment is already at the network. Ask any product which of the two it does on a changed beneficiary account, and insist on seeing it rather than hearing it.

Who is liable if the software misses a fraudulent wire?

Liability turns on the agreements between the parties and on Article 4A of the Uniform Commercial Code, not on the software's performance, and the outcome is often that the party who sent the money bears it. A vendor contract may provide a remedy between you and the vendor; it does not change where the loss falls between the bank, its customer and the payee. Treat the software as a way of making your procedure reliable, not as a transfer of risk.

What belongs on a checklist for verifying payee bank accounts?

Six things, in this order: a verified payee record with controlled edit rights; a field-by-field comparison on every outgoing instruction; a call-back rule covering changes, first payments, dormant payees and out-of-channel documents; a number source that is always your own record; dual approval above a limit; and a stored record for each payment of the comparison, the call and the approval. Everything else is an improvement on those six, not a substitute for them.

Where should the control sit in the payment process?

Where the instruction is first read, which on a funding desk is the mailbox, the fax queue and the borrower portal — not at the payments system. Placing it earlier preserves the document signals, prevents a person forming a view before the comparison runs, and puts the result in front of the one person who can telephone the payee. A control at the payments system is verifying a retyped instruction that somebody has already accepted.

How do you test account verification software before buying?

Send cases rather than watch a demonstration: one genuine payment, one with a name-only change, one correct instruction arriving outside the agreed channel. Then ask who could have released each one anyway, and what a supervisor would have seen. A product that cannot be tested this way during an evaluation cannot be tested this way in production either.