v.2.1.0 - Test Environment

2026-03-31 - Planned deployment to 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.

Last updated