Implementing FedNow and RTP for Instant Payer Settlement in Physician Practices

A practice manager looking at 38 days in A/R usually assumes the money is stuck somewhere in the banking system. It is almost never stuck there. Under standard ACH, the payer's credit clears in one banking day; the other 37 days are adjudication, posting lag, and statement cycles.

That matters because it tells you exactly what instant payment rails can and cannot fix. FedNow and RTP compress one specific interval to seconds. If that interval is not where your cash is sitting, adopting them changes nothing you can see on a dashboard. This article separates the intervals, works one encounter through both timelines with real clock times, and lists what has to be true in your practice before the rail is worth the integration.

The three clocks between the visit and the deposit

Every dollar a practice collects passes through three independent clocks:

Clock 1 — adjudication. Claim submission to payer decision. Driven by clean-claim rate, payer processing time, and rework loops. Typically the longest interval, and no payment rail touches it.

Clock 2 — settlement. Payer decision to funds available in your operating account. This is the rail. Standard ACH: one to two banking days, banking days only. RTP or FedNow: seconds, any hour, any day.

Clock 3 — reconciliation. Funds available to known, posted, and reconciled. Driven entirely by how you handle the 835. A practice that batch-posts remittances twice a week has a Clock 3 measured in days, on money already sitting in the bank.

Instant rails move Clock 2 only. If you have $180,000 in A/R and $2,000 of it is in ACH transit on any given day, moving to an instant rail frees $2,000 of timing — a rounding error. The rails become material in two places: patient balances, where Clock 2 today is a paper statement cycle measured in weeks, and the final hop between a payments platform and your bank account.

One clarification worth making early, because vendors blur it: the HIPAA-mandated healthcare EFT standard for payer-to-provider claim payments is the ACH CCD+ entry carrying the 835 TRN reassociation trace in its addenda record. Payers are not going to start sending you FedNow credits for adjudicated claims next quarter. Plan around ACH on the payer leg and instant rails on the patient and settlement legs.

What the instant rails actually change

Both networks are credit-push only. There is no debit pull, so there is no NSF return and no chargeback. The payer of funds authorizes and the money leaves; you cannot originate a pull against a patient's account the way a card or an ACH debit does.

Both are final and irrevocable on acceptance. An erroneous $2,400 refund sent over RTP is gone. Your recourse is a request-for-return message (camt.056 in ISO 20022 terms) that the receiving institution and its customer may simply decline. Practices that currently fix mistakes by reversing an ACH within the return window lose that safety net entirely — refund controls have to move before the send, into approval workflow.

Both are ISO 20022 native, which matters more than it sounds. The credit transfer (pacs.008) carries a structured end-to-end identifier and a remittance field, and the acknowledgment (pacs.002) returns an accept/reject status in seconds. You get a machine-readable confirmation tied to your own reference — the raw material for automated reconciliation. Both networks also support a request-for-payment message (pain.013, answered by pain.014), which is the plumbing under a patient payment request delivered into a banking app.

And both run 24/7/365. That is an operational change, not just a marketing line. Cash arrives on Saturdays, on Christmas, and at 11:40 PM. A bank reconciliation process that runs on banking days will drift.

The two rows that decide most implementations are reachability and finality. Reachability means you always need an ACH fallback path — an instant-only patient payment flow will fail for some patients. Finality means your refund process needs a maker-checker step it probably does not have today.

Worked example: one $560 encounter, two timelines

Take the three-line claim from our line-level 835 reconciliation walkthrough: $560.00 submitted, CLP04 = $102.40 paid by the payer, CLP05 = $87.60 patient responsibility, split $62.00 deductible (PR-1) and $25.60 coinsurance (PR-2).

Timeline A — today, at most practices:

Payer dollars: 8 days from DOS. Patient dollars: 42 days from DOS.

Timeline B — automated 835 plus an instant rail:

Patient dollars: 7 days from DOS instead of 42. Payer dollars: identical.

That asymmetry is the whole point. Thirty-five days came off the patient leg — and most of it came from Clock 3, not Clock 2: the request went out because the 835 was parsed at 2:11 AM instead of read by a person on Thursday afternoon. The instant rail then removed the last two weeks of check float. Neither piece works without the other, and neither one touched the payer's adjudication.

Where real-time settlement does move payer-side cash is the final hop. When a payments platform holds adjudicated funds and settles them to your operating account, the difference between an ACH batch and an RTP credit is one to three days of your money, every day, including weekends. See the patient request-for-payment article for the delivery and consent mechanics on the patient side.

What has to be true before real-time settlement helps

Five prerequisites, in the order they usually bite:

1. Your bank participates, and on the right side. Many institutions enabled receive before send. Receiving is what you need for inbound patient payments; sending is what you need for refunds. Ask your treasury contact about both directions and both networks by name.
2. Your 835 handling is already automated. An instant rail feeding a queue someone opens Thursday afternoon just moves the wait.
3. Reconciliation runs daily, not on banking days. Weekend and holiday credits post to a real balance. If your close process assumes settlement batches, it will report variances that are not variances.
4. Refunds have an approval gate. Irrevocability removes the reversal you have been quietly relying on. Two-person approval above a threshold, and an ACH fallback for anything that does not need to be instant.
5. Payment messages carry no clinical detail. The unstructured remittance field is short and, more importantly, it is not a HIPAA-controlled channel end to end. Reference an opaque account or invoice token. No CPT, no diagnosis, no visit description in a payment memo that will land in a banking app screenshot.

Then measure two things and ignore the rest: hours from adjudication to available funds (Clock 2, per source), and share of patient balances collected within seven days of the 835. The first tells you whether the rail is doing its job. The second tells you whether anything upstream is undoing it.

FAQ

Will our payers pay us over FedNow or RTP?

Not in the near term for adjudicated claims. The HIPAA-mandated healthcare EFT standard is ACH CCD+ with the 835 TRN trace in the addenda record, and the CAQH CORE operating rules for EFT/ERA reassociation are built around that pairing [verify current rule version]. Some payers are piloting instant rails for specific use cases, but design your architecture assuming ACH on the payer leg. The realistic near-term wins are patient balances and platform-to-practice settlement.

Can we send patient refunds over RTP or FedNow?

Yes, if your bank supports send on that network and the patient's bank can receive — and you should treat it as a different risk category than an ACH refund. There is no reversal. Require approval above a dollar threshold, validate the destination account against the account that originally paid, and keep an ACH path for anything that fails reachability. A refund sent to the wrong account is recoverable only if the receiving customer voluntarily returns it.

Is a request-for-payment message HIPAA-compliant?

The message itself is a payment instruction, not a clinical record, but the amount plus the provider's identity is enough to constitute PHI in context. Apply minimum necessary: an amount, a practice name, and an opaque reference. Keep clinical and line-level detail behind an authenticated view rather than in the payload delivered to a banking app or SMS preview. And confirm you have a BAA with any vendor in the path that handles the balance data, not just the funds.

Run the timeline against your own numbers

The shteg.ai sandbox lets you replay both timelines with synthetic data: an 835 arriving at 2:10 AM, the line-level parse, the request-for-payment dispatch, and the settlement acknowledgment — with simulated rail failures (unreachable receiving bank, rejected pacs.002, ACH fallback) so you can see the exception paths before they show up in production.

Open the shteg.ai sandbox → Use the provided synthetic files. Do not upload live PHI or real account numbers to a sandbox environment.

This article is provided for educational purposes and describes general payment-network and X12 transaction mechanics. It is not legal, compliance, or financial advice. Network operating hours, transaction limits, participant coverage, and operating rules change; every item marked [verify] should be confirmed against current FedNow Service documentation, The Clearing House RTP operating rules, NACHA rules, and CAQH CORE operating rules before you rely on it. Timelines and amounts are synthetic. Confirm capabilities, per-item pricing, and send/receive enablement with your own financial institution.

Draft notes (not part of the article): ~1,610 words. H1 + 6 H2. The requirement was one comparison table; there are three tables total — the rail comparison is the comparison table, the other two are the worked-example timelines, which read better as tables than prose. Say the word if you want Timeline A/B converted to bulleted prose. Internal-link slugs are placeholders matching briefs #1 and #3 and match the slugs used in the article 1 draft. Everything volatile (network limits, NACHA windows, RTP/FedNow coverage) is marked [verify] rather than stated — the $10M RTP limit and FedNow's configurable cap in particular have both moved recently.

Want me to save this to workspace/drafts/revenue-cycle-2-<id>.md in the seo-presence workspace?

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