> ## Documentation Index > Fetch the complete documentation index at: https://docs.lead.bank/llms.txt > Use this file to discover all available pages before exploring further. # Upcoming Changes > Advance notice of planned Lead platform, API, and reporting changes that may require partner awareness, testing, or action before effective dates. Upcoming changes are not yet live in production unless explicitly noted. Check back frequently for the latest status. We will continue to update details throughout the change lifecycle: 🟑 **Announced β†’** 🟒 **Sandbox Available β†’** 🟠 **Enforcement Soon β†’** βœ… **Released** Timelines may change as implementation details are finalized. ## Active Changes | **Status** | Important Dates | **Change** | | -------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | 🟒 Sandbox Available | Required Action by November 12, 2026 | [ACH Status Lifecycle Expansion](/upcoming-changes#ach-status-lifecycle-expansion) | | 🟑 Announced | Rolling Out July and August 2026 | [Asynchronous Debit Card Network Reconciliation](/upcoming-changes#asynchronous-debit-card-network-reconciliation) | | 🟑 Announced | Required Action by November 12, 2026 | [OAuth Access Token Caching](/upcoming-changes#oauth-access-token-caching) | | 🟒 Sandbox Available | Required Action by September 30, 2026 | [Instant Payments Return API Updates](/upcoming-changes#instant-payments-return-api-updates) | | 🟑 Announced | Required Action by September 30, 2026 | [Multi-Card Program File Updates](/upcoming-changes#multi-card-program-file-updates) | | 🟑 Announced | Required Action by October 6, 2026 | [Account Validation During New Balance Creation](/upcoming-changes#account-validation-during-new-balance-creation) | | 🟑 Announced | Required Migration by November 12, 2026 | [Wires API V2 Migration](/upcoming-changes#wires-api-v2-migration) | | Status | Description | | :------------------- | :--------------------------------------------------------------------------------------- | | 🟑 Announced | Change has been communicated and is planned, but is not yet available for testing. | | 🟒 Sandbox Available | Change is available for testing in sandbox but is not yet live in production. | | 🟠 Enforcement Soon | Production date is approaching and any required implementation work should be completed. | | βœ… Released | Change is now live in production and has been added to the Changelog. | | ⏸️ Delayed | Previously announced timelines have changed. | *** ## ACH Status Lifecycle Expansion **Status:** 🟒 Sandbox Available
**Action Required:** Yes (Deadline will be enforced)
**Sandbox Available:** July 14, 2026
**Effective Date:** Β November 12, 2026 We're expanding visibility into the ACH lifecycle by surfacing previously hidden events and introducing support for dishonored and contested returns. Historically, certain ACH events β€” such as auto-returns and manual review holds β€” were handled internally and were not visible to partners. This update brings ACH behavior in line with other payment rails by exposing the complete lifecycle through statuses and webhooks. ### **What's Changing** #### **Previously Hidden Events Are Now Visible** The following events will now be surfaced through statuses and webhooks: * ACH entries held for manual review * ACH entries automatically returned by Lead This introduces a new visible status: * `under_review` #### **Expanded Return Lifecycle** We're adding support for the full ACH return lifecycle, including dishonored and contested returns. New statuses include: * `pending_dishonored_return` * `return_dishonored` * `pending_contested_return` * `return_contested` New webhooks include: * `ach.under_review` * `ach.rejected` * `ach.return_dishonored` * `ach.return_contested` #### **ACH Entries May Receive Additional Status Updates** In certain scenarios, ACH entries that previously appeared terminal may continue transitioning through additional states. Examples include: ```text theme={null} posted β†’ pending_return β†’ posted ``` and ```text theme={null} rejected β†’ pending_return_dishonored β†’ return_dishonored ``` #### **Recommended testing process** **For previously hidden events:** you can simulate the new behavior by using `/v1/simulate/ach/incoming_ach` to initiate an incoming transaction on an `account_number_id` you have set to `inactive` status **For dishonored and contested transactions:** we have updated the list of return codes to include the R6x and R7x series return codes to indicate dishonored and contested returns respectively.Β  Please see the [Updated ACH Status Lifecycle Documentation](/api-integrations/ach/statuses) for expanded details. ### **What You Need To Do** Before the effective date: 1. Ensure your `ach.posted webhook` handler is idempotent for a given ACH entry. 2. Update status handling to support: * `under_review` * `return_dishonored` * `return_contested` * `pending_dishonored_return` * `pending_contested_return` 3. Do not assume rejected or returned are always terminal states. 4. Test your integration against the updated ACH lifecycle in sandbox. ### **Why This Matters** Partners that do not update their integrations may experience: * Duplicate processing from repeated webhook events * Missed or incorrect status transitions * Incomplete visibility into ACH return and dispute scenarios * Incorrect reconciliation or customer notifications ### **Additional Resources** * [Updated ACH Status Lifecycle Documentation](/api-integrations/ach/statuses) * [Returns & Reversals Documentation](/api-integrations/ach/returns-and-reversals) *** ## **Asynchronous Debit Card Network Reconciliation** **Status:** 🟑 Announced
**Action Required:** No (Advance notice only; optional remediation tools available)
**Sandbox Available:** N/A
**Effective Date:** Rolling out July and August 2026 We're relaxing debit card network reconciliation requirements so that Balance and Transaction files for deposit products no longer block on exact reconciliation to the prior day's network settlement. Files process when you submit them, and Lead sends a daily alert summarizing any differences. Today, network reconciliation requires Balance and Transaction files submitted on a given day (T) to reconcile exactly to the previous day's (T-1) network settlement before they process. When amounts do not match to the penny, file processing is blocked. This is time-consuming for you and for Lead, and it delays otherwise valid file processing. ### **Why We're Making This Change** To-the-penny reconciliation at file-processing time creates friction without a proportional benefit. Moving reconciliation to an asynchronous, offline process lets your files process without interruption while still giving you the visibility you need to manage reconciliation on your own schedule. ### **What's Changing** Balance and Transaction files for deposit products submitted on T will no longer block on exact reconciliation to the T-1 network settlement. These files process when submitted. In place of hard blocking, Lead delivers a daily alert for each network settlement. Each alert reports the life-to-date (LTD) network settlement amounts and compares them to the LTD transaction amounts, so you can see any differences (deltas) as they arise. This change does not break current Balance or Transaction file processing. Files that reconcile continue to process as they do today. ### **What You Need To Do** No action is required to take advantage of this change. Your existing Balance and Transaction file workflows continue to work. You remain responsible for managing reconciliation. Two options are available when you need to remediate a difference: * When a transaction is reported with an incorrect settlement date, use Transaction Updates to reflect the correct settlement date. * When a transaction is missing, you can now submit a transaction with an effective date earlier than T-1 on day T to fill the gap. The rollout of this change will occur in two waves. The new asynchronous debit card network reconciliation process will roll out to our first wave of partners on July 21st, 2026, and the remaining partners on August 3rd, 2026. ### **Why This Matters** This change reduces file-processing delays and gives you clearer, daily insight into reconciliation differences. Lead continues to expect partners to manage this reconciliation. Internally, Lead's product finance team monitors programs whose differences exceed our threshold and will escalate to you directly when follow-up is needed. ### Timeline | **Milestone** | **Date** | | ----------------------------------------------- | -------------- | | Announcement | July 14, 2026 | | Rollout Begins to Initial Partners (First Wave) | July 21, 2026 | | Rollout to Remaining Partners (Second Wave) | August 3, 2026 | *** ## **OAuth Access Token Caching** **Status:** 🟑 Announced
**Action Required:** Yes (Deadline will be enforced)
**Sandbox Available:** October 1, 2026
**Effective Date:** November 12, 2026 We're updating how OAuth access tokens are issued and managed to improve platform performance and reduce unnecessary authentication traffic. Today, some integrations request a new access token before every API call. Going forward, access tokens will be cached for up to 23 hours and should be reused until they expire. ### **Why We're Making This Change** OAuth access tokens are designed to be reused for their full validity period. Requesting a new token for every API call creates unnecessary authentication traffic and increases platform overhead. This change aligns Lead's authentication model with standard OAuth practices and improves the efficiency and reliability of the platform. ### **What's Changing** Access tokens issued through the Token Exchange API will: * Remain valid for approximately 23 hours * Be reused during that validity period * Continue to include an `expires_in` field that indicates when the token should be refreshed Integrations should use the existing token until it expires rather than requesting a new token for every API request. ### **What You Need To Do** Before the effective date: 1. Review your authentication implementation. 2. Ensure access tokens are cached and reused until expiration. 3. Use the `expires_in` field to determine when a token should be refreshed. 4. Update any integrations that request a new access token before every API call. ### **Why This Matters** Integrations that do not properly cache access tokens may experience: * Authentication failures * Unexpected authorization errors * Reduced application performance * Future limitations related to excessive token generation ### **Recommended Error Handling** If an API request fails due to an expired or invalid token: 1. Evict the cached token. 2. Request a new access token. 3. Retry the request once. ### Timeline | **Milestone** | **Date** | | ----------------- | ----------------- | | Announcement | June 10, 2026 | | Sandbox Available | October 1, 2026 | | Effective Date | November 12, 2026 | *** ## **Instant Payments Return API Updates** **Status:** 🟒 Sandbox Available
**Action Required:** Yes (Deadline will be enforced)
**Sandbox Available:** Available Now
**Effective Date:** September 30, 2026 We are actively adding support for RTP as a payment rail. In preparation, we are updating portions of the Instant Payments API to align return request functionality across FedNow and RTP. These changes affect return-related fields and endpoints and introduce updated validation requirements for return reasons and supporting information. ### **Why We're Making This Change** As we expand support for RTP and continue to align behavior across instant payment networks, we're standardizing how return requests and return responses are handled. These changes simplify the API, remove unsupported return scenarios, and ensure consistent behavior across instant payment rails. ### **What's Changing** #### **Reduced Maximum Length for** `additional_information` The `additional_information` field will be limited to **105 characters** for the following endpoints: * `/return` * `/request_return` * `/simulate/incoming_return` * `/simulate/incoming_return_request` Requests exceeding this limit will fail validation. #### **Updated Return Request Reason Values** The following reason values will no longer be supported on: * `/request_return` * `/simulate/incoming_return_request` Removed values: * `narrative` * `service_not_rendered` The following values will no longer be supported on: * `return_requests.reason` Removed values: * `narrative` * `per_agent_request` * `service_not_rendered` #### **Changes to Return Request Rejections** The `/reject_return_request `endpoint will no longer support: * `additional_information` * `narrative` as a rejection reason The `/simulate/incoming_return_request_rejection` endpoint will no longer support * `additional_information` * `narrative` and `per_agent_request` as rejection reasons The `return_requests.resolution.rejection_reason` field will no longer support: * `narrative` and `per_agent_request` Requests containing these values will fail validation. ### **What You Need To Do** Before August 31, 2026: 1. Review any integrations that deal with returns, return requests, or return request responses. 2. Ensure additional\_information values do not exceed 105 characters. 3. Remove any usage of unsupported reason values. ### **Why This Matters** Partners that do not update their integrations may experience: * Validation errors * Failed return requests * Failed return request responses * Operational delays when processing return-related workflows While current return volumes are low, we recommend validating your implementation before the effective date to avoid disruptions. ### Timeline | **Milestone** | **Date** | | ----------------- | ------------------ | | Announcement | June 10, 2026 | | Sandbox Available | June 30, 2026 | | Effective Date | September 30, 2026 | *** ## **Multi-Card Program File Updates** **Status:** 🟑 Announced
**Action Required:** Yes (If currently offering a card product)
**Sandbox Available:** N/A
**Effective Date:** September 30, 2026 We're updating our network settlement processing to support multiple card products under the same program, including programs with different funds flows (for example, debit and credit card products operating on the same card network). This enhancement expands the flexibility of our card infrastructure and lays the foundation for additional card product support in the future. ### **Why We're Making This Change** Historically, network settlement processing assumed a single card product per program. As partners expand into multiple card products and card networks, we're updating our settlement infrastructure to support more complex program structures while maintaining accurate settlement and transaction reporting. ### **What's Changing** #### **Network Settlement File Paths** The network settlement file path is changing to include a settlement reporting identifier. **Current Format** ```text theme={null} /network-settlement/{card_network}/ ``` **New Format** ```text theme={null} /network-settlement/{card_network}/{settlement_reporting_id} ``` This additional identifier enables support for multiple card products associated with the same card network. #### **Transaction File Requirements** The `BIN` field will become required for transactions where: * `type = card` * `type = oct` * `type = aft` Partners must provide the appropriate BIN enum value for each applicable transaction. Program-specific BIN values will be provided before the effective date. ### **What You Need To Do** Before September 30, 2026: 1. Update any systems that consume network settlement files to support the new file path structure. 2. Update transaction file generation to include the appropriate BIN enum values. 3. Validate downstream processes that rely on settlement file locations. 4. Test file ingestion and processing before the migration deadline. Lead will provide your program-specific: * Settlement reporting identifiers * BIN enum values * Testing and implementation guidance ### **Why This Matters** Partners that do not update their implementations before September 30, 2026 may experience: * Failed settlement file processing * Missing settlement data * Transaction file validation errors * Delays in reconciliation and reporting workflows ### Timeline | **Milestone** | **Date** | | ------------------------------------ | ----------------------- | | Announcement | June 10, 2026 | | Program-Specific Details Distributed | Prior to September 2026 | | Effective Date | September 30, 2026 | *** ## Account Validation During New Balance Creation **Status:** 🟑 Announced
**Action Required:** Yes (Deadline will be enforced)
**Sandbox Available:** September 22, 2026
**Effective Date:** October 6, 2026 We're introducing additional validation to ensure every new Balance record contained in a Balance file submitted to Lead is associated with a valid parent Account. Balances created via API already have this enforced and no action is required. Today, Lead does not enforce that the account\_id referenced on a new Balance ties back to a recognized and valid Account. This update closes that gap and improves our ability to accurately associate Balances and Transaction activity with the correct Account and Entity. ### **Why We're Making This Change** Every Balance should be traceable to a valid Account. This change improves data integrity, financial attribution, and operational consistency by ensuring Balance records reference Accounts that exist, belong to your program, and are configured appropriately. ### **What's Changing** Starting October 6, 2026, Lead will validate the account\_id referenced by each new Balance record submitted through Balance files. The following validations will be enforced: #### **Account Existence & Ownership** The referenced `account_id` must: * Exist within Lead’s system * Belong to your program Failures will return: ```text theme={null} account_not_found ``` #### **Account Status** The referenced Account must be in a permitted status: * active * inactive Accounts in other statuses (such as closed) will be rejected. Failures will return: ```text theme={null} account_status_invalid ``` #### **Account Capability Validation** When applicable, the Balance type must be supported by the Account's capabilities. Examples: * `credit` Balances require: * `credit_with_underwriting` * or `credit_without_underwriting` * `deposit` Balances require: * `deposit` Failures will return: ```text theme={null} account_capability_missing ``` This validation applies only to Accounts that include a capabilities array (i.e., were created via the Accounts API). ### **What You Need To Do** Before October 6, 2026: 1. Ensure all referenced Accounts have been submitted to and processed by Lead before submitting Balance files. 2. Verify referenced Accounts are in a permitted status. 3. Where capability validation applies, ensure the Account supports the Balance type being created. 4. Review Balance file generation processes for any assumptions that may result in invalid `account_id` references. If Lead identifies existing Balance records that require remediation, we will proactively contact affected partners during Q3 2026. ### **What Happens If You Don't Act** Starting October 6, 2026: * Invalid new Balance records will be rejected. * Balance files containing invalid new records will fail processing. * Downstream transaction and reporting workflows may be delayed until corrected files are submitted. ### Timeline | **Milestone** | **Date** | | ----------------- | ------------------ | | Announcement | June 10, 2026 | | Sandbox Available | September 22, 2026 | | Effective Date | October 6, 2026 | *** ## Wires API V2 Migration **Status:** 🟑 Announced
**Action Required:** Yes (Deadline will be enforced)
**Sandbox Available:** August 2026 (Planned)
**Effective Date:** November 12, 2026 We're introducing Wires API V2 to support the upcoming Fedwire ISO 20022 mandate while also providing a foundation for future wire enhancements. This release updates how wire address information is submitted and introduces several improvements, including the ability to distinguish domestic vs. international, updated wire statuses, and future readiness for international wire expansion. ### **Why We're Making This Change** On November 16, 2026, the Federal Reserve will implement additional ISO 20022 requirements for Fedwire, including new message format and validation requirements. As part of this industry-wide change, fully unstructured wire addresses will no longer be supported. To ensure continued wire processing, partners must migrate to Wires API V2 before the enforcement deadline. ### **What's Changing** #### **Structured Address Support** Wire addresses will move from fully unstructured address lines to a hybrid format that includes required structured fields. Examples of new required data include: * Town / City * Country Additional address requirements are documented in the [V2 Create-a-Wire API reference](https://docs.lead.bank/api-reference/endpoint/wire/create-a-wire-v2) and [V2 Migration Guide](/api-integrations/wire/v2-migration). #### **New Wire Attributes** Wires API V2 also introduces: * A new `corridor_type` field to indicate whether a wire is domestic or international * The consolidation of routing numbers into `local_routing_identifier` * Additional infrastructure to support future international wire enhancements ### **What You Need To Do** Before November 12, 2026: 1. Update your Wires API integration to use the V2 specification. 2. Review any integrations that consume wire statuses. 3. Validate your implementation in sandbox once testing becomes available. ### **What Happens If You Don't Act** After November 12, 2026: * Existing V1 integrations will no longer be supported. * Wires submitted using unsupported address formats will be rejected. * Wire processing may be disrupted once ISO 20022 requirements take effect. ### **Timeline** | **Milestone** | **Date** | | :-------------------- | :-------------------- | | Announcement | June 10, 2026 | | Sandbox Available | August 2026 (Planned) | | Migration Deadline | November 12, 2026 | | ISO 20022 Enforcement | November 16, 2026 | ### **Additional Resources** * [Wires API V2 Reference](https://docs.lead.bank/api-reference/endpoint/wire/create-a-wire-v2) * [Wires API V2 Migration Guide](/api-integrations/wire/v2-migration) *** ## Released Changes ## Slack File Alerts Now Include File Paths **Status:** βœ… [Released](/changelog#slack-file-alerts-now-include-file-paths)
**Action Required:** No (Advance notice only)
**Sandbox Available:** N/A
**Effective Date:** July 1, 2026 As part of an internal platform update, [Slack file alerts](/file-integrations/file-delivery/slack-alerts) will begin including the full file path along with the filename wherever a file is referenced. This applies to both success and error alerts. ### **Why We're Making This Change** Including the full file path gives you clarity on exactly where Lead received the file. This makes it unambiguous which file an alert refers to, so you can quickly locate and act on the file in question. ### **What's Changing** Any reference to a file in a Slack alert will now include its full file path. **Current Format** ```text theme={null} File 2026-04-30_transactions_v6.csv failed validation. ``` **New Format** ```text theme={null} File transactions/2026-04-30_transactions_v6.csv failed validation. ``` No changes are being made to the file schema, folder structure, validations, or error codes. This is a presentation-only change to the text of Slack alerts. ### **What You Need To Do** No action is required for most partners. If you have downstream automation that parses or matches on the exact filename string in Slack alert messages, update it to account for the file path now being prepended to the filename. ### Timeline | **Milestone** | **Date** | | -------------- | ------------- | | Announcement | June 16, 2026 | | Effective Date | July 1, 2026 |