Skip to main content
​
3/3/2026
🚀 New

​
Applications API Now In Beta

The Applications API is now available in beta to support real-time workflows for lending and overdraft products. This API lets you submit underwriting decisions — approved, declined, or canceled — in real time, as an alternative to the file-based application workflow. It’s also compatible with existing credit use-cases. For example, you can submit Applications via API even if you plan to use files to report Balances and Transactions.Why this mattersThe file-based workflow surfaces validation errors via Slack notification, 5–10 minutes after submission. The Applications API returns errors synchronously — you know immediately whether your data is valid. For lending use-cases, it also works in tandem with the Subledger Balances and Funding APIs: Lead wants to ensure you are capturing loan application data compliantly before you instruct Lead to originate a loan. The API is also compatible with credit use-cases (e.g., credit cards) more broadly.Approved applications return an application_id, which you’ll use to create an Account. Accounts are the next step in the lending sequence and an Account API is coming soon.Functionality
  • Submit approved, declined, or canceled applications
  • Retrieve applications by ID
  • Retrieve all account holders and authorized signers associated with an application
Getting StartedThe Applications API is available in Sandbox for new partners starting today.For existing partners submitting the Applications file, there is coordination required with our team to prepare your program before you can switch to the API.
Please reach out to your Technical Account Manager if you have interest in switching to an API-based flow for submission of Application data.
Learn More
​
2/26/2026
📆 Coming Soon

​
Instant Payments & International Wires

Here’s what you need to plan for to take advantage of these new products.

​
Instant Payments

Our first offering of instant payments will be FedNow — giving you the ability to send and receive payments in ~20 seconds, 24x7x365.Available NowTimeline
  • API GA: End of April
Testing
  • Sandbox: Our Sandbox environment will be ready by the end of March. We strongly recommend using this window to prioritize and test receiving instant payments first.
  • Controls: You will have full control over incoming and outgoing instant payments via “accept,” “reject,” and “allowlist” settings at the account number level, identical to our current wire controls.
Notes
  • Critical Deadline of April 30: When we enable instant payments at the end of April, incoming payments that previously used other rails may “rail hop” to FedNow.
  • Important: Lead will auto-reject incoming instant payments if a partner is not yet configured to receive them. 
  • Recommendation: To avoid these missed payments and business disruptions, we strongly recommend all partners be prepared to receive incoming instant payments by this date.

​
International Wires

Outgoing USD wires (via intermediaries)We’ll support the ability to send USD wires to foreign financial institutions (reach depends on correspondent relationships).Two workflow options:
  • Provide your own intermediary by including it directly in the wire request
  • Use our intermediary lookup and we’ll populate the appropriate U.S. correspondent for you
Incoming WiresWe’ll be publishing a BIC (Bank Identifier Code) so foreign institutions can send wires using standard correspondent banking details (no U.S.-specific routing required).Timeline
  • Updated API Preview: March
  • Sandbox: Early April
  • API GA: End of April
​
1/20/2026
🚀 New

​
Refreshed Documentation

We’ve made a significant investment in improving our documentation — and this refresh is just the first step. Our goal is to deliver clearer, more comprehensive, and more useful docs that continue to evolve alongside our products.What’s new in this release:
  • AI-powered search: Ask questions in plain English and get relevant answers instantly — going beyond simple keyword matches.
  • Changelog RSS feed: Subscribe once and stay up to date on product and documentation changes.
  • Faster load times: Pages now load significantly quicker, so you can get what you need without waiting.
  • Improved navigation and structure: Find the right guide or reference with fewer clicks.
This update lays a stronger foundation, but it’s not the finish line. We’re actively investing in expanding coverage, improving clarity, and keeping documentation in lockstep with new features and releases.We have many more updates planned throughout the year and your feedback plays a key role in how we think about documentation. Please share your suggestions for this site with your Technical Account Manager and they’ll pass them along to our product team.
​
1/05/2026
✨ Improvement

​
Updated Slack Alerts for File Validations

We’re improving the format and clarity of our file validation alerts in Slack to make issues easier to understand and resolve. This update affects message content only — there are no changes to validation logic or alert timing.What’s new
  • Standardized Format: Alerts now include clear Error Code, Detail, and Action sections.
  • Program Visibility: Each alert specifies the affected program, helping you managing multiple programs.
  • Actionable Guidance: Messages provide concrete steps to fix the issue and resubmit the file.
  • Documentation Links: Alerts include links to relevant docs for faster troubleshooting.
This change will roll out gradually throughout January. Your Technical Account Manager will confirm the timeline for your program.
​
12/09/2025
🚀 New

​
New Payment Controls at the Account Number Level

You should be able to fully manage ACH, Wires, and Internal Transfers without contacting your bank partner. That’s why we’ve built powerful payment controls directly into our API — giving you the precision to block or allow transactions at the account number level.Here’s how it worksConfigure the controls through the create or update Account number API.
Reaching out to Lead to block account numbers is no longer required.
Example
  • To determine if incoming ACH credit is accepted, use accept_credit.
  • To determine if incoming ACH debit is accepted, use accept_debit.
The counterparty_filter (accept_all, reject_all, allowlist_only) and counterparty_account_numbers_allowlist determine which counterparties are allowed to send or receive payments.Default behaviorIf no controls are configured, we default to accept_credit=true, accept_debit=true, and counterparty_filter=accept_all, maintaining the current permissive behavior.
The API will automatically prevent contradictory configurations, such as accept_credit=false combined with counterparty_filter=accept_all.
Start using the new controls todayIf you’re currently relying on our team to return unexpected payments, it’s time to make the switch. By integrating with our APIs, you can automatically block transactions on specific accounts, reducing operational friction and ensuring funds don’t land where they shouldn’t.Save time, reduce risk, and streamline your payment operations — all while avoiding manual returns.Get started with the Account Number API today.
​
12/08/2025
🚀 New

​
New Originator Endpoint for ACH Transactions

We’ve introduced a new originator endpoint that gives you more control and flexibility when originating ACH payments. You can now manage multiple ACH Company IDs under a single bank account, making payments more clearly identifiable to your end users.What’s new
  • Configure ACH Company IDs, names, and other Nacha details directly through the new endpoint
  • Send payments from a single bank account while using multiple company IDs
  • Improve brand visibility and transparency for end users
What this means for you
  • If you originate under a single Company ID:
    • No changes are required. Lead will automatically handle setup. The only difference you’ll see is that an originator_id will now appear on the account_number object in API responses.
  • If you originate under multiple Company IDs:
    • You’ll be granted access to the new originator APIs. Once enabled, you can create and manage originators and associate them with your end users’ account numbers as needed.
Further ReadingCheck out the Originator API and reach out to your Technical Account Manager to discuss if this functionality is right for you.
​
10/27/2025
🚀 New

​
Removal of Single-Character Last Name Validation for Entity API and Customer Files

Lead will no longer reject entities with single-character last names at the point of entry. There will no longer be a manual review process for Lead’s team to conduct additional due diligence on all individuals with single character last names.This change removes a validation restriction to improve the onboarding experience for legitimate users. This update is particularly beneficial for partners serving international customer bases where single-character last names are more common.What this means for API and file-based workflowsAPI Requests (POST and PATCH) and Customer File Uploads for entities with single-character last names will no longer be rejected by this specific validation. Requests that would have previously failed will now be accepted. No manual review submissions via file uploads for entities with single character last names will be required.This is a nonbreaking change as it removes a restriction; it does not introduce a new requirement.Validation Behavior
Previous ValidationNew Validation
Entities with single-character last names were rejected at the point of entry.Entities with single-character last names are accepted at the point of entry.
Note: Partners continue to have the business expectation to provide valid last names that match KYC / identification documents.
​
12/16/2025
✨ Improvement

​
Settlement Amount Calculations

We’ve clarified our documentation and examples in Settlement Amount guide to accurately reflect how Lead has been calculating the SOFR rate for receivables during the hold period by adding the following note:
  • When applicable, the SOFR rate is set based on the rate published on the last business day of the month prior to the loan’s origination date. This rate remains fixed for the entire hold period, even if the hold period spans multiple months.
Settlement Amount only applies to credit programs where imputed interest is charged.
​
10/15/2025
✨ Improvement

​
Updates to the Outstanding Credit Balance Payment Attribution

We’ve improved how payments are attributed to outstanding credit balances to ensure greater accuracy and consistency. This new method can help reduce your imputed interest charges.What’s changed
  • Refunds and disputes are now applied directly to the original transaction on a first-in, first-out (FIFO) basis.
  • This clears the oldest outstanding balances first, leading to a more precise calculation of your credit balance and potential interest savings.
For more information, see our updated Settlement Amount guide.
This change only affects credit programs where imputed interest is charged.
​
09/16/2025
✨ Improvement

​
KYC Data Requirements For Non-US Authorized Users

Lead no longer requires full KYC to be complete for Non-US Authorized Users. Non-US Authorized User data requirements now match those of US entities.What this means for API and file-based workflows
  • API Requests (POST and PATCH) and Customer File Uploads that specify the intended role of authorized user will succeed as long as first name, last name, and contact information for the individual entity is provided in the request.
  • You may now use an Entity ID for all Authorized User use-cases as long as you have provided a first name, last name, and contact information for the individual entity.
What this means for API-only workflowsYou may now expect to see status: active for the authorized_user role in the role_details property of a Lead Entity, in POST and PATCH responses as well as GET entity requests.Requirements
Previous RequirementsNew Requirements
- First name - Last name - Contact method (email or phone number) - If not a US entity1, require full KYC2 1. An entity is a US entity if they have a US tax identification number
2. Full KYC: Name, date of birth (applies to individual entity only), physical address, and government verified ID		- First name - Last name - Contact method (email or phone number)
​
09/07/2025
🛠️ Fix

​
Slack Integration Maintenance Completed

The scheduled maintenance for our Slack integration has been successfully completed, and all related services have been restored.The maintenance window occurred today, Sunday, September 7, 2025, from 7:00am to 9:00am ET. Our integration is now fully operational.
  • Team Availability: Our team is once again available and reachable via our shared Slack channels.
  • Automated Alerts: Automated Slack alerts indicating successful or failed file processing outcomes are now generating as normal for all files uploaded after 9:00am ET.
As mentioned in the initial notice, any files processed during the maintenance window did not generate a Slack alert, and these alerts will not be sent retroactively. File processing itself was not impacted.We appreciate your patience and understanding as we completed this necessary work. If you encounter any issues, please don’t hesitate to reach out to our support team.
​
08/27/2025
✨ Improvement

​
Entity & Customers File Timestamp Precision

Previously, Lead’s Entity API and Customers’ file truncated timestamps to rounded-down second-precision. For example, a request with the timestamp of 2025-02-10T17:22:34.0001Zwas stored by Lead, returned in GET requests, and used for Lead’s business validations, with a value of 2025-02-10T17:22:34.0000Z.Moving forward, all timestamps submitted by partners for customer/entity records will be persisted with the precision up to nanosecond.Existing timestamps stored in Lead will remain truncated.Before this change
  • POST/upload entity 1:
    • Request: 2025-02-10T17:22:34.0001Z
    • Response:2025-02-10T17:22:34.0000Z
  • GET entity 1
    • Response: 2025-02-10T17:22:34.0000Z
After this change
  • GET entity 1
    • Response: 2025-02-10T17:22:34.0000Z
  • POST/upload entity 2:
    • Request: 2025-03-10T17:22:34.0001Z
    • Response:2025-03-10T17:22:34.0001Z
  • GET entity 2:
    • Response:2025-03-10T17:22:34.0001Z
Timestamps may be submitted with less-than-nanosecond precision without issue. For instance, 2025-03-10T17:22:34Z is a valid timestamp submission, that Lead will treat as 2025-03-10T17:22:34.0000Z
​
08/27/2025
✨ Improvement

​
Documentation Updates

We’ve made a few clarifications to our documentation:
  • Transactions Update File Schema
    • Clarified which combinations of transaction and transfer types are permitted to have an updated settlement date
    • Added additional description to clarify the purpose of the file and when it should be used
​
08/25/2025
✨ Improvement

​
Updated Iconography for Slack Alerts

We’re changing our iconography for Slack alerts to ensure consistency and make it easier to quickly recognize the type of message you’re receiving.
  • 🔴 Error: a required file or action failed and needs your attention
  • 🟡 Warning: something looks off, but may not block processing
  • 🟢 Success: the file successfully processed or action completed
​
08/21/2025
✨ Improvement

​
Documentation Updates

We’ve made a few updates and clarifications to our documentation:
  • Accepted Currencies
    • Removed ANG as an accepted currency. Please use XCG as the currency going forward
    • Removed SLL as an accepted currency. Please use SLE as the currency going forward
  • File Naming Convention
    • Clarified that the file naming convention must be either a generation time (must be an epoch timestamp and not ISO 8601) or version number (v1, v2, etc.).
  • Validation messages for Sales Request and Sales Response files
    • We’ve improved Slack validation messages for financial file submissions. You’ll now get clearer step-by-step alerts that make it easier to track progress, spot issues, and follow up as needed.
    • Here’s what’s new:
      • Balance and Transaction File Submission: You’ll receive a success alert as soon as these files are received and pass initial validation.
      • Sales Request Generation: Once we generate the expected sales for your submitted data, you’ll get a dedicated alert confirming this step.
      • Sales Response Submission: After your sales response file is received and validated, you’ll see a final alert confirming its acceptance.
​
8/16/2025
🚀 New

​
Platform Upgrades FAQs

Why we’re upgrading
As part of our continued investment in banking infrastructure, we’re upgrading our systems to improve performance, reliability, and scalability for our clients. This migration is a key component of that effort.Timeline
  • October 15, 2025: Redirect all incoming ACH and Wires to the account numbers and routing numbers listed in the List of Accounts file sent to your Signatories and Trusted Points of Contact..
  • October 15, 2025 - February 28, 2025: In this phase, we’ll move you to the new platform with a transition and execution plan tailored to your program. Although we don’t anticipate using the full window, we’ve provided a clear timeframe to guide expectations.
  • March 2026: Upgrade complete.
Please raise them in Slack. As we move through the project, we’ll provide updates on timelines, milestones, and any required actions there.
After this date, any incoming payments to your account using the legacy routing number will be flagged, and we’ll notify you before returning the funds. To ensure a smooth transition, please redirect all incoming payments before then.
Please notify us via Slack if you are aware of any items scheduled to post to your account via the legacy routing number. Refer to the List of Accounts file for your new account details.
Outgoing wires, outgoing ACH transfers, and check processing will remain unaffected through March 2026.
The account and routing numbers in the List of Accounts file will be your designated account and number going forward. We do not anticipate any additional redirects for the foreseeable future.
If you are currently instructing your counterparties to send payments to an account number with the legacy routing number, you will need to notify them of the change. Please begin directing them to use your new account and routing number details listed in the List of Accounts file.
No changes will take effect immediately as the upgrade isn’t scheduled to complete until March 2026; however, we’re anticipating a significantly improved experience, including:
  • Increased uptime with minimal to no maintenance-related downtime
  • A modernized online banking interface with enhanced controls and expanded functionality
  • A streamlined account opening experience designed for speed and ease of use
No. Currently Positive Pay is not supported. You will be responsible for monitoring all payments and initiating a return when appropriate. If you are integrated with the API, you will receive notifications via webhooks for incoming payments. If you are currently not receiving webhooks, and would like to turn this on - please reach out and we can help with this.
No. If you are integrated with the API, you will receive notifications via webhooks for incoming payments. If you are currently not receiving webhooks, and would like to turn this on - please reach out and we can help with this.
We’re reviewing your program and will contact you with next steps when it’s time to move you to the new platform.
Yes, to the bank statements. Previously, each individual ACH transaction posted as its own line item. When you transition to your new account and routing number, this behavior will change. Instead of posting individually, incoming ACH will post as an aggregate amount per ACH settlement window just as you see with your BaaS programs. If you use the API, individual ACH transaction details will be supplied in your supplemental reports.
​
08/15/2025
🚀 New

​
Enforcement of ACH & Wire Limits

Effective date: September 15thWe’re transitioning from soft to hard limits for ACH and Wire payments. Payments that exceed configured limits will be rejected immediately at submission - rather than being flagged for manual review.What’s changing:Previously, payments that exceeded per-transaction or aggregate limits were allowed to proceed and were routed to our team for manual review. This often caused processing delays and required follow-up with your team to confirm next steps.Why this helps:This update gives you faster, more actionable feedback and reduces uncertainty:
  • Faster feedback: You’ll know instantly if a payment exceeds your limits - no more waiting for a manual review.
  • Fewer delays: Immediate rejection lets you adjust and resubmit right away, keeping payment flows moving.
  • More control: Limit issues are surfaced at the point of submission, so you can troubleshoot and resolve them without relying on intervention from Lead’s support team.
Error behavior:
Submission MethodFormatDetails
APIAPI response bodyACH or wire payments that exceed the outgoing per-transaction limit will return a synchronous error in the API response body: JSON { "title": "Validation Error", "code": "per_transaction_limit_exceeded", "detail": "Entry would exceed per transaction limit. Current limit value: [LIMITVALUE].", "status": "422" }
APIach.rejected or wire.rejected webhooksACH or wire payments that exceed the outgoing daily or rolling 30 day aggregate limit will trigger an asynchronous webhook containing the rejection reason aggregate_limit_exceeded. Full rejection details are available in the rejection hash: JSON "rejection": { "reason": "aggregate_limit_exceeded", "details": "Entry would exceed the aggregate limit. Current limit value [LIMITVALUE].", }
File uploadFull file rejectionIf a submitted file contains entries that exceed ACH limits, the entire file will be rejected. An alert will be sent to your dedicated alerting Slack channel: Text Error Code: "aggregate_limit_exceeded" Description: "Entry would exceed the aggregate limit. Current limit value: [LIMITVALUE]."
Next steps:Review your current ACH and wire limits and ensure they are sufficient to support your payment daily and rolling 30 day payment volumes. Contact our Business Banking team if you need to make updates.Monitor your limits regularly to allow for proactive limit increase requests when necessary to avoid failed transactions and ensure uninterrupted payment activity.
​
07/14/2025
✨ Improvement

​
Docuentation Updates

We’ve made a few updates and clarifications to our documentation:
  • Balances
    • For deposit programs with interest, interest_accrued_balance and interest_accrued_balance_in_usd must be at least the minimum number of decimal places required by the currency. For example, if the currency is USD, value must be at least 2 decimals 11.500.
  • Transactions
    • When the transaction.type = interest_accrued, amount and amount_in_usd must be at least the minimum number of decimal places required by the currency. For example, if the currency is USD, value must be at least 2 decimals 11.500.
  • Clarified definitions for some transfer types
    • no_money_movement
    • out_of_bank_settlement
  • Bank Reporting Overview
    • Added clarification that daily balance and activity reports are comma delimited, while ACH cash recon reports are pipe delimited
​
07/03/2025
✨ Improvement

​
Documentation Updates

We’ve made a few clarifications to our documentation:
  • Accepted Currencies
    • Corrected MGA to have 2 decimals
    • Added the following currencies: XCG, KPW, UYW, ZWG, SYP, IRR, VES, STD, CUP, CUC, LYD, MRU, CNH
​
06/26/2025
🚀 New

​
Upcoming Validations & Adoption Deadlines

We’ve made a one-time adjustment to the rollout timeline for upcoming account number and entity validations.To give customers more implementation time, we’ve shifted our original enforcement dates slightly. This delay is not part of a broader trend - you should continue to expect that future deadlines for breaking changes will be firm.Your systems should be fully prepared to handle the new validations by the adoption deadlines listed below. After those dates, Lead will begin our own rollout, with at least 7 days’ notice before enforcement begins on our side.Each phase below outlines what’s changing, how to prepare, and what to expect when enforcement starts.
Adoption Deadline: July 17th, 2025
  • What’s changing:
    • New account numbers must be associated with the account_holder role.
  • How to prepare:
    • Use the Entity API to create all customer records.
    • (Optional but recommended) Set intended_roles: [“account_holder”] when creating the entity. This ensures the entity can create Account Numbers.
  • What happens after:
    Lead will begin rejecting:
    • Requests to link account numbers to entities without the account_holder role (returns a 422 Unprocessable Entity error).
Adoption Deadline: August 14th, 2025
  • What’s changing:
    • All existing account numbers must be linked to an entity that holds the account_holder role.
  • How to prepare:
    • If not already shared, Lead will provide a list of entities who don’t pass current data validations or whose records Lead is unable to retrieve from an Account Number
    • Use the PATCH endpoint to update these entities.
    • (Optional but recommended) Set intended_roles: [“account_holder”] when creating the entity. This ensures the entity can create Account Numbers.
  • What happens after:
    Lead will run a migration to deactivate account numbers that:
    • Aren’t linked to an entity
    • Are linked to entities not eligible for the account_holder role
Adoption Deadline: September 4th, 2025
  • What’s changing:
    We’ll validate that the creditor name on incoming wires matches the name of the entity linked to the receiving account number.
  • How to prepare:
    • Lead will share a list of incoming wires that would fail under the new validation.
    • Review the list and notify end customers if needed.
  • What happens after:
    We’ll begin rejecting incoming wires if:
    • The linked entity is missing or invalid
    • The beneficiary name doesn’t reasonably match the entity name
​
06/23/2025
✨ Improvement

​
Examples Addded to Accounts File Schema

We’ve added an example and clarified the description of the expected contents of the documents field in the Accounts File Schema
FieldDescriptionRequiredData Type
documentsAn array of JSON hashes of customer-facing documents. The JSON hash should reference any dynamic document that has been uploaded to the Documents folder or the consented version of a static document approved by Lead compliance, and include the document name/type, its client_document_name or document_id, its version, and its consent date. The required docs will be defined between the client and Lead bank during setup.RequiredExample- [{"document_id": "client_document_123", "type": "xyz_firm_privacy_notice", "consented_at": "2025-02-12T15:38:34.101-06:00", "version": "20220202"}] Note: JSON strings embedded in CSV fields must be enclosed in double quotes, with internal double quotes escaped by doubling them (""). Original: [{"id":1,"name":"Alice"},{"id":2,"name":"Bob"}] CSV-escaped: "[\{""id"":1,""name"":""Alice""},{""id"":2,""name"":""Bob""}]" For documents uploaded via SFTP, please input the full file name as document_id. The suggested naming convention is: <Date>__<AccountID><FileType><Version>.<FileExtension>

Changes
  • Updated and clarified the type of transactions accepted for Deposit and Credit
  • Deposit:
    • Added Reversed as a supported action for the following type: charge_off , charge_off_recovery
    • Removed Reversed as a supported action for the type disbursement
  • Removed the following as a type of transaction:
    • Cancelled
    • Fee with fee_type of atm, overdraft, periodic_maintenance, other
  • Credit:
    • Added Reversed as a supported action for the following type: charge_off , charge_off_recovery
​
06/11/2025
✨ Improvement

​
Documentation Updates

We’ve made a few clarifications to our documentation to enable a more seamless onboarding experience for partners, specifically:
​
06/04/2025
🚀 New

​
New Payments Functionality

We’re making important updates to our payment infrastructure based on your feedback. These changes are designed to improve predictability and reduce manual effort - especially around ACH, wires, and file-based processing.Some of the updates will require action on your end. Without these changes, certain payment workflows may fail or behave unexpectedly.We know updates like these take time and effort. Thank you in advance for adapting - we’re confident the improvements will result in faster feedback, easier troubleshooting, and a more reliable developer experience.This update includes the following key elements:
  1. Synchronous ACH API validation errors
    Starting June 18, More validation failures will now return real time HTTP 422 error responses instead of asynchronous webhooks.
  2. File-Based ACH validations
    Starting June 18, Nacha files containing validation failures will be rejected in full.
  3. Fixed cutoff times for ACH processing windows
    Starting August 11, all ACH submission cutoffs will be enforced as hard deadlines (no best-effort processing). Additionally, the final same-day and next-day ACH submission cutoffs are moving earlier.
  4. ISO 20022 Fedwire migration
    Fedwire is transitioning to ISO 20022 format. Partners must be ready for new message structures and can transition to Wires V1 between July 3rd and July 10th. July 10th onwards all partners must be on Wires V1.
  5. Previously announced: upcoming Q2 feature deadlines
    Reminders for previously announced changes taking effect July 1st, including Entity requirements, Wire validation, and Internal Transfers V1.
Effective date: Jun 18, 2025ACH origination and return submissions via API that fail certain semantic validations will now return real-time validation errors (HTTP 422) instead of triggering asynchronous error notifications via webhook. Some validations may still fall back to asynchronous handling for exceptions and trigger a webhook. The full list of validations run by Lead can be found here.What’s changing: You’ll now receive synchronous error responses on initial submission, enabling faster debugging and reduced turnaround time.Next steps:
  • Ensure your systems are prepared to handle synchronous responses.
  • Update error handling logic as needed based on the validations list here .
Effective date: Jun 18, 2025We are updating our Nacha file processing logic to strictly enforce entry-level validation rules. Starting June 18, any file containing one or more invalid ACH entries will be rejected in full.What’s changing: Each entry contained in a Nacha file will be validated, and if any entry fails validation, the entire file will be rejected — no entries will be processed.A Slack alert will be posted to your designated ‘alerts’ channel detailing the reason for the rejection.Why this helps: Catching issues at submission helps prevent downstream errors, unexpected return files, or delays in processing. This change reduces operational friction by surfacing problems before they reach the network.Next steps:
  • Review the list of possible validation failures here and update your file generation process to avoid common errors.
  • Ensure your team monitors your Slack channel and is prepared to correct and resubmit rejected files promptly.
Effective date: Aug 11, 2025To better support our clients’ businesses, we are formally expanding support for all six FedACH windows for ACH submission—three same-day and six next-day windows. This provides greater flexibility in when you can submit payments and improves your ability to meet time-sensitive disbursement needs.Additionally, we are updating cutoff times for the final ACH processing windows to ensure consistent, predictable delivery to FedACH. These cutoff changes affect only the last windows for same-day and next-day ACH submissions.What’s changing:Lead will support submission into:
  • All three same-day ACH windows
  • All six next-day ACH windows
Updated cutoff times for final windows:
  • Same-day ACH cutoff: shifting from 3:15 PM CT to 2:00 PM CT
  • Next-day ACH cutoff: shifting from 12:45 AM CT to 10:00 PM CT (prior day)
  • Next-day returns cutoff: shifting from 12:45 AM CT to 10:00 PM CT (prior day)

​
Same-day ACH

Lead’s Cutoff DeadlineCorresponding Fed Window DeadlineSettlement Time (at Counterparty’s Bank)Effective Date
09:00 AM CT09:30 AM CT12:00 PM CT (Same Business Day)current day
01:15 PM CT01:45 PM CT04:00 PM CT (Same Business Day)current day
02:00 PM CT03:45 PM CT05:00 PM CT (Same Business Day)current day

​
Next-day ACH

Lead’s Cutoff DeadlineCorresponding Fed Window DeadlineSettlement Time (at Counterparty’s Bank)Effective Date
09:00 AM CT09:30 AM CT07:30 AM CT (Next Business Day)next business day
01:15 PM CT01:45 PM CT07:30 AM CT (Next Business Day)next business day
03:15 PM CT03:45 PM CT07:30 AM CT (Next Business Day)next business day
06:30 PM CT07:00 PM CT07:30 AM CT (Next Business Day)next business day
09:15 PM CT09:45 PM CT07:30 AM CT (Next Business Day)next business day
10:00 PM CT01:15 AM CT07:30 AM CT (Next Business Day)next business day
Submissions after these Lead cutoff times will no longer be processed on a best-effort basis. Instead, they’ll be automatically queued for the next available window, ensuring consistent outcomes.Why this helps:
  • Access more FedACH processing windows, giving you additional flexibility to meet customer needs
  • Eliminate uncertainty from “best-effort” processing - align your submission workflows to a clear, reliable schedule, which is easier to manage and automate
Next steps:
  • Review your submission schedules to ensure alignment with the new cutoffs.
Effective date: July 3, 2025Fedwire is migrating to the ISO 20022 message format. This is a mandatory, industry-wide change, and all Lead partners using our Wire APIs must migrate to Wires V1 to remain compatible. As a follow-up to our previous announcement, we’re providing more details on what’s changing and outlining the required actions for our partners.What’s changing: Fedwire is retiring the FAIM format and adopting ISO 20022, which introduces structured fields for originator and beneficiary details, BICs, remittance info, and more.Lead’s current Wires V0 implementation is not compatible with ISO 20022 and will be deprecated. The Wires V1 sandbox will be available for testing starting on June 13, 2025. All partners must migrate from Wires V0 to Wires V1 by July 10, 2025.Rollout plan:
DateRelease milestoneRequired Action(s)
June 13, 2025Wires V1 Sandbox go-liveBegin testing against the Wires V1 Sandbox APIs and webhooks.
July 3, 2025Wires V1 Production APIs and webhooks go-livePartners are now able to begin migrating from V0 to V1 APIs in production. Please reach out to Lead when you’d like to migrate.
July 10, 2025Deadline for V0 to V1 migrationPartners must complete the migration from V0 to V1 by this date.
July 11, 2025Wires V0 Production APIs and webhooks deprecatedNo required action.
Next steps:
  • Review and test in the Wires V1 sandbox in accordance with the updated API documentation and sample payloads (coming soon).
  • Migrate to Wires V1 in production between July 3rd and July 10th. This version includes updated request formats and response fields designed to support ISO 20022 structure.
  • Validate any internal systems that process webhook data or depend on wire message structure.
AnnouncementSummaryEffective Date
Entity Association Requirement for Account Number ActivationActive Account Numbers must be linked to an Entity with the account_holder role, or they will be deactivated.July 1, 2025
Validation of Beneficiary on Incoming WiresThe beneficiary name on incoming wires must match the name on the Entity that owns the Account Number to meet FinCrimes compliance.July 1, 2025
Internal Transfer v1 Release; Removal of v0V0 will be deprecated. Migrate to internal_transfer V1 for improved async behavior.July 1, 2025
New Controls Available on Account NumbersYou will be able to set optional ACH permissions on account numbers, including flags for credits, debits, and allowed counterparties.Early Q3
​
05/30/2025
✨ Improvement

​
Documentation Improvements

We’ve made a few clarifications to our documentation to enable a more seamless onboarding experience for partners, specifically:
  • SFTP Connectivity:
    • Clarified that SFTP folders are auto-created upon initial upload of a file to the desired path.
  • File Delivery Overview:
    • Clarified that CSV files should be formatted with a pipe delimiter, and not with a comma or semicolon delimiter.
    • Added recommendation that partners use an open source CSV parser to confirm that a CSV file is valid before submitting it to Lead for more streamlined processing.
    • Clarified that all file header values are case-sensitive, and partners should refer to specific file schemas to ensure they are formatted accordingly.
  • Customer File Schema:
    • Added in an example E.123-formatted phone number that will pass Lead’s validation for easy reference.
  • Applications File Schema:
    • Clarified the requirements for the credit bureau data-related fields (credit_pulled_at, credit_score, and credit_report_source). These fields are only required if your program’s underwriting policy requires credit bureau data on all applications. This will be agreed upon with Lead’s Legal team during your implementation process.
  • Accounts File Schema:
    • Clarified the requirements for the credit bureau data-related fields (credit_pulled_at, credit_score, and credit_report_source). These fields are only required if your program’s underwriting policy requires credit bureau data on all accounts. This will be agreed upon with Lead’s Legal team during your implementation process.
    • Added other as a valid enum for status_reason
  • Transactions File Schema:
    • Clarified that card_transaction_effective_at must be excluded if the transfer_type is not card
    • Clarified that card_network must be excluded if the transfer_type is not card. Added tabapay as a valid enum
  • Balances File Schema
    • Clarified the data type requirements for interest_rate across deposit and credit products
  • Cards File Schema
    • Clarified that the activated_at datetime must also be before the expiry_date if the expiry_date field is present
  • Non Posted Transactions File Schema
    • Clarified that amount is Currency decimal field
    • Updated the hyperlink for transfer_type
​
05/23/2025
🚀 New

​
Open API Spect Now Available

Lead’s Open API spec is now fully available.
​
05/22/2025
✨ Improvement

​
Improvements to Transactions File Requirements

We’ve clarified in our documentation the requirements for including transfer types (transfer_type) in the Transactions File, specifically:
  • Which transaction types require an associated transfer type to be submitted
  • For transaction types that require a transfer type, which transfer types are valid enums to be submitted
  • For transaction types that do not require a transfer type, which transfer types are valid enums to be optionally submitted
Please refer to the following for more details:
​
04/03/2025
🛠️ Fix

​
Updated Data Schema Examples

In the Lead Data Schemas for Applications and Accounts , the documents property correctly had the description: “An array of JSON hash of customer-facing documents.” However, in the Data Type column, the table included an erroneous outer nested JSON that does not match Lead’s implementation. We’ve updated the examples in both data schemas to correctly reflect the expected object structure.Expected [<object>]Unexpected {"documents":[<object>]}This change was exclusively to the documentation and does not reflect any change in the system behavior.
​
04/01/2025
🚀 New

​
Q2 2025 Product Announcements

​
Summary

We are enhancing the utility of our account_number object to give you greater control over how money moves in and out of your accounts. With this update, you can programmatically set permissions that automatically allow or reject different types of incoming and outgoing transfers. This ensures that only authorized transactions occur, reducing operational risk and providing a more seamless way to manage funds. Whether you want to prevent unauthorized deposits, restrict outgoing payments, or fine-tune which counterparties can interact with your accounts, these new controls put you in charge of your money flows.

​
What’s changing

Note that Lead considers the addition of optional fields to theaccount numberobject a backwards-compatible change.Once released, you will be able to create account_number objects with the following new controls. If these controls are set to false, Lead will automatically return transfers. For outgoing, you will receive a failure response via API.For Incoming and Outgoing ACH:
  • Allow ACH Credits – true/false
  • Allow ACH Debits – true/false
  • Allowed ACH counterparties
Each of these controls will have default values that mirror existing account_number functionality.ACH Defaults:
  • Allow incoming ACH (both credit and debit) – true
  • Allow outgoing ACH (both credit and debit) – false (unless your current program allows this behavior, in which case, we will map the controls to match your existing configuration)
  • Allowed ACH counterparties – permissive of all counterparties

​
Who is impacted

Any partner that is utilizing the Account Number API will have access to this enhanced functionality.

​
When this will be released

Development is currently in progress for these features with a target release of end of Q2 2025. We will provide additional clarity on release date and a finalized account_number object specification and updated documentation at least a month before the release.

​
Summary

To enhance compliance and improve operational efficiency, we are implementing a new requirement for account number activation. Effective July 1, 2025, an active account number must have a properly associated entity object with an account_holder role set.

​
What’s changing

Starting July 1, 2025 (Tuesday), account numbers that do not meet the entity association requirements will be automatically deactivated. This will prevent any payments (ACH, wires, etc.) from being processed for these accounts.Account number objects with a status of:
  • Unassigned will not be impacted.
  • Active and associated entities that meet account_holder role requirements will remain active.
  • Active but do not have associated entities that meet account_holder role requirements will be moved to an inactive status.
  • Inactive will not be impacted.
  • Canceled will not be impacted.

​
Who is impacted

This change affects partners who use account number objects for ACH and wire payments.If you are already using the Entity API to create entities and the Account Number API to associate entities with account numbers, your account numbers are likely already compliant. However, if you are creating entities using file submissions, you will need to verify compliance.To verify compliance, use the Retrieve an Entity by Entity ID or Retrieve an Entity by Client Customer ID endpoints and check the role_details for the account_holder role. If your entity objects do not have the account_holder role enabled, refer to the data requirements for additional data needed. Use the Update an Entity endpoint to resubmit any required data.

​
When this will be released

  • Monitoring: Throughout June, we will monitor account number compliance and reach out to partners with a significant number of non-compliant accounts. Early verification and remediation are strongly encouraged to avoid disruptions.
  • Production: Account number deactivation will begin on July 1, 2025 (Tuesday).

​
Learn more

​
Summary

In order to ensure compliance with FinCrimes and risk requirements, the beneficiary name stated on an incoming wire transfer (i.e., the individual or business that the wire sender says the funds are intended for) must match Lead’s records of the entity or customer associated with the account number to which the wire is sent. This is to ensure that inbound wires are only posted to the account of an intended recipient, and flagged for review in cases where the intended recipient differs from the account number’s associated entity. Typically, wire transfers with a name mismatch will be returned.

​
What’s changing

On July 1, 2025 (Tuesday), Lead will begin enforcement of beneficiary names matching with the name of the individual or business associated with the account number.As an example, let’s say a counterparty financial institution sends an incoming wire to Lead account number 123412341234 and the beneficiary name on the wire is Jane Smith. Lead will do a lookup of the entity_id or client_customer_id associated with that account number.
  • If the entity type is an individual, we will look for approximate matches to the first name and last name on file.
  • If the entity type is a business or sole proprietorship, we will look for approximate matches to the business name, the “doing business as” name of the entity, beneficial owner(s) name, and/or the sole proprietor’s name
If the names are mismatched, Lead will return the wire with a rejection.reason of beneficiary_name_mismatch, and you will receive a webhook notifying you of the wire.rejected event. In certain cases where the names are close, the Lead team may reach out to you for more information.

​
Who is impacted

All partners using account number objects to receive wires will be impacted by this change, and should ensure that customer data (specifically names) are fully up to date and complete. We strongly recommend the use of the Entity API for this purpose.

​
When this will be released

  • Monitoring: We will begin monitoring the impact of this enforcement in shadow mode in June to evaluate impact to rejection rates. We will reach out to individual partners with high match failures to partner on how to improve on match rates.
  • Production: We will begin enforcing this validation on July 1, 2025 (Tuesday).

​
Learn more

  • To learn more about which entity_id or client_customer_id is associated with an account number (and therefore which name we will check against), use the Retrieve an Account Number endpoint.
  • If you are an Entity API user: To learn more about the name-related data associated with an entity_id, use the Retrieve an Entity by Entity ID endpoint.
  • If you are a partner uploading Customer Files: To learn more about the name-related data associated with a client_customer_id, use the Retrieve an Entity by Client Customer ID endpoint.

​
Summary

On the July 14, 2025 (Monday) business day, Fedwire is planning on executing a one-time migration in message formats. Its current Fedwire Application Interface Manual (FAIM) spec will be deprecated in favor of the ISO 20022 spec (more information on its website here). This migration date was previously slated for March 10, 2025, but was pushed back to allow Fedwire participants more time to prepare. There is work required for both Lead and our partners to be prepared for this change.We recognize that this will require considerable bandwidth from your teams between early June and mid-July, and appreciate your understanding as we work together to navigate this one-time transition. In addition to the below, we will follow up with additional details closer to date.

​
What’s changing

In preparation for this message format migration, we are planning to up-version the Wire API from v0 to v1. The core workflows for the wire product are not changing (i.e., retrieve, create, update, return, and cancel operations will remain the same), but we will be up-versioning the wire object to enable a seamless transition. Existing wire objects will continue to be available via the v1 API endpoints (retrieve, return, and cancel), and we will publish clear documentation to support you in mapping any data fields where changes have been made.

​
Who is impacted

All live partners currently sending or receiving wires in production, and currently implementing partners that plan to use Lead to send or receive wires.

​
When this will be released

  • Early June: Lead will release v1 endpoints in Sandbox, allowing you to simulate wire workflows end-to-end utilizing the new v1 wire object
  • By June 27, 2025 (Friday): Fedwire will make a go or no-go decision on whether the ISO 20022 migration will proceed on July 14
    • If it is a “no-go” decision: Lead will continue to use the v0 wire object in production until further notice. We may decide to release v1 on an opt-in basis depending on when Fedwire’s plans to execute on the migration.
    • If it is a “go” decision, by June 30, 2025 (Monday): Lead will release v1 endpoints in Production, allowing you to start working with the v1 wire object in production on an opt-in basis. We will begin sending v1 webhooks after the first time you call a v1 endpoint. The v0 API endpoints will no longer be available after the July 14 Fedwire migration.

​
Learn more

We are working on a specific guide to support our partners’ migration efforts – what you need to know about ISO, key dates, and v1 wire object documentation. These will be shared by early June.

​
Summary

We have received feedback from Lead Partners that the current behavior of the internal_transfer functionality is confusing. Transfers can be processed synchronously or asynchronously depending on different factors that are not easily predictable.To address this, we have released a new v1 version of our Internal Transfers API to ensure that the behavior is fully asynchronous and predictable. We are requesting that all partners using the Internal Transfers API migrate to v1 before July 1, 2025 (Tuesday).

​
What’s changing

The new v1 version introduces two key enhancements over the existing functionality:
  • Fully Asynchronous Processing
    • In v1, all internal transfer requests will be processed asynchronously, ensuring a consistent and predictable response pattern for our Partners.
  • Detailed Rejection Information
    • If a transfer is rejected, the response will include a rejection hash with details on the reason for rejection, allowing for easier troubleshooting and resubmission.
    • For example, if an internal_transfer is attempted with an amount greater than the available balance, the rejection response will indicate non_sufficient_funds and provide the available balance at the time of the request.
When you submit a request to create an Internal Transfer, you will receive a 200 response and the status of the transfer will be set to processing. As we process the transfer, we will update you on the status change events via webhooks.Note that events and webhooks are changing between v0 (processing, succeeded, and failed) and /v1 (processing, posted, and rejected).Please see below to view the different webhooks you should expect between v0 and v1:
VersionEventDescriptionWebhook
v0internal_transfer.processingThe Internal Transfer is being executed.N
v0internal_transfer.succeededThe Internal Transfer has succeeded.Y
v0internal_transfer.failedThe Internal Transfer has failed.Y
v1internal_transfer.processingThe Internal Transfer is being executed.N
v1internal_transfer.postedThe Internal Transfer was completed and money has successfully moved from the sender_account_number_id to the receiver_account_number_id.Y
v1internal_transfer.rejectedThe Internal Transfer was not completed and will not be retried. Please see rejection.reason and rejection.details for more information.Y
Most of the time, these requests are completed successfully within seconds, but there are some instances where additional processing is required. If an issue is encountered in processing the request, Lead will continue to retry until we inform you of a terminal status (posted or rejected).

​
Who is impacted

This change impacts all partners using the Internal Transfers API. If you are currently using v0, you will need to migrate to v1 before the deprecation deadline and will begin receiving webhooks for v1 once you call the endpoints.

​
When this will be released

Beginning July 1, 2025 (Tuesday), calls to the v0 Internal Transfers API endpoints will be rejected.The v1 Internal Transfers API is now available for adoption. You can review the v1 Internal Transfer API endpoints below:
​
02/24/2025
✨ Improvement

​
Updates to File Schemas

Lead released a **Draft Data Schema ** on February 9, 2025. This Data Schema is now Stable. The Changelog below reflects all changes made between the Draft publication and the current Stable Data Schema.
  • Applications
    • removal of available_credit_limit
    • removal of interest_rate and over_draft_limit
  • Accounts
    • removal of status_updated_at
    • removal of interest_rate and over_draft_limit
    • removal of is_exception_approval and exception_reason
    • change scra_ended_at validation to be optional and may not be present if is_scra is false
    • change decision_reason to status_reason
    • change client_application_id to application_id
    • change user_closed to entity_closed under status_reason
    • addition of paid_off, charged_off and canceled under status_reason
    • update of account_holder min size of 1
    • enhanced validation where authorized users files are required if authorized_user is greater than max size 10
    • enhanced validation where available_credit = credit_limit - sum of balances
  • Cards
    • update to expiry_date format to YYYY-MM-DD from datetime
    • update to entity_id accepting either client_customer_id or entity_id
    • change client_account_id to account_id
    • change client_customer_id to entity_id
    • enhanced validation where activated_at must be prior to expires_at
    • removal of updated_at
  • Authorized Users
    • update to entity_id accepting either client_customer_id or entity_id
    • change client_customer_id to entity_id
  • Collaterals
    • change client_account_id to account_id
    • change client_application_id to application_id
    • change client_balance_id to balance_id
  • Balances
    • removal of status_updated_at
    • removal of is_revolving
    • removal of non_finance_charge_amount
    • removal of is_autopay
    • addition of paid_off, charged_off and canceled under status_reason
    • addition of dispute_balance and charge_off_balance as required fields for deposit balance.
    • change client_settlement_bank_id to client_settlement_bank_account_id
    • change client_account_id to account_id
    • change user_closed to entity_closed under status_reason
    • enhancement of required validations (e.g. expected_finance_charge_amount and repayment_details are required if expected_maturity_date is present)
    • enhancement of examples on Balance Reconciliation and Examples
      • amount will affect all of balance, interest_accrued_amount,dispute_balance,charge_off_balance
      • rewards_amount will affect rewards_balance
      • past_due_balance does not reconcile against amount but just tracking credit balance that are past due
  • Transactions
    • removal of client_funding_ids
    • addition of interest_amount for deposit programs.
    • updated typeacross type, fee_type, action, tranfer_type.
    • updated rewards_amount and rewards_unit to be applicable to non-card programs
    • change client_settlement_bank_id to client_settlement_bank_account_id
    • change client_balance_id to balance_id
    • change client_card_id to card_id
    • enhancement of required validations (e.g. (i) for card transactions related fields, required if card_id is provided, (ii) for credit balances, required if balance_id type = credit)
  • Sales Request
    • change client_balance_id to balance_id
​
10/29/2024
✨ Improvement

​
Upcoming API Enhancements

  1. ACH - we are enhancing how we communicate details about rejected ACHs. Beginning on 11/12/2024, Lead will include a new object named rejection in our ACH object. This field will contain a reason and corresponding details. This will allow clients to understand why an ACH was rejected without having to contact Lead. More details are below.
  2. Internal Transfers - we are developing a new version of our Internal Transfers API to make the behavior asynchronous. You will no longer have to manage retries on your own system, and we will also provide additional details about rejections should they happen. We will send an additional communication once we are closer to a release date.

​
ACH Rejections

rejection object
Field NameTypeDescription
reasonenumProvides the reason code if this ACH is in rejected status.
detailsstringA short, human-readable string with more details about why the ACH was rejected.

​
Mapping

account_number_not_activeAccount number [ACCOUNTNUMBER] has non-active status: [STATUS].
aggregate_limit_exceededEntry would exceed the aggregate limit. Current limit value [LIMITVALUE].
beneficiary_account_number_unrecognizedAccount number [ACCOUNTNUMBER] not recognized.
client_customer_not_presentAccount number [ACCOUNTNUMBER] does not have a client customer ID or entity ID.
client_requestPlease contact Lead for further details.
disallowed_counterpartyCounterparty is not allowed.
disallowed_sec_codeSEC code [SECCODE] is not permitted.
duplicate_entryA duplicate entry was found [ACHID].
entry_link_failedEntry is a return or correction, but the associated parent entry could not be found.
invalid_formatInvalid format. Please contact Lead for details.
non_sufficient_fundsInsufficient funds. Balance result: [BALANCERESULT].
ofac_rejectionPlease contact Lead for further details.
per_transaction_limit_exceededEntry would exceed per transaction limit. Current limit value [LIMITVALUE].
previously_correctedA previous ACH to the same counterparty was corrected (correction id = [ACHID]).
processor_discretionary_decisionPlease contact Lead for further details.
related_prenote_exceptionACH entry cannot be created within 3 banking days of a prenote’s settlement date. (prenote id = [ACHID]).
related_prenote_exceptionPrevious prenote to this counterparty (id = [ACHID]) was not accepted.
return_untimelyReturn is not within the proper return timeframe.
reversal_rejectionReversal rejected upon review.
unexpected_change_codeUnexpected change code: [CHANGECODE].
unexpected_return_codeUnexpected return code: [RETURNCODE].
unexpected_routing_numberInvalid routing number provided.
​
12/16/2023
✨ Improvement

​
API Changes

  • We now enforce the NACHA same-day limit of $1,000,000 USD. For transactions above $1,000,000 USD you will need to set the delivery_type to next_business_day.
  • We have removed the account{} hash from the ACH object. It’s been replaced by two new fields, account_id, and account_number_id.
  • The maximum length of the idempotency-key header across the API has been set at 255 characters.
  • We have renamed individual_identification on the ACH object to individual_id. This field is optional and, if set, contains any relevant ID number to allow the ACH counterparty to verify the sender.
  • We have renamed related_information to additional_information. This field is optional and, if set, will contain any additional information provided by the counterparty. Note: For outgoing ACHes, the counterparties bank is not required to share this information with the ACH recipient.