Every platform keeps logs.
Login time. Session ID. IP address. Device fingerprint. Action type. Timestamps. OTP issued. OTP acknowledged. Risk score produced. Transaction completed.
These records are operationally useful. They are reconstructable, searchable, and correlatable.
They are not proof.
What Proof Actually Requires
Proof, in any setting that might end in dispute, has three properties.
- •Independent authorship. The artifact is produced by a party other than the one now asserting its meaning.
- •Tamper evidence. Modification after the fact is detectable without trusting the party holding the record.
- •Specific binding. The artifact refers to a particular action, actor, and moment — not a class of actions that might have produced it.
A session log fails all three.
The bank wrote it. The bank holds it. The bank can regenerate it. A customer who claims the transaction was not theirs cannot be confidently overruled by a record the bank produced about the bank’s own systems.
Why OTP Acknowledgments Fail
An OTP acknowledgment looks like evidence. It is not.
The OTP is a shared secret at the moment of use. The bank generated it. The bank transmitted it. The bank received back a copy of it.
Nothing about the acknowledgment is uniquely attributable to the customer.
The customer may have entered the code. The bank’s own system may have recorded it for them as part of a support flow. A scammer on the phone may have been told it. An insider at the bank may have logged it. All of these produce the same acknowledgment record.
An acknowledgment that could have been produced by several parties is not evidence that any one of them produced it.
Why Risk Scores Fail Immediately
A risk score is the bank’s own opinion about the likelihood of fraud on a given transaction.
It is a defensible operational tool. It is the exact opposite of proof of customer authorization.
A transaction with a low risk score was simply one the bank chose to let through. In dispute, the fact that the bank chose to let it through is not evidence that the customer authorized it. It is evidence that the bank assessed the probability and bet on the customer.
This is a useful bet to place. It is not a proof.
What Does Satisfy Proof
An artifact that satisfies the three properties above has a specific structure.
It is produced on the customer’s own device, by a private key held in secure hardware the customer alone controls, over a canonical description of the specific action — amount, payee, timestamp, monotonic counter.
Producing the signature requires a fresh biometric gesture on the device.
The signature verifies against a public key held on record by the bank, the regulator, or a court. Verification is deterministic. It does not require access to the customer, to the bank’s systems, or to the device.
Independent authorship: the key lives outside the bank.
Tamper evidence: the signature stops verifying if anything changes.
Specific binding: the canonical action is inside the signed payload.
All three properties, in a single artifact.
Why This Matters Now
Regulators are beginning to distinguish operational records from admissible evidence.
Issuers facing mandatory reimbursement (UK PSR, 2024) and fraud model degradation from agentic systems need evidence that is cryptographic, device-bound, and action-specific. See APP Scam Fraud.
PSD2 Article 97 requires non-repudiation as a distinct property from authentication. See PSD2 Article 97.
A bank that can produce session logs, OTP acknowledgments, and risk scores — but cannot produce a signed, device-bound artifact — is now exposed to liability that did not exist five years ago.
Not because the logs stopped working.
Because the logs never were proof.
Closing
A log is the platform’s account of what it observed.
Proof is an artifact that does not depend on the platform’s account.
Every regulated system will eventually need the second thing.
Most still have only the first.