> ## Documentation Index
> Fetch the complete documentation index at: https://agenticbanking.backbase.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 2026.09-LTS

> Grand Central Unified APIs release notes, version 2026.09-LTS.

## Features

The following feature updates are available in 2026.09-LTS for Grand Central Unified APIs:

<div className="release-notes">
  | Product group | Software component | Version | Title | Description |
  | - | - | - | - | - |
  | Deposit | `grandcentral-deposit-api` | 1.4.0 | Extended deposit API schemas with custom fields | The deposit API adds optional `customFields` on operation-root and nested objects, including balances, interest, overdraft, term deposit, fee arrangements, account parties, person name, and product. Use `customFields` for vendor-specific extensions on create, get, and related deposit operations. |
  | Party Reference | `grandcentral-party-reference-api` | 2.6.0 | Extended party reference schemas with additional custom fields | The party reference API adds optional `customFields` on further party and account objects, including legal structure, email, phone, postal addresses, demographics, occupation, education, account party, account identification, nested deposit and loan arrangements, and product on `GET` party accounts. |
  | Servicing Consent | `grandcentral-servicing-consent-api` | 1.6.0 | Extended servicing consent address fields to ISO 20022 | The servicing consent API maps the shared address object to ISO 20022 postal-address fields used by payment order, including `addressType` values such as `BIZZ`, `MLTO`, and `STAT`, `addressLines` as an array, `townLocationName`, `districtName`, and `postalCode` in place of `postCode`. If you still send the previous address field names on PIS create-consent responses, review the v1.6.0 specification. |
  | Position Keeping | `grandcentral-position-keeping-api` | 0.3.0 | Extended transaction enrichment acknowledgement to HTTP 202 | `POST /internal/transactions/enrichment` returns HTTP `202` Accepted with an empty JSON object instead of HTTP `200` with no body. The request body is unchanged. Clients that treated HTTP `200` as the success acknowledgement need to accept `202`. |
</div>