Skip to main content
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 → ✅ ReleasedTimelines may change as implementation details are finalized.

​
Active Changes

StatusImportant DatesChange
🟡 AnnouncedEnd of Q3 2026 (Exact date to be announced)ACH Status Lifecycle Expansion
🟡 AnnouncedEnd of Q3 2026 (Exact date to be announced)OAuth Access Token Caching
🟢 Sandbox AvailableRequired Action by September 30, 2026Instant Payments Return API Updates
🟡 AnnouncedRequired Action by September 30, 2026Multi-Card Program File Updates
🟡 AnnouncedRequired Action by October 6, 2026Account Validation During New Balance Creation
🟡 AnnouncedRequired Migration by November 12, 2026 Q3Wires API V2 Migration
StatusDescription
🟡 AnnouncedChange has been communicated and is planned, but is not yet available for testing.
🟢 Sandbox AvailableChange is available for testing in sandbox but is not yet live in production.
🟠 Enforcement SoonProduction date is approaching and any required implementation work should be completed.
✅ ReleasedChange is now live in production and has been added to the Changelog.
⏸️ DelayedPreviously announced timelines have changed.
​
End of Q3 2026 (exact date to be announced)

​
ACH Status Lifecycle Expansion

Status: 🟡 Announced
Action Required: Yes (Deadline will be enforced)
Sandbox Available: July 2026 (Planned)
Effective Date:  End of Q3 2026 (Exact date to be announced)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_return_dishonored
  • return_dishonored
  • pending_return_contested
  • 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:
posted → pending_return → posted
and
rejected → pending_return_dishonored → return_dishonored

​
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_return_dishonored
    • pending_return_contested
  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 (Coming Soon)
  • Returns & Reversals Documentation (Coming Soon)
​
End of Q3 2026 (exact date to be announced)

​
OAuth Access Token Caching

Status: 🟡 Announced
Action 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 hours
  • Be reused during that validity period
  • Continue to include an expires_at 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_at 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
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

MilestoneDate
AnnouncementJune 10, 2026
Sandbox AvailableQ3 2026 (Exact date to be announced)
Effective DateEnd of Q3 2026 (Exact date to be announced)
​
Required Action by September 30, 2026

​
Instant Payments Return API Updates

Status: 🟢 Sandbox Available
Action Required: Yes (Deadline will be enforced)
Sandbox Available: Available Now
Effective Date: September 30, 2026We’re updating portions of the Instant Payments API to align return request functionality across FedNow and RTP.These changes affect several return-related 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

MilestoneDate
AnnouncementJune 10, 2026
Sandbox AvailableJune 30, 2026
Effective DateSeptember 30, 2026
​
Required Action by 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, 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 Format
/network-settlement/{card_network}/
New Format
/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

MilestoneDate
AnnouncementJune 10, 2026
Program-Specific Details DistributedPrior to September 2026
Effective DateSeptember 30, 2026
​
Required Action by October 6, 2026

​
Account Validation During New Balance Creation

Status: 🟡 Announced
Action 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 referenced account_id must:
  • Exist within Lead’s system
  • Belong to your program
Failures will return:
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:
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:
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

MilestoneDate
AnnouncementJune 10, 2026
Sandbox AvailableQ3 2026 (Planned)
Effective DateOctober 6, 2026
​
Required Migration by November 12, 2026

​
Wires API V2 Migration

Status: 🟡 Announced
Action 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
Additional address requirements will be documented in the wires guide.To make it easier for you to adopt this change, we will make the new address fields, including town_name and country, available as optional fields in the current version of the API by June 15, 2026. We encourage you to start passing this information as soon as possible to reduce the work required later when migrating to Wires API V2.

​
New Wire Attributes

Wires API V2 also introduces:
  • Updated wire statuses
  • 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

MilestoneDate
AnnouncementJune 10, 2026
Sandbox AvailableAugust 2026 (Planned)
Migration DeadlineNovember 12, 2026
ISO 20022 EnforcementNovember 16, 2026

​
Additional Resources

  • Wires API V2 Migration Guide (Coming Soon)