In the corridors of every Product and Fraud department, it’s well-known that passwords and SMS OTPs are not enough in isolation to prevent fraud.

Even together, layering a weak solution over a broken one doesn't create security; it creates friction.

The core issue is that both can be stolen, shared, or intercepted.

The Phishing Trap: Consider the lifecycle of a standard phishing attack: A fraudster buys a list of stolen credentials - or even just emails - these are easily available online. They send a phishing email (e.g. “your package is waiting for customs clearance”) with a fake payment link.

The victim clicks the link, selects their bank, and begins what they believe is a normal payment process. They will be asked to write their username and / or password - the fraudster sees these. To spoof the possession factor, the victim will also be asked to type in a SMS OTP. They receive it, and type it into the fake website - again, the fraudster sees this.

Behind the scenes, the fraudster uses the details entered by the victim to initiate a real account recovery flow on the bank’s website. When the bank asks for the SMS OTP code, the fraudster uses the one that the victim has entered into the fake payment website to break into the person’s account.

Man-in-the-Middle (MITM) Attacks: MITM attacks are even more insidious. Attackers position themselves digitally between your device and the server. They intercept the communication traffic, allowing them to capture the OTP in transit before it ever reaches the intended destination.

We don’t need to labor the point on passwords—we all know the dangers of reuse, credential stuffing, and weak complexity. If the industry consensus is that these methods are failing, where do we go next?

If "something you know" and "something you possess" are compromised, we must turn to "something you are"—inherence. This leads us to biometrics. However, not all biometrics are created equal.

The Necessity of Facial Matching When building a true chain of trust, the biometric used for authentication must be linked to the verifiable identity created at the start customer journey. Almost every regulatory Identity Verification (KYC) check involves scanning a government-issued photo ID and matching it to a selfie.

Therefore, the only logical authentication method for high-security actions is the face.

If a bank relies on a fingerprint for authorizing a large transfer, they break the chain of identity. That fingerprint cannot be cross-referenced against the passport photo stored on file. The bank knows someone is touching the sensor, but they cannot scientifically prove it is the same person who passed the initial background check. Facial biometrics are the only modality that maintains a continuous, unbreakable link to the verified identity.

It is easy to assume that using FaceID or TouchID solves this problem, but relying on device-based (local) biometrics introduces a new set of risks.

Local Biometrics are Tied to the Device, Not the Identity. Local biometrics, like those provided by Apple or Google, are essentially convenience wrappers for a PIN. You cannot set them up without a passcode, and if the biometric fails, the device defaults back to that passcode. This means the security is only ever as strong as a 4 or 6-digit number.

The "Family Fraud" Loophole: Crucially, local biometrics do not communicate with the bank’s servers. The bank never sees the biometric data; they only receive a "yes" or "no" signal from the phone. This creates a blind spot. The bank knows the device was unlocked by a registered face, but not necessarily the customer's face.

This architecture enables "friendly fraud." A child who knows their parent's passcode can add their own face to the device settings. Later, they can approve payments using their own face. To the banking app, this looks like a legitimate FaceID check. The bank has no way to distinguish between the account holder and the unauthorized user because the local data cannot be compared to the original KYC photo.

To fix this, we must move from local authentication to Server-Side Biometrics.

Unlike device-based methods, server-side systems do not rely on the phone’s internal storage. Instead, when a user logs in, a fresh biometric scan is encrypted and sent to a secure server. Here, it is compared directly against the biometric template created during the initial KYC onboarding.

This approach closes the loop. It ensures that the person holding the phone is the exact same individual who owns the account. It looks and feels just like the FaceID experience users love, but with genuine identity assurance powering the backend.

But not all server-side biometrics are created equal. To read more, check out our dedicated blog that discusses the pros and cons of different server-side systems.

Interested in learning more? Contact us today to discover how Keyless can help your business overcome the challenges of account recovery or request a demo.