This document describes the data model for each endpoint in the DSOP Control Common standard APIs (Customer Relations Overview API and DSOP Control API), both for input parameters and the response. Technical specification of the APIs can be found in the API-specification documentation. The technical specification must be followed when implementing the different endpoints of the APIs that are part of the DSOP Control Common Standard. Documentation describing how data is either exchanged or protected is to be found in the Architecture documentation or in the Security documentation.

Guidelines regarding input-parameter validation criteria as well as which data element are to be delivered for each DSOP Service based on the Common Standard are not described in this document but can be found in each DSOP Service documentation.

Each endpoint in both the Customer Relations Overview and DSOP Control APIs return several fields and subfields. Some fields are mandatory due to technical reasons.

An overview of the relevant endpoints per DSOP Service is presented in the table below. This is according to the legal basis for each DSOP Service.

Description of all input- and output parameters in the APIs

The APIs have both structured and free text fields in each endpoint. Structured fields have a specific purpose and may have legal values (enums) or a specified format. If there is a matching structured field in the API definition, structured information shall be placed there and not in the free text fields. The free text fields are intended for information not fitting into any structured field, for instance free text the data provider has received from the control object issuing the transaction.

See description of all fields in each endpoint below. Some DSOP Services will have to filter the response and only return a limited portion of the fields that are initially available in the common standard.

Customer Relations Overview API

Endpoints Description of data delivery Data model for V.2.0
customerRelationships The endpoint provides all the financial institution where the subject (person or business) has/had a relationship as an account owner or authorized user for a given time period.

Delivery from customerRelationships is a list of financial institutions.

Data delivered per financial institution:
  • name or organisation number
  • role in the financial institution
    		•  Description of customerRelationships V.2.0
    accountServicingProvider The endpoint identifies the financial institution servicing a given account number.
    Delivery from accountServicingProvider is the financial institution servicing the account number.

    Data delivered:
  • name or organisation number of the financial institution
  • information if the account number is a collection account or not
    		•  Description of accountServicingProvider V.2.0

    DSOP Control API

    Endpoints Description of data delivery Data model for V.2.0
    Accounts The endpoint provides all accounts that the subject (person or business) owns or has owned, and, for some DSOP services, accounts for which the subject has been granted authorized user (disponent) rights, for a given time period.

    Delivery from Accounts is a list of accounts.

    Data delivered per account:
  • account number
  • account status
  • which financial institution services the account
  • account owner and when this role started and, if applicable, ended
  • account type
  • account currency
    		•  Description of Accounts V.2.0
    Account details The endpoint provides additional details about an account.

    Delivery from Account Details is:
    • all data from endpoint Accounts and, in addition:
      • current booked and available balance
      • when the account started and, if applicable, ended
    		 Description of Account details V.2.0
    Transactions The endpoint provides all transactions that have been carried out by the subject (as account owner or authorized user) on an account for a given time period.

    Delivery from Transactions is a list of transactions.

    Per account that is provided:
  • transaction ID and reference number
  • transaction status (booked, pending)
  • transaction type and additional transaction information
  • booking date, value date, and execution date and time
  • transaction amount and currency
  • counterparty information (identity, address, etc.)
  • merchant information for card payments
  • exchange rate for transactions in a currency other than NOK
  • masked card identifier for card-based transactions
    		•  Description of Transactions V.2.0
    Cards The endpoint provides all cards that are or have been associated with an account for a given time period.

    Delivery from Cards is a list of cards for the account (applicable if the account has or had cards).

    Per account that is provided:
  • masked card number
  • cardholder’s name
  • card issuer
  • type of card (credit/debit)
  • issuing and expiry dates
  • status (active/blocked) and version number
    		•  Description of Cards V.2.0
    Roles The endpoint provides all roles that are or have been associated with an account for a given time period.

    Delivery from Roles is a list of roles for the account.

    Per account that is provided:
  • name and identifier of the party having a role as account owner or authorized user
  • when the role started and when it ended, if applicable
  • permissions associated with the role
    		•  Description of Roles V.2.0

    Principles for delivery of information via DSOP Control information common standard

    A key principle of the DSOP Control API is that data providers should aim to deliver information for all fields included in the response, unless specified otherwise for a particular DSOP service, regardless of whether the fields are mandatory.

    However, it is crucial to understand the following specification:

    A mandatory field does not always mean that data will be available for it. For instance, if a transaction is a bill payment via an online bank, there will be no information about a payment card associated with this transaction, and thus, no payment card information will be returned.

    Therefore, specific delivery principles have been established for the DSOP Control API to account for these typical scenarios.

    These delivery principles are outlined in the table below:

    Abbreviations Delivery principle Description
    M Mandatory This field must be included in the response, even if the data provider has no data. Omitting this field can cause the receiving API to fail.
    D Deliver Data providers must deliver all requested data if possible*. If the data exists in the provider’s systems and can be delivered through the DSOP Control API, it must be included in the response. However, if the data does not exist or cannot be delivered through the API, the field can be omitted.
    MC Mandatory conditional - Child fields, where the Parent field is marked “M” (Mandatory), are crucial for providing value to the Parent field and must be delivered, even if there is no data. (Refer to the separate description for instructions on how to return empty or no data in fields.) Omitting this field in the response can cause the receiving API to fail.
    - If a parent field marked with “D” is included in the response, the child field marked with “MC” must also be returned if the data exists in the provider’s systems and can be delivered through the DSOP Control API.
    O Optional Only used in input parameters

    * If the data provider cannot deliver all requested data through the Control API but has more data available offline, responseDetails.status must return the value “partial,” and a reason must be provided in responseDetails.message.

    Change log

    Date Change
    16.01.26 Improved specification language for multiple data fields to ensure better interpretability. No behaviour or interface changes. Refer to the linked PDF for details.
    25.02.25 Introduction of a new section “Principles for delivery of information via DSOP Control information common standard” in the document.
    20.03.24 New version of the DSOP Control API generating extensive changes throughout all documentation.
    03.05.23 Added V.1.2, added responseDetails
    17.09.20 Changes from V.1.0 to V.1.1, Version 1.1 approved by “Styringsgruppe Kontrollinformasjon”