> ## Documentation Index
> Fetch the complete documentation index at: https://grandcentral.backbase.io/llms.txt
> Use this file to discover all available pages before exploring further.
# 2026.03-LTS
> Grand Central Unified APIs release notes, version 2026.03-LTS.
## Features
The following feature updates are available in 2026.03-LTS for Grand Central Unified APIs:
| Product group | Software component | Version | Title | Description |
| -------------------------- | --------------------------------------- | ------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Direct Debit Mandate | `grandcentral-direct-debit-mandate-api` | 1.0.5 | Improved Search Mandates API with party type filtering, collection tracking, and restructured pagination | The `/mandates/searches` endpoint now supports `partyType` filtering (`PERSON`/`ORGANISATION`) and accepts a `payerMandateAccount` object instead of the removed `accountNo` field. The response returns `externalMandateId`, `partyId`, `partyType`, and a new `mandateCollectionInformation` object with payment tracking fields (`lastPaymentDate`, `nextPaymentDate`, amounts, and `numberOfFailedAttempts`). The `mandateAccount` schema adds `accountHolderName` for clearer account identification, `mandateAmount.amount` changes from a numeric type to a decimal string, and `document.date` is renamed to `document.documentDate`. |
| Fraud Detection | `grandcentral-fraud-detection-api` | 1.3.0 | Added decisionFlag to the fraud detection API response | The fraud detection API response now includes a decisionFlag field that provides a vendor-configured action such as Allow, Block, Challenge, or Quarantine directly from the vendor partner. This removes the need for customers to map risk scores to actions on their side. |
| Party Lifecycle Management | `grandcentral-party-lifecycle-api` | 1.7.0 | Extended screening response with matched risk profiles and watchlist details | The customer screening API response now includes detailed risk profiles for each matched subject, including matchScore, matchStrength, alertReference, and vendor-specific AML data (risk categories, PEP entries, sanction list matches, and adverse media references). This helps customers meet AML compliance requirements with richer screening data. |
| Party Lifecycle Management | `grandcentral-party-lifecycle-api` | 1.7.0 | Added support to receive push notifications from an identity verification vendor | Grand Central can now receive identity verification results from a partner vendor once the verification workflow is complete and the results are available for consumption. |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Added request and response examples for previously undocumented operations | New example files for `updatePaymentStatus`, `getPaymentByAccountId` (including recurring and scheduled variants), and the bank directory endpoint help connector developers integrate faster by providing ready-to-use request and response payloads. All existing examples were rewritten to match the v2 schemas. |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Unified bank and party reference schemas for consistent integration | Separate `payerBankReference` and `payeeBankReference` schemas are replaced by a single reusable `bankReference` schema, simplifying connector implementations that handle multiple bank parties. The new `involvedPartyInformation` model adds email contact details and a `paymentPartiesInvolved` schema for ultimate debtor and creditor tracking, supporting richer party data in payment flows. The `paymentInstructionAccountInfo` schema introduces `accountSchemeName` (supporting `IBAN`, `BBAN`, `WALLET_ID`, `ACCOUNT_NUMBER`) and `accountCurrency`, giving connector developers a consistent way to represent accounts across different payment networks. |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Added remittance information and regulatory reporting support | Connector developers can now pass structured remittance details — including referred documents, tax information, and creditor references — enabling automated reconciliation for end users. The new `regulatoryReporting` schema supports cross-border compliance by capturing authority details, country codes, and reporting classifications, reducing manual reporting overhead. A `paymentCategoryPurpose` field provides ISO 20022 purpose codes for payment classification. These fields are available in payment initiation requests and in recurring and scheduled payment responses. |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Renamed and enhanced the bank details endpoint to `/payments/bank-directory` | |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Removed `500` and `504` error responses from payment endpoints | The `500 Internal Server Error` and `504 Gateway Timeout` response definitions were removed from the `initiatePayment`, `updatePayment`, and `validatePayment` operations, streamlining connector error-handling logic. These endpoints now define `201`/`200`, `400`, `401`, and `422` responses only. |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Added support for retrieving standing orders and scheduled payments by account | You can retrieve a list of standing orders and future scheduled payments for a specific account. This enables account-level visibility into recurring and upcoming payment activity. |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Rebuilt the fetch fees request as a standalone schema | The `fetchFeesRequest` schema no longer inherits from `paymentInformationRequest`, letting connector developers define fee-specific mandatory fields independently from payment initiation. This separation simplifies fee retrieval integrations where only a subset of payment data is available. The response now includes an `additionalFeeInformation` field for supplementary context such as fee conditions or disclaimers. The response status code changed from `201` to `200`, and `feeValidity.min` and `feeValidity.max` changed from `integer` to `string` type. |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Enhanced exchange rate schema with FX contract tracking | The `exchangeRate` schema now supports `contractIdentification`, `externalContractId`, and `utilizationId` fields, letting connector developers link payments to specific FX deals and track contract utilization. This gives treasury teams and end users full visibility into the FX contract applied to each cross-currency payment. |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Redesigned address schema with broader international support | The updated address schema supports a wider range of international address formats with new fields for `careOf`, `buildingName`, `floor`, `unitNumber`, `room`, and `postbox`. The `addressLine` field changed from a single string to an array, enabling multi-line unstructured addresses for regions where structured components aren't available. Address type values now use ISO 20022-aligned codes (`HOME`, `BUSI`, `MAIL`, `POST`, `TEMP`, `POBO`, `PERM`). |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Renamed payment validation endpoint to `/payments/validations` | The validation endpoint path changed from `/payments/validate` to `/payments/validations`, aligning with RESTful resource-naming conventions. The request and response schemas now use the v2 `paymentInformationRequest` and `paymentInformationResponse`, consistent with the `initiatePayment` and `updatePayment` operations. |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Upgraded payment API specification to v2 with ISO 20022 alignment | The v2 payment API specification lets connector developers build integrations that align with ISO 20022 messaging standards, reducing custom mapping effort when connecting to core banking systems that follow these standards. The `initiatePayment`, `updatePayment`, and `validatePayment` operations now use dedicated `paymentInformationRequest` and `paymentInformationResponse` schemas with support for remittance information, regulatory reporting, payment purpose classification, intermediary agents, and FX contract tracking. The structured `paymentInformationResponse` provides lifecycle status, reason codes, network references, and next execution dates, giving consuming applications richer feedback without additional API calls. |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Aligned payment initiation, update, and validation APIs with ISO 20022 standards in version 2 | The payment order API v2.0.0 replaces the `paymentTransaction` schema with `paymentInformationRequest` and `paymentInformationResponse` across the payment initiation, update, and validation endpoints. This modular, scheme-agnostic structure supports domestic, regional, and cross-border payment schemes without depending on specific payment rails. New response fields include `networkReferences` for clearing and settlement tracking, `regulatoryReporting`, `exchangeRate` with FX contract details, and `paymentPurpose` with ISO 20022 category purpose codes. The `/payments/validate` endpoint is renamed to `/payments/validations`, and `500` and `504` error responses are removed from the payment initiation and update endpoints. |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Redesigned Fetch Bank Details as bank directory search with flexible request fields | The `/payments/fetch-bank-details` endpoint is renamed to `/payments/bank-directory` and the operation ID changes from `fetchBankDetails` to `searchBankDirectory`. All request fields are now optional, letting you query the bank directory without requiring `identificationNumber` and `identificationType`. New request field `bankDirectorySource` and new response fields `involvementType` and `supportedPaymentTypes` (with `paymentMethod`, `clearingChannel`, `cutoffTime`, and `processingDays`) provide richer directory information for payment routing decisions. |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Restructured the Fetch Fees API with a standalone request schema and updated response fields | The `fetchFeesRequest` schema no longer inherits from `paymentInformationRequest`, letting the Fetch Fees endpoint define its own mandatory field requirements independently. The response code changes from `201` to `200`. New response field `additionalFeeInformation` is added to `feeInformation`, and `feeValidity.min` and `feeValidity.max` change from `integer` to `string`. |
| Payment | `grandcentral-payment-order-api` | 1.4.7 | Added Holiday Calendar API for retrieving payment processing calendar information | The new Holiday Calendar endpoint lets you retrieve holiday and business day information for payment scheduling, including holiday dates, types, names, and next business day calculations. |
| Product Matching | `grandcentral-product-matching-api` | 1.0.7 | Enabled term deposit maturity calculation simulation through the Flexcube Connector | |
| Product Matching | `grandcentral-product-matching-api` | 1.0.7 | Added a Unified API for term deposit maturity calculation in the product matching domain | The maturity calculation API lets you simulate deposit maturity details before product enrollment. It supports eligibility checks and maturity projections through any connector integrated with the Grand Central product matching domain. |
## Fixes
2026.03-LTS contains the following bug fixes for Grand Central Unified APIs:
| Product group | Software component | Version | Title | Description |
| -------------------- | --------------------------------------- | ------- | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Direct Debit Mandate | `grandcentral-direct-debit-mandate-api` | 1.0.5 | Renamed `date` to `documentDate` in the mandate document identification schema | The `date` field in the document identification object is renamed to `documentDate` for naming consistency across the API contract. If you use `document.date` in field mappings or generated client models, update to `document.documentDate` before deploying. |