Biometrics, tokens and authentication: what evidence actually supports a banking transaction?

Abstract

The phrase “authenticated transaction” may refer to radically different architectures: password, OTP, physical or software token, local biometric unlock, push approval, certificate, cryptographic key or passkey. For forensic purposes, the decisive issue is understanding what the mechanism actually proves, how the credential was issued, bound and recovered, and which records demonstrate its use. This article reviews major contemporary authentication mechanisms using NIST guidance and WebAuthn Level 3, and discusses how authentication events can be transformed into technically defensible evidence.

Keywords: authentication; biometrics; token; MFA; WebAuthn; passkeys; banking fraud.

1. “Authenticated” is an incomplete conclusion

When a system reports that an operation was authenticated, the first question should be: by which mechanism, at what assurance level and in what context?

Authentication is the process by which a system verifies a claim through credentials or authenticators. NIST SP 800-63B-4 distinguishes authenticator types and assurance levels, acknowledging that methods offer different resistance to phishing, replay, credential theft and compromise.[1]

A password demonstrates knowledge of a secret. An OTP demonstrates temporary access to a delivery channel or generator. A private-key operation demonstrates control over the key. Biometrics may merely unlock that key locally. These are not equivalent pieces of evidence.

2. Three traditional factors — and the architecture behind them

Authentication factors are commonly grouped into:

• something the user knows;

• something the user possesses;

• something the user is.

Multiple factors can improve security, but practical assurance depends on independence between factors and on recovery procedures. A system may use strong MFA during normal login while allowing recovery through a weaker channel.

A forensic timeline should therefore include credential issuance, device enrollment, phone/e-mail change, account recovery, password/PIN reset, token activation, biometric enrollment and credential revocation.

3. Passwords and PINs: knowledge is not identity

A correct password is relevant evidence, but it does not explain how the password was obtained. Phishing, password reuse, malware, observation and sharing are distinct hypotheses. The examiner should look at failed attempts, origin, recent resets, recovery mechanisms and risk alerts instead of assuming any one explanation.

4. OTP, SMS and temporary tokens

One-time passwords reduce the usefulness of stolen static passwords, but their evidentiary value depends on protocol design.

An SMS OTP shows that the transmitted code was presented to the system; it does not necessarily establish who physically possessed the telephone. SIM-swap, social-engineering and remote-access scenarios require additional evidence.

App-generated tokens may be time-based, transaction-bound or device-bound. The examiner needs to know which.

5. Biometrics: probabilistic verification and local architecture

Biometric matching is probabilistic, and architecture matters. On many mobile platforms, the banking application does not receive a fingerprint or face image. The operating system performs verification in protected hardware/software and releases a key operation or success signal.

Thus “biometric authentication” may technically mean that the operating system’s local authentication policy was satisfied.

Relevant questions include modality, location of matching, template storage, fallback methods, re-enrollment events, liveness controls and which operation was released after success.

NIST’s 2025 identity guidelines include updated biometric and fraud considerations.[1][2]

6. Public keys, passkeys and WebAuthn

Public-key authentication changes the security model. Rather than transmitting a shared secret, an authenticator uses a private key to create a cryptographic proof that the relying party verifies.

WebAuthn Level 3, published as a W3C Recommendation in August 2026, defines scoped public-key credentials and authenticator signatures/attestation mechanisms.[3]

Forensic significance can be strong: the records may show that a specific credential participated in a protocol. But control of a credential is not automatically equivalent to the physical identity of the person who activated it. Unlock mechanisms, passkey synchronization, recovery and compromise remain relevant.

7. Push approval and authentication fatigue

Push-based approval improves usability but can be abused through repeated prompts. In a dispute, “push approved” should be contextualized:

• how many prompts were sent?

• how close together?

• did the prompt display transaction amount and beneficiary?

• did approval require biometric/PIN?

• was the device already trusted?

• had an account-recovery event occurred?

The semantics of the event matter as much as its status.

8. Session authentication and transaction authorization are different

A user may log in at one time and transact later under the same session. High-risk operations may or may not require step-up authentication.

A proper reconstruction should identify session start, session lifetime, reauthentication, context changes and the credential specifically used to authorize the payment.

Saying that a transfer “used biometrics” requires evidence that the biometric step was linked to that transfer rather than only to an earlier login.

9. Evidence worth preserving

A useful evidence package may include:

• credential identifiers without secrets;

• issuance and binding dates;

• device history;

• authentication and authorization logs;

• authentication method;

• cryptographic challenge/result where appropriate;

• recovery/reset events;

• notifications;

• synchronized timestamps;

• session IDs;

• app/OS versions;

• related fraud-control logs.

ISO/IEC 27037 and NIST SP 800-86 provide principles for preservation and structured forensic analysis.[4][5]

10. Expert questions that distinguish hypotheses

Instead of “does biometrics confirm the transaction?”, ask:

• which authenticator was used?

• did authentication occur at login or for the specific transaction?

• was the method phishing-resistant?

• was the credential recently issued or recovered?

• which device held the token/key?

• was a weaker fallback available?

• does the server retain cryptographic proof or only a derived success flag?

• is recovery security equivalent to normal authentication?

• do authentication, device, network, session and behavioral evidence converge?

11. Conclusion

MFA, biometrics, passkeys and cryptographic authentication can substantially strengthen security and generate richer evidence. No technology, however, removes the need for interpretation.

The correct question is not merely “did the system accept authentication?”. It is: which credential was accepted, at which stage, under which conditions, how was it issued or recovered, and how far does that event support human attribution?

For banking disputes, that distinction is central to technically defensible evidence.

11A. 2026 methodological update

Four propositions should be kept separate: identity proofing, possession/control of the authenticator, session authentication, and authorization of the specific transaction. Local biometric unlock is also different from remote biometric verification. In synchronized passkey environments, account recovery and enrollment of new devices may be as relevant as the terminal on which the event was observed.

References

1. NIST.

   SP 800-63B-4

   . 2025. https://csrc.nist.gov/pubs/sp/800/63/b/4/final

2. NIST.

   SP 800-63-4

   . 2025. https://csrc.nist.gov/pubs/sp/800/63/4/final

3. W3C.

   Web Authentication: An API for accessing Public Key Credentials — Level 3

   . 2026. https://www.w3.org/TR/webauthn/

4. ISO/IEC.

   ISO/IEC 27037:2012

   . https://www.iso.org/standard/44381.html

5. NIST.

   SP 800-86

   . https://doi.org/10.6028/NIST.SP.800-86

6. ISO/IEC. ISO/IEC 19795-1:2021 — Information technology — Biometric performance testing and reporting — Part 1: Principles and framework. https://www.iso.org/standard/73515.html

• ISO/IEC.

  ISO/IEC 27042:2015 — Guidelines for the analysis and interpretation of digital evidence

  . https://www.iso.org/standard/44406.html

• ISO/IEC. ISO/IEC 30107-3:2023 — Information technology — Biometric presentation attack detection — Part 3: Testing and reporting. https://www.iso.org/standard/79520.html

Editorial note: authentication is a property of a protocol and credential; human attribution requires contextual correlation with other evidence.