The Engineering Case for FedNow and RTP in Independent Practice Revenue Cycles

There is one interval in your revenue cycle that no payer controls, no coder touches, and no clearinghouse edit affects: the gap between the moment a payer's adjudication engine finishes and the moment the money is spendable in your operating account. Nothing happens during it. It exists because ACH is a batch system running on a banking calendar.

Most practices have never measured that interval, which makes it hard to know whether a real-time rail is worth the integration work. So this article does three things in order: names where the legacy path spends its time, describes what FedNow and RTP actually are at the settlement layer, and then defines a metric you can compute from fields already sitting in your 835s — before you talk to a vendor about anything.

Where the legacy path spends its days

When adjudication completes, two artifacts leave the payer through two different pipes. An X12 835 remittance advice heads for your clearinghouse mailbox. A payment instruction heads for the payer's payment vendor, which aggregates across providers, builds a Nacha-format file, and originates it to its bank inside a submission window.

Four properties of that path add time, and none of them involve anyone thinking about your claim:

  • Batching. Your payment is one entry detail record inside a file assembled on the vendor's cadence, not yours. Miss the origination cutoff and you wait for the next one.
  • The banking calendar. ACH settles on banking days. Weekends and Federal Reserve holidays are not delays in the system's view — they are simply not time.
  • Deferred effective dating. The BPR16 element in the 835 carries the effective entry date: the banking day the receiving bank is instructed to post. It is a statement about the future, not a record of settlement.
  • Reversibility. ACH entries can be returned after settlement, so the network needs defined windows and a settlement calendar to manage that exposure [verify current Nacha operating rules]. The float is the price of the return right.

That last property is the load-bearing one. Every timing constraint above follows from the fact that an ACH credit is not final when it arrives.

What FedNow and RTP are at the settlement layer

Two instant rails operate in the U.S. RTP is run by The Clearing House and has been live since November 2017. FedNow is run by the Federal Reserve and has been live since July 2023. They are separate networks with similar mechanics and one architectural difference worth understanding, because it explains what your bank will and won't let you do.

FedNow is real-time gross settlement on the Federal Reserve's own books: each transfer settles directly between participants' Federal Reserve master accounts. RTP settles on The Clearing House's books against a joint prefunded balance account held at the Federal Reserve Bank of New York — participating banks post funds into it in advance, and transfers move balances within it [verify current mechanics and any LMT window changes].

The practical consequence for a practice: receiving is easy, sending is gated. A bank that has prefunded a position has to manage it around the clock, which is why weekend and overnight send limits get throttled while receive capability is comparatively unconstrained. If all you need is to be paid, you are on the easy side of that asymmetry — but receive is still separately provisioned, and you have to ask for it explicitly.

Both rails share the properties that matter downstream: one ISO 20022 message per payment (pacs.008, with a pacs.002 status returned in seconds), credit-push only, irrevocable on acceptance, and 24/7/365.

Standard ACH (CCD+)Same Day ACHRTP (The Clearing House)FedNow (Federal Reserve)
Settlement modelDeferred net, banking daysDeferred net, fixed windowsPrefunded joint account at FRBNYRTGS in Fed master accounts
Unit of transmissionNacha file (batched)Nacha file (batched)Single pacs.008 messageSingle pacs.008 message
Operating windowBanking days, cutoff-boundBanking days, fixed windows24/7/36524/7/365
Funds availableOn the BPR16 effective entry date, per receiving-bank policyEnd of same banking day [verify]SecondsSeconds
FinalityReversible; return windows apply [verify Nacha]Same return exposureIrrevocable on acceptanceIrrevocable on acceptance
Remittance carriage80-char addenda; 835 arrives separatelySameRmtInf — unstructured, structured, or URL [verify]RmtInf — unstructured [verify]
Request for paymentNot supportedNot supportedpain.013 / pain.014Supported [verify]
Per-transaction limitSet by your bank, not the networkNetwork cap [verify current]Network-set, revised periodically [verify current]Network default, raisable by the receiving bank [verify current]
Correction mechanismReturn codes; offset in a later 835SameRequest for return of funds; you must actRequest for return of funds; you must act

Worked example: computing adjudication-to-available on one claim

Here is the metric. Adjudication-to-Available (A2A) is the elapsed time from the 835's production date to the timestamp your bank makes the funds available. Both inputs already exist: DTM*405 in the remittance, and the value date on your bank statement or credit notification. No vendor benchmark required.

One synthetic claim, three lines, commercial payer, deductible partially unmet. All values are synthetic and contain no patient data.

code
BPR*I*107.80*C*ACH*CCP*01*021000021*DA*4455667788*1234567890**01*011000015*DA*3312009*20260908~
TRN*1*20260904C9130847*1234567890~
DTM*405*20260904~
CLP*PCN-51188*1*295.00*107.80*51.20*12*ICN-2026-0904-9130*11~
SVC*HC:99213*185.00*75.00**1~
CAS*CO*45*67.00~
CAS*PR*1*43.00~
SVC*HC:93000*92.00*32.80**1~
CAS*CO*45*51.00~
CAS*PR*2*8.20~
SVC*HC:36415*18.00*0.00**1~
CAS*CO*97*18.00~

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

  • 99213 — 185.00 = 75.00 + 67.00 (CO-45) + 43.00 (PR-1) ✓
  • 93000 — 92.00 = 32.80 + 51.00 (CO-45) + 8.20 (PR-2) ✓
  • 36415 — 18.00 = 0.00 + 18.00 (CO-97) ✓

Claim level ties out: CLP03 − CLP04 = 295.00 − 107.80 = 187.20, which equals all CAS amounts summed (136.00 contractual + 51.20 patient). CLP05 = 51.20 is the PR-group total and the only amount billable to this patient — 43.00 deductible plus 8.20 coinsurance. The 136.00 in the CO group is contractual write-off, including the entire venipuncture line, which paid zero and is billable to no one. Putting CO amounts on a statement is balance billing under a participating-provider agreement.

Now the timing elements. DTM*405 = 20260904 — Friday. BPR16 = 20260908 — Tuesday, because Monday September 7 is Labor Day and therefore not a banking day. TRN02 = 20260904C9130847 is the reassociation trace number, the only value tying this remittance to a specific deposit.

Path A — ACH as it actually runs:

  • Fri Sep 4, 19:40 — adjudication completes, 835 written (DTM*405)
  • Sat Sep 5, 06:10 — 835 lands in the clearinghouse mailbox. Postable, no cash behind it
  • Tue Sep 8, 08:15 — $107.80 posts, inside a lump deposit with other claims
  • Tue Sep 8, 11:30 — statement line matched to TRN02, posted at the line level

A2A ≈ 84.5 hours. Roughly 60 of those hours are weekend and federal holiday — time the network does not recognize as existing.

Path B — the same claim on an instant rail:

  • Fri Sep 4, 19:40 — adjudication completes, 835 written
  • Fri Sep 4, 19:41 — pacs.008 for $107.80 sent; pacs.002 accept returns in seconds; funds final and available

A2A ≈ 1 minute. The header changes with it: BPR04 moves off ACH, BPR05 (CCP) drops away since there is no Nacha format to name, and BPR16 stops being a future instruction and becomes the actual settlement date [verify how your specific payers populate these].

Note what A2A does not capture. In Path B the money arrives Friday night and the 835 is not retrievable until Saturday morning, so the deposit lands as unidentified cash. Real-time settlement collapses A2A and makes available-to-posted the binding constraint instead.

To baseline your own practice: pull twenty remittances per major payer, record DTM*405, funds-available date, and line-level-posted date. Three intervals, three owners. Any claim about average A/R reduction that doesn't start from your own payer mix is a guess [verify any vendor-quoted reduction against your baseline].

Integration paths into an existing PMS — and where the PHI boundary sits

Most practice management systems have no concept of an intraday credit event. They post from an 835 batch, often on a nightly job. A real-time rail wired to a nightly posting process yields nightly posting. Three integration patterns exist, in increasing order of work:

  1. Payer-side origination only. The payer sends on the rail; your bank receives. The PMS is untouched, and cash lands sooner. Your posting cadence becomes the constraint, and unmatched deposits accumulate in suspense.
  2. Bank cash-side notification. Your bank emits real-time credit notifications (camt.054, or a webhook on a treasury API). A listener writes each credit to a suspense account, then matches against the 835 by TRN02 when the file arrives. Two engineering requirements here: idempotency — key on the message's end-to-end identifier, because notifications can be redelivered and a replay must not double-post — and a suspense policy, because a deposit without a matched remittance must never touch a patient ledger.
  3. Orchestration layer. A vendor holds the deposit account of record, receives on the rail, matches to the 835, and pushes a posting file into the PMS. Least internal build, most diligence required. See automating 835 remittance reconciliation for instant deposits for the matching mechanics.

The PHI boundary follows the pattern you choose. The rail message should carry an amount, account details, and an opaque reference token — the TRN02 value or an encounter identifier. Not a name, not a date of birth, not a CPT code. The 835 is the opposite: a HIPAA-mandated standard transaction containing PHI [verify citation to 45 CFR Part 162], which stays behind your access controls.

That split determines who needs a BAA. A bank moving money in a payment transaction generally falls under the financial-institution carve-out in the business-associate definition [verify 45 CFR 160.103]. A vendor that parses your 835 is handling PHI on your behalf and is a business associate. Pattern 3 needs a signed BAA; pattern 1 largely does not. Ask any vendor which side of that line their pipeline sits on, and expect a specific answer.

FAQ

Our largest payer says they can't originate on FedNow. Is any of this still worth doing?

The measurement is, immediately — it costs an afternoon and tells you which interval owns your A/R. Payer adoption of instant rails for provider payments is not universal, and most commercial remittance today still arrives as CCD+ with a separately delivered 835 [verify against your own payer mix]. Two things are available regardless of payer capability: the patient leg, where request-for-payment works on your bank's enablement rather than a payer's, and the reassociation lag, which is entirely yours to fix.

Is Same Day ACH good enough?

Often, and it's easier to obtain. It compresses the settlement leg to the same banking day when origination makes a window. It does not change the banking calendar, the return exposure, or the 80-character addenda constraint. In the worked example above, Same Day ACH still cannot deliver Friday-evening money before Tuesday, because Saturday, Sunday, and Labor Day aren't banking days. It improves a batch system; the instant rails are a different system.

If instant credits are irrevocable, how do payer overpayments get corrected?

Not by clawback. Under ACH, a correction typically appears as a provider-level adjustment — a PLB segment offsetting a later remittance — or as a reversal against the account. On RTP and FedNow the original credit is final, so the correction arrives as a separate transaction or as a request for return of funds that you must affirmatively act on. Better for cash predictability, worse for a posting process on autopilot: it has to recognize a return request as a distinct event rather than a new payment.

Run the numbers on your own remittance

The shteg.ai sandbox takes a de-identified 835 and returns the settlement decomposition for that file: DTM*405 production date against BPR16 effective entry date against your actual funds-available timestamp, the computed A2A interval with banking-calendar time broken out, the TRN02 reassociation key, service-line balancing validated on every SVC (SVC02 = SVC03 + CAS), the PR-group total isolated as the only billable patient amount, and a side-by-side of ACH versus instant-rail availability for the same dollars.

Bring one file from your slowest payer — ideally one where the deposit and the remittance landed on different days. That gap, annualized across your payer mix, is the entire business case, and it belongs to you rather than to a vendor's benchmark.

[Open the shteg.ai sandbox →](/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, trace numbers, dates, and dollar figures in this article are synthetic illustrations and contain no patient data. X12 835 specifications, CAQH CORE operating rules, Nacha rules, and FedNow and RTP network capabilities, limits, settlement mechanics, 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,720 words. H1 + 6 H2s (4 body + FAQ + CTA), within the 4–6 spec by merging brief items 4 and 5 into one section — the PHI boundary is what distinguishes the three integration patterns, so they read better together than apart. All five outline items from fast-payment-mssl22mx.md §Article 1 are covered. Carries the brief's prescribed internal link to Article 2 with the specified anchor text, placed in the PMS-integration section as directed. Worked example carries SVC02 = SVC03 + CAS on all three lines plus claim-level tie-out (CLP03 − CLP04 = 187.20 = sum of all CAS; CLP05 = 51.20 = PR total) and a two-path settlement timeline. One comparison table. Fourteen [verify] flags — no transaction limits, adoption rates, or A/R-reduction figures asserted anywhere; brief item 3's "[verify potential average reduction]" is answered by giving a formula instead of a number. Dates verified against a real 2026 calendar (Sep 4 Friday, Sep 7 Labor Day, Sep 8 Tuesday).

Differentiation check: the two prior drafts in this slot own the four-clock decomposition (msr79be9) and the Nacha file hierarchy plus reconciliation inversion (msskmg9y). This draft's distinct load-bearing content is (a) the RTP prefunded-joint-account vs. FedNow RTGS settlement distinction and the send/receive asymmetry it explains, (b) A2A as a computable metric rather than a vendor benchmark, and (c) the three PMS integration patterns with idempotency, suspense policy, and the BAA/financial-institution carve-out mapped onto them. The rails comparison table overlaps msskmg9y; rows here are re-cut toward settlement architecture and correction mechanism. Still worth a dedupe pass before publishing all three in the same cluster.

Before publish: both link targets are guesses at eventual slugs. The 45 CFR 160.103 carve-out characterization should get a compliance eyeball — it's the one claim here where an over-broad reading would matter operationally. No named clinical or revenue-cycle reviewer assigned.


Want me to save this to examples/seo-presence/workspace/drafts/fast-payment-1-<id>.md? The pipeline uses a short base-36 timestamp slug — give me one, or say the word and I'll generate it.

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