Skip to main content
FedACH is the Federal Reserve’s electronic payment network for ACH transactions in the United States. It clears and settles payments through multiple processing windows each business day. Lead has a direct connection to the FedACH network. Lead creates an ACH object for every entry your program sends and every entry it receives. The object tells you which account number the entry is on, which core balance it posted to, and which core transaction each posting created. ACH is the only Lead rail on which a posted payment can later be returned. Each return, dishonored return, and contested return is recorded on the same object with its own core transaction. Use ACH for recurring payments, payroll, loan disbursements, and consumer-initiated transfers when same-day or next-day settlement is acceptable. Plan for returns as part of your integration.

​
How ACH relates to the rest of the model

An ACH entry connects to these objects:
  • Account number. Every entry is on one account number, named by account_number_id. For outgoing entries you choose it. For incoming entries Lead matches it from the entry’s account number. See Account Numbers.
  • Core balance. Lead resolves the balance behind the account number and posts the entry there. The ACH object returns it as core_balance_id. An account number on a user deposit balance settles to the FBO core balance behind it, and that is the balance returned.
  • Core transaction. Each posting creates one core transaction. The original posting is core_transaction_id on the ACH object. Each return, dishonored return, or contested return that posts carries its own core_transaction_id inside returns[]. Read them with the Core Transactions API, and look an entry up by core transaction with the core_transaction_id list filter.
  • Originator. Outgoing entries include the company name and company ID of the originator the account number sends under. Lead sets up one originator for your program at onboarding. See Originators.
  • User deposit balance. ACH on an account number attached to a user deposit balance is allowed in both directions. Lead records the movement on the user deposit balance for you.

​
What you can do

You can use these endpoints:
  • POST /v2/ach: Create an outgoing credit or debit. Requires an Idempotency-Key header.
  • GET /v2/ach/{ach_id}: Retrieve an entry.
  • GET /v2/ach: List entries. Filter by account_number_id, account_number, counterparty_account_number, core_transaction_id, direction, status, transaction_type, or created_at.
  • PATCH /v2/ach/{ach_id}: Update metadata.
  • POST /v2/ach/{ach_id}/cancel: Cancel an outgoing entry that is still cancellable.
  • POST /v2/ach/{ach_id}/return: Return an incoming entry, dishonor a return, or contest a dishonored return, by return code.
  • POST /v2/ach/{ach_id}/reverse: Reverse an erroneous entry you originated, within five business days (weekdays that aren’t Federal Reserve holidays) of settlement.
The cancel, return, and reverse endpoints require an Idempotency-Key. See Idempotency. Outgoing entries support a delivery_type of same_business_day or next_business_day and the CCD, PPD, TEL, WEB, and CIE SEC codes. Incoming entries can also use IAT. See Sending ACH, Receiving ACH, ACH timing and availability, and Validations and how to avoid them.

​
Authentication

The endpoints use these scopes:
  • ach/read_write for create, cancel, return, reverse, and update. Also grants read access.
  • ach/read for the GET endpoints only.

​
What you can’t do

These actions aren’t available:
  • Originate IAT. Lead receives IAT entries but doesn’t send them.
  • Originate from an account number Lead holds. The request returns an error.
  • Reference an account_id. It isn’t accepted on requests, returned on responses, or available as a filter. Filter by account_number_id instead.
  • Read core_transaction_id before the entry posts. It is null until the core ledger entry exists, and null on entries whose posting predates core transaction capture.

​
In this section

These are the pages in this section: