v.2.1.0

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:

  • 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}

• Purpose: This strict validation allows the Tax Engine to reliably determine the taxpayer's federal state, which is required for correct tax calculations.

• Logic: When creating or updating an address where the country is Germany (DE), the system verifies that there is a valid, real-world combination of zip (postal code) and city.

• Impact: API requests containing invalid or mismatched German postal codes and cities will now be rejected and will fail the onboarding process.

• 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

Corporate Actions Simulator Payload Update

We have added a new required field to the payload of our SWIFT mock simulation endpoints. (Note: These simulation endpoints are subject to change as the simulator evolves).

• Endpoints:

  • POST /corporate-actions/swift-mock/publishMT564

  • POST /corporate-actions/swift-mock/publishMT566

• Payload Changes:

  • Added: A new required field corporateActionMessageReference has been added to the request payload for both endpoints.

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 to ensure accurate interpretation of transaction history.

• Endpoints:

  • GET /transactions/{transactionId}

  • GET /customers/{customerId}/transactions

• Purpose: Added PARTIALLY_FILLED_CANCELLED and PARTIALLY_FILLED_EXPIRED enum values to the following fields:

  • 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, enabling the submission of multiple corporate action options for the same customer product simultaneously.

• Payload Changes:

  • Removed: Flat corporateActionOption and tenderedQuantity fields.

  • Added: elections array containing objects with the corporateActionOption and tenderedQuantity fields.