Passwordless Banking: Passkeys, Fraud, and Signing Real Money

A friend of mine who works in fraud at a mid-sized bank once described his job to me as "professionally distrusting everyone, including the customer, especially the customer." He wasn't being cruel. He was describing the actual problem at the heart of modern banking security, which is that the bank can never quite be sure the person holding the credentials is the person who owns the money. For decades the answer to that uncertainty was to pile on more secrets: a password, then a PIN, then a card reader, then a code texted to your phone, then a security question about a pet you no longer remember. Each layer was supposed to make the bank surer. Each layer was, underneath, just another secret that could be stolen, relayed, or socially engineered out of a tired human at the worst possible moment. The whole edifice rested on the hope that the right person, and only the right person, knew the magic words.

Passkeys are interesting to banks for a reason that goes deeper than "passwords are annoying," and it took me a while to appreciate the depth of it. Banks aren't just trying to let the right people in. They're trying to prove, in a way that holds up against fraud, against chargebacks, and against a regulator, that a specific human approved a specific action. That's a fundamentally different and harder problem than logging in, and it's the one I find genuinely fascinating, because it's where cryptography stops being about access and starts being about consent.

Phishing-resistant SCA, or why texting you a code was always a stopgap

If you bank in Europe or the UK you've felt the regulatory weight of strong customer authentication, SCA, the rule that pushes banks to verify you using at least two independent factors from the classic three categories: something you know, something you have, something you are. The intent is good. The common implementation, a one-time code over SMS, has aged like milk. SMS codes get intercepted through SIM-swap fraud, where an attacker convinces your carrier to move your number to their device, and they get harvested wholesale by reverse-proxy phishing kits that sit between you and your real bank, relaying your password and your code in real time while quietly stealing the session. The code felt like security. It was really just a shared secret with a short shelf life, and short-lived secrets are still secrets, still typeable, still phishable.

This is where passkeys land hard for banks, because they satisfy SCA's two-factor requirement in a way that's phishing-resistant by construction rather than by warning label. A passkey is something you have, the private key bound to your device, unlocked by something you are or something you know, your fingerprint, face, or device PIN. Two factors, cleanly. But the part that makes a fraud team's eyes light up is that the cryptographic signature is bound to the bank's actual domain. The lookalike site that relays your SMS code in real time cannot get a passkey signature for the wrong origin, full stop. The single most scalable attack on banking logins, the real-time phishing proxy, stops producing usable credentials, because there's no reusable credential being produced. You can't relay a secret that was never sent.

Signing the payment, not just the login

Here's the idea that I think is genuinely underappreciated outside payments circles, and it's the one that separates passkeys-as-login from passkeys-as-banking-infrastructure. Logging in proves you got into the building. It says nothing about what you agreed to once inside. The expensive fraud, the kind that actually drains accounts, often happens after a perfectly legitimate-looking login: an attacker who's hijacked a session adds a new payee and sends themselves the money, and from the bank's logs the session looks authenticated and fine. Authenticating the login was never the hard part. Authenticating the transaction is.

WebAuthn, the standard passkeys are built on, has a quietly powerful feature for exactly this: the challenge the bank asks your device to sign can carry context, and the signed response is bound to it. So instead of just signing "this is the account owner," your device can sign "I, the account owner, approve sending 4,200 to account ending 9981, right now." This is transaction signing, and it's the difference between a guard checking your ID at the door and a notary watching you sign a specific cheque. The approval is cryptographically welded to the specific amount and the specific recipient. If anything about the transaction changes, the signature doesn't match, and the bank knows. An attacker who hijacked your session still can't move money, because moving money requires a fresh signature over those exact details, and that signature lives behind your fingerprint on your device, not in the session cookie they stole.

This also reshapes step-up authentication into something that finally makes sense. Step-up is when a system asks for stronger proof before a riskier action, and most of us have experienced its dumb version: you're already logged in, you go to do something sensitive, and it makes you type a password you already typed. With passkey-based transaction signing, the step-up isn't a redundant secret, it's a context-bound approval of the specific thing you're about to do. Add a new payee, sign it. Send a large payment, sign that exact payment. Change your contact details, sign that change. Each high-risk action gets its own cryptographic consent that can't be lifted and replayed against a different action, because the signature only validates for the details it was made over. The friction lands exactly where the risk is and nowhere else.

What this does to fraud and chargebacks

Follow the money and you'll see why banks and fintechs are moving regardless of whether their customers ever learn the word "passkey." Account takeover fraud feeds on stolen reusable credentials, so when there's no reusable credential to steal, that funnel narrows dramatically. Phishing, the industrial engine behind most takeovers, loses its payload because the thing it harvests is no longer reusable on the wrong domain. And transaction signing closes the post-login gap where so much real loss happens. You're not just stopping people from getting in, you're stopping them from authorising things once a session is somehow compromised.

Then there's the chargeback dimension, which is quietly enormous and which merchants feel acutely. A huge slice of payment disputes are friendly fraud and repudiation: a customer, honestly or not, claims they never authorised a transaction, and the merchant eats the cost plus a fee because proving the customer did authorise it has always been hard. A context-bound passkey signature over the exact transaction is about as strong a piece of evidence as you can produce that this specific person approved this specific payment. It doesn't make disputes vanish, people are creative, but it shifts the evidentiary ground under everyone's feet. "Prove I agreed to this" gets a cryptographic answer instead of a shrug and a log entry. For a payments business, turning ambiguous disputes into defensible records is the kind of thing that moves the actual profit-and-loss, not just the security slide.

The regulatory tailwind is blowing the same direction

None of this is happening in a vacuum, and the regulators are, for once, pushing the same way the cryptography wants to go. Strong customer authentication rules already demand multi-factor, phishing-resistant authentication for payments in major markets, and the guidance keeps tightening toward methods that resist real-time interception, which is precisely the property passkeys have and SMS codes lack. Standards bodies have been steadily downgrading SMS as an authentication factor for years. Government identity programmes increasingly specify phishing-resistant authentication outright. The direction of travel is unambiguous: away from shared secrets, toward device-bound cryptographic proof. Banks that adopt passkeys aren't gambling on a fashion, they're skating to where the rulebook is already moving, which is the rare situation where the compliant thing and the secure thing and the less-annoying thing are all the same thing.

I'll be honest about the parts that are still hard, because I build in this space and the unglamorous bits are where projects die. Account recovery is the soft underbelly, lose your device and the recovery flow becomes the new attack surface, so it has to be designed with the same rigour as the front door rather than bolted on as an afterthought. Cross-device and cross-platform passkey syncing has matured a lot but still has rough edges. And banks have years of legacy authentication plumbing that doesn't rip out overnight. We work on this every day at Paswad and I won't pretend the migration is a weekend job. But the core proposition is sound and, for once, simple to state: stop asking customers to prove they know a secret, and start letting them cryptographically sign the specific thing they actually intend to do. For money, where the whole game is proving a particular person approved a particular action, that's not an upgrade. It's the thing we should have been doing all along.

FAQ

Why are banks and fintechs moving to passkeys?

Because passkeys give them phishing-resistant strong customer authentication by design. They satisfy multi-factor rules cleanly, the private key never leaves the customer's device, and signatures are bound to the bank's real domain, so the real-time reverse-proxy phishing kits that defeat SMS and app codes simply can't produce a usable credential. For a fraud team, that closes off the single most scalable attack on account logins.

What is transaction signing and how is it different from logging in?

Logging in proves you got into your account; transaction signing proves you approved a specific action. With WebAuthn, the challenge your device signs can include details like the amount and recipient, so your approval is cryptographically bound to "send this amount to this account," not just "let me in." An attacker who hijacks an authenticated session still can't move money, because moving money needs a fresh signature over those exact details, locked behind your device's biometrics.

How do passkeys reduce fraud and chargebacks?

They cut account takeover by removing the reusable stolen credential that takeover relies on, and they close the post-login gap where attackers authorise payments from hijacked sessions. On chargebacks, a context-bound signature over the exact transaction is strong evidence that a specific person approved a specific payment, which shifts repudiation and friendly-fraud disputes from a shrug-and-a-log-entry toward a defensible cryptographic record.

Does regulation actually favour passkeys over SMS codes?

Yes. Strong customer authentication rules in major markets already require multi-factor, phishing-resistant authentication for payments, and guidance keeps tightening toward methods that resist real-time interception. Standards bodies have been downgrading SMS as a factor for years, and identity programmes increasingly specify phishing-resistant authentication outright. Passkeys line up with where the rulebook is already heading.