Business credit cards
Introduction
Solaris credit cards for businesses allow you to offer credit cards to your business customers and their employees in an easy and automated onboarding flow. To onboard a business on our credit card solution, the business must go through the standard onboarding flow, including business identification (BKYC) and other steps related to the credit card setup.
In this guide, you will find all the onboarding requirements you need to integrate into your solution to offer this product to your business customers.
Available branches
This product is currently only offered to businesses in Germany.
How does it work?
Using Solaris credit cards, your business customers can offer their employees credit cards. The business will be the account's owner, whereas the employees, who will be issued a credit card, will be cardholders who only have access to the funds on their credit cards as allocated to them by the business.
Therefore, 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:
- Fulfill all legal and compliance requirements.
- Submit the required business data points and documents.
- Submit the required data points about legal representatives, beneficial owners, and authorized persons.
- Pass the credit scoring process.
- Complete the business identification flow (BKYC).
- Onboard their employees who will be issued a credit card.
Additionally, you can offer the business the option to choose between charge and revolving credit cards. Read more about the difference between charge and revolving cards here.
note
This page covers the specific integration steps for business credit cards. See the credit cards overview page for a general overview of how Solaris credit cards work.
System prerequisites
Before starting the onboarding process, implement the following requirements:
1. Technical setup:
Set up your environment and get your authentication keys. For step-by-step instructions, check the Technical setup guide.
2. Legal and compliance screens:
Build the necessary legal and compliance screens in your sign-up flow to collect your customers' consent to the necessary legal and compliance requirements. The Legal and compliance screens guide contains step-by-step instructions on how to create these screens and what they must contain.
The following screens are required to onboard B2C and freelancer customers for Digital Banking & Cards:
- Terms and Conditions
- Customer information
- Economic interest
- Person tax information (Only for customers in Germany)
- FATCA indication
- Self-declaration as a politically exposed person (PEP). (Only for customers in France, Italy, and Spain)
- Compliance screen
Record the customer's consent on each screen as a UTC timestamp (e.g., 2019-01-01T00:00:00Z
). Afterward, you must pass each timestamp in its respective field to Solaris.
- Collect the customer's consent to Solaris's Terms and Conditions and store the timestamp in the
terms_conditions_signed_at
field. - Collect the customer's consent to data processing and store the timestamp in the
data_terms_signed_at
field. - Collect the customer's economic interest declaration and store the timestamp in the
own_economic_interest_signed_at
field. - Collect the customer's FATCA indication and store it in the
fatca_relevant
field. Store the timestamp in thefatca_crs_confirmed_at
field.
note
The mentioned fields are part of the person resource in which all the customer data points are stored.
attention
- 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 an 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 (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
attention
- This guide includes the onboarding requirements for both charge and revolving cards for businesses in Germany.
- The following integration uses IDnow video identification 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. Click on each step to go to its dedicated section for full instructions:
You can integrate Solaris' business credit card product by completing the 12 steps explained in the following sections. Here's an overview of these steps:
Category | Step | Description |
---|---|---|
Business registration | Step 1 | Collect the mandatory business data, and create a business resource for your customer. |
Business registration | Step 2.1 | Collect the required business documents from the business and pass them to Solaris by creating document resources. |
Business registration | Step 2.2 | Upload the B2B SDD mandate. |
Natural persons registration | Step 3 | 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 for each legal representative. 3.2 Assign the legal representative role to each legal representative. |
Natural persons registration | Step 4 | 4.1. Collect the mandatory data from each of the business' beneficial owner(s), including the FATCA relevance indication, and create a person resource. 4.2 Assign the beneficial owner role to each beneficial owner. |
Tax information | Step 5 | 5.1. Collect the mandatory tax information from the business and create a business tax identification resource. 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). |
Credit card application | Step 6 | 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 | 7.1. Trigger the business identification process (BKYC) 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 endpoints. 7.3. Implement the compliance questions endpoints related to the business' legal identification process. Make sure to 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 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. |
Credit card confirmation & reference account creation | Step 8 | 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) on the business account. |
Credit card confirmation & reference account creation | Step 9 | 9.1 Create a reference account for the business. 9.2 Attach the credit card limit to the credit card account. |
Employee onboarding | Step 10 | 10.1 For each employee who will be issued a credit card, collect the required data and create a person resource. 10.2 Collect and confirm the mobile number of each employee who will be issued a credit card. 10.3 Create and trigger the identification. |
Card creation, activation & servicing | Step 11 | Create and activate the credit card for all cardholders. |
Card creation, activation & servicing | Step 12 | Implement all endpoints related to servicing credit cards. |
Sequence diagram
The following sequence diagram gives an overview of the integration flow:
note
To view a larger version of this diagram, right-click on the image and click "Open in a new tab."
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.
- ACCOUNT_BLOCK
- ACCOUNT_CLOSURE_REQUEST
- ACCOUNT_CLOSURE
- BENEFICIAL_OWNER
- BOOKING
- BUSINESS_CHANGED
- BUSINESS_DELETED
- BUSINESS_SEIZURE_CREATED
- BUSINESS_SEIZURE_DELETED
- BUSINESS_SEIZURE_FULFILLED
- BUSINESS_SEIZURE_UPDATED
- BUSINESS_IDENTIFICATION
- BUSINESS_TAX_IDENTIFICATION_CHANGED
- CARD_LIFECYCLE_EVENT
- CARD_AUTHORIZATION
- CARD_AUTHORIZATION_DECLINE_V2
- CARD_AUTHORIZATION_RESOLUTION
- CARD_FRAUD_CASE_PENDING
- CARD_FRAUD_CASE_TIMEOUT
- IDENTIFICATION
- LEGAL_REPRESENTATIVE
- PERSON_CHANGED
- PERSON_DELETED
- PERSON_SEIZURE_CREATED
- PERSON_SEIZURE_DELETED
- PERSON_SEIZURE_FULFILLED
- PERSON_SEIZURE_UPDATED
- PERSON_MOBILE_NUMBER_CREATED
- PERSON_MOBILE_NUMBER_DELETED
- PERSON_TAX_IDENTIFICATION_CHANGED
- POSTBOX_ITEM_CREATED
- SCA_CHALLENGE
Mandatory features
You must integrate all the mandatory features for Digital Banking & Cards highlighted in the Onboarding requirements guide before going live with your solution except for Account Closure. Credit cards have their own termination process, which is described below.
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.
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:
Related webhook events
Important points about data collection
- Please consider the special considerations for data collection highlighted in the onboarding requirements guide.
- You must submit the information exactly as it appears in official documents.
POST Create business
Important points
- 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
- There are certain mappings between the fields
tax_country
,sector
, andlegal_form
. Check this section 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
orregistration_type
business_purpose
-
tax_information
tax_country
tax_confirmation
registration_issuer
: For Germany, it must be preceded by AMTSGERICHT (e.g., AMTSGERICHT Berlin).registration_number
registration_district
terms_conditions_signed_at
data_terms_signed_at
fatca_relevant
fatca_crs_confirmed_at
Request URL:
POST /v1/businesses
Click here to view the full API reference.
Automatic data collection (Optional)
Simplify your customers' onboarding process by opting for the automatic data collection feature. With our external service provider, Business Registry, customers can enter the country and company name, and the remaining business data fields will be automatically filled out.
info
Automated data collection is an optional step that improves user experience. For more information on this feature and its associated cost, please 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
:
note
This endpoint may be used free of charge.
Request URL:
GET /v1/commercial_registrations/search_by_name?country={{}}&name={{}}
Example response
{
"name": "FLOOR 13 GmbH",
"registration_number": "HRB 198673",
"registration_issuer": "AMTSGERICHT MÜNCHEN"
}
Click here to view the full API reference.
GET Automatic business data collection
Use the following endpoint to automatically retrieve the remaining business details after obtaining the registration_issuer
and registration_number
from the response of the previous endpoint:
attention
- This endpoint has an associated cost per request. Contact your Partner Manager for more information.
- Please note that for companies in Germany, you must add
AMTSGERICHT
before the value of theregistration_issuer
, e.g., AMTSGERICHT MÜNCHEN.
Request URL:
GET /v1/commercial_registrations/find?registration_number={{}}®istration_issuer={{}}
Example response
{
"name": "FLOOR 13 GmbH",
"address": {
"country": "DE",
"postal_code": "86919",
"city": "Utting a.Ammersee",
"line_1": "Seestraße 9",
"line_2": ""
},
"legal_form": "GMBH",
"tax_country": "DE",
"registration_number": "HRB 198673",
"registration_issuer": "AMTSGERICHT MÜNCHEN",
"registration_date": "2012-05-09",
"registry_updated_at": "2015-11-17",
"legal_representatives": [
{
"first_name": "Stefan",
"last_name": "Schneider"
}
]
"commercial_registry_industry_key": [
"66190 - Sonstige mit Finanzdienstleistungen verbundene Tätigkeiten",
"70109 - Sonstige Verwaltung und Führung von Unternehmen und Betrieben",
"70220 - Unternehmensberatung",
"73110 - Werbeagenturen"
]
}
Click here to view the full API reference.
Foreign companies examples
If the company is not registered in Germany, you can still use this service for companies in other countries. The following examples describe how to find the business registration details for a French company.
note
The field registration_issuer
is only required for companies in Germany.
GET Search for business commercial registration (France)
Request
GET v1/commercial_registrations/search_by_name?name=PARISOL&country=FR
Response
{
"name": "PARISOL",
"registration_number": "513 937359",
"registration_issuer": null
}
GET Automatic business data collection (France)
Request
GET /v1/commercial_registrations/find?registration_number=513937359&country=FR
Response
{
"name": "PARISOL",
"address": {
"country": "FR",
"postal_code": null,
"city": "NANTERRE",
"line_1": "RUE D ARRAS 18",
"line_2": ""
},
"legal_form": null,
"tax_country": "FR",
"registration_number": "513 937359",
"registration_issuer": null,
"registration_date": "2009-07-27",
"registry_updated_at": null,
"legal_representatives": [
{
"first_name": "Stefan",
"last_name": "Schneider"
}
]
}
info
Check the appendix 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 the appendix 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.
attention
You have to make a separate API request for each document and specify the document_type
. See the appendix 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:
POST Upload a document
This endpoint uploads a document and links it to the business with the business_id
specified in the request URL.
You have to add the following properties to the request body:
document_type
: The document type. For a list of possible values, check the API reference.file
: The file to be uploaded.
note
The request body of this endpoint is a multipart/form-data content type and parameters are transmitted as form-data and not as a raw JSON string.
Request URL
POST /v1/businesses/{business_id}/documents
Click here to view the full API reference..
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
.
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 (Gesellschafter) 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, make sure to create and link all of them to the
business
object on our system to avoid any delays during the business identification process.
Legal representatives as legal entities
A business' legal representative could 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:
- Collect the business data of the legal entity acting as the legal representative and create a business resource for it.
- The natural persons who are the legal representatives of this legal entity are then the ones who will 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:
Related webhook events
Important points about data collection
- Please consider the special requirements for data collection highlighted in the onboarding requirements guide.
- You must submit the information exactly as it appears in official documents.
- When testing the process on Sandbox, please ensure that each person you create has unique values for
first_name
,last_name
,birth_city
, andbirth_date
. If you create over 1000 identical person resources, the API will return a400
error. - Don't use any personal data when testing this endpoint on 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
- 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:
POST /v1/persons
Click here to view the full API reference
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 toALONE
.
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:
Related webhook events
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
: Alegal_representative
could have atype_of_representation
, which indicates whether this legal representative can make decisions alone or jointly with other legal representatives. This attribute is optional. Possible values areALONE
,JOINT
, orOTHER
.power_of_attorney_confirmed_at
: In case ofJOINT
representation, legal representatives need to confirm the power of attorney's timestamp in thepower_of_attorney_confirmed_at
attribute.
Request URL:
POST /v1/businesses/{business_id}/legal_representatives
Click here to view the full API reference.
info
Check the FAQ for more information about legal representatives.
Step 4: Create Beneficial Owner(s)
In this step, you must do the following:
- 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 correspondingperson
object. - Include the definition of the beneficial owner in your UI.
Important
- If a business has more than one beneficial owner, make sure to create and link all of them to the corresponding
business
object to avoid any 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 notes
- 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
Please 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.
- 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.
- 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
- 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:
POST /v1/persons
Click here to view the full API reference
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:
Related webhook events
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.
note
Please note is that if you're creating a fictitious beneficial owner, the voting_share
is not required.
Request URL:
POST /v1/businesses/{business_id}/beneficial_owners
Click here to view the full API reference.
info
Check the FAQ for more information about beneficial owners.
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, please 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 aperson
or abusiness
must be the primary tax identification. If anothertax_identification
with the value ofprimary
set totrue
is created, it will set theprimary
value of the previously createdtax_identification
tofalse
. - A
person
orbusiness
may only have onetax_identification
percountry
. - When creating a
tax_identification
, explicitly collect thecountry
value from the user and do not default to their physical residence (i.e., thecountry
property of theperson
resource). - Check the Onboarding requirements guide 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:
Related webhook events
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 areNOT_ASSIGNED_YET
,NOT_ASSIGNED_BY_COUNTRY
,OTHER
.reason_description
: Applies only if thereason_no_tin
isOTHER
.tax_id_type
: (Only for Spain) Possible values areNIE
andNIF
.
Request URL
POST /v1/businesses/{business_id}/tax_identifications
Click here to view the full API reference.
Business tax declaration
Please 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.
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:
Related webhook events
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 areNOT_ASSIGNED_YET
,NOT_ASSIGNED_BY_COUNTRY
,OTHER
.reason_description
: Applies only if thereason_no_tin
isOTHER
.tax_id_type
: (Only for Spain) Possible values areNIE
andNIF
.
Request example:
POST /v1/persons/{person_id}/tax_identifications
Click here to view the full API reference.
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.
attention
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, chooseBUSINESS_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 areFULL
orPARTIAL
.minimum_amount
: Minimum amount of the used limit to be repaid at the end of each billing cycle. Only relevant in caseupcoming_type
is set toPARTIAL
.minimum_percentage
: Minimum percentage of the used limit to be repaid at the end of each billing cycle. Only relevant in caseupcoming_type
is set toPARTIAL
.
-
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
// 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.
Click here to view the full API reference.
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
GET /v1/credit_card_applications/{id}
Click here to view the full API reference.
Application status flow
The following diagram shows the different statuses and transitions for a credit card application:
Step 7: Complete the business identification (BKYC) and due diligence process
In this step, you must do the following:
- 7.1. Trigger the 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.
- 7.2. Implement the manual video identification endpoints.
- 7.3. Implement the endpoints related to compliance questions, forward any questions (if any) to the business' legal representatives, and send the answers back to Solaris
- 7.4. Make sure all natural persons linked to the business successfully passed the customer due diligence checks.
- 7.5. Complete the FATCA-related checks to ensure that all natural persons linked to the business are NOT FATCA-relevant.
attention
- Please note that 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: Solaris' Banking Operations team verifies the completeness and accuracy of the data submitted by the business customer and ensures that all legal representatives and ultimate beneficial owners are disclosed and linked to the business.
- Video identification(s): 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 notes
- The business must pass both of these checks before the business identification process can be considered successful.
- Only legal representatives and authorized persons need to undergo video identification; ultimate beneficial owners 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:
Related webhook events
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). You have to specify the identification method
in the request body. The default method is idnow
.
Request URL
POST /v1/businesses/{business_id}/identifications
Response
The API 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
. You must call the API to monitor the progress of this process, particularly the legal_identification_missing_information
field, where Solaris will highlight compliance questions requiring answers from the business.
Click here to view the full API reference.
7.2 Manual video identification
Your solution might need to trigger video identification manually in the following cases:
- New legal representatives are found during the legal identification process. In this case, you'll receive a webhook notification from the event
legal_representative
, which includes thelegal_representative_id
of the discovered legal representative. Afterward, initiate a video identification with IDnow and trigger the identification session by redirecting the legal representative to the provided URL. - If any of the initially triggered video identifications fail, manually trigger a new identification.
API reference
For a complete list of endpoints, properties, and examples related to customer identification (KYC), visit the following link:
note
- The previous link includes all endpoints for different KYC methods. This section includes the relevant endpoints required for video identification with IDnow.
- Please note the system prerequisites needed for IDnow here.
Related webhook events
POST Create identification
Call this endpoint to create an identification resource for the person specified in the request URL, and add the following properties to the request body:
method
: The identification method to use. In this case, set the value toidnow
.language
: The customer's preferred language for the identification process. Possible values areEN
andDE
.proof_of_address_type
: The type of document submitted by the customer as a proof of address. This field is mandatory if the customer's identification document does not include their address.proof_of_address_issued_at
: The date when the proof of address document was issued. This field is mandatory if the customer's identification document does not include their address. It may not be older than 6 months.
attention
Note that this endpoint does not actually trigger the identification process with the provider. Calling the PATCH Request an identification endpoint will trigger the process.
Request example
POST /v1/persons/{person_id}/identifications
{
"method": "idnow",
"language": "DE",
"proof_of_address_type": "GAS_BILL",
"proof_of_address_issued_at": "2022-09-21"
}
Response example
The API call will return an identification object with a unique id
(i.e., identification_id) and an initial status
of created
.
{
"id": "6dc54352d6793a892e0702850d07b831cidt",
"reference": null,
"url": null,
"status": "created",
"completed_at": null,
"method": "idnow",
"proof_of_address_type": "GAS_BILL",
"proof_of_address_issued_at": "2022-09-21",
"language": "DE",
"iban": null,
"terms_and_conditions_signed_at": null,
"authorization_expires_at": null,
"confirmation_expires_at": null
}
Click here to view the full API reference.
GET List supported documents for a person identification
The purpose of this endpoint is to provide you with a list of supported identification documents per issuing country. You can use this endpoint to inform your customers of the required documents before starting the identification process.
The API call returns an array of document types with the corresponding issuing countries listed as ISO country codes (ISO-3166-1 alpha 2). If a customer provides a document type that is not supported, their identification process will fail.
Request URL
GET /v1/persons/{person_id}/identifications/{id}/supported_documents
Click here to view the full API reference
PATCH Request person identification
Call this endpoint to trigger the identification flow with IDnow for the specific customer.
Request URL
PATCH /v1/persons/{person_id}/identifications/{id}/request
Response example
The API call returns the identification object with the status pending
. The status will remain pending
until the customer completes the identification. Additionally, the payload includes the following key properties:
url
The URL to which you must redirect the customer to complete the identification. Valid for 14 days.reference
: An internal IDnow identification token for the session (format: ABCDEFGH). Do not share this with the customer under any circumstances.
{
"id": "6dc54352d6793a892e0702850d07b831cidt",
"reference": "TST-KCCEY",
"url": "https://go.test.idnow.de/solarisbankvideoidentsandbox/identifications/6dc54352d6793a892e0702850d07b831cidt",
"status": "pending",
"completed_at": null,
"method": "idnow",
"proof_of_address_type": "GAS_BILL",
"proof_of_address_issued_at": "2022-09-21",
"language": "DE",
"iban": null,
"terms_and_conditions_signed_at": null,
"authorization_expires_at": null,
"confirmation_expires_at": null,
"estimated_waiting_time": 60
}
Click here to view the full API reference.
IDnow video identification session
Your customer will now be redirected to an IDnow-branded landing page, where they consent to IDnow's Terms & Conditions and confirm that they have a valid ID document for the video identification. They must also provide a valid mobile number, which the IDnow agent will verify during the call using an SMS OTP.
Customers may choose to conduct the call with a German- or English-speaking IDnow agent. When the video identification call begins, the agent will greet the customer on behalf of either you or Solaris (depending on your agreement with Solaris). The agent will then verify the customer's mobile number, first name, and last name. If there are any missing data properties, the agent will provide these as well, and they will be added to the customer's person
resource.
GET Retrieve person identification
Once the identification completes successfully, call this endpoint to retrieve the finalized person identification. If you use the include_documents
filter, the API will also return the documents submitted by the customer during the process. To download any of these documents, use the document's unique id
to call the document download endpoints.
Request URL
GET /v1/persons/{person_id}/identifications/{id}
Click here to view the full API reference.
Other identification endpoints
- GET Index identifications for a person
- POST Upload documents for a person identification
- GET List the IDnow attempts of a person identification
- GET List IDnow legitimation data.
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 to be uploaded.
How to identify compliance questions and documents?
- If Solaris needs further clarification during the business identification, you will receive a notification on the BUSINESS_IDENTIFICATION webhook.
- Call the GET Retrieve a business identification endpoint to retrieve the required details.
Only compliance questions
If Solaris has compliance questions for the business, the field legal_identification_missing_information
will contain only COMPLIANCE_QUESTIONS
as a value. In this case, customers can simply provide answers to the questions on your frontend. Additionally, we recommend to have document upload set as optional to enable the customer to add supporting documents.
Example payload
{
"legal_identification_status": "information_required",
"legal_identification_status_missing_information": "COMPLIANCE_QUESTIONS"
}
Both compliance questions & documents
If Solaris requires both answers to compliance questions and documents from the business, the field legal_identification_missing_information
will contain COMPLIANCE_QUESTIONS
and a document_type
enum, e.g., FOUNDATION_DOCUMENT
or any other document_type
. In this case, customers need to provide answers to the questions on your frontend. Additionally, they need to upload the required document type specified in the payload. You should have document upload set as mandatory on your frontend and submit the document to Solaris using the POST Create a Business Document endpoint.
Example payload
{
"legal_identification_status": "information_required",
"legal_identification_status_missing_information":
[
"COMPLIANCE_QUESTIONS",
"FOUNDATION_DOCUMENT"
]
}
How to retrieve compliance questions and provide answers?
In case your customer must answer compliance questions, you need to call the following endpoints to retrieve the questions and allow to the customer to answer them on your frontend:
GET Retrieve compliance questions
To get the compliance questions, call the following endpoint:
Request URL
GET /v1/businesses/{business_id}/identifications/{business_identification_id}/legal_identification/questions
Response example
The API call returns an object that includes the question(s) with a unique ID and the corresponding text. You must redirect these questions to your customers and retrieve their answers as part of your workflow. You should also provide a dedicated page for answering all questions separately.
{
"question_id": "ebb463137becc09788dfe21fc066e670qstn",
"question_text": "Please provide the license for security / guarding services (Bewachungsgewerbe): § 34a GewO",
"legal_identification_id": "14eb210435e09ab7f6a06c8b9b86ce27lid",
"business_identification_id": "4c74c804eaea5d2a2d64ef400a27a4d3bid",
"business_id": "880bbac68a34add190786b9c74f4c82fcbiz",
"answer_id": null,
"answer_text": "string",
"asked_at": "2021-07-16T13:38:06.000Z",
"answered_at": null
}
Click here to view the full API reference.
Create answers for compliance questions
After receiving the compliance question answers from the customer, call the following endpoint to share them with Solaris. Note that you must make a separate API call for each answer.
Request URL
You have to provide the question's answer in the request body of this endpoint.
POST /v1/businesses/{business_id}/identifications/{business_identification_id}/legal_identification/questions/{question_id}/answers
Click here to view the full API reference.
PATCH Update business legal identification
Call this method to update the legal identification and mark it as ready to resume the identification process after adding all answers to the compliance questions. This endpoint changes the legal_identification_status
from information_required
to pending
when called.
Request URL
PATCH /v1/businesses/{business_id}/identifications/{id}/legal_identification/mark_as_ready
Click here to view the full API reference.
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.
7.5 Screening for FATCA indicia
To comply with the Foreign Account Tax Compliance Act (FATCA), Solaris is required to perform checks to determine whether the customer is subject to US tax law. These checks are in addition to the self-declaration during the Legal and Compliance screen.
To perform the FATCA checks, parse the person
and identification
resources using the following endpoints:
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
andaddress_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.
attention
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
POST /v1/credit_card_applications/{id}/finalize
Click here to view the full API reference.
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.
note
- 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 section to know about allowed transactions.
Check the account management guide 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 explicitely 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
.
API reference
For a complete list of endpoints, properties, and examples related to the business authorized person
resource, visit the following link:
POST Create authorized person
note
- 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 withtype_of_representation
set toALONE
ornull
must approve the action by confirming the request via 2FA.
Request example:
You must add the person_id
of the the legal representative(s) who will act as an authorized person on the account in the request body.
// POST /v1/businesses/{business_id}/accounts/{account_id}/authorized_persons
{
"authorized_person_id": "3b8cfd40fb4dce5a231251ea06a014cper"
}
Example response:
{
"id": "568b5241afd0ce435c56ea0efef2bd0dcpea",
"authorized_person_id": "3b8cfd40fb4dce5a231251ea06a014cper"
}
Click here to view the full API reference.
note
In case of additional authorized persons who are not legal representatives, you must first create a person resource for each authorized person, including 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 a reference account for the business and afterward set the credit card limit on the business' account.
9.1 Create reference account for the business
API reference
Visit the following link to find all the endpoints related to the reference account resource, including related properties and examples.
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
: SelectB2B
.
Request URL
// 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
.
Click here to view the full API reference.
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.
note
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
// 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.
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
POST /v1/persons
Click here to view the full API reference
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.
Related webhook events
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, and include the customer's person_id
in the request URL.
Request example:
POST /v1/persons/{person_id}/mobile_number
{
"number": "+15550101"
}
Response example:
The API returns a mobile_number
resource with a unique id
and attaches it to the person
resource.
{
"id": "91e4d939d781b8eb30d1ee86809761c2cmno",
"number": "+15550101",
"verified": false
}
Click here to view the full API reference.
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 example:
POST /v1/persons/{person_id}/mobile_number/authorize
{
"number": "+15550101"
}
Response example:
{
"id": "91e4d939d781b8eb30d1ee86809761c2cmno",
"number": "+15550101",
"verified": false
}
Click here to view the full API reference..
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 example:
POST /v1/persons/{person_id}/mobile_number/confirm
{
"number": "+15550101",
"token": "212212"
}
Response example:
{
"id": "91e4d939d781b8eb30d1ee86809761c2cmno",
"number": "+15550101",
"verified": true
}
Click here to view the full API reference.
Mobile number management
For more information about how to manage mobile numbers, check the related guide.
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 section.
All other cardholders will be identified using a light KYC method, such as IDnow AutoIdent. 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:
// POST /v1/persons/:person_id/identifications
{
"idnow_autoident"
}
Click here to view the full API reference.
PATCH Request an identification for a cardholder via AutoIdent
Call this endpoint to trigger the KYC flow.
// POST /v1/persons/:person_id/identifications
{
"idnow_autoident"
}
Click here to view the full API reference.
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.
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.type
: The card type. View here a list of possible card types for each customer segment.
Request URL:
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
.
{
"id": "8febdba4912a747808ccc6f95f82aaa4",
"status": "PROCESSING"
}
Click here to view the full API reference.
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:
GET /v1/cards/{card_id}
Click here to view the full API reference.
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:
POST /v1/cards/{card_id}/activate
Click here to view the full API reference.
Cards servicing
For more information about cards servicing, check the Card creation and servicing guide.
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.
info
See the Cards overview page 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.
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).
attention
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
// 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.
GET Index a credit card bill
Call this endpoint to retrieve a credit card bill.
note
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
GET /v1/credit_card_bills/{bill_id}
Click here to view the full API reference.
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:
-
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 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 endpoint. This will create a credit card application termination resource.
-
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.
- You will receive notifications on the CREDIT_CARD_APPLICATION_TERMINATION webhook event 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
orCARD_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:
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.
POST Revoke a termination request
This endpoint revokes a request to terminate a credit card.
Request URL:
POST /v1/credit_card_terminations/{id}/revoke
Click here to view the full documentation.
What's next?
Congratulations! You've successfully integrated 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
- Reference accounts API reference documentation
- Video Identification
- Account management guide
- Card creation & servicing guide
- SEPA Transfers Overview
- SEPA Direct Debit Transfers
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 the 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 - A corporation whose shares are regularly traded on at least one recognized stock exchange (or a company affiliated with it), a government entity, an international organization, a central bank, or a legal entity wholly owned by NFE |
NFE_PASSIVE Passiver NFE |
Passive NFE - Non-active NFE |
NFE_PASSIVE_INVESTMENT |
Inactive NFE/NFFE or an Investment Entity that is a Financial Institution in a jurisdiction not participating in the CRS and that 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 a company's annual financial statement. |
KYC_REPORT |
The KYC report generate after a successful customer identification. |
ID_DOCUMENT |
An person's identification document, such as passport or ID. |
SIGNATURE |
A signature example. |
PICTURE |
A picture or a 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_CHECK |
A register check. |
REGISTER_EXTRACT |
A business or a company's commercial register excerpt or a similar document. |
FOUNDATION_DOCUMENT |
The foundation document of a company or business. |
SCHUFA_COMPACT_REPORT |
A compact SCHUFA report. |
SCHUFA_GWG_REPORT |
A GWG 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 business or a company's shareholders agreement. |
SHAREHOLDERS_LIST |
A business or a company's shareholders list. |
TRADING_LICENSE |
A business or a company's trading license. |
TRANSPARENCY_REGISTER_EXTRACT |
An extract of a 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 are generated. You must redirect the customer to the URL to complete the identification process with IDnow. |
pending_failed |
The identification is currently under review. You cannot offer banking services to the customer at this stage. The identification might eventually turn to successful, but it is unlikely. |
successful |
The video identification was successful. The customer can be onboarded. Please note that the customer's data might have been updated during the identification session. |
aborted |
The customer aborted the identification process. The customer can still video-identify using the same URL. |
canceled |
The provider canceled the video identification. The customer should video-identify again using the same URL. |
failed |
The identification was unsuccessful. You cannot onboard the customer or offer any banking services to them. |
IDnow provides a reason whenever the identification has a canceled
or
aborted
status. No reason can be disclosed for the final failed
status.
Tax country
The following tables includes the possible values for the field tax_country
:
Enum | Country |
---|---|
DE |
Germany |
IT |
Italy |
AT |
Austria |
GB |
United Kingdom |
CZ |
Czech Republic |
FR |
France |
BE |
Belgium |
LU |
Luxembourg |
NL |
The Netherlands |
ES |
Spain |
PT |
Portugal |
Sector
The following are the possible values for the field sector
.
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_WORKMAN
OTHER_COMPANIES
OTHER_PRIVATE_INDIVIDUAL
Legal form
The selected value for the field tax_country
influences the accepted values for the field legal_form
. The following are the possible values for the field legal_form
per 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
Solaris accepts the following legal forms for companies in Germany and other countries that are not specified in our system:
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_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
Please note that there are certain dependencies between the fields tax_country
, sector
, and legal_form
. For example, based on the value selected for the field tax_country
, certain values will be accepted for the field sector
, and based on the value selected for the field sector
, certain values will be accepted for the field legal_form
.
The following sections give an overview of the mapping between these fields.
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 |
|
All other countries |
|
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 |
|
OTHER_COMPANIES_WORKMAN |
|
FOREIGN_COMPANIES |
|
GERMAN_BANKS |
|
MUNICIPALITY_AND_MUNICIPALITY_ASSOCIATION |
|
ECONOMICALLY_SELF_EMPLOYED |
|
NON_PROFIT_ORGANIZATION |
|
Legal identification status
The following table includes the possible values for the field legal_identification_status
for the legal identification process of the business legal entity carried out by Solaris and the related description of each status.
Status | Description |
---|---|
created |
The legal identification was initiated and will be conducted shortly. |
information_required |
The legal identification cannot be conducted because Solaris is missing one or more required documents. Refer to the legal_identification_missing_information array to determine which document(s) is/are missing. |
blocked_internally |
The legal identification is put on hold due to additional internal checks |
successful |
The legal identification was conducted successfully. |
failed |
The legal identification was marked as failed. Refer to the legal_identification_reason to find out why. |
expired |
The legal identification was not updated to terminal status in 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), including the legal identification of the business legal entity carried out by Solaris and the video identification of the business's natural persons.
Status | Description |
---|---|
created |
The legal identification was initiated and will be conducted shortly. |
pending |
A business identification (solarisIdent) is mark_as_successful by partner |
successful |
Both steps of the business identification process (solarisIdent) were completed successfully. |
failed |
The business identification process (solarisIdent) will not continue. The business couldn't be identified. A reason will not be provided. Verify the status of either the legal identification or the individual video identifications instead. |
expired |
The business identification process (solarisIdent) was not completed within six months of being initiated. Either the legal identification or one of the individual video identifications was not finished on time. |
Appendix II: BKYC required documents
The following table includes the required documents for identification for each legal form:
Legal form | Required documents - Descriptions | Required documents - Enum values | Notes |
---|---|---|---|
ADOR |
|
|
|
AG |
|
|
Document must include a notarial stamp, seal, and signature. |
EG |
|
|
|
EK |
|
|
|
EV |
|
|
|
GBR |
|
|
Documents must be signed by all business partners. Solaris may request additional information based on the document contents (e.g., all shareholders, distribution of shares, etc). For GmbH/UG & Co. KGs, these requirements apply to the entity that is registered in the trade register as shareholder (i.e., Komplementär-Gesellschafter ). |
GMBH |
|
|
|
GMBH_I_GR |
|
|
Documents must be notarized. |
GMBH_CO_KG |
|
|
Document must include a notarial stamp, seal, and signature. |
KDOR |
|
|
|
KGAA |
|
|
|
LTD |
|
|
Document must include a notarial stamp, seal, and signature. |
MUNICIPAL_COMPANY |
|
|
The document requirements are dependent on the legal form of the company. For the onboarding of a municipal company, please check the relevant requirements in this table for the specific legal form. |
MUNICIPALITY |
|
|
|
NEV |
|
|
|
OHG & KG |
|
|
|
PARTG |
|
|
Document must include a notarial stamp, seal, and signature. |
PRIVATE_PERSON |
|
|
|
SAVINGS_BANK |
|
|
|
SE |
|
|
Document must include a notarial stamp, seal, and signature. |
SELF_EMPLOYED |
|
|
|
SOLE_PROPRIETORSHIP |
|
|
|
UG |
|
|
Document must include a notarial stamp, seal, and signature. |
UG_CO_KG |
|
|
Document must include a notarial stamp, seal, and signature. |
UG_I_GR |
|
|
Documents must be notarized. |
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 | HRB198673 | MÜNCHEN | FLOOR 13 GMBH |
DE | HRA23670 | BERLIN | OHG Erich-Steinfurth-Strasse 7 |
DE | HRA4029 | WITTLICH | SG-AUTO-WASCHTREFF WERNER KG |
DE | HRB571744 | STUTTGART | Klima Investment GmbH & Co. KGaA |
DE | HRB18686 | Bonn | Tekcor 1. V V UG (haftungsbeschraenkt) |
DE | HRB54636 | DUESSELDORF | AF Azurit AG |
DE | HRA204605 | Stiftung St., Joseph | Stift, Stiftung kirchlichen Rechts |
DE | HRA94238 | HAMBURG | PR-AUTO Peter Reimann e.K. |
ES | A46103834 | ---- | MERCADONA SA |
ES | N00434391 | ---- | HYUNDAI MOTOR EUROPE SE |
ES | B17262213 | ---- | AUTOLINE SOCIEDAD LIMITADA |
ES | B19202969 | ---- | SEIJAS ALONSO YA CIA, S.R.C. |
ES | G91487967 | ---- | CASAS Y CAMPOS S.C. |
ES | W2501222J | ---- | COLLIERS INTERNATIONAL INVESTMENT & ASSET MANAGEMENT |
ES | D81586729 | ---- | COLGATE PALMOLIVE HOLDING S COM P A |
FR | 513937359 | ---- | PARISOL |
FR | 332199462 | ---- | NATIOCREDIMURS - SOCIETE EN NOM COLLECTIF |
FR | 582051843 | ---- | GASTINNE RENETTE SOCIETE EN COMMANDITE SIMPLE |
FR | 304463284 | ---- | AVENTIS PHARMA S.A. |
FR | 807956966 | ---- | MENTION PARC AUTO |
FR | 539358994 | ---- | SOCIETE EN COMMANDITE PAR ACTIONS ETCHE ONA |
FR | 438755092 | ---- | SOC EUROPEEN DE BREVETS AUTOMOBILES SE |
IT | TO824350 | ---- | BUSINESS NETWORK S.P.A. |
IT | ME247881 | ---- | TORO S.C.R.L. |
IT | GE447187 | ---- | SOCIET SEMPLICE MONT BLANC |
IT | PN51072 | ---- | S.N.C. GEFCO DI LUIGI DAL BON & C |
IT | AO43300 | ---- | CALDARELI SERVIZI ASSICURATIVI S.A.A DI VALTER CALDARELLI |
IT | MI1712979 | ---- | LUIGI DE PRA S.A.P.A |
IT | AN146244 | ---- | FIAT SERVIZI PER L'INDUSTRIA S.C.P.A O SEMPLICEMENTE SE.P.IN |
IT | FI514669 | ---- | SCLE DELTA TRAZIONE SOCIETA' CONSORTILE A RESPONSABILITA |
IT | TO1215674 | ---- | S.R.L. SPORTIVA DILETTANTISTICA SPORT LAB |
IT | TP131030 | ---- | MAIORANNA GIUSEPPE PICCOLO IMPRENDITORE EDILE |
note
For non DE
companies, the registration_issuer is not necessary.
Appendix IV: 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). In there you'll find all the official legal representatives which you would need to tell us. As a further indication, these people also need to be listed in the Imprint of your website (Impressum).
The Legal Representative has sole representations 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 would need the complete set of information for regulatory purposes. Therefore, please enter the information about 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; please submit the information as it is currently written in the official register. If you already know that these individuals will change, then please inform your Onboarding manager accordingly, and they will help sort things out.
Why do I have to submit all legal representatives here?
As a bank, Solaris is obliged to keep a record about the companies it works with and check whether the provided information is correct. Solaris makes every effort to keep the flow as smooth as possible. Nevertheless, the law stipulates that Solaris must collect this information for all legal representatives.
Beneficial Owner FAQs
What is a “Beneficial Owner”?
A so-called “Beneficial Owner” is a natural person (a human) who owns directly or indirectly more than 25% of the voting shares of a legal entity today. Ultimately it is the person who benefits from the entered agreement and has the eventual decision power. It can never be another company, as Solaris would need to look up the owner of that company. There is a more detailed (legally-worded) definition here as well. It may significantly help cases with beneficial owners incorporated as trusts or other non-commercial entity types.
The company has no beneficial owners – how should I proceed?
It might be the case after a thorough investigation that nobody has directly or indirectly enough voting shares of the business. In that case, Solaris is required to take the legal representatives instead. Please enter their information accordingly.
I don't know the ownership structure of the company – how shall I proceed?
Ultimately, the ownership structure of a company is determined in the shareholder agreement (Gesellschaftervertrag), which has been signed at least when founding the entity. In the meantime, this may have changed but would need to be noted in an amendment or update of this contract.
Another company owns the company – what shall I do now?
Please submit the information of the natural person (human) owning your shareholders. If this is also another company (holding- or corporate-structure), you would need to follow the trail of indirect ownership until you either find an individual or the ownership is diluted under 25% ownership (through indirect ownership).
What do you mean by direct or indirectly & how do I calculate that?
Direct ownership refers to a natural person (individual) owning him-/herself voting shares in the business. Indirect ownership refers to somebody owning one entity that then owns a specific part of the business. It also qualifies if the entities are stacked into each other (several companies in between). Also, if one individual holds voting shares via different entities in the business, you would need to add up his/ her total indirect ownership to see whether the total engagement reaches more than 25%. When the shareholding structure is stacked over several hierarchies, you multiply the ownership-quotas of each entity to get the ultimate quota for the respective person.
Example:
Adello GmbH needs to provide its beneficial owners. Adello's shareholders are Peter 30% of shares, Susi 10% of shares, Anne 10% of shares, and Toscana GmbH 50% of shares. Toscana's shareholders: Hugo 75% of shares and Marie 25% of shares Direct beneficial owners of Adello: Peter Indirect beneficial owners of Adello: Hugo with 37,5% of shares (Toscana's share in Adello 50% x Hugo's ownership quota in Toscana 75%). Please note that Marie is not a beneficial owner as she has indirectly only 12,5% in Adello.
We have different kinds of shares – which shares are the decisive ones?
Please refer to the shares with decisive voting power as the beneficial owner is ultimately the person deciding the significant strokes of the company.
Does the UBO need to do something, for instance, sign something or perform a video identification?
No, please only submit the information of that person as stated in his/her official documents (ID card or passport). There is no further double-checking of that information. Therefore, the beneficial owner does not need to do anything during this identification process.