Accounts API

The Accounts API allows Third Party Providers (TPPs) to access account information on behalf of authorized users. This API requires the PSP_AI (Account Information) scope.

Capabilities

List Accounts

Retrieve a list of all accounts accessible to the authenticated user.

GET /accounts

Each account includes:

List Transactions

Retrieve transaction history for a specific account.

GET /accounts/{accountId}/transactions

Query Parameters

Response Structure

The response is a TransactionsResponse wrapper object:

Transaction Properties

Each transaction includes:

Billing amount vs. transaction amount

A transaction carries two amount fields:

• transactionAmount — the amount in the original currency of the payment (e.g., EUR 20 for a purchase at a European shop). Can be null in some special cases for example when the payment was never reserved on the account, such as certain direct settlements.
• billingAmount — the amount that was actually posted to the account, in the currency of the posting. For foreign-currency transactions this is the converted amount after exchange.

When both currencies are the same, the two values will match. When they differ, the currencyExchange object provides the conversion details.

Example: A card payment made for 20 EUR:

{
  "billingAmount": { "amount": -149.0, "currency": "DKK" },
  "transactionAmount": { "amount": -20.0, "currency": "EUR" },
  "currencyExchange": {
    "currency": "EUR",
    "targetCurrency": "DKK",
    "exchangeRate": 7.45
  }
}

Mapping properties for transaction fields

Here is a mapping of our statuses, to codes of the ISO 20022 data table:

Mapping to NextGenPSD2 (Berlin Group) fields:

Lunar uses transactionTime and postingTime as full ISO-8601 timestamps. The NextGenPSD2 spec uses bookingDate, valueDate, and transactionDate as date-only (ISODate) fields. The mapping between them depends on the transaction status:

bookingDate — “The date when an entry is posted to an account on the ASPSP’s books.”

• Maps to postingTime. Both represent when the transaction was recorded on the account.
• null for pending transactions, just as bookingDate is absent for pending entries in NextGen.

valueDate — “The date at which assets become available to the account owner in case of a credit, or cease to be available in case of a debit. If entry status is pending, refers to an expected/requested value date.”

• For settled transactions (financial status): maps to postingTime. Lunar does not distinguish between the booking date and the value date — settlement, booking, and funds availability happen at the same time.
• For future/scheduled transactions (future status): maps to transactionTime, which holds the scheduled execution date — equivalent to the “expected/requested value date” in NextGen.
• For other pending transactions (authorization, interim, initiated): Lunar does not expose an expected value date. There is no direct equivalent.

transactionDate (NextGen card transactions only) — “Date of the actual card transaction.”

• Maps to transactionTime. Both represent when the transaction was initiated (e.g., the moment a card was swiped or a transfer was created).

  Reconciliation guidance:

• Use postingTime for matching against bank statements and cash-flow reconciliation — this is when the account balance actually changed. It corresponds to bookingDate in NextGenPSD2.

• Use transactionTime to determine when the transaction was initiated, e.g., for dispute timelines or user-facing activity logs.

• For pending transactions (authorization, interim, initiated), only transactionTime is available. postingTime is populated once the transaction reaches financial status.

• For future/scheduled transactions, transactionTime represents the expected execution date and can be used as an anticipated settlement date.

Debtor and creditor parties

Transfer-like transactions (domestic credit transfers, international payments, direct debits, bank giro, plus giro, Swish, e-faktura) carry structured debtor and creditor objects. The direction follows the sign of billingAmount:

• Incoming (positive billingAmount) — the counterparty is the debtor (the sender); the account holder is the creditor.
• Outgoing (negative billingAmount) — the account holder is the debtor; the counterparty is the creditor.

All fields on the party object are optional. Consumers must not rely on any particular field being present.

When account is present, both scheme and identification are guaranteed:

Additional schemes may be introduced in the future; consumers should treat unknown values defensively.

When the counterparty’s account identifier is not a bank account (e.g. bank giro, plusgiro, Swish), the account field is omitted and the relevant identifier is surfaced via additionalInformation instead.

Example: An incoming domestic credit transfer of DKK 500:

{
  "billingAmount": { "amount": 500.0, "currency": "DKK" },
  "debtor": {
    "name": "Jane Doe",
    "account": { "scheme": "BBAN", "identification": "12345678901" }
  },
  "creditor": {
    "name": "John Smith",
    "account": { "scheme": "BBAN", "identification": "98765432109" }
  }
}

Example: An outgoing international payment to a Danish IBAN:

{
  "billingAmount": { "amount": -1000.0, "currency": "DKK" },
  "creditor": {
    "name": "Foreign Recipient",
    "account": { "scheme": "IBAN", "identification": "DK1212345678901234" },
    "bic": "BANKDKKKXXX"
  }
}

Account balance after transaction

accountBalanceAfterTransaction carries the booked account balance immediately after a transaction settled, as an Amount object ({ amount, currency }). It is populated for settled transactions and omitted otherwise.

This field aligns with Berlin Group’s balanceAfterTransaction and is useful for reconstructing a running balance from a transaction list without a separate balance call.

Additional information map

additionalInformation is a free-form string-to-string map for identifiers that don’t fit other structured fields. It is omitted when empty. Consumers should treat unrecognized keys as opaque — new keys may be added without a version bump.

Currently emitted keys:

Get Transaction by ID

Retrieve a single transaction by its identifier.

GET /accounts/{accountId}/transactions/{transactionId}

Path Parameters

Headers

Returns a single Transaction object (same structure as in the list endpoint).

Funds Confirmation

Check whether a specific amount is available in an account. This is useful before initiating a payment to ensure it won’t fail due to insufficient funds.

GET /funds-confirmation

Request Body

{
  "accountId": "account-uuid",
  "amount": 100.0,
  "currency": "DKK"
}

Response

{
  "fundsAvailable": true
}

Required Scopes

Error Handling

Each endpoint defines its own set of error responses:

Error responses include an errorCode and message for debugging.