Implementing Request-for-Payment (RfP) for Post-Adjudication Patient Balances

Patient responsibility is the slowest-collecting line in an independent practice's A/R, and the reason is architectural, not behavioral. By the time a patient balance is knowable, the practice has already waited for adjudication. Then it adds a statement cycle, a mail float, and a portal login that the patient has to remember a password for. Each of those steps is a queue, and each queue has a drop rate.

Request-for-Payment (RfP) removes most of that stack. It is a message type on the RTP and FedNow networks that asks a patient's bank to present a payable item inside the banking app the patient already uses. The patient approves; funds move as a credit push in seconds and settle with finality. No card number, no stored credential, no portal.

This article covers what the message actually is, how to derive the requested amount directly from the 835 so the number is never hand-keyed, and how to design the payload so nothing clinical leaks onto a lock screen. Patient collection is one leg of a larger problem — see also accelerating total practice cash flow with FedNow settlement for the payer side.

Why Statements and Portals Leak Revenue

The failure modes are mechanical and worth naming precisely, because each one maps to a different fix:

• Mail float. A statement printed on day 1 is not in a mailbox until day 3–5. The practice has no delivery signal, so the follow-up cycle is timer-based rather than event-based.
• Authentication friction. Portal payment requires the patient to locate a credential for a system they use once or twice a year. Every abandoned login is a collection failure that looks identical to an unwillingness to pay.
• Amount ambiguity. A statement that arrives before secondary adjudication, or before a corrected 835, shows a number the patient may reasonably dispute. Disputed statements generate phone calls, and phone calls cost staff minutes per dollar collected.
• No structured return path. A check or a card payment arrives with a memo line, not a claim identifier. Someone has to match it.

RfP addresses delivery, authentication, and matching simultaneously. It does not address amount ambiguity — that is solved upstream, in the 835.

What Request-for-Payment Actually Is

RfP is a non-monetary message. The practice's bank sends an ISO 20022 pain.013 request to the patient's bank; the patient's bank renders it in the app; if the patient accepts, their bank originates a separate credit transfer back to the practice. [verify current message version and network support matrix for RTP and FedNow]

Three properties matter for a medical practice:

It is credit-push. The practice never holds the patient's account credentials and never initiates a debit. This is the opposite of card-on-file and it collapses PCI scope, because there is no PAN in the system to protect.

It is final. Settlement on RTP and FedNow is irrevocable. There is no chargeback mechanism. Patient disputes are handled by the practice directly, as a refund — which is generally what a practice wants, but it means refund policy has to be an actual written process, not an implicit reliance on the card network's dispute rails.

It carries a structured reference. The request and the resulting credit transfer both carry an end-to-end identifier that you control. Set it to your claim reference and the inbound payment reconciles itself. This is the same mechanism described in automating 835 remittance reconciliation for instant deposits, applied to the patient side of the ledger.

The practical constraint is reachability. Not every consumer institution that can receive an instant credit can also present an RfP. Any production implementation needs a fallback path — a hosted card or ACH page — selected at send time based on the receiving institution's capability, not after the patient has already failed to pay. [verify current RfP-capable institution coverage]

Worked Example: Deriving the Request Amount from the 835

The requested amount should never be typed by a human. It is a field in the remittance. Here is a synthetic two-line professional claim.

CLP*ACCT-4471*1*187.00*84.00*58.00*12*PCN-99120041*11~
  SVC*HC:99214*175.00*118.36**1~     <- placeholder, corrected below

Take the office visit line as adjudicated:

SVC*HC:99214*175.00*84.00**1~
CAS*CO*45*45.00~
CAS*PR*3*25.00~
CAS*PR*2*21.00~

The 835 balancing rule at the service line is SVC02 − Σ(CAS amounts) = SVC03:

175.00  (SVC02, submitted charge)
−45.00  (CAS*CO*45  contractual write-off → allowed = 130.00)
−25.00  (CAS*PR*3   copay)
−21.00  (CAS*PR*2   coinsurance, 20% of 105.00)
───────
= 84.00 (SVC03, line paid)   ✔ balances

Second line, a non-covered urinalysis:

SVC*HC:81002*12.00*0.00**1~
CAS*PR*96*12.00~

12.00 − 12.00 = 0.00 (SVC03)   ✔ balances

Now roll to the claim level. The patient balance is the sum of CAS amounts carrying the PR group code — and nothing else:

PR-3  copay          25.00
PR-2  coinsurance    21.00
PR-96 non-covered    12.00
──────────────────────────
CLP05 patient resp.  58.00

Cross-check the whole claim: CLP03 (187.00) − CLP04 (84.00) − CLP05 (58.00) = 45.00, which is exactly the CO-45 contractual adjustment. The claim balances, so the $58.00 is trustworthy enough to send.

That last sentence is the actual engineering rule. Send the RfP only when the claim balances and no secondary payer is pending. An unbalanced 835, a CLP02 status indicating a reversal or a pending claim, or a populated COB segment are all hard stops that route to human review instead of to the patient's phone. A wrong request-for-payment is more expensive than a late one, because it costs a phone call and the patient's trust in the channel.

Designing a HIPAA-Safe Payload

HIPAA permits disclosure of PHI for payment purposes, and a bill is a payment activity. That is the legal floor, not the design target. Two things push the design well above it.

First, the minimum necessary standard applies. Second — and more concretely — the RfP renders inside a bank app the practice does not control, on a device that may be a shared or joint account, sometimes as a lock-screen push notification. "Riverside Oncology Associates — $58.00" is a disclosure to whoever is looking at the phone. Separately, a financial institution processing a payment transaction is generally not acting as a business associate, which means there is no BAA governing what the bank does with the descriptor text you supply. [verify — 45 CFR 164.501 payment definition and the financial-institution carve-out; confirm with counsel]

So the payload rule is: the RfP carries money and an opaque token. Everything explanatory lives behind authentication.

{
  "amount":        "58.00",
  "currency":      "USD",
  "creditor_name": "SHTEG MEDICAL GROUP",     // legal/DBA name, no specialty
  "remittance_info": "Visit 04-22 Ref 4471",  // date + opaque ref only
  "end_to_end_id": "ACCT-4471-01",            // your claim ref; returns on the credit
  "expiry":        "2026-09-05T23:59:59Z",
  "detail_url":    "https://pay.example.com/r/8f3a..."  // authenticated; PHI lives here
}

Fields that must never appear: CPT or HCPCS codes, ICD codes, diagnosis or procedure descriptions, provider specialty in the creditor name, referring physician, place-of-service descriptors, or any free text a biller can type into. Make the remittance-info field template-generated and non-editable. A free-text box that reaches a bank rail will eventually contain a diagnosis.

Note also that SMS or push delivery of a payment request is subject to consent rules independent of HIPAA. Capture and store the consent artifact at registration, with timestamp and channel. [verify applicable TCPA requirements and current consent standards with counsel]

Comparing the Collection Channels

The table argues for RfP-first with a deterministic fallback, not RfP-only. Coverage is the binding constraint, and it is the one variable that improves without any work on your part as network participation grows.

Instrumenting the Channel

RfP produces status events that statements do not, so measure the funnel rather than a single collection rate:

• Send eligibility rate — claims that balanced and cleared COB checks, over all claims with a non-zero CLP05. A low number here is an 835-ingestion problem, not a collections problem.
• Deliverability — requests presented by the receiving bank, over requests sent. This is your live coverage measurement.
• Accept / decline / expire split. A decline is signal: it should route to a payment-plan offer, not to a second identical request.
• Time-to-cash from adjudication, measured from 835 receipt rather than from statement date, so the metric captures the delay you are actually removing.

Avoid benchmarking against published industry collection averages without checking methodology — definitions of "patient responsibility collected" vary widely across sources. [verify any comparative benchmark before publishing it internally]

FAQ

Is sending a request-for-payment to a patient's phone a HIPAA violation?

Billing is a payment activity, and payment activities are permitted disclosures. The risk is not the act of requesting payment — it is what the message says. A request carrying an amount, your legal entity name, and an opaque reference discloses substantially less than a mailed statement. A request carrying a procedure description in the remittance field is a problem regardless of the rail. Confirm your specific implementation with compliance counsel. [verify]

What happens if the patient's bank does not support RfP?

Nothing should reach the patient. Capability should be checked before send, and non-capable institutions should route automatically to your fallback channel. Treat an undeliverable RfP as a routing decision the system makes, never as a failed patient interaction.

Can a patient reverse an RfP payment the way they can reverse a card charge?

No. RTP and FedNow credit transfers are final. This eliminates chargeback exposure but shifts the burden to you: you need a documented refund path and the ability to originate a return payment quickly. Practices moving off cards should write that policy before the first request goes out, not after the first dispute.

Try It Against Real Message Flows

The shteg.ai sandbox lets you post a synthetic 835, watch the PR-coded CAS amounts roll into a claim-level patient balance, and issue an RfP against a simulated receiving institution — including the decline, expiry, and non-capable-bank paths, which are the ones worth testing. No PHI, no bank connection required.

Open the shteg.ai sandbox →

This article is provided for educational purposes and describes general technical patterns. It is not legal, compliance, tax, or financial advice. Payment network rules, HIPAA obligations, and consent requirements vary by institution, state, and payer contract, and change over time. Verify all regulatory and network specifics with qualified counsel and your financial institution before implementation. Items marked [verify] require independent confirmation against current primary sources.

Draft notes for the editor:

• ~1,540 words. H1 + 6 H2 (5 content + FAQ).
• The SVC*HC:99214*175.00*118.36**1~ line in the first code block is deliberately shown as a placeholder then corrected — remove it if you'd rather not show the mid-stream correction; the balanced version below it is the one that matters.
• Both internal links use the brief's prescribed anchor text (3→1 in the intro; the 2-linkable anchor is reused mid-article). Slugs are placeholders.
• All numbers in the worked example are synthetic and internally consistent; the claim balances at both line and claim level.
• Nine [verify] flags, mostly on network coverage, per-item costs, and the HIPAA financial-institution carve-out citation — none of these should ship unchecked.

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