Instant Payment Reachability, Liquidity, Limits and Fallback Routing. A practitioner deep dive into RTP and FedNow reachability, capability data, prefunding and settlement liquidity, LMT and funding-agent models, network and bank limits, deterministic rail selection, safe pre-release fallback, uncertain outcomes, reconciliation and 24x7 controls.
Instant payments become operationally difficult at exactly the point where the customer thinks they should be easy. A customer enters a beneficiary, amount and reference, presses Send now, and expects the bank to know whether that payment can travel immediately. Behind that button, the bank has to answer several different questions in a very short time: is the receiving institution reachable on RTP, FedNow, both or neither; is the specific payment capability enabled; is the beneficiary and account eligible; is the amount inside network, bank, customer, channel and risk limits; does the bank have enough settlement liquidity for the selected rail; is the rail and the bank's own connection healthy; and if the preferred path cannot be used, is there another path that can be selected before the payment is released without creating duplicate-payment risk?
That is the subject of Chapter 25.
Chapters 21–24 already established the US instant-payment architecture, RTP credit-transfer mechanics, FedNow credit-transfer mechanics and Request for Payment. This chapter does not repeat those payment lifecycles. It concentrates on the decision layer that determines whether an instant payment should be offered, which rail should be selected, whether funding is sufficient, which limits apply, how availability changes during 24x7 operations, and when fallback is safe.
The governing principle is simple but extremely important:
routing is a pre-release decision; recovery is a post-release investigation. Never use fallback to hide an uncertain payment outcome.
For a roughly 60-minute core session, spend about 35 minutes on Sections 1–5, Sections 6–10 and Sections 11–15. For the next 10 minutes, use the chapter’s three diagrams to test reachability, limits and liquidity before choosing a route. Use 10 minutes to work through one case in Section 16, then spend the final 5 minutes explaining: When is fallback safe, and when would it risk paying the beneficiary twice? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Chapter navigator
- The four questions behind every instant-payment send
- Reachability is capability data, not just a routing number
- RTP reachability and participant data
- FedNow reachability and participant data
- Building a bank-grade reachability service
- Rail selection and deterministic routing policy
- Liquidity models: RTP prefunding and FedNow settlement
- FedNow liquidity management transfers and settlement support
- RTP funding participants, non-funding participants and funding agents
- Limit hierarchy from network maximum to customer controls
- Availability, health, cutover and 24x7 operating state
- Safe fallback before release
- Unsafe fallback after release and uncertain outcomes
- Reconciliation, reporting, treasury and operational evidence
- Real-bank architecture, controls and testing
- End-to-end cases, BA checklist and authoritative references
1. The four questions behind every instant-payment send
A mature instant-payment bank does not ask only, “Is RTP up?” or “Is FedNow up?” It asks four independent questions.
Reachability: can the destination institution receive the intended payment type on this rail now?
Liquidity: can the sending institution settle the payment on that rail without breaching its funding or settlement controls?
Limits: is the amount permitted by the network, the participant configuration, the bank's product policy, the customer agreement, the channel, the account and the fraud-risk decision?
Routing: if more than one eligible mechanism exists, which route should be selected under an explicit policy, and can an alternative be selected safely if the first choice is unavailable before release?
Those questions should remain separate in data and code. If they are collapsed into one Boolean such as instant_payment_available=true, operations cannot explain why a payment was not offered. A bank needs decision evidence.
A practical decision object might contain:
payment_id
beneficiary_rtn
beneficiary_account_reference
requested_amount
currency
candidate_rails
rtp_reachable
fednow_reachable
rtp_capability
fednow_capability
reachability_source_version
reachability_effective_time
rtp_liquidity_state
fednow_liquidity_state
network_limit
participant_limit
product_limit
customer_limit
remaining_daily_limit
fraud_limit_or_threshold_result
rail_health_state
selected_rail
routing_rule_id
routing_rule_version
decision_timestamp
release_state.
This data is not bureaucracy. It lets the bank answer a customer complaint, an operations investigation or an audit question months later: why was this payment routed this way at that exact moment?
2. Reachability is capability data, not just a routing number
A nine-digit Routing Transit Number is necessary in many US bank-payment contexts, but an RTN by itself does not prove that a destination can receive a particular instant-payment message on a particular rail.
The bank therefore needs to distinguish at least four concepts.
Institution identity says which financial institution the RTN belongs to.
Network participation says whether that RTN is enabled on RTP or FedNow.
Capability says what the participant can do: receive customer credit transfers, send, receive Request for Payment, use liquidity-management functionality, or operate under another participation configuration.
Current operational availability says whether the bank's own route to that network and that participant capability should be treated as usable at this moment.
This is why reachability should be modeled as effective-dated reference data rather than a static lookup copied into application code.
A good record has source, version, effective_from, observed_at, capability flags and status. The customer channel should not consume an old spreadsheet directly. A bank-grade design ingests authoritative network data, validates it, publishes a controlled internal reachability service, and records which version was used for each routing decision.
Reachability is directional
A bank may be able to receive on a rail before it can send. A participant may support one message type but not another. Request for Payment receive capability is not necessarily equivalent to credit-transfer receive capability. A service provider may connect several RTNs but the capabilities remain participant-specific.
The decision therefore needs to ask a precise question, for example:
Can RTN X receive a customer credit transfer on FedNow at decision time T?
That is much stronger than:
Is bank X on FedNow?
Reachability must have freshness rules
Authoritative lists change. Participants join, change configuration and become enabled. The Clearing House states that RTP routing information is updated regularly. Federal Reserve Financial Services publishes participating FedNow RTNs and also provides a Participant List API whose stated benefit is reducing payment rejections by giving systems an updated list of RTNs enabled on the service.
A bank should define:
- ingestion frequency;
- maximum acceptable age;
- source precedence;
- effective-time handling;
- missing-update behavior;
- validation against the previous version;
- rollback procedure for corrupt reference data;
- cache invalidation;
- consumer notification when capability changes.
The dangerous design is to treat reachability as “download once and forget.”
3. RTP reachability and participant data
The Clearing House publishes RTP participants and routing/transit numbers through its RTP resources. The list represents the network reach that institutions and routing engines use to determine whether a receiving RTN is enabled for RTP processing.
The network has broad reach, but a routing engine should never infer universal reach from network-level marketing statistics. The operational question is always the destination RTN and required capability.
RTP reachability in the send journey
Before an RTP pacs.008 is constructed for release, the bank should resolve the destination routing data against its current RTP directory/reference set. A robust flow is:
beneficiary input → RTN normalization → participant/reachability lookup → account/product eligibility → bank policy → RTP candidate created.
If the RTN is not currently reachable on RTP, the system should not submit an RTP payment merely to learn that fact from a network rejection. Rejecting locally before release gives a clearer customer experience and reduces unnecessary network traffic.
Never use payment messages to search for accounts
RTP rules prohibit using payment messages simply to discover whether guessed account numbers are valid. Reachability reference data and account-validation or beneficiary-verification controls must not be confused with “trying a payment and seeing what happens.”
This matters when building smart routing. The router can ask whether a financial institution is reachable. It must not turn payment initiation into an account-enumeration mechanism.
Reachability and funding are different
An RTP receiving institution may be reachable even when the sending bank does not currently have sufficient RTP settlement liquidity. The reachability answer remains yes; the funding answer is no or insufficient. Combining these conditions produces misleading data and weak operations.
The routing engine should preserve both facts:
rtp_destination_reachable = true
rtp_funding_available = false
Then policy determines whether another pre-release rail is eligible.
4. FedNow reachability and participant data
Federal Reserve Financial Services publishes FedNow participating institutions and RTNs. The official page displayed participant/RTN data updated September 28, 2026 at this audit, but FRFS warns that the RTN list is updated irregularly and will not fully reflect all FedNow participants at any point in time. Use a governed, timestamped capability feed and apply a stale-data policy rather than treating the public list as a complete reachability oracle.
FedNow also provides a Participant List API. The official API description says it provides a daily listing of RTNs enabled on FedNow, can be called at any time, changes at the start of each cycle date, and helps reduce payment rejections by ensuring systems have an updated list of receiving RTNs.
That makes reachability integration a first-class technical component, not a spreadsheet exercise.
FedNow participant profile matters
The FedNow operating model uses participant profiles and participation types. A bank should not reduce all of that to one generic “FedNow member” flag. For credit transfers, the routing engine needs the capability relevant to the intended message and the sender's own configured profile.
A typical canonical representation could be:
network = FEDNOW
rtn = 123456789
credit_transfer_receive = true
credit_transfer_send = false/true
rfp_receive = false/true
source = FEDNOW_PARTICIPANT_LIST
source_cycle_date = YYYY-MM-DD
loaded_at = timestamp
status = ACTIVE.
API availability is not payment-network availability
The FedNow Participant List API is an information service. A successful API call does not prove that MQ connectivity for payment messages is healthy. Conversely, a temporary API issue does not necessarily mean the FedNow payment service is unavailable.
Banks should separately monitor:
- participant/reference-data ingestion;
- API connectivity;
- MQ/payment connectivity;
- bank adapter health;
- downstream posting dependencies;
- treasury/liquidity systems.
That separation is essential for accurate routing and incident response.
5. Building a bank-grade reachability service
A mature bank normally benefits from a shared reachability service rather than embedding different participant files into every payment channel.
The service should answer a deterministic question using controlled inputs and return both the answer and evidence.
Example request:
beneficiary_rtn + payment_type + amount + currency + customer/product context + timestamp
Example response:
RTP: eligible
FedNow: eligible
ACH: eligible but not instant
reason codes: RTP_RTNSOURCE_ACTIVE, FEDNOW_CT_RECEIVE_ACTIVE
source versions: ...
decision time: ...
The reachability service should not decide fraud, liquidity and all business policy by itself. Its job is narrower: provide trustworthy network capability information. The orchestration layer then combines that with limits, liquidity and health.
Data lineage is part of the functional requirement
A BA requirement that says “check if beneficiary bank supports RTP/FedNow” is incomplete. It should define:
- authoritative source;
- field mapping;
- RTN normalization;
- capability interpretation;
- ingestion schedule;
- versioning;
- effective dating;
- fallback behavior when source data is stale;
- audit retention;
- how changes are propagated to channels;
- who owns data-quality exceptions.
Stale data should degrade safely
If the latest participant list cannot be loaded, the bank needs an explicit policy. Possible policies include continuing with the last known good version for a controlled maximum period, disabling new instant sends after a freshness threshold, or requiring operations approval. The correct policy depends on risk appetite and network guidance, but the behavior must be deliberate.
Silently using indefinitely stale reachability data is not acceptable.
6. Rail selection and deterministic routing policy
When both RTP and FedNow are eligible, the bank needs a routing policy. “Choose whichever answers first” is not a policy. Neither is random selection unless that is deliberately designed and governed.
Routing policy can consider:
- destination reachability;
- transaction amount and applicable limits;
- bank funding position on each rail;
- customer/product entitlement;
- network and internal availability;
- service-provider availability;
- cost and contractual considerations;
- operational capacity;
- use-case requirements;
- risk controls;
- bank strategy and treasury policy.
The policy should be deterministic enough that the decision can be reconstructed later.
A simplified hierarchy might be:
- eliminate rails that cannot reach the destination;
- eliminate rails that do not support the required capability;
- eliminate rails where amount exceeds an effective limit;
- eliminate rails without sufficient settlement liquidity or approved funding headroom;
- eliminate rails in unavailable/degraded state according to policy;
- apply product/customer routing preference;
- select the highest-priority remaining rail;
- freeze the decision for release and write immutable routing evidence.
Routing policy must be versioned
If Treasury changes RTP funding thresholds at 14:00 or Product changes the default rail next month, historical payments must still explain the decision under the policy that existed at the time.
Store routing_policy_version and relevant limit/reference versions with the payment.
Do not reroute after network submission merely because a response is slow
The route can be changed safely only while the bank still knows the original payment has not been released. Once submission may have occurred, the bank has moved from routing into outcome determination. That boundary is central to Sections 12 and 13.
7. Liquidity models: RTP prefunding and FedNow settlement
RTP and FedNow both settle instant payments, but their funding models are different. A bank supporting both must normalize the customer experience without pretending the treasury mechanics are identical.
RTP
RTP uses a prefunded settlement model. Funding participants maintain funds supporting RTP settlement and the network provides specific funding/settlement and reconciliation material. Institutions can participate through funding arrangements that include funding agents for non-funding participants.
The practical implication is that the sending bank's RTP capability depends not only on system uptime and destination reachability, but also on the available position under its RTP funding arrangement.
FedNow
FedNow settles through Federal Reserve accounts under its service framework. Participants can use correspondent arrangements, and FedNow provides liquidity management transfers using pacs.009 for eligible participants. Official materials also provide account-balance information useful for managing master-account and subaccount positions.
Customer balance is not settlement liquidity
A customer can have $2 million available in a deposit account while the bank's instant-payment settlement position is constrained. The customer balance check and the network-liquidity check therefore serve different purposes.
A correct release gate asks both:
Does the customer have available funds?
and
Can the bank settle this payment on the chosen rail under current treasury controls?
Treasury needs forward-looking controls
Liquidity control should not wait until the network rejects or blocks activity. Banks normally define warning thresholds, reserve buffers, expected intraday/overnight demand, automated funding triggers, escalation thresholds and manual intervention procedures.
Instant payments are 24x7. Treasury design must therefore cover nights, weekends and holidays, not just normal office hours.
8. FedNow liquidity management transfers and settlement support
FedNow supports Liquidity Management Transfers (LMTs) using pacs.009 for participants with the relevant participation type. The official operating procedures define send-and-receive and receive-only LMT participation and configurable maximum transaction values.
As of November 12, 2025, the FedNow network transaction limit for customer credit transfers and payment returns is $10 million, and the network transaction limit for LMTs is also $10 million. Participants can set lower configurable limits.
LMT is not a customer payment
An LMT is a financial-institution liquidity mechanism. It should never be shown as a customer credit transfer or reconciled into customer-payment volume.
The accounting, identifiers, message family and operational ownership need to remain separate.
LMT operating hours are not identical to 24x7 customer payment availability
FedNow customer instant payments operate around the clock. LMT has defined operating hours published by Federal Reserve Financial Services. That creates a treasury design issue: the bank must understand when liquidity can be repositioned through LMT and what alternative arrangements or buffers are needed outside those periods.
A robust liquidity engine therefore stores:
current_position
available_headroom
warning_threshold
critical_threshold
forecast_outflow
forecast_inflow
lmt_window_state
settlement_agent_capacity
manual_override_state
last_balance_update_time.
Balance information and freshness
The FedNow Account Balance API is designed to support balance management for master accounts and certain subaccount information. Treasury and payment orchestration must define how stale a balance can be before release controls become conservative.
A payment engine should not assume that a five-minute-old liquidity snapshot is always safe during a surge of high-value instant payments.
9. RTP funding participants, non-funding participants and funding agents
The Clearing House publishes separate guidance for RTP funding participants and for non-funding participants/funding agents. Funding agents support participating institutions by managing settlement accounts and 24x7x365 liquidity.
This creates several operating models.
A funding participant manages its own RTP prefunded position and reconciliation responsibilities.
A non-funding participant may access RTP while relying on a designated funding agent for the funding relationship.
A funding agent supports one or more institutions and needs clear contractual, operational, limit and notification arrangements.
Funding-agent dependency must be visible to routing
If an institution depends on a funding agent, the routing layer cannot treat liquidity as an internal bank balance alone. It needs a reliable signal representing available funding capacity under that arrangement.
The bank should define:
- how funding capacity is obtained;
- update frequency;
- who can change limits;
- emergency contact paths;
- weekend/overnight escalation;
- what happens if the funding agent connection is unavailable;
- reconciliation ownership;
- how fees or funding movements are accounted;
- how participant and funding-agent records are linked.
Prefunding threshold management
A practical RTP treasury model often has several bands:
green: normal operating headroom;
amber: increased monitoring or funding action required;
red: new sends restricted or stopped according to policy;
critical: incident/escalation and controlled recovery.
The exact numbers are bank-specific. The chapter therefore does not invent a universal reserve percentage. What matters is that thresholds are explicit, approved and tested.
10. Limit hierarchy from network maximum to customer controls
A network transaction limit is only the outer ceiling. It is not automatically the amount every customer can send.
Both RTP and FedNow currently support customer credit transfers up to a network maximum of $10 million. RTP rules allow sending participants to establish lower limits for senders. FedNow states that participants may configure lower maximum transaction limits within the network maximum.
A bank should therefore calculate the effective send limit as the most restrictive applicable control.
Conceptually:
effective_limit = min(network_limit, participant_limit, bank_product_limit, customer_limit, channel_limit, account_limit, remaining_velocity_limit, risk_decision_limit, available_liquidity_headroom)
Not every organization implements that as one literal min() function, because some controls produce blocks rather than numerical ceilings. But the functional principle is correct: the customer cannot rely on the network maximum when a stricter bank control applies.
Types of limits
Network limit — maximum allowed by RTP or FedNow.
Participant-configured limit — value configured by the participating institution where the scheme permits it.
Product limit — for example consumer versus business instant-payment product.
Customer limit — based on agreement, segment, risk and onboarding.
Channel limit — mobile, online banking, API or branch-assisted initiation may differ.
Account limit — account type or account-specific restriction.
Transaction limit — maximum per payment.
Velocity limit — cumulative amount or count over a period.
Fraud/risk threshold — may block, step-up or lower permitted activity.
Liquidity limit — treasury headroom available to the rail.
FedNow participant-only risk capabilities
FedNow exposes participant-only Account Activity Thresholds and Network Intelligence capabilities. Public FRFS material describes Network Intelligence as supplemental network-level risk data that participants may use to complement their own controls. Exact thresholds, fields, codes and operating obligations require authenticated participant documentation and must not be taught as universal public rules. Instant-payment limits are therefore dynamic risk controls as well as product configuration, but the bank must obtain the applicable participant procedures.
High-value instant payments change operating expectations
A $9 million payment may fit under the network limit but has very different liquidity, fraud, approval and customer-servicing implications from a $90 payment. Banks should test high-value instant-payment behavior explicitly: maker-checker controls where applicable, fraud latency, liquidity reservation, customer confirmation, operational alerting and downstream accounting.
11. Availability, health, cutover and 24x7 operating state
Instant-payment availability is multi-layered.
The rail can be healthy while the bank's adapter is down. The bank adapter can be healthy while a fraud service is unavailable. Fraud can be healthy while customer posting is degraded. Reachability data can be current while treasury balance data is stale.
A routing engine therefore needs a service-health model richer than UP/DOWN.
Useful states include:
AVAILABLE
DEGRADED_SEND_ALLOWED
DEGRADED_RECEIVE_ONLY
SEND_SUSPENDED
UNKNOWN
MAINTENANCE_INTERNAL
RECOVERY_VALIDATION.
24x7 means change management without a payment “night”
RTP advertises continuous operation with no scheduled downtime. FedNow is also a round-the-clock service. Banks still need to patch applications, rotate certificates, update routing data and deploy rules. The solution is resilient bank architecture—active/active or controlled failover patterns, rolling deployments, blue/green releases, duplicate protection and clear operational runbooks—not an assumption that the rail will stop for maintenance.
Cycle dates and business dates matter
FedNow participant-list data changes at cycle-date boundaries. Internal accounting systems may use local business dates. RTP and FedNow continue across weekends and holidays. Reconciliation therefore cannot assume that “today” means the same thing in every system.
Store precise timestamps, timezone, network cycle date where relevant and internal accounting date separately.
12. Safe fallback before release
Fallback is safe when the bank can prove that the original route has not been released.
Examples:
Destination not reachable on preferred rail. RTP lookup says no, FedNow says yes. The router selects FedNow before creating/releasing the network payment.
Amount exceeds a bank-configured FedNow limit but is permitted under an RTP product route and all other controls pass. The route can be changed before release.
RTP funding headroom is below the bank's release threshold while FedNow liquidity is sufficient. If the payment has not entered RTP, FedNow may be selected under policy.
Preferred rail adapter is marked unavailable before submission. The router selects the eligible alternative rail.
The key invariant is:
original_rail_release_state = NOT_SENT
Only then can the bank create a new attempt on another rail without first resolving an uncertain financial outcome.
Fallback should preserve customer intent
Changing rail must not silently change important product characteristics without permission. If fallback means the payment is no longer instant—for example moving to ACH—the bank should clearly present the changed speed, availability, fees or execution expectation before authorization where required by the product design.
Re-run controls after route change
A rail change can alter limits, liquidity, data requirements, fraud signals and customer disclosures. The payment should therefore pass the applicable controls for the newly selected route rather than simply reusing every decision from the abandoned candidate.
13. Unsafe fallback after release and uncertain outcomes
The most dangerous routing defect in instant payments is automatic fallback after an ambiguous timeout.
Imagine the bank sends an RTP payment. The connection drops before the sender receives the final response. The customer sees a spinner. A badly designed router says, “RTP timed out, so send it on FedNow.” If the RTP payment actually settled, the beneficiary can receive the money twice.
That is not fallback. It is uncontrolled duplicate-payment creation.
UNKNOWN must be a real state
The payment engine needs a state such as:
SENT_OUTCOME_UNKNOWN
or
UNCERTAIN
When that state is entered, routing is frozen. Operations or automated recovery must determine the original outcome using network evidence, message identifiers, reports, account postings and reconciliation data.
Only when the bank can prove the first payment did not settle and is not capable of later settlement can a new payment be considered under controlled recovery rules.
Timeout is not rejection
A timeout is an observation about communication. A rejection is a known payment outcome. Those are not equivalent.
The routing model should distinguish at least:
NOT_SENT
SUBMISSION_STARTED
SENT_AWAITING_RESPONSE
ACCEPTED_OR_SETTLED
REJECTED_CONFIRMED
OUTCOME_UNKNOWN.
Fallback belongs only before the system crosses the release boundary, or after a formally confirmed non-settlement outcome where product rules permit a new attempt.
14. Reconciliation, reporting, treasury and operational evidence
Reachability and routing decisions create operational evidence even before settlement. A bank should preserve enough data to reconcile decision, submission, network outcome, settlement and customer posting.
For each payment, useful evidence includes:
- candidate rails;
- reachability results and source versions;
- effective limits;
- liquidity snapshot or release decision;
- health state;
- selected rail and reason;
- fallback reason if selected before release;
- network identifiers;
- settlement evidence;
- customer debit and beneficiary-credit evidence where available;
- final reconciliation state.
Treasury reconciliation
Treasury should reconcile network/funding positions to payment activity and liquidity movements. RTP prefunding and FedNow account/LMT activity should be separated operationally while contributing to a consolidated liquidity view.
Important break types include:
payment settled but liquidity ledger not updated;
liquidity movement recorded but not reflected in treasury position;
funding-agent statement differs from participant ledger;
duplicate funding movement;
stale position used by release control;
unexpected high-value outflow concentration.
Routing reporting
Management reporting should answer questions such as:
- percentage of instant payments where both rails were reachable;
- rail-selection distribution;
- payments not offered because destination was unreachable;
- payments blocked by bank/customer limits;
- payments blocked by liquidity thresholds;
- fallback rate and reasons;
- uncertain-outcome rate;
- stale reachability incidents;
- funding threshold breaches;
- high-value instant-payment volumes.
Those metrics help distinguish customer adoption problems from technical or treasury constraints.
15. Real-bank architecture, controls and testing
A strong implementation separates source-of-truth services while keeping orchestration fast.
Typical components are:
channel/API layer — captures customer intent and displays available options;
beneficiary service — stores payee/routing information and verification evidence;
reachability service — provides versioned RTP/FedNow capability data;
limit service — calculates applicable product/customer/channel/velocity controls;
fraud/risk service — provides release decision and risk thresholds;
treasury/liquidity service — provides rail funding state and headroom;
rail-health service — provides operational availability;
routing engine — selects a route under versioned policy;
payment orchestrator — freezes route, creates rail-specific message and controls state transitions;
RTP/FedNow adapters — manage network-specific messaging;
ledger/core — customer balance reservation/debit/posting;
reconciliation/evidence store — proves financial and technical outcome.
Controls that should be explicit
The bank should prevent:
- routing with stale participant data beyond policy;
- amount above effective limit;
- send with insufficient approved liquidity headroom;
- fallback after uncertain submission;
- duplicate release across rails;
- route changes after customer authorization when material product terms change without required re-authorization;
- silent use of a degraded rail contrary to policy;
- missing routing-decision evidence.
Testing must be state-based
Happy-path testing is not enough. Required scenarios include:
- RTP-only reachable destination;
- FedNow-only reachable destination;
- both reachable;
- neither reachable;
- reachability changes between beneficiary setup and payment execution;
- stale reference data;
- participant-list ingestion failure;
- value exactly at and one cent above every relevant limit;
- customer limit below network limit;
- liquidity just above and just below treasury threshold;
- simultaneous high-value sends consuming shared liquidity;
- funding-agent connectivity failure;
- FedNow LMT unavailable while customer sends continue;
- preferred rail unavailable before release;
- timeout before any submission;
- timeout after possible submission;
- delayed network response;
- duplicate channel retry;
- routing-policy version change during a long-lived corporate approval;
- midnight/cycle-date transition;
- weekend/holiday treasury conditions;
- disaster-recovery failover.
The pass condition is not only “payment succeeded.” It is that the route, financial outcome and evidence are correct under every state.
16. End-to-end cases, BA checklist and authoritative references
Case 1 — both rails reachable, normal value
A business sends $18,500 to a beneficiary whose RTN is enabled on both networks. Both rail adapters are healthy. RTP prefunding is in the green band; FedNow settlement headroom is also sufficient. All customer and fraud limits pass.
The routing engine applies the bank's versioned policy and selects RTP. It stores both reachability results, the policy version, liquidity decision and selected route. The payment is released once. No later route comparison is allowed to create a duplicate attempt.
Case 2 — preferred rail unreachable
The customer's beneficiary bank is not reachable on the preferred RTP route but is present and enabled for FedNow customer-credit receipt. The system eliminates RTP before release, confirms FedNow amount/limits/liquidity and presents/sends through FedNow.
This is genuine fallback routing because the first rail was never released.
Case 3 — liquidity constraint
Both rails can reach the beneficiary, but the bank's RTP prefunded position has crossed its red release threshold. Treasury has not yet replenished it. FedNow has sufficient approved settlement capacity.
The routing policy selects FedNow before release. Reporting records the reason as RTP_LIQUIDITY_POLICY_BLOCK, not RTP_UNREACHABLE.
Case 4 — ambiguous timeout
The RTP adapter submits a payment and the connection fails before the bank receives a definitive response. FedNow is also reachable.
The correct action is not to send through FedNow. The payment moves to OUTCOME_UNKNOWN; recovery checks RTP evidence and reconciliation. Customer communication reflects that the bank is confirming the outcome. Only after non-settlement is definitively established can a controlled new payment be considered.
Case 5 — network maximum versus customer maximum
A corporate customer requests $8.5 million. The current network maximum is $10 million on both RTP and FedNow, but the customer's approved instant-payment limit is $5 million.
The bank blocks or routes to an alternative authorized product according to product design. It does not allow the payment merely because the network could technically carry it.
BA checklist
A complete Chapter 25 requirement set should be able to answer:
- What are the authoritative RTP and FedNow reachability sources?
- How fresh must the data be?
- How are RTN and capability changes versioned and distributed?
- Which exact capability is required for each payment type?
- How are RTP and FedNow liquidity states obtained?
- What treasury thresholds control send eligibility?
- How do funding-agent arrangements affect RTP capacity?
- How are FedNow LMT and customer-payment liquidity separated?
- What is the current network limit on each rail?
- What lower participant, bank, product, customer, channel and velocity limits apply?
- How are fraud/risk thresholds integrated without confusing them with network limits?
- What is the deterministic rail-selection hierarchy?
- Which policy version is stored with the payment?
- At exactly what state is routing frozen?
- What conditions permit safe pre-release fallback?
- What conditions force
OUTCOME_UNKNOWN and prohibit fallback?
- How are duplicate cross-rail attempts prevented?
- How are reachability, routing and liquidity decisions reconciled and reported?
- What happens when participant data, liquidity data or health data is stale?
- How are nights, weekends, holidays, cycle dates and failover tested?
Authoritative references
Federal Reserve Financial Services — FedNow Service Participants and Service Providers
https://www.frbservices.org/financial-services/fednow/organizations/
Federal Reserve Financial Services — FedNow APIs, including Participant List and Account Balance
https://www.frbservices.org/fedline-solutions/fedline-developer/fednow-apis
Federal Reserve Financial Services — FedNow Service Operating Circulars and Operating Procedures
https://www.frbservices.org/resources/rules-regulations/operating-circulars.html
Federal Reserve Financial Services — Customer Credit Transfer and Liquidity Management Transfer network limit increases, November 12, 2025
https://www.frbservices.org/news/communications/111225-fednow-transaction-limit-increase
Federal Reserve Financial Services — FedNow Service operating hours
https://www.frbservices.org/resources/financial-services/fednow/operating-hours
The Clearing House — RTP Network
https://www.theclearinghouse.org/payment-systems/rtp
The Clearing House — RTP Participants and Routing/Transit Numbers
https://www.theclearinghouse.org/payment-systems/rtp/rtn
The Clearing House — RTP Document Library, including current Operating Rules, Participation Rules, prefunded settlement, funding-agent and reconciliation material
https://www.theclearinghouse.org/payment-systems/rtp/document-library
The Clearing House — RTP Funding Agents
https://www.theclearinghouse.org/payment-systems/rtp/Funding-Agents
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.