# v.2.1.0 - Live Environment

**2026-03-31 - Live**

**2026-03-17 - Test Environment**

***

**Added**

**Address Plausibility Check (Germany)**

We have implemented a new address plausibility validation for German addresses to ensure accurate tax processing.

* **Endpoints:** Applies to all endpoints handling address creation or updates, including:
  * `POST /entities/natural-persons`
  * `PATCH /entities/natural-persons/{naturalPersonId}`
  * `POST /entities/legal-entities`
  * `PATCH /entities/legal-entities/{legalEntityId}`
  * `POST /entities/joint-persons`
  * `PATCH /entities/joint-persons/{jointPersonId}`
  * `POST /entities/{legalEntityId}/beneficial-owners`
  * `PATCH /entities/beneficial-owners/{beneficialOwnerId}`
  * `POST /entities/{legalEntityId}/legal-representatives`
  * `PATCH /entities/legal-representatives/{legalRepresentativeId}`
* **Logic:** When creating or updating an address where the country is Germany (`DE`), the system now verifies that there is a valid, real-world combination of `zip` (postal code) and `city`.
* **Purpose:** This strict validation allows to reliably determine the taxpayer's federal state, which is required for correct tax calculations.
* **Impact:** API requests containing invalid or mismatched German postal codes and cities will now be rejected with and fail onboarding.
* **Examples of valid combinations:**
  * City: `"Berlin"`, Zip: `"10178"`
  * City: `"München"`, Zip: `"80331"`
  * City: `"Frankfurt am Main"`, Zip: `"60311"`

**Transfer Receipt Document for SEPA Transfers**

A new document type has been introduced to allow clients to retrieve receipts confirming successfully booked SEPA transfers.

* **Endpoints:**
  * `GET /v2/documents`
  * `GET /v2/documents/{documentId}`
  * `GET /v2/documents/{documentId}/file`
* **Purpose:** Added the `TRANSFER_RECEIPT` enum value to the document type fields, enabling the retrieval and downloading of SEPA transfer receipt files.

***

**Changed**

**Final Statuses for Partially Filled Traditional Orders**

Two new final statuses have been introduced to distinguish the final outcome of the unexecuted quantity of partially executed traditional trading orders.

* **Endpoints:**
  * `GET /traditional/orders/{orderId}`
  * `GET /products/{customerProductId}/traditional/orders`
* **Purpose:** Added `PARTIALLY_FILLED_CANCELLED` and `PARTIALLY_FILLED_EXPIRED` to the `status` enum. These follow-up states indicate whether the remaining unexecuted order quantity was cancelled or expired.

**Transaction API Order Status Extension**

The new partial fill statuses have been propagated to transaction responses related to traditional trading.

* **Endpoints:**
  * `GET /transactions/{transactionId}`
  * `GET /customers/{customerId}/transactions`
* **Purpose:** Added `PARTIALLY_FILLED_CANCELLED` and `PARTIALLY_FILLED_EXPIRED` enum values to the following fields to ensure accurate interpretation of transaction history:
  * `traditionalTradingTransaction.orderStatus`
  * `traditionalTradingTransaction.partialExecutions[].status`

**Corporate Action Instructions (Multiple Elections)**

The Corporate Action Instructions API has been extended to support the submission of multiple elections within a single request.

* **Endpoint:** `POST /corporate-actions/{corporateActionId}/instructions`
* **Purpose:** Restructured the request payload to accept an `elections` array. This enables submitting multiple corporate action options for the same customer product simultaneously.
* **Payload Changes:**
  * **Removed:** Flat `corporateActionOption` and `tenderedQuantity` fields.
  * **Added:** `elections` array containing objects with `corporateActionOption` and `tenderedQuantity`.