[2] Data collection

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude
• Connect to Cursor

  Install MCP server on Cursor
• Connect to VS Code

  Install MCP server on VS Code

Collecting customer data is one of the first steps to onboard your customers on any of Solaris' products.

You must collect the required data points from all your customers in your sign-up flow and pass it to Solaris by creating either a person or business resource.

Customer data resource types

The customer data is stored on Solaris' system in two types of resources:

1. Person resource:

The person resource represents the customer's personal and financial data at Solaris. It contains all mandatory customer data, and links to other resources created for the customer (e.g., accounts, tax identifications). It's used to store the customer data of the following customer types:

• Retail customers (B2C)
• Authorized persons on a retail account
• Freelancers
• The natural persons associated with a business, such as legal representatives, beneficial owners, and authorized persons.

For more information about the person resource, check the API reference.

2. Business resource:

The business resource represents the data of a business' legal entity at Solaris. It contains all mandatory business data, as well as links to other resources created for the business (e.g., legal representative(s), beneficial owner(s), accounts, tax identifications, etc.).

For more information about the business resource, check the API reference.

The following diagram describes the resources that you need to create to store customer data:

Which customer data should you collect?

Solaris requires different data points depending on the customer type, country, and product. The customer data points are used during onboarding and customer identification (KYC). Additional data points related to credit risk and scoring are also required for lending products.

The following sections include the mandatory data points for each use case.

Digital Banking & Cards

If you're onboarding customers for Digital Banking & Cards products, the following data points are required for each customer type and country:

Retail customers (B2C)

Freelancers

Business customers (B2B)

Legal representatives

Authorized persons

Authorized persons on a business account are treated similar to a business' legal representative. Please collect the data points required for legal representatives above.

Beneficial owners

Lending Standalone

If you're onboarding customers for lending products, you need to collect two different sets of data points:

• Personal data points: Stored in the person or business resource and used for onboarding and the KYC flow.
• Credit risk-related data points: Stored in the specific lending product application (e.g., loan application, credit line application, etc.). It includes self-declared information about the customer's income, expenses and existing credit repayments, and used by the credit scorer to determine the customer's credit risk and eligibility.

The following diagram describes the resources that you need to create to store customer data for lending products:

The required data points for lending vary per product, customer type, and country. In the following sections, you'll find the customer data points required for each product.

Fronting

Fronting products are offered to B2C (in Germany) and B2B customers (in Germany & France).

The following data points are mandatory for onboarding and KYC. Additional credit-risk related fields are also mandatory, but stored in a product-specific resource (e.g., fronting loan application resource). Check the respective fronting product guide for more details.

Retail customers (B2C) - Germany

• salutationNote:MR for male, MS for female, null for gender-neutral.
• 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
  • line_1
  • line_2
  • postal_code
  • city
  • country
• birth_date
• birth_city
• birth_country
• nationality
• employment_status
• mobile_number
• terms_conditions_signed_at
• data_terms_signed_at
• own_economic_interest_signed_at

Business customers (B2B)

Legal representatives

Beneficial owners

Loans

Loans are offered to B2C customers (in Germany).

The following data points are mandatory for onboarding and KYC. Additional credit-risk related fields are also mandatory, but stored in a product-specific resource (e.g., loan application resource). Check the respective loans product guide for more details.

Retail customers (B2C) - Germany

Germany

• salutationNote:MR for male, MS for female, null for gender-neutral.
• 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
  • line_1
  • line_2
  • postal_code
  • city
  • country
• birth_date
• birth_city
• birth_country
• nationality
• employment_status
• tax_information
  • marital_status
• mobile_number
• terms_conditions_signed_at
• data_terms_signed_at
• own_economic_interest_signed_at

Splitpay

Splitpay or credit lines are offered to B2C and freelancer customers (in Germany).

The following data points are mandatory for onboarding and KYC. Additional credit-risk related fields are also mandatory, but stored in a product-specific resource (e.g., credit line application resource). Check the respective Splitpay product guide for more details.

Retail customers (B2C) - Germany

• salutationNote:MR for male, MS for female, null for gender-neutral.
• 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
  • line_1
  • line_2
  • postal_code
  • city
  • country
• birth_date
• birth_city
• birth_country
• nationality
• employment_status
• tax_information
  • marital_status
• mobile_number
• terms_conditions_signed_at
• data_terms_signed_at
• own_economic_interest_signed_at

Freelancers - Germany

• salutationNote:MR for male, MS for female, null for gender-neutral.
• 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 (Home address)
  • line_1
  • line_2
  • postal_code
  • city
  • country
• birth_date
• birth_city
• birth_country
• nationality
• employment_status Possible values below:
  • FREELANCER
  • SELF_EMPLOYED
• tax_information
  • marital_status
• mobile_number
• business_trading_name
• business_address_line_1
• business_address_line_2
• business_postal_code
• business_city
• business_country
• business_purpose
• nace_code Relevant NACE codes up to level 4.
• terms_conditions_signed_at
• data_terms_signed_at
• own_economic_interest_signed_at

KYC Standalone

If you're only integrating one of Solaris' KYC methods as a standalone product without provisioning any other banking solution to your customers, usually you only need to collect a minimal set of data points from your customers.

For more information, visit the respective integration guide of your desired KYC method here.

Important considerations for data collection

Name validation

Solaris validates the values entered for the fields first_name and last_name. Please ensure your solution applies the following sanitization rules to these fields:

• It must not be longer than 50 characters.
• It must not start with a whitespace.
• It must not include any symbols or emojis.

Address validation

Your solution must implement address validation to ensure that your system rejects non-existent or wrong address entries before the customer goes through the identification flow. In addition, please note the following best practices:

• Select a reliable provider to ensure the accuracy and actuality of data.
• Address validation must happen in real-time when the customer enters their address during the onboarding flow.
• The system can make auto-complete suggestions to the customer when entering the address. Additionally, it must reject non-existent or wrong entries.
• If the address validation fails, the customer can enter a nearby address and proceed with the identification flow. However, the customer must submit a proof of address afterward to customer support, such as a rental contract, electricity bill, or certificate of residence in Germany (i.e., Meldebescheinigung).

Spanish addresses requirements

For Spanish addresses, you must collect the following parameters and store them in dedicated fields in your database:

Type of street

Province

Customer address reporting

For spanish addresses, you're required to generate and upload a weekly CSV file containing all address data for every customer with ES IBAN residing in Spain present in your database.

Contact your partner manafer to know more details about the upload method.

File requirements

• Format: UTF-8
• Filename: CustomerSpainAdress_:PartnerUID:_YYYY-MM-DD.csv, where :PartnerUID: is replaced with with your specific Partner UID value.
• Field separator is ,
• A header

Note about branching

Solaris may restrict the residency countries that are allowed for customers onboarding to a specific branch. If you attempt to create a customer with a residency country that is not allowed for the given branch, the API will return a 400 error and provide a list of allowed residency countries.

Example:

{
    "errors": [
        {
            "id": "24b0e02a-341d-40bc-9e52-0d9f8cc8c6eb",
            "status": 400,
            "code": "invalid_model",
            "title": "Invalid Model",
            "detail": "country Residency Country is not allowed for this branch,allowed residency country values for branch \"null\" are [\"DE\", \"FR\"]",
            "source": {
                "field": "country",
                "message": "Residency Country is not allowed for this branch,allowed residency country values for branch \"null\" are [\"DE\", \"FR\"]"
            }
        }
    ]
} 

Please contact your Partner Manager for information about which residency countries are allowed for your branch(es).

Enums

Annual income range

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

French birth provinces

This table maps the INSEE code of each French province with the name to display to your customers in a drop-down menu as well as the value to assign to the birth_province property of the Person.

Legal form per country

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.

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.

NACE code

The Statistical Classification of Economic Activities in the European Community, commonly known as NACE, is the industry standard classification system used in the European Union.

NACE uses four hierarchical levels:

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

The first four digits of the code, which is the first four levels of the classification system, are the same in all European countries. National implementations may introduce additional levels. The fifth digit might vary from country to country and further digits are sometimes placed by suppliers of databases.

For example, if the NACE code A 01.11 (Growing of cereals (except rice), leguminous crops and oil seeds) would apply to the person/business, supply the value like such:

nace_code = "A 01.11"

Please visit this site for the list of values of NACE codes values you need to implement in your solution. The list is available in multiple languages.

NACE codes are mandatory for B2B and freelancer customers in Germany, Italy, and Spain. For France, NACE codes are excluded due to the usage of different coding system CODE NAF.

Mobile number collection

Collecting mobile numbers from your customers has its own requirements. Whereas the field mobile_number is collected and stored in the person resource, you must create and verify the number using our dedicated mobile number endpoints.

Through this flow, a mobile number is created and then verified by initiating an SMS OTP challenge, which the customer must use to verify the number.

Please note, however, the following use cases:

• Digital Banking & Cards: You can combine the device binding flow with the mobile number verification to verify the number and the device using one SMS OTP for better user experience.
• Lending products: Most lending products use IDnow as the identification method. In this case, you don't have to initiate the mobile number verification because the mobile number will be verified during the KYC flow.