SEB's capital requirement raised by 10 billion kronor after credit risk model flaws

When the numbers don't add up

A bank's capital requirement is a bit like the emergency fund you keep in case the washing machine breaks: the riskier your loans, the more you have to set aside. Banks with advanced internal models calculate their own risk, but they have to show the supervisor that the maths is sound.

SEB's models didn't pass that test. FI found deficiencies in how the bank measures credit risk, and the result is a temporary capital add-on of roughly 10 billion kronor ^[1]. That's not a fine. It's FI saying: your models understate the risk, so hold more capital until you fix them.

The shortcomings relate to SEB's internal rating-based approach for credit risk, which the bank uses to calculate how much capital it needs to hold against potential loan losses ^[1]. Banks that use these models are allowed to rely on their own risk assessments, but in return they must document every assumption and be ready to defend them to the regulator.

What went wrong

FI has not published the full details of what it found, but the general pattern is familiar. Internal models rest on historical data, assumptions about borrower behaviour and judgements about what counts as default. When those inputs are incomplete, outdated or inconsistently applied, the model's output—the risk-weighted assets—becomes unreliable.

For a supervisor, that's a problem. If a bank's models say the risk is lower than it actually is, the bank holds too little capital, and the system becomes less stable. The capital add-on is FI's way of closing that gap while the bank sorts out the models ^[1].

DORA and the logs underneath

Since 17 January 2025, banks and other financial firms in the EU have had to follow DORA, the Digital Operational Resilience Act ^[2]. One of its technical standards, on ICT risk management, requires logs to be protected against tampering, deletion and unauthorised access ^[3].

That matters here because a bank's internal models rely on data: loan performance, defaults, recoveries. That data gets logged, aggregated and fed into the model. If the logs can be quietly edited—by someone with administrator rights, say, or during an incident—then the model's foundation is shakeable.

The rule doesn't specify how to protect the logs, only that they must be protected ^[3]. Access controls and monitoring are the starting point. A digital witness goes further: it seals a fingerprint of each log segment as it's written, so a change shows up even when it's made by someone who is supposed to have access.

How a digital witness fits here

The thing to seal is each log segment or batch of model inputs as they are written: loan identifiers, rating parameters, default flags, recovery amounts. Sealing happens continuously, every few minutes, through the REST API, the SDK or the MCP server. The data itself never leaves the bank's systems; only a fingerprint does.

Anyone the bank shares the log with—an internal auditor, FI or a notified body—can later check that the log segment is exactly what was written at that time. Change a single character in the log and the fingerprint won't match.

What it doesn't do: it doesn't make the model accurate, it doesn't validate the risk-weighted assets, and it doesn't replace the bank's data governance. It answers one narrow question: has this log been altered since it was sealed? That's useful when a supervisor asks to see the data behind a model's calculations.

Getting started is straightforward. WitniumChain seals the fingerprint on a chain where any later change would show, even one made by us. The first 2,000 witnesses a month are free. Read the docs or get in touch for a demo.

How it would work

1. Seal log segments or batches of model inputs every few minutes as part of the bank's logging pipeline.
2. Store the witness ID with each sealed segment.
3. When an auditor or supervisor asks for the data, recalculate the fingerprint and check it against the sealed one to show it hasn't changed.

What this means for you

If your organisation uses internal models for credit risk, operational risk or market risk, ask yourself:

• Could we show a supervisor, in six months, exactly what data our model used on a given day?
• Who has the rights to change those logs, and would we know if they did?
• Do our access controls and monitoring cover the logs that feed into regulatory capital calculations?
• If FI or another supervisor questions our risk-weighted assets, what evidence can we produce?

The capital add-on at SEB is temporary, but the lesson is permanent: a model is only as reliable as the data it rests on, and that data has to be both accurate and demonstrably unchanged.

What to watch

DORA's technical standards on ICT risk management have applied since 17 January 2025 ^[2]. For banks using internal models, FI's supervisory review and evaluation process (SREP) is ongoing. The next round of SREP decisions will be published in the first quarter of 2027.

The AI Act's requirements on data governance for high-risk AI (Article 10) apply from 2 December 2027 for systems in Annex III ^[4]. That includes some credit scoring models. The logging requirement in Article 12 applies on the same date ^[5].

Sources

1. Sak & Liv, "FI: SEB:s kapitalkrav höjs efter brister i kreditriskmodeller", 14 October 2026, https://sakochliv.se/2026/10/14/fi-sebs-kapitalkrav-hojs-efter-brister-i-kreditriskmodeller/
2. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), https://eur-lex.europa.eu/eli/reg/2022/2554/oj
3. Commission Delegated Regulation (EU) 2024/1774, Article 12(2)(d), on ICT risk management under DORA, https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj
4. Regulation (EU) 2024/1689 (AI Act), Article 10 on data governance, https://eur-lex.europa.eu/eli/reg/2024/1689/oj
5. AI Act, Article 12 on automatic logging, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-12