Business Fronting Loans

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

Introduction

This guide explains the integration process for the Solaris Business Fronting Loans product (B2B), including mandatory data collection, endpoints, and webhooks.

Product overview

What is a fronting loan?

Solaris fronting loans solution allows you to offer single loans to your customers by leveraging Solaris' banking license. As the fronting bank, Solaris takes over the functions that require a banking license, such as customer identification and vetting (KYC/BKYC), credit risk checks, and loan origination and payout.

After a loan is paid out to the requesting customer, Solaris sells the loan agreement and receivables back to you or other investors. Therefore, fronting loans don't involve servicing activities from Solaris, such as collection or dunning.

How does it work?

In the lifecycle of a fronting loan, Solaris acts as the fronting bank that performs the initial regulatory steps until a loan is paid out.

• You start the process by collecting the required information from your customers and doing your internal due diligence and credit risk checks.
• After you approve the customers, prepare the loan agreement and applicable interest rates and pass all the details and loan application to Solaris.
• Your customers must go through an identification process (KYC/BKYC) and credit risk checks by Solaris to approve or reject the loan application.

Money flow:

After successful identification and approval of the loan application, the money flow goes as follows:

• Solaris triggers the loan payout by sending the requested loan amount to the customer's account.
• Solaris sells back the loan agreement and receivables to you or other investors, who take care of the rest of the loan lifecycle.

Available markets

Business fronting loans are currently available only for business customers in Germany and France.

System prerequisites

Before integrating Business Fronting Loans, you must implement the following requirements:

1. Technical setup

Set up your environment and get your authentication keys. For instructions, see 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 explains how to create these screens and lists their mandatory contents.

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

• Collect the customer's consent to Solaris' 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.

Webhooks

Subscribe to the following webhook events to automate your processes:

• BENEFICIAL_OWNER: A beneficial owner was created or updated.
• BUSINESS_CHANGED: One or more attributes of the business changed.
• BUSINESS_DELETED: The business and its data were deleted (GDPR).
• BUSINESS_IDENTIFICATION: The status of the BKYC process changed.
• IDENTIFICATION: The status of a person identification (e.g., Legal Rep) changed.
• LEGAL_REPRESENTATIVE: A legal representative was created or updated.
• PERSON_CHANGED: A person's attributes changed.
• PERSON_DELETED: A person's data was deleted.
• PERSON_MOBILE_NUMBER_CREATED: A mobile number was created but not yet verified.
• BUSINESS_FRONTING_LOAN_APPLICATION: The status of the loan application changed.
• BUSINESS_FRONTING_LOAN_PAYOUT: The status of the payout changed (e.g., to payout_issued).

Integration overview

The following diagram provides a high-level overview of the integration process.

To integrate the product, complete the following steps:

Sequence diagram

The following sequence diagram gives an overview of the integration flow:

Mandatory features

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

Step 1: Collect business data and create business resource

The customer must provide the mandatory data points 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.

API reference

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

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

Related webhook events

• BUSINESS_CHANGED
• BUSINESS_DELETED

POST Create a business

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

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

Request URL:

POST /v1/businesses

View full API reference

Automatic data collection (Optional)

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

GET Search for business commercial registration

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

Request URL:

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

Example response

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

Click here to view the full API reference.

GET Automatic business data collection

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

Request URL:

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

Example response

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

Click here to view the full API reference.

Foreign companies examples

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

GET Search for business commercial registration (France)

Request URL

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

Response

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

GET Automatic business data collection (France)

Request URL

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

Response

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

Step 2: Upload business documents

The business must submit documents for the BKYC process based on their legal form and sector. See Appendix II for a list of required documents.

Create document resources and attach them to the business.

API reference

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

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

POST Upload a document

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

Add the following properties to the request body:

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

Request URL

POST /v1/businesses/{business_id}/documents

Click here to view the full API reference

Roles and Natural Persons

After creating the business resource, you must associate natural persons with the business to fulfill mandatory roles.

• Person Resource: Contains the personal data of the individual.
• Role: Links the person to the business (e.g., Legal Representative, Beneficial Owner).

You must create a person resource first, then assign the role.

Step 3: Create Legal representative(s)

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

What is a legal representative?

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

Legal representatives as legal entities

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

In this case, you must do the following:

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

3.1 Create person resource(s) for each legal representative

API reference

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

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

Related webhook events

• PERSON_CHANGED
• PERSON_DELETED

POST Create person (Legal representative)

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

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

Request URL:

POST /v1/persons

View full API reference

3.2 Create legal representative resource(s)

Link the person to the business with the legal_representative role.

POST Create legal representative

API reference

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

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

Related webhook events

• LEGAL_REPRESENTATIVE

POST Create legal representative

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

Attributes

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

Request URL:

POST /v1/businesses/{business_id}/legal_representatives

Click here to view the full API reference.

Step 4: Create Ultimate Beneficial Owner(s)

In this step:

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

What is a Beneficial Owner?

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

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

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

Beneficial owner legal definition

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

Full definition in English

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

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

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

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

Full definition in German

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

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

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

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

4.1 Create person resource(s) for each beneficial owner

POST Create person (Beneficial owner)

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

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

Request URL:

POST /v1/persons

View full API reference

4.2 Create beneficial owner resource(s)

Link the person to the business with the beneficial_owner role.

POST Create beneficial owner

API reference

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

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

Related webhook events

• BENEFICIAL_OWNER

POST Create beneficial owner

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

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

Request URL:

POST /v1/businesses/{business_id}/beneficial_owners

Click here to view the full API reference.

Step 5: Create tax identifications

You must collect mandatory tax information and create a person_tax_identification resource for all natural persons associated with the business (Legal Representatives, UBOs, Authorized Persons).

API reference

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

• Person tax identifications API reference:

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

Related webhook events

• PERSON_TAX_IDENTIFICATION_CHANGED

POST Create person tax identification

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

• number
• country
• primary

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

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

Request example:

POST /v1/persons/{person_id}/tax_identifications

Click here to view the full API reference.

Step 6: Complete the business identification (BKYC) process

Complete the following identification and compliance steps:

1. Identification: Trigger BKYC and ensure all legal representatives complete video identification (IDnow).
2. Compliance: Forward compliance questions to the legal representatives and return answers to Solaris.
3. Screening: Ensure all Customer Due Diligence (CDD) properties are green.

6.1 Business identification

What is BKYC?

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

How does BKYC work?

The business identification consists of two asynchronous processes:

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

API reference

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

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

Related webhook events

• BUSINESS_IDENTIFICATION
• IDENTIFICATION

POST Initiate business identification

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

Request URL

POST /v1/businesses/{business_id}/identifications

Response

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

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

Click here to view the full API reference

6.2 Compliance questions

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

How to identify compliance questions and documents?

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

Only compliance questions

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

Example payload

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

Both compliance questions & documents

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

Example payload

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

How to retrieve compliance questions and provide answers?

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

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

GET Retrieve compliance questions

To get the compliance questions, call the following endpoint:

Request URL

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

Response example

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

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

Click here to view the full API reference.

Create answers for compliance questions

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

Request URL

Provide the answer in the request body.

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

Click here to view the full API reference.

PATCH Update business legal identification

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

Request URL

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

Click here to view the full API reference.

6.3 Customer Due Diligence

Solaris conducts risk screening on the business. Results are returned in the GET business resource.

• Status: The application status changes to cdd_pending during checks.
• Approval: The application is approved only if all CDD properties are green.
• Rejection: If any property is red or yellow, the application is rejected.

See the Customer Due Diligence guide.

Step 7: Create business fronting loan application

Collect loan details and create the application. The credit scorer uses this data to check eligibility.

POST Create business fronting loan application

Mandatory Properties:

• transaction_description: SEPA reference (visible to recipient).
• transaction_end_to_end_id: SEPA end-to-end ID.
• requested_amount: Loan amount (EUR).
• duration: Repayment duration.
• recipient_name: Name of loan recipient.
• recipient_iban: IBAN of loan recipient.
• purpose & purpose_description: Reason for the loan.
• creditreform_pd: Probability of default (e.g., from Creditreform).
• creditreform_score: Credit score.

Request URL

POST /v1/businesses/{business_id}/fronting_loan_applications

Request example

{
  "creditreform_pd": "0.10",
  "creditreform_score": 2,
  "duration": 24,
  "purpose": "Buying office equipment",
  "purpose_description": "Buying office equipment for new headquarters.",
  "recipient_iban": "DE92370601930002130041",
  "recipient_name": "Daniel Schmidt",
  "requested_amount": {
    "currency": "EUR",
    "unit": "cents",
    "value": 10000
  },
  "transaction_description": "Example transaction.",
  "transaction_end_to_end_id": "DDHHDHG333243"
}

• API Reference: Create application

GET Retrieve business fronting loan application

Call this endpoint to check the current status and details of an existing application.

Request URL

GET /v1/businesses/{business_id}/fronting_loan_applications/{application_id}

Webhooks: Subscribe to BUSINESS_FRONTING_APPLICATION to receive automatic updates.

• API Reference: Retrieve application

Application status flow

Step 8: Upload documents and link them to the loan application

In this step, you must create document resources for all the required documents, such as loan agreement, credit risk report, invoices etc., and link them to the business fronting loan application.

Use the upload document endpoint to upload the loan-related documents.

PUT Link documents to fronting application

After creating the document resources, you must link each document to the fronting loan or factoring application.

This endpoint links a document resource to the business fronting loan or factoring application. You must add the following properties in the request body:

• document_type: The document type. For a list of possible values, check the appendix.
• document_id: The unique ID of the document resource.

Request URL

PUT /v1/businesses/{business_id}/fronting_loan_applications/{application_id}/documents

Request example

{
  "document_id": "69ec2a9d8dbaf5ea1b13124098a34ea3cdoc",
  "document_type": "INVOICE"
}

View full API reference

Step 9: Link the business identification to the loan application

In this step, you must link the business identification resource to the business fronting loan application by calling the following endpoint.

PUT Link identification to loan application

This endpoint links a business identification resource to the business fronting loan application. You must add the following properties in the request body:

• identification_id: The unique ID of the identification resource, created after triggering the business identification process.

Request:

PUT /v1/businesses/{business_id}/fronting_loan_applications/{application_id}/identification

{
  "identification_id": "1063504cf74919f60ae4c806bdc9ce75bid"
}

View full API reference

Step 10: Trigger the loan payout

Once BKYC and scoring are successful, trigger the payout.

POST Trigger loan payout

This endpoint creates the loan and triggers the transfer from the Solaris settlement account.

Mandatory Property:

• settlement_account_iban: Solaris account from which funds are transferred.

Request URL

POST /v1/businesses/{business_id}/fronting_loan_applications/{application_id}/payout

Request example

{
  "settlement_account_iban": "DE07110101014503906016"
}

Response: Returns the loan_id and sets status to payout_pending.

• API Reference: Trigger payout

GET Retrieve business fronting loan

Retrieve loan details and track the BUSINESS_FRONTING_LOAN_PAYOUT webhook.

Request URL

GET /v1/businesses/{business_id}/fronting_loans/{loan_id}

• API Reference: Retrieve loan

Money flow

After triggering payout, you must execute the following transfers:

1. Payout: Solaris transfers funds from the Settlement Account -> Customer Account.
2. Agio (If applicable): Solaris transfers the agio (commission) from the Settlement Account -> Your Collection Account.
3. Settlement: You must transfer the full loan amount (Net + Agio) from Your Collateral Account -> Solaris Settlement Account.

When all transfers complete, the status changes to payout_issued.

Testing

Banque de France checks (France only)

Happy path

Simulate a successful check.

1. Create Business

{
  "name": "Business FR",
  "sector": "FOREIGN_COMPANIES",
  "legal_form": "FR_SA",
  "tax_information": {
    "registration_number": "552144503",
    "tax_country": "FR",
    "registration_issuer": "registration_issuer_fr"
  },
  "vat_number": "552144503"
}

2. Create Person

{
  "first_name": "Adchilove",
  "last_name": "Toussaint",
  "salutation": "MR",
  "birth_date": "1985-07-01",
  "birth_province": "97",
  "registration_number": "registration_number_1",
  "postal_code": "1234"
}

3. Assign Roles

• Legal Rep: POST /v1/businesses/{business_id}/legal_representatives
• UBO: POST /v1/businesses/{business_id}/beneficial_owners

4. Result: Create the loan application. Status should reach scoring_pending.

Unhappy path

Simulate a failed check (Rejected status).

1. Create Business

{
  "name": "Business FR",
  "sector": "FOREIGN_COMPANIES",
  "legal_form": "FR_SA",
  "tax_information": {
    "registration_number": "234568087",
    "tax_country": "FR",
    "registration_issuer": "registration_issuer_fr"
  },
  "vat_number": "234568087"
}

2. Create Person

{
  "first_name": "Marie",
  "last_name": "Marchand",
  "salutation": "MS",
  "birth_date": "1980-01-26",
  "birth_province": "86",
  "registration_number": "registration_number_1",
  "postal_code": "1234"
}

3. Result: Create the loan application. Status should reach rejected.

Related resources

• Business Fronting API Reference
• Business Identification API Reference
• Video Identification Guide
• SEPA Transfers Guide

Appendix I: Enums

Business fronting loan application status

The following table includes the enums for the field status and their descriptions in the business fronting loan application resource. For example, it is available when you call the GET Retrieve business fronting loan application.

Business fronting loan payout status

The following table includes the enums for the field status and their descriptions for the business fronting loan payout. For example, it is available when you call the GET Retrieve business fronting loan.

CRS company type

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

Document types

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

IDnow status

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

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

Tax country

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

Sector

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

Legal form

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

Austria (AT)

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

Belgium (BE)

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

Bulgaria (BG)

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

Croatia (HR)

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

Czech Republic (CZ)

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

France (FR)

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

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

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

Hungary (HU)

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

Italy (IT)

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

Luxembourg (LU)

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

Poland (PL)

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

Portugal (PT)

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

Romania (RO)

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

Serbia (RS)

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

Slovenia (SI)

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

Spain (ES)

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

Switzerland (CH)

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

The Netherlands (NL)

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

Turkey (TR)

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

United Kingdom (GB)

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

Sector, tax country, and legal form mapping

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

The following sections outline these dependencies.

Tax country and sector mapping

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

Sector and legal form mapping

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

Legal identification status

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

NACE code

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

NACE uses four hierarchical levels:

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

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

Example

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

nace_code = "A 01.11"

Reference List

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

Requirements

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

Solarisident status

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

Appendix II: BKYC required documents

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

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

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

Appendix IV: License requirements

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

Appendix V: Business Registry offices

Appendix VI: FAQs

Legal Representative FAQs

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

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

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

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

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

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

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

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

Why do I have to submit all legal representatives here?

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

Beneficial Owner FAQs

What is a “Beneficial Owner”?

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

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

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

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

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

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

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

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

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

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

Example:

Adello GmbH is the company being identified.

• Shareholders of Adello GmbH:

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

• Shareholders of Toscana GmbH:

  • Hugo: 75%
  • Marie: 25%

Resulting Beneficial Owners of Adello GmbH:

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

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

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

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

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