Account Transaction & Balance API

Introduction

The Account Transaction & Balance API gives businesses direct access to transactions and balances on their Danske Bank accounts in real time through a single integration.

Whether you're automating reconciliation, building cash forecasting models, embedding live bank feeds into an ERP, or automating workflows, the API delivers the data your financial tool needs without delays, batch jobs, or fragmented connections.

It's designed to slot into existing systems, treasury platforms, accounting software, Excel/PowerBI, or AI tools.

Use Cases and Features

Real-time insights: See account activity and balance changes the moment they happen.

Automated reconciliation: Match incoming payments to invoices automatically and trigger downstream workflows like order fulfilment, settlement, or reporting.

Embedded bank feeds: Push transactions and balances directly into ERP, accounting, or treasury platforms, so end users see live Danske Bank data inside the tools they already work in.

Features

• Real-time transaction retrieval for a specified account
• Transaction history with date-range and ULID-based filtering
• Rich transaction detail: counterparty, reference, booking date, value date, amount, and more
• Detailed retrieval of a specific transaction, including entryDetails for underlying transactions when available
• Current and historical balances (booked, interest, available, intra-group)
• End-of-day balanace lookup
• Multi-language transaction texts (DA, EN, SV, NO, FI, DE, PL, FR)

Markets

The API is available across all of Danske Bank's markets.

It's been built and validated with a disparate range of customers. The API covers the core jobs that finance teams and platforms rely on every day. Equally, we continuously expand its capabilities and add more data points.

For specific requirements or integration questions, please reach out to us.

Getting Started

External API Platform

To get started with the Account Transaction & Balance API, it is necessary to onboard via External API Platform first. After onboarding the platform, you will have access to all the Premium APIs that Danske Bank offers.

Link to External API Platform onboarding guidelines: Danske Bank Open Banking Developer Portal

Certificate

Production acccess requires a valid certificate registered. See the Premium APIs FAQ for supported certificate types and the registration steps: Danske Bank Open Banking Developer Portal

Environment Description

As described in the External API Platform onboarding guidelines, the Account Transaction & Balance API will be available in two environments:

• Sandbox: This environment will be used for initial integration tests and will provide mocked data. The mocked data includes three accounts. Each account will have transactions with either NOK, SEK or DKK currencies.

• Production will provide you access to your real data. What accounts you have access to depends on your technical user setup.

Sandbox URLs

Token Endpoint: https://sandbox-api.danskebank.com/sandbox-corporate/api/dk/business/oauth2/token

Account Transaction & Balance API: https://sandbox-api.danskebank.com/sandbox-corporate/api/v1/account-transaction-service

Production URLs

Token Endpoint: https://api.danskebank.com/corporate/api/dk/business/oauth2/token

Account Transaction & Balance API: https://api.danskebank.com/corporate/api/v1/account-transaction-service

Authentication

To access a resource, the client must first request a Client Credentials Grant token by calling the token endpoint specified in the OpenId configuration (token_endpoint). The request should be an x-www-form-urlencoded POST with the following parameters:

• grant_type - client_credentials (read more).

• scope - should include a scope the client has access to; for the Account Transaction & Balance API, it MUST contain the “accounts” keyword (read more).

• client_id - the ID received after onboarding (read more).

Example Request:

curl --location --request POST 'https://example.com/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=1233456' \
--data-urlencode 'scope=accounts'

Example Response:

{
  "token_type":"Bearer",
  "access_token":"A****",
  "metadata":"m:",
  "expires_in":3600,
  "consented_on":1588933990,
  "scope":"accounts"
}

Using the Access Token:

The access_token received is valid for 1 hour and must be included in the request header on all subsequent API requests:

Authorization: Bearer <access_token>

Supported Endpoints

Account Transaction & Balance API includes the following key endpoints to interact with:

Implementation Details

Accounts

Retrieve account information for the accounts available through your technical user. This endpoint provides the foundation for building account overviews, dashboards, and financial workflows on top of Danske Bank account data.

The /accounts/list endpoint is a prerequisite to fetch your transactions by fetching account ids first. The accounts you have access to will be defined by how your technical user is set up. You can only see accounts where that user has enquiry permissions.

The endpoint will provide you with UUIDs (technical ids) of your accounts within the field called "other" (see example response below). This is the {accountId} to use in both the /accounts/{accountId}/transactions and the /accounts/{accountId}/balances endpoint. These UUIDs will remain the same, so it is suggested that you store them to avoid having to call the endpoint every time you want to fetch transactions. See suggested flow below.

Accounts Pagination

Pagination can be implemented by utilizing the “offset” parameter together with the value in “href” in the response. To get next page, extract the number value after “offset=” and use it in the offset request parameter. An example of a href value:

"href": "/v1/account-transaction-service/accounts/list?offset=1314351&limit=10"

Here you would extract the value 1314351 and use it in the offset request parameter for your next request to get “page 2”.

Example Request and Response for Accounts

Accounts cURL Request

curl -X GET https://api.danskebank.com/corporate/api/v1/account-transaction-service/accounts/list?offset=0&limit=10 \ 
-H "Authorization: Bearer {accessToken}" 

Accounts Response

{
  "accounts": [
    {
      "iban": "DK3030000011223388",
      "bban": "11223388",
      "other": "b03bb874-b6c5-5bbf-bb63-bbb96984bb23",
      "country": "DK",
      "currency": "DKK"
    },
    {
      "iban": "NO511112233333",
      "bban": "11112233333",
      "other": "7bb255b2-7352-50bb-b278-0b19b02db829",
      "country": "NO",
      "currency": "NOK"
    },
    {
      "iban": "SE7212000000011223344556",
      "bban": "11223344556",
      "other": "bbb2bb25-5a20-5463-b676-5b088cb7b1b9",
      "country": "SE",
      "currency": "SEK"
    }
  ],
  "next": {
    "href": "/v1/account-transaction-service/accounts/list?offset=4121389&limit=3"
  }
}

Transactions

Retrieve real-time transaction data for a specific account. This endpoint provides enriched transaction information such as counterparty details, references, booking and value dates, amounts, and other data points that support reconciliation, reporting, and financial automation.

This section covers the request parameters to the /accounts/{accountId}/transactions endpoint, the response structure, pagination, and the recommended polling pattern for staying in sync with an account without missing or duplicating transactions.

Query Parameters

Field Details: aspspParameters

Each transaction is assigned a ULID (Universally Unique Lexicographically Sortable Identifier). The ULID for a given transaction is exposed in the response at links.aspspParameters.href, and the maximum ULID across the response is also surfaced in the response's top-level next.href link to support pagination (see Pagination below).

A ULID is assigned at the moment a transaction is processed by our system, not at the moment it is booked. This distinction matters because:

• A transaction can have a bookingDate in the future (a future-booked transaction). It receives its ULID today, when it is processed, but only becomes visible in responses once its booking date arrives. On its booking date, its ULID will already be lower than transactions both booked and processed that day.
• A transaction can have a bookingDate in the past (a backdated transaction). It also receives its ULID at the moment of processing, so its ULID will sit alongside other transactions processed at the same time, even though its bookingDate is older.

In short: ULIDs are monotonic within a single UTC day, but not across day boundaries. These properties are what drive the Recommended Query Pattern further down.

Disclaimers on aspspParameters

• The value will not be available for transactions created before 2025-03-01.

Date Filters

Both bookingDateFrom and bookingDateTo use the format YYYY-MM-DD and are inclusive at both ends. If you do not provide a bookingDateTo, the endpoint returns transactions from bookingDateFrom up to "now" (the moment the request is processed).

When combined with aspspParameters, the server applies both filters: it returns transactions whose bookingDate is within the date range and whose ULID is strictly greater than aspspParameters.

Disclaimer on date filters

• Historical data is only available back until 2025-03-01.

Bank Transaction Code Filters

The endpoint allows transactions to be filtered by their bank transaction code. When a bank transaction code is provided, the endpoint returns transactions that match the specified value.

The supported format for bank transaction codes is abcd-efgh-ijkl, and the search is not case sensitive.

Disclaimer on Bank Transaction Code filters

• Partial bank transaction codes can also be used as search terms, though the position of the substring cannot be specified.

Language Code Selection

The endpoint accepts a languageCode parameter to specify the language for bank-generated transaction texts. For example, setting languageCode to FI displays transaction texts in Finnish. The language code must conform to the ISO 639-1 standard. If no languageCode is provided, the API defaults to English. Include the languageCode parameter in your API request to receive transaction texts in the specified language, where available.

The following languages are currently supported:

Please note that not all texts are translated into every supported language. If a specific translation is missing, the original untranslated text will be returned.

Transactions Pagination

When a response contains exactly limit transactions (1000 by default), there may be more transactions to retrieve. To page through the remainder:

1. Take the URL provided in the response's top-level next.href. Its query string already contains aspspParameters set to the highest ULID in the response just received — the server pre-computes this so consumers do not need to scan the response array themselves.
2. Call that URL.
3. Repeat until a response returns fewer than limit transactions.

The transactions in a response are not sorted by ULID, so if for any reason you need to determine the maximum ULID yourself rather than relying on next.href, do not assume the last item in the array carries the highest value.

This pagination pattern applies to every call described in the Recommended Query Pattern below.

Recommended Query Pattern

This section describes how to call the endpoint so that you receive every transaction exactly once — no duplicates, no misses — regardless of how often you poll. Run bootstrap (A) once at onboarding; from then on every poll uses the within-day flow (B), except the first poll of each new UTC day, which uses the rollover flow (C)

State to persist (per account)

You only need to persist one value per account:

• lastSeenUlid — the maximum aspspParameters value seen so far for that account. Update this as you process transactions across all paginated responses; the highest value encountered is your new lastSeenUlid.

Constants used below

• LOOKBACK_DAYS = 30 — how far back to re-check for backdated transactions. Increase this if your business accepts backdating beyond 30 days; decrease at the cost of risking missed backdated transactions.
• "Day" means UTC day, since the API operates in UTC.

A. First-ever poll (bootstrap)

Run once per account when first integrating.

Paginate to completion. Save the maximum ULID encountered as lastSeenUlid.

Example: ?bookingDateFrom=2025-03-01&limit=1000

B. Subsequent poll within the same UTC day

A single call per account.

Paginate to completion. Update lastSeenUlid to the new maximum.

Example: ?bookingDateFrom=2026-04-04&aspspParameters=01JP1XJV95P02XBDAVVSF6E2QB&limit=1000

C. First poll of a new UTC day (rollover)

This requires two calls per account, in either order. The two calls are deliberately non-overlapping: C1 covers today's bookings; C2 covers everything earlier.

C1 — Future-booked sweep. Picks up transactions whose bookingDate is today but which were processed (and ULID-stamped) earlier, possibly days or weeks ago.

Example: ?bookingDateFrom=2026-05-04&limit=1000

C2 — Backdated sweep. Picks up transactions backdated into the lookback window that have been processed since the last poll.

Example: ?bookingDateFrom=2026-04-04&bookingDateTo=2026-05-03&aspspParameters=01JP1XJV95P02XBDAVVSF6E2QB&limit=1000

Paginate each sweep to completion. Update lastSeenUlid to the maximum across both sweeps and all their pages. For any further polls during the same UTC day, fall back to flow B.

Why this works

The two rollover calls do not overlap: C1 returns only bookingDate = today; C2 returns only bookingDate = yesterday. Flow B only returns transactions with ULIDs greater than lastSeenUlid, so previously delivered transactions are not redelivered.

Notes and edge cases

• Historical limit. Transaction history and ULIDs are only available from 2025-03-01. During the first 30 days after that limit, cap the lookback window at the available history.
• Lookback window. The 30-day default covers the great majority of backdated transactions. If your accounts accept backdating beyond 30 days, increase LOOKBACK_DAYS; note that this widens the date range queried by both flow B and flow C2.
• Defensive deduplication. As a safety net, consumers may deduplicate on transactionId on their side. With the recipe above this should never be necessary, but it is inexpensive and protects against unexpected boundary cases.
• Polling cadence. This pattern works for any cadence, from once per day to continuous polling. The only cadence-sensitive step is detecting that the UTC day has rolled over since the previous poll, which triggers flow C instead of flow B.

Example Request and Response for Transactions

Transactions cURL request

curl -X GET "https://api.danskebank.com/corporate/api/v1/account-transaction-service/accounts/63bd9d0c-67ba-4be6-bccb-f4c20190aa7d/transactions?bookingDateFrom=2025-06-01&limit=1000&aspspParameters=01JP1XJV95P02XBDAVVSF6E2QB" \
-H "Authorization: Bearer {accessToken}"

Transactions Response

{
  "transactions": [
    {
      "transactionId": "CE42C787E4EBB35119A5A4854D90CE9A26C2F492112D4E6B7C2742DE97936F24",
      "entryReference": "2025-03-10T19:52:13.952918Z",
      "batchIndicator": false,
      "references": {
        "accountServicerReference": "8101579783",
        "instructionId": "TEST-65980824",
        "endToEndId": "700179278"
      },
      "bookingDate": "2025-03-10",
      "valueDate": "2025-03-10",
      "transactionAmount": {
        "currency": "DKK",
        "amount": "-472.05"
      },
      "amountDetails": {
        "instructedAmount": {
          "currency": "DKK",
          "amount": "-472.05"
        }
      },
      "creditorAccount": {
        "bban": "81015797830824"
      },
      "debtor": {
        "name": "Test Solutions Ltd"
      },
      "remittanceInformationUnstructured": ["Money to XXX"],
      "additionalTransactionInformation": "ABC.TEST-65980824",
      "bankTransactionCode": "PMNT-ICDT-DMCT",
      "balanceAfterTransaction": {
        "balanceAmount": {
          "currency": "DKK",
          "amount": "4360368.23"
        },
        "balanceType": "interimBooked"
      },
      "links": {
        "aspspParameters": {
          "href": "01JP1XJV95P02XBDAZVQF6D8QB"
        }
      }
    },
    {
      "transactionId": "69CA5B4E7D873BFAF40B13AB68C92BF8758ADF60E23436BC128566CC89367D64",
      "entryReference": "2025-03-10T19:41:13.485129Z",
      "batchIndicator": false,
      "references": {
        "accountServicerReference": "8101579784",
        "instructionId": "TEST-44480824"
      },
      "bookingDate": "2025-03-10",
      "valueDate": "2025-03-10",
      "transactionAmount": {
        "currency": "DKK",
        "amount": "-553.65"
      },
      "amountDetails": {
        "instructedAmount": {
          "currency": "DKK",
          "amount": "-553.65"
        }
      },
      "creditorAccount": {
        "bban": "81111797830824"
      },
      "debtor": {
        "name": "Test Trading Co"
      },
      "remittanceInformationUnstructured": ["Money to XXX"],
      "additionalTransactionInformation": "ABC.TEST-44480824",
      "bankTransactionCode": "PMNT-ICDT-DMCT",
      "balanceAfterTransaction": {
        "balanceAmount": {
          "currency": "DKK",
          "amount": "4360840.28"
        },
        "balanceType": "interimBooked"
      },
      "links": {
        "aspspParameters": {
          "href": "01JP1XJPXGN64SB5HQFJ7F3G6K"
        }
      }
    }
  ],
  "next": {
    "href": "/v1/account-transaction-service/accounts/63bd9d0c-67ba-4be6-bccb-f4c20190aa7d/transactions?bookingDateFrom=2025-06-01&limit=1000&aspspParameters=01JP1XJV95P02XBDAZVQF6D8QB"
  }
}

Transaction Details

Retrieve the full details of a specific transaction on an account. This endpoint can provide underlying entry details for supported bulked transactions, helping you gain deeper insight into payment activity and reconciliation processes.

The /accounts/{accountId}/transactions/{transactionId} endpoint returns entryDetails when available. This is useful for transactions that represent multiple underlying entries, such as bulked transactions.

Data on bulked transactions are subject to availability and are currently limited to FIK and certain CREMUL (KID) payments.

Path and Query Parameters

What the endpoint returns

The response contains a transactionDetail object with detailed information about the requested transaction. This includes fields such as transactionId, entryReference, references, bookingDate, valueDate, transactionAmount, amountDetails, creditor, debtor, remittanceInformation, bankTransactionCode, and additionalTransactionInformation.

When available, the response also includes entryDetails. The entryDetails array contains additional details related to the transaction entry and may be useful when a single booked transaction represents multiple underlying entries.

If the number of entryDetails exceeds the requested page size, pagination is supported through the limit, offset, and next fields.

Entry Details

Each item in entryDetails can include:

• debtor
• transactionAmount
• debtorAccount
• remittanceInformationStructured

If entryDetails is present, it provides a more granular breakdown of the transaction.

For transactions that represent multiple underlying entries, such as bulked transactions, the entryDetails array may contain many items and can be paginated.

Language Code Selection

The endpoint accepts an optional languageCode parameter to specify the language for bank-generated transaction texts.

For supported language codes and fallback behavior, see the Language Code Selection section under Transactions.

Transaction Details Pagination

The response may include a next object with an href value for retrieving the next page of entryDetails.

Use the limit parameter to control page size and the offset parameter to request subsequent pages.

Pagination is relevant when the transaction contains more entryDetails items than can be returned in a single response.

Example Request and Response for Transaction Details

Transaction Details cURL request

curl -X GET "https://api.danskebank.com/corporate/api/v1/account-transaction-service/accounts/{accountId}/transactions/{transactionId}?languageCode=EN&limit=100&offset=0" \
-H "Authorization: Bearer {accessToken}"

Transaction Details Response

{
  "transactionDetails": {
    "transactionId": "3B8063BEC1E5856E0S36AFF4B382EDCB108CE952886DE8545E590D9AD2FE16BA",
    "entryReference": "2026-05-18T23:49:15.199160Z",
    "batchIndicator": false,
    "references": {
      "accountServicerReference": "FISAM.POST"
    },
    "bookingDate": "2026-05-19",
    "valueDate": "2026-05-19",
    "transactionAmount": {
      "currency": "DKK",
      "amount": "18718.75"
    },
    "entryDetails": [
      {
        "remittanceInformationStructured": {
          "creditorReferenceInformation": {
            "reference": "0000000000080341602",
            "referenceTypeCode": "SCOR"
          }
        },
        "transactionAmount": {
          "currency": "DKK",
          "amount": "3406.25"
        }
      },
      {
        "remittanceInformationStructured": {
          "creditorReferenceInformation": {
            "reference": "0000000000080543106",
            "referenceTypeCode": "SCOR"
          }
        },
        "transactionAmount": {
          "currency": "DKK",
          "amount": "15312.50"
        }
      }
    ],
    "additionalTransactionInformation": "Paying-in forms 89124128 / 71",
    "bankTransactionCode": "PMNT-RCDT-VCOM"
  },
  "next": {
    "href": "/v1/account-transaction-service/accounts/63bd9d0c-67ba-4be6-bccb-f4c20190aa7d/transactions/3B8063BEC1E5856E0S36AFF4B382EDCB108CE952886DE8545E590D9AD2FE16BA?limit=10020&offset=0&languageCode=EN"
  }
}

Balances

The balance endpoint allows you to retrieve both current and historical balances for a specified account. It provides up-to-date information on booked, interest and intra-group balances, ensuring transparency and ease of financial tracking.

With a single request to the /accounts/{accountId}/balances endpoint, all supported balance types are returned. Depending on the account type, different balance types are available.

Balance Types

At present, retrieving balances for Multi-Currency Cash Pool top and folder is not supported. This functionality is planned for a future update and will be made available in due course.

Historical Balances

The endpoint supports retrieving historical balances using the datetime parameter. Five different input formats are supported with strict validation and future timestamp prevention:

• YYYY-MM-DD - Date only (e.g., 2026-02-10)
• HH:mm - Time only (e.g., 14:30)
• HH:mm:ss - Time with seconds (e.g., 14:30:45)
• HH:mm:ss.SSSSSSZ - Time with microseconds (e.g., 14:30:45.123456Z)
• YYYY-MM-DD'T'HH:mm:ss.SSSSSSZ - Full datetime (e.g., 2026-02-10T14:30:45.123456Z)

To retrieve the end-of-day (EOD) balance, provide only the date in YYYY-MM-DD format. The application will automatically return the EOD balance for that date.

All valid inputs are converted to the standard format: YYYY-MM-DD'T'HH:mm:ss.SSSSSS'Z'.

Example Request and Response for Balances

Balances cURL Request

curl -X GET https://api.danskebank.com/corporate/api/v1/account-transaction-service/accounts/63bd9d0c-67ba-4be6-bccb-f4c20190aa7d/balances?datetime=2026-02-10T14:30:45.123456Z \ 
-H "Authorization: Bearer {accessToken}"

Balances Response

{
  "account": {
    "resourceId": "00b23b5a-a7aa-4289-b84b-257ade5b9cc7",
    "iban": "FR7612345987650123456789014",
    "bban": "BARC12345612345678",
    "country": "DK",
    "currency": "DKK"
  },
  "balances": [
    {
      "balanceAmount": {
        "currency": "DKK",
        "amount": "894659.29"
      },
      "balanceType": "interimBooked",
      "referenceDate": "2026-02-10T14:30:45.123456Z"
    },
    {
      "balanceAmount": {
        "currency": "DKK",
        "amount": "894640.20"
      },
      "balanceType": "valueBalance",
      "referenceDate": "2026-02-10T14:30:45.123456Z"
    }
  ]
}

Error Codes

Our API uses standardized HTTP status codes to indicate the success or failure of API requests. Below is a summary of the error codes you may encounter:

A more exhaustive list of HTTP errors can be found within our API specification. Please refer to this documentation for comprehensive information on all possible error responses you may encounter.

The Account Transaction & Balance API will return errors in the following structure:

{
   "exceptionType":"accounts.api.security.exceptions.AuthenticationException",
   "status":"UNAUTHORIZED",
   "details":"Access unauthorized: Access token is not provided."
}