Skip to content
Why Instant Changes ItWhat ChangedThe Payment Run As DataPublished September 2, 2026

Instant payments now move ten million dollars in seconds, and the payment run is where you build the confidence to send.

The Federal Reserve raised the FedNow limit to ten million dollars, so instant, final settlement now reaches payments that used to wait for a wire cutoff or an ACH cycle. On a rail that never closes and hands the receiver the funds the moment it settles, the checks that mattered the next morning move to the seconds before a send. The teams that verify the beneficiary, screen before the payment leaves, and set their own limits turn that speed into confidence.

Instant, final, and always on is a different job.

Most payment controls were built around a pause. An ACH file sits before it posts, a wire has a cutoff and a business-day rhythm, and a mistake often has a window where someone can catch it. An instant payment removes the pause. FedNow settles in near real time, the network keeps a 24 hour business day every day of the week including weekends and holidays, and the receiver institution makes the funds available immediately after it is notified of settlement. The Federal Reserve raised the per payment limit from one million dollars to ten million dollars, effective November 2025, and named corporate treasury, payroll, vendor payments, and commercial real estate as the high value uses it now supports.

What that combination changes is where a control has to live. A credit push has no reversal the sender controls, so recovering a payment sent to the wrong account depends on the receiver agreeing to return it. The check that used to run on the overnight batch, is this the right account, is this a duplicate, is this name on a screening list, is this within our limits, has to run in the moment before the payment leaves. The speed is the part everyone notices. The finality is the part that matters, and it is finality that moves the work forward in time.

The Federal Reserve has built for this on the institution side. In June 2025 it launched an account activity threshold feature that lets a participating institution set dollar value and transaction velocity thresholds by customer segment, and it raised the default limit from five hundred thousand to one million dollars at the same time. Institutions can still set lower limits based on their own risk parameters. For 2026 the Federal Reserve has a pilot for a network intelligence tool that will let a sending institution pre-check a receiver account before an instant payment goes. The direction is steady: more of the safety is being pushed to the moment of send.

Read as a systems problem, this is an opportunity rather than a burden. The same record that makes an instant send safe, a verified beneficiary, a set of gates that pass together, a limit chosen on purpose, and a settlement notification captured and matched, is the record that makes cash application faster and reconciliation cleaner every day. Build the payment run as a control point once, and a ten million dollar send stops being a leap and becomes a lookup. The rest of this piece walks through what changed, then gets concrete about that record.

What changed, and what it asks of your systems.

The change itself is small to state and large in effect. The table below sets out the control points a high value payment passes on its way to an instant rail, where each one comes from in the Federal Reserve material, what the change asks of the send, and what it should produce in the data a finance team owns.

The control points a high value payment passes before and after an instant send, with the FedNow fact behind each and what each should produce in a finance team's data. Facts are drawn from Federal Reserve Financial Services and Federal Reserve Board material.
Control pointWhere it comes fromWhat the change asksWhat it produces in your data
Choose the rail on purposeLimit now $10M, effective Nov 2025The ceiling on an instant send rose from one million dollars to one order of magnitude higher, so payments that once waited for a wire cutoff or an ACH cycle, a supplier release, a payroll funding, a property closing, can now settle in seconds. The choice of rail is a decision, not a default.The rail held as an attribute of the payment, so instant, final settlement is used where it earns something rather than reached for by habit.
Verify the beneficiary before the sendCredit push, funds available at settlementA FedNow payment pushes a credit and the receiver gets the funds immediately on notification of settlement. Recovering a payment sent to the wrong account depends on the receiver agreeing to return it, so the account has to be right before it goes.The beneficiary routing and account held as verified vendor or customer master data, dated and owned, rather than a number typed onto the payment.
Screen and dedupe in the same moment24x7x365, no overnight batchThe network keeps a 24 hour business day every day of the week, so there is no nightly file to inspect and no morning to catch a mistake. Sanctions screening, a duplicate check, and a name match against the account have to clear before the payment leaves.A joined pre-send gate that must pass as one, so a payment that fails any single check is held rather than sent and chased.
Set sending limits by counterparty and segmentAccount activity thresholds, 24 Jun 2025The Federal Reserve added a feature that lets an institution set dollar value and transaction velocity thresholds by customer segment, and it lets institutions set limits below the network ceiling. Your own policy limits are a separate, deliberate decision.Per payment, per counterparty, and per segment caps held as governed numbers, set below the ten million ceiling where that is right, versioned and owned.
Capture settlement and apply the cashImmediate availability on notificationThe term of service requires the receiver institution to make funds available immediately after it is notified of settlement, and that notification is the cleanest signal the payment landed. It is worth feeding straight into reconciliation.The settlement notification captured and matched to the item it paid, so the proof of the send also closes the cash application it feeds.
Prepare for the receiver pre-checkNetwork intelligence tool pilot, 2026A Federal Reserve pilot is underway for a network intelligence tool that will let a sending institution pre-check a receiver account before an instant payment goes. Clean, structured beneficiary data is what makes that check usable when a bank offers it.Beneficiary records kept structured and current, so a future pre-check reads good data rather than forcing a cleanup at the worst moment.
The control points a high value payment passes before and after an instant send, with the FedNow fact behind each and what each should produce in a finance team's data. Facts are drawn from Federal Reserve Financial Services and Federal Reserve Board material.

The theme worth sitting with runs down the first column: every one of these checks now runs before the payment leaves. On a batch rail a team can inspect the file, hold a suspect item, and release the rest in the morning. On FedNow the money is gone and available to the receiver the moment it settles, so the inspection has to be a gate the payment passes through rather than a report read afterward. That is not a reason to avoid the rail. It is the reason to design the send.

Two of the rows are easy to under-build. The first is limits. The network ceiling is ten million dollars and an institution can set a lower one, but your own per payment and per counterparty caps are a separate decision, and the account activity threshold feature is a signal that segment belongs in the limit. The second is the receive side. FedNow includes an optional request for payment message, and a company that can receive one, match it to an open invoice, and act on it turns an inbound collection into a reconciled credit. Both are part of using the rail well, not extras to add later.

The payment run, read as a governed record.

A worked example makes it concrete. Take a single high value supplier payment set to go on the instant rail. The beneficiary bank account is verified master data with a date and an owner, not a number typed at payment time. The pre-send gates, sanctions, duplicate, name match, approval, and limit, all have to pass together before the payment leaves. The sending limits are set per counterparty and per segment, below the ten million network ceiling. And the settlement notification, when it arrives, is captured and matched to the invoice it paid.

Here is that logic expressed as a record. Each payment carries its rail, its verified beneficiary, the gates it must pass, the limits it is checked against, and the settlement notification that closes it. A blocked list at the end names any payment held for an unverified beneficiary or a breached limit, because those are the two conditions that make an instant send unsafe.

An instant payment control record for a high value send

# Instant payment control record for a single high value send
# Figures and names are placeholders for shape, not real values.

payment:
  reference: "AP-2026-041872"
  rail: fednow                       # fednow | ach | wire | rtp
  amount_usd: 4250000                # within the 10,000,000 network limit
  value_time: "on send, any hour, any day"   # 24x7x365
  reversal: none_sender_controlled   # credit push; recovery needs the receiver to return

beneficiary:
  legal_name: "Kestrel Components LLC"
  routing_number: "****0137"
  account_ref: "****9042"
  account_verified: true             # verified before the send, not after
  verified_on: 2026-08-31
  source_of_record: vendor_master    # owned, not keyed onto the payment

pre_send_gates:                      # all must pass in the same moment
  sanctions_screen: clear
  duplicate_check: clear             # no matching amount and beneficiary in window
  name_match: clear                  # payee name matches the account
  approver: "controller@entity"
  within_limits: true

sending_limits:                      # set on purpose, mirrored from the bank policy
  per_payment_usd: 5000000           # company policy, below the 10,000,000 ceiling
  per_counterparty_daily_usd: 8000000
  segment: strategic_supplier        # account activity threshold by segment
  velocity_cap_per_hour: 3

settlement:
  notification: settlement_confirmed # the bank confirms settlement
  funds_available_to_receiver: immediate
  captured_for_cash_application: true
  matched_to: "AP-2026-041872"       # closes the item it paid

blocked:
  - reference: "AP-2026-041919"
    reason: beneficiary_not_verified # account never checked against the source
    status: held                     # will not send until verified
  - reference: "TR-2026-000204"
    reason: exceeds_segment_limit    # over the per-counterparty daily cap
    status: held                     # will not send until reviewed

The blocked list is what keeps it honest. Holding the beneficiary as verified master data means the send reads a checked record rather than trusting a number keyed in the moment. Making the gates pass together is what turns a pile of separate checks into one control on a rail with no second chance. Setting the limits on purpose keeps a strategic supplier and a brand new payee from sharing a ceiling. And capturing the settlement notification is the difference between a rail that complicates reconciliation and one that closes it. None of this is elaborate. It is ordinary payment discipline pointed at a rail that does not wait.

How a high value payment reaches the FedNow instant rail through a set of pre-send gates, and how the settlement notification closes the cash applicationA flow that starts from a high value payment request. Before the payment leaves it passes one joined gate made of a verified beneficiary account held in master data, a sanctions screen, a duplicate check, a name match against the account, an approval, and a limit check set per counterparty and per segment. If every check passes, the payment goes on the instant rail, which settles in near real time, runs every day of the year, makes the funds available to the receiver immediately on notification of settlement, and offers no reversal the sender controls. The settlement notification is then captured and matched to the item the payment paid, closing the cash application. If any check fails, the payment is held rather than sent, because a completed instant payment cannot be recalled by the sender. A guard beneath states that the sending limits are set below the ten million dollar network ceiling, and that a completeness query lists any payment set to go with an unverified beneficiary or over a limit.THE PAYMENT RUN AS A CONTROL POINTPAYMENT REQUESTA high value send,up to $10,000,000Rail chosen on purpose:instant, final, always onPRE-SEND GATE, PASSES AS ONEVerified beneficiary in master dataSanctions screenDuplicate checkName match against the accountApprovalLimit, per counterparty and segmentAny single failure holds the paymentALL PASSINSTANT RAILSettles in near real time,every day of the yearFunds available at onceNo sender-controlled reversalSETTLEMENT NOTIFICATIONCaptured and matched tothe item it paidCloses the cash applicationANY FAILUREHELD, DOES NOT SENDUnverified beneficiary, or over acounterparty or segment limitFixed before it can goTHE GUARDSending limits are set below the $10,000,000 network ceiling, per counterparty and per segment, as numbers you own.Completeness is one query: every payment set to go instant with an unverified beneficiary or over a limit is on the list.Run it before the rail is relied on, not after a payment that cannot be recalled.
A high value payment passes one joined pre-send gate, a verified beneficiary, sanctions and duplicate checks, a name match, an approval, and a limit set per counterparty and per segment, before it reaches the instant rail. The rail settles in near real time every day of the year and makes funds available immediately, with no reversal the sender controls, so any failed check holds the payment rather than sending it. The settlement notification is captured and matched to the item it paid, closing the cash application.

An implementation checklist.

  1. 1.Decide which payments belong on the instant rail. Not every payment needs to settle in seconds. Pick the ones where immediate, final value earns something real: a supplier release that unblocks a shipment, a payroll funding, a real estate closing. Record the rail as an attribute of the payment, so the choice is deliberate and repeatable rather than a default nobody set.
  2. 2.Verify the beneficiary bank account before the payment leaves, not after. A FedNow credit is a push, and recovering one sent to the wrong account depends on the receiver agreeing to return it. Hold the beneficiary routing and account as owned vendor or customer master data, verified and dated, so every send draws on a checked record rather than a number typed onto the payment.
  3. 3.Make sanctions, duplicate, and name-match screening one gate the payment passes through. With no overnight batch behind it, an instant payment has to clear its checks before it goes, not the next morning. Join the pre-send gates so they pass together, and hold the payment if any single one fails, because on this rail a report read afterward is a report read too late.
  4. 4.Set your own sending limits, per counterparty and per segment. The account activity threshold feature lets an institution set dollar value and velocity thresholds by segment, and institutions can sit below the network ceiling. Mirror that in your policy so a strategic supplier and a payee added this morning do not share one limit, and so a company cap sits below ten million dollars where that is right for you.
  5. 5.Capture the settlement notification and let it close the cash. The receiver gets the funds immediately on notification of settlement, and that same notification is the cleanest proof the payment landed. Feed it straight into cash application and reconciliation, so the record that proves the send also closes the item it paid.
  6. 6.Prepare for the 2026 pre-check on receiver accounts. The Federal Reserve has a pilot for a network intelligence tool that will let a sending institution pre-check a receiver account before an instant payment. Keep your beneficiary data clean and structured now, so you can use that check when your bank offers it rather than scrambling to fix records later.
  7. 7.Run one completeness query before you rely on the rail. Any high value payment set to go instant with an unverified beneficiary, or above a counterparty or segment limit, is a gap. While that list has entries, the rail is not yet safe to lean on for those payments, and it is far better found in a query than in a payment that settled in seconds and will not come back.

Failure modes, framed so you can avoid them.

  • Treating an instant payment like an ACH file with a faster clock. ACH gives a return window and a batch a team can inspect before it posts. FedNow settles in near real time and hands the receiver the funds the moment it is notified of settlement, so a control that assumed an overnight look is not a control on this rail.
  • Typing the beneficiary bank details onto the payment. A routing and account number keyed by hand at payment time is the classic way money reaches the wrong account. On a rail with no sender-controlled reversal, the verified beneficiary record has to live in master data and be checked before the send, not entered in the moment.
  • Leaving one sending limit for every payee. A single ceiling treats a decade-long supplier and a payee added this morning the same way. The account activity threshold feature exists because segment matters, and a flat limit either blocks good payments or waves through the ones that deserved a second look.
  • Running the sanctions or duplicate screen after the batch. On an instant rail there is no batch. A screen that fires on a nightly job runs after the money is gone, so the screen has to be a gate the payment passes through, not a job that reports on what already left.
  • Assuming the bank limit is your limit. The network ceiling is ten million dollars and an institution can set a lower one, but your own per payment and per counterparty caps are a separate decision. A company that never sets its own limits has handed a control to a default it did not choose.
  • Losing the settlement notification instead of applying it. The notification that a payment settled is both the proof it happened and the trigger to close the item it paid. A process that files it away rather than feeding cash application throws away the cleanest reconciliation signal the rail hands you.
  • Building only to send, and forgetting request for payment. FedNow includes an optional request for payment message, and a company that can receive one, match it to an open invoice, and act on it turns an inbound collection into a reconciled credit. Ignoring it leaves the receive side to the same manual matching instant rails were meant to remove.
  • Discovering a stale beneficiary record at send time. A vendor that changed banks a year ago and was never updated surfaces as a failed or misdirected instant payment. Keeping bank records current and verified as a standing task is what turns the send into a lookup against clean data rather than a gamble on an old number.

What this asks of the data model.

  • The rail is an attribute of the payment, chosen on purpose. Whether a payment goes instant, by ACH, or by wire is a decision worth recording, so the fast, final rail is used where its finality earns something and not by accident.
  • The beneficiary bank account is verified master data, not a payment-time entry. The routing and account belong to the vendor or customer record, verified and dated, so every send draws on a checked source rather than a number retyped each time a payment goes out.
  • The pre-send gates are a set that passes together. Sanctions, duplicate, name match, approval, and limit are one gate on an instant rail, because there is no later batch to catch a miss, and holding them as a joined check is what makes a held payment visible before it leaves.
  • Sending limits are governed numbers, per counterparty and per segment. The network ceiling and the institution limit are inputs, while your own per payment, per counterparty, and per segment caps are decisions you own and version, set below the ten million ceiling where that is right for the payee.
  • The settlement notification is a first-class record, not a receipt to file. It proves the payment settled and it closes the item the payment paid, so capturing it and matching it is what lets the instant rail clean up reconciliation rather than complicate it.
  • Immediacy is a property to design around, not a surprise. Funds reach the receiver immediately on notification of settlement and the network runs every day of the year, so cutoffs, approvals, and screens have to work at any hour rather than only inside a business-day window.
  • Request for payment is a receive-side data object worth owning. An inbound request for payment, matched to an open invoice, turns a collection into a reconciled credit, and treating it as data rather than a message is what makes cash application on the receive side clean.
  • Completeness reduces to one query. Any high value payment set to go instant with an unverified beneficiary, or above a counterparty or segment limit, is the exception list, and it can run before the rail is relied on rather than surfacing in a payment that will not come back.

The evidence to keep.

  • The register of which payment types use the instant rail and why, so a reader can see the fast, final rail was chosen where its finality earns something rather than applied across the board.
  • The verified beneficiary records behind instant payments, showing the routing and account, the verification and its date, and the owner, so each send rests on checked master data rather than a keyed number.
  • The pre-send gate log for high value instant payments, showing the sanctions, duplicate, name match, approval, and limit checks that passed together before the payment left.
  • The sending limit policy, showing the per payment, per counterparty, and per segment caps and how they sit against the network and institution limits, with who set them and when.
  • The settlement notifications captured for instant sends, matched to the items they paid, evidencing that the proof of settlement also closed the cash application it fed.
  • The held payment report, listing any instant payment stopped for an unverified beneficiary or a breached limit, so the exceptions were caught before send rather than after the money moved.
  • The request for payment handling record on the receive side, showing inbound requests matched to open invoices, evidencing that the receive side was built rather than left to manual matching.
  • The completeness exception report before the rail is relied on, ideally empty, listing any high value instant payment with an unverified beneficiary or over a limit, so the two conditions were checked in advance.

Questions worth asking in your own review.

  • For each high value payment we send, is the rail a recorded, deliberate choice rather than a default nobody set?
  • Is the beneficiary bank account verified in master data and dated before the payment leaves, or keyed onto the payment at send time?
  • Do our sanctions, duplicate, and name-match screens run as a gate the payment must pass, or as a report we read after a batch that no longer exists?
  • Have we set our own per payment, per counterparty, and per segment sending limits, below the ten million network ceiling where that is right for us?
  • When a payment settles, do we capture the notification and use it to close the item it paid, or file it as a receipt and reconcile the hard way later?
  • Do our approvals, screens, and cutoffs work at any hour and any day, given the rail keeps a business day every day of the week?
  • Can we receive and act on a request for payment, matching it to an open invoice, so the receive side is as clean as the send side?
  • Could we produce, today, a list of every high value instant payment set to go with an unverified beneficiary or over a limit?

What this adds up to.

The FedNow increase is a straightforward, welcome change. A ten million dollar ceiling opens instant settlement to payments that used to wait for a wire cutoff or an ACH cycle: a supplier release, a payroll funding, a property closing. The rail is fast, it is open every day of the year, and the funds reach the receiver the moment the payment settles. For a treasury team that already runs clean payments, most of the work is deciding where that speed and finality are worth it.

The build that makes it safe is small and pays off beyond this one rail. Choose the rail on purpose. Verify the beneficiary in master data before the send. Make the pre-send screens one gate the payment has to pass. Set your own limits per counterparty and per segment. Capture the settlement notification and let it close the cash. Do that and a ten million dollar instant payment is a lookup against clean data, and the same data makes every other payment cleaner too.

If there is one place to start, run the completeness query against your own payments before you lean on the rail: any high value payment set to go instant with an unverified beneficiary, or above a counterparty or segment limit. For a small accounts payable function that list is short and the work is a morning. For a group paying many suppliers across many banks, it is the work, and it is far better found now, while there is time to verify an account and set a limit, than discovered in a payment that settled in seconds and will not come back.

Sources.

The limit increase to ten million dollars, its November 2025 effective date, the four named use cases, the account activity threshold feature and the earlier rise to one million dollars, the 2026 network intelligence pre-check pilot, and the participant figures come from Federal Reserve Financial Services releases and Fed360. The design of the service as a 24x7x365 instant payments infrastructure, the immediate availability of funds on notification of settlement, settlement through master account entries at the Reserve Banks, the optional request for payment feature, and the 20 July 2023 go live come from the Federal Reserve Board pages. Sources differ on the exact announcement day, the release is filed under a 5 September slug while trade press dates it to 9 September 2025, so this article cites the month. No embedded posts from X appear here, because no public post on this change could be verified as current, relevant, and authentic at the time of writing, and an unverified embed is worse than none. Nothing here is payments, treasury, or legal advice for a specific company. The figures and names in the worked example and the record are placeholders for shape rather than real values, and how a given company uses FedNow depends on its own facts, its bank, and its risk appetite.