The Architecture of Real-Time Settlement in Healthcare Payments

A card transaction has three separate events that practices routinely collapse into one word: authorization, clearing, and funding. The patient sees approval at 4:52 PM Friday. The practice management system marks the balance paid. The money arrives Tuesday.

Nothing is broken in that sequence — it is the system working as designed. But the design is a batch system built around banking days, which means your ledger and your bank balance disagree for most of every week. On a Friday before a Monday holiday, they disagree for four days.

Real-time rails collapse those three events into one. This article covers what RTP and the FedNow Service do at the message level, a four-day settlement timeline for one practice running both rails side by side, what real-time settlement changes in daily reconciliation, and what irrevocability means for your controls.

The three clocks in a card or ACH transaction

Break a card payment into its components and the latency is easy to locate:

• Authorization places a hold on the cardholder's line of credit. It is a promise, not a transfer — under two seconds, and it moves no money.
• Batch capture happens at your terminal's cutoff. Anything authorized after the cutoff rolls to the next batch.
• Clearing moves the captured batch through the network to the issuer.
• Funding credits your merchant account, net of fees, on your processor's schedule — commonly the next or second banking day, and only on banking days [verify your merchant agreement].

ACH has the same shape with different labels: entries are originated into a batch, transmitted in a window, and settled on a subsequent banking day. Same-day ACH compresses this into intraday windows but remains a batch system on a banking calendar, with a per-transaction ceiling [verify current Nacha operating rules].

The common property is that money moves on a schedule the practice does not control, and that schedule stops on weekends and federal holidays. All five channels below are legitimate ways to get paid. They differ in when funds become yours, and in what can undo them afterward.

The two right-hand columns are the architectural break. RTP, operated by The Clearing House, and the FedNow Service, operated by the Federal Reserve, are both credit-push-only, both 24/7/365, and both settle with finality at the moment of acceptance. Transaction ceilings, network reach, and fee schedules differ between them and change over time — confirm current figures with your financial institution rather than designing against a number you read in an article [verify].

Mechanically, an instant payment is an ISO 20022 pacs.008 credit transfer. The receiving institution returns a pacs.002 status report accepting or rejecting it, and on acceptance the funds are final and available. There is no pending state, no "in transit," and no settlement date distinct from the transaction date. If your patients approve requests for payment in their banking apps, that flow terminates in exactly this message pair — see Request for Payment: Collecting Patient Balances Without Waiting for the Statement Cycle for the origination side [verify link target].

Worked example: four days, two rails, one practice

Synthetic values throughout — no real identifiers, no patient data. Assume a card effective rate of 2.60% + $0.10 per item purely to make the arithmetic checkable; your contracted rate is your own [verify your merchant agreement].

A practice collects patient responsibility across a Friday-through-Monday window, where Monday is a federal holiday. Card volume: 22 transactions, $4,120.00 gross. Instant-rail volume: 15 payments, $2,298.75 gross.

Same practice, same four days. The $2,298.75 was spendable as it arrived — including $1,173.00 that landed on days when no batch system was running at all. The card volume was still in transit on Tuesday morning, roughly 88 hours after the first swipe in that batch.

That 88 hours is not a fee, but it is not free either. If you carry a line of credit, the float has a rate attached; if you fund payroll Friday and Friday's collections arrive Wednesday, you are borrowing against your own revenue on a recurring basis. The liquidity argument for independent practices is narrower than the marketing version: real-time settlement does not increase what you collect. It removes the gap between collecting and having, which matters in three specific places — payroll timing, vendor terms with early-pay discounts, and month-end close, where in-transit balances are why your bank reconciliation takes an afternoon.

What changes in reconciliation

Card deposits arrive net and aggregated. One credit of $4,010.68 hits your operating account. It matches no invoice and no encounter. Someone with a spreadsheet decomposes it back into 22 transactions plus $109.32 in fees, then posts each against its encounter. Every deposit is a small forensic exercise, and refunds and disputes surface in later batches with no visible relationship to the original deposit.

Instant payments arrive gross and discrete. Fifteen payments produce fifteen credits, each carrying its own end-to-end identifier and structured remittance data. If your origination path stamped an encounter reference into that field, posting is a lookup rather than a reconstruction. Fees are billed separately instead of netted out, so your bank credit equals your ledger credit — the single most useful property in the arrangement.

Three adjustments follow:

• Post on the status message, not the UI. Treat pacs.002 acceptance as the posting trigger. A screen that says "sent" is not settlement.
• Retire the undeposited-funds step for this rail. There is no clearing account and no in-transit balance to age. A holding account kept out of habit will sit at zero and hide errors instead of catching them.
• Refunds become outbound payments. There is no void and no reversal. A refund is a new credit transfer you originate, needing its own approval control, audit trail, and place in the close.

Irrevocability is a security model, not a footnote

Finality relocates risk rather than removing it. Card networks put the control after the transaction — chargeback rights let disputes be adjudicated for months. Instant rails put it before. Once a payment is accepted, your recourse is a request for return of funds (camt.056 on FedNow, the equivalent message on RTP), which the receiving institution is under no obligation to honor.

Operationally:

• Inbound risk is low; outbound is where controls belong. As the receiver of patient payments you hold final funds. The exposure runs the other way: refunds, vendor payments, and disbursements sent to a wrong or manipulated account cannot be clawed back unilaterally. 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. With no post-hoc undo, verification moves to the front of the workflow. Ask your financial institution what account-validation or payee-confirmation service it offers on these rails [verify what is available to you].
• Credit-push removes a credential you currently store. You hold no card number and no debit authorization for this flow, and authentication happens inside the patient's banking app under their institution's step-up controls. That shrinks your PCI footprint for these payments; it does not change scope for the card flows you still run.
• Your real attack surface is the provider integration. You touch an 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.

Try it in the shteg.ai sandbox

The sandbox replays a settlement scenario end to end: a de-identified 835, the balance it produces, the credit transfer message, the pacs.002 acceptance, and the resulting ledger entry — against a simulated clock, so you can watch the same volume land on a batch schedule and an instant schedule side by side.

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

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

FAQ

Do we have to replace our card processing?

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 bank supports them, cards and ACH everywhere else, one ledger behind all of it. The posting and reconciliation work above improves every channel you run, which is why it is worth doing before a rail migration rather than after.

What happens if a patient pays the wrong amount, or pays twice?

You refund it as a new outbound payment, typically within seconds on the same rail — there is no reversal mechanism to invoke. Practically, duplicate prevention has to live in your origination logic: deduplicate on the encounter reference before dispatch, and net any front-desk collection against the balance before you ask for it. Catching it before origination is cheap; catching it after is a refund, a posting entry, and a phone call.

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, and a given patient's bank may participate in one, both, or neither. 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].

Educational content for physicians, practice administrators, and revenue-cycle staff. Not legal, financial, billing, or compliance advice. All timestamps, transaction counts, dollar amounts, and fee rates in this article are synthetic illustrations and contain no patient data; the card rate in the worked example is a stated assumption for arithmetic, not a market figure. Payment network capabilities, message specifications, transaction limits, operating rules, and fee schedules change — verify current specifications with your financial institution before making operational decisions. Funding timelines are governed by your merchant and treasury agreements; consult your bank and counsel for your situation.

Draft notes: ~1,700 words (estimated — I couldn't run a word count without write access). 4 body H2s + FAQ H2 (5 total), CTA as H3. Worked example is a four-day dual-rail settlement timeline; instant-rail arithmetic checks ($84.60 + $1,041.15 + $1,053.00 + $120.00 = $2,298.75 across 15 payments), as does the card side ($4,120.00 × 2.60% = $107.12; 22 × $0.10 = $2.20; $4,120.00 − $109.32 = $4,010.68). One comparison table (five rails × seven dimensions). Eight [verify] flags: merchant agreement terms, Nacha rules, card dispute windows, RTP/FedNow ceilings and fee schedules, account-validation availability, and the two link targets. No statistics asserted — the only rates present are labeled assumptions. Reciprocal internal link to brief #1 per the cluster linking strategy.

Two notes: I deliberately kept the 835/CAS arithmetic out of this one — the sibling draft patient-payments-1-mssk80vl.md already owns that worked example, and brief #2's angle is the settlement rail, so I used a timeline instead (the requirement allows either). And I left the H2 count at 5 rather than padding to 6.

Want me to save this to examples/seo-presence/workspace/drafts/patient-payments-2-<id>.md? A patient-payments-2-msr720tp.md already exists there, but it's the fallback scaffold — I can overwrite it or write a new ID alongside, your call. Saving would also let me give you a measured word count.

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