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

​

​
ACH Status Lifecycle Expansion

Status: 🟢 Sandbox Available
Action 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
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:
and
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:
  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

​

​
New Balances and Transactions File Alert

Status: ✅ Released
Action 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:
  1. Update your alert-handling logic to consume the new alert.
  2. Use the alert to trigger any corresponding action, such as submitting the next day’s files.
  3. 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

​

​
Daily Report V2 Migration and New Transaction Codes

Status: 🟡 Announced
Action Required: Yes (review downstream accounting, reconciliation, and reporting logic)
Sandbox Available: N/A (V2 sample files available by December 1, 2026)
Effective Date:  Transaction codes: January 20, 2027 // V2 files begin: No later than January 20, 2027 // Current (V1) files end: March 20, 2027We’re changing the daily activity and balance reports Lead sends you over SFTP. This notice covers every change that affects your reconciliation process:
  1. New transaction codes (January 20, 2027). Entries that post under code 37 today move to 910 (fees), 911 (interest), 912 (IntraFi sweeps), 913 (Lead-generated), and 937 (platform-initiated GL-to-DDA transactions). The 937 change was previously announced for December 3, 2026 and is delayed to January 20. API internal transfers initiated by Lead move from 1075 to 1016.
  2. New V2 activity and balance files (no later than January 20, 2027). V2 files use a transaction type instead of a numeric code and take the end-of-day balance from the ledger at 10:00 pm CT. They no longer wait on a separate end-of-day process, so they arrive on time and each day’s balance ties to that day’s activity.
  3. New columns are not breaking changes (V2 and later). Consistent with our API versioning policy, new columns in files are non-breaking changes and may be added without an Upcoming Changes notice. Your parser should identify columns by header name rather than position.
  4. Current (V1) files end March 20, 2027. Move to the V2 files or the Core Accounts, Core Balances, and Core Transactions APIs. With the Core APIs, you can read balances and transactions at whatever cadence your reconciliation runs, instead of waiting for a daily file.

​
Why We’re Making This Change

Today, several kinds of activity share code 37, and the balance report waits on a separate end-of-day process that can hold your reports. With these changes, the transaction codes, V2 files, and Core APIs use the same transaction types and identifiers, and V2 balances come directly from the ledger. Moving the December 3 date lets all changes that may affect your internal processes take effect on the same day.

​
What’s Changing

New Transaction Codes
Starting January 20, 2027, in your current activity report:Code 37 remains for a small number of true miscellaneous entries. Activity posted before January 20, 2027 keeps its original code. Core Transactions API integrations don’t need changes.
V2 Activity and Balance Files
V2 files arrive in a new SFTP folder, and Lead will notify you when they begin landing. Your current files stay in their existing folder until March 20, 2027.
  • Type and ID: Each entry has a type and a unique transaction_id, both matching the Core Transactions API.
  • 10:00 pm CT cutoff: Transactions after 10:00 pm CT, including daily interest posted shortly after midnight, appear on the next day’s file with the prior day’s posted_date. Online banking shows the live ledger, so it may differ from the file at the cutoff.
  • Source of truth: While both files are delivered, V2 is authoritative. Report any difference not on the expected-differences list to your Technical Account Manager. The V2 schema, sample files, code-to-type mapping table, and expected-differences list will be published by December 1, 2026.
  • Breaking changes: Renaming or removing a column, changing a column’s type, format, or meaning, or changing the file name or cadence. These are considered breaking changes and are announced ahead of the change on Lead’s Upcoming Changes page. New columns are not considered breaking, and are posted to the Changelog once they ship. Until March 20, 2027, Lead will correct data errors in the current files but won’t add new fields.

​
What You Need To Do

Before January 20, 2027:
  • If you’ll still read your current activity report on January 20, add the new codes to any logic that uses codes 37 or 1075.
  • If you prepared for the 937 change on December 3, keep recognizing code 37 for those entries until January 20.
Before March 20, 2027:
  • Choose the V2 files or the Core APIs.
  • For V2, read the new folder, parse columns by header name, use type instead of the code, and test with the December 1 sample files and mapping table.
If a third party reads your files on your behalf, share this notice with them. For migration help, contact your Technical Account Manager.

​
What Happens if You Don’t Act

  • From January 20, 2027, logic that only recognizes code 37 or 1075 may miscategorize or drop the new entries.
  • After March 20, 2027, current files stop, and integrations that read them stop receiving data.
  • V2 integrations that read columns by position may fail when columns are added.

​
Who This Affects

Partners that receive daily activity or balance reports over SFTP, and third parties that read these files for them. Partners that don’t use these reports are not affected.

​
Timeline

​
Additional Resources

​

​
Updated Transaction Codes for System Activity

Status: ⏸️ Delayed
Action Required: Yes (review downstream accounting, reconciliation, and reporting logic)
Sandbox Available: N/A
Effective Date:  January 20, 2027 (previously December 3, 2026)Timeline update: This change was previously scheduled for December 3, 2026. It now takes effect on January 20, 2027 as part of Daily Report V2 Migration and New Transaction Codes, so all transaction code changes take effect on the same day. The details below are otherwise unchanged.We’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.
For these transactions, the code will change from 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:
  1. Review accounting, reconciliation, and reporting workflows that identify affected entries by tran code.
  2. Update those workflows to recognize 937 instead of 37 for Lead-originated GL-to-DDA transactions.
  3. Test downstream processing against the updated code before the change takes effect.
If you already updated your workflows for December 3, 2026, continue to recognize code 37 for these entries until January 20, 2027.

​
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: 🟢 Sandbox Available
Action 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_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
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

​

​
Instant Payments Return API Updates

Status: ✅ Released
Action 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
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

​

​
Account Validation During New Balance Creation

Status: ✅ Released
Action 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 and ownership

The referenced account_id must:
  • Exist within Lead’s system
  • Belong to your program
Failures will return:

​
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 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:
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

​

​
Wires API V2 Migration

Status: ⏸️ Delayed
Action Required: Yes (Deadline will be enforced)
Sandbox Available: TBD
Effective Date: TBDWe’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 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
Additional address requirements are documented in the V2 Create-a-Wire API reference and V2 Migration Guide.

​
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 the migration deadline:
  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 the migration deadline:
  • Lead no longer supports V1 integrations.
  • Lead rejects wires that use unsupported address formats.

​
Timeline

​
Additional Resources

​

​
Receivable Sales and Receivables APIs

Status: 🟡 Announced
Action 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.
Imputed interest will be calculated on the principal amount Lead has extended as credit, rather than being adjusted for payments or refunds you report during the hold period. This keeps the calculation consistent regardless of your file processing status.

​
What You Need To Do

Before your switchover date:
  1. Migrate your integration to the Receivable Sales and Receivables APIs.
  2. Coordinate a switchover date with Lead.
  3. Test the full Receivable Sale and Receivable flow in sandbox once it becomes available (targeted for the second half of Q4 2026).
New programs will integrate against the API directly.

​
What Happens If You Don’t Act

The file-based Sales Request/Response process is being retired for in-scope programs. Partners that do not migrate by their coordinated switchover date risk disruption to their receivable sales process.In addition to these APIs, we’re also building out a full suite of APIs. This includes Balance and Transaction APIs. Lead will compute balances so partners do not need to report these. Lead will attribute any Transactions it processes (eg. ACH transactions processed via Lead) to their corresponding Balances automatically. The Transaction APIs are primarily how you’ll report transactions that occur outside Lead’s systems (e.g. card transactions). This is a meaningfully lighter reporting integration than today’s files; while partners are not required to migrate to both these APIs and the Receivable Sales and Receivables APIs at the same time, we want to highlight that there is an opportunity to migrate all integration touch-points from file to API. We’ll share more details in a separate announcement.

​
Timeline