Skip to content

SYSTEM Cited by 1 source

Swedbank core banking system

The Swedbank core banking system is one of the critical IT systems of Swedbank AB, a Swedish retail bank serving ~7M retail and ~600K corporate customers across Sweden and the Baltic region. The system enters this wiki via the April 2022 outage and the SEK 850M regulatory fine described in the 2023-08-16 High Scalability post. Concrete architecture details are not in the public record.

The 2022 incident (what's known)

From the source post and the underlying Finansinspektionen judgment (publicly released 2023-03-14):

  • Date: April 2022.
  • Scope: "temporarily left nearly a million customers with incorrect balances, many of whom were unable to meet payments."
  • Root trigger: "caused by an unapproved change to their IT systems" — an undocumented production change to "one of the bank's most central IT systems".
  • Control failure: "none of the bank's control mechanisms were able to capture the deviation and ensure that the process was followed."
  • Secondary effect: the non-compliance "probably… resulted in a slower analysis of the incident and a greater impact on the operations" — i.e., MTTR was inflated by the same deficit that caused MTTD to slip.

The regulatory response

  • Regulator: Finansinspektionen (the Swedish Financial Supervisory Authority, "Swedish FSA").
  • Options considered: full range up to "withdraw Swedbank's authorisation" (banking licence).
  • Sanction issued: "a remark and an administrative fine" of SEK 850M ≈ USD 85M.
  • Basis: "non-compliance with the change management process"
  • "insufficient [internal] controls". Legal reasoning quoted: "The deficiencies that were present in Swedbank's internal control made it possible to make changes to one of the bank's most central IT systems without following the process in place at the bank to ensure continuity and reliable operations. This violation is therefore neither minor nor excusable."

What's NOT in the public record

  • What the changed system was (core ledger, payments engine, account-lookup service, etc.).
  • What the nature of the change was (code deploy, config push, schema migration, data fix).
  • The exact duration of customer-visible impact.
  • The MTTD (how long before detection) or MTTR (time to restore) numbers.
  • The specific tooling used for change management at Swedbank.
  • Any post-incident architectural or process remediation plan.

All of the above is outside both the regulator's public judgment and the High Scalability post.

Why it enters the corpus

The incident is the most-cited recent, high-dollar example of CAB-style change management failing to catch an undocumented change. It makes the argument concrete for concepts/change-management (what the process promises vs. delivers), for external-approval ineffectiveness (the regulator-required process didn't catch anything), for undocumented production change (the direct cause), and for legacy system risk (the financial-services structural context). It is also the closest recent parallel to the 2012 Knight Capital incident (see systems/knight-capital-smars).

Seen in

External references

Last updated · 319 distilled / 1,201 read