Signature Creation: FAQ – Nordea Open Banking Support

If you encounter Signature is invalid error (error.signature.invalid), please consider the following:

Documentation regarding Signature creation:

Example code: eIDAS signature creation

Help Centre article regarding eIDAS signing:

How can I get started signing with eIDAS?

An example in our documentation:

Redirect - Token Exchange (Access Authorization API)

Use our Postman collection with your data and check if a request passes (if the Signature works it shows everything is in order from Nordea side):

Swagger and Postman files (Nordea API Market Resources)

Compare Signature received from Postman Pre-Request script to your own script. Postman Pre-Request script generates working Signatures
Send the request without "\" (backslashes) in the Signature header
Digest and Signature headers values are not hardcoded. These values are generated according to:

How do I sign my API requests? (Corporate Access Authorization API)

Postman collection includes the logic for generating these values as a pre-request script:

Creating signature header with Postman (Corporate Access Authorization API)

(Sandbox) Signature is generated based on a private key (variable: eidasPrivateKey) and Sandbox testing with any other certificate than the sample QSealC which is downloadable from:

API Market (Sandbox Developer Portal)

will always lead to an unsuccessful request. You can set Signature header to SKIP_SIGNATURE_VALIDATION_FOR_SANDBOX in case you want to test without a signature. Refer to:

How to test in developer portal and sandbox with a PKI certificate

(Sandbox) change x-nordea-originating-host value from Production host:

open.nordea.com

to Sandbox host:

api.nordeaopenbanking.com

in the signature, so it matches the value sent in X-Nordea-Originating-Host header

Ensure that headers values in the request are exactly the same as the values used to calculate the Signature (for example: if the Signature string is created based on application/json content-type, the request must also include application/json)
Headers shouldn't contain content-type and digest. For GET requests it should be:

headers="(request-target) x-nordea-originating-host x-nordea-originating-date"

Do not miss content-type: application/json in normalized string:

Authentication with eIDAS certificate/How does it work? (Access Authorization API)

Preserve a proper order of headers:

How can I get started signing with eIDAS?

Ensure they are sent in the right order and that /n is not present at the end

Use relevant private key for signing
Make sure you don't miss space characters between ":" and the value of headers:

(request-target): POST /corporate/v2/authorize
x-nordea-originating-host: open.nordea.com
x-nordea-originating-date: Mon, 14 Aug 2023 06:25:45 GMT
content-type: application/json
digest: SHA-256=IgkTCJLHZWDfD4RTmdkYscsonWvEc642BwP+gufZAsA=

Don't include whitespace characters in the payload and while generating the Digest:

Authentication with eIDAS certificate

Both endpoint URL and Digest value are taken into consideration when a Signature is calculated
When calling /corporate/v2/authorize endpoint you should have this endpoint in the normalized string:

(request-target): POST /corporate/v2/authorize
x-nordea-originating-host: open.nordea.com
x-nordea-originating-date: Mon, 07 Aug 2023 09:21:22 GMT
content-type: application/json
digest: SHA-256=IgkTCJLHZWDfD4RTmdkYscsonWvEc642BwP+gufZAsA=

Request-target is a part taken to build normalised string, hence make sure it doesn't contain double-slashes (//).

FAQ

(Sandbox) When we try to upload a test certificate to Microsoft Azure Key Vault, we get an error message: “More than one certificate with private key found in the specified X.509 certificate content. Please specify X.509 certificate content with only one certificate containing private key.” We downloaded the test certificate and changed the file extension to .pfx (Azure Key Vault does not support .p12 format). The Sandbox certificate is expired and Microsoft Azure doesn't allow expired certificates. When will you have a valid certificate for Sandbox available?

We recommend skipping the signature signing with SKIP_SIGNATURE_VALIDATION_FOR_SANDBOX in the Signature header or use alternative way of storing the certificate if your secure secret store doesn't allow you to store our test certificate.

(Sandbox) We are testing GET requests on the endpoint corporate/premium/v4/accounts and having trouble with the signature-argument in the header “Signature”. We are using a test eIDAS Certificate. What format the signature code must be provided in? Do we have to encode with base64? Do you have an example request?

In our documentation:

Example code: eIDAS signature creation

we state that the Final Signature should be created similarly as: signature="Base64(RSA-SHA256(signing string))". We provide an example on how the signature can be created with Java in the same section. In case of POST, PUT or PATCH method you have to also add "Content-Type" and "Digest" header with value Digest. Example on how to create Digest can be found in our documentation:

Testing eIDAS signature

Are the following steps correct?

Define the signing string as desired:

“(request-target): get corporate/premium/v3/accounts\n
x-nordea-originating-host: api.nordeaopenbanking.com\n
x-nordea-originating-date: Fri, 31 Mar 2023 08:31:34 GMT\n”

Encrypt the signing string using RSA-SHA256 and the private key from the test certificate
base64-encode the encrypted signing string
Assign the encoded signing string to the signature-header and define the remaining headers
Make the get request

Yes, they're correct. Refer to our Help Centre article:

Signature header content

(Sandbox) What could be the reason of the following error ("code": "error.signature.invalid", "description": "Signature is invalid.")?

"group_header": {
"message_identification": "1403586aee0bac92dabdde59172a4d24",
"creation_date_time": "2025-01-02T13:22:51.125082431Z",
"http_code": 401
},
"error": {
"request": {
"url": "/premium/v4/accounts/DK20{redacted}15-DKK"
},
"failures": [
{
"code": "error.signature.invalid",
"description": "Signature is invalid."

Error code "error.signature.invalid" usually means that "Signature" header in a request is invalid. Probably wrong data was used for encryption in "signature" part of "Signature" header or there might be too many quotation marks at the beginning and the end of signature value.

As our certificates expired and we tried to use the new ones, we encountered the following error:

code:"error.signature.invalid"
description:"Signature is invalid."
url:"/personal/v5/authorize"
creation_date_time:"2025-04-11T12:32:35.421821277Z"
http_code:401
message_identification:"25d3482f9007166e"

Please refer to: eIDAS QsealC Certificate/PSD2 (Compliance) Onboarding FAQ

(Sandbox) We tried to call:

Corporate Authorization API

API Reference - Corporate Access Authorization API

for an access token but encountered the following error response:

Request
curl --request POST \
--url http://api.nordeaopenbanking.com/corporate/v2/authorize \
--header 'content-type: application/x-www-form-urlencoded' \
--header 'digest: sha-256=01d4b63399818[redacted]9fa45f4da' \
--header 'signature: keyId="65c47[redacted]2585",algorithm="rsa-sha256",headers="(request-target) x-nordea-originating-host x-nordea-originating-date content-type digest",signature="t8GCFjJydSH6/3UWDU[redacted]7CNTI7SjvhxoOEiaH"' \
--header 'x-ibm-client-id: 65c47[redacted]585' \
--header 'x-ibm-client-secret: [redacted]' \
--header 'x-nordea-originating-date: Mon, 23 Jun 2025 09:00:53 GMT' \
--header 'x-nordea-originating-host: api.nordeaopenbanking.com' \
--data grant_type=client_credentials

Response
{
"group_header": {
"message_identification": "261e451d3d36ea8778aef94b91446927",
"creation_date_time": "2025-06-23T09:43:47.737666836Z",
"http_code": 401
},
"error": {
"request": {
"url": "/v2/authorize"
},
"failures": [
{
"code": "error.signature.invalid",
"description": "Signature is invalid."

You need to include required body parameters in your request towards:

POST /corporate/v2/authorize

Please also see:

Swagger and Postman files (Nordea API Market Resources)

Which private key format is accepted by Nordea?

Different tools and languages handle private keys in different formats (PKCS#1, PKCS#8, PKCS#12), but the underlying key material is the same (private key can be converted between those formats using OpenSSL tool). In general our APIs accept keys in PKCS#8 format, which is the industry standard. Java code often expects .p12 (PKCS#12) files which is essentially a container that can hold PKCS#8 keys and certificates. JavaScript/Postman code may show PKCS#1 keys, but these can be converted from and to PKCS#8 (without changing the actual key itself).

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?

Ensure the following:

The signature algorithm configuration between the client and server must match. The only accepted algorithm is RSA-SHA256.
The public key registered on the server via the certificate must correspond to the private key used for signing.

After the eIDAS certificate update, we did not make any changes to our signature creation process. Could this be the reason of the following error: "code":"error.signature.invalid", "description":"Signature is invalid."?

{"group_header":{"message_identification":"23f85e8a2df21681","creation_date_time":"2025-11-06T14:45:39.901724267Z","http_code":401},"error":{"request":{"url":"/personal/v5/authorize"},"failures":[{"code":"error.signature.invalid","description":"Signature is invalid."}]}}

Yes, you must update the private key assigned to the new certificate, which is used when creating a signature. This is required for proper communication. The private key and certificate must match: the private key is used to create the signature, and the certificate is used to verify it. If you update the certificate but do not update the corresponding private key, the signature cannot be validated, and signature creation will fail. You need to update the private key in your script to match the new certificate in order to generate the Signature header correctly.

If you still need our assistance, please submit a request:

Nordea Open Banking contact form

and provide:

a full body of an Open Banking API request/response with an exact endpoint, headers, message_identification and creation_date_time included - please see:

API Reference

API responses and response codes

Error codes and responses

calculated normalized string before encryption
your algorithm (don't disclose your certificate) in order to show how you create a Signature

Related Questions

FAQ

If you still need our assistance, please submit a request: