USA Instant Payment Architecture. A master practitioner guide to the complete US instant and faster-payments landscape, spanning RTP, FedNow, Zelle, push-to-card and debit-network faster payments, alternative network models, RfP, wallets and business use cases, with bank architecture, controls, settlement, liquidity, routing, status, reconciliation, resilience and 24x7 operations.
Instant payments are often described as payments that move in seconds. That description is true, but it is not enough for a bank. A real instant-payment service is an always-on operating model in which customer authentication, account validation, fraud and sanctions controls, reachability, routing, ISO 20022 message creation, network processing, interbank settlement, beneficiary posting, status reporting, liquidity, reconciliation and exception handling all have to work continuously and coherently.
That is the focus of Chapter 21.
The United States currently has two major bank-account instant-payment infrastructures: The Clearing House RTP® network and the Federal Reserve’s FedNow® Service. Both support 24/7/365 instant credit transfers and ISO 20022 messaging, but their operating, settlement, participation, liquidity and network-control models are not identical. A bank should therefore avoid building two disconnected instant-payment products. The stronger architecture is a common internal instant-payments capability with rail-specific adapters and rules at the network boundary.
This chapter is deliberately architectural. Chapter 22 will go deeply into RTP credit transfers. Chapter 23 will do the same for FedNow credit transfers. Chapter 24 will focus on Request for Payment. Chapter 25 will go deeper into reachability, liquidity, limits and fallback routing. Here we build the bank-wide architecture that makes those later mechanics understandable.
A useful end-to-end model is:
customer intent → authentication and entitlement → payment capture → validation and enrichment → fraud/compliance decision → reachability and route decision → ISO 20022 orchestration → RTP or FedNow gateway → receiving-bank validation and acceptance decision → network settlement → beneficiary posting and availability under the applicable rules → confirmation → accounting, reconciliation, reporting and evidence.
The key lesson is simple: an instant-payment architecture must be designed around financial state, not just message speed. A message can be accepted by a channel, validated internally, submitted externally, accepted by a network, settled interbank, posted to the beneficiary, reported to the customer and reconciled financially at different instants. The architecture must preserve those distinctions even when the whole journey completes within seconds.
For a roughly 60-minute core session, spend about 35 minutes on Sections 1–5, Sections 7–10 and Sections 11–13. For the next 10 minutes, use the chapter’s three diagrams to connect network participation, bank state ownership and settlement evidence. Use 10 minutes to work through one case in Section 16, then spend the final 5 minutes explaining: Which system should prevent a second payment when the first instruction's outcome is unknown? 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
- What an instant-payment architecture really is
- The US instant-payment landscape and the role of RTP and FedNow
- Participants, access models and architectural ownership
- The sending-bank architecture from customer intent to release
- The receiving-bank architecture from network receipt to funds availability
- Canonical payment model and ISO 20022 message architecture
- Reachability, routing and rail-selection architecture
- Clearing, settlement and financial-state architecture
- Liquidity and 24x7 funding architecture
- Fraud, sanctions, limits and payment-release controls
- Statuses, confirmations and customer-visible truth
- Exceptions, uncertain outcomes, returns and recovery architecture
- Reconciliation, accounting and reporting architecture
- Resilience, observability and continuous operations
- Real-bank implementation model, data ownership and governance
- End-to-end cases, BA checklist, testing and authoritative references
1. What an instant-payment architecture really is
An instant-payment architecture is the set of business capabilities, systems, interfaces, controls, data models and operating processes that allow a bank to send and receive account-to-account payments within seconds at any time of day while preserving financial integrity.
The phrase within seconds is important, but at any time of day changes the architecture even more profoundly. Traditional bank processing often assumes business-day boundaries, overnight windows, end-of-day batches, staffed operations periods and maintenance windows. Instant payments challenge every one of those assumptions.
If a customer initiates an eligible payment at 02:17 on a Sunday, the bank may need to authenticate the customer, check the account, make a fraud decision, identify a reachable destination, select a rail, create a compliant message, obtain external acceptance, settle the interbank obligation, update the customer ledger, send a confirmation and reconcile the resulting financial events without waiting for Monday morning.
That means instant payments are not simply an additional clearing adapter attached to a legacy payment engine.
A mature architecture normally contains at least the following logical capabilities:
- customer and channel initiation;
- authentication, authorization and entitlement;
- account and product validation;
- canonical payment capture;
- fraud and financial-crime controls;
- participant reachability and routing;
- rail-specific message transformation;
- external network connectivity;
- real-time settlement awareness;
- receiving-side acceptance and posting;
- customer status and notification;
- liquidity management;
- accounting and general-ledger integration;
- reconciliation;
- exception and investigation handling;
- audit, telemetry and operational monitoring.
The physical systems implementing those capabilities differ by bank. One bank may use a centralized payment hub with microservices around it. Another may use a vendor instant-payments engine. A third may operate separate RTP and FedNow gateways but share fraud, ledger and customer-channel services. The architecture should be judged by whether the responsibilities are clear, not by the number of boxes on the diagram.
Architecture begins with the customer promise
Before choosing technology, define the service promise.
Does the bank promise that the beneficiary will normally receive funds within seconds? Is the service available to consumers, small businesses and corporates? Can customers send as well as receive? What transaction limits apply? Which accounts are eligible? Are scheduled payments allowed? Is Request for Payment supported? Does the bank offer only RTP, only FedNow or both? What happens if the preferred rail is unavailable or the destination institution is not reachable?
Those are product questions, but they drive architecture.
A product promise of “24/7 instant transfer” means the underlying ledger, fraud services, network connectivity, notification services and operational support cannot all remain business-hours-only.
Instant is not the same as synchronous everywhere
The customer experience may feel synchronous: press send, receive an answer. Internally, however, an architecture may use event-driven processing, durable queues and distributed services. The design objective is not to eliminate asynchronous technology. The objective is to ensure that the financial path is deterministic, low-latency, observable and safe.
A real-time orchestration service may synchronously wait for a network response while simultaneously writing events to an audit stream and downstream reporting bus. The customer does not need every reporting system to finish before seeing success. But the system must know which downstream work can complete later and which event is required before the payment may be called complete.
That distinction prevents slow peripheral processes from blocking payment execution while still preserving financial evidence.
2. The US instant-payment landscape and the role of RTP and FedNow
The U.S. instant-payment landscape is unusual because two national-scale bank-account instant-payment infrastructures coexist.
The RTP network, operated by The Clearing House, launched in 2017. It operates 24/7/365, uses ISO 20022 messaging and provides immediate final settlement under its network model. The network supports credit transfers, Request for Payment and other nonvalue messages. The current network transaction limit is $10 million.
The FedNow Service, operated by the Federal Reserve Banks, launched on July 20, 2023. It is a 24x7x365 interbank real-time gross settlement service with integrated clearing functionality. It uses ISO 20022 and settles obligations by generating entries to Federal Reserve Bank master accounts. Its customer credit transfer and payment-return network limits increased to $10 million effective November 12, 2025. Participants may choose lower internal limits.
Those facts matter architecturally because a bank can no longer treat “instant” as the name of one rail.
One customer proposition, multiple infrastructures
A customer may simply see “Instant payment.” The bank may have to decide whether RTP or FedNow is the available or preferred route.
The decision can depend on:
- whether the receiving routing number is reachable on one or both networks;
- the sending bank's participation and connection model;
- customer and product eligibility;
- transaction value and bank-set limits;
- liquidity and funding position;
- service availability;
- internal pricing or commercial policy;
- message or feature requirements;
- operational risk rules.
That creates a routing problem similar in concept to other multi-rail payment environments, but with far less tolerance for manual intervention because the service is expected to complete within seconds.
Do not hide the rail completely from operations
Customers do not necessarily need to know which rail was chosen. Operations absolutely does.
Every transaction should retain the selected network, receiving participant identifier or routing number, network reference, timestamps, settlement evidence, message version and response codes. Otherwise investigations become difficult because two payments that looked identical at initiation may have followed different rulebooks and settlement models.
Instant payment is a credit-push architecture
Both networks fundamentally support credit-push instant payments. The payer side authorizes the transfer of funds to the receiving account. Request for Payment can initiate a conversation that leads to a credit push, but the request itself is not the movement of funds.
This matters for control design. A bank should not reuse ACH-debit assumptions about post-transaction return rights. Instant payments emphasize strong pre-release controls because the sending bank should assume that an accepted, settled credit transfer cannot simply be cancelled like an unprocessed batch item.
3. Participants, access models and architectural ownership
The simplest instant-payment picture has a sender, a sending bank, a network, a receiving bank and a receiver. Production architecture often includes more participants.
A sending institution may connect directly to a network or use a service provider. A participant may use a funding agent, settlement agent, correspondent arrangement or technology provider depending on the network and participation model. A processor may host the instant-payment gateway while the bank remains responsible for customer accounts, controls and regulatory obligations.
For FedNow, eligible organizations can participate through the Federal Reserve service framework. The Federal Reserve publishes live lists of participating institutions, settlement agents, liquidity providers and certified service providers. FedNow settlement ultimately uses Federal Reserve Bank master-account entries, directly or through the applicable participant/settlement arrangements.
For RTP, financial institutions can participate directly or through third-party service providers, and the network supports funding participants, non-funding participants and funding-agent arrangements within its prefunded settlement framework.
Separate business ownership from technical performance
Suppose a processor hosts the network connection. The processor may receive the pacs.008 response, but the bank still needs to decide what that response means for the customer account and product state.
A useful responsibility map is:
customer channel — captures intent and displays status;
account-holding bank — owns customer account eligibility, funds and posting;
payment orchestration — owns internal workflow and route decision;
fraud/compliance services — own risk decisions according to bank policy;
network gateway or processor — performs network-specific connectivity and message exchange;
settlement/funding function — ensures the institution can support the selected rail financially;
operations and investigations — own abnormal outcomes and recovery workflows;
reconciliation/accounting — prove that external settlement and internal books agree.
Participation capability is not one Boolean
A routing number may be reachable for receive-only service but not necessarily for every optional feature. A bank may be enabled to receive instant payments before enabling sending. Request for Payment may have separate enrollment or capability requirements. Network participation data therefore needs to be modeled as a capability profile, not simply instantPayments=true.
A realistic reachability record might contain:
network + routing number + send/receive capability + RfP capability + effective timestamp + source + status + last refresh.
That record must be governed because stale reachability data can create unnecessary rejects or unsafe routing assumptions.
4. The sending-bank architecture from customer intent to release
The sending side is where most preventative control work occurs.
A customer might initiate through mobile banking, online banking, a corporate portal, an API, a treasury workstation or an embedded-finance experience. Regardless of channel, the bank should normalize the instruction into one controlled payment model before network release.
The sending flow usually contains the following stages.
Capture and customer authority
The channel captures debtor account, amount, beneficiary information, payment purpose, remittance data and any customer references. The bank authenticates the customer or calling application and validates entitlements.
For a consumer this may involve device binding, multifactor authentication and behavioral risk. For a corporate it may involve user roles, transaction entitlements, dual approval, API credentials or host-to-host controls.
The important architectural rule is that channel authentication evidence must travel with the payment decision. Downstream fraud or operations teams may need to know how strongly the customer was authenticated, whether the device was new, whether approvals were dual-controlled and whether the payee was recently changed.
Account and product validation
Before route selection, the bank normally verifies that:
- the debit account exists and is open;
- the account/product is eligible for instant sending;
- the customer is entitled to use it;
- the currency is USD for domestic RTP/FedNow credit transfers;
- the amount is within product, customer and network limits;
- sufficient available funds or permitted credit exists;
- the requested execution time is valid for an immediate service;
- required beneficiary and remittance data is present.
These validations should be deterministic and fast.
Fraud and compliance decision
Instant payments compress the intervention window. Fraud decisioning therefore needs to happen before release and with low latency.
Signals can include customer behavior, device risk, new payee, unusual amount, velocity, beneficiary risk, account takeover indicators, mule-account intelligence, prior fraud alerts and transaction context. Sanctions screening and other compliance controls should use the payment data required by bank policy and applicable obligations.
A design should avoid one generic RISK_OK result. The orchestration layer should know whether fraud, sanctions and other required controls each completed, which rules were applied and whether the decision was automated or manually overridden.
Reachability and route selection
Once the payment is eligible, the routing service determines whether the receiving institution is reachable through RTP, FedNow or both.
If only one network is available, routing is straightforward. If both are available, bank policy decides the preferred route. That policy should be explicit and auditable.
Network message creation and release
The canonical payment is transformed into the network-specific ISO 20022 message according to the relevant implementation guide. The rail adapter should add or map network-required identifiers without losing the bank's internal payment identity.
At release, the bank should freeze the financially relevant instruction. Changes after this point should create a new controlled action rather than silently mutate the sent payment.
5. The receiving-bank architecture from network receipt to funds availability
Receiving is sometimes treated as easier because the payment has already been approved by the sender. That is a mistake.
A receiving bank must process an external instant payment within seconds and make the correct posting decision without weakening controls.
A robust receiving flow is:
network receipt → message validation → participant/account validation → receiving-side risk controls → posting decision → customer ledger credit → immediate funds availability → response/confirmation → customer notification → reconciliation and reporting.
Validate the message, but do not duplicate the network blindly
The network has already performed its own message-level and participant-level validation. The receiving bank still needs to validate what is necessary for its own systems: message integrity, required identifiers, destination account, duplicate protection, product eligibility and internal posting rules.
The receiving platform should not perform expensive unnecessary transformations that jeopardize latency. At the same time, it should not assume that every network-accepted message can automatically be posted to every customer account.
Examples of receiving-side problems include:
- account closed;
- account blocked or legally restricted;
- internal account mapping failure;
- duplicate internal processing;
- unavailable core ledger;
- beneficiary-account mismatch under bank policy;
- fraud or compliance concern requiring the specific treatment permitted by rules and law.
Posting and availability must be coupled carefully
The customer promise of instant payment depends on immediate access to funds when the transfer is completed under the network rules, subject to applicable exceptions.
Architecture should therefore avoid a design in which the external payment settles instantly but the customer credit waits in a legacy hourly posting batch.
The beneficiary posting service must be part of the real-time path.
Receiving confirmation is part of the product
The sending bank needs a definitive external outcome. The receiving bank therefore has to respond according to the network message flow within the required timing.
Internally, the receiving system should create the response from authoritative posting state rather than from a gateway assumption. If the gateway says “message received” but the ledger failed, the bank should not generate a success state that implies customer credit occurred.
6. Canonical payment model and ISO 20022 message architecture
Both RTP and FedNow use ISO 20022, which creates an opportunity for a common internal architecture. It does not mean the two networks are message-identical.
The strongest approach is to maintain a canonical instant-payment object inside the bank and map it to each network's implementation rules at the edge.
A canonical object can include:
- bank payment identifier;
- end-to-end/customer reference;
- debtor and debtor account;
- creditor and creditor account;
- amount and currency;
- sending and receiving financial institution identifiers;
- remittance information;
- purpose/category information where used;
- initiation channel and authentication context;
- product and service level;
- selected rail;
- network message identifiers;
- settlement state;
- posting state;
- customer-visible status;
- timestamps for each major lifecycle event.
ISO 20022 is a business-data model, not just XML
The architecture should preserve structured data internally. If rich ISO 20022 data is flattened into a legacy description field before screening, reporting or reconciliation, the bank loses much of the value of the standard.
At the same time, the bank should not copy every network XML element into every internal table. The canonical model should hold business data the bank needs, while the raw sent and received network messages are retained for evidence and troubleshooting according to retention policy.
Important message families
At architecture level, FedNow uses ISO 20022 messages including customer credit transfers, payment returns, financial-institution liquidity transfers, Request for Payment and reporting/system messages. The Federal Reserve's current documentation identifies pacs.008, pacs.004 and pacs.009 as value messages in the FedNow operating model.
RTP also uses ISO 20022 for credit transfers, Request for Payment, response and related messaging under its published message specifications.
Chapter 22 and Chapter 23 will cover the detailed message flows. Chapter 21's design point is that the bank should have a message-governance layer controlling schema versions, implementation-guide versions, validation rules, mapping rules and backward/forward change impact.
Identity must survive translation
A transaction may have a customer reference, internal payment ID, network message ID, end-to-end ID, instruction ID and reconciliation reference.
Do not choose one and discard the rest.
The bank needs a correlation model that can answer, days later: which customer instruction produced this network message, which settlement event resulted, which ledger postings were created and which customer notification was sent?
7. Reachability, routing and rail-selection architecture
Routing is the architectural brain of a multi-network instant-payment capability.
Before sending, the bank needs current participant reachability information. FedNow publishes participating routing numbers, and RTP publishes participating financial institutions/routing numbers. Banks and processors typically ingest and normalize such information into internal reference data.
The route decision should be explainable
A routing engine may evaluate:
- Is the destination routing number valid?
- Is it reachable on RTP?
- Is it reachable on FedNow?
- Is the sending bank enabled for the required direction on those networks?
- Does the customer/product allow the rail?
- Is the amount within the bank's configured limit?
- Are required features supported?
- Is the rail operational and available?
- Is liquidity/funding sufficient?
- Which route is preferred by bank policy?
The result should not simply be RTP or FEDNOW. Store a routing decision record containing the inputs, selected route, reason and timestamp.
Fallback is not automatic retry
If the preferred rail is unavailable before external submission, policy may allow selection of another eligible instant rail.
After a payment has been submitted and the outcome is uncertain, automatic switching to another rail can create a duplicate payment. The architecture must distinguish pre-send fallback from post-send uncertainty.
This distinction is so important that it should be coded into the payment state machine.
A safe model is:
ROUTE_SELECTED → RELEASED_TO_RAIL → NETWORK_OUTCOME_KNOWN.
Fallback may be allowed before RELEASED_TO_RAIL. Once released, a second route should not be used unless the first outcome is definitively known to be non-executed and bank rules permit a new submission.
8. Clearing, settlement and financial-state architecture
Instant payment systems combine message processing and settlement more tightly than traditional batch systems, but architecture still needs to distinguish clearing logic from settlement truth.
FedNow is an interbank real-time gross settlement service with integrated clearing functionality. It settles by generating entries to Federal Reserve Bank master accounts under its participation and settlement arrangements.
RTP uses a prefunded settlement model. Participants and funding agents operate under rules governing prefunded positions and the network's settlement account structure.
The two models differ, but the bank's internal requirement is similar: do not credit or confirm based on assumption. Use authoritative network outcome and internal posting state.
Financial state must be immutable enough to reconstruct
A useful sending-side state model can include:
CAPTURED → VALIDATED → CONTROL_APPROVED → ROUTED → RELEASED → NETWORK_ACCEPTED → SETTLED → CUSTOMER_CONFIRMED → RECONCILED.
The exact statuses will differ by implementation, but each should represent a real event.
If the network rejects the message, the payment should move to a terminal rejected state with the reason captured. If settlement occurs, the original transaction should not later be edited back to a pre-send state.
Sending debit timing matters
Banks need a consistent accounting model for when the payer's account is debited or funds are reserved relative to external release and settlement.
Possible designs include placing a real-time hold before release and converting it to a posted debit when external execution succeeds. Another architecture may post the debit as part of an atomic internal transaction before network send, with compensating logic for a definitive pre-settlement rejection.
The chosen pattern must avoid two dangerous outcomes:
- external settlement succeeds but payer debit does not occur;
- payer debit remains final even though the network definitively rejected before settlement.
This is a financial-integrity design question, not merely a UI question.
Receiving credit timing matters equally
On the receiving side, once the network payment is accepted and the bank is obligated to make funds available under the relevant rules, the posting service must update the beneficiary account immediately.
If the core cannot post, the architecture needs an explicit contingency model rather than pretending success.
9. Liquidity and 24x7 funding architecture
Instant payments turn liquidity into a continuous technical requirement.
A bank can receive payments at any time and may need to send large payments at any time. The current network transaction limits of both RTP and FedNow are up to $10 million, although institutions may configure lower internal limits. That makes treasury and funding integration important even for an architecture originally designed for consumer payments.
RTP prefunding
RTP's settlement architecture depends on prefunded positions. A bank or its funding arrangement must ensure adequate position to support sending. The payment engine therefore needs access to reliable liquidity information or an authoritative send-eligibility signal.
If the position is insufficient, the correct response is not to let the payment disappear into a retry loop. The architecture should place the instruction into a defined non-released state or reject it according to product rules.
FedNow settlement and liquidity management
FedNow settles through Federal Reserve master-account entries and supports liquidity management transfers using pacs.009 within defined LMT operating hours. FedNow's instant payment processing continues 24/7 across its funds-transfer business days, while LMT processing hours have specific windows.
This means treasury systems need to understand that payment availability is continuous but every liquidity tool may not have identical hours.
Liquidity controls in the route decision
A sophisticated router may consider liquidity before selecting a rail, but this must be carefully governed. Liquidity should not cause unpredictable customer outcomes.
For example, if both networks can reach the beneficiary, the bank may prefer the rail on which it has stronger available position. But policy should specify whether that is allowed, how often position data refreshes and what happens if liquidity changes between route decision and release.
Continuous treasury monitoring
Treasury and operations need dashboards showing, where applicable:
- available/prefunded position;
- projected outgoing demand;
- incoming credits;
- high-value pending instructions;
- threshold alerts;
- funding actions;
- settlement-agent or funding-agent status;
- rail availability.
The instant-payment engine should produce events that treasury can consume without delaying the payment path.
10. Fraud, sanctions, limits and payment-release controls
Instant-payment controls must operate before irreversible financial action whenever possible.
The architecture should treat controls as a set of explicit services and decisions rather than one black-box check.
Fraud decisioning
Fraud systems need low-latency access to customer, account, device, payee and behavioral signals. The decision should be returned within the product SLA.
Common instant-payment risk patterns include:
- account takeover;
- authorized push-payment scams;
- mule-account funding;
- rapid account draining;
- new-beneficiary fraud;
- unusual high-value activity;
- compromised API credentials;
- repeated attempts just below customer limits.
The control engine may approve, decline, challenge or hold according to bank policy. A manual hold is difficult for a product promised as instant, so the service design must state clearly whether a held payment remains an instant-payment instruction or becomes a separate reviewed workflow.
Sanctions and compliance
Banks must apply applicable sanctions and financial-crime controls using the data and processes required by their legal and risk frameworks. The architecture should preserve structured party and institution data so screening can be performed consistently.
A time-critical payment should never justify silent bypass of a required control.
Layered limits
There can be several limits at once:
- network maximum;
- bank rail limit;
- product limit;
- customer limit;
- account limit;
- user entitlement limit;
- daily/velocity threshold;
- fraud-engine dynamic limit.
The orchestration layer should know which limit caused a rejection. A generic LIMIT_EXCEEDED status is insufficient for operations and customer service if the bank cannot identify the governing rule.
Release gate
Before the network adapter transmits the value message, the orchestration service should be able to assert that all mandatory controls completed successfully.
A strong release record includes payment version, route, control outcomes, limit decision, timestamp, releaser/system identity and message hash or equivalent integrity evidence where appropriate.
11. Statuses, confirmations and customer-visible truth
Instant payments create a temptation to compress every state into SUCCESS or FAILED. That is dangerous.
The customer wants a simple answer. The bank needs a precise state model.
A practical internal model distinguishes:
- instruction received;
- customer authorization complete;
- validation complete;
- risk controls complete;
- route selected;
- released externally;
- network accepted/rejected;
- settlement completed;
- beneficiary posting confirmed where available through the rail flow;
- sender customer notified;
- receiving customer notified;
- reconciliation complete.
Customer status should map to real financial truth
A customer-facing status such as Completed should map to an internally defined event. It should not mean “we sent the message and have not heard otherwise.”
For an instant payment, the strongest completed state normally depends on definitive network outcome and the bank's interpretation of the network flow, not just transport delivery.
If an outcome is uncertain because connectivity failed after submission, the customer-facing status should not falsely show failed if the payment might have settled. A state such as Processing — confirmation pending may be operationally safer, depending on product design.
Timestamps matter
Store separate timestamps for:
- customer initiation;
- bank acceptance;
- external submission;
- network response;
- settlement;
- customer debit;
- beneficiary credit/posting event if known;
- notification;
- reconciliation.
These timestamps allow SLA measurement and incident reconstruction.
12. Exceptions, uncertain outcomes, returns and recovery architecture
Instant does not mean exception-free. It means exceptions have less time to be resolved before financial consequences become final.
The most important architectural distinction is between pre-release exception, definitive network rejection, uncertain outcome, and post-settlement recovery.
Pre-release exceptions
Examples include invalid account data, unreachable destination, fraud decline, insufficient funds, limit breach or missing mandatory fields. These are safest because no external financial action occurred.
The payment can be corrected or rejected according to product rules.
Definitive network rejection
If the network clearly rejects the payment before settlement, the bank can return the instruction to a rejected state and release any internal reservation according to its accounting design.
The external reason code should be mapped to an internal reason without losing the original network response.
Uncertain outcome
This is one of the hardest production scenarios.
Imagine the bank submits a payment and then loses connectivity before receiving the network response. The payment may have settled, or it may not have been accepted.
The unsafe response is immediate retransmission.
The architecture should move the item into an UNKNOWN/UNCERTAIN state, use network inquiry or operational evidence to establish the outcome and prevent duplicate release until truth is known.
Post-settlement return or recovery
Once an instant payment has been accepted and settled, it is not treated like an unprocessed instruction that can simply be cancelled. Networks provide return or return-request mechanisms under their rules, but those are new controlled processes.
Chapter 26 will go deeper into instant-payment exceptions, fraud and return-of-funds requests. Here the architectural rule is that the original payment remains historically settled while any returned value is represented as a linked new financial event.
Case management linkage
The payment engine should be able to create or link an investigation case containing:
- original payment ID;
- rail and network references;
- customer communication;
- fraud/compliance context where permitted;
- return request/reference;
- returned payment ID if funds come back;
- financial reconciliation impact;
- closure reason and evidence.
13. Reconciliation, accounting and reporting architecture
Instant payments require reconciliation just as much as ACH or wires. The difference is that the service operates continuously.
A bank needs to reconcile at several layers.
Transaction reconciliation
For each sent payment:
customer instruction = internal payment record = network outcome = settlement event = customer debit = reporting event.
For each received payment:
network receipt = settlement event = beneficiary posting = availability = customer reporting.
Any missing link becomes an exception.
Settlement reconciliation
The bank must prove that its network settlement position agrees with the relevant external settlement records and internal settlement-account accounting.
The exact process differs between RTP's prefunded model and FedNow's Federal Reserve account model, but the control objective is the same: external settlement truth and internal books must agree.
General ledger architecture
Payment accounting may involve customer accounts, settlement accounts, fee accounts, suspense accounts and intersystem clearing accounts.
A good design avoids using suspense as a routine substitute for missing state. Suspense should be controlled, aged, owned and reconciled.
Continuous reconciliation plus formal close
Because instant payments operate 24/7, banks increasingly need continuous reconciliation rather than waiting for a single overnight batch.
That does not eliminate business-day or accounting close processes. It means breaks should be detected quickly throughout the day and then formally carried into the institution's financial-close controls.
Customer and corporate reporting
Instant payment reporting can appear through mobile transaction history, online banking, APIs, account statements and corporate cash-management reports. Rich remittance information should be preserved where useful so corporates can automate cash application.
A payment is operationally incomplete if it settled but the customer cannot identify what it was for.
14. Resilience, observability and continuous operations
24/7 availability forces architecture teams to rethink maintenance, failover and monitoring.
A service cannot advertise continuous instant payments if its fraud engine is routinely offline for Sunday maintenance or its core ledger needs a multi-hour unavailable batch window.
Design for no single point of failure on the critical path
Critical components include:
- channel/API ingress;
- authentication;
- payment orchestration;
- fraud/compliance decision services;
- reachability reference data;
- network gateway;
- core ledger/posting service;
- settlement/funding interface;
- status store.
High availability should be designed across zones or sites according to the institution's resilience requirements.
Idempotency everywhere value can move
Every retryable interface should use durable transaction identity and idempotency controls.
Retries are normal in distributed systems. Duplicate payments are not.
A gateway timeout must never automatically cause a new payment with a new identity to be released. The retry strategy should distinguish transport retry from business re-initiation.
Observability must follow the payment
Operations should be able to search by customer reference, internal payment ID, network message ID, routing number, account and time window.
Telemetry should capture latency at each stage:
- channel-to-orchestrator;
- validation;
- fraud/compliance;
- routing;
- network round-trip;
- ledger posting;
- notification;
- reconciliation.
This allows teams to know whether a slowdown is internal or external.
Continuous operations model
A bank needs ownership outside traditional office hours. That does not necessarily mean every specialist sits in a 24-hour command center. It means alerts, on-call responsibilities, escalation paths and runbooks are defined for failures that cannot safely wait.
Examples include network connectivity loss, settlement-position threshold breach, mass posting failure, fraud-engine outage, duplicate-processing risk or widespread customer-status inconsistency.
15. Real-bank implementation model, data ownership and governance
An implementation becomes manageable when architecture is divided into stable business capabilities.
A common target model is:
channels → instant-payment API/gateway → payment orchestration → validation/enrichment → risk controls → routing/reachability → canonical message model → RTP/FedNow adapters → settlement and posting → events/reporting/reconciliation.
Keep the core orchestration rail-neutral
The core service should understand an instant payment as a product capability. Rail-specific details belong behind adapters as far as practical.
This reduces duplicated logic. Customer limits, fraud checks, payment identity, reporting and reconciliation should not be independently reinvented for RTP and FedNow.
But rail neutrality has limits. Differences in rules, message usage, settlement/funding and optional services must remain explicit. Over-abstraction can be as dangerous as duplication.
Data ownership
Define authoritative sources.
For example:
- customer identity → customer master;
- account balance → core ledger;
- entitlements → access-control platform;
- participant reachability → payment reference-data service;
- payment state → payment orchestration store;
- raw network message → gateway/evidence archive;
- fraud decision → fraud platform with decision reference;
- settlement evidence → network/settlement service;
- accounting entries → ledger/GL platform;
- customer notification → communication service.
If two systems both claim to own payment status, incidents become difficult.
Version governance
Instant-payment networks evolve. Message specifications, rules, participant data, limits and operational requirements change.
Architecture should therefore support versioned configuration for:
- schema and message versions;
- routing data;
- network limits;
- bank product limits;
- fraud rules;
- control policies;
- fee rules;
- participant capabilities.
Hard-coding a network limit deep inside application code is poor design when the network can change that limit.
Change isolation
A FedNow message-version change should not require rewriting customer-channel logic if the canonical model is stable. An RTP participation-rule change should not accidentally alter FedNow behavior.
This is one of the strongest reasons to separate common business orchestration from rail-specific implementation.
16. End-to-end cases, BA checklist, testing and authoritative references
The best way to test architecture is through realistic journeys.
Case 1 — consumer sends an instant account-to-account payment
A consumer opens mobile banking at 10:42 p.m. on Saturday and sends $1,250 to an account at another bank.
The channel authenticates the customer and captures the payment. The bank validates the debit account and available balance. Fraud controls review the device, customer behavior, beneficiary and amount. The reachability service determines that the destination routing number is available on both RTP and FedNow. Bank routing policy selects one rail. The payment is transformed to the required ISO 20022 message and released.
The selected network accepts and settles the transfer. The sending bank finalizes the customer debit. The receiving bank posts the beneficiary credit and makes funds available. A confirmation reaches the sending bank and the customer sees Completed. Events flow to transaction history, notifications, accounting and reconciliation.
The BA should be able to identify the authoritative state at every step.
Case 2 — preferred network unavailable before release
A corporate customer sends a $2.5 million supplier payment. Both rails are normally available. The routing service identifies that the preferred rail is unavailable before submission.
If bank policy allows, the router selects the other eligible rail after confirming reachability, amount eligibility, liquidity and controls. The routing decision record states why the alternative route was selected.
This is safe fallback because no first-rail submission occurred.
Case 3 — network response lost after submission
A payment is submitted externally, but the bank's connection drops before the response is received.
The instruction moves to NETWORK_OUTCOME_UNKNOWN rather than failed. Customer funds are not automatically released back for reuse if that would create risk. The system queries authoritative network/settlement evidence or escalates according to the runbook. Only after the outcome is established does the payment move to settled or rejected.
The system does not send the payment over the other network simply because the first response timed out.
Case 4 — receiving posting service unavailable
The receiving bank gets an instant payment, but its core posting service is unavailable.
This scenario should be designed before production. The gateway cannot invent a success response disconnected from ledger truth. The bank needs a tested resilience pattern — for example active-active posting, controlled failover or another rule-compliant contingency — so the service can satisfy its receiving obligations without creating unreconciled customer balances.
Case 5 — high-value payment and liquidity threshold
A corporate treasury payment approaches the bank's internal instant-payment limit. The route is reachable, but the bank's current funding position is below its internal threshold.
The architecture should apply the configured liquidity rule before external release. Depending on policy, the payment may wait in a controlled non-released state, be declined, or use another eligible route if allowed before submission. Every decision should be visible to treasury and operations.
BA requirement checklist
Before signing off an instant-payment requirement, ask:
- What customer use case is being solved?
- Who can send and who can receive?
- Which account types are eligible?
- Which networks are supported?
- How is participant reachability maintained?
- What determines routing when both networks are available?
- What is the exact fallback rule?
- Which internal and network limits apply?
- When are funds reserved or debited?
- Which fraud and compliance controls must finish before release?
- What is the authoritative payment state store?
- Which ISO 20022 messages are produced or consumed?
- Which identifiers correlate customer, bank and network events?
- What exactly means customer-visible Completed?
- How are uncertain outcomes handled?
- How are returns or recovery requests linked to the original payment?
- What settlement/funding information is required?
- How are incoming funds posted and made available immediately?
- What is reconciled continuously and what is reconciled at formal close?
- What monitoring and on-call support exists 24/7?
- What happens during fraud, ledger, gateway, reference-data or network outages?
Testing matrix
A minimum test set should include:
initiation and authority — valid user, invalid entitlement, new device, corporate dual approval, API credential failure;
account and funds — valid account, closed account, blocked account, insufficient funds, balance changes during processing;
reachability — RTP only, FedNow only, both, neither, stale participant data;
routing — preferred rail available, preferred rail down before release, alternative rail selected, no permitted alternative;
limits — below limit, exact limit, above customer limit, above bank limit, above network limit;
risk controls — fraud approval, fraud decline, sanctions alert, control-service timeout, manual-review policy;
network processing — accepted, rejected, duplicate, schema failure, connectivity timeout before send, timeout after send;
receiving — valid beneficiary, closed beneficiary account, posting delay, duplicate receipt, core outage;
financial state — debit reservation, final debit, settlement confirmation, beneficiary credit, returned funds;
reconciliation — matched transaction, missing ledger posting, missing external event, duplicate internal posting, suspense item;
resilience — service restart, active-active failover, network interruption, delayed participant-reference update;
customer communication — processing, completed, rejected, unknown outcome and returned-payment messaging.
What Chapter 21 should leave you able to explain
After completing this chapter, a learner should be able to draw the architecture of a U.S. bank that supports RTP and FedNow, explain the responsibility of every major component, distinguish route selection from network processing, explain why liquidity and 24/7 operations are architectural concerns, define safe payment states, describe the difference between pre-send fallback and post-send uncertainty, and show how settlement, customer posting, reconciliation and reporting fit into one connected model.
That is the foundation required before studying the RTP and FedNow rail mechanics separately.
Authoritative references
Federal Reserve Financial Services — About the FedNow Service
https://www.frbservices.org/financial-services/fednow/about.html
Federal Reserve Financial Services — FedNow Service Operating Procedures and resources
https://www.frbservices.org/resources/financial-services/fednow
Federal Reserve Financial Services — FedNow Service Operating Hours
https://www.frbservices.org/resources/financial-services/fednow/operating-hours
Federal Reserve Financial Services — FedNow and ISO 20022
https://www.frbservices.org/financial-services/fednow/what-is-iso-20022-why-does-it-matter
Federal Reserve Financial Services — FedNow Participants and Service Providers
https://www.frbservices.org/financial-services/fednow/organizations/
Federal Reserve Financial Services — Operating Circular 8 and FedNow operating documents
https://www.frbservices.org/resources/rules-regulations/operating-circulars.html
Federal Reserve Financial Services — FedNow network limit increase effective November 12, 2025
https://www.frbservices.org/news/communications/111225-fednow-transaction-limit-increase
The Clearing House — RTP Network
https://www.theclearinghouse.org/payment-systems/rtp
The Clearing House — RTP Document Library, Operating Rules, message specifications and settlement/funding guides
https://www.theclearinghouse.org/payment-systems/rtp/document-library
The Clearing House — RTP participating routing numbers
https://www.theclearinghouse.org/payment-systems/rtp/rtn
The Clearing House — RTP network statistics
https://www.theclearinghouse.org/payment-systems/rtp/RTP-Annual-Statistics
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.