# Business credit cards
## Introduction
Integrate Solaris business credit cards to offer charge or revolving cards to business customers and their employees. This guide covers the end-to-end onboarding flow, including business identification (BKYC), credit scoring, and card issuance.
### How does it work?
Using Solaris credit cards, your business customers can offer their employees credit cards. The business acts as the account owner, while employees are cardholders with access to allocated funds.
**Integration highlights:**
* **Contractual Party:** The business and its legal representatives/authorized persons.
* **Identification:** At least six individuals (legal representatives and employees) must be fully identified.
* **Card Types:** Choose between charge and revolving credit cards.
The business and its associated legal representatives and/or authorized persons will be the main contractual party and the one subject to customer identification and vetting. However, six persons (including legal representatives) must be identified to fulfill the legal onboarding requirements. Other employees must be identified if the number of legal representatives is less than six.
**Businesses can apply for a credit card through your solution by doing the following:**
1. Fulfill all legal and compliance requirements.
2. Submit the required business data points and documents.
3. Submit the required data points about legal representatives, beneficial owners, and authorized persons.
4. Pass the credit scoring process.
5. Complete the business identification flow (BKYC).
6. Onboard their employees who will be issued a credit card.
For details on the differences between charge and revolving cards, see [Types of credit cards](/guides/cards/credit-cards#types-of-credit-cards).
This page covers specific integration steps. See the [Credit Cards Overview](/guides/cards/credit-cards) for general product logic.
## System prerequisites
Before starting the onboarding process, implement the following requirements:
### 1. Technical setup
Before starting, ensure your environment is configured for the **Digital Banking** product scope.
* **Authentication:** Retrieve your client credentials and set up your OAuth flow.
* **Webhooks:** Configure your endpoint to receive event notifications (e.g., incoming transfers, status changes).
[View the Technical Setup Guide](/guides/get-started/technical-setup)
### 2. Legal & Compliance screens
You must integrate specific consent screens into your signup flow *before* initiating the API onboarding process.
**Required Screens:**
1. **Terms & Conditions:** Collect explicit consent to Solaris T&Cs.
2. **Customer Information:** verify personal details.
3. **Economic Interest:** Confirm the customer is acting on their own behalf.
4. **Tax Information:** Collect Tax ID (required for Germany).
5. **FATCA/CRS:** Determine US tax liability.
6. **PEP Declaration:** Self-declaration for Politically Exposed Persons (Required for FR, IT, ES).
**Data Storage:**
For every consent screen, you must capture a **UTC timestamp** (e.g., `2023-10-27T10:00:00Z`). These timestamps are mandatory fields when creating the `person` resource.
| Consent Type | API Field (Person Resource) |
| --- | --- |
| Terms & Conditions | `terms_conditions_signed_at` |
| Data Processing | `data_terms_signed_at` |
| Economic Interest | `own_economic_interest_signed_at` |
| FATCA/CRS | `fatca_crs_confirmed_at` |
[View the Legal Screens Guide](/guides/get-started/onboarding-requirements/1-legal-compliance-screens)
* All legal representatives of the business, beneficial owners, and authorized person(s) must consent to FATCA-related fields.
* Only legal representative(s) and authorized person(s) must consent to Solaris' Terms and Conditions and data processing terms fields.
### B2B SDD mandate
You need to create a B2B SDD mandate and collect the customer's signature on it to allow Solaris to charge the business's reference account for credit card repayments each month.
The [SEPA Direct Debit](/guides/digital-banking/sepa-transfers/sepa-direct-debit-transfer/#sdd-mandate) (SDD) mandate is the customer's authorization for Solaris to collect funds from their account in the future.
During your sign-up, you need to collect the IBAN of the reference account from the the customer, and create a B2B SDD mandate and collect the customer's signature on it.
**How to create the SDD mandate?**
You must generate a unique SDD mandate number. The `mandate_number` must contain
35 characters and the first 6 must be a partner-specific string agreed upon by you and Solaris during the implementation phase. The remaining 29 may only contain
the following: [A-Z], [a-z], [0-9].
Additionally, make sure to display the following information to the customer before they sign the mandate:
- Full name (`First_name` + `last_name`)
- IBAN
- Generated mandate reference
- Name of Payee: Solaris SE
- Legal text containing authorization for the mandate
## Integration overview
* This guide includes the onboarding requirements for both charge and revolving cards for businesses in Germany.
* The following integration uses [IDnow video identification](/guides/kyc/videoident) as the identification method. Other identification methods are also possible. Contact your Partner Manager for more information.
The following diagram gives a high-level overview of the integration process for business credit cards.
```mermaid
flowchart TD
%% --- Chart Structure ---
subgraph P1 ["Phase 1: Business Registration"]
A1("Step 1:
Collect Business Data") --> A2("Step 2:
Upload Docs & SDD Mandate")
end
subgraph P2 ["Phase 2: Person Registration"]
A2 --> B1("Step 3:
Register Legal Reps")
B1 --> B2("Step 4:
Register Beneficial Owners")
B2 --> B3("Step 5:
Create Tax Identifications")
end
subgraph P3 ["Phase 3: Application & Identification"]
B3 --> C1("Step 6:
Create CC Application")
C1 --> C2{Scoring
Check}
C2 -->|Pre-Approved| C3("Step 7:
Trigger BKYC &
CDD Checks")
C3 --> C4{BKYC
Successful?}
end
subgraph P4 ["Phase 4: Account & Limits"]
C4 -->|Yes| D1("Step 8:
Finalize Application")
D1 --> D2("Step 9.1:
Create Reference Account")
D2 --> D3("Step 9.2:
Assign Credit Limit")
end
subgraph P5 ["Phase 5: Employee Cards"]
D3 --> E1("Step 10:
Onboard Employees")
E1 --> E2("Step 11:
Create & Activate Cards")
E2 --> E3("Step 12:
Card Servicing")
end
F[Decline / Abort]
%% --- Connections for Failure Cases ---
C2 -->|Declined| F
C4 -->|No| F
%% --- Inline Style Definitions ---
style A1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px
style A2 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px
style B1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px
style B2 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px
style B3 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px
style C1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px
style C2 fill:#dedbd3,color:#1b2230,stroke:#5e6a7a,stroke-width:2px
style C3 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px
style C4 fill:#dedbd3,color:#1b2230,stroke:#5e6a7a,stroke-width:2px
style D1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px
style D2 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px
style D3 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px
style E1 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px
style E2 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px
style E3 fill:#f2f2f2,color:#1b2230,stroke:#c8cdd6,stroke-width:2px
style F fill:#ffc2ad,color:#1b2230,stroke:#5d5746,stroke-width:2px
%% --- Clickable Links ---
click A1 "#step-1-collect-business-data-and-create-business-resource"
click A2 "#step-2-upload-business-documents"
click B1 "#step-3-create-legal-representatives"
click B2 "#step-4-create-beneficial-owners"
click B3 "#step-5-create-tax-identifications"
click C1 "#step-6-create-credit-card-application"
click C3 "#step-7-complete-the-business-identification-bkyc-and-due-diligence-process"
click D1 "#step-8-finalize-credit-card-application"
click D2 "#91-create-reference-account-for-the-business"
click D3 "#92-attach-the-credit-limit-to-the-businesss-credit-card-account"
click E1 "#step-10-onboard-employees"
click E2 "#step-11-create-and-activate-credit-card"
click E3 "#step-12-servicing-credit-cards"
```
br
You can integrate the Solaris business credit card product by completing the 12 steps explained in the following sections.
| Category | Step | Description |
| --- | --- | --- |
| **Business registration** | [Step 1](#step-1-collect-business-data-and-create-business-resource) | Collect the mandatory business data, and create a business resource for your customer. |
| **Business registration** | [Step 2.1](#21-upload-bkyc-required-documents) | Collect the required business documents from the business and pass them to Solaris by creating document resources. |
| **Business registration** | [Step 2.2](#22-upload-the-b2b-sdd-mandate) | Upload the B2B SDD mandate. |
| **Natural persons registration** | [Step 3](#step-3-create-legal-representatives) | **3.1.** Collect the mandatory data from each of the business' legal representatives, including the consent to the legal and regulatory requirements, and [create a person resource](#31-create-person-resources-for-each-legal-representative) for each legal representative. **3.2.** Assign the [legal representative role](#32-create-legal-representative-resources) to each legal representative. |
| **Natural persons registration** | [Step 4](#step-4-create-beneficial-owners) | **4.1.** Collect the mandatory data from each of the business' beneficial owner(s), including the FATCA relevance indication, and [create a person resource](#41-create-person-resources-for-each-beneficial-owner). **4.2.** Assign the [beneficial owner role](#42-create-beneficial-owner-resources) to each beneficial owner. |
| **Tax information** | [Step 5](#step-5-create-tax-identifications) | **5.1.** Collect the mandatory tax information from the business and [create a business tax identification resource](#51-business-tax-identification). **5.2.** Collect the mandatory tax information of the business' legal representative(s), beneficial owner(s) and authorized person(s) and [create person tax identification resource(s)](#52-person-tax-identifications). |
| **Credit card application** | [Step 6](#step-6-create-credit-card-application) | Collect the required data and create a credit card application for the business. Once the application status reaches `PRE_APPROVED`, proceed with the following steps. |
| **Customer identification** | [Step 7](#step-7-complete-the-business-identification-bkyc-and-due-diligence-process) | **7.1.** Trigger the [business identification process (BKYC)](#71-business-identification) for the business and redirect all of the business' legal representative(s) to complete the video identification process with IDnow. **7.2.** Implement the [manual video identification](#72-manual-video-identification) endpoints. **7.3.** Implement the [compliance questions](#73-compliance-questions) endpoints related to the business' legal identification process. Ensure you redirect the questions (if any) to the business' legal representative(s) and provide the answers to Solaris on time. **7.4.** Ensure that all natural person(s) (e.g., legal representatives and beneficial owners) pass the [customer due diligence process](#74-customer-due-diligence) before proceeding with the following steps. **7.5.** Ensure that all natural person(s) (e.g., legal representatives and beneficial owners) pass the [FATCA checks](#75-screening-for-fatca-indicia). |
| **Credit card confirmation & reference account** | [Step 8](#step-8-finalize-credit-card-application) | Finalize the credit card application to trigger the account creation. Once the credit card account is created, add all legal representatives as [authorized person(s)](#add-legal-representatives-as-authorized-persons-on-the-account) on the business account. |
| **Credit card confirmation & reference account** | [Step 9](#step-9-create-reference-account-and-set-credit-card-limit) | **9.1.** Create a [reference account](#91-create-reference-account-for-the-business) for the business. **9.2.** Attach the [credit card limit](#92-attach-the-credit-limit-to-the-businesss-credit-card-account) to the credit card account. |
| **Employee onboarding** | [Step 10](#step-10-onboard-employees) | **10.1.** For each employee who will be issued a credit card, collect the required data and create a [person resource](#101-create-person-resources-for-all-cardholders). **10.2.** Collect and confirm the [mobile number](#102-create-and-verify-mobile-numbers-of-all-cardholders) of each employee who will be issued a credit card. **10.3.** Create and trigger the [identification](#103-identify-employees). |
| **Card creation, activation & servicing** | [Step 11](#step-11-create-and-activate-credit-card) | Create and activate the credit card for all cardholders. |
| **Card creation, activation & servicing** | [Step 12](#step-12-servicing-credit-cards) | Implement all endpoints related to servicing credit cards. |
### Sequence diagram
The following sequence diagram gives an overview of the integration flow:
Diagram: Business credit cards flow
In the following sections, you can find descriptions of these steps and their related endpoints.
### 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](/api-reference/webhooks/).
- [ACCOUNT_BLOCK](/api-reference/onboarding/webhooks/webhook-events/paths/account_block/post)
- [ACCOUNT_CLOSURE_REQUEST](/api-reference/onboarding/webhooks/webhook-events/paths/account_closure/post)
- [ACCOUNT_CLOSURE](/api-reference/onboarding/webhooks/webhook-events/paths/account_closure/post)
- [BENEFICIAL_OWNER](/api-reference/onboarding/webhooks/webhook-events/paths/beneficial_owner/post)
- [BOOKING](/api-reference/onboarding/webhooks/webhook-events/paths/booking/post)
- [BUSINESS_CHANGED](/api-reference/onboarding/webhooks/webhook-events/paths/business_changed/post)
- [BUSINESS_DELETED](/api-reference/onboarding/webhooks/webhook-events/paths/business_deleted/post)
- [BUSINESS_SEIZURE_CREATED](/api-reference/onboarding/webhooks/webhook-events/paths/business_seizure_created/post)
- [BUSINESS_SEIZURE_DELETED](/api-reference/onboarding/webhooks/webhook-events/paths/business_seizure_deleted/post)
- [BUSINESS_SEIZURE_FULFILLED](/api-reference/onboarding/webhooks/webhook-events/paths/business_seizure_fulfilled/post)
- [BUSINESS_SEIZURE_UPDATED](/api-reference/onboarding/webhooks/webhook-events/paths/business_seizure_updated/post)
- [BUSINESS_IDENTIFICATION](/api-reference/onboarding/webhooks/webhook-events/paths/business_identification/post)
- [BUSINESS_TAX_IDENTIFICATION_CHANGED](/api-reference/onboarding/webhooks/webhook-events/paths/business_tax_identification_changed/post)
- [CARD_LIFECYCLE_EVENT](/api-reference/onboarding/webhooks/webhook-events/paths/card_lifecycle_event/post)
- [CARD_AUTHORIZATION](/api-reference/onboarding/webhooks/webhook-events/paths/card_authorization/post)
- [CARD_AUTHORIZATION_DECLINE_V2](/api-reference/onboarding/webhooks/webhook-events/paths/card_authorization_decline_v2/post)
- [CARD_AUTHORIZATION_RESOLUTION](/api-reference/onboarding/webhooks/webhook-events/paths/card_authorization_resolved/post)
- [CARD_FRAUD_CASE_PENDING](/api-reference/onboarding/webhooks/webhook-events/paths/card_fraud_case_pending/post)
- [CARD_FRAUD_CASE_TIMEOUT](/api-reference/onboarding/webhooks/webhook-events/paths/card_fraud_case_timeout/post)
- [IDENTIFICATION](/api-reference/onboarding/webhooks/webhook-events/paths/identification/post)
- [LEGAL_REPRESENTATIVE](/api-reference/onboarding/webhooks/webhook-events/paths/legal_representative/post)
- [PERSON_CHANGED](/api-reference/onboarding/webhooks/webhook-events/paths/person_changed/post)
- [PERSON_DELETED](/api-reference/onboarding/webhooks/webhook-events/paths/person_deleted/post)
- [PERSON_SEIZURE_CREATED](/api-reference/onboarding/webhooks/webhook-events/paths/person_seizure_created/post)
- [PERSON_SEIZURE_DELETED](/api-reference/onboarding/webhooks/webhook-events/paths/person_seizure_deleted/post)
- [PERSON_SEIZURE_FULFILLED](/api-reference/onboarding/webhooks/webhook-events/paths/person_seizure_fulfilled/post)
- [PERSON_SEIZURE_UPDATED](/api-reference/onboarding/webhooks/webhook-events/paths/person_seizure_updated/post)
- [PERSON_MOBILE_NUMBER_CREATED](/api-reference/onboarding/webhooks/webhook-events/paths/person_mobile_number_created/post)
- [PERSON_MOBILE_NUMBER_DELETED](/api-reference/onboarding/webhooks/webhook-events/paths/person_mobile_number_deleted/post)
- [PERSON_TAX_IDENTIFICATION_CHANGED](/api-reference/onboarding/webhooks/webhook-events/paths/person_tax_identification_changed/post)
- [POSTBOX_ITEM_CREATED](/api-reference/onboarding/webhooks/webhook-events/paths/postbox_item_created/post)
- [SCA_CHALLENGE](/api-reference/onboarding/webhooks/webhook-events/paths/sca_challenge/post)
* [CREDIT_CARD_APPLICATION](/api-reference/onboarding/webhooks/webhook-events/paths/credit_card_application/post)
### Mandatory features
You must integrate all the mandatory features for Digital Banking & Cards highlighted in the [Onboarding requirements guide](/guides/get-started/onboarding-requirements/6-mandatory-features) before going live with your solution **except for** Account Closure. Credit cards have their own termination process, which is [described below](#step-13-terminating-credit-cards).
## Step 1: Collect business data and create business resource
Collect the mandatory data points from the customer in your sign-up flow, including all the timestamps of the business's consent to the [legal and compliance screens](#system-prerequisites).
Afterward, pass all the data points to Solaris by creating a business resource to represent your customer.
### API reference
For a complete list of endpoints, properties, and examples related to the `business` resource, visit the following links:
- [Business resource API reference](/api-reference/onboarding/businesses/#tag/Businesses):
- [POST Create business](/api-reference/onboarding/businesses/#tag/Businesses/paths/~1v1~1businesses/post)
- [GET Retrieve business](/api-reference/onboarding/businesses/#tag/Businesses/paths/~1v1~1businesses~1%7Bid%7D/get)
- [PATCH Update business](/api-reference/onboarding/businesses/#tag/Businesses/paths/~1v1~1businesses~1%7Bid%7D/patch)
**Related webhook events**
- [BUSINESS_CHANGED](/api-reference/onboarding/webhooks/webhook-events/paths/business_changed/post)
- [BUSINESS_DELETED](/api-reference/onboarding/webhooks/webhook-events/paths/business_deleted/post)
Important points about data collection
- Review the special considerations for data collection highlighted in the [onboarding requirements guide](/guides/get-started/onboarding-requirements/2-data-collection/#important-considerations-for-data-collection).
- You must submit the information exactly as it appears in official documents.
- When testing in the Sandbox, ensure that each business you create has unique values for `name`, `postal_code`, `legal_form`, and `registration_number` (if provided). If you create over 1000 identical business resources, the API returns a `400` error.
#### POST Create business
Important
- The mandatory data points required for businesses may differ depending on the country in which you're opening the account. The following example outlines the mandatory fields for Germany. For information about other countries, please refer to the [Onboarding requirements guide](/guides/get-started/onboarding-requirements/2-data-collection/#business-customers-b2b)
- There are certain mappings between the fields `tax_country`, `sector`, and `legal_form`. Check this [section](/guides/get-started/onboarding-requirements/2-data-collection/#sector-tax-country-and-legal-form-mapping) for more information.
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**:
```shell
POST /v1/businesses
```
[Click here to view the full API reference.](/api-reference/onboarding/businesses/#tag/Businesses/paths/~1v1~1businesses/post)
### Automatic data collection (Optional)
Simplify your customers' onboarding process by opting for the automatic data collection feature. With our external service provider, [Business Registry](https://www.kompany.com/search), customers can enter the country and company name, and the remaining business data fields will be automatically filled out.
Info
Automated data collection is an optional step that improves user experience. For more information on this feature and its associated cost, contact your Partner Manager.
#### 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`:
Info
This endpoint might be slow in certain markets.
**Request URL:**
```shell
GET /v1/commercial_registrations/search_by_name?country={{}}&name={{}}
```
**Example response**
```json Example Response
[
{
"name": "EWIV für Unternehmensberatung",
"registration_number": "HRA 201632",
"registration_issuer": "AMTSGERICHT Lüneburg"
}
]
```
[Click here to view the full API reference.](/api-reference/onboarding/businesses/#tag/Business-Registrations/paths/~1v1~1commercial_registrations~1search_by_name/get)
#### GET Automatic business data collection
Info
If the previous endpoint cannot retrieve the registration number, you must allow the user to enter it manually.
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:
Important
- **Cost:** This endpoint has an associated cost per request. Contact your Partner Manager for more information.
- **Prefix (Germany):** For companies in Germany, you must add `AMTSGERICHT` before the value of the `registration_issuer` (e.g., `AMTSGERICHT MÜNCHEN`).
- **Registration Number:** You must enter the complete registration number, including the letters at the beginning (e.g., `HRB 12345`). Inputting `12345` alone will not work.
- **Registration Issuer:** For the `registration_issuer`, we expect one of the Business Registry offices from the list available in [Appendix V](/guides/get-started/digital-banking/onboard-business/#appendix-v-business-registry-offices). We cannot accept free input as it breaks automation.
**Request URL**:
```shell
GET /v1/commercial_registrations/find?registration_number={{}}®istration_issuer={{}}
```
**Example response**
```json 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.](/api-reference/onboarding/businesses/#tag/Business-Registrations/paths/~1v1~1commercial_registrations~1find/get)
#### 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.
Info
The field `registration_issuer` is only required for companies in Germany.
**GET Search for business commercial registration (France)**
**Request URL**
```shell
GET v1/commercial_registrations/search_by_name?name=PARISOL&country=FR
```
**Response**
```json Example Response
{
"name": "PARISOL",
"registration_number": "513 937359",
"registration_issuer": null
}
```
**GET Automatic business data collection (France)**
**Request URL**
```shell
GET /v1/commercial_registrations/find?registration_number=513937359&country=FR
```
**Response**
```json Example 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"
}
]
}
```
Check [Appendix III](#appendix-iii-testing-samples-for-get-search-for-business-commercial-registration) for testing data for these endpoints.
## Step 2: Upload business documents
### 2.1 Upload BKYC required documents
The business must submit the required documents for the business identification process (BKYC) in your sign-up flow. The required documents depend on different factors, such as the business's legal form, sector, etc. Check [Appendix II](#appendix-ii-bkyc-required-documents) for a list of required documents per legal form.
Create document resources for all the required documents you've collected from the business and attach them to the business using the following endpoints.
You have to make a separate API request for each document and specify the `document_type`. See [Appendix I](#document-types) for a list of possible values for this field.
### 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](/api-reference/onboarding/businesses/#tag/Business-documents):
- [POST Create a business document](/api-reference/onboarding/businesses/#tag/Business-documents/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1documents/post)
- [GET Retrieve a business document](/api-reference/onboarding/businesses/#tag/Business-documents/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1documents~1%7Bid%7D/get)
- [GET Download business document](/api-reference/onboarding/businesses/#tag/Business-documents/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1documents~1%7Bid%7D~1file/get)
- [PATCH Update a business document](/api-reference/onboarding/businesses/#tag/Business-documents/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1documents~1%7Bid%7D/patch)
- [DELETE Delete a business document](/api-reference/onboarding/businesses/#tag/Business-documents/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1documents~1%7Bid%7D/delete)
#### 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.
Info
The request body of this endpoint is a `multipart/form-data` content type. Parameters are transmitted as form-data, not as a raw JSON string.
**Request URL**
```shell
POST /v1/businesses/{business_id}/documents
```
[Click here to view the full API reference](/api-reference/onboarding/businesses/#tag/Business-documents/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1documents/post)
### 2.2 Upload the B2B SDD mandate
For B2B mandates, you also have to upload the SDD mandate signed by the business in your sign-up flow to Solaris. Call the **POST Create a business document** endpoint to upload the signed mandate and attach it to the business, and set the `document_type` property to `B2B_MANDATE`.
[View Create a business document API](/api-reference/onboarding/businesses/#tag/Business-documents/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1documents/post)
After creating a `business` resource, create the natural person(s) associated with the business and assign them to their respective roles. The natural person(s) are represented in our system by a `person` resource that contains their data, and then you have to assign each person a dedicated role. The mandatory roles are Legal Representative and Ultimate Beneficial Owner.
## Step 3: Create Legal Representative(s)
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.
Important
- A business must have at least one legal representative.
- If a business has more than one legal representative, you must create and link **all of them** to the `business` object in the Solaris system to prevent delays during the business identification process.
#### 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
For each of the business' legal representatives, collect the following mandatory information and pass them to Solaris by creating 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](/api-reference/onboarding/persons/#tag/Persons)
- [POST Create person](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons/post)
- [GET Retrieve a person](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons~1%7Bid%7D/get)
- [PATCH Update person](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons~1%7Bid%7D/patch)
**Related webhook events**
- [`PERSON_CHANGED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_changed/post)
- [`PERSON_DELETED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_deleted/post)
Important points about data collection
- Review the special requirements in the [Onboarding requirements guide](/guides/get-started/onboarding-requirements/2-data-collection/#important-considerations-for-data-collection).
- Submit information exactly as it appears in official documents.
- **Sandbox Testing:** Ensure that each person you create has unique values for `first_name`, `last_name`, `birth_city`, and `birth_date`. If you create over 1000 identical person resources, the API will return a `400` error.
- **Privacy:** Do not use real personal data when testing in Sandbox.
#### POST Create person (Legal representative)
Important points
- The mandatory data points for legal representatives depend on the country in which you're opening the account. The following example shows the mandatory data points for **Germany**. For other countries, check the [Onboarding requirements guide](/guides/get-started/onboarding-requirements/2-data-collection/#legal-representatives)
- You have to create a separate `person` object for each legal representative associated with the business.
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:**
```shell
POST /v1/persons
```
[Click here to view the full API reference](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons/post)
### 3.2 Create legal representative resource(s)
For each person resource you created in the previous step, create a `legal_representative` resource, and set the value of the `legal_representative` attribute to its associated `person_id`.
IMPORTANT
Solaris currently supports **only** legal representatives with the `type_of_representation` set to `ALONE`.
#### POST Create legal representative
### 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](/api-reference/onboarding/businesses/#tag/Business-legal-representatives):
- [POST Create a business legal representative](/api-reference/onboarding/businesses/#tag/Business-legal-representatives/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1legal_representatives/post)
- [GET Index a business legal representatives](/api-reference/onboarding/businesses/#tag/Business-legal-representatives/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1legal_representatives/get)
- [PATCH Update a business legal representative](/api-reference/onboarding/businesses/#tag/Business-legal-representatives/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1legal_representatives~1%7Bid%7D/patch)
**Related webhook events**
- [LEGAL_REPRESENTATIVE](/api-reference/onboarding/webhooks/webhook-events/paths/legal_representative/post)
#### 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:**
```shell
POST /v1/businesses/{business_id}/legal_representatives
```
[Click here to view the full API reference.](/api-reference/onboarding/businesses/#tag/Business-legal-representatives/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1legal_representatives/post)
Check the [Legal Representative FAQs](#legal-representative-faqs) for more information.
## Step 4: Create Beneficial Owner(s)
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.
Important
- If a business has more than one beneficial owner, you must create and link **all of them** to the corresponding `business` object to avoid delays during the business identification process.
- A beneficial owner MUST be a natural person and CANNOT be another company.
### 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.
Important
- The beneficial owner **must** be a **natural** person (individual) and not a legal entity (company). If your business is owned by another company (holding or corporate structure), you need to follow the trail of indirect ownership until you find an individual.
- After a thorough investigation, if no individual owns directly or indirectly more than 25% of the company's voting shares, you must add the legal representative(s) as `fictitious` beneficial owners.
- Beneficial owners don't require video identification.
- For more information about beneficial owners, check the FAQ in the appendices section.
### 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.
1. 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.
1. 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
For each of the business' beneficial owners, collect the following mandatory information and pass them to Solaris by creating a person resource.
#### POST Create person (Beneficial owner)
Important points
- The mandatory data points for beneficial owners depend on the country in which you're opening the account. The following example shows the mandatory data points for **Germany**. For other countries, check the [Onboarding requirements guide](/guides/get-started/onboarding-requirements/2-data-collection/#beneficial-owners)
- You have to create a separate `person` object for each beneficial owner associated with the business.
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:**
```shell
POST /v1/persons
```
[Click here to view the full API reference](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons/post)
### 4.2 Create beneficial owner resource(s)
For each person resource you created in the previous step, create a `beneficial_owner` resource, and set the value of the `person_id` attribute to the `id` of the associated person resource.
#### POST Create beneficial owner
### 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](/api-reference/onboarding/businesses/#tag/Beneficial-Owners):
- [POST Create a business beneficial owner](/api-reference/onboarding/businesses/#tag/Beneficial-Owners/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1beneficial_owners/post)
- [GET Retrieve a business beneficial owner](/api-reference/onboarding/businesses/#tag/Beneficial-Owners/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1beneficial_owners~1%7Bid%7D/get)
- [PATCH Update a business beneficial owner](/api-reference/onboarding/businesses/#tag/Beneficial-Owners/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1beneficial_owners~1%7Bid%7D/patch)
**Related webhook events**
- [BENEFICIAL_OWNER](/api-reference/onboarding/webhooks/webhook-events/paths/beneficial_owner/post)
#### 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.
Info
Please note is that if you're creating a fictitious beneficial owner, the `voting_share` is not required.
**Request URL:**
```shell
POST /v1/businesses/{business_id}/beneficial_owners
```
[Click here to view the full API reference.](/api-reference/onboarding/businesses/#tag/Beneficial-Owners/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1beneficial_owners/post)
Check the [Beneficial Owner FAQs](#beneficial-owner-faqs) for more information.
## Step 5: Create tax identifications
In this step, you must do the following:
* Collect the mandatory tax information of the business' legal entity and create a business tax identification resource.
* Collect the mandatory tax information of the natural person(s) associated with the business and create person tax identification resource(s).
Important points about tax information
Submitting the tax information of your customers is a requirement to open a bank account in all of Solaris branches. However, note the following:
* You can open the bank account for customers in Germany (DE branch) before they provide tax information. However, you must submit the customer's tax information to Solaris within **90 days** of opening the account. Otherwise, Solaris will block the customer's account with the reason `MISSING_TAX_INFORMATION` until you submit the required tax information.
* If a customer has multiple tax residencies (i.e., taxable in multiple countries), you must create a separate tax identification resource for each tax residency and specify **only** one of them as `primary`.
* The first `tax_identification` to be submitted for a `person` or a `business` must be the primary tax identification. If another `tax_identification` with the value of `primary` set to `true` is created, it will set the `primary` value of the previously created `tax_identification` to `false`.
* A `person` or `business` may only have one `tax_identification` per `country`.
* When creating a `tax_identification`, explicitly collect the `country` value from the user and do not default to their physical residence (i.e., the `country` property of the `person` resource).
* Check the [Onboarding requirements guide](/guides/get-started/onboarding-requirements/3-tax-information#tax-identification-number-tin-per-country) for more information about the TIN requirements per country.
### 5.1 Business tax identification
First, you must collect the tax information about the business' legal entity and pass it to Solaris by creating 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](/api-reference/onboarding/businesses/#tag/Business-tax-identifications):
- [POST Create business tax identification](/api-reference/onboarding/businesses/#tag/Business-tax-identifications/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1tax_identifications/post)
- [GET Retrieve business tax identification ](/api-reference/onboarding/businesses/#tag/Business-tax-identifications/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1tax_identifications~1%7Bid%7D/get)
- [PATCH Update business tax identification ](/api-reference/onboarding/businesses/#tag/Business-tax-identifications/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1tax_identifications~1%7Bid%7D/patch)
**Related webhook events**
- [BUSINESS_TAX_IDENTIFICATION_CHANGED](/api-reference/onboarding/webhooks/webhook-events/paths/business_tax_identification_changed/post)
#### 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**
```shell
POST /v1/businesses/{business_id}/tax_identifications
```
[Click here to view the full API reference.](/api-reference/onboarding/businesses/#tag/Business-tax-identifications/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1tax_identifications/post)
#### Business tax declaration
Note the UI requirements and tax declaration text for collecting the tax information from business customers as explained in the [Legal and compliance screens guide](/guides/get-started/onboarding-requirements/1-legal-compliance-screens#business-tax-information).
### 5.2 Person tax identification(s)
In this step, you must collect additional tax information from the natural person(s) linked to the business and create a person tax identification for each.
Important
This is a mandatory requirement for businesses in **all branches.** In this case, you have to collect the tax information and create a `person` tax identification for all natural persons associated with the business, such as **legal representatives,** **beneficial owners,** and **authorized persons.**
### 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](/api-reference/onboarding/persons/#tag/Person-tax-identifications):
- [POST Create person tax identification](/api-reference/onboarding/persons/#tag/Person-tax-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1tax_identifications/post)
- [GET Retrieve person tax identification ](/api-reference/onboarding/persons/#tag/Person-tax-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1tax_identifications~1%7Bid%7D/get)
- [PATCH Update person tax identification ](/api-reference/onboarding/persons/#tag/Person-tax-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1tax_identifications~1%7Bid%7D/patch)
**Related webhook events**
- [PERSON_TAX_IDENTIFICATION_CHANGED](/api-reference/onboarding/webhooks/webhook-events/paths/person_tax_identification_changed/post)
#### 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:**
```shell
POST /v1/persons/{person_id}/tax_identifications
```
[Click here to view the full API reference.](/api-reference/onboarding/persons/#tag/Person-tax-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1tax_identifications/post)
## Step 6: Create credit card application
In this step, collect additional information from the business related to the credit card application and pass it to Solaris using the following endpoint.
### POST Create credit card application for a business
This endpoint creates a credit card application and assigns it to the business with the `business_id` specified in the request URL. The application includes all the required information about the business, such as financial information, credit card type, and requested limit, which Solaris' credit scorer uses to initiate a series of credit checks.
The following fields are just an indication. Solaris will share the mandatory fields based on your banking use case.
**Mandatory fields**
Add the following mandatory properties in the request body:
* `product_type`: Credit card type. For businesses, choose `BUSINESS_CREDIT_CARD`.
* `repayment_options`: An object containing the repayment options of the credit card.
* `upcoming_type`: The type of credit card (e.g., revolving or charge card). Options are `FULL` or `PARTIAL`.
* `minimum_amount`: Minimum amount of the used limit to be repaid at the end of each billing cycle. Only relevant in case `upcoming_type` is set to `PARTIAL`.
* `minimum_percentage`: Minimum percentage of the used limit to be repaid at the end of each billing cycle. Only relevant in case `upcoming_type` is set to `PARTIAL`.
* `scoring_options`: An object containing different fields relevant for the credit scoring process:
* `customer_desired_limit`: The credit card limit requested by the customer, subject to the scorer's decision.
* `other_credit_credit_limit`: If the customer has existing credit cards, include the granted limit in this field.
* `total_assets`: The business' total assets.
* `total_equity`: The business' total equities.
* `annual_turnover`: The business' annual turnover amount.
* `partner_recommended_limit`: Your recommended limit for the business applying for credit cards.
* `partner_pd_rate`: The business' probability of default (PD) rate as calculated by your internal scoring system.
* `partner_score`: The business' credit score as calculated by your internal scoring system.
**Request example**
```json
// POST /v1/businesses/{business_id}/credit_card_applications
{
"product_type": "BUSINESS_CREDIT_CARD",
"repayment_options": {
"upcoming_type": "PARTIAL",
"upcoming_billing_cycle": "MONTHLY",
"minimum_amount": {
"value": 1000,
"unit": "cents",
"currency": "EUR"
},
"minimum_percentage": 3
},
"scoring_options": {
"customer_desired_limit": {
"value": 10000,
"unit": "cents",
"currency": "EUR"
},
"other_credit_card_limit": {
"value": 1000,
"unit": "cents",
"currency": "EUR"
},
"total_assets": {
"value": 10000,
"unit": "cents",
"currency": "EUR"
},
"total_equity": {
"value": 10000,
"unit": "cents",
"currency": "EUR"
},
"annual_turnover": {
"value": 10000,
"unit": "cents",
"currency": "EUR"
},
"partner_recommended_limit": {
"value": 10000,
"unit": "cents",
"currency": "EUR"
},
"partner_pd_rate": 0,
"partner_score": 0
}
}
```
The API call returns an object with a unique id (the `application_id`), including the application `status` (initially set to `PENDING`) and the remaining attributes, which will be populated during the application lifecycle.
Additionally, the call automatically triggers Solaris' credit scoring system, which scores the application and provides its decision on the credit card application, including the limit.
[View full API reference](/api-reference/digital-banking/credit-cards/#tag/Credit-cards/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1credit_card_applications/post)
### GET Retrieve credit card application
This endpoint returns the current status and details of an existing credit card application. For a list of possible values of the application status and their descriptions, check the appendix.
Additionally, subscribe to the webhook event `CREDIT_CARD_APPLICATION` to receive status updates on the application.
**Request URL**
```shell
GET /v1/credit_card_applications/{id}
```
[Click here to view the full API reference.](/api-reference/digital-banking/credit-cards/#tag/Credit-cards/paths/~1v1~1credit_card_applications~1%7Bid%7D/get)
### Application status flow
The following diagram shows the different statuses and transitions for a credit card application:
Diagram: Credit card application status
## Step 7: Complete the business identification (BKYC) and due diligence process
In this step, you must do the following:
1. Trigger the [business identification](#71-business-identification) process to identify the business legal entity and all legal representative(s), and make sure all legal representative(s) are successfully identified via IDnow.
2. Implement the [manual video identification](#72-manual-video-identification) endpoints.
3. Implement the endpoints related to [compliance questions](#73-compliance-questions), forward any questions (if any) to the business' legal representatives, and send the answers back to Solaris.
4. Make sure all natural persons linked to the business successfully passed the [customer due diligence](#74-customer-due-diligence) checks.
5. Complete the [FATCA-related checks](#75-screening-for-fatca-indicia) to ensure that all natural persons linked to the business are NOT FATCA-relevant.
* At least 6 employees (this number includes also legal representatives) related to the business must be fully identified using video identification to fulfill the minimum legal requirements.
* If the number of legal representatives identified in the context of business onboarding is less than 6, the business must identify other employees.
### 7.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.
Important
* The business must pass **both** of these checks before the business identification process is successful.
* Only legal representatives and authorized persons must undergo video identification. Ultimate beneficial owners (UBOs) are **exempt** from this requirement.
**API reference**
For a complete list of endpoints, properties, and examples related to business identification (BKYC), visit the following links:
- [Business identification API reference](/api-reference/identity/identifications/#tag/Business-identifications):
- [POST Create business identification](/api-reference/identity/identifications/#tag/Business-identifications/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1identifications/post)
- [GET Retrieve business identification](/api-reference/identity/identifications/#tag/Business-identifications/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1identifications~1%7Bbusiness_identification_id%7D/get)
**Related webhook events**
- [BUSINESS_IDENTIFICATION](/api-reference/onboarding/webhooks/webhook-events/paths/business_identification/post)
- [IDENTIFICATION](/api-reference/onboarding/webhooks/webhook-events/paths/identification/post)
#### 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**
```shell
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](/api-reference/identity/identifications/#tag/Business-identifications/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1identifications/post)
### 7.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`](/api-reference/onboarding/webhooks/webhook-events/paths/legal_representative/post) 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](/api-reference/identity/identifications)
Prerequisites
- This guide focuses on video identification with **IDnow**.
- Ensure you have completed the [IDnow technical prerequisites](/guides/kyc/videoident/#idnow-integration) (e.g., mobile SDKs or web redirects).
**Related webhook events**
- [`IDENTIFICATION`](/api-reference/onboarding/webhooks/webhook-events/paths/identification/post)
### 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).
Creating the resource does **not** start the video call. You must trigger it in the next step.
**Request example**
```json
// 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`.
```json
{
"id": "6dc54352d6793a892e0702850d07b831cidt",
"status": "created",
"method": "idnow",
...
}
```
[Click here to view the full API reference](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications/post).
Custom Flows
The method `idnow_custom` allows for a customized IDnow flow. If you are interested in offering this to your customers, contact your Partner Manager.
### 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**
```shell
GET /v1/persons/{person_id}/identifications/{id}/supported_documents
```
[Click here to view the full API reference](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D~1supported_documents/get)
### Trigger identification request
Call this endpoint to generate the required tokens and URLs for the IDnow session.
**Request URL**
```shell
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.
```json
{
"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](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D~1request/patch).
### The IDnow session
```mermaid
flowchart LR
A[Start] --> B{Integration Type?}
B -- Web --> C[Redirect User to 'url']
B -- Mobile SDK --> D[Init SDK with 'reference']
C --> E[IDnow Session]
D --> E
E --> F{Outcome}
F -- Success --> G[Webhook: IDENTIFICATION]
F -- Failure --> H[Retry / Abort]
```
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**
```shell
GET /v1/persons/{person_id}/identifications/{id}
```
[Click here to view the full API reference](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D/get).
### Other utility endpoints
- [List IDnow attempts](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D~1idnow_attempts/get) (Audit log of failed/aborted calls)
- [Upload additional documents](/api-reference/onboarding/persons/#tag/Person-documents/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D~1document_upload/post)
### 7.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`](/api-reference/onboarding/webhooks/webhook-events/paths/business_identification/post) webhook.
2. Call the [GET Retrieve a business identification](/api-reference/identity/identifications/#tag/Business-identifications/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1identifications~1%7Bbusiness_identification_id%7D/get) 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**
```json
{
"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](/api-reference/onboarding/businesses/#tag/Business-documents/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1documents/post).
**Example payload**
```json 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:
```mermaid
stateDiagram-v2
direction LR
[*] --> information_required: Legal Review Paused
state "Resolution Loop" as Resolution {
information_required --> FetchQuestions: GET /questions
FetchQuestions --> SubmitAnswer: POST /answers
SubmitAnswer --> SubmitAnswer: Repeat for all questions
}
SubmitAnswer --> pending: PATCH /mark_as_ready
pending --> [*]: Legal Review Resumes
```
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**
```shell
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.
```json Example Payload
{
"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](/api-reference/identity/identifications/#tag/Business-identifications/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1identifications~1%7Bbusiness_identification_id%7D~1legal_identification~1questions/get).
#### 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.
```shell
POST /v1/businesses/{business_id}/identifications/{business_identification_id}/legal_identification/questions/{question_id}/answers
```
[Click here to view the full API reference](/api-reference/identity/identifications/#tag/Business-identifications/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1identifications~1%7Bbusiness_identification_id%7D~1legal_identification~1questions~1%7Bquestion_id%7D~1answers/post).
#### 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**
```shell
PATCH /v1/businesses/{business_id}/identifications/{id}/legal_identification/mark_as_ready
```
[Click here to view the full API reference](/api-reference/identity/identifications/#tag/Business-identifications/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1identifications~1%7Bbusiness_identification_id%7D~1legal_identification~1mark_as_ready/patch).
### 7.4 Customer due diligence
Solaris conducts risk screening and customer vetting checks, known as the Customer Due Diligence process, on the business legal entity, all legal representatives, all beneficial owners, and any other authorized persons on the business account. Results for each entity are returned in the **GET person** or **GET business** resources.
All entities must have a `green` status in their risk screening fields for the business to be onboarded. For more information, check the [Customer Due Diligence guide](/guides/kyc/cdd).
### 7.5 Screening for FATCA indicia
To comply with the [Foreign Account Tax Compliance Act (FATCA)](https://www.irs.gov/businesses/corporations/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](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons~1%7Bid%7D/get)
- [GET Retrieve person identification](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D/get)
#### 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.
Important
Note that Solaris periodically checks FATCA relevance for existing customers. If a customer's FATCA relevance changes to `true`, Solaris's Customer Support team will provide further instructions.
You can only proceed to the next steps when:
* The identification status reaches `successful`.
* All screening and risk checks in the CDD process have a green status.
* The FATCA screening is completed to confirm the customer is not liable for taxes in the United States.
## Step 8: Finalize credit card application
After successful customer identification process, finalize the credit card application by calling the following endpoint:
### POST Finalize credit card application
Call this endpoint to finalize the credit card application. This API call triggers the creation of the credit card account by Solaris. The API response will return the account ID and IBAN and the application status changes to `FINALIZED`. Additionally, the billing cycle start and end date will be automatically calculated.
**Request URL**
```shell
POST /v1/credit_card_applications/{id}/finalize
```
[Click here to view the full API reference.](/api-reference/digital-banking/credit-cards/#tag/Credit-cards/paths/~1v1~1credit_card_applications~1%7Bid%7D~1finalize/post)
### Credit card account
The account ID and IBAN returned in the payload of the previous call is the account associated with the credit card to which the credit card limit will be attached.
- For business and freelancer credit cards, the business or the freelancer will be the account holder and the approved credit card limit will be attached to this account. Afterward, the business or freelancer can request credit cards for their employees and attach spending limits to the cards. In this case, the employee is only a cardholder who can access and use the funds allocated to them through the usage of their issued credit card.
- Please note that a credit card account is a restricted account. Check the [credit card usage](/guides/cards/credit-cards/#credit-card-usage) section to know about allowed transactions.
Check the [account management guide](/guides/digital-banking/account-management/) to find details about how to manage and service accounts.
### Add legal representatives as authorized persons on the account
After the credit card account is created by Solaris, you must explicitly add the legal representatives as authorized persons on the account.
An authorized person is a natural person who can act on the account and receive authorization challenges on their verified mobile number. Legal representatives are by default authorized to act on the business's account. However, they must be explicitly set as `authorized_person` on our system. Other persons can also be authorized by a legal representative, provided their `type_of_representation` is set to `ALONE` or `null`.
[View Business Authorized Persons API reference](/api-reference/onboarding/businesses/#tag/Authorized-persons)
#### POST Create authorized person
Legal representatives can be added as `authorized_person` without authorization. However, to assign other natural person(s) who are not legal representatives as authorized persons on the business account, any legal representative with `type_of_representation` set to `ALONE` or `null` must approve the action by confirming the request via 2FA.
**Request example:**
You must add the `person_id` of the legal representative(s) who will act as an authorized person on the account in the request body.
```json
// POST /v1/businesses/{business_id}/accounts/{account_id}/authorized_persons
{
"authorized_person_id": "3b8cfd40fb4dce5a231251ea06a014cper"
}
```
**Example response:**
```json
{
"id": "568b5241afd0ce435c56ea0efef2bd0dcpea",
"authorized_person_id": "3b8cfd40fb4dce5a231251ea06a014cper"
}
```
[View full API reference](/api-reference/onboarding/businesses/#tag/Authorized-persons/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1accounts~1%7Baccount_id%7D~1authorized_persons/post)
In case of additional authorized persons who are not legal representatives, you must first create a person resource for each authorized person, ensuring the following attributes of the `person` resource are populated:
* `address_line_1` (street)
* `birth_city`
* `birth_date`
* `country`
* `first_name`
* `last_name`
* `nationality`
* `salutation`
## Step 9: Create reference account and set credit card limit
In this step, you must create a reference account for the business and set the credit card limit on the business' account.
### 9.1 Create reference account for the business
**API reference**
* [View Reference accounts resource API reference](/api-reference/digital-banking/account-management/#tag/Reference-accounts)
* [View POST Create a reference account for a business](/api-reference/digital-banking/account-management/#tag/Reference-accounts/paths/~1v1~1persons~1%7Bperson_id%7D~1accounts~1%7Baccount_id%7D~1reference_accounts/post)
* [View GET Index reference accounts for a business](/api-reference/digital-banking/account-management/#tag/Reference-accounts/paths/~1v1~1persons~1%7Bperson_id%7D~1accounts~1%7Baccount_id%7D~1reference_accounts/get)
#### POST Create business reference account
After creating the SDD mandate, you must create a reference account resource for the business and link it to the internal account. You must add the customer's `business_id` and `account_id` in the request URL. You must add the external account details and the signed mandate information in the request body.
You must include the following properties in the request body:
* `name`: The customer's name on their external bank account.
* `iban`: The IBAN of the external bank account from which the SDD will be debited.
* `mandate_number`: The number of the SDD mandate the customer signed.
* `mandate_signature_date`: The date when the customer signed the SDD mandate.
* `mandate_type`: Select `B2B`.
**Request URL**
```json
// POST /v1/businesses/{business_id}/accounts/{account_id}/reference_accounts
{
"name": "Account holder name",
"iban": "DE32110101001000000029",
"mandate_number": "SAMPAY7D226d32882d11Eb8DcD0242Ae2F4",
"mandate_signature_date": "2022-04-20",
"mandate_type": "B2B"
}
```
The API call returns an object with a unique ID, which is the reference account ID. The `status` field refers to the reference account's status. Possible values are `ACTIVE` and `INACTIVE`.
[View full API reference](/api-reference/digital-banking/account-management/#tag/Reference-accounts/paths/~1v1~1businesses~1%7Bbusiness_id%7D~1accounts~1%7Baccount_id%7D~1reference_accounts/post)
### 9.2 Attach the credit limit to the business's credit card account
After creating the reference account, you must attach the credit limit approved by Solaris to the credit card's account using the following endpoint.
You can set the credit card limit to the account as you see fit as long as it falls within or equals the limit approved by Solaris.
#### PATCH Attach credit limit to credit card account
**Request example**
```json
// PATCH /v1/credit_card_applications/{id}/limit
{
"limit": {
"value": 1000,
"unit": "cents",
"currency": "EUR"
}
}
```
The API call returns the details of the application and sets the `current_limit` to the limit defined by you. The limit will also be attached to the associated credit card account.
[Click here to view the full API reference.](/api-reference/digital-banking/credit-cards/#tag/Credit-cards/paths/~1v1~1credit_card_applications~1%7Bid%7D~1limit/patch)
## Step 10: Onboard employees
In this step, you need to collect the information of the business' employees who will be issued a credit card.
### 10.1 Create person resources for all cardholders
For each employee (e.g., cardholder) that will be issued a credit card, collect the required data points and create a person resource using the following endpoint.
**Required data points for a cardholder with full KYC**
This person will be identified using video identification.
* `salutation`
* `first_name` (Including all middle names as printed on the ID document)
* `last_name` (Including all middle names as printed on the ID document)
* `address`
* `birth_date`
* `birth_city`
* `nationality`
* `email`
* `mobile_number`
* `fatca_relevant`
* `fatca_crs_confirmed_at`
**Required data points for a cardholder with light KYC**
This person will be identified using Autoident.
* `salutation`
* `first_name` (Including all middle names as printed on the ID document)
* `last_name` (Including all middle names as printed on the ID document)
* `address`
* `birth_date`
* `birth_city`
* `nationality`
* `email`
* `mobile_number`
**Request URL**
```shell
POST /v1/persons
```
[View full API reference](/api-reference/onboarding/persons/#tag/Persons/paths/~1v1~1persons/post)
### 10.2 Create and verify mobile numbers of all cardholders
All employees who will be issued a credit card must have a verified mobile number. You must collect the customer's mobile number in your sign-up flow and then create a mobile number resource and verify it by sending an SMS OTP to the customer's mobile number. Then, the customer enters the OTP in your frontend to verify their number.
### Mobile number resource
Creating and verifying a mobile number for your customer is a crucial step in the customer onboarding process. With a verified mobile number, customers can use SMS OTPs to complete two-factor authentication (2FA) challenges, which is a requirement for Strong Customer Authentication (SCA).
Info
In some use cases (e.g., stand-alone integrations), the mobile number is verified during the identification process.
### API reference
Visit the following link to find all the endpoints related to the mobile number resource, including related properties and examples.
- [Mobile number resource API reference](/api-reference/onboarding/persons/#tag/Person-mobile-numbers)
**Related webhook events**
- [PERSON_MOBILE_NUMBER_CREATED](/api-reference/onboarding/webhooks/webhook-events/paths/person_mobile_number_created/post)
- [PERSON_MOBILE_NUMBER_DELETED](/api-reference/onboarding/webhooks/webhook-events/paths/person_mobile_number_deleted/post)
Testing static values
To test the following endpoints on Sandbox, you can use the following static values:
- Mobile number: `+15550101`
- SMS OTP: `212212`
#### POST Create mobile number
Collect the customer's mobile number and pass it to Solaris using the following API call. You must include the customer's `person_id` in the request URL.
**Request URL**
```shell
POST /v1/persons/{person_id}/mobile_number
```
**Request example**
```json
{
"number": "+15550101"
}
```
**Response example**
The API returns a `mobile_number` resource with a unique `id` and attaches it to the `person` resource.
```json
{
"id": "91e4d939d781b8eb30d1ee86809761c2cmno",
"number": "+15550101",
"verified": false
}
```
[Click here to view the full API reference.](/api-reference/onboarding/persons/#tag/Person-mobile-numbers/paths/~1v1~1persons~1%7Bperson_id%7D~1mobile_number/post)
#### POST Authorize mobile number
Use the following endpoint to verify the ownership of the provided mobile phone number. The endpoint initiates a one-time-password (OTP) flow: Solaris sends a six-digit OTP to the customer's number, and then they must enter it in your UI.
**Request URL**
```shell
POST /v1/persons/{person_id}/mobile_number/authorize
```
**Request example**
```json
{
"number": "+15550101"
}
```
**Response example**
```json
{
"id": "91e4d939d781b8eb30d1ee86809761c2cmno",
"number": "+15550101",
"verified": false
}
```
[Click here to view the full API reference.](/api-reference/onboarding/persons/#tag/Person-mobile-numbers/paths/~1v1~1persons~1%7Bperson_id%7D~1mobile_number~1authorize/post).
#### POST Confirm mobile number
Use this endpoint to submit the SMS OTP the customer received on their mobile number to finalize the mobile number authorization process. You must add the customer's `number` and `token` (i.e., the SMS OTP) in the request body. Afterward, the mobile number will be `verified` and can be used in the context of Strong Customer Authentication (SCA).
**Request URL**
```shell
POST /v1/persons/{person_id}/mobile_number/confirm
```
**Request example**
```json
{
"number": "+15550101",
"token": "212212"
}
```
**Response example**
```json
{
"id": "91e4d939d781b8eb30d1ee86809761c2cmno",
"number": "+15550101",
"verified": true
}
```
[Click here to view the full API reference.](/api-reference/onboarding/persons/#tag/Person-mobile-numbers/paths/~1v1~1persons~1%7Bperson_id%7D~1mobile_number~1confirm/post)
For more information about how to manage mobile numbers (e.g., changing or deleting a number), check the related [mobile number management guide](/guides/digital-banking/mobile-number-management).
### 10.3 Identify employees
If the number of legal representatives identified within the context of the BKYC is less than 6, you have to identify other employees using video identification by following the instructions in the [manual video identification](#72-manual-video-identification) section.
All other cardholders will be identified using a light KYC method, such as [IDnow AutoIdent](https://docs-autoident.idnow.io/?version=latest#107f6d04-34a7-4ac7-a8b4-e0243b9f4450). For each person you've created, you must create and trigger an identification using the following endpoint:
#### POST Create an identification for a cardholder via AutoIdent
Call this endpoint to create an identification for the cardholder via IDnow's AutoIdent:
```json
// POST /v1/persons/:person_id/identifications
{
"method": "idnow_autoident"
}
```
[View full API reference](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications/post)
#### PATCH Request an identification for a cardholder via AutoIdent
Call this endpoint to trigger the KYC flow.
```json
// POST /v1/persons/:person_id/identifications
{
"idnow_autoident"
}
```
[View full API reference](/api-reference/identity/identifications/#tag/Person-identifications/paths/~1v1~1persons~1%7Bperson_id%7D~1identifications~1%7Bid%7D~1request/patch)
## Step 11: Create and activate credit card
In this step, create and activate the credit cards for each of the business' employees who have been onboarded. Cardholders can choose between different card types, such as a physical or a virtual card, with the option to tokenize the card to be used in any e-wallet, such as Google Pay or Apple Pay.
### API reference
Visit the following link to find all the endpoints related to cards, including related properties and examples.
- [Cards API reference](/api-reference/digital-banking/cards/)
#### POST Create a card
This endpoint initiates the card creation process for the customer. Include the `account_id` along with the `person_id` in the request URL. Additionally, include the following properties in the request body:
- `line_1`: The cardholder's name which will be printed on the card. Pay attention to the special rules governing card names mentioned [here](/guides/cards/creation-and-servicing/#cardholder-name-and-address-generation).
- `type`: The card type. View [here](/guides/cards/creation-and-servicing/#appendix-i-card-types) a list of possible card types for each customer segment.
**Request URL:**
```shell
POST /v1/persons/{person_id}/accounts/{account_id}/cards
```
**Response example:**
A card will be created in the system, and Solaris will issue a card creation request with SIA. The API will respond with the ID of the card and the status of `PROCESSING`.
```json
{
"id": "8febdba4912a747808ccc6f95f82aaa4",
"status": "PROCESSING"
}
```
[Click here to view the full API reference.](/api-reference/digital-banking/cards/#tag/Cards-servicing/paths/~1v1~1persons~1%7Bperson_id%7D~1accounts~1%7Baccount_id%7D~1cards/post)
#### GET Retrieve card details
Before you can activate the card, make the following API call to retrieve the details of the card. The `status` must have the value of `INACTIVE`. The status change may take a few seconds after the initial `POST Create card` request, as Solaris submits card creation requests asynchronously to SIA.
The API will respond with the card details when the `status` changes to `INACTIVE`. Until then, the response will look the same as the one from the previous call.
**Request URL:**
```shell
GET /v1/cards/{card_id}
```
[Click here to view the full API reference.](/api-reference/digital-banking/cards/#tag/Cards-servicing/paths/~1v1~1cards~1%7Bid%7D/get)
#### POST Activate a card
Once the card is `INACTIVE` and you have retrieved the details using the previous API call, you can activate the card using the following endpoint:
**Request URL:**
```shell
POST /v1/cards/{card_id}/activate
```
[Click here to view the full API reference.](/api-reference/digital-banking/cards/#tag/Cards-servicing/paths/~1v1~1cards~1%7Bcard_account_id%7D~1activate/post)
### Cards servicing
For more information about cards servicing, check the [Card creation and servicing guide](/guides/cards/creation-and-servicing/).
### Card push provisioning
If your customer wants to use their card in a digital wallet, such as Google Pay, Apple Pay, or Samsung Pay wallet, implement the relevant endpoints in the [Card Push Provisioning guide](/guides/cards/push-provisioning).
See the [Cards overview page](/guides/cards) for more information about cards.
### Card spending controls
After creating all the required credit cards for the business' employees, the business can set control lists and spending limits on each card as they see fit. Note that all issued credit cards must not exceed the limit attached to the business' account.
For instructions on how to implement spending limits, check the [Card spending controls guide](/guides/cards/card-spending-controls).
## Step 12: Servicing credit cards
In this section, you can find endpoints related to servicing credit cards.
### PATCH Update repayment option
Your customer can change the repayment option after initial onboarding (e.g., switching from charge to revolving and vice versa).
The requested repayment option will be effective from the next billing cycle.
You can update the repayment option by calling the following endpoint:
**Request example**
```json
// PATCH /v1/credit_card_applications/{id}
{
"repayment_options": {
"upcoming_type": "PARTIAL",
"minimum_amount": {
"value": 100,
"unit": "cents",
"currency": "EUR"
},
"minimum_percentage": 3
},
"statement_with_details": true
}
```
[Click here to view the full API reference.](/api-reference/digital-banking/credit-cards/#tag/Credit-cards/paths/~1v1~1credit_card_applications~1%7Bid%7D/patch)
### GET Index a credit card bill
Call this endpoint to retrieve a credit card bill.
Please note that Solaris generates credit cards statements and uploads them to Postbox. You can use this endpoint if you want to generate your own bills.
**Request URL**
```shell
GET /v1/credit_card_bills/{bill_id}
```
[Click here to view the full API reference.](/api-reference/digital-banking/credit-cards/#tag/Credit-cards/paths/~1v1~1credit_card_bills~1%7Bbill_id%7D/get)
## Step 13: Terminating credit cards
This section describes how credit card termination works and how to use the related API endpoints.
### Credit card termination process
Here is a summary of the termination process:
1. Either you, the customer (via your frontend), or Solaris initiates the termination.
- If **Solaris** initiated the termination, then you will receive a notification on the [CREDIT_CARD_APPLICATION_TERMINATION webhook event](/api-reference/onboarding/webhooks/webhook-events/paths/credit_card_application_termination/post) and you must immediately notify the customer about the termination.
- If the **customer** initiated the termination, then your application must call the [POST Terminate a credit card application](/api-reference/digital-banking/credit-cards/#tag/Termination-requests/paths/~1v1~1credit_card_applications~1%7Bapplication_id%7D~1termination_requests/post) endpoint. This will create a **credit card application termination** resource.
2. Solaris' system will trigger a termination and calculate a **legal closure date** for the credit card.
- If the credit card has a **negative** balance, then Solaris will generate a final bill and trigger a SEPA Direct Debit (SDD) from the customer's reference account.
- If the credit card has a **positive** balance, then Solaris will initiate a payout to the attached reference account.
3. You will receive notifications on the [CREDIT_CARD_APPLICATION_TERMINATION webhook event](/api-reference/onboarding/webhooks/webhook-events/paths/credit_card_application_termination/post) when the status of the credit card application termination changes. If the termination succeeds, the credit card will be closed. If it fails, then Solaris Customer Support will provide assistance.
#### Pre-termination checks
Solaris will check for the following criteria before terminating a credit card:
- The credit card is in **dunning.**
- The credit card has `CARD_TRANSACTION` or `CARD_DIRECT_DEBIT` bookings from the past 45 days.
- The credit card has **reservations** with the status OPEN.
- The credit card has bookings with a valuta date in the future.
- The last SDD was triggered less than 56 days ago.
If any of these criteria are met, then the **technical closure** of the credit card may be delayed.
### POST Terminate a credit card application
This endpoint initiates a termination request for an existing credit card.
Termination requests can be revoked within **5 business days** of their
initiation. After that, the termination can not be reversed. See the endpoint
below for instructions on how to revoke a termination request.
**Request URL:**
```shell
POST /v1/credit_card_applications/{application_id}/terminate
```
**Required properties:**
- `reason`: The reason for terminating the credit card.
[Click here to view the full documentation.](/api-reference/digital-banking/credit-cards/#tag/Termination-requests/paths/~1v1~1credit_card_applications~1%7Bapplication_id%7D~1termination_requests/post)
### POST Revoke a termination request
This endpoint revokes a request to terminate a credit card.
**Request URL:**
```shell
POST /v1/credit_card_terminations/{id}/revoke
```
[Click here to view the full documentation.](/api-reference/digital-banking/credit-cards/#tag/Termination-requests/paths/~1v1~1credit_card_terminations~1%7Bid%7D~1revoke/post)
## What's next?
Congratulations! You've successfully integrated the Solaris Credit Cards product.
Check the following appendices section for additional information on enums and testing data.
### Useful resources
Check the following links for additional related guides and API reference documentation:
* [Credit cards API reference documentation](/api-reference/digital-banking/credit-cards/#tag/Credit-cards)
* [Reference accounts API reference documentation](/api-reference/digital-banking/account-management/#tag/Reference-accounts)
* [Video Identification](/guides/kyc/videoident)
* [Account management guide](/guides/digital-banking/account-management)
* [Card creation & servicing guide](/guides/cards/creation-and-servicing)
* [SEPA Transfers Overview](/guides/digital-banking/sepa-transfers)
* [SEPA Direct Debit Transfers](/guides/digital-banking/sepa-transfers/sepa-direct-debit-transfer)
## Appendix I: Enums
### Credit card application status
The following table includes the enums for the field `status` and their descriptions in the credit card application resource. For example, it's available when you call the GET Retrieve credit card application.
| Status | Description | Actions |
| --- | --- | --- |
| `PENDING` | The credit card application has been created for the customer and is currently being validated. | Wait for the scorer's result. |
| `IN_SCORING` | The application has passed the initial validation checks. The scorer has been triggered and the application is currently under credit scoring. | Wait for the scorer's result. |
| `PRE_APPROVED` | The scorer approved the credit card application. | Trigger the identification flow for the customer. Download the SECCI form and credit card contract. Get the customer's consent on the SECCI and contract and upload signed documents. |
| `FINALIZED` | The customer identification is successful and the credit card application has been finalized. | Set the credit card limit on the account. Set up the reference account. |
| `DECLINED` | The scorer has rejected the application and/or identification has failed, and the credit card application is rejected. | Notify the customer and abort the onboarding process. |
### 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:
| Enum | Description |
| --- | --- |
| `FE_REPORTING` | Reporting Financial Institution. |
| `FE_NON_REPORTING` | Non-Reporting Financial Institution. |
| `NFE_ACTIVE_OTHER` | Active NFE (Non-Financial Entity) - A corporation whose shares are regularly traded on at least one recognized stock exchange (or an affiliate), a government entity, an international organization, a central bank, or a legal entity wholly owned by one of these. |
| `NFE_PASSIVE` | Passive NFE - A non-active Non-Financial Entity. |
| `NFE_PASSIVE_INVESTMENT` | Passive NFE (Investment) - An Investment Entity that is a Financial Institution in a jurisdiction not participating in the CRS and is managed by another Financial Institution. |
### Document types
The following table includes the possible values for the field `document_type` and their descriptions.
| Enum | Description |
| --- | --- |
| `ANNUAL_FINANCIAL_STATEMENT` | A business or company's annual financial statement. |
| `KYC_REPORT` | The KYC report generated after successful customer identification. |
| `ID_DOCUMENT` | A person's identification document, such as a passport or ID card. |
| `SIGNATURE` | A signature sample. |
| `PICTURE` | A picture or scanned document of any other type. |
| `QES_DOCUMENT` | A document related to a Qualified Electronic Signature (QES). |
| `SIGNED_CONTRACT` | A signed contract of any kind. |
| `SIGNED_QES_DOCUMENT` | A document signed by a Qualified Electronic Signature (QES). |
| `REGISTER_APPLICATION` | A document proving the application for registration (Gründungsurkunde), used for companies "in formation". |
| `REGISTER_CHECK` | A register check. |
| `REGISTER_EXTRACT` | A commercial register excerpt or similar document. |
| `FOUNDATION_DOCUMENT` | The foundation document of a company or business. |
| `SCHUFA_COMPACT_REPORT` | A compact SCHUFA report. |
| `SCHUFA_GWG_REPORT` | A GWG (Money Laundering Act) SCHUFA report. |
| `SCHUFA_FULL_REPORT` | A full SCHUFA report about a person. |
| `SCHUFA_SHORT_REPORT` | A short SCHUFA report about a person. |
| `CREDIT_AGENCY_REPORT` | A report issued by a credit agency. |
| `SHARE_HOLDERS_AGREEMENT` | A shareholder agreement. |
| `SHAREHOLDERS_LIST` | A list of shareholders. |
| `TRADING_LICENSE` | A trading license. |
| `TRANSPARENCY_REGISTER_EXTRACT` | An extract from the transparency register. |
| `INVOICE` | An invoice of any kind. |
| `OTHER` | Any other type of document. |
| `VIDEO` | A video of any kind. |
| `VAT_CERTIFICATE` | VAT registration certificate. |
### 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.
| Status | Description |
| --- | --- |
| `created` | The identification resource has been created for the customer. |
| `pending` | The identification process has been triggered, and the video identification URL and reference have been generated. Redirect the customer to the URL to complete the identification. |
| `pending_failed` | The identification is currently under review by the provider. You **cannot** offer banking services to the customer at this stage. |
| `successful` | The video identification was successful. The customer can be onboarded. Note that the customer's data might have been updated during the identification session. |
| `aborted` | The customer aborted the identification process. They can retry using the same URL. |
| `canceled` | The provider canceled the video identification. The customer should retry using the same URL. |
| `failed` | The identification was unsuccessful. You **cannot** onboard the customer or offer any banking services to them. |
| `expired` | The identification link has expired (validity period passed). You must create a new identification request. |
IDnow provides a reason whenever the identification has a `canceled` or `aborted` status. No reason is disclosed for the final `failed` status.
### Tax country
The following table includes the possible values for the field `tax_country`.
| Enum | Description |
| --- | --- |
| `AT` | Austria |
| `BE` | Belgium |
| `CZ` | Czech Republic |
| `DE` | Germany |
| `ES` | Spain |
| `FR` | France |
| `GB` | United Kingdom |
| `IT` | Italy |
| `LU` | Luxembourg |
| `NL` | The Netherlands |
| `PT` | Portugal |
### Sector
The following table includes the possible values for the field `sector`.
| Enum |
| --- |
| `ECONOMICALLY_SELF_EMPLOYED` |
| `ECONOMIC_DEPENDENT` |
| `FOREIGN_COMPANIES` |
| `FOREIGN_ECONOMIC_DEPENDENT` |
| `FOREIGN_PRIVATE_INDIVIDUAL` |
| `FOREIGN_SELF_EMPLOYED_PRIVATE_PERSON` |
| `GERMAN_BANKS` |
| `MUNICIPALITY_AND_MUNICIPALITY_ASSOCIATION` |
| `OTHER_COMPANIES` |
| `OTHER_COMPANIES_WORKMAN` |
| `OTHER_PRIVATE_INDIVIDUAL` |
### 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`.
| Tax country | Allowed values for sector |
| --- | --- |
| `DE` | * `ECONOMICALLY_SELF_EMPLOYED`
* `ECONOMIC_DEPENDENT`
* `GERMAN_BANKS`
* `MUNICIPALITY_AND_MUNICIPALITY_ASSOCIATION`
* `OTHER_COMPANIES_WORKMAN`
* `OTHER_COMPANIES`
* `OTHER_PRIVATE_INDIVIDUAL`
|
| All other countries | * `FOREIGN_COMPANIES`
* `FOREIGN_ECONOMIC_DEPENDENT`
* `FOREIGN_PRIVATE_INDIVIDUAL`
* `FOREIGN_SELF_EMPLOYED_PRIVATE_PERSON`
|
#### 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`.
| Sector | Allowed values for legal form |
| --- | --- |
| `OTHER_COMPANIES` | * `AG`
* `EG`
* `GBR`
* `GMBH_CO_KG`
* `GMBH_I_GR`
* `GMBH`
* `KG`
* `KGAA`
* `LTD`
* `OHG`
* `PARTG`
* `SE`
* `UG_I_GR`
* `UG`
|
| `OTHER_COMPANIES_WORKMAN` | * `EK`
* `GBR`
* `LTD`
* `SELF_EMPLOYED`
* `SOLE_PROPRIETORSHIP`
|
| `FOREIGN_COMPANIES` | * `FOREIGN_CORPORATION`
* `NONE`
|
| `GERMAN_BANKS` | * `SAVINGS_BANK`
|
| `MUNICIPALITY_AND_MUNICIPALITY_ASSOCIATION` | * `MUNICIPALITY`
* `MUNICIPAL_COMPANY`
|
| `ECONOMICALLY_SELF_EMPLOYED` | * `EK`
* `GBR`
* `SELF_EMPLOYED`
* `SOLE_PROPRIETORSHIP`
|
| `NON_PROFIT_ORGANIZATION` | * `EV`
* `NEV`
|
### 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.
| Status | Description |
| --- | --- |
| `created` | The legal identification has been initiated and will be conducted shortly. |
| `information_required` | Solaris is missing one or more required documents or information. Check the `legal_identification_missing_information` array to see what is missing. |
| `pending` | The legal review is currently in progress. This status is set after you call the `mark_as_ready` endpoint. |
| `blocked_internally` | The legal identification is put on hold due to additional internal checks. |
| `successful` | The legal identification was completed successfully. |
| `failed` | The legal identification failed. Check the `legal_identification_reason` field for details. |
| `expired` | The legal identification was not completed within the required timeframe (90 days). |
### 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.
| Status | Description |
| --- | --- |
| `created` | The business identification resource has been created. The legal review and video identification steps will begin shortly. |
| `pending` | The business identification is currently in progress. This may mean Solaris is reviewing the legal documents or waiting for the legal representatives to complete their video identification. |
| `successful` | Both steps of the business identification process (legal review and video identifications) were completed successfully. |
| `failed` | The business identification process failed and will not continue. To understand why, check the status of the `legal_identification` or the individual video identifications. |
| `expired` | The business identification process was not completed within the allowed timeframe (usually 6 months). Either the legal identification or one of the video identifications was not finished on time. |
## Appendix II: BKYC required documents
The following table lists the required documents for identification for each legal form.
Info
For all registered legal forms, customers must input their business data (`registration_number` and `registration_issuer`).
Once the customer enters this data, Solaris automatically retrieves the required company documents, eliminating the need to request them during the onboarding flow.
Important
Inaccurate data (`registration_number` and `registration_issuer`) causes automated retrieval to fail. In this case, you must request documents manually from the customer using the request information and request document endpoints.
Solaris may request further documents during the onboarding process depending on factors such as legal entities acting as beneficial owners, complex business structures, or specific service types.
| Legal Form | Documents required | Document Type | Data can be retrieved by Solaris |
| --- | --- | --- | --- |
| ADÖR | Register extract | REGISTER_EXTRACT | Yes - Automated |
| ADÖR | Articles of Association (Satzung) | FOUNDATION_DOCUMENT | No |
| AG | Register extract | REGISTER_EXTRACT | Yes - Automated |
| AG | "Aktionärsliste" for AG or AG/SE as General Partner | SHAREHOLDER_LIST | No |
| AG | Articles of Association (Satzung) | FOUNDATION_DOCUMENT | No |
| AG_CO_KG | Register extract | REGISTER_EXTRACT | Yes - Automated |
| AG_CO_KG | "Aktionärsliste" for AG or AG/SE as General Partner | SHAREHOLDER_LIST | No |
| AG_CO_KG | Articles of Association (Satzung) for AG/SE as General Partner | FOUNDATION_DOCUMENT | No |
| EG | Register extract | REGISTER_EXTRACT | Yes - Automated |
| EG | Articles of Association (Satzung) | FOUNDATION_DOCUMENT | No |
| EK | Register extract | REGISTER_EXTRACT | Yes - Automated |
| GbR | Gesellschaftsvertrag (partnership/shareholder agreement) | OTHER or SHAREHOLDER_AGREEMENT | No |
| eGbR | Register extract | REGISTER_EXTRACT | Yes - Automated |
| eGbR | Gesellschaftsvertrag (partnership/shareholder agreement) | OTHER or SHAREHOLDER_AGREEMENT | No |
| Gemeinde | Articles of Association (Satzung) | FOUNDATION_DOCUMENT | No |
| gGmbH | Register extract | REGISTER_EXTRACT | Yes - Automated |
| gGmbH | List of Shareholders | SHAREHOLDER_LIST | Yes - Automated |
| GMBH | Register extract | REGISTER_EXTRACT | Yes - Automated |
| GMBH | List of Shareholders | SHAREHOLDER_LIST | Yes - Automated |
| GMBH_CO_KG | Register extract | REGISTER_EXTRACT | Yes - Automated |
| GMBH_CO_KG | Shareholderlist for GmbH/UG General Partner | SHAREHOLDER_LIST | No |
| GMBH_I_GR | Articles of Association (Satzung) | FOUNDATION_DOCUMENT | No |
| GMBH_I_GR | Gesellschaftsvertrag (partnership/shareholder agreement) | OTHER or SHAREHOLDER_AGREEMENT | No |
| GMBH_I_GR | Notariell beglaubigte Urkundenrolle/Musterprotokoll | OTHER | No |
| gUG | Register extract | REGISTER_EXTRACT | Yes - Automated |
| gUG | List of Shareholders | SHAREHOLDER_LIST | Yes - Automated |
| KDOR | Articles of Association (Satzung) | FOUNDATION_DOCUMENT | No |
| KG | Register extract | REGISTER_EXTRACT | Yes - Automated |
| KGAA | Register extract | REGISTER_EXTRACT | Yes - Automated |
| KGAA | Articles of Association (Satzung) | FOUNDATION_DOCUMENT | No |
| LTD | Register extract | REGISTER_EXTRACT | Yes - Automated |
| LTD | List of Shareholders | SHAREHOLDER_LIST | No |
| LTD | Articles of Association (Satzung) | FOUNDATION_DOCUMENT | No |
| NEV | List of Shareholders (List of Board members) | SHAREHOLDER_LIST | No |
| NEV | Articles of Association (Satzung) | FOUNDATION_DOCUMENT | No |
| OHG | Register extract | REGISTER_EXTRACT | Yes - Automated |
| PARTG | Register extract | REGISTER_EXTRACT | Yes - Automated |
| PARTG | Gesellschaftsvertrag (Partnerschaftsvertrag) | OTHER or SHAREHOLDER_AGREEMENT | No |
| SE | Register extract | REGISTER_EXTRACT | Yes - Automated |
| SE | List of Shareholders | SHAREHOLDER_LIST | No |
| SE_CO_KG | Register extract | REGISTER_EXTRACT | Yes - Automated |
| SE_CO_KG | "Aktionärsliste" for AG or AG/SE as General Partner | SHAREHOLDER_LIST | No |
| SE_CO_KG | Articles of Association (Satzung) for AG/SE as General Partner | FOUNDATION_DOCUMENT | No |
| SE_CO_KG | Gesellschaftsvertrag (partnership/shareholder agreement) | OTHER or SHAREHOLDER_AGREEMENT | No |
| SOLE_PROPRIETORSHIP | Register extract | REGISTER_EXTRACT | No |
| Stiftungen | Articles of Association (Satzung) | FOUNDATION_DOCUMENT | No |
| Stiftungen | Trustee Agreement / Stiftungssatzung or Statement signed by the Legal Representatives | OTHER | No |
| UG | Register extract | REGISTER_EXTRACT | Yes - Automated |
| UG | List of Shareholders | SHAREHOLDER_LIST | Yes - Automated |
| UG_CO_KG | Register extract | REGISTER_EXTRACT | Yes - Automated |
| UG_CO_KG | Shareholderlist for GmbH/UG General Partner | SHAREHOLDER_LIST | No |
| UG_CO_KG | Gesellschaftsvertrag (partnership/shareholder agreement) | OTHER or SHAREHOLDER_AGREEMENT | No |
| UG_I_GR | Articles of Association (Satzung) | FOUNDATION_DOCUMENT | No |
| UG_I_GR | Gesellschaftsvertrag (partnership/shareholder agreement) | OTHER or SHAREHOLDER_AGREEMENT | No |
| UG_I_GR | Notariell beglaubigte Urkundenrolle/Musterprotokoll | OTHER | No |
## 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`.
| Country | Registration number | Registration issuer | Company name |
| --- | --- | --- | --- |
| DE | HRA204605 | Oldenburg (Oldenburg) | Stiftung St. Josef-Stift |
| DE | HRB18686 | Bonn | Tekcor 1. V V UG |
| DE | HRA201632 | Lüneburg | EWIV für Unternehmensberatung |
| DE | HRA12751 | Dortmund | Industrial Mercantile International Co. |
| DE | HRB39889 | Berlin (Charlottenburg) | OKV-Ostdeutsche Kommunalversicherung auf Gegenseitigkeit |
| DE | HRA928 | Koblenz | Hans Leininger, Textilgroßhandlung |
| DE | HRA551344 | Ulm | Ravensburger Verkehrs- und Versorgungsbetriebe |
| DE | GnR729 | Landshut | BürgerEnergie Niederbayern eG |
| ES | A31239833 | ---- | BEKO ERROTA SAL |
| ES | A82234113 | ---- | HOTEL BAHIA TROPICAL SA |
| ES | D92943109 | ---- | MICHAEL SCHMIDT Y CIA ENERGIA SOLAR [...] |
| ES | B40547747 | ---- | CACTUS DIGITAL SIGNAGE SOCIEDAD LIMITADA |
| ES | V54433230 | ---- | EL SECRETO DE SUS OJOS AIE |
| ES | B93050672 | ---- | PURAENVIDIA CONSULTING SL |
| ES | G83086751 | ---- | BARCLAYS GESTION FI |
| ES | B57761249 | ---- | GRUPO SA VINYA IBIZA, SOCIEDAD LIMITADA |
| ES | A79102331 | ---- | UNIDAD EDITORIAL SA |
| FR | 304141732 | ---- | ROGER & GALLET |
| FR | 790241467 | ---- | SR SIGNALETIC |
| FR | 807956966 | ---- | MENTON PARC AUTO |
| FR | 321470072 | ---- | GROUP ETUD CONSTR HAB CONSEIL |
| FR | 642050199 | ---- | AUTOMOBILES CITROEN |
| FR | 330034968 | ---- | INNOVATION ANIMATION CULTURE TOURISME |
| FR | 388843930 | ---- | RISKAUDIT IRSN-GRS INTERNATIONAL |
| FR | 332856574 | ---- | JEAN BAPTISTE POLIZZI |
| FR | 702006230 | ---- | SOFILOGIS |
| FR | 521753418 | ---- | HOLMES AND TOOLS |
| IT | BA543920 | ---- | FONDAZIONE NICOLA E VITO ANTONIO RUGGIERI |
| IT | TP131030 | ---- | MAIORANA GIUSEPPE PICCOLO IMPRENDITORE EDILE |
| IT | BA520383 | ---- | SPECIAL CARS SRL |
| IT | BI11627 | ---- | ALLEANZA COOPERATIVA TORINESE*A.C.T. |
| IT | MI152555 | ---- | UNICREDIT SERVICES S.C.P.A |
| IT | BS505351 | ---- | FUNGHI ENERGIA & SALUTE S.R.L. |
| IT | RM1046737 | ---- | CONSORZIO G.T.I. - GRUPPO TECNOLOGIE INTEGRATE IN LIQUIDAZIONE |
| IT | ME239092 | ---- | RUACH S.C. A R.L. - CONSORZIO STABILE |
For non-`DE` companies, the `registration_issuer` field is not necessary.
## 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`.
| Industries that require licenses |
| --- |
| Alcoholic Beverages (Ausschanklizenz) |
| Brokerage or Consultancy on Financial Investments |
| Waste/ Rubbish Collection, Transportation, Trade, or Brokerage |
| Insurance broker / Insurance advisor |
| Fee-based financial investment advisor |
| Realtor (Immobilienmakler) |
| Real Estate Loan Brokerage (Immobiliardarlehensvermittler) |
| Residential Property Manager (Wohnimmobilienverwalter) |
| Site supervisor (Baubetreuer) |
| Property developer (Bauträger, Bauherr) |
| Drones |
| Tour Operator (Reisevermittler) |
| Labour Leasing (Arbeitnehmerüberlassung) |
| Tax Advisor/ Tax Consultancy (Steuerberater) |
| Taxi Business (Taxenverkehr/ Taxiservice) |
| Provision of Ambulatory (Non-stationary) Care |
| Geriatric Nurses (Altenpflegerinnen und Altenpfleger) |
| Employment Agency (Arbeitsvermittlung) |
| Auctioneer/ auction houses (Auktionator) |
| Gastronomy Establishments Without Alcoholic Beverages |
| Accommodation Establishments (Beherbergungsbetriebe) |
| Loan brokerage (Darlehensvermittler) |
| Wholesale of Medicinal Products |
| Road Haulage (Güterkraftverkehr) |
| Ambulance Services (Krankentransport) |
| Trade Fairs, Exhibitions, Markets |
| Pawn Shops (Pfandleihgewerbe) |
| Podiatrist/ Medical Podiatrist |
| Showman on Funfairs (Reisegewerbe) |
| Pension Advisor (Rentenberater) |
| Pest Control (Schädlingsbekämpfung) |
| Debtor and consumer insolvency advisor |
| Covid Test Centre (Corona Schnelltestzentrum) |
| Payment service providers (Zahlungsdienstleister) |
## Appendix V: Business Registry offices
| Register Court |
| --- |
| Aachen |
| Altenburg |
| Amberg |
| Ansbach |
| Apolda |
| Arnsberg |
| Arnstadt |
| Arnstadt Zweigstelle Ilmenau |
| Aschaffenburg |
| Augsburg |
| Aurich |
| Bad Hersfeld |
| Bad Homburg v.d.H. |
| Bad Kreuznach |
| Bad Oeynhausen |
| Bad Salzungen |
| Bamberg |
| Bayreuth |
| Berlin (Charlottenburg) |
| Bielefeld |
| Bochum |
| Bonn |
| Braunschweig |
| Bremen |
| Chemnitz |
| Coburg |
| Coesfeld |
| Cottbus |
| Darmstadt |
| Deggendorf |
| Dortmund |
| Dresden |
| Duisburg |
| Düren |
| Düsseldorf |
| Eisenach |
| Erfurt |
| Eschwege |
| Essen |
| Flensburg |
| Frankfurt am Main |
| Frankfurt/Oder |
| Freiburg |
| Friedberg |
| Fritzlar |
| Fulda |
| Fürth |
| Gelsenkirchen |
| Gera |
| Gießen |
| Gotha |
| Göttingen |
| Greiz |
| Gütersloh |
| Hagen |
| Hamburg |
| Hamm |
| Hanau |
| Hannover |
| Heilbad Heiligenstadt |
| Hildburghausen |
| Hildesheim |
| Hof |
| Homburg |
| Ingolstadt |
| Iserlohn |
| Jena |
| Kaiserslautern |
| Kassel |
| Kempten (Allgäu) |
| Kiel |
| Kleve |
| Koblenz |
| Köln |
| Königstein |
| Korbach |
| Krefeld |
| Landau |
| Landshut |
| Langenfeld |
| Lebach |
| Leipzig |
| Lemgo |
| Limburg |
| Lübeck |
| Ludwigshafen a.Rhein (Ludwigshafen) |
| Lüneburg |
| Mainz |
| Mannheim |
| Marburg |
| Meiningen |
| Memmingen |
| Merzig |
| Mönchengladbach |
| Montabaur |
| Mühlhausen |
| München |
| Münster |
| Neubrandenburg |
| Neunkirchen |
| Neuruppin |
| Neuss |
| Nordhausen |
| Nürnberg |
| Offenbach am Main |
| Oldenburg (Oldenburg) |
| Osnabrück |
| Ottweiler |
| Paderborn |
| Passau |
| Pinneberg |
| Pößneck |
| Pößneck Zweigstelle Bad Lobenstein |
| Potsdam |
| Recklinghausen |
| Regensburg |
| Rostock |
| Rudolstadt |
| Saarbrücken |
| Saarlouis |
| Schweinfurt |
| Schwerin |
| Siegburg |
| Siegen |
| Sömmerda |
| Sondershausen |
| Sonneberg |
| Stadthagen |
| Stadtroda |
| Steinfurt |
| Stendal |
| St. Ingbert (St Ingbert) |
| Stralsund |
| Straubing |
| Stuttgart |
| St. Wendel (St Wendel) |
| Suhl |
| Tostedt |
| Traunstein |
| Ulm |
| Völklingen |
| Walsrode |
| Weiden i. d. OPf. |
| Weimar |
| Wetzlar |
| Wiesbaden |
| Wittlich |
| Wuppertal |
| Würzburg |
| Zweibrücken |
## 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.