FedNow and RTP: Implementing Real-Time Settlement for Independent Practices

A patient approves a $141.20 balance at 8:14 AM on a Saturday. Whether that money is in your operating account by 8:15 AM or on Wednesday afternoon is not a function of how motivated your billing staff is. It is a function of which rail the payment travels on, and every rail's timing is fixed by a specification you can read.

This article is about what changes in your billing system when the rail is real-time. Not the marketing version — the message sequence, the ledger states, the arithmetic, and the controls that move to the front of the workflow when there is no undo.

ACH is not slow — it is scheduled

Automated Clearing House is a batch file system, and it behaves like one. Entries are originated into a file, transmitted in defined windows, and settled on a subsequent banking day. Same-day ACH compresses this into intraday processing windows but remains a batch system running on a banking calendar, subject to a per-transaction ceiling [verify current Nacha Operating Rules and limits].

Card payments split into four events practices routinely collapse into one word:

• Authorization — a hold on the cardholder's line. Under two seconds, moves no money.
• Capture — at your terminal's batch cutoff. Anything after the cutoff rolls to tomorrow.
• Clearing — the batch moves through the network to the issuer.
• Funding — a net credit to your merchant account on your processor's schedule, banking days only [verify your merchant agreement].

The shared property is that the clock belongs to someone else, and it stops on nights, weekends, and federal holidays. The two right-hand columns below break that property. The table is framed around what your billing system has to implement, not around marketing claims:

RTP is operated by The Clearing House; the FedNow Service is operated by the Federal Reserve. Both are credit-push-only, both run 24/7/365, and both settle with finality at acceptance. Transaction ceilings, participating-institution reach, and fee schedules differ between them and change over time — get current figures from your financial institution rather than designing against a number in an article [verify].

What actually happens on the wire

Both rails use ISO 20022 messages. The sequence you will integrate against, in order:

1. `pain.013` — request for payment. You originate it: amount, your account, a reference string, an end-to-end ID.
2. `pain.014` — status report on that request. The patient's institution acknowledges receipt; this is not payment.
3. `pacs.008` — the credit transfer itself, originated by the patient's institution after the patient approves inside their own banking app.
4. `pacs.002` — status report on the transfer. Acceptance here is settlement. There is no pending state and no settlement date distinct from the transaction date.
5. `camt.054` — credit notification to your account.

Note what you never touch: no card number, no debit authorization, no stored credential. Authentication happens inside the patient's institution under its own step-up controls.

Worked example: one balance, one Saturday

Synthetic values throughout — no real identifiers, no patient data.

An 835 posts for encounter ENC-4471. Charged 340.00, allowed 244.00, payer paid $102.80, with CAS*CO*45*96.00, CAS*PR*1*118.40, and CAS*PR*2*22.80. The line balances: 340.00 = 102.80 + 96.00 + 118.40 + 22.80, and the allowed amount reconciles as 244.00 = 102.80 + 141.20.

Only the PR group is requestable. The 96.00 in CO-45 is a contractual adjustment and is not billable to the patient under a participating-provider agreement — putting it on a statement is balance billing. The billable figure is `118.40 + 22.80 = 141.20`, less anything collected at the front desk (here, nothing). The line-level derivation of that number is the subject of Line-Level 835 Remittance Intelligence: Beyond Basic ERA Parsing [verify link target].

Saturday, 08:14:03. No banking day is running.

Six minutes and forty-two seconds from request to final funds, on a Saturday morning, with no batch running anywhere.

The same 141.20 on a card at an assumed 2.9% + 0.30 (a stated assumption for arithmetic, not a market rate — your contracted rate is your own): 141.20 × 0.029 = $4.09, plus $0.30 = $4.39 in fees, netting $136.81, funded on your processor's schedule, no earlier than Monday. Two differences follow from that line, and the second matters more than the first.

The ledger difference is gross-and-discrete versus net-and-aggregated

Card deposits arrive net and aggregated. One credit lands that matches no encounter. Someone decomposes it back into transactions plus fees, then posts each against its encounter. Every deposit is a small forensic exercise, and refunds surface in later batches with no visible link to the original.

Instant payments arrive gross and discrete. One payment, one credit, one end-to-end ID, one structured remittance field. Fees are billed separately rather than netted, so your bank credit equals your ledger credit — the single most useful property in the arrangement, and the reason month-end close stops taking an afternoon.

The float is worth stating as arithmetic rather than as a claim. If a practice collects 38,400 per month in patient responsibility and averages two calendar days between collection and funding, then `38,400 ÷ 30 × 2 = 2,560` is permanently in transit — not a fee, but money you have earned and cannot spend, refilled every day. If you carry a line of credit, that balance has a rate attached.

Three posting rules change:

• Post on `pacs.002`, not on a UI state. A screen that says "sent" is not settlement.
• Retire the undeposited-funds step for this rail. There is no in-transit balance to age. A clearing account kept out of habit sits at zero and hides errors instead of catching them.
• Refunds are outbound payments, not voids. A refund is a new credit transfer you originate, with its own approval control and audit trail.

Finality relocates risk — it does not remove it

Card networks put the control after the transaction. Instant rails put it before. Once accepted, your only recourse is a request for return of funds (camt.056 on FedNow, the equivalent on RTP), which the receiving institution is under no obligation to honor.

• Inbound risk is low; outbound is where controls belong. Receiving patient payments, you hold final funds. The exposure is refunds and disbursements sent to a wrong or manipulated account. Dual approval above a threshold, an allowlist for recurring payees, and out-of-band verification of any change to payee bank details are the controls that matter.
• Validate the account before you originate. Ask your financial institution what account-validation or payee-confirmation service it offers on these rails [verify what is available to you].
• Your attack surface is the provider API, not the rail. Scope and rotate credentials, verify webhook signatures rather than trusting payloads, and reconcile against the status message rather than a callback that could be replayed.
• Keep PHI out of the structured remittance field. It renders in a consumer banking app and traverses parties operating under no BAA. Carry an opaque encounter reference and resolve it server-side. That is a payload-design property you implement, not a compliance conclusion any vendor can grant you.

Implementation notes for a billing system

The integration is small; the state machine is where the bugs live.

• Model five states explicitly — requested, in_flight, settled, declined, expired. Collapsing requested and settled into a boolean paid flag is the defect that produces duplicate asks.
• Dedupe on the encounter reference before dispatch. A corrected 835 must not generate a second request for the same balance.
• Make settlement handling idempotent, keyed on the end-to-end ID. Networks and providers retry; your ledger should absorb a duplicate without double-posting.
• Net front-desk collections against the PR total at request time, not at statement time. Asking for 141.20 after collecting 40.00 creates a refund obligation and costs you the patient's trust in every future number you send.
• Define partial-payment behavior. A 141.20 request paid at 100.00 leaves $41.20 open and needs a stated re-ask rule, not a silent write-off.
• Handle the secondary-payer race. A patient can pay while a secondary 835 is in flight that reduces responsibility to zero. Detect it, refund promptly, log it against the same encounter.
• Have a fallback rail. A given patient's institution may participate in one network, both, or neither. Origination logic should degrade to card or ACH rather than fail.

The request side of this flow — token design, notification content, and channel constraints — is covered in Securing Point-of-Care and Post-Visit Patient Payments: A HIPAA-Safe Architecture [verify link target].

Try it in the shteg.ai sandbox

The sandbox replays this scenario end to end against a simulated clock: a de-identified 835, the PR/CO split, the billable amount, the pain.013 request, the pacs.002 acceptance, and the resulting ledger entry — with the same volume run on a batch schedule alongside, so the availability gap is visible rather than argued.

Bring one week of your own deposit history. The distance between your collection dates and your availability dates is usually the entire finding.

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

FAQ

Do we have to replace card processing to use these rails? No, and most practices should not try. Card acceptance is table stakes for in-person collection and for patients who prefer it. The realistic architecture is mixed — instant rails where the patient's institution supports them, cards and ACH everywhere else, one ledger behind all of it. The posting and reconciliation discipline above improves every channel you run, which is why it is worth doing before a rail migration rather than after.

Are RTP and FedNow interchangeable from our side? Functionally similar, operationally distinct. Both are credit-push, ISO 20022, 24/7/365, and final on acceptance. They differ in operator, settlement mechanism, participating institutions, transaction ceilings, and fee schedules. In practice your treasury bank abstracts the routing — ask which networks it reaches, what ceilings apply to your account, and how fees are billed before you model the economics [verify with your financial institution].

What if a patient pays twice, or pays the wrong amount? You refund it as a new outbound payment, typically within seconds on the same rail; there is no reversal to invoke. Practically, that means duplicate prevention lives in origination logic — dedupe on the encounter reference, net front-desk collections before dispatch, and suppress requests on accounts in dispute or financial assistance. Catching it before origination is a conditional; catching it after is a refund, a posting entry, and a phone call.

Educational content for physicians, practice administrators, and revenue-cycle staff. Not legal, financial, billing, coding, or compliance advice. All timestamps, message identifiers, dollar amounts, adjustment codes, and fee rates in this article are synthetic illustrations and contain no patient data; the card rate and collection volume in the worked examples are stated assumptions for arithmetic, not market figures. Payment network capabilities, message specifications, transaction limits, operating rules, and fee schedules change — verify current specifications with your financial institution, and consult X12 835 documentation, CMS remittance guidance, Nacha Operating Rules, and the applicable RTP or FedNow operating rules for authoritative detail. Funding timelines are governed by your merchant and treasury agreements. Consult counsel for your jurisdiction and your vendor arrangements.

Draft notes: ~1,680 words. 5 body H2s + FAQ H2 (6 total), CTA as H3, worked example as H3 inside §2. Comparison table is implementation-dimension-framed (5 rails × 7 dimensions). Arithmetic is checkable: 340.00 = 102.80 + 96.00 + 118.40 + 22.80; 244.00 = 102.80 + 141.20; PR total 118.40 + 22.80 = 141.20; card 141.20 × 2.9% = 4.09, + 0.30 = 4.39, 141.20 − 4.39 = 136.81; float 38,400 ÷ 30 × 2 = 2,560. Nine [verify] flags (Nacha limits, merchant agreement, card dispute windows, remittance field lengths, RTP/FedNow ceilings and fees, account validation, two link targets). No statistics asserted — every number is either arithmetic from a labeled assumption or a synthetic illustration. PR-vs-CO balance-billing guardrail is stated in the worked example, per the cluster's standing requirement. HIPAA framing is mechanism-only (opaque encounter reference, server-side resolution, no PHI in the remittance field) — no compliance conclusion asserted in the platform's voice.

Differentiation from `patient-payments-2-msskdrb6.md` (same brief slot, prior batch): that draft argues the four-day multi-payment cash timeline and a rails-capability table. This one argues the message sequence and the billing-system state machine, with a single-payment sub-message timeline and an implementation-dimension table. No shared figures, no shared table, different worked example.

Blocking before publish, per pipeline convention: a named physician or revenue-cycle reviewer must be assigned — I did not invent one. Both internal link targets need confirming against live slugs.

Want me to save this to examples/seo-presence/workspace/drafts/patient-payments-2-<id>.md? I held off because the id is a pipeline decision and patient-payments-2-msskdrb6.md already occupies the slot from the prior batch — I can write a new id alongside it or overwrite, your call.

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