Digital banking fraud: what must be technically demonstrated in an expert examination?

Abstract

Disputes involving digital banking fraud are often framed as a binary conflict: the institution states that the transaction was authenticated; the customer claims not to have performed it. Technically, however, authentication of a session or validation of an authentication factor does not automatically amount to unequivocal identification of the person who performed the act. A robust forensic examination must reconstruct the event as a chain: enrolled identity, device, authentication context, session, transaction, anti-fraud controls, network records, security events and evidence preservation. This article proposes a technical model for that analysis, discusses the evidentiary limits of data such as IP addresses, biometrics and tokens, and explains why the strength of the evidence depends as much on collection and correlation methods as on the existence of records.

Keywords: banking fraud; authentication; instant payments; logs; digital forensics; digital evidence; technical assistance.

1. The mistake of starting with the conclusion

In a digital banking dispute, the technically useful question is rarely just “was the transaction authenticated?”. A positive answer may mean very different things: the correct password was entered; an OTP or token was accepted; a previously authenticated session remained valid; an already enrolled device issued a request; local biometrics unlocked a cryptographic key; or an account-recovery flow granted new access.

These events have different evidentiary weight. NIST’s Digital Identity Guidelines separate identity proofing, authentication, authenticators, credential management and assurance levels. That separation matters because a system may correctly record that an authenticator was accepted without, by that fact alone, proving who was physically operating the device at the relevant time.[1][2]

The forensic analysis should therefore avoid circular reasoning: “the operation was authenticated, therefore it was performed by the account holder.” The questions are instead which mechanism was used, how it was bound to the account, what threats it resists, what events preceded the transaction, and whether the technical trail is consistent with the competing factual hypotheses.

2. Treat the transaction as a sequence of events

A useful reconstruction can be organized into seven layers:

1. Identity and enrollment:

   how the account was created and which identity attributes were validated;

2. Device:

   which device, application version and identifiers participated in the session;

3. Authentication:

   which factors were required and accepted;

4. Session:

   when it began, how long it remained valid and what changed during it;

5. Transaction:

   amount, beneficiary, channel, time, internal identifiers and confirmation;

6. Risk controls:

   alerts, fraud score, behavioral changes, new beneficiary, limits and blocks;

7. Post-event response:

   dispute, notifications, blocking, refund mechanisms and preservation of records.

Modern instant-payment and mobile-banking systems commonly combine authenticated sessions, authenticator lifecycle controls, device binding, risk analysis and step-up authorization. International digital-identity guidance distinguishes assurance levels and authenticator-management requirements that are directly relevant to forensic reconstruction.[3][4] These controls provide context, but they do not replace a technical reconstruction of the disputed event.

3. Which records normally matter

The relevant data depend on the architecture and dispute, but a mature investigation may examine:

• unique transaction identifier;

• timestamps, time zone and precision;

• login and authentication logs;

• device enrollment or replacement events;

• password, PIN or credential resets;

• token activation or migration;

• biometric or local-unlock events where applicable;

• application and operating-system versions;

• IP address, source port when available, and network information;

• session identifiers;

• limit changes;

• new-beneficiary registration;

• fraud/risk alerts;

• push, SMS or e-mail notifications;

• account-recovery records;

• backend audit trails;

• support and dispute records;

• evidence export and preservation metadata.

The central issue is not the volume of records, but their temporal and logical correlation. An IP address by itself is far less informative than IP + source port + precise timestamp + session + device + authentication event + transaction identifier.

4. Authentication is not the same as authorship

Authentication establishes that a mechanism was accepted according to the system’s rules. Human authorship requires an additional inference.

NIST SP 800-63B-4, published in 2025, addresses authenticators, assurance levels and resistance to contemporary threats. Current approaches increasingly include cryptographic credentials and phishing-resistant authentication.[2] In 2026, W3C published WebAuthn Level 3, defining public-key credentials scoped to a relying party and cryptographic proofs produced by authenticators.[5]

This can substantially improve security and the quality of technical records, but interpretation still matters. A signature produced by a device-bound credential demonstrates that the credential participated in the protocol; attribution to a human depends on possession, unlocking, compromise, coercion, social engineering and account-management context.

The forensic examiner should therefore separate two questions:

• did the system correctly authenticate a credential?

• does the available evidence support attribution of the act to the person at issue, and to what extent?

5. Biometrics: strong evidence, not magic

Biometrics are sometimes treated as equivalent to absolute identity. Technically, they are not.

Biometric systems use probabilistic comparison and are evaluated through false-acceptance, false-rejection and related performance measures. Architecture also matters. On many smartphones, a banking application does not receive a fingerprint or face image. The operating system performs local verification in a protected environment and may only release a cryptographic operation or a success signal to the app.

Relevant forensic questions include:

• which biometric modality was used?

• did matching occur locally or on a server?

• where was the biometric template stored?

• did the application receive biometric data or only an authentication result?

• was a PIN/password fallback available?

• was biometric or device enrollment changed near the event?

• was liveness or presentation-attack detection relevant?

NIST’s 2025 digital identity revision incorporated updated requirements and considerations for biometric technologies and fraud.[1][2]

6. IP and location: contextual evidence, not civil identity

Another recurring error is to state that an IP address “proves” who performed an operation. In NAT and Carrier-Grade NAT environments, many subscribers may share one public IPv4 address. IETF RFCs explain that attribution may require source port and precise timestamp, correlated with service-provider records, in addition to the public IP address.[6][7]

Even a correct attribution to a subscriber identifies a network-access relationship, not necessarily the person operating the device. Shared Wi-Fi, corporate networks, VPNs, compromised endpoints and other scenarios matter.

Location data must likewise be interpreted according to source. GNSS/GPS, cellular positioning, Wi-Fi positioning and IP geolocation have different accuracy and reliability properties.

A responsible conclusion states what the data support, rather than turning the data into proof of something they do not measure.

7. Fraud controls and transaction behavior

Modern anti-fraud systems combine multiple signals: known device, time, geography, transaction velocity, new beneficiary, limit changes, device reputation, session behavior and other attributes.

In a dispute, relevant questions include:

• which signals were available at the time?

• which controls were triggered?

• what risk score or category was generated?

• which rule allowed or blocked the operation?

• was there a significant behavioral deviation?

• were model thresholds documented?

• were automated decisions auditable?

A “low-risk” classification is an operational control result; it is not equivalent to proof that the account holder personally initiated the transaction.

8. Integrity and chain of custody

A technically rich trail can lose evidentiary value if its provenance and integrity are not demonstrated.

ISO/IEC 27037 provides guidance on identification, collection, acquisition and preservation of digital evidence.[8] NIST SP 800-86 structures forensic work into collection, examination, analysis and reporting.[9] ISO/IEC 27042 further emphasizes documented analysis and interpretation so that validity, reproducibility and repeatability can be assessed.[10]

Where possible, an examination should establish:

• source system;

• extraction procedure;

• person responsible for extraction;

• filters used;

• original and delivered formats;

• hashes or other integrity controls;

• acquisition date/time;

• transformations or normalization;

• retention of original records;

• reproducibility of results.

Screenshots may be useful representations, but they rarely preserve all metadata needed for deeper forensic analysis.

9. Framing the forensic questions

A technically sound expert examination should not merely ask “was there fraud?”. That combines legal characterization, intent and technical analysis.

More useful questions include:

• which authentication mechanisms were used for the disputed transaction?

• which credential or device changes occurred beforehand?

• which records identify the session and device?

• are timestamps across sources consistent?

• was a new beneficiary added or a limit changed?

• which risk signals were recorded?

• can the data correlate session, authentication and transaction?

• how were the logs preserved and extracted?

• which conclusions are technically supported and which remain indeterminate?

Such questions allow the report to expose premises, method, results and limitations.

10. Conclusion

Digital banking fraud cannot be reliably analyzed through a single indicator. A correct password, successful biometric check, valid token, familiar IP address or previously enrolled device are pieces of a reconstruction, not self-sufficient conclusions.

The evidentiary strength emerges from correlation among independent sources, temporal consistency, understanding of authentication architecture and forensic treatment of records. For legal teams, that means technical work ideally begins before the final expert report: when defining the object of proof, preserving necessary records and formulating questions capable of distinguishing competing explanations.

In digital disputes, the decisive question is often not “is there a log?” but: what exactly does the log measure, how was it generated, what other records corroborate it, and how far can its interpretation responsibly go?

10A. 2026 methodological update

Forensic reconstruction should distinguish device registration, session authentication and transaction authorization. The chronology of authenticator enrollment, device binding, recovery and re-binding is particularly relevant when a new or changed device appears close to the disputed event. Preservation must also extend to the analytical process: ISO/IEC 27042:2015 emphasizes validity, reproducibility, repeatability and sufficient recording for independent scrutiny.

References

1. NIST.

   SP 800-63-4: Digital Identity Guidelines

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

2. NIST.

   SP 800-63B-4: Digital Identity Guidelines: Authentication and Authenticator Management

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

3. NIST. SP 800-63-4: Digital Identity Guidelines. 2025. https://csrc.nist.gov/pubs/sp/800/63/4/final

4. NIST. SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management. 2025. https://csrc.nist.gov/pubs/sp/800/63/b/4/final

5. W3C.

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

   . Recommendation, 25 Aug. 2026. https://www.w3.org/TR/webauthn/

6. IETF.

   RFC 6888: Common Requirements for Carrier-Grade NATs

   . https://www.rfc-editor.org/rfc/rfc6888

7. IETF.

   RFC 6302: Logging Recommendations for Internet-Facing Servers

   . https://www.rfc-editor.org/rfc/rfc6302

8. ISO/IEC.

   ISO/IEC 27037:2012

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

9. NIST.

   SP 800-86

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

10. 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 27043:2015 — Incident investigation principles and processes. https://www.iso.org/standard/44407.html

Editorial note: technical and informational content. Application to a specific dispute requires examination of the actual system architecture, original records and formally defined expert scope.