Onboard a business (Digital Banking & Cards)

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude
• Connect to Cursor

  Install MCP server on Cursor
• Connect to VS Code

  Install MCP server on VS Code

This guide provides step-by-step instructions for onboarding new business customers for Digital Banking and Cards products using the Solaris API. You will learn which information is mandatory and which endpoints and webhooks to integrate.

Business onboarding overview

Onboarding a business requires creating multiple resources to represent the legal entity and the natural persons associated with it.

Business information

You must manage two distinct streams of data simultaneously:

Business identification

Verification occurs at two levels:

• Legal identification: Solaris verifies the legal entity.
• Video identification: The service provider (IDnow) identifies the natural persons. Note that only persons assigned to specific roles require video identification.

Business entities and roles

The Business Resource

In the API, a business represents the legal entity (the company). The business is the account holder and owner of the funds. A business must have at least one natural person attached to it.

The Person Resource

Natural persons (humans) are represented by person resources. They do not own the account but are authorized to act on behalf of the business.

Roles

You must assign a specific role to every person attached to a business. A single person can hold multiple roles (e.g., a Legal Representative who is also a Beneficial Owner).

The following roles are available:

• Legal Representative: Represents the company legally.
• Ultimate Beneficial Owner (UBO): Owns or controls the company.
• Authorized Person: Authorized to access the account (usually the Legal Representative, but can be others).
• Signee: Restricted role for signing documents or viewing info.

System prerequisites

Before starting the onboarding process, implement the following prerequisites:

1. Technical setup:

Set up your environment and get your authentication keys. For step-by-step instructions, check the Technical setup guide.

2. Legal and compliance screens:

Build the following legal and compliance screens into your sign-up flow. The linked Legal and compliance screens guide contains detailed instructions for each.

The following screens are required to onboard B2B customers for Digital Banking & Cards:

1. Terms and Conditions: Present Solaris's T&Cs and collect the customer's consent.
2. Customer information: Inform the customer about data processing and collect their consent.
3. Business tax declaration: Display the required tax declaration text and collect the business's tax information.
4. FATCA indication: Determine if the business is subject to US tax law (FATCA).
5. Self-declaration as a politically exposed person (PEP): Collect a PEP declaration for all relevant persons. (Only for customers in France, Italy, and Spain)
6. Compliance screen: Display Solaris's compliance disclaimer before starting the identification process.

Record the customer's consent on each screen as a UTC timestamp (e.g., 2019-01-01T00:00:00Z). Afterward, you must pass each timestamp in its respective field to Solaris.

• Collect the customer's consent to Solaris's Terms and Conditions and store the timestamp in the terms_conditions_signed_at field.
• Collect the customer's consent to data processing and store the timestamp in the data_terms_signed_at field.
• Collect the customer's FATCA indication and store it in the fatca_relevant field. Store the timestamp in the fatca_crs_confirmed_at field.

Integration overview

The following diagram outlines the integration process for onboarding business customers. Click on each step to jump to the relevant section.

Sequence diagram

To view a larger version, right-click the image and select "Open in a new tab".

Webhooks

Solaris recommends subscribing to the following webhook events to better automate your processes. For detailed instructions on implementing Solaris webhooks, check the webhooks documentation.

• ACCOUNT_BLOCK
• ACCOUNT_CLOSURE_REQUEST
• ACCOUNT_CLOSURE
• BENEFICIAL_OWNER
• BOOKING
• BUSINESS_CHANGED
• BUSINESS_DELETED
• BUSINESS_SEIZURE_CREATED
• BUSINESS_SEIZURE_DELETED
• BUSINESS_SEIZURE_FULFILLED
• BUSINESS_SEIZURE_UPDATED
• BUSINESS_IDENTIFICATION
• BUSINESS_TAX_IDENTIFICATION_CHANGED
• CARD_LIFECYCLE_EVENT
• CARD_AUTHORIZATION
• CARD_AUTHORIZATION_DECLINE_V2
• CARD_AUTHORIZATION_RESOLUTION
• CARD_FRAUD_CASE_PENDING
• CARD_FRAUD_CASE_TIMEOUT
• IDENTIFICATION
• LEGAL_REPRESENTATIVE
• PERSON_CHANGED
• PERSON_DELETED
• PERSON_SEIZURE_CREATED
• PERSON_SEIZURE_DELETED
• PERSON_SEIZURE_FULFILLED
• PERSON_SEIZURE_UPDATED
• PERSON_MOBILE_NUMBER_CREATED
• PERSON_MOBILE_NUMBER_DELETED
• PERSON_TAX_IDENTIFICATION_CHANGED
• POSTBOX_ITEM_CREATED
• SCA_CHALLENGE

Mandatory features

You must integrate all mandatory features highlighted in the Onboarding requirements guide before going live.

Step 1: Collect business data and create business resource

Collect mandatory data points in your sign-up flow, including timestamps for the business's consent to the legal and compliance screens.

Pass this data to Solaris by creating a business resource.

API reference

For a complete list of endpoints, properties, and examples related to the business resource, visit the following links:

• Business resource API reference:
  • POST Create business
  • GET Retrieve business
  • PATCH Update business

Related webhook events

• BUSINESS_CHANGED
• BUSINESS_DELETED

Create business

This endpoint creates a business resource for your customer. You must collect the following mandatory data points from the customer in your sign-up flow and pass it to Solaris in the request body of this endpoint:

• name
• address
  • line_1
  • line_2
  • postal_code
  • city
  • country
• sector
• legal_form
• nace_code
• foundation_date
• crs_company_type or registration_type
• business_purpose
• tax_information
  • tax_country
  • tax_confirmation
  • registration_issuer: For Germany, it must be preceded by AMTSGERICHT (e.g., AMTSGERICHT Berlin).
  • registration_number
• registration_district
• terms_conditions_signed_at
• data_terms_signed_at
• fatca_relevant
• fatca_crs_confirmed_at

Request URL:

POST /v1/businesses

Click here to view the full API reference.

Automatic data collection (Optional)

Simplify your customers' onboarding process by opting for the automatic data collection feature. With our external service provider, Business Registry, customers can enter the country and company name, and the remaining business data fields will be automatically filled out.

GET Search for business commercial registration

The customer enters the company's name and country on your frontend and you pass this information using the following endpoint to automatically fetch the business' registration_issuer and registration_number:

Request URL:

GET /v1/commercial_registrations/search_by_name?country={{}}&name={{}}

Example response

[
    {
        "name": "EWIV für Unternehmensberatung",
        "registration_number": "HRA 201632",
        "registration_issuer": "AMTSGERICHT Lüneburg"
    }
]

Click here to view the full API reference.

GET Automatic business data collection

Use the following endpoint to automatically retrieve the remaining business details after obtaining the registration_issuer and registration_number from the response of the previous endpoint:

Request URL:

GET /v1/commercial_registrations/find?registration_number={{}}&registration_issuer={{}}

Example response

{
  "name": "FLOOR 13 GmbH",
  "address": {
    "country": "DE",
    "postal_code": "86919",
    "city": "Utting a.Ammersee",
    "line_1": "Seestraße 9",
    "line_2": ""
  },
  "legal_form": "GMBH",
  "tax_country": "DE",
  "registration_number": "HRB 198673",
  "registration_issuer": "AMTSGERICHT MÜNCHEN",
  "registration_date": "2012-05-09",
  "registry_updated_at": "2015-11-17",
  "legal_representatives": [
    {
      "first_name": "Stefan",
      "last_name": "Schneider"
    }
  ],
  "commercial_registry_industry_key": [
      "66.19.0 - Sonstige mit Finanzdienstleistungen verbundene Tätigkeiten",
      "70.10.9 - Sonstige Verwaltung und Führung von Unternehmen und Betrieben",
      "70.22.0 - Unternehmensberatung",
      "73.11.0 - Werbeagenturen"
  ]
}

Click here to view the full API reference.

Foreign companies examples

If the company is not registered in Germany, you can still use this service for companies in other countries. The following examples describe how to find the business registration details for a French company.

GET Search for business commercial registration (France)

Request URL

GET v1/commercial_registrations/search_by_name?name=PARISOL&country=FR

Response

{
  "name": "PARISOL",
  "registration_number": "513 937359",
  "registration_issuer": null
}

GET Automatic business data collection (France)

Request URL

GET  /v1/commercial_registrations/find?registration_number=513937359&country=FR

Response

{
  "name": "PARISOL",
  "address": {
    "country": "FR",
    "postal_code": null,
    "city": "NANTERRE",
    "line_1": "RUE D ARRAS 18",
    "line_2": ""
  },
  "legal_form": null,
  "tax_country": "FR",
  "registration_number": "513 937359",
  "registration_issuer": null,
  "registration_date": "2009-07-27",
  "registry_updated_at": null,
  "legal_representatives": [
    {
      "first_name": "Stefan",
      "last_name": "Schneider"
    }
  ]
}

Step 2: Upload business documents

Create document resources and attach them to the business to verify its identity. These documents are mandatory and vary based on legal form and sector. Refer to the appendix for a list of required documents.

API reference

For a complete list of endpoints, properties, and examples related to the business document resource, visit the following links:

• Business Documents API Reference Documentation:
  • POST Create a business document
  • GET Retrieve a business document
  • GET Download business document
  • PATCH Update a business document
  • DELETE Delete a business document

POST Upload a document

This endpoint uploads a document and links it to the business with the business_id specified in the request URL.

Add the following properties to the request body:

• document_type: The document type. For a list of possible values, see the API reference.
• file: The file to be uploaded.

Request URL

POST /v1/businesses/{business_id}/documents

Click here to view the full API reference

Step 3: Create Legal Representatives

Once the business resource is created, you must create the associated natural persons and assign them roles.

In this step, collect the mandatory data points from the business' legal representative(s) and create a person object for each representative. Then, create a legal_representative resource and link it to the corresponding person object.

What is a legal representative?

Legal representatives can be natural persons (individuals) or legal entities (businesses) appointed by a company to act on its behalf. The legal representative(s) of a company may be, for instance, its general manager(s) or its managing director(s). The names of a business' legal representatives are usually recorded in the company's commercial register.

Legal representatives as legal entities

A business' legal representative can be a legal entity instead of a natural person. For example, the legal representative of a GbR company could be another GmbH or AG company.

In this case, you must do the following:

1. Collect the business data of the legal entity acting as the legal representative and create a business resource for it.
2. The natural persons who are the legal representatives of that legal entity are the ones who must go through the KYC flow.

3.1 Create person resource(s) for each legal representative

Collect the mandatory information for each legal representative and create a person resource.

API reference

For a complete list of endpoints, properties, and examples related to the person resource, visit the following links:

• Person resource API reference
  • POST Create person
  • GET Retrieve a person
  • PATCH Update person

Related webhook events

• PERSON_CHANGED
• PERSON_DELETED

POST Create person (Legal representative)

Call this endpoint to create a person resource for the business' legal representative. You must collect the following mandatory data points in your sign-up flow and pass it to Solaris in the request body of this endpoint:

• salutation
• first_name
• last_name
• address
  • line_1
  • line_2
  • postal_code
  • city
  • state
  • country
• birth_date
• birth_city
• birth_country
• nationality
• mobile_number
• terms_and_conditions_signed_at
• data_terms_signed_at
• fatca_relevant
• fatca_crs_confirmed_at

Request URL:

POST /v1/persons

Click here to view the full API reference

3.2 Create legal representative resource(s)

For each person resource created, create a legal_representative resource linking the person_id.

API reference

For a complete list of endpoints, properties, and examples related to the legal_representative resource, visit the following links:

• Business Legal Representative resource API reference:
  • POST Create a business legal representative
  • GET Index a business legal representatives
  • PATCH Update a business legal representative

Related webhook events

• LEGAL_REPRESENTATIVE

POST Create legal representative

Call this method to create a legal_representative resource on the business and link a person to the business as a legal representative.

Attributes

• type_of_representation: A legal_representative could have a type_of_representation, which indicates whether this legal representative can make decisions alone or jointly with other legal representatives. This attribute is optional. Possible values are ALONE, JOINT, or OTHER.
• power_of_attorney_confirmed_at: In case of JOINT representation, legal representatives need to confirm the power of attorney's timestamp in the power_of_attorney_confirmed_at attribute.

Request URL:

POST /v1/businesses/{business_id}/legal_representatives

Click here to view the full API reference.

Step 4: Create Beneficial Owners

In this step:

• Collect the mandatory data points from the business' beneficial owner(s) and create a person object for each beneficial owner.
• Create a beneficial_owner resource and assign it to its corresponding person object.
• Display the definition of the beneficial owner in your UI.

What is a Beneficial Owner?

The Beneficial Owners (BO) are natural persons who, directly or indirectly, own more than 25% of a company's shares.

According to the German Money Laundering Act (Geldwäschegesetz - GwG), a Beneficial Owner is a natural person who:

• Ultimately owns or controls the business.
• On whose behalf a transaction is ultimately carried out.
• On whose behalf a business relationship is ultimately established.

Beneficial owner legal definition

Ensure that the beneficial owner's full definitions and the checkbox are available to your customers in your sign-up flow.

Full definition in English

The ultimate beneficial owner in the sense of the German Money Laundering Act (Geldwäschegesetz - GwG) is the natural person who ultimately owns or controls the contracting party, or on whose behalf a transaction is ultimately carried out or a business relationship is ultimately established. This particularly includes:

1. In case of legal persons, foundations without legal capacity and, in the case of other companies, any natural person who directly or indirectly holds more than a 25% share of the capital, controls more than 25% of the voting rights or exercises control in any comparable manner (+). Establishing the identity of the beneficial owner can be waived, though, for companies that are listed in an organised market in the EU with in accordance with Sec on 2 para. 5 of the Securities Trading Act or, in case of listed companies from a third country, if they are subject to EU-equivalent transparency requirements regarding voting rights or equivalent international standards;
2. In case of foundations or other legal arrangements with legal capacity (or similar) used to manage or distribute assets or property as trustee (trust management), or through which third parties are instructed with the management or distribution of assets or property, the ultimate beneficial owner is:

• any natural person who is a trustor/settlor, trustee or protector, if applicable
• any natural person who is a member of the board of the foundation,
• any natural person designated as a beneficiary,
• the group of natural persons in whose favour the assets are mainly to be administered or distributed, provided that the natural person who is to be the ultimate beneficial owner of the assets or property has not yet been determined
• any natural person who, by any other means, directly or indirectly exercises control over the asset management or property or the distribution of income.

3. In the event of acting on behalf of another party, the ultimate beneficial owner includes the party upon whose initiative the transaction is performed. If the contracting party acts as a trustee, he also acts on behalf of another party. (+) Indirect control exists particularly if corresponding shares are held by one or more associations pursuant to Sec on 20 para. 1 GwG which are controlled by a natural person. Control exists particularly if the natural person can directly or indirectly exert a controlling influence on the association pursuant to Sec on 20 para. 1 GwG. Sec on 290 para. 2 to 4 German Commercial Code (Handelsgesetzbuch - HGB) applies mutatis mutandis to the existence of a controlling influence. If, after extensive audits have been performed and without the facts according to Sec on 43 para. 1 GwG applying, no natural person has been identified or if there is any doubt that the identified person is the ultimate beneficial owner, the ultimate beneficial owner shall be the legal representative, managing partner or partner of the contracting party.

Full definition in German

Wirtschaftlich Berechtigter im Sinne des Geldwäschegesetzes, ist die natürliche Person, in deren Eigentum oder unter deren Kontrolle der Vertragspartner letztlich steht, oder auf deren Veranlassung eine Transaktion letztlich durchgeführt oder eine Geschäftsbeziehung letztlich begründet wird. Hierzu zählen insbesondere:

1. Bei juristischen Personen, außerrechtsfähigen Stiftungen und bei sonstigen Gesellschaften jede natürliche Person, welche unmittelbar oder mittelbar mehr als 25 Prozent der Kapitalanteile hält, mehr als 25 Prozent der Stimmrechte kontrolliert oder auf vergleichbare Weise Kontrolle ausübt(2). Auf die Abklärung des wirtschaftlich Berechtigten kann aber verzichtet werden bei Gesellschaften, die innerhalb der EU an einem organisierten Markt im Sinne des § 2 Abs. 5 des Wertpapierhandelsgesetzes notiert sind, oder bei börsennotierten Unternehmen aus einem Drittstaat, wenn sie dem Gemeinschaftsrecht entsprechenden Transparenzanforderungen im Hinblick auf Stimmrechtsanteile oder gleichwertigen internationalen Standards unterliegen;
2. Bei rechtsfähigen Stiftungen und Rechtsgestaltungen, mit denen treuhänderisch Vermögen verwaltet oder verteilt oder die Verwaltung oder Verteilung durch Dritte beauftragt wird, oder diesen vergleichbaren Rechtsformen zählt zu den wirtschaftlich Berechtigten:

• jede natürliche Person, die als Treugeber, Verwalter von Trusts (Trustee) oder Protektor, sofern vorhanden,
• jede natürliche Person, die Mitglied des Vorstands der Stiftung ist,
• jede natürliche Person, die als Begünstigte bestimmt worden ist,
• die Gruppe von natürlichen Personen, zu deren Gunsten das Vermögen hauptsächlich verwaltet oder verteilt werden soll, sofern die natürliche Person, die Begünstigte des verwalteten Vermögens werden soll, noch nicht bestimmt ist,
• jede natürliche Person, die auf sonstige Weise unmittelbar oder mittelbar beherrschenden Einfluss auf die Vermögensverwaltung oder Ertragsverteilung ausübt.

3. Bei Handeln auf Veranlassung zählt zu den wirtschaftlich Berechtigten derjenige, auf dessen Veranlassung die Transaktion durchgeführt wird. Soweit der Vertragspartner als Treuhänder handelt, handelt er ebenfalls auf Veranlassung.

4.1 Create person resource(s) for each beneficial owner

Collect the mandatory information for each beneficial owner and create a person resource.

POST Create person (Beneficial owner)

Call this endpoint to create a person resource for the business' beneficial owner. You must collect the following mandatory data points in your sign-up flow and pass it to Solaris in the request body of this endpoint:

• salutation
• first_name
• last_name
• address
  • line_1
  • line_2
  • postal_code
  • city
  • state
  • country
• birth_date
• nationality
• fatca_relevant
• fatca_crs_confirmed_at

Request URL:

POST /v1/persons

Click here to view the full API reference

4.2 Create beneficial owner resource(s)

For each person resource created, create a beneficial_owner resource linking the person_id.

API reference

For a complete list of endpoints, properties, and examples related to the beneficial_owner resource, visit the following links:

• Business Beneficial Owner resource API reference:
  • POST Create a business beneficial owner
  • GET Retrieve a business beneficial owner
  • PATCH Update a business beneficial owner

Related webhook events

• BENEFICIAL_OWNER

POST Create beneficial owner

Call this method to create a beneficial_owner resource on the business and link a person to the business as a beneficial owner. You must add the following properties in the request body of this endpoint:

• person_id: The ID of the person resource you created for the beneficial owner.
• voting_share: The beneficial owner's voting share in the business.

Request URL:

POST /v1/businesses/{business_id}/beneficial_owners

Click here to view the full API reference.

Step 5: Create tax identifications

Collect relevant tax information and create tax identification resources for:

1. The business legal entity.
2. All natural persons associated with the business.

5.1 Business tax identification

Collect tax information for the business entity and create a business tax identification resource.

API reference

For a complete list of endpoints, properties, and examples related to the business tax identification resource, visit the following links:

• Business tax identifications API reference:

  • POST Create business tax identification
  • GET Retrieve business tax identification
  • PATCH Update business tax identification

Related webhook events

• BUSINESS_TAX_IDENTIFICATION_CHANGED

POST Create business tax identification

Call this endpoint to create a business tax identification for the business with the business_id specified in the request URL. Collect the following tax information from the business and pass them to Solaris in the request body:

• number
• country
• primary

If the business has not submitted their TIN to your solution yet (i.e., the value of number is null), then include the following properties in the request:

• reason_no_tin: Possible values are NOT_ASSIGNED_YET, NOT_ASSIGNED_BY_COUNTRY, OTHER.
• reason_description: Applies only if the reason_no_tin is OTHER.
• tax_id_type: (Only for Spain) Possible values are NIE and NIF.

Request URL

POST /v1/businesses/{business_id}/tax_identifications

Click here to view the full API reference.

Business tax declaration

Ensure your UI meets the requirements for collecting tax information as detailed in the Legal and compliance screens guide.

5.2 Person tax identification(s)

Collect tax information from all natural persons linked to the business and create a person tax identification for each.

API reference

For a complete list of endpoints, properties, and examples related to the person tax identification resource, visit the following links:

• Person tax identifications API reference:

  • POST Create person tax identification
  • GET Retrieve person tax identification
  • PATCH Update person tax identification

Related webhook events

• PERSON_TAX_IDENTIFICATION_CHANGED

POST Create person tax identification

Call this endpoint to create a person tax identification for the customer with the person_id specified in the request URL. Collect the following tax information from your customers and pass them to Solaris in the request body:

• number
• country
• primary

If the customer has not submitted their TIN to your solution yet (i.e., the value of number is null), then include the following properties in the request:

• reason_no_tin: Possible values are NOT_ASSIGNED_YET, NOT_ASSIGNED_BY_COUNTRY, OTHER.
• reason_description: Applies only if the reason_no_tin is OTHER.
• tax_id_type: (Only for Spain) Possible values are NIE and NIF.

Request example:

POST /v1/persons/{person_id}/tax_identifications

Click here to view the full API reference.

Tax ID testing data

You can use the following test values for the TIN to test these endpoints on Sandbox:

Compliance disclaimer screen

Before starting identification, your solution must display the Solaris compliance disclaimer and collect the customer's agreement.

Refer to the UI requirements and legal text in the Legal and compliance screens guide.

Step 6: Complete the business identification (BKYC) and due diligence process

In this phase, you must:

1. Trigger Identification: Start the business identification process and ensure all legal representatives complete video identification via IDnow.
2. Manual Video ID: Implement manual video identification endpoints.
3. Compliance Questions: Implement compliance questions endpoints and forward any questions to the legal representatives.
4. Due Diligence: Ensure all natural persons pass customer due diligence (CDD) checks.
5. FATCA: Complete FATCA-related checks.

6.1 Business identification

What is BKYC?

Solaris' BKYC solution uses RESTful APIs to perform a series of identification and compliance checks for business customers.

How does BKYC work?

The business identification consists of two asynchronous processes:

• Legal identification: The Solaris Banking Operations team verifies the completeness and accuracy of the data submitted by the business customer. They ensure that all legal representatives and ultimate beneficial owners are disclosed and linked to the business.
• Video identification: All of the business' legal representatives and authorized persons must undergo a video identification session with IDnow to validate their data against their identification documents.

API reference

For a complete list of endpoints, properties, and examples related to business identification (BKYC), visit the following links:

• Business identification API reference:
  • POST Create business identification
  • GET Retrieve business identification

Related webhook events

• BUSINESS_IDENTIFICATION
• IDENTIFICATION

POST Initiate business identification

Call this endpoint to initiate the business identification process, which automatically triggers both the legal identification of the business and the video identification of applicable natural person(s). Specify the identification method in the request body. The default method is idnow.

Request URL

POST /v1/businesses/{business_id}/identifications

Response

Returns an identification object with a unique id representing the business identification resource and its overall status. Additionally, the payload contains individual identification objects for the video identification sessions of legal representatives, including their respective resource id, IDnow status, reference, and url for completing the process.

The payload also provides information on the legal identification process, including its dedicated legal_identification_status. Monitor the progress of this process by calling the API, particularly the legal_identification_missing_information field, where Solaris highlights compliance questions requiring answers from the business.

Click here to view the full API reference

6.2 Manual video identification

While the initial business identification process automatically triggers video identification for the known legal representatives, you may need to initiate this process manually. This occurs if new legal representatives are discovered during the legal review or if an initial identification attempt fails.

Trigger video identification manually in the following cases:

1. New legal representatives: If the legal review uncovers new representatives, you will receive a LEGAL_REPRESENTATIVE webhook event containing the new legal_representative_id. You must then initiate a video identification with IDnow and redirect the person to the provided URL.
2. Failed attempts: If a video identification fails, you must manually trigger a new identification session.

API reference

• Customer identification (KYC) API reference

Related webhook events

• IDENTIFICATION

Create identification

Call this endpoint to initialize the identification process. You must specify the method (idnow) and the customer's preferred language.

Required fields:

• method: Set to idnow.
• language: EN or DE.
• proof_of_address_type: Required if the ID document does not show the address (e.g., Passport).
• proof_of_address_issued_at: Required if providing a proof of address (must be < 6 months old).

Request example

// POST /v1/persons/{person_id}/identifications
{
  "method": "idnow",
  "language": "DE",
  "proof_of_address_type": "GAS_BILL",
  "proof_of_address_issued_at": "2022-09-21"
}

Response example

Returns an identification object with status created.

{
    "id": "6dc54352d6793a892e0702850d07b831cidt",
    "status": "created",
    "method": "idnow",
    ...
}

Click here to view the full API reference.

Check supported documents

Before redirecting the customer, check which documents are supported for their country. This avoids user frustration if they attempt to use an unsupported ID.

Request URL

GET /v1/persons/{person_id}/identifications/{id}/supported_documents

Click here to view the full API reference

Trigger identification request

Call this endpoint to generate the required tokens and URLs for the IDnow session.

Request URL

PATCH /v1/persons/{person_id}/identifications/{id}/request

Response example

The status changes to pending. The response contains two critical fields depending on your integration type:

• url: Use this for Web integrations (redirect the user here). Valid for 14 days.
• reference: Use this token for Mobile SDK (iOS/Android) integrations.

{
    "id": "6dc54352d6793a892e0702850d07b831cidt",
    "reference": "TST-KCCEY",
    "url": "[https://go.test.idnow.de/solarisbankvideoidentsandbox/identifications/](https://go.test.idnow.de/solarisbankvideoidentsandbox/identifications/)...",
    "status": "pending",
    ...
}

Click here to view the full API reference.

The IDnow session

Once you redirect the customer (Web) or initialize the SDK (Mobile), the IDnow session begins.

1. Consent & Setup: The customer lands on an IDnow-branded page. They must consent to Terms & Conditions and confirm they have a valid ID document ready.
2. Mobile Verification: The customer provides a mobile number. The IDnow agent sends an SMS OTP to this number during the call to verify possession.
3. Video Call: The agent connects via video to verify the customer's face and ID document live.
4. Data Update: If the agent detects missing or incorrect data (e.g., name spelling), they will update the record directly. These changes are automatically reflected in the person resource.

Retrieve identification status

Once the webhook IDENTIFICATION signals success, retrieve the final data.

Use the ?include_documents=true query parameter to download the images of the ID document and the user's face.

Request URL

GET /v1/persons/{person_id}/identifications/{id}

Click here to view the full API reference.

Other utility endpoints

• List IDnow attempts (Audit log of failed/aborted calls)
• Upload additional documents

6.3 Compliance questions

During the legal identification process, Solaris' legal and compliance team may require additional information from your customers, including answers to certain compliance questions and/or additional documents.

How to identify compliance questions and documents?

1. If Solaris needs further clarification during the business identification, you will receive a notification on the BUSINESS_IDENTIFICATION webhook.
2. Call the GET Retrieve a business identification endpoint to retrieve the required details.

Only compliance questions

If Solaris has compliance questions for the business, the field legal_identification_missing_information contains only COMPLIANCE_QUESTIONS. In this case, collect answers from the customer on your frontend. We recommend setting document upload as optional to allow the customer to add supporting documents if needed.

Example payload

{
  "legal_identification_status": "information_required",
  "legal_identification_missing_information": [
    "COMPLIANCE_QUESTIONS"
  ]
}

Both compliance questions & documents

If Solaris requires both answers to compliance questions and documents, the field legal_identification_missing_information contains COMPLIANCE_QUESTIONS and a document_type (e.g., FOUNDATION_DOCUMENT). In this case, collect the answers and the mandatory documents. You must set document upload as mandatory on your frontend and submit the document to Solaris using the POST Create a Business Document endpoint.

Example payload

{
  "legal_identification_status": "information_required",
  "legal_identification_missing_information": [
    "COMPLIANCE_QUESTIONS",
    "FOUNDATION_DOCUMENT"
  ]
}

How to retrieve compliance questions and provide answers?

If the status indicates missing information, follow this flow to resolve it:

To retrieve the questions and submit answers, use the following endpoints:

GET Retrieve compliance questions

To get the compliance questions, call the following endpoint:

Request URL

GET /v1/businesses/{business_id}/identifications/{business_identification_id}/legal_identification/questions

Response example

The API call returns an object that includes the question(s) with a unique ID and the corresponding text. You must redirect these questions to your customers and retrieve their answers as part of your workflow. Provide a dedicated page for answering all questions separately.

{
  "question_id": "ebb463137becc09788dfe21fc066e670qstn",
  "question_text": "Please provide the license for security / guarding services (Bewachungsgewerbe): § 34a GewO",
  "legal_identification_id": "14eb210435e09ab7f6a06c8b9b86ce27lid",
  "business_identification_id": "4c74c804eaea5d2a2d64ef400a27a4d3bid",
  "business_id": "880bbac68a34add190786b9c74f4c82fcbiz",
  "answer_id": null,
  "answer_text": "string",
  "asked_at": "2021-07-16T13:38:06.000Z",
  "answered_at": null
}

Click here to view the full API reference.

Create answers for compliance questions

After receiving the compliance question answers from the customer, call the following endpoint to share them with Solaris. Make a separate API call for each answer.

Request URL

Provide the answer in the request body.

POST /v1/businesses/{business_id}/identifications/{business_identification_id}/legal_identification/questions/{question_id}/answers

Click here to view the full API reference.

PATCH Update business legal identification

Call this method to update the legal identification and mark it as ready to resume the identification process after adding all answers and documents. This endpoint changes the legal_identification_status from information_required to pending.

Request URL

PATCH /v1/businesses/{business_id}/identifications/{id}/legal_identification/mark_as_ready

Click here to view the full API reference.

6.4 Customer due diligence

Solaris conducts risk screening (Customer Due Diligence) on the business, legal representatives, beneficial owners, and authorized persons. Results are returned in the GET person or GET business resources.

All entities must have a green status to proceed. For details, see the Customer Due Diligence guide.

6.5 Screening for FATCA indicia

To comply with the Foreign Account Tax Compliance Act (FATCA), Solaris is required to perform checks to determine whether the customer is subject to US tax law. These checks are in addition to the self-declaration during the Legal and Compliance screen.

To perform the FATCA checks, parse the person and identification resources using the following endpoints:

• GET Retrieve person
• GET Retrieve person identification

Hard criteria

To determine the customer's FATCA relevance, you must screen for the following hard criteria:

• Has the customer provided a US passport as their identification document? Check the legitimation_country attribute on the identification resource.
• Is the customer a citizen of the US? Check the nationality attribute.
• Has the customer provided a residential address in the US, the US Minor Outlying Islands, or the US Virgin Islands? Check the country attribute.
• Was the customer born in the US, the US Minor Outlying Islands, or the US Virgin Islands? Check the birth_country attribute.

When to reject the customer

If any of these hard criteria attributes have the value of US or USA, you must deny banking services to the customer and stop the onboarding process. Failure to screen for these hard FATCA criteria may cause ongoing operational burdens for Solaris customer support.

Soft criteria

To further determine the customer's FATCA relevance, screen for the following soft criteria:

• Has the customer provided a US mobile number? Check the mobile_number attribute. US mobile numbers have a country code of +1.
• Is the customer's only address a PO box or a c/o address? Check the address_line_1 and address_line_2 attributes.

When to reject the customer

• If the answer is "Yes" to any of the soft criteria, ask the customer to clarify their phone number and/or address.
  • If the customer provides a non-US phone number and a physical address, you may onboard them.
• If the customer does not provide a non-US phone number and a physical address, you may not onboard them.

Failure to screen for soft FATCA criteria may cause ongoing operational burdens for Solaris customer support.

Identification statuses

There are three key statuses in the business identification process:

1. Solarisident status: Tracks the overall legal and video identification. Initially created, becomes successful upon completion.
2. Legal identification status: Tracks the verification of the legal entity. Initially created.
3. Video identification status: A unique object for each person. The IDnow status remains pending until the person completes video identification.

See the appendices for status values.

Validity of identification documents (Spain & Italy)

To comply with regulatory requirements, Solaris must keep copies of valid identification documents for active customers in its Italy and Spain branches. This requirement applies to the following customer segments:

• Retail customers
• Freelancers & Sole proprietors
• Businesses' legal representatives
• Authorized persons on a business or a retail account

How will you be notified of the expiry of ID documents?

In Italy and Spain, Solaris stores the expiry date of a customer's identification document and calculates a follow-up date to notify you before it expires. You'll receive a webhook notification on the event POTENTIAL_ACCOUNT_BLOCKING 30 days before the expiry date, and then every 30 days until 90 days after the expiry.

The webhook payload includes the blocking_date, which is the date by which the account will be blocked if the customer has not identified again with a valid ID document, and the reason for the account blocking is set to IDENTIFICATION_DOCUMENT_EXPIRED.

What should you do?

After receiving a notification on the POTENTIAL_ACCOUNT_BLOCKING webhook event, you should take the following steps:

1. Create a new identification resource for the customer and specify the identification method using the POST Create an identification.
2. Request the identification for the customer by calling PATCH Request an identification.
3. Notify the customer that they must complete the KYC flow with their new valid ID document.
4. After successful KYC, Solaris will store the expiry date of the new ID document and calculates a new follow-up date.

If the customer did not identify with a valid ID document within 90 days after the expiry date, the customer's account will be blocked with the reason IDENTIFICATION_DOCUMENT_EXPIRED. If a new ID document is submitted, the account will be unblocked.

Which KYC method to use?

For the re-identification due to expired ID documents, you can choose between the following methods:

• Fourthline
• IDnow AutoIdent

Proceed to the next steps only when:

• The identification status is successful.
• All CDD checks have a green status.
• FATCA screening confirms the customer is not liable for US taxes.

Step 7: Create business account

Present the customer with a button to open their account using the specific formulations below:

English

Order / Open account (subject to a charge)

German

Bestellen / Konto eröffnen (zahlungspflichtig)

(Consult your Onboarding Project Manager if you wish to use different text.)

Account opening and management

• Account opening guide
• Account management guide
• Account management API reference

Step 8: Create authorized person(s)

An authorized person is a natural person who can act on the account and receive authorization challenges (2FA).

• Legal representatives are authorized by default but must be explicitly added as an authorized_person in the system.
• Other persons can be authorized by a legal representative (see Step 10).

API reference

• Business Authorized Persons API reference

POST Create authorized person

Request example:

Add the person_id of the legal representative.

// POST /v1/businesses/{business_id}/accounts/{account_id}/authorized_persons
{
  "authorized_person_id": "3b8cfd40fb4dce5a231251ea06a014cper"
}

Example response:

{
  "id": "568b5241afd0ce435c56ea0efef2bd0dcpea",
  "authorized_person_id": "3b8cfd40fb4dce5a231251ea06a014cper"
}

Step 9: Create and activate card

Once onboarded, you can create a card for the customer. See the Cards Creation and Servicing guide for instructions.

Step 10: Create other optional roles

You can add optional roles based on your use case:

• Additional Authorized Person: A person who is not a legal representative but can act on the account.
• Signee: A person with specific rights (view info, sign documents) but not full authorization power.

Create additional authorized person(s)

In this step, you can add other persons who are not legal representatives as authorized_person on the business account.

Request URL:

POST /v1/businesses/{business_id}/accounts/{account_id}/authorized_persons

Response example:

Returns a URL to authorize the action.

{
  "id": "d6c778822b2d7bd3b778935bcfd0d1d3csc",
  "status": "AUTHORIZATION_REQUIRED",
  "updated_at": "2017-07-15T14:04:35.000Z",
  "url": ":env/v1/change_requests/:id/authorize"
}

POST Authorize adding an additional authorized person

Call the url from the previous response. Specify the person_id of the legal representative authorizing the request.

// POST /v1/change_requests/{change_request_id}/authorize
{
  "person_id":"5af2ea4271038d5c53e68ccbf4fe43b3cper",
  "delivery_method": "mobile_number"
}

This sends a 6-digit OTP to the legal representative's verified mobile number.

POST Confirm adding an additional authorized person

Confirm the request with the OTP (tan).

// POST /v1/change_requests/{change_request_id}/confirm
{
  "person_id":"5af2ea4271038d5c53e68ccbf4fe43b3cper",
  "tan": "123456"
}

Create signee

Signees are optional roles added after successful business identification.

POST Create signee

Assign the signee role to a person linked to the business.

Request URL:

POST /v1/businesses/{business_id}/signees

Click here to view the full API reference.

What's next?

Congratulations! You have successfully onboarded a business, identified the legal representatives, and opened an account.

Critical Next Step: Authentication The Legal Representative cannot log in or authorize payments yet. You must now implement the security framework:

1. Bind a Device: Prompt the Legal Representative to link their smartphone to the user account.
   • Choice: You can implement either the SMS OTP flow or the Activation Code (QR) flow.
   • Requirement: This binding is mandatory for Strong Customer Authentication (SCA).
2. Implement Login & SCA: Set up the flows for logging in and authorizing transactions using the bound device.

Appendix I: Enums

Annual income range

To set the value of annual_income_range, you may offer the customer a drop-down list with the following numeric values for each range:

CRS company type

The field crs_company_type is required to collect mandatory tax information and create the business tax_identification resource. The following table includes the possible values for this field and their descriptions:

Document types

The following table includes the possible values for the field document_type and their descriptions.

NACE code

The Statistical Classification of Economic Activities in the European Community (NACE) is the industry standard classification system used in the European Union.

NACE uses four hierarchical levels:

• Level 1: 21 sections identified by alphabetical letters A to U.
• Level 2: 88 divisions identified by two-digit numerical codes (01 to 99).
• Level 3: 272 groups identified by three-digit numerical codes (01.1 to 99.0).
• Level 4: 629 classes identified by four-digit numerical codes (01.11 to 99.00).

The first four digits (the first four levels) are consistent across all European countries. National implementations may introduce additional levels. The fifth digit might vary by country, and suppliers of databases sometimes add further digits.

Example

If the NACE code A 01.11 (Growing of cereals (except rice), leguminous crops and oil seeds) applies to the business, supply the value as follows:

nace_code = "A 01.11"

Reference List

Visit the Eurostat Reference Data site for the full list of NACE code values required for your implementation. The list is available in multiple languages.

Requirements

• Mandatory: NACE codes are required for B2B and freelancer customers in Germany, Italy, and Spain.
• Excluded: For France, NACE codes are not used. The CODE NAF system is used instead.

Tax country

The following table includes the possible values for the field tax_country.

Sector

The following table includes the possible values for the field sector.

Legal form

The selected value for the field tax_country influences the accepted values for the field legal_form. The following lists show the possible values for legal_form for each tax_country.

Austria (AT)

• AT_SE
• AT_OHG
• AT_KG
• AT_AG
• AT_GESMBH
• AT_EG
• AT_GBR
• AT_EV
• AT_SOLE_PROPRIETORSHIP
• AT_SELF_EMPLOYED
• AT_AMT
• AT_KOR
• AT_STIFTUNGEN
• AT_GMBH
• AT_GMBH_CO_KG

Belgium (BE)

• BE_SNC
• BE_SCS
• BE_SA
• BE_SPRL
• BE_SE
• BE_SCA
• BE_SC
• BE_SCRI
• BE_SEP
• BE_SF
• BE_SPRLU
• BE_SOLE_PROPRIETORSHIP
• BE_SELF_EMPLOYED

Bulgaria (BG)

• BG_AD
• BG_OOD
• BG_KDA
• BG_KD
• BG_SD
• BG_SELF_EMPLOYED
• BG_SOLE_PROPRIETORSHIP

Croatia (HR)

• HR_DD
• HR_DOO
• HR_JDOO
• HR_KD
• HR_JTD
• HR_SELF_EMPLOYED
• HR_SOLE_PROPRIETORSHIP
• HR_ORTA

Czech Republic (CZ)

• CZ_AS
• CZ_SRO
• CZ_KS
• CZ_VOS
• CZ_DRUZSTVO
• CZ_FYZICKA_OSOBA
• CZ_SOLE_PROPRIETORSHIP
• CZ_SELF_EMPLOYED

France (FR)

• FR_AE
• FR_EI
• FR_SNC
• FR_SCS
• FR_SA
• FR_SAS
• FR_SARL
• FR_SE
• FR_SCA
• FR_EURL
• FR_SC
• FR_SCOP
• FR_SELARL
• FR_SOLE_PROPRIETORSHIP
• FR_SELF_EMPLOYED

Germany & Others (Default) Solaris accepts the following legal forms for companies in Germany and other countries not specified in this list:

• AG
• EG
• EK
• EV
• NEV
• GBR
• GMBH
• GMBH_CO_KG
• GMBH_I_GR
• KG
• KGAA
• LTD
• MUNICIPALITY
• MUNICIPAL_COMPANY
• NONE
• OHG
• PARTG
• PRIVATE_PERSON
• SAVINGS_BANK
• SE
• SELF_EMPLOYED
• SOLE_PROPRIETORSHIP
• UG
• UG_I_GR
• FOREIGN_CORPORATION
• ADOR
• AMT
• KDOR
• STIFTUNGEN
• SECOKG
• AGCOKG

Hungary (HU)

• HU_NYRT
• HU_KFT
• HU_BT
• HU_KKT
• HU_SOLE_PROPRIETORSHIP
• HU_SELF_EMPLOYED
• HU_ORTA

Italy (IT)

• IT_SE
• IT_SNC
• IT_SAS
• IT_SPA
• IT_SRL
• IT_SAPA
• IT_SCPA
• IT_SCARL
• IT_SCOP
• IT_SS
• IT_SOLE_PROPRIETORSHIP
• IT_SELF_EMPLOYED

Luxembourg (LU)

• LU_SNC
• LU_SCS
• LU_SA
• LU_SARL
• LU_SE
• LU_SCA
• LU_SCSP
• LU_SARLS
• LU_SC
• LU_SCOP
• LU_SOLE_PROPRIETORSHIP
• LU_SELF_EMPLOYED
• LU_SECA
• LU_ASBL
• LU_FON
• LU_SP

Poland (PL)

• PL_SA
• PL_SPZOO
• PL_SE
• PL_SKA
• PL_SPK
• PL_SPJ
• PL_SELF_EMPLOYED
• PL_OTHER

Portugal (PT)

• PT_SNC
• PT_SC
• PT_SA
• PT_LDA
• PT_SE
• PT_SUNI
• PT_EIRL
• PT_SCIV
• PT_COP
• PT_SOLE_PROPRIETORSHIP
• PT_SELF_EMPLOYED

Romania (RO)

• RO_SA
• RO_SRL
• RO_SCA
• RO_SCS
• RO_SNC
• RO_SELF_EMPLOYED
• RO_SOLE_PROPRIETORSHIP

Serbia (RS)

• RS_AD
• RS_DOO
• RS_KD
• RS_OD
• RS_SELF_EMPLOYED
• RS_SOLE_PROPRIETORSHIP

Slovenia (SI)

• SI_DD
• SI_DOO
• SI_KDD
• SI_KD
• SI_DNO
• SI_SELF_EMPLOYED
• SI_SOLE_PROPRIETORSHIP

Spain (ES)

• ES_SRC
• ES_SC
• ES_SA
• ES_SAS
• ES_SRL
• ES_SE
• ES_SCA
• ES_SLNE
• ES_SAU
• ES_SLU
• ES_SPRO
• ES_SCOP
• ES_SOLE_PROPRIETORSHIP
• ES_SELF_EMPLOYED

Switzerland (CH)

• CH_DE_AG
• CH_FR_SA
• CH_IT_SA
• CH_DE_GMBH
• CH_FR_SARL
• CH_IT_SAGL
• CH_SE
• CH_DE_KOMAG
• CH_FR_SCA
• CH_IT_SACA
• CH_DE_KG
• CH_FR_SCM
• CH_IT_SAC
• CH_DE_KIG
• CH_FR_SNC
• CH_IT_SNC
• CH_DE_EG
• CH_FR_SS
• CH_IT_SS
• CH_SELF_EMPLOYED
• CH_SOLE_PROPRIETORSHIP
• CH_DE_KMG

The Netherlands (NL)

• NL_VOF
• NL_CV
• NL_NV
• NL_BV
• NL_SE
• NL_CVOA
• NL_COPV
• NL_MTS
• NL_SOLE_PROPRIETORSHIP
• NL_SELF_EMPLOYED
• NL_VERENIGING
• NL_STICHT

Turkey (TR)

• TR_ADI_SIR
• TR_AS
• TR_LS
• TR_KOM_STI
• TR_KOLL_STI
• TR_SELF_EMPLOYED
• TR_SOLE_PROPRIETORSHIP

United Kingdom (GB)

• GB_SE
• GB_PARTNERSHIP
• GB_LP
• GB_PLC
• GB_LTD
• GB_COPS
• GB_UAS
• GB_PRCU
• GB_PUCU
• GB_SOLE_PROPRIETORSHIP
• GB_SELF_EMPLOYED

Sector, tax country, and legal form mapping

Dependencies exist between the fields tax_country, sector, and legal_form. The value selected for one field determines the accepted values for the next.

The following sections outline these dependencies.

Tax country and sector mapping

The selected value for the field tax_country influences the accepted values for the field sector. The following table gives an overview about the mapping of values between the field tax_country and sector.

Sector and legal form mapping

The selected value for the field sector influences the accepted values for the field legal_form. The following table gives an overview about the mapping of values between the field sector and legal_form.

IDnow status

The following table includes the possible values for the field status for the video identification process carried out by IDnow and the related description of each status.

IDnow provides a reason whenever the identification has a canceled or aborted status. No reason is disclosed for the final failed status.

Legal identification status

The following table includes the possible values for the field legal_identification_status. This status tracks the progress of the legal checks performed by Solaris on the business entity.

Solarisident status

The following table includes the possible values for the field status, which refers to the overall status of the business identification process (BKYC). This includes the legal identification of the business entity carried out by Solaris and the video identification of the business's natural persons.

Appendix II: BKYC required documents

The following table lists the required documents for identification for each legal form.

Appendix III: Testing samples for GET Search for business commercial registration

The following table includes testing samples for the GET Search for business commercial registration endpoint, including values for the fields country, registration_number, registration_issuer, and name.

Appendix IV: License requirements

The following table lists industries connected with license requirements depending on the services provided by the business customer. Upload the license with document_type as OTHER.

Appendix V: Business Registry offices

Appendix VI: FAQs

Legal Representative FAQs

The company I am about to register is a „Gesellschaft mit beschränkter Haftung“ (GmbH) – who is my legal representative?

The easiest and surest way to figure that out is to check your current register excerpt (Handelsregisterauszug). It lists all the official legal representatives you must submit. As a further indication, these people must also be listed in the Imprint of your website (Impressum).

The Legal Representative has sole representation rights – do I need to add the other legal representatives as well?

Yes. Even though this legal representative could conclude the process on behalf of the company alone in the following steps, Solaris needs the complete set of information for regulatory purposes. Therefore, enter the information for all legal representatives associated with the business.

One of our legal representatives is currently unavailable – do we need to reach them to complete the process?

Yes. All legal representative(s) must be identified in a video identification session to complete the business identification process (BKYC).

Our legal representatives are about to change soon – shall I include the new ones already?

No; submit the information as it is currently written in the official register. If you already know that these individuals will change, inform your Onboarding Manager immediately.

Why do I have to submit all legal representatives here?

As a bank, Solaris must keep a record of the companies it works with and verify the provided information. The law stipulates that Solaris must collect this information for all legal representatives.

Beneficial Owner FAQs

What is a “Beneficial Owner”?

A "Beneficial Owner" is a natural person (an individual) who directly or indirectly owns more than 25% of a legal entity's voting shares. Ultimately, it is the person who benefits from the agreement and holds decision-making power. It can never be another company; Solaris must identify the natural person behind any corporate ownership.

The company has no beneficial owners – how should I proceed?

If a thorough investigation shows that no individual directly or indirectly holds more than 25% of the voting shares, Solaris is required to identify the legal representatives as "fictitious" beneficial owners. Enter their information accordingly.

I don't know the ownership structure of the company – how shall I proceed?

The ownership structure is determined in the shareholder agreement (Gesellschaftsvertrag), signed when founding the entity. Any changes should be noted in amendments or updates to this contract. Consult these documents to verify ownership.

Another company owns the company – what shall I do now?

Submit the information of the natural person (individual) who owns that shareholder company. If the shareholder is also a company (holding or corporate structure), follow the trail of indirect ownership until you find an individual or the ownership is diluted below 25%.

What do you mean by direct or indirectly & how do I calculate that?

Direct ownership: A natural person owns voting shares in the business directly.

Indirect ownership: A person owns an entity that, in turn, owns a part of the business. You must also calculate ownership if entities are stacked (multi-level hierarchy) or if one individual holds shares via multiple entities. To determine the indirect quota, multiply the ownership percentages through each level of the hierarchy. If the total exceeds 25%, that person is a beneficial owner.

Example:

Adello GmbH is the company being identified.

• Shareholders of Adello GmbH:

  • Peter: 30% (Direct BO)
  • Susi: 10%
  • Anne: 10%
  • Toscana GmbH: 50%

• Shareholders of Toscana GmbH:

  • Hugo: 75%
  • Marie: 25%

Resulting Beneficial Owners of Adello GmbH:

• Peter: Yes (Direct owner with >25%)
• Hugo: Yes (Indirect owner). Calculation: 50% (Toscana's share in Adello) x 75% (Hugo's share in Toscana) = 37.5%.
• Marie: No. Calculation: 50% x 25% = 12.5% (Below the 25% threshold).

We have different kinds of shares – which shares are the decisive ones?

Use the shares with voting power, as the beneficial owner is defined by their ability to control the company's decisions.

Does the UBO need to do something, for instance, sign something or perform a video identification?

No. Submit the information exactly as stated in their official documents (ID card or passport). Beneficial owners do not need to perform a video identification or sign documents during this process.