FI wants to know how *AI models* change the cyber risks banks face

The question FI is asking

Finansinspektionen, Sweden's financial supervisor, has sent a survey to banks, payment institutions and credit firms asking how they assess new cyber threats from AI models ^[1]. The survey is part of FI's supervision under DORA, the EU's Digital Operational Resilience Act, which has applied since January 2025 and sets detailed requirements for how financial companies protect their digital systems ^[2].

The survey does not say AI is unsafe. It asks how AI changes the risks. For example, a model trained on data that includes patterns from past attacks might behave in ways its operators don't fully understand, or an attacker might find a way to influence the model's output. Those are operational resilience questions, and they sit squarely within DORA's scope.

Why logs matter under DORA

DORA's technical standard on ICT risk management includes a short requirement that gets less attention than it deserves: logging procedures must protect log systems and log information against tampering, deletion and unauthorised access, and detect failures in the logging ^[3].

Think of it like a bank statement. You trust it because the bank keeps it, but if you and the bank disagree about a transaction, the statement is only as good as the systems that protect it. A log is the same. It tells you what happened during an incident or an audit, but if someone with the right access can quietly change it, the record becomes hard to trust.

That is the evidence question: how do you show a supervisor, an auditor or an insurer that a log hasn't changed, when you are the one keeping it?

Access control is the foundation, but it isn't the end

Access controls and monitoring are where it starts. You limit who can reach the logs, you monitor who does, and you keep those audit trails in a separate place. That works well when everyone follows the rules.

The harder case is when the person who could change a log is the same person who has legitimate reasons to access it: a system administrator during an incident, or an engineer fixing a fault. Access control stops outsiders. It doesn't stop someone with the right credentials, and it doesn't give you a way to prove to someone else that nothing was changed.

That is where the gap sits, and it is the gap FI's survey seems to be probing. When AI models are part of the operational stack, and something goes wrong, the question of what the system did and when it did it becomes harder to answer and harder to prove.

A digital witness for each log segment

A digital witness seals a fingerprint of each log segment as it closes, for example every few minutes. The fingerprint is a short string derived from the log's content: change one character in the log and the fingerprint no longer matches. The seal itself goes onto WitniumChain ^[4], where any later change would show, even one made by us.

When someone asks whether a log has changed, you calculate the fingerprint again and compare it with the sealed one. If they match, the log is unchanged. If they don't, something has been edited. The log itself never leaves your systems, and anyone you share it with can check it.

What it shows is that a particular log segment existed at a particular time, unchanged since it was sealed. What it doesn't show is that the log is complete, that the monitoring around it worked, or that the response to an incident was adequate. Those are separate questions. A digital witness gives you a checkable record of what you did log, so that when FI or an auditor asks, the answer is short rather than long.

How it would work

1. Each log segment is fingerprinted as it closes, and the fingerprint is sealed through the REST API, the SDK or the MCP server.
2. The seal is stored on WitniumChain, and you keep the witness ID with the log.
3. To check, anyone calculates the fingerprint of the log segment and compares it with the sealed one.

What this means for you

If you work for a bank, a payment firm or another financial company covered by DORA, here are three questions worth asking now:

• Can you show that your ICT logs haven't been edited, even by someone with administrator rights?
• If FI asks how you protect logs against tampering, as DORA's technical standard requires, what is your answer?
• When you assess cyber risks from AI models, do you include the question of how you prove what your systems did on a given day?

DORA is about resilience, and resilience means being able to show what happened when something goes wrong. Logs are the foundation of that, and a log you can prove hasn't changed is a stronger foundation than one you have to ask people to trust.

The content stays with you. The first 2,000 witnesses a month are free. Read the docs at witniumchain.com/docs ^[5].