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
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
Customers with an expanded agreement with EVRY: name, national identity number, address, citizenship, country code and close family members
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' \
-u "$CLIENT_ID:$CLIENT_SECRET" \
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() save_to_cache(token) make_api_call(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