Payee verification, Positive Pay, and fraud scoring are three different payment controls that stop three different attacks, and confusing them is a large part of why authorized payment fraud keeps getting through. Positive Pay matches a payment to a file you already gave your bank. Payee verification checks that an account belongs to the name you intend to pay. Fraud scoring rates how risky a transaction looks based on patterns. None of the three, on its own, stops a payment you were deceived into authorizing to a legitimate-looking payee, which is exactly how business email compromise and vendor impersonation take money. The 2026 AFP Payments Fraud and Control Survey found that 76 percent of organizations faced attempted or actual payments fraud, and 74 percent were hit by business email compromise1, the attack these controls most often fail to catch. The FBI put reported BEC losses at $3.046 billion across 24,768 complaints in 2025, with 86 percent moving by wire or ACH2. This guide lays the four controls side by side, explains what each one checks and misses, and shows which risk each one is actually for, so you can tell which gap you still have open. The honest short version: Positive Pay, payee verification, and fraud scoring each solve a real problem, but the authorized-payment problem needs a control that verifies the payee and the approval before the money is released.
The four controls, side by side
The fastest way to see why authorized payment fraud survives is to line up the controls by what they check, what they miss, and when they act. Three of the four fire either at your bank or on transaction patterns, and none of those three looks at whether the person approving the payment was deceived. The table below is the whole argument in one view.
Read down the last column and the pattern is clear: Positive Pay acts at presentment, fraud scoring acts on submission, and payee verification acts on the account details, but only intent verification acts on the decision to pay itself, before the money is released. That timing is the difference between a control that reports a fraud and a control that prevents one, because on wire and instant rails the payment is final in seconds.
| Control | What it checks | What it misses | When it fires |
|---|---|---|---|
| Positive Pay | Presented checks and ACH debits against a file of items you authorized | An authorized payment you originated to a changed but real-looking payee | At presentment, inside your bank |
| Payee (account-name) verification | Whether the account number belongs to the payee name you entered | Whether you were deceived into choosing that payee in the first place | Before you send, on the account details |
| Fraud scoring | Statistical risk signals: device, velocity, geography, and anomaly | An authorized payment that looks perfectly normal to the model | At or after submission, as a probability |
| Pre-settlement intent verification | Payer, payee, amount, and purpose, plus proof a human approved this payment | It does not remove the approver’s judgment; it makes the check unskippable | Before release, as a verdict you can check later |
What Positive Pay actually checks, and the fraud it cannot see
Positive Pay is a bank matching control, and it is very good at the job it was built for. You send your bank a file of the checks or ACH debits you authorized, with amounts and payees, and the bank holds or flags anything presented that does not match. Payee Positive Pay adds the payee name to the check match, and ACH Positive Pay screens debits against accounts and dollar limits you approve. It stops altered checks, forged items, and unauthorized debits, which are real and common problems.
What it cannot see is a payment you authorized. In vendor impersonation, business email compromise, or a CEO-wire scam, your own team originates the payment to an account that looks legitimate, so it matches the file you gave the bank, because you are the one who put it there. Positive Pay confirms the payment matches what you told the bank to expect; it cannot tell you that what you told the bank to expect is itself the product of a scam. With BEC losses at $3.046 billion in 2025, 86 percent of it on wire and ACH2, that blind spot is where most of the money is lost. If you want to see how a control checks the payee and the approval before release, you can see how the verification works.
Payee verification: what account-name matching proves and what it does not
Payee verification, also called account-name verification or confirmation of payee, checks that the bank account you are about to pay actually belongs to the name you entered. It is a genuinely useful control, and account validation is now an expectation for many originators under Nacha’s risk-management rules that took effect in June 20263. It catches typos, stale account details, and mismatches where the name and number do not line up. For paying the wrong account by mistake, it works.
What it does not prove is that the name itself is the party you should be paying. In a bank-change scam the fraudster gives you a real account that matches a plausible name, often the supplier’s name spelled correctly, or a lookalike entity set up for the purpose. The account-to-name check passes, because the account really does belong to that name. The deception is one layer up: you were convinced to pay that payee at all. Account-name verification answers does this account match this name; it does not answer should I be paying this name, which is the question a deceived approver gets wrong. That is why it narrows the gap without closing it.
Why fraud scoring misses authorized payments
Fraud scoring rates a transaction’s risk from patterns: the device and location it came from, how fast payments are moving, how the amount compares to history, and dozens of other signals. It is the backbone of card and account-takeover defense, where the fraudster is an intruder whose behavior looks abnormal. Against that kind of attack, a good model catches a large share of fraud before it clears, and it does so at a scale no manual review could match.
Authorized payment fraud defeats it for a simple reason: there is no anomaly. A real, authorized employee logs in from the usual device, on the usual network, and approves a payment that fits the company’s normal pattern, because the whole scam is engineered to look ordinary. The model sees a legitimate user doing a legitimate thing and scores it low, which is correct at the pattern level and wrong at the intent level. The tooling is also thinner than most people assume: the 2026 AFP survey found that only 17 percent of organizations use AI or machine learning to detect payments fraud1. Scoring is necessary for the anomaly-based attacks. It is structurally blind to the authorized ones.
Pre-settlement intent verification: checking the payee and the approval before the money moves
The gap all three leave open is the same one: none of them verifies, before release, that this specific payee and amount were intended and that a real, authorized person approved them. That is what pre-settlement intent verification does. It checks the payer, payee, amount, and purpose against the records you already trust, requires proof that an authorized approver signed off on this exact payment, and holds anything that does not match rather than letting it settle. On instant rails this timing is the whole point, because The Clearing House’s RTP network is credit-push and final once settled4, so a check that runs afterward has nothing left to stop.
This is where RankShield Financial fits, and it is worth being precise about what it is. It sits in the authorization path as a verification and attestation layer, not a wallet or a processor, and it never takes custody of your funds; your bank and rails still move the money. It verifies the payee and proves an authorized approval before release, and seals a signed, tamper-evident record of the decision. The difference from fraud scoring is the difference between a verdict you can check and a score you must trust: a fraud score is a private probability, while a RankShield verdict is independently verifiable, so an examiner, an insurer, or a partner can confirm it rather than take it on faith. That shared signal compounds as members join, rather than claiming a scale we have not yet reached, and the signing is quantum-safe by construction, not quantum-proof. For a head-to-head with a scoring-based incumbent, see RankShield versus Accertify, or read how pre-settlement verification works in detail.
How to decide which control you actually need
These controls are not rivals so much as answers to different questions, and most businesses need more than one. The way to choose is to name the risk you are actually carrying, then match it to the control built for it. The decision comes down to four cases.
Once you map your real exposure this way, the pattern most businesses find is that they already have three of the four and have left the last one open. Positive Pay comes from the bank, scoring often comes bundled with a payments platform, and account validation is increasingly required. The authorized-payment control, the one that verifies intent before release, is the piece that is usually missing, and it is the one the largest losses run through.
- If your risk is altered or forged checks and unauthorized debits, Positive Pay is the right control, because it matches every presented item against what you authorized.
- If your risk is paying the correct party at the wrong account, account-name verification helps, because it confirms the account belongs to the payee name you entered.
- If your risk is high-volume card or account-takeover fraud, fraud scoring earns its place, because it flags the statistical anomalies that intruders produce at scale.
- If your risk is an authorized payment to a deceived approver, which covers BEC, vendor impersonation, CEO-wire, and authorized push payment fraud, you need pre-settlement intent verification, because it is the only control that checks who is being paid and who approved it before the money is released.
