Finansinspektionen will ask banks to prove their *AI cyber defences*

When the supervisor asks, have you got the receipts?

Finansinspektionen, Sweden's financial supervisory authority, has said it will carry out an in-depth analysis in 2026 of how financial firms protect themselves against cyber threats from advanced AI models ^[1]. The timing is not a coincidence. AI tools are getting better at spotting weaknesses, and the firms FI supervises are obvious targets: banks, payment institutions, insurers and investment firms.

The review will look at whether firms have adequate safeguards and whether they can demonstrate that those safeguards work, especially when it comes to logging AI-related security incidents. That second part—whether you can demonstrate it—is where a lot of firms will find the question harder than it sounds.

Think of it like this: if your phone gets stolen and you call the bank to block your card, the bank checks its systems and tells you when the card was last used. You trust that answer because you trust the bank, but if you didn't, you would want to see the log. And if the log could be edited by the same people keeping it, you would want some other way of knowing it had not been touched. Financial supervision works the same way. The supervisor wants to see the logs, and the logs need to be trustworthy.

What DORA already requires

The Digital Operational Resilience Act (DORA) has applied across the EU since 17 January 2025 ^[2]. It sets out rules for how financial firms manage ICT risk, and one of its technical standards deals specifically with logging.

Article 12(2)(d) of the delegated regulation under DORA says logs must be protected against tampering, deletion and unauthorised access ^[3]. The standard also requires detection of failures in the logging process itself. That is a short sentence with a long tail: it means access controls, monitoring, and some way of showing a supervisor or an auditor that nobody has quietly rewritten the record after the event.

For firms preparing for FI's review, the question is not just whether the logs exist. It is whether you can prove they have not changed.

The AI angle

AI changes the threat in two ways. First, attackers are using AI to find vulnerabilities faster and to automate attacks at scale. Second, firms are using AI themselves, and those systems create new logs that need protecting: which model version ran, what data it used, what decisions it made.

When FI asks how a firm defends against AI-driven threats, part of the answer will be about prevention—firewalls, access controls, monitoring. But another part will be about evidence: when an incident happens, can the firm show exactly what occurred, and when, in a way that would stand up to scrutiny?

That is where logs come in, and where the protection of those logs becomes a trust question.

The hard part: proving nothing has changed

Access controls and monitoring are the foundation. They stop unauthorised changes and record who did what. But they do not, on their own, answer the question a supervisor might ask: how do I know this log is the one written on the day, and not one edited yesterday by someone with the right access?

The problem is circular. The people keeping the logs are often the same people who could change them. Internal audit can check the controls, but the question remains: if something was changed, would it show?

How a digital witness fits here

This is a strong fit for a digital witness.

What gets sealed is each log segment as it closes—say, every few minutes—covering detection events, access attempts, system changes and AI activity. The segment itself stays in your systems. What gets sealed is a fingerprint: a short, unique value calculated from the segment's content.

That fingerprint is recorded on a chain where any later change would show, even one made by us. When FI or an auditor asks to see the logs, you hand over the segments and the sealed fingerprints. They calculate the fingerprint again from the segment. If it matches, nothing has changed since sealing. Change a single character in the log and it will not match.

Internal audit, supervisors and incident responders can all run the same check, independently.

What it does not do: it does not replace access control, monitoring or backups, and it does not show that the logs are complete or that the response to an incident was adequate. What it does is give you a way of proving that what you are showing is what was written at the time, without asking anyone to trust the person keeping it.

How it would work

1. Your logging system sends a fingerprint of each closed segment to WitniumChain through the REST API, the SDK or the MCP server, and gets a witness ID back.
2. The segment and its witness ID are stored together in your systems.
3. When questioned, you share the segment and the witness ID. Anyone can calculate the fingerprint again and check it matches the sealed one. Read the docs.

The first 2,000 witnesses a month are free.

What this means for you

If you work at a firm FI supervises, here are three questions worth asking now:

• Can we show a supervisor exactly what our systems logged during an incident, in a way they can independently verify has not changed?
• Do our logging controls detect changes made by someone with legitimate access, or do they only stop unauthorised access?
• If an AI system we use makes a decision that gets questioned later, can we prove which version of the model ran, what data it used and what it output?

FI's review will happen in 2026. The logging requirements under DORA are already in force. The gap between having logs and being able to prove they are unchanged is smaller than it looks, but it is the gap a supervisor will ask about.

What to watch

FI has not yet published the exact scope or timing of its 2026 review. Watch for further announcements on its website in early 2026 ^[1].

DORA's incident reporting deadlines are already running: early warning within 24 hours of becoming aware of a significant incident, incident notification within 72 hours, and a final report within one month ^[2]. The clock starts when you know, not when it suits you, so the question of when you knew becomes a question about your logs.