Events & community · General · 3 min read
The API Economy in the Nordics: Banking, Public Data, Identity
Short answer
The Nordic countries have an unusually API-driven digital economy because of early digital banking, open public data, widely used electronic IDs such as BankID and MitID, and EU open banking rules under PSD2, which together made OAuth-protected APIs a normal part of banking and government services.
Key takeaways
- PSD2 required banks across the EU and EEA, including the Nordics, to open payment and account APIs to licensed third parties.
- National eIDs (Swedish and Norwegian BankID, Denmark's MitID, Finnish bank IDs) are the default way people prove identity online.
- Public agencies publish open data APIs, which raises the bar for API documentation and reliability.
Ask people in Stockholm, Oslo, Copenhagen or Helsinki how they sign in to their bank, file taxes or prove their age online, and most will name the same national eID. Combine that with early digital banking, open data policies and EU payment rules, and you get a region where APIs are part of everyday infrastructure.
Why are the Nordics so API-driven?
Early digitization of banking and government, high trust in shared digital identity, and EU rules that pushed banks to open APIs.
Online banking arrived early, and banks cooperated on shared identity schemes rather than each building their own. Governments digitized tax, health and business registration services and committed to open data. When PSD2 came into force, the infrastructure for secure, identity-aware APIs was already partly in place.
What did PSD2 change?
PSD2 required banks to give licensed third parties access to payment accounts through secure interfaces, which in practice meant APIs with strong customer authentication.
The directive, adopted in 2015, created regulated roles for account information and payment initiation services. Its technical standards on strong customer authentication applied from September 2019. Nordic banks, like others in the EU and EEA, published APIs, usually based on OAuth 2.0 with redirects to their own sign-in. Third-party providers identify themselves with eIDAS certificates. Industry groups published common API specifications to reduce fragmentation.
How do national eIDs fit in?
They are the authentication step inside many API flows, giving strong, legally recognized identity at sign-in.
| Country | Common eID | Typical issuers |
|---|---|---|
| Sweden | BankID | Banks |
| Norway | BankID | Banks |
| Denmark | MitID (replaced NemID) | Public-private scheme |
| Finland | Bank IDs, mobile certificates | Banks, mobile operators |
When a fintech app initiates a payment through a bank's API, the user is redirected to authenticate with their eID. The bank then issues an OAuth token scoped to that consent. Developers can sketch such requests in the Authorization URL Builder, though bank APIs add profile-specific parameters.
What do Nordic API teams focus on?
Security profiles for high-value APIs, consent management, developer experience and the OWASP API risks.
The OWASP API Security Top 10 (2023 edition) is a common baseline. Broken object level authorization sits at the top: an API that checks the token but not whether this user may access this account number. Payment and health APIs often follow stricter profiles such as FAPI from the OpenID Foundation, with sender-constrained tokens and pushed authorization requests.
What can API teams elsewhere learn from the region?
That shared identity infrastructure and clear regulation make APIs easier to build and to trust.
Three lessons travel well. First, when people already have a strong, widely accepted eID, API flows can rely on it for consent instead of inventing their own sign-in. Second, common specifications across banks or agencies save every developer from integrating the same thing ten ways. Third, publishing documentation, sandboxes and status pages for public APIs creates pressure to keep them reliable, and that discipline spreads to private APIs.
The flip side is concentration. When one eID or one aggregator sits in the middle of most transactions, its outages and its security become everyone's problem. Teams designing payment or data-sharing APIs should plan for the identity provider being unavailable, and for revoking consents quickly when a third party is compromised.
Where does the community meet?
At meetups, conferences and online groups for API design, security and identity.
Our overview of API security events and communities lists the kinds of events worth following. For gateway and platform choices, see the API gateway guide.
Questions
What replaced NemID in Denmark?
MitID, rolled out from 2021. NemID was then phased out.
Do Nordic open banking APIs use OAuth?
Generally yes. Most PSD2 APIs use OAuth 2.0 flows, often with redirects to the bank's own authentication using the national eID, plus certificates (eIDAS qualified certificates) to identify the third-party provider.
Sources
Tagged: APIs and the API economy, API, Nordic API community, Nordics, REST