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. |