# Multi-accounts

The **Multi-accounts** feature enables your customers to open multiple fully-fledged Solaris accounts under their existing legal entity. This allows them to segregate funds for different purposes, such as savings, household expenses, taxes, or investments.

This feature is available for **Consumers**, **Freelancers**, and **Businesses**.

Each additional account is functionally identical to a primary account, supporting:

* [SEPA Direct Debits (SDDs)](/guides/digital-banking/sepa-transfers/sepa-direct-debit-transfer)
* [SEPA Credit Transfers (SCTs)](/guides/digital-banking/sepa-transfers/sepa-credit-transfer)
* [other features](/guides/digital-banking)


Feature Activation
This feature is not enabled by default. Contact your Partner Manager to enable multi-accounts for your solution.

## Prerequisites

Before opening an additional account, ensure the following conditions are met:

1. **Onboarding Complete:** The customer must have a fully identified and active `person` or `business` resource.
2. **Main Account Active:** The customer's primary account must be **active** and free of any blocks or seizures.
3. **Contract Limits:** The maximum number of accounts per customer is defined in your Solaris contract. You must enforce this limit in your frontend.


## Integration steps

### 1. Confirm Terms & Conditions

For **every** new account, you must collect the customer's consent to the Solaris Terms & Conditions (T&Cs).

* Display the T&Cs in your UI.
* Store the **UTC timestamp** and the **Document ID** of the agreed T&Cs.
* **Guide:** See [Legal & Compliance Screens](/guides/get-started/onboarding-requirements/1-legal-compliance-screens#solaris-terms--conditions) for implementation details.


### 2. Verify customer data

Before creating the account, you must verify that the customer's KYC data is still current.

1. Call [`GET Retrieve a person`](/api-reference/onboarding/persons#tag/Persons/paths/~1v1~1persons~1%7Bid%7D/get) to fetch the current data.
2. Display this data to the customer and ask them to confirm its accuracy.
  * **If accurate:** Proceed to Step 3.
  * **If outdated:** The customer must update their data. Call [`PATCH Update a person`](/api-reference/onboarding/persons#tag/Persons/paths/~1v1~1persons~1%7Bid%7D/patch) with the new values and set the `aml_confirmed_on` property to the current date.
    * *Note:* Data changes require a [Change Request](/guides/authentication/strong-customer-authentication#change-request) authorization (SCA).


Risk Assessment Trigger
Updating customer data triggers a new **Customer Due Diligence (CDD)** check.

If this check uncovers new risks (e.g., a PEP match or Sanction hit):

1. You will receive a [`PERSON_CHANGED`](/api-reference/onboarding/webhooks/webhook-events/paths/person_changed/post) webhook.
2. You must review the `screening_progress` and `risk_classification_status` fields.
3. If the status is `RED` or `YELLOW`, you may be blocked from opening the new account.


For details on the screening logic, see the [Customer Due Diligence (CDD)](/guides/kyc/cdd) guide.

### 3. Request the new account (AOR)

If the data is verified, submit an **Account Opening Request (AOR)**. Unlike the primary account, you must specify the `account_purpose`.

**Endpoint:** [`POST /v1/accounts/opening_requests`](/api-reference/onboarding/account-creation#tag/Account-Opening-Request/paths/~1v1~1accounts~1opening_requests/post)

**Required Fields:**

* `customer_type`: `Person` or `Business`.
* `customer_id`: The ID of the existing customer.
* `account_purpose`: **Mandatory.** Select a value from the [Compliance Guidelines](#compliance-account-purpose) below (e.g., `Savings`).
* `product_name`: Your commercial product ID (e.g., `CURRENT_ACCOUNT_CONSUMER_GERMANY`).



```json
{
  "customer_type": "Person",
  "customer_id": "123456789",
  "product_name": "CURRENT_ACCOUNT_CONSUMER_GERMANY",
  "account_type": "CHECKING_PERSONAL",
  "account_bic": "SOBKDEB2XXX",
  "account_currency": "EUR",
  "account_purpose": "Savings" // Specific to multi-accounts
}
```

Asynchronous Process
The account is not created immediately. You must listen for the [`ACCOUNT_OPENING_REQUEST`](/api-reference/onboarding/webhooks/webhook-events/paths/account_opening_request/post) webhook to receive the new `account_id` or rejection reason.

## Compliance: Account purpose

To comply with **§10 (2) 1 GwG (German Money Laundering Act)**, Solaris must understand the purpose of every business relationship. Multi-accounts add complexity to transaction monitoring, so you must strictly adhere to these guidelines when setting the `account_purpose` field.

### Guidelines

* **Predefined Values:** Do not allow free-text input. Use a dropdown list.
* **Limit:** Offer a maximum of **12** distinct purpose options.
* **Length:** Maximum **40 characters** per value.
* **Specificity:** Do **not** offer "Other" or "Miscellaneous" as options.
* **Consistency:** The primary account purpose is automatically `Main Account`.
* **Brevity:** Use single words where possible (e.g., "Savings", not "My savings account").


### Approved examples

| Consumer (`CHECKING_PERSONAL`) | Business (`CHECKING_BUSINESS`) |
|  --- | --- |
| Savings | Taxes |
| Spendings | Operational |
| Household | Salaries |
| Vacation | Investments |
| Rainy Day | Provisioning |
| Renovation | Marketing |


## API Reference

Account Opening Request
View the full specification for the AOR endpoint.