Beneficial ownership identification

Bisnode's new service for identifying beneficial owners presents: 

  • Owners (direct) of companies entered in The Register of Business Enterprises

  • Private individuals who control more than 25% (independent of share ownership)

  • Close relations between owners, private individuals who control more than 25% and combinations of owners and private individuals who own more than 25% between them 

  • Reasons as to why they are considered to be beneficial owners or potential beneficial owners

Why have we made a new service? 

  • New Money Laundering Act in Norway entered into force 15.10.2018

  • Company structures can be complicated and difficult to get an overview of manually

  • Can be challenging to locate and calculate the potential beneficial owners based on control – across ownership, roles and directors – and even more so when close family members are involved

  • There does not exist a national register for beneficial owners in Norway (at present)

  • The present service is no longer compliant as it only lists beneficial owners (direct or indirect), and does not consider the 25%-in-all-levels rule


Key Features



  • Basic information such as organisation number, owners, owner percentage, chairman, board members, managing director and entry date

  • Signatory power and procuration 

  • NACE code/activity code

Private individuals: 

  • Customers with an expanded agreement with EVRY: name, national identity number, address, citizenship, country code and close family members


Refer to Docs for more details

Ready to start?

Get API Key


Test companies with beneficial owners to use in Sandbox

Company name DUNS-no. 
Antilope 912345678
Blåbær 912344745
Uvær 912344737
Væren 912344740


Changes and versioning

API version is provided in the base of the requested URL in the form of "v1", "v2" etc. Only major version numbers are used.

API versions are raised only on breaking (i.e. backwards incompatible) changes in the API. Fields may be added but will never be removed during an API version lifecycle. When developing your application, take care to ensure that your application is able to handle additional fields.



Authentication using OAuth2

Bisnode's latest APIs use OAuth2 for authentication. For all API requests, you need to supply an access token in order to authenticate yourself. To obtain such an access token you need to submit your CLIENT_ID and CLIENT_SECRET to Bisnode's authentication endpoint at https://login.bisnode.com/as/token.oauth2. The access token is then passed along in the Authorization header to all API requests. Follow the instructions below to learn how to do this.


Get and Use the Access Token

Step 1. Get the Access Token

To get an access token you need to make a POST request to https://login.bisnode.com/as/token.oauth2 using the following HTTP header: Content-Type: application/x-www-form-urlencoded and the following request body: grant_type=client_credentials&scope=credit_data_companies. The request must be authenticated using HTTP Basic authentication and your CLIENT_ID and CLIENT_SECRET.

Example in cURL
curl -X POST \
-H "Content-Type: application/x-www-form-urlencoded" \
-d 'grant_type=client_credentials&scope=no_beneficialowner_finance' \

Example response
"access_token": "eyJhb....seAtPCCQ",
"token_type": "Bearer",
"expires_in": 7199

Step 2. Use the Access Token

Supply your access token with all requests to the API using the HTTP Authorization header: Authorization: Bearer <your access token here> You should reuse the access token for multiple calls to the API. See the next section on recommended usage.

Example in cURL - search for Beneficial owners for a company

curl -X GET \
-H "Authorization: Bearer eyJhb...seAtPCCQ" \
-H 'Content-Type: application/json' \

Reusing the Access Token
After you have fetched an access token you should save it and use it for subsequent calls to the API. There is no limit on the number of calls it can be used for, but it will expire after a certain time.

We recommend that you use the expires_in field to determine when to request a new access token. It specifies the number of seconds the token will be valid for. Because of possible delays in network communication as well as delays between checking the timestamp and transmitting the actual API request, it is a good idea to request a new token a few seconds before it is about to expire. This minimizes the risk of accidentally using an expired token.

The following pseudo code illustrates how to use the authentication endpoint together with the API.

function make_authorized_api_request():
    token = get_cached_access_token()
    if token == null or is_soon_to_be_expired(token):
        token = get_new_access_token()

function get_new_access_token():
    token = get_token_from_auth_endpoint()
    token.expiration_timestamp = now().add_seconds(token.expires_in)
    return token

function is_soon_to_be_expired(token):
    # Add time margin to avoid token expiring during call
    if now().add_seconds(60) >= token.expiration_timestamp:
        return true
    return false


API Console

Production Endpoints

Production URLs:

Sandbox Endpoints

Sandbox URLs:

Get Access

Please find the complete reference of the API below. In future releases it will also be possible to try the API out directly from your browser.