FedNow Healthcare Payments: What Your Bank Has to Support Before Any of It Works

Most FedNow explainers written for physicians stop at "payments settle in seconds." That sentence is true and nearly useless, because it describes the network and not your practice. FedNow is plumbing. Whether water comes out of your tap depends on four separate things your bank, your patient's bank, and your treasury software each have to support — and on a remittance question that real-time settlement makes harder, not easier.

This article covers what the FedNow Service actually is, the enrollment chain that determines whether you can use it, one synthetic patient balance traced from an 835 service line through a request-for-payment message to final funds, and the specific questions to put to your bank before you plan around any of it.

What FedNow is, precisely

The FedNow Service is an instant payment rail operated by the Federal Reserve Banks, live since July 2023. Four properties define it, and all four matter operationally:

Credit push only. Money moves because the payer's bank originates it. Nobody pulls from an account. There is no stored credential, no card on file, no debit authorization sitting in your system waiting to be misused.

Irrevocable on acceptance. Once settled, the transfer is final. There is no return window, no NSF reversal three days later, no chargeback. This is the single biggest operational difference from every other way you collect today.

24/7/365. Settlement does not observe a banking calendar. A payment initiated at 9pm on a Saturday of a holiday weekend settles at 9pm on that Saturday.

ISO 20022 messaging. Structured messages, not fixed-width batch files — which is what makes a request for payment expressible as a first-class message rather than an invoice you email and hope about.

Compare that to what legacy rails are structurally. ACH is a batch, store-and-forward, reversible system. Reversibility is not a bug; it's the design. But reversibility is exactly why ACH settles on a banking calendar and why funds that appear in your balance can be pulled back after you've posted them. You cannot have same-second finality and a multi-day return window in the same system.

The other instant rail is RTP, operated by The Clearing House and live since 2017. Practices frequently assume these are one thing. They are two networks with separate participants, separate reach, and separate rulebooks.

Read the last row before the finality row. Universal reach is the thing ACH has that neither instant rail does yet.

The enrollment chain: four links, any one of which breaks it

"Our bank is on FedNow" is not an answer. It's the first of four conditions.

1. Your FI is a participant — and is send-enabled, not receive-only. Institutions can join to receive without enabling send. Receiving is what you need for inbound patient balances, so receive-only is often sufficient for collections; sending matters for refunds and payouts. Ask which you have.

2. Your FI supports Request for Payment as a distinct service election. Participation in the network does not imply RfP. This is the link that most often breaks. Without RfP you can receive an instant payment, but you have no supported way to ask for one — you're back to a statement with your account details on it.

3. Your patient's FI is reachable and accepts RfP. An RfP only lands in a banking app if the debtor's institution participates and supports RfP receipt. Reach is growing but is not universal on either instant network [verify current participant coverage]. Plan for a fallback path per patient, not a single rail.

4. Your treasury platform or bank portal exposes the messages to you. The value of ISO 20022 is that the status report (pacs.002) and the RfP response (pain.014) are machine-readable events you can post against. If your bank surfaces them only as a line on a statement the next morning, you have instant settlement with next-day information, which reconciles no better than ACH.

Worked example: $62.00 from 835 line to final funds

Established patient, three lines, commercial payer, 20% coinsurance after deductible. All values below are synthetic and contain no patient data.

The relevant fragment of the 835:

CLP*PCN-90312*1*310.00*196.00*62.00*12*ICN-2026-0803-1147*11~
SVC*HC:99213*175.00*108.00**1~
CAS*CO*45*32.00~
CAS*PR*2*35.00~
SVC*HC:81002*45.00*28.00**1~
CAS*CO*45*10.00~
CAS*PR*2*7.00~
SVC*HC:93000*90.00*60.00**1~
CAS*CO*45*10.00~
CAS*PR*2*20.00~

Every service line balances — SVC02 = SVC03 + the sum of that line's CAS amounts:

• 99213 — 175.00 = 108.00 + 32.00 (CO-45) + 35.00 (PR-2) ✓
• 81002 — 45.00 = 28.00 + 10.00 (CO-45) + 7.00 (PR-2) ✓
• 93000 — 90.00 = 60.00 + 10.00 (CO-45) + 20.00 (PR-2) ✓

Claim level ties out the same way: CLP03 − CLP04 = 310.00 − 196.00 = 114.00, which equals 52.00 contractual (CO-45) plus 62.00 patient (PR-2). CLP05 = 62.00.

That $62.00 is the entire billable patient amount. The $52.00 in CO-45 is your contractual write-off; putting it on a statement is balance billing under a participating-provider agreement. The request you're about to send must be for 62.00 — derived from the PR group, itemizable line by line, never charges-minus-payments.

Now the RfP over FedNow, with clock times:

[verify current FedNow message set and version with your FI.]

Three things to notice. The money moved on a Saturday night — no window, no cutoff, no Monday. Elapsed settlement time was ~3 seconds, but elapsed collection time was two days, because the binding constraint is the patient opening their banking app, not the rail. And the payment matched an encounter on arrival, because your own reference rode out on the request and came back on the response.

What FedNow does not fix

It does not adjudicate claims faster. Nothing on this page shortens the interval between clean-claim submission and the payer's payment decision. That clock is bounded by payer processing and by regulation, including Medicare's payment floor and state prompt-pay statutes [verify current CMS provisions and your state's statute]. Any vendor implying otherwise is selling something else — usually an advance against an adjudicated receivable, which is a financing product with financing risk. Make them name it.

Your payers probably aren't on it yet. Commercial remittance today still arrives predominantly as ACH CCD+ with the 835 delivered through a separate pipe [verify against your own payer mix]. The payer leg is a payer-by-payer question you should ask directly. The patient leg is available to you unilaterally, which is why it's the practical starting point.

It does not carry your remittance detail. The remittance field on an instant payment is sized for a reference, not for a line-level breakdown [verify current field lengths]. This is the part practices get wrong: they expect the instant rail to replace the 835. It does not. What changes is which reconciliation problem you have. Under EFT/ERA you match a payer-generated trace number in the ACH addenda against TRN02 in a separately delivered 835 — the failure mode the CAQH CORE reassociation rule exists to address [verify current CORE rule version]. Under an RfP you originated, the reference is yours, issued at request time, returned on the response. Matching by construction beats matching by search.

It does not grant you compliance. See the FAQ.

FAQ

My bank says we're "on FedNow." Can I start collecting patient balances this way?

Not from that sentence alone. Ask four questions in order: Are we send-enabled or receive-only? Do we have Request for Payment enabled as a service election, or only credit receipt? What is our reach for RfP to consumer accounts at other institutions [verify current coverage]? And how do we receive the pacs.002 status and pain.014 response — as machine-readable events, or as a line on tomorrow's statement? A "yes" on network participation with a "no" on RfP is common and means you cannot originate a request.

If the payment can't carry line-level remittance, how do I post it correctly?

You post from the 835 and your own AR record; the payment carries a token, not an explanation. The sequencing matters: post the 835 at the service-line level first, derive the PR-group total, then originate the request against that number with your encounter reference attached. The returning payment matches an open balance by construction. Practices that try to run it the other way — payment arrives, then go find what it was for — have rebuilt the EFT/ERA reassociation problem on a faster rail.

How does this stay HIPAA-safe when payment data leaves my system?

Ask for the mechanism, not the assurance — no platform can grant you compliance, and a vendor who answers "we're HIPAA safe" without describing the payload has told you nothing. The mechanism to look for: the payment instruction references an opaque encounter identifier (ENC-7Q4K2 above) rather than carrying clinical content, PHI stays in your system of record, remittance parsing operates on the financial segments of the 835, and the rail sees an amount and a token. Then confirm the compliance layer separately — an executed BAA, a documented payload policy, and your own configuration. All three are required; the mechanism alone isn't sufficient, and neither is the paperwork.

Run it against your own remittance

The shteg.ai sandbox takes a de-identified 835 and returns the arithmetic above on your own data: service-line balancing validated on every SVC (SVC02 = SVC03 + CAS), claim-level tie-out against CLP03 − CLP04, the PR-group total isolated as the billable patient amount, and the request-for-payment payload that would be generated from it — reference-only, with the encounter token in place of anything clinical.

Bring one 835 and your bank's answer to the four enrollment questions. Those two things together tell you whether FedNow is a plan or a slide.

Open the shteg.ai sandbox → [verify link target before publish]

Educational content for physicians, practice administrators, and revenue-cycle staff. Not legal, billing, coding, or compliance advice. All segment values, claim identifiers, encounter tokens, dates, and dollar figures in this article are synthetic illustrations and contain no patient data. X12 835 specifications, CAQH CORE operating rules, Nacha rules, ISO 20022 message versions, and FedNow and RTP network capabilities, limits, reach, and message support change over time — verify current specifications with your clearinghouse and financial institution before making operational decisions. Payment timing obligations, patient billing, and balance-billing restrictions are governed by your payer contracts and by applicable state and federal law; consult counsel for your jurisdiction.

Draft notes: ~1,690 words. H1 + 6 H2s (4 body + FAQ + CTA). Angle divergence from fast-payment-1-msr79be9: that draft decomposes the AR cycle into four clocks and compares rails generically; this one is network-specific — FedNow vs RTP as distinct systems, the four-link enrollment chain, and the remittance-carriage argument (matching by construction vs. EFT/ERA reassociation), which the sibling does not make. Worked example uses a fresh three-line synthetic claim and carries both required forms: SVC02 = SVC03 + CAS on all three lines with claim-level tie-out (CLP03 − CLP04 = 114.00 = 52.00 CO + 62.00 PR; CLP05 = 62.00), plus a timestamped settlement timeline through the ISO 20022 message sequence. Comparison table is four-rail (CCD+ / Same Day ACH / RTP / FedNow) on operator, settlement mechanics, finality, limits, RfP support, remittance carriage, and reach. Eleven [verify] flags: Nacha return windows, Same Day ACH limit, RTP and FedNow limits, FedNow and RTP RfP message sets, remittance field lengths, participant reach (×2), CMS payment floor and state prompt-pay, CORE rule version, payer mix, sandbox link. No statistics asserted — timeline values are one labeled synthetic transaction, not a benchmark. PR-vs-CO balance-billing guardrail stated at the point the request amount is derived. HIPAA FAQ answers with mechanism plus BAA/configuration caveat, not an assurance. Primary-source pointers: X12 835 TR3, CAQH CORE EFT/ERA reassociation rule, Nacha operating rules, FedNow Service operating procedures, RTP operating rules, ISO 20022 message definitions, CMS claims processing. Blocking before publish: §5 requires a named physician or revenue-cycle reviewer — currently unassigned.

Want me to save this to examples/seo-presence/workspace/drafts/fast-payment-2-<id>.md to match the pipeline convention? The existing drafts use a short base-36 timestamp slug (msr79be9) — give me an ID in that format, or say the word and I'll generate one.

<!-- generated_by: claude-draft-1 -->