Witnium logo
WITNIUM. Chain.
← News

Cases · 2026-10-12 · 6 min read

When a screenshot is the evidence: what courts expect from digital records

Canada's highest court has ruled on liability for fraudulent electronic transfers, whilst judges face deepfake evidence that requires stricter authentication. One U.S. case was dismissed because of AI-generated records. All three point to a harder question for organisations: can you show what your system actually did?

EliasBy Elias

Share
Abstract illustration showing examination of digital evidence
Illustration: AI-generated

The bank pays, unless it can prove otherwise

In January 2025, the Supreme Court of Canada decided B.M.P. Global Distribution v Bank of Nova Scotia [1]. An employee at B.M.P. fell for a phishing email, entered their credentials, and authorised fraudulent wire transfers totalling over $1.1 million. The question was who should bear the loss: the bank or the customer.

The court ruled 5–2 that the bank whose system was compromised bears the loss, unless it can show fraud or negligence on the customer's part. The majority said the legal risk of an unauthorised electronic payment sits with the bank, because the bank controls the security of its own system. The customer had followed the bank's instructions. The transfers looked legitimate in the bank's interface. That was enough.

The dissenting judges argued that the customer should have spotted red flags and that the bank had met the industry standard for security. They lost. The majority held that meeting an industry standard doesn't shift the risk back to the customer, and that the bank is better placed to guard against phishing and to absorb the loss.

For anyone running payment systems, insurance claims or account access, the decision is a reminder that courts look at whose system was breached and who could best prevent it. It's a bit like leaving your bike unlocked: the thief is guilty, but you still lose the bike. Here, though, it's the bank that left the lock open, not the customer.

When evidence gets questioned

Whilst Canadian judges ruled on liability, courts elsewhere are tightening the rules on evidence itself. In the U.S., a lawyer submitted a brief with case citations generated by ChatGPT [2]. The citations looked real but the cases didn't exist. The judge imposed sanctions and dismissed the motion, noting that generative AI can produce plausible but entirely fictional legal authority.

At the same time, judges are increasingly seeing deepfake video and audio in disputes. In family law, employment cases and even fraud claims, parties turn up with recordings that the other side says have been manipulated. Courts in several jurisdictions now require stronger authentication before admitting such evidence, and some have begun asking for metadata, forensic analysis or independent corroboration.

None of this is new in principle. Courts have always weighed reliability. What's changed is that making a convincing fake document, video or screenshot is now easier than checking whether it's genuine.

Under Swedish law, a court applies free evaluation of evidence [3]. Anything can be presented, but its weight depends on how trustworthy it is. A screenshot from a customer might be convincing if the organisation offers nothing to contradict it. A sealed record of what the system actually said levels the field.

The evidence question in practice

Say a customer contacts your chatbot, gets an answer about a refund policy, takes a screenshot and later claims the answer was different from your terms. The customer has a dated image. What do you have?

If your logs can be edited by anyone with administrator access, an auditor, an ombudsman or a judge may treat them as less reliable than the customer's screenshot. Access controls and monitoring are necessary, but they don't answer the question a neutral observer will ask: how do I know this log is the one written on the day, and not a version edited later?

That's where the neutral witness fits. It doesn't take sides and it doesn't forget.

A sealed record of what the AI said

Here, the thing to seal is each answer as the chatbot sends it: the question, the answer, the model version and the timestamp. Sealing takes a fingerprint of the record, not the record itself, so the conversation stays in your systems. The fingerprint is posted to WitniumChain, which returns a witness ID.

When the answer is questioned months later, anyone you share the record with can check it. They calculate the fingerprint again and compare it with the sealed one. If it matches, the record hasn't changed. Change a single character and it won't match.

Who can check? Customer service, the customer, an ombudsman or a court. The check is public and doesn't require access to your systems.

What it shows: that the record of what the chatbot said, and when, is exactly what was written at that time.

What it doesn't show: it doesn't prove the answer was correct, or that your organisation is bound by it. Those are separate legal questions. What it does is give both sides the same starting point, so the dispute can be about what the answer meant rather than whether anyone changed the log.

The transparency requirement in Article 50 of the AI Act already says people must as a rule be told when they're interacting with an AI [4]. Sealing the conversation doesn't replace that duty. It sits alongside it, so you can show what the AI said to the person who was told they were talking to an AI.

How it would work

  1. The chatbot sends an answer. Your system calls the WitniumChain API with a fingerprint of the answer and gets a witness ID back.
  2. Months later, the customer disputes the answer. You retrieve the original record and calculate its fingerprint again.
  3. Anyone can check the witness ID on WitniumChain. If the fingerprints match, nothing has changed since the answer was sent.

You can do the same with versions of documents, policy updates or approval records. Seal each version when it's sent, and you can show which version existed when.

The content stays with you. The fingerprint is public. The check doesn't depend on trusting whoever keeps the log. You can start with the REST API, the SDK or the MCP server, and the first 2,000 witnesses a month are free. Documentation is at witniumchain.com/docs.

What this means for you

If you run customer-facing AI, ask these questions this week:

  • Could we show a court or an ombudsman exactly what our chatbot said to a specific customer on a specific day?
  • Who keeps the log, and who could edit it?
  • If a customer turned up with a screenshot, would our record carry more weight or less?
  • When we say a system made a decision, can we prove it, or do we just have our word for it?

The Canadian Supreme Court ruling shows that liability follows control. If it's your system, it's your risk. The U.S. case on fabricated citations and the tightening rules on deepfakes show that courts are getting better at questioning digital evidence.

The best defence is a record nobody can quietly rewrite, not even you. That's what a digital witness gives you: evidence that holds up because it doesn't ask anyone to trust you.

What to watch

The Product Liability Directive treats software as a product for anything placed on the market after 9 December 2026 [5]. If a court asks which version of your software was running on a given day, a sealed release history shortens that conversation.

For high-risk AI systems under Annex III of the AI Act, the logging requirement in Article 12 applies from 2 December 2027 [6]. The Act says what to log. It doesn't say how to protect the logs, but their evidential value when something's questioned is a reason to seal them as they're written.

If you work in finance, DORA's technical standard on ICT risk already requires logs to be protected against tampering, deletion and unauthorised access [7]. Sealing log segments at short intervals answers the question of how you show they haven't been tampered with, even by someone with the right access.

Sources

  1. [1]B.M.P. Global Distribution Inc. v. Bank of Nova Scotia, 2025 SCC 1, Supreme Court of Canada, 2025-01-24
  2. [2]Mata v. Avianca, Inc., 22-cv-1461 (PKC), United States District Court, S.D. New York, 2023-06-22
  3. [3]Rättegångsbalken 35 kap. 1 §, Riksdagen, 1942-01-01
  4. [4]Article 50 of Regulation (EU) 2024/1689 (AI Act), European Commission AI Act Service Desk, 2024-07-12
  5. [5]Directive (EU) 2024/2853 on liability for defective products, EUR-Lex, 2024-10-23
  6. [6]Article 12 of Regulation (EU) 2024/1689 (AI Act), European Commission AI Act Service Desk, 2024-07-12
  7. [7]Commission Delegated Regulation (EU) 2024/1774, Article 12(2)(d), EUR-Lex, 2024-01-17
Pass it on

Know someone who should read this?

Share it with a colleague, your compliance team or your network.

Email

Sealed with WitniumChain

Seal pending. This article will be sealed shortly, and the seal details will appear here.

Written with AI assistance and reviewed by Elias.

Related