In any discussion of B2B payment security, someone inevitably presents the idea: what if we cut out the person-to-person verification step entirely? No callbacks, no identity checks; just confirm account legitimacy directly.

It’s an appealing thought. But as soon as you start digging into the details of how, exactly, this could be done, it falls apart.

Banks as a source of truth

The obvious approach: check the account owner in the bank’s records, and make sure that it’s the person or entity you want to pay.

For the most basic form of this, you don’t need any special platform. When you log in to an online portal to place a wire or ACH transfer, your financial institution will ask you to input the name of the account holder. So now the bank knows where you want the money to go, and will make sure it gets there, right?

Unfortunately, no. The default behavior of financial networks is to send funds based on the routing and account numbers, ignoring the name.

Banks will sometimes return payments if they detect the names don’t match. In the US for example, it’s required by the Uniform Commercial Code that banks stop the payment if they have “actual knowledge” that the names don’t match. But the UCC also specifies that “The beneficiary's bank need not determine whether the name and number refer to the same person.”

There have been court cases over the details of this law. The outcome has been that banks are allowed to design their internal systems to not give them “actual knowledge” of such discrepancies. In other words, if the bank checks the name and sees a problem, they have to do something about it, but they don’t have to check. Banks tend to take the second option.

Globally, this is slowly changing. The European Payments Council recently mandated the Verification of Payee standard, to be rolled out across the Single Euro Payments Area (SEPA) by mid 2027. This standard enforces that banks must always check the name on the recipient account, and give the sender the opportunity to cancel the payment if it doesn’t match what they expected.

Some other locations are moving towards (or already have) similar initiatives, like the UK and Australia’s Confirmation of Payee systems. But in the United States and many other countries, no such system is on the horizon.

So if you can’t trust the banks to check the name on the account themselves, how can you use that information to protect yourself? Roughly, there are two options: obtain it from the banks in another way, or check it yourself.

Products like Early Warning take the first option: make several custom agreements with individual banks to query their data, then resell this as a package deal.

These services are valuable, and they’re widely used. But by its nature this model cannot be comprehensive. There are more than 4,000 banks in the US alone, more than 20,000 worldwide, and only a tiny fraction of them are willing to share this kind of data with any given third-party platform.

When we talk to prospective clients about why they’re moving away from reliance on this model, it’s nearly always due to the tremendous gaps in coverage, often with fewer than 60% of their payee’s accounts having a record in the system.

This leaves the option of checking the information yourself. Platforms like Plaid or Yodlee will log into the recipient’s bank account and verify ownership details using this direct access. These solutions can get better coverage rates, but they require the recipient to hand over their bank login credentials. Many people are not comfortable doing this, and many people cannot do this. An accounts receivable clerk, for example, will know only the company’s account number; not its password!

All-in-all, it’s feasible to get ownership data on some accounts, but surprisingly difficult to get that data on anything approaching all accounts.

Names aren’t an identity

All of this hassle has been about obtaining one piece of information: the name on record with the bank as the owner of the account. However, having access to the name on the account is still not enough to provide assurance.

Problem #1: Is that information relevant?

A substantial fraction of business wires are paid to FFC (For Further Credit) accounts. An FFC account is a bank account owned by a brokerage, wealth manager, or other intermediary that accepts payments on behalf of its clients. When sending to an FFC account, you’ll specify a second account number “for further credit”, requesting that the intermediary forward those funds within its own system to the ultimate beneficiary. 

The actual account holder on an FFC account is the intermediary. The FFC instructions are, as far as the receiving bank is concerned, a “notes” field. This means that any fraudulent FFC account will pass account ownership checks with flying colors, as the owner will be “Morgan Stanley” or “Charles Schwab” or some other large institution. None of the methods of querying account ownership listed above are capable of “drilling down” to the ultimate account holder identified in FFC instructions.

Problem #2: Is that information correct?

Think back to the last time you opened a bank account; did the bank ask you for an ID? There’s a thriving black market for those. Corporate paperwork? An hour in Microsoft Word and you could have paperwork that shows you own Microsoft.

In the United States, the PATRIOT Act requires only that banks “establish the accuracy of enough information to form a reasonable belief it knows the true identity of the customer.” Banks are given broad latitude in how to interpret this prescription, and in practice they tend to err on the side of less scrutiny rather than more. The Federal Reserve cites a report finding that 1-3% of all bank accounts in the US were opened under a fake identity.

Broadly-speaking, KYC and AML controls are designed to let a non-negligible fraction of less-than-well-intentioned entities register. This is a sensible policy decision in the interest of usability for everyone else, but the bank can’t know in advance how large incoming transfers are going to be. So the level of scrutiny they apply to all accounts may be lower than you’re comfortable with for your transfer.

Problem #3: Is that information sufficient?

Even if the bank has the right name on the account, a name does not uniquely identify a business entity.

A single business will often have multiple legal entities that could appear on its accounts. If you’re trying to pay Google, there are any number of possible names: Google LLC, Alphabet Inc, Google Commerce Ltd, Google Payment Corp, XXVI Holdings Inc, Google North America Inc, and several more.

This is a large part of why many banks don’t block transactions with a non-matching name; it would lead to massive numbers of legitimate payments being flagged. This is not theoretical: upwards of 30% of legitimate payments are being flagged by the Verification/Confirmation of Payee systems being implemented in other countries.

But the real risk arises in the opposite direction. Just as one organization can have multiple names, one name can apply to multiple organizations. Consider how many distinct entities in the US alone could be reasonably identified as “Synergy Group”. Hint: It is significantly more than the 1-per-US-state one might assume from corporate name uniqueness laws. The existence of words like “holdings”, “ventures”, and “enterprises”, not to mention “LP”, “LLC”, and “Inc”, is sufficient to distinguish two legal entities, but is frequently not surfaced in the fuzzy-matching used by most methods that exist to query an account holder’s name.

You might want to pay “The real Google”, but if a fraudster has registered a shell company with a name like “Google Holdings Inc.”, most account name checks are going to see that as “close enough” and let the payment proceed.

(Large companies like Google will go after impersonators via trademark law, but this can take weeks or months- plenty of time for a fraudster to take advantage of the lookalike name in the mean time. And smaller companies don’t have the resources or brand recognition to enforce that their name be unique.)

The barrier to registering a new corporate entity is quite low. A few minutes of online paperwork, a trivial fee, and you too could be the owner of a company whose name is quite similar to, well, anyone.

Alternatives

These flaws have led people to look for alternative methods to verify account legitimacy — ways that do not rely on bank ownership data. Unfortunately, these methods are even less reliable.

Alternative #1: Microdeposits

You may have encountered microdeposits in your personal banking: someone sends you some tiny transactions of a few cents each, and you confirm the amounts.

Some providers claim that they can use microdeposits to combat push payment fraud. They cannot.

In a typical push payment fraud scenario, the fraudster has already inserted themselves into an email chain or gotten their phone number into your records. They then use this access to provide their own bank details for a payment you’re about to send.

If your authentication solution involves asking them to confirm small amounts sent to the account they’ve provided, the fraudster will pass easily …because they own the fraudulent account!

Microdeposits can be helpful in other ways, like making sure that the person did not typo their account number, or preventing pull payment fraud, where a fraudster tries to pay from someone else’s account. But for push payment fraud (which includes all wire transfers and most B2B ACH transactions) they only provide a false sense of security.

Microdeposits confirm access to an account. They do not confirm legitimacy.

Alternative #2: Statistical history checks

Another common approach is to check the history of the account for indicators of fraud, like atypical transaction patterns. This is the primary method used to fight credit card fraud, with providers like Stripe Radar ingesting huge amounts of data and learning statistical patterns. A similar form of analysis can be performed on bank accounts; this is most frequently done internally by the banks themselves, but some providers also offer these warning signals to others.

Problems can arise trying to apply these methods to B2B transactions. Consider some common indicators of fraud:

• The account was recently opened.
• The account is registered to an entity that does not appear in prior records.
• The transaction is much larger than previous transactions of that account.

What else is perfectly described by these indicators? A new startup accepting venture funding.

Statistical checks work by flagging atypical behavior, but for the receiving party, investments are atypical. A simple statistical algorithm will struggle to tell the difference.

Historical analysis does better for transactions with a more consistent profile, such as vendor payments. But there’s another reason why statistical methods fall flat for B2B transactions: the amounts are larger.

The average credit card transaction is $80. Whatever fraud analysis a card provider is going to do, it needs to be done for a few cents, in a fraction of a second. Stripe Radar advertises a 38% reduction in fraud; that’s a lot better than 0%, but it’s also not 100%. There is an upper limit to how much signal can be derived from blunt statistical approaches.

Business transactions are larger: anywhere from $10,000 to $10 billion. At these scales, a 38% reduction in the chance of fraud would be nice, but spending a few extra dollars to take that reduction up to 99% starts to look more appealing.

To put it another way, consumer fraud is a numbers game; hundreds of thousands of stolen credentials being tried automatically by malicious software. In business email compromise, the fraudsters (or their AI agents) are giving you their personal attention.

They might spend months “seasoning” bank accounts they control with legitimate deposits and withdrawals before using that account to perpetuate a single large fraud. Or they might hire the services of a money mule: a formerly-legitimate person or business who (knowingly or unknowingly) offers up their account as an intermediary for fraud. Money mules pass account history checks easily, because up until the fraud in question, they were legitimate accounts.

Note that banks already use these analysis methods internally. They keep an eye out for suspicious transaction patterns, compile fraud reports, and close accounts that are suspected of being used for crime. But this is insufficient to fully prevent fraudulent accounts. And for a third-party solution to provide value, it needs to be better than the banks at detecting fraud, which is a tall order.

Looking at historical indicators is reactive. Algorithms notice fraud that has already occurred and flag the associated accounts to be blocked. In environments where a single fraud would be too much, this is not good enough. You need a proactive solution that can identify fraudulent accounts before they’re first used.

Alternative #3: Known account matching

This leaves one more method: building a database of trusted accounts from scratch, outside of the banking system.

Various platforms offer this service (usually in combination with name-matching like Early Warning). When a company onboards to such a platform, the platform will ingest that company’s existing payment records and add those records to a central database of known accounts, allowing all their clients to reference this database for their future payments.

This makes your safety dependent on all other companies in the network. If any of the platform’s other clients have incorrect credentials in their records, your records are now contaminated too.

But there’s a deeper problem: what do you do when you need to pay someone new?

Coverage on these tools is even worse than account lookup tools, because in order to get a match, you or someone else in the network has to have paid that exact account before. Scale doesn’t solve this; new accounts and new companies are created every day.

So you’re going to have to onboard new payees for many of your transactions, and these platforms generally don’t offer much in the way of security for onboarding. Sometimes they’ll rely on the other methods in this article, like account name or history checks. Sometimes they’ll do ID-based authentication, which is invasive and increasingly defeatable by artificial intelligence. Sometimes they’ll rely on manual phone conversations, which comes with all the downsides we explored in our callbacks article.

Often they’ll make you be the guinea pig, leaving you on your own for the first payment and only adding the credentials to their database after you’ve confirmed nothing went wrong.

These platforms aren’t trying to solve the problem of fraud. They’re hoping that someone else solves the problem for them, with the platform simply keeping a record of the results.

The way forward

Except for microdeposits, all of these methods do have something to offer for business email compromise fraud prevention. Account owner mismatches and historical behavior analysis can flag transactions for a deeper look, and trusted databases can save time with known counterparties.

But none of these methods are capable of providing the robust safety guarantee that you need before sending large transfers to someone you’ve never transacted with before. For that, you need a more advanced solution.

‍