Related Questions

Unable to find what you are looking for?
Raise a Ticket

Access Authorization: FAQ

Reference:

Access Authorization API

API reference - Access Authorization

Swagger and Postman files (Nordea API Market Resources)

 

Q:

We want to test the authorization flow in your Sandbox environment. How can we go through Nordea UI where a user authenticates and select bank accounts? We cannot find the URL for the wizard where we can select bank accounts and redirect to our application with the provided authorization code. What is the starting point of this flow?

A:

Nordea UI is not available in Sandbox - this step is mocked in Sandbox. The first step of the authorization flow is:

Redirect - Initiating the authorization flow

The call will return HTTP 302 redirect code, indicating a successful redirect. Check response Headers - Location for getting the authorization code.

 

Q:

Then requesting:

POST /v5/authorize

will redirect us to the Nordea UI where the user authenticates and select bank accounts only in Production environment?

A:
Yes, that's correct.

 

Q:

Will the user be automatically redirected from your side to Nordea UI after:

POST /authorize

request or you will return only 302 and we have to redirect the user to the returned Response.Headers.Location?

A:
This option is correct for Sandbox. Nordea UI Authentication wizard is skipped in Sandbox. After initiating the authorization flow the call should return HTTP 302 redirect code and you need to redirect the user to the returned Response.Headers.Location. This value corresponds with the redirect_uri provided in the /authorize request with the parameter auth code. For example:

 Response.Headers.Location: test.com?code=<code>

Refer to:

Redirect - Initiating the authorization flow

 

Q:

What happens after:

POST /v5/authorize

in Production environment? Will we get URL for Nordea UI in Response.Headers.Location where we should redirect the user? Is that a web page URL?

A:

Refer to the following Production flow:

  1. TPP starts the process by initiating the Redirect Authorization flow. The flow can be initiated through the following endpoint: POST /authorize
  2. The call will return an HTTP 302 redirect code, indicating a successful redirect ("Location" header of the response includes the Nordea UI URL)
  3. PSU (Payment Service User) is redirected to Nordea UI to select bank accounts he wishes to grant access to
  4. After this selection is done, he can continue the flow and return back to TPP application.

Refer to:

Redirect access authorization flow (Access Authorization API)

 

Q:

Do you provide the information about user's selected bank accounts? If yes, where we can acquire it?

A:

TPP cannot see the information about selected accounts until a full authorisation flow is successfully completed. Then TPP can call:

GET /assets

endpoint to get a list of accounts with a given consent.

 

Q:

(Sandbox) Is it possible to use localhost as a redirect URL for testing purposes?

A:

It's not possible to use localhost as a redirect URL endpoint. Redirect URL must be opened by Nordea services in order to pass the authorization code to TPP and localhost is not accessible from outside your machine. Authorization code is short-lived with a one-time usage, and exchanged for an access token during access authorization. You may use https://www.example.org as a redirect_uri for testing purposes.

Note:

In Sandbox redirects are defined in Developer Portal, during application creation:

Please also see: Nordea Developer Portal (API Market Sandbox) guide

 

Q:

(Sandbox) While making the request towards:

POST /personal/v5/authorize?Client_id=720f{redacted}d09f&country=DK&duration=3600&redirect_uri=https://example.org&scope=ACCOUNTS_BASIC,ACCOUNTS_BALANCES, ACCOUNTS_DETAILS,ACCOUNTS_TRANSACTIONS,PAYMENTS_MULTIPLE&state=teststate HTTP/1.1
Host: api.nordeaopenbanking.com

with an empty body and default Postman headers we get the following response:

{"httpCode":"401","httpMessage":"Unauthorized","moreInformation":"Invalid client id or secret."}

A:

Proper headers and the body must be included within the request. Please refer to:

Redirect Access Authorization (POST /personal/v5/authorize)

 

Q:

What am I supposed to send in the "state" parameter?

A:

Please refer to:

Swagger and Postman files (Nordea API Market Resources)

OAuth 2.0 Authorization Framework

 

Q:

We want to integrate SEPA Payments through Nordea. While exploring Access Authorization API we see that obtaining an access token involves multiple API calls. What's the rationale behind this process? Is there a way to simplify the token retrieval process?

A:

We have two authorisation flows: redirect and decoupled. 

  • In case of redirect flow there are only two API requests:
    1. First - a user provides information about a consent (scope, duration, etc.) and in the response there is a link for a customer to be redirected to the authorisation system
    2. Second - to exchange auth code into access and refresh tokens or refresh pairs of tokens

Please refer to:

Redirect access authorization flow (Access Authorization API)

  • In case of decoupled flow there are four API requests:
    1. First - to define which authentication method a customer chooses
    2. Second - has several justifications: to get status of customer authentication and fetch auto start token to meet animated QR code requirements
    3. Third - is for a customer to provide a consent details, but the most important thing is that in a case of multiple agreements a customer provides information which agreement he gives consent to. List of agreements can be returned after successful authorisation.
    4. Fourth - to exchange authorisation code to access and refresh tokens, but this request is also used to get a new pairs of access and refresh tokens during consent duration.

Please refer to:

Decoupled access authorisation flow (Denmark, Finland, Norway and Sweden) - Access Authorization API

 

Q:

(Sandbox) While calling:

POST personal/v5/authorize/token

curl --location 'https://api.nordeaopenbanking.com/personal/v5/authorize/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'X-IBM-Client-Id: {{client_id}}' \
--header 'X-IBM-Client-Secret: {{client_secret}}' \
--header 'Digest: sha-256={{sha_256}}' \
--header 'X-Nordea-Originating-Date: Thu, 29 May 2025 04:03:17 GMT' \
--header 'X-Nordea-Originating-Host: api.nordeaopenbanking.com' \
--header 'Signature: SKIP_SIGNATURE_VALIDATION_FOR_SANDBOX' \
--data-urlencode 'code=ZXlKbGJtTWlPaUpCTWpVMlIwTk5JaXdp{redacted}ucDhjTV9id0Z6Nk9tWDd3S192YnozX3BSV3lCSzgzUUNxaU5ldXE4LlRXdVdQR0N4SEY0VTdWTUhJWkdaMnc=' \
--data-urlencode 'grant_type=authorization_code'

to exchange the authorization code for access and refresh tokens, we encounter the following error ("code": "error.parameters.invalid", "description": "Parameters invalid"):

Response:
{
"group_header": {
"message_identification": "531f07049df1d11dc954b37d9a81e7d9",
"creation_date_time": "2025-05-29T04:26:05.374073561Z",
"http_code": 400
},
"error": {
"request": {
"url": "/v5/authorize/token"
},
"failures": [
{
"code": "error.parameters.invalid",
"description": "Parameters invalid"

A:

You need redirect_uri parameter to be included in your request's body. Please see:

Redirect - Token Exchange (Access Authorization API)

 

Q:

(Sandbox) We are trying to implement a decoupled authorisation flow and have encountered an issue when exchanging the first authorisation code for the second one. The error indicates that the request has an invalid response_type:

POST https://api.nordeaopenbanking.com/personal/v5/decoupled/authorizations HTTP/1.1
Content-Type: application/json
X-IBM-Client-Id: f4db39***8671
X-IBM-Client-Secret: ***
X-Nordea-Originating-Date: Mon, 11 Aug 2025 13:33:02 GMT
X-Nordea-Originating-Host: api.nordeaopenbanking.com
Signature: keyId="f4db399c***671",algorithm="rsa-sha256",headers="(request-target) x-nordea-originating-host x-nordea-originating-date content-type digest",signature="xoaf5swZCeTL***/NL3AiqCS5KreFm11AFa3R+5/X"

{"account_list":["ALL"],"code":"eyJlbmMiOiJBMjU2R0NNIiwiYW***1UFHjKDywkAqLJoZikiuzF.4dAVmKRO-8LZ86EvE_KRIw","duration":259200,"max_tx_history":12,"response_type":"code","scope":["ACCOUNTS_BASIC","ACCOUNTS_BALANCES","ACCOUNTS_DETAILS","ACCOUNTS_TRANSACTIONS"]},

HTTP/1.1 400 Bad Request
Date: Mon, 11 Aug 2025 13:33:03 GMT
Content-Type: application/json
Content-Length: 333
Connection: keep-alive
Vary: Origin,Access-Control-Request-Method,Access-Control-Request-Headers
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 0
Referrer-Policy: no-referrer
X-Global-Transaction-ID: 7fd914***b6c1
X-RateLimit-Limit: name=default-rate,10000;
X-RateLimit-Remaining: name=default-rate,9991;
X-Proxygen-Request-Success: true
X-Postigen-Response-URL: https://api.nordeaopenbanking.com/personal/v5/decoupled/authorizations

{
"group_header": {
"message_identification": "f1c71aa0353af8971b0e115c41ba9752",
"creation_date_time": "2025-08-11T13:33:03.702458914Z",
"http_code": 400
},
"error": {
"request": {
"url": "/v5/decoupled/authorizations"
},
"failures": [
{
"code": "error.validation",
"description": "Response type not supported.",
"path": "response_type",
"type": "Pattern"

A:

Please see:

Authorize PSU accounts (Access Authorization API)

and provide a valid response_type parameter - nordea_token - in your request:

 

Q:

While we request the production endpoint:

POST /v5/authorize

URI : https://open.nordea.com/personal/v5/authorize
Method : POST
X-IBM-Client-ID: 802e***fac5e
X-IBM-Client-Secret: ***
X-Nordea-Originating-Host: api.nordeaopenbanking.com
X-Nordea-Originating-Date: Wed, 03 Sep 2025 17:52:35 GMT
Signature: keyId="802ecbe4***c4bfac5e",algorithm="rsa-sha256",headers="(request-target) x-nordea-originating-host x-nordea-originating- date content-type.........

we receive the following error in the response ("code" : "error.host.invalid",
"description" : "X-Nordea-Originating-Host contains invalid host [api.nordeaopenbanking.com]."):

Status code : 401 UNAUTHORIZED
Status text : Unauthorized

Body:
{
"group_header" : {
"message_identification" : "17bf0fef2df21681",
"creation_date_time" : "2025-09-03T17:52:36.874846685Z",
"http_code" : 401
},
"error" : {
"request" : {
"url" : "/personal/v5/authorize"
},
"failures" : [ {
"code" : "error.host.invalid",
"description" : "X-Nordea-Originating-Host contains invalid host [api.nordeaopenbanking.com]."

What is the correct value of the X-Nordea-Originating-Host header in production?

A:

The production value of X-Nordea-Originating-Host header should be: open.nordea.com

 

Q:

We encountered the following error: "code": "error.security.invalid",
"description": "Unspecified error with OBI authentication."

REQUEST:
POST https://open.nordea.com/personal/v5/authorize (2025-09-08T11:32:40.9528387Z)
RESPONSE:
401 Unauthorized https://open.nordea.com/personal/v5/authorize (2025-09-08T11:32:41.0880000Z)
Connection: Keep-Alive
Content-Type: application/json
Date: Mon, 08 Sep 2025 11:32:41 GMT
Strict-Transport-Security: max-age=157680000
Strict-Transport-Security: max-age=157680000; includeSubDomains
Transfer-Encoding: chunked
X-BurstLimit-Limit: name=burst-limit-1,130;name=auth-v5-api-burstlimit,30;
X-BurstLimit-Remaining: name=burst-limit-1,129;name=auth-v5-api-burstlimit,29;
X-Global-Transaction-ID: c054***7491
X-RateLimit-Limit: name=rate-limit-1,11000000;name=auth-v5-api-ratelimit,1700000;
X-RateLimit-Remaining: name=rate-limit-1,10999744;name=auth-v5-api-ratelimit,1699744;
{
"group_header": {
"message_identification": "17e92a54816a1681",
"creation_date_time": "2025-09-08T11:32:41.069558349Z",
"http_code": 401
},
"error": {
"request": {
"url": "/personal/v5/authorize"
},
"failures": [
{
"code": "error.security.invalid",
"description": "Unspecified error with OBI authentication."

What could be the reason?

A:

Please refer to: Signature Creation: FAQ

 

Q:

Our organisation implements direct integration with Nordea through PSD2 AIS APIs and requires clarification regarding agreement relationships with user profiles and account access. Consider this scenario: when parents possess access to multiple profiles, including personal accounts and children's accounts, do these constitute separate agreements? Does account connection across multiple profiles necessitate individual authentication processes for each agreement? Does the sandbox environment support multi-agreement scenario testing, or does this functionality exist exclusively in production environments?

A:

  • Each agreement corresponds to a distinct profile. When users authenticate and gain access to multiple profiles, both personal and family member profiles appear as separate agreement entries. Each entry displays a unique identifier alongside the associated customer name.
  • The issued access token and refresh token are scoped to the selected agreement. Accounts, scopes, and consent are all bound to that one profile. A token for one profile cannot be used to fetch data belonging to another.
  • Accessing a different profile requires a separate, independent authentication. There is no mechanism to obtain a token that spans multiple profiles or to switch profiles on an existing token.

Consequently, implementing a parent-child account structure requires executing complete authentication flows for each profile, with each flow generating its own access and refresh token pair.

Agreement selection is only available in the decoupled flow (currently supported for Sweden and Denmark):

POST personal/v5/decoupled/authorizations

Upon submission of a decoupled authorization request, the API responds with HTTP 409 Conflict in place of the authorization code when the authenticated user possesses access to multiple profiles. The response body includes an agreements array containing the available profiles: 

{  "agreements": [    { "id": "…", "type": "…", "customer_name": "Parent Name", "customer_id": "…" },    { "id": "…", "type": "…", "customer_name": "Child Name",  "customer_id": "…" }  ]}

Your application presents the list to the end user, then calls:

POST /v5/decoupled/authorizations/{agreement_id} {  "code": ""}

This request generates the authorization code required for subsequent token exchange.

The sandbox environment provides complete multi-profile selection functionality within the decoupled flow. Our documentation:

Agreement Selection API (For Denmark and Sweden only)

specifies particular test PSU identifiers that activate HTTP 409 response scenario: 

Country

Auth method

PSU ID
Sweden BANKID_SE 199711282849
Denmark MTA_DK 4301481

The sandbox environment simulates PSU identification, ensuring that only designated test identifiers generate multiple agreement responses. All other PSU identifiers function as single-agreement scenarios.

Note: The redirect-based OAuth flow resolves to the user's primary agreement without offering a selection step.

 

Q:

Which authentication method - redirect or decoupled - is most effective or commonly used for personal accounts in SE, FI, DK, and NO?

A:

The success of the authentication solution (redirect or decoupled) depends mainly on the TPP’s use case and user journey, not market differences. We offer both options so TPPs can choose what fits best. Both meet all requirements and receive equal support.

 

Q:

How can we identify the PSU's authentication method in Sweden to decide between redirect or decoupled flow?

A:

BankID authentication is available in both redirect and decoupled solutions. The choice depends on the TPP’s specific use case and user journey.

 

Q:

If the PSU uses a physical keycard/token and we choose the decoupled approach, will the decoupled flow still work?

A:

The Nordea ID device (physical token) isn't available in the decoupled flow, which requires mobile or app-based methods.

Still need help?
Have we not answered your question?
Don't worry, you can contact us for more information Contact us