Active Changes
Status Descriptions
Status Descriptions
Required Action by November 12, 2026
ACH Status Lifecycle Expansion
Status: 🟢 Sandbox AvailableAction Required: Yes (Deadline will be enforced)
Sandbox Available: July 14, 2026
Effective Date: November 12, 2026We’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
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_returnreturn_dishonoredpending_contested_returnreturn_contested
ach.under_reviewach.rejectedach.return_dishonoredach.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: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 statusFor 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 for expanded details.What You Need To Do
Before the effective date:- Ensure your
ach.posted webhookhandler is idempotent for a given ACH entry. - Update status handling to support:
under_reviewreturn_dishonoredreturn_contestedpending_dishonored_returnpending_contested_return
- Do not assume rejected or returned are always terminal states.
- 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
Rolling Out July And August 2026
Asynchronous Debit Card Network Reconciliation
Status: 🟡 AnnouncedAction Required: No (Advance notice only; optional remediation tools available)
Sandbox Available: N/A
Effective Date: Rolling out July and August 2026We’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.
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
End of Q3 2026 (exact date to be announced)
OAuth Access Token Caching
Status: 🟡 AnnouncedAction Required: Yes (Deadline will be enforced)
Sandbox Available: Q3 2026 (Planned)
Effective Date: End of Q3 2026 (Exact date to be announced)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 hoursRemain valid for approximately 23 hours
- Be reused during that validity period
- Continue to include an
expires_infield that indicates when the token should be refreshed
What You Need To Do
Before the effective date:- Review your authentication implementation.
- Ensure access tokens are cached and reused until expiration.
- Use the
expires_infield to determine when a token should be refreshed. - 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 tokenIf an API request fails due to an expired or invalid token:- Evict the cached token.
- Request a new access token.
- Retry the request once.
Timeline
Required Action by September 30, 2026
Instant Payments Return API Updates
Status: 🟢 Sandbox AvailableAction Required: Yes (Deadline will be enforced)
Sandbox Available: Available Now
Effective Date: September 30, 2026We 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
Updated Return Request Reason Values
The following reason values will no longer be supported on:/request_return/simulate/incoming_return_request
narrativenarrativeservice_not_renderedservice_not_rendered
return_requests.reason
narrativeper_agent_requestservice_not_rendered
Changes to Return Request Rejections
The/reject_return_request endpoint will no longer support:additional_informationnarrativeas a rejection reason
/simulate/incoming_return_request_rejection endpoint will no longer supportadditional_informationnarrativeandper_agent_requestas rejection reasons
return_requests.resolution.rejection_reason field will no longer support:narrativeandper_agent_request
What You Need To Do
Before August 31, 2026:- Review any integrations that deal with returns, return requests, or return request responses.
- Ensure additional_information values do not exceed 105 characters.
- 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
Timeline
Required Action by September 30, 2026
Multi-Card Program File Updates
Status: 🟡 AnnouncedAction Required: Yes (If currently offering a card product)
Sandbox Available: N/A
Effective Date: September 30, 2026We’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 FormatTransaction File Requirements
TheBIN field will become required for transactions where:type = cardtype = octtype = aft
What You Need To Do
Before September 30, 2026:- Update any systems that consume network settlement files to support the new file path structure.
- Update transaction file generation to include the appropriate BIN enum values.
- Validate downstream processes that rely on settlement file locations.
- Test file ingestion and processing before the migration deadline.
- 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
Required Action by October 6, 2026
Account Validation During New Balance Creation
Status: 🟡 AnnouncedAction Required: Yes (Deadline will be enforced)
Sandbox Available: Q3 2026 (Planned)
Effective Date: October 6, 2026We’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 referencedaccount_id must:- Exist within Lead’s system
- Belong to your program
Account Status
The referenced Account must be in a permitted status:- active
- inactive
Account Capability Validation
When applicable, the Balance type must be supported by the Account’s capabilities.ExamplesExamples:creditBalances require:credit_with_underwriting- or
credit_without_underwriting
depositBalances require:deposit
What You Need To Do
Before October 6, 2026:- Ensure all referenced Accounts have been submitted to and processed by Lead before submitting Balance files.
- Verify referenced Accounts are in a permitted status.
- Where capability validation applies, ensure the Account supports the Balance type being created.
- Review Balance file generation processes for any assumptions that may result in invalid
account_idreferences.
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
Required Migration by November 12, 2026
Wires API V2 Migration
Status: 🟡 AnnouncedAction Required: Yes (Deadline will be enforced)
Sandbox Available: August 2026 (Planned)
Effective Date: November 12, 2026We’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
New Wire Attributes
Wires API V2 also introduces:- A new
corridor_typefield 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:- Update your Wires API integration to use the V2 specification.
- Review any integrations that consume wire statuses.
- 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
Additional Resources
Released Changes
Rolling out July 1, 2026
Slack File Alerts Now Include File Paths
Status: ✅ ReleasedAction Required: No (Advance notice only)
Sandbox Available: N/A
Effective Date: July 1, 2026As part of an internal platform update, Slack file 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.