Active Changes
Status Descriptions
Status Descriptions
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
New Balances and Transactions File Alert
Status: 🟡 AnnouncedAction Required: Yes, only if you use Slack alerts to drive file-processing workflows
Sandbox Available: N/A
Effective Date: October 6, 2026We’re adding a new Slack alert to indicate when the next day’s Balance and Transactions files can be submitted. The alert provides a definitive signal for submission timing, complementing the existing success alert, which confirms only that a file processed correctly.This is particularly helpful when a program is behind and the previous day’s files have not yet finished processing.This is an additive change to the existing file alert workflow.
Why We’re Making This Change
The existing successful-processing alert confirms that a file was received and validated, but it is not intended to indicate readiness to submit the next file. The new alert closes that gap by providing a dedicated signal for when the next day’s files can be submitted.What’s Changing
Lead is adding a new Slack alert related to Balance and Transactions files.- The existing alert confirming that files were submitted and validated successfully will continue to be sent.
- The new alert will indicate when the next day’s files can be submitted.
- The new alert is intended to distinguish successful file validation from readiness to submit the next day’s files.
What You Need To Do
No action is required if you do not use Slack alerts to drive file-processing workflows. If you process Slack alerts programmatically:- Update your alert-handling logic to consume the new alert.
- Use the alert to trigger any corresponding action, such as submitting the next day’s files.
- Test the updated workflow before the alert is enabled for your program.
What Happens if You Don’t Act
Your existing file-submission process will continue to work, but any automation that relies on Slack alerts will not receive or act on this new readiness signal unless it is updated to consume the alert. Those workflows may need to continue relying on existing error messages or manual checks to determine when to submit the next day’s files.Who This Affects
This update applies to everyone with a deposit, debit, and/or prepaid program.Timeline
Updated Transaction Codes for System Activity
Status: 🟡 AnnouncedAction Required: Yes (review downstream accounting, reconciliation, and reporting logic)
Sandbox Available: N/A
Effective Date: December 3, 2026We’re updating the transaction codes used for certain Lead-originated transactions to streamline downstream accounting processes. Transactions initiated by Lead between a GL and DDA will use tran code
937 instead of 37 in the Daily Activity Report.No line items will be added or removed. Only the transaction code for affected entries will change. If your program includes a card program and/or receivable sales, then your reports will be affected. More specifically, Network Settlement and the Sales process generate these transactions.Why We’re Making This Change
This change standardizes the classification of Lead-originated transactions between a GL and DDA, which supports more consistent downstream accounting processes.What’s Changing
The new tran code applies when both conditions are true:- The transaction was initiated by Lead.
- The transaction occurred between a GL and DDA.
37 to 937.The Daily Activity Report will continue to include the same line items. This update changes the applicable transaction code only.Below is a list of accounting entries today that Lead generates that will be affected - if any of your entries include this in the memo description, then it will have its tran code updated to from 37 to 937:{ProgramName} Interchange Fee Income {FileDate}-{CardNetwork}{ProgramName} Network Fee {FileDate}-{CardNetwork}{ProgramName} Receivables Funding {FileDate}-{CardNetwork}{ProgramName} Interchange Expense {FileDate}{ProgramName} Network Fee Expense {FileDate}{ProgramName} Interchange Payout {FileDate}{ProgramName} Network Fee Charge {FileDate}{ProgramName} Payment Principal {FileDate}{ProgramName} Receivables Interest Accrual {FileDate}{ProgramName} Receivables Purchase Principal {FileDate}{ProgramName} Loan Purchase Net Suspense {FileDate}{ProgramName} Canceled Disbursement {FileDate}{ProgramName} Disbursement Funding {FileDate}{ProgramName} Down Payment Funding {FileDate}{ProgramName} Held Disbursements {FileDate}{ProgramName} New Disbursements {FileDate}
What You Need To Do
Before the effective date:- Review accounting, reconciliation, and reporting workflows that identify affected entries by tran code.
- Update those workflows to recognize 937 instead of 37 for Lead-originated GL-to-DDA transactions.
- Test downstream processing against the updated code before the change takes effect.
What Happens if You Don’t Act
If your downstream processes rely on tran code 37 to identify these entries, they may not correctly recognize or classify affected transactions after the change. This may lead to inaccurate accounting, reconciliation, or reporting results until the logic is updated.Who This Affects
All Lead partners.Timeline
OAuth Access Token Caching
Status: 🟡 AnnouncedAction Required: Yes (Deadline will be enforced)
Sandbox Available: October 1, 2026
Effective Date: November 12, 2026We’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_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 token:- Evict the cached token.
- Request a new access token.
- Retry the request once.
Timeline
Instant Payments Return API Updates
Status: 🟠 Enforcement SoonAction 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
narrativeservice_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
Multi-Card Program File Updates
Status: 🟠 Enforcement SoonAction Required: Yes (If currently offering a card product)
Sandbox Available: N/A
Effective Date: September 30 - October 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
Account Validation During New Balance Creation
Status: 🟡 AnnouncedAction Required: Yes (Deadline will be enforced)
Sandbox Available: September 22, 2026
Effective Date: October 6 - November 10, 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.Examples: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
Earlier ACH Posting
Status: 🟡 AnnouncedAction Required: Recommended (partners are recommended to review their time-dependent processes; no enforced deadline)
Sandbox Available: N/A
Effective Date: November 12, 2026We’re moving ACH posting earlier across all settlement windows so you receive money-movement information sooner. Instead of waiting for each Federal Reserve settlement window, we’ll post entries as soon as we receive the Fed’s advice file for that window. The largest change is in the morning, where entries will post roughly 4 hours earlier than today.
What’s Changing
Today, ACH entries post to your accounts at approximately the time of their Federal Reserve settlement window — for example, entries settling in the 8:30 a.m. ET (7:30 a.m. CT) morning window post at approximately 8:30 a.m. ET. Starting November 12, 2026, we’ll post entries as soon as we receive the Fed’s advice file for each window instead of waiting for the window itself. In practice this means:- This applies across all settlement windows, not just the morning window.
- Both incoming and outgoing entries — credits and debits — post earlier.
- Balances reflect ACH activity earlier in the day, with the largest change in the morning window (roughly 4 hours earlier than today).
- Your
ach.postedwebhooks (and any downstream events you consume) fire earlier by the same amount. - The order and content of events do not change. Only the time of day moves.
- Exact posting time may vary day to day depending on when we receive the Fed’s advice file for each window. Treat the new timing as approximate, not a fixed schedule.
Why This Matters
Earlier posting gives you and your customers faster visibility into money movement and faster access to incoming funds. The extra runway each morning gives your teams and systems more time to run fraud and risk review, make funds availability decisions, send customer notifications, and complete reconciliation before the business day starts.If your integration is event-driven, you receive the benefit automatically. If any of your processes assume ACH posts at fixed window times (at or after 8:30 a.m., 1:00 p.m., or 6:00 p.m. ET) — morning reconciliation jobs, batch sweeps, fraud and risk queues, or time-keyed customer notifications — we recommend reviewing them before the effective date. Note that debits post earlier too, so morning available balances may be lower, as well as higher, than they are today.Timeline
Wires API V2 Migration
Status: 🟡 AnnouncedAction Required: Yes (Deadline will be enforced)
Sandbox Available: TBD
Effective Date: End of Q4 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
The Federal Reserve plans to introduce additional requirements for Fedwire, including changes to address formatting and message validation. While the release originally planned for November 2026 has been delayed, these requirements are still expected to take effect at a later date.We are moving forward with Wires V2 in Q4 2026 because the release includes improvements that are valuable independent of the Fedwire timeline and provides the foundation for future wire enhancements. Migrating now will also ensure partners are prepared for the future Fedwire requirements without requiring another breaking API migration later.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 Q4 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 Q4 2026:- Existing V1 integrations will no longer be supported.
- Wires submitted using unsupported address formats will be rejected.
Timeline
Additional Resources
Receivable Sales & Receivables APIs
Status: 🟡 AnnouncedAction Required: Yes (Migration required; switchover date coordinated with Lead)
Sandbox Available: Second half of Q4 2026 (Planned)
Effective Date: March 31, 2027We’re migrating the receivable sales process from Sales Request/Response files to an API-native experience. With the new Receivable Sales and Receivables APIs, you can purchase loan and credit card receivables independent of any other workflow.Today, completing a Receivable Sale depends on your Balance and Transaction files processing successfully. Reconciliation discrepancies can block file processing and hold up a Receivable Sale. The new APIs remove that dependency.
Why We’re Making This Change
Tying Receivable Sales to file processing means a reconciliation discrepancy can block an otherwise valid Receivable Sale. Moving to an API-native model decouples the two, streamlines the sales process, and gives you a simpler, more reliable way to complete purchases and inspect what’s being sold.What’s Changing
- Lead generates a Receivable Sale daily, which triggers a webhook for you to process. On a scheduled daily basis, Lead debits your account for the purchase amount.
- You can inspect any Receivable Sale through the Receivables API to confirm what’s being sold before it settles.
- Your Receivable Sale obligations are no longer tied to successful Balance and Transaction file processing. Reconciliation discrepancies that previously blocked file processing will not affect your ability to complete a Receivable Sale.
- Receivable Sale objects communicate the aggregate amount for purchase across all receivables.
- Receivable objects communicate the individual receivables that comprise a Sale (for example, term loans or credit card settlements). For a given day, Lead represents the total network settlement as a single aggregate receivable rather than listing out the individual transactions that comprise it.
What You Need To Do
Before your switchover date:- Migrate your integration to the Receivable Sales and Receivables APIs.
- Coordinate a switchover date with Lead.
- Test the full Receivable Sale and Receivable flow in sandbox once it becomes available (targeted for the second half of Q4 2026).