Push, Pull, Request-to-Pay and On-Us Transfers. A deep practitioner guide to payment direction and authority models: payer-initiated pushes, collector-initiated pulls, Request for Payment, on-us book transfers, controls, state models, routing, exceptions and testing.
US payment design becomes much easier when four ideas are separated early: who starts the movement, who authorises it, whether money is actually moving yet, and whether an external interbank network is needed.
That sounds simple, but many payment requirements fail precisely because these questions are mixed together. A biller says “pull the money,” a product team calls every customer-approved transaction “push,” a channel team calls a Request for Payment a payment, and an internal book transfer is described as though it travelled across an external network. Those shortcuts may be harmless in casual conversation. They are dangerous in banking requirements.
This chapter is therefore about payment direction and authority models, not a catalogue of payment rails. Chapter 1 built the US ecosystem map. Chapter 2 identified the participants. Chapter 3 now explains how value can be initiated or requested between those participants.
At the end of this chapter you should be able to look at a use case and answer, without guessing:
- who creates the first instruction;
- who has legal or contractual authority to cause an account debit;
- whether the underlying value movement is a credit push or a debit pull;
- whether a request message is only asking for payment or actually moving funds;
- whether the transaction is on-us or interbank;
- where fraud controls must sit before release;
- which return, rejection, reversal or recovery concepts can apply;
- how status, reporting and reconciliation should represent the event;
- and what a developer or tester must never infer from a vague label such as “pay”, “collect”, “instant” or “internal transfer”.
For a roughly 60-minute core session, spend about 35 minutes on Sections 1–5 and Sections 12–15. For the next 10 minutes, use the chapter’s three diagrams to identify who gives authority and where value actually moves. Use 10 minutes to work through one case in Section 16, then spend the final 5 minutes explaining: What must happen between receiving a payment request and recording a completed payment? 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
- Four models, four different questions
- Push payments: the payer releases a credit
- Pull payments: the collector initiates under authority
- Request for Payment: request first, payment second
- On-us transfers: value moves inside one bank
- How the four models compare
- ACH credit: the classic US push model
- ACH debit: the classic US pull collection model
- Wires and instant payments: push with stronger finality
- RTP and FedNow Request for Payment in practice
- Cards and checks: why pull is only an analogy
- Authority, fraud, liability and customer protection
- Data, messages and state transitions
- Routing, reachability, settlement and fallback
- Exceptions, returns, reversals and cancellations
- End-to-end cases, BA checklist and testing
1. Four models, four different questions
The cleanest starting point is to stop treating “payment type” as one dimension. A transaction can be described from several angles at once.
Push or pull describes who causes the funds movement. In a push, the payer side releases a credit toward the beneficiary. In a pull, the collector side submits a debit based on valid authority to debit the payer’s account.
Request for Payment describes a request or messaging interaction. It asks the payer to pay. It does not, by itself, move money. If the payer accepts, a separate credit transfer is normally created.
On-us describes where the accounts sit. If both accounts are held by the same institution, value can often move through the bank’s own ledger without an external clearing or settlement network.
These are not mutually exclusive labels. An on-us transfer can be initiated as a payer push. A bank may offer an internal collection arrangement that feels pull-like. A Request for Payment can result in an on-us credit if both customers bank at the same institution. A payer can receive an RfP through an instant-payment service and then initiate an interbank credit push.
That is why a requirement such as “support request-to-pay collections” is incomplete. It needs to answer what happens after the request is accepted. Does the bank create an RTP credit transfer, a FedNow credit transfer, an ACH credit, an internal book transfer, or simply hand the customer to another payment method? What determines that choice? Is the payer allowed to change the amount? Can the request expire? Can the biller cancel it? What does “paid” mean in the request service versus the settlement rail?
Similarly, “support account pull” is incomplete. Is the instruction an ACH debit? Is it a check converted to ACH? Is it a card merchant transaction being described loosely as a pull? Is it an internal sweep under a treasury agreement? The authority model, return rights, fraud controls and data requirements differ materially.
A useful practitioner rule is:
Direction answers who initiates value. Authority answers why the debit is permitted. Messaging answers what is being communicated. On-us/interbank answers where settlement occurs.
Keep those four questions separate throughout the chapter.
2. Push payments: the payer releases a credit
A push payment starts from the payer side. The payer, or an authorised party acting for the payer, instructs the payer’s bank to send value to a beneficiary.
The defining feature is not speed. ACH credits are pushes even though they are often batch processed. Fedwire customer transfers are pushes. CHIPS customer payments are pushes. RTP and FedNow customer credit transfers are pushes. An on-us transfer initiated by one customer to another customer at the same bank is also a push even though no interbank network is involved.
The defining feature is control of release. The payer side decides that money should leave the account and identifies the destination.
A corporate supplier payment is a good example. The corporation creates a payment instruction in its ERP or treasury system. The instruction reaches the bank through a portal, file or API. The bank authenticates the channel, checks entitlements, validates the debit account, applies approval rules, examines fraud and compliance signals, validates beneficiary and routing information, checks available funds and determines an executable route. Only then does the bank release the credit into the selected rail.
A consumer instant payment follows the same control logic at a smaller scale. The mobile app may make the experience look like one tap, but the bank still has to authenticate the customer, identify the payee, verify the account and amount, assess fraud signals, confirm network reachability, check internal limits and release the credit.
The crucial risk characteristic of push payments is that a payment can be fully authorised by the genuine customer and still be fraudulent in economic substance. An authorised push payment scam illustrates this. The customer may genuinely authenticate and approve the payment but may have been deceived about the beneficiary or purpose. Traditional controls that only ask “did the customer log in correctly?” are therefore insufficient.
This is one reason the US industry has increased focus on credit-push fraud. Nacha’s 2026 risk-management changes explicitly broadened attention toward suspicious ACH credits and fraud induced through false pretenses. Similar pre-release thinking is essential for wires and instant payments because recovery can be difficult after final settlement.
Push controls therefore need to ask two different questions:
- Is this instruction authorised?
- Does this authorised instruction look economically legitimate?
Those are not the same decision.
A bank-grade push lifecycle can be modelled as:
capture → authenticate → approve → validate → fraud/compliance → beneficiary/reachability → funds/limit → route → release → network acceptance → settlement → beneficiary posting → reporting → reconciliation
The earlier the settlement becomes final, the more important the controls before release become.
Push does not mean irrevocable in every rail
A common mistake is to say “push payments cannot be reversed.” That is too broad.
An ACH credit is a push, but ACH has a mature return and reversal framework. A credit can be returned for rule-defined reasons, and an Originator can initiate a reversal only under permitted circumstances. A mistaken ACH credit therefore behaves differently from a completed Fedwire or accepted instant credit transfer.
Push describes initiation direction, not the entire exception regime.
Push does not mean real time
Another mistake is to say “push means instant.” Payroll via ACH credit is one of the largest examples proving otherwise. The corporate pushes funds, but processing is still ACH.
Always separate direction from speed.
3. Pull payments: the collector initiates under authority
A pull payment starts from the collector side. The collector, biller or merchant-side participant submits an instruction that will debit the payer’s account under an existing authorisation, mandate, agreement or other permitted basis.
In US bank-account collections, the clearest example is an ACH debit.
Suppose a utility customer signs up for autopay. The customer authorises the utility to debit the customer’s checking account for the amount due each month under defined terms. On the due date, the utility or its service provider creates an ACH debit. The utility’s ODFI submits it into the ACH Network. The RDFI receives the debit and, subject to applicable rules and account conditions, posts the debit to the consumer account.
The important control fact is that the customer is not normally logging in at the exact moment of every recurring debit and pressing “send.” The authority was established earlier. The collection instruction relies on that stored authority.
This creates a fundamentally different risk pattern from a payer-authenticated push.
The collector must be able to prove that it had valid authority. The ODFI needs confidence in its Originator or Third-Party Sender. The RDFI must handle customer claims according to applicable Nacha Rules and consumer-protection requirements. The product must manage return codes, revocations, stop-payment instructions where applicable, account changes, insufficient funds and retry rules.
A pull product therefore has a mandate or authorisation lifecycle in addition to a payment lifecycle.
That lifecycle may include:
capture authority → validate authority → store evidence → activate collection arrangement → create debit → submit → receive result → reconcile → maintain authority → amend/revoke/expire
This is why “we already store the account number” is not enough for recurring ACH collections. The bank or Originator needs to understand the basis on which that account can be debited.
Pull is not “take money whenever you want”
Valid debit authority has scope. It may define amount, timing, frequency, account, method of revocation and other required elements depending on the transaction type and governing rules.
For consumer ACH debits, compliant authorisation is especially important. Nacha has repeatedly emphasised that authorisation is the foundation that allows Entries to be transmitted and supports the ODFI’s warranties. An Originator may need to provide proof of authorisation when requested.
A production collection platform therefore needs more than a boolean mandate=true. It needs evidence: when authority was obtained, what terms were presented, which account it applies to, whether the amount is fixed or variable, whether the debit is one-time or recurring, when it can be revoked, and how a later dispute can be investigated.
Pull concentrates different risks
The collector controls initiation, so collector-side controls become central:
- originator onboarding;
- customer or debtor authorisation;
- account validation strategy;
- debit blocks or filters;
- exposure management;
- return-rate monitoring;
- fraudulent merchant/originator behaviour;
- retry rules;
- cancellation/revocation handling;
- evidence retention.
The payer-side institution also needs controls because consumer protection and unauthorised-debit claims can create recredit and return obligations.
The collection may be operationally convenient because the biller controls timing. That convenience comes with responsibility.
4. Request for Payment: request first, payment second
Request for Payment is one of the most important concepts to explain correctly because its name makes it sound as though the request itself is a payment.
It is not.
An RfP is a structured message asking another party to make a payment. The payer can review the request and, depending on the implementation, accept, reject, ignore or otherwise respond. If the payer accepts, the payer’s financial institution then initiates the actual funds movement.
On FedNow, the operating procedures are explicit: an RFP uses pain.013; if accepted, the Participant initiates a Customer Credit Transfer using pacs.008. That means the request and the payment are separate events with separate message identities and states.
On RTP, Request for Payment likewise sits alongside the credit-transfer capability. The Clearing House maintains specific RfP rules, sender registration, additional requirements, customer display requirements and permissible-use interpretations.
This separation has major design consequences.
A request can exist even when no payment ever occurs.
A request can be delivered successfully but declined by the payer.
A request can expire.
A request can be cancelled before payment.
A payer may approve a request but the resulting payment can still fail due to insufficient funds, fraud controls, network reachability, limits or another execution reason.
A request service therefore needs its own state model.
A simplified RfP lifecycle might be:
created → validated → sent → delivered → presented → accepted/declined/expired/cancelled
The resulting payment lifecycle is separate:
payment created → authenticated/approved → validated → routed → sent → accepted → settled → posted
Do not collapse those into a single status called PAID.
Why billers like RfP
Traditional ACH debit collections give the biller initiation control but rely on debit authority and return rights. RfP can create a different collection experience: the biller asks for payment while the payer retains the final release decision.
This can be attractive for invoices, utilities, rent, insurance, business-to-business collections and one-time obligations where the biller wants structured remittance information but the payer wants explicit control.
The request can carry context such as biller identity, amount, due date, invoice reference and remittance data. If the payer accepts, those references can be carried or linked into the resulting payment, improving reconciliation.
RfP is not direct debit
A direct debit and an RfP can both support collections, but the authority model is different.
In an ACH debit, the collector originates the debit under previously established authority.
In RfP, the collector originates the request. The payer then initiates or authorises the credit payment.
That difference changes fraud treatment, customer experience, exception handling and liability analysis.
RfP is not a payment guarantee
A biller must not treat “request accepted by the messaging service” as “cash received.”
The receivable should generally be closed only after the resulting payment reaches the business-defined completion point—typically successful settlement and beneficiary posting, with sufficient reconciliation evidence.
The collection platform therefore needs linkage between request ID and payment ID.
5. On-us transfers: value moves inside one bank
An on-us transfer occurs when both sides of the transaction are held within the same financial institution or, depending on the bank’s legal/entity architecture, within an internal ledger arrangement that does not require an external interbank clearing network for the value movement.
The simplest example is one customer at Malla Bank paying another customer at Malla Bank.
The bank can debit Customer A and credit Customer B on its own books.
No ACH Operator is needed. No Fedwire message is required. No RTP or FedNow settlement position needs to move for that internal value transfer.
But “no external rail” does not mean “no payment controls.”
The bank still needs to determine:
- who authorised the debit;
- whether the payer account is eligible;
- whether funds are available;
- whether fraud controls pass;
- whether the beneficiary account is valid and permitted to receive;
- whether sanctions or other compliance controls are required;
- when the debit and credit are posted;
- when funds become available;
- what customer references are preserved;
- how fees, if any, are booked;
- how the transaction appears in statements;
- how the bank reconciles the two ledger legs;
- what happens if the bank itself makes an error.
The economic movement is internal, but the operational discipline remains bank-grade.
On-us can be push or pull-like
On-us is a location/settlement concept, not an initiation-direction concept.
A customer can push money from one internal account to another.
A corporate treasury product can perform an internal concentration sweep under an agreement that looks pull-like from the receiving account’s perspective.
A biller can issue an RfP to a payer at the same bank and, after acceptance, the bank can execute an internal book transfer.
This is why requirements should not create an enum where PUSH, PULL, RFP, and ON_US are mutually exclusive values. They describe different dimensions.
A better model may have separate attributes such as:
initiationModel = PUSH | PULL | REQUEST_LEDsettlementScope = ON_US | INTERBANKrail = ACH | FEDWIRE | CHIPS | RTP | FEDNOW | INTERNAL_BOOK | CARD | CHECK ...authorityType = REAL_TIME_CUSTOMER_APPROVAL | STORED_DEBIT_AUTHORITY | BANK_AGREEMENT ...
This type of modelling prevents architecture confusion.
On-us finality is contractual and ledger-based
Do not copy a network finality statement onto an internal transfer without analysis.
An internal posting can be immediately available and treated as final under the bank’s account agreements and internal rules, but the legal and operational framework differs from Fedwire finality or instant-network settlement rules.
The bank must define exactly what “final” means for its internal product.
On-us routing should be deliberate
A payment hub may identify that both accounts belong to the same bank and choose an internal route instead of sending out to an external network and back.
That can reduce cost and external dependency, but the product must ensure that customer expectations, data requirements, statements and status semantics remain consistent.
The bank also needs controls preventing false on-us classification. Routing purely by account-number pattern without authoritative account ownership data can create serious errors.
6. How the four models compare
A practitioner needs a simple way to compare these models without oversimplifying them.
| Dimension | Push | Pull | Request for Payment | On-us |
|---|
| Who starts the relevant action? | Payer side | Collector side | Requester/biller starts request | Either side depending on product |
| Who releases value? | Payer side | Collector causes debit under authority | Payer side after acceptance | Depends on internal product |
| Authority model | Real-time or prior payer approval | Stored/standing/specific debit authority | Payer approves the requested payment | Internal account/product authority |
| Does first message move money? | Usually yes, once executable instruction released | Yes, once debit entry released | No; request is separate | Internal instruction causes ledger movement |
| Common US examples | ACH credit, Fedwire, CHIPS, RTP, FedNow | ACH debit | RTP RfP, FedNow RFP | Book transfer, internal sweep |
| Main fraud concern | Deceived or compromised payer sends money | Invalid/fraudulent debit authority or bad Originator | Fraudulent bill/request + payer deception | Internal account fraud, compromised user, bad entitlement |
| Exception regime | Rail-specific | Rail-specific, often strong return processes | Request exception + separate payment exception | Bank-specific/internal |
| Settlement scope | On-us or interbank | On-us or interbank | Resulting payment can be on-us/interbank | Internal by definition |
The table is intentionally conceptual. Detailed legal rights depend on the rail, customer type, agreement and applicable law.
The most useful design lesson is that payment method selection should happen after the authority model is understood.
A biller who needs predictable recurring collections may prefer a debit model because the payer does not need to approve every monthly payment. A customer may prefer RfP because each payment remains under payer control. A treasury user may prefer a push because it aligns with internal approval and release processes. If both accounts are at the same bank, the bank may execute on-us regardless of which customer experience initiated the movement.
Product language should match the actual model
Avoid labels that create false expectations.
“AutoPay” usually implies recurring debit authority, but a product could also schedule customer-originated credits.
“Pay by Bank” can use ACH debit or payer-approved instant credit depending on provider implementation.
“Instant collection” can mean an RfP followed by an instant push, not a collector-initiated instant debit.
“Internal transfer” may be on-us, but if different legal entities or external settlement accounts are involved the architecture may be more complex.
The product label is not the rail definition.
7. ACH credit: the classic US push model
ACH credit is one of the clearest push examples in US payments.
The Originator instructs its ODFI to send a credit to a Receiver through the ACH Network. Payroll, supplier payments, tax payments, benefits, reimbursements and many account-to-account transfers use this model.
The direction is payer to payee.
For payroll:
Employer/Originator → ODFI → ACH Operator → RDFI → Employee/Receiver
The employee does not ask the employer’s bank to debit the employer. The employer decides to release payroll.
Corporate control model
A corporate ACH credit file may pass through:
- ERP or payroll generation;
- maker/checker approval;
- file signing or channel authentication;
- ODFI customer validation;
- file-control totals;
- duplicate detection;
- effective-entry-date checks;
- fraud monitoring;
- account and exposure controls;
- ACH formatting and operator submission.
The customer experience is “we sent payroll.” The bank’s execution story is much more detailed.
Credit-push fraud matters in ACH too
Historically, many ACH risk discussions focused heavily on unauthorised debits. The risk environment has changed. Corporate email compromise, vendor impersonation, payroll redirection and account takeover can produce fraudulent but customer-authorised ACH credits.
Nacha’s 2026 risk-management amendments require risk-based processes designed to identify suspicious ACH activity across additional participant categories. This is directly relevant to a chapter about push versus pull: the control model must evolve when fraud moves from unauthorised pulling to deceived pushing.
ACH credit returns do not change its direction
An RDFI may return an ACH credit for reasons such as invalid or closed destination accounts. That does not make the original entry a pull. The return is a later exception event.
Similarly, an Originator may use a reversal only under conditions allowed by the rules. Reversal is not an unrestricted cancel function.
Same Day ACH is still push when the entry is a credit
Changing the settlement window does not change direction. A Same Day ACH credit is still a push.
This sounds obvious, but it prevents a common architecture mistake: modelling direction from speed.
8. ACH debit: the classic US pull collection model
ACH debit is the clearest large-scale US bank-account collection example.
The Originator submits a debit against the Receiver’s account under valid authorisation.
Examples include:
- utility autopay;
- insurance premiums;
- loan repayments;
- subscriptions;
- recurring membership dues;
- one-time account-based purchases;
- business-to-business collections;
- account funding and other authorised debit scenarios.
The chain is still:
Originator → ODFI → ACH Operator → RDFI → Receiver
But the financial direction differs. The entry tells the RDFI to debit the Receiver and ultimately credit the Originator side through ACH settlement.
The authorisation is part of the product
A pull product cannot be designed only from the payment file.
The bank and Originator need to know:
- how authority is obtained;
- whether it is consumer or commercial;
- one-time or recurring;
- fixed or variable amount;
- how notice works where required;
- how revocation is handled;
- how evidence is retained;
- how disputes are investigated.
For consumer ACH debits, Regulation E can also affect the customer-protection framework. Nacha Rules and federal consumer-protection requirements interact; they should not be treated as interchangeable.
Pull convenience creates return exposure
A biller likes ACH debit because it controls when the collection instruction is sent. But the collection can later fail or be returned.
The receivables system should therefore distinguish:
initiated ≠ submitted ≠ settled ≠ finally collectible
For cash application, an ACH debit that has posted may still need return-risk treatment depending on the use case and accounting policy.
Retry is not “just send it again”
Repeated debit attempts must follow applicable rules and product policy. A failed collection workflow needs an explicit retry strategy rather than a generic loop.
The system should know:
- original entry;
- return reason;
- whether retry is permitted;
- maximum attempts;
- timing;
- customer communication;
- whether receivable status reopens;
- whether fees apply;
- whether account data needs correction.
Debit blocks and filters matter for commercial customers
Corporate accounts may use ACH debit blocks or filters to control which Originators can debit the account. A collection product should understand that valid authority at the biller side does not guarantee the RDFI will accept every debit if the customer has configured protective controls.
That is another reason the collection state must distinguish instruction acceptance from successful debit posting.
9. Wires and instant payments: push with stronger finality
Fedwire, CHIPS customer payments, RTP and FedNow customer credit transfers are fundamentally push models.
The payer side releases the funds.
But these rails differ from ACH credit in ways that matter to risk and exception design.
Fedwire settles transfers individually in central-bank money and is designed around strong finality once processed.
CHIPS is a high-value USD system with its own settlement model and participant rules.
RTP and FedNow operate 24/7/365 and support instant credit transfers with immediate processing and settlement models appropriate to their networks.
The key operational consequence is that the decision window moves before release.
A bank cannot rely on a long post-payment correction window to compensate for weak beneficiary controls.
Beneficiary confidence matters
For a high-finality push, the most dangerous fields can be the beneficiary details.
Business email compromise frequently targets legitimate corporate users by changing invoice payment instructions. The user may be fully authenticated. The account may have sufficient funds. The payment may pass sanctions screening. Yet the beneficiary account belongs to a fraudster.
Good controls can therefore include:
- protected payee maintenance;
- dual approval for beneficiary changes;
- cooling-off or step-up controls;
- anomaly detection;
- beneficiary history;
- out-of-band verification for high-risk changes;
- user warnings appropriate to the risk;
- transaction limits.
The exact control depends on the bank and customer segment, but the principle is consistent: authentication proves who approved; it does not prove the beneficiary is legitimate.
Instant push also changes operations
RTP and FedNow can operate outside traditional business hours. Fraud controls, account posting, liquidity, customer notifications and monitoring must therefore support the same service clock.
A payment that is valid at 2:00 a.m. cannot depend on a manual weekday operations queue for a mandatory pre-release control.
Finality is not the same as no recovery process
Even highly final payment systems can support requests to return funds, return messages or bank-cooperation processes. But those mechanisms do not mean the original final settlement is casually undone.
Requirements must use precise language such as:
- return request;
- payment return;
- recall request;
- receiving-bank response;
- customer refund;
- bank adjustment.
Avoid one generic reversePayment() concept across all rails.
10. RTP and FedNow Request for Payment in practice
Request for Payment becomes most useful when the request lifecycle and payment lifecycle are connected without being merged.
FedNow
FedNow operating procedures describe RFP using pain.013. A participant can send an RFP on behalf of itself or an end customer. If the RFP is accepted, the payer-side participant initiates a pacs.008 customer credit transfer.
That is the architecture in one sentence:
request message → payer decision → credit transfer
FedNow participation capability also matters. Receiving RFPs requires an appropriate participation type. A financial institution may be able to send customer credit transfers without necessarily being enabled to receive RFPs. Product teams therefore need to distinguish network participation from specific RFP capability.
RTP
RTP maintains its own RfP rules, sender registration requirements, permissible-use interpretations, customer-display requirements and fraud/control expectations.
Again, the request does not itself settle funds.
The request should carry enough context
A useful RfP can contain:
- requester/biller identity;
- payer identity or destination;
- amount;
- currency;
- due date;
- invoice or bill reference;
- remittance information;
- request expiry;
- payment terms or description;
- request identifier.
This structured context helps the payer understand what is being requested and helps the biller reconcile the resulting payment.
Linkage is critical
The biller’s system should preserve:
request ID ↔ payer response ↔ payment ID ↔ network reference ↔ settlement/posting ↔ receivable
Without that linkage, the bank can deliver a sophisticated request experience but still leave the biller manually matching incoming credits.
Partial payment and amount changes need explicit design
Do not assume the payer can always change the requested amount.
Some use cases require exact payment. Others may allow partial settlement or customer-entered amounts.
The product must define:
- exact amount required?
- underpayment allowed?
- overpayment allowed?
- partial payment closes or leaves residual receivable?
- multiple payments against one request?
- payer can edit remittance?
- biller can reissue request?
These are business rules, not network assumptions.
RfP fraud is different from payment fraud
A fraudulent request can deceive a customer into authorising a legitimate credit transfer to a fraudster.
Controls may therefore need to validate request senders, display biller identity clearly, enforce permissible use, monitor abnormal request patterns and provide customer warnings.
The request service is part of the fraud boundary even though it does not move money itself.
11. Cards and checks: why pull is only an analogy
Cards and checks are sometimes described as “pull payments” because the merchant or payee presents a transaction that ultimately debits the payer.
That analogy can help a beginner, but it becomes dangerous if treated as formal equivalence with ACH debit.
Cards
A merchant submits a card transaction through the acquiring chain. The issuer authorises based on the card account, fraud controls and network rules. Clearing and settlement follow later.
Economically, the merchant is collecting from the cardholder. Operationally, the transaction is governed by card-network roles, cardholder authentication, authorisation, clearing, settlement and dispute rules—not Nacha debit authority.
Calling it an “ACH-style pull” would create wrong assumptions about mandates, returns and message formats.
Checks
A check is a payer-created instrument instructing a bank to pay. The payee deposits or presents it for collection. The paying bank decides whether to pay the item.
The payee is initiating collection, so the experience can feel pull-like. But check law, image exchange, presentment, funds availability and returns are distinct from ACH debit.
Check conversion can become ACH debit
Some eligible checks can be converted into ACH entries under specific SEC-code and notice rules. At that point, the resulting electronic collection follows ACH mechanics.
This illustrates why the BA must identify the actual underlying rail rather than infer it from the customer experience.
Product language should be precise
It is fine to teach that merchants and billers often “pull” value conceptually.
But in specifications use the formal model:
- ACH debit;
- card merchant transaction;
- check presentment;
- internal sweep;
- RfP + credit transfer.
Precision prevents downstream teams from applying the wrong rules.
12. Authority, fraud, liability and customer protection
Push and pull models place authority at different points, and that changes both fraud exposure and customer protection.
Push authority
In a push, the payer authorises the credit.
The bank therefore focuses heavily on:
- authenticating the payer;
- confirming entitlement;
- validating payee details;
- detecting account takeover;
- detecting scam indicators;
- limits;
- transaction signing or approval;
- clear confirmation before release.
The biggest risk can be an authorised but deceived customer.
Pull authority
In a pull, the collector initiates the debit based on authority obtained earlier.
The control questions shift:
- was valid authorisation obtained?
- can it be proved?
- has it been revoked?
- does amount/timing fit the authority?
- is the Originator legitimate?
- are return rates acceptable?
- is the RDFI receiving a valid entry?
- what rights does the consumer have if unauthorised?
RfP authority
An RfP sender needs authority to issue the request in the permitted use case. But the request does not grant authority to debit the payer.
The payer still authorises the resulting payment.
This is a critical fraud-control advantage of request-led collection, but it does not eliminate scams.
On-us authority
The bank defines internal authority through account agreements and product controls.
If a corporate sweep arrangement allows a concentration account to pull from subaccounts, the bank must preserve the agreement and entitlements that justify that internal debit.
If a consumer pushes to another internal customer, the real-time customer approval is the relevant authority.
Consumer protection varies by instrument
Do not state one universal “consumer can always reverse” or “consumer cannot reverse” rule.
Regulation E applies to covered consumer electronic fund transfers and includes error-resolution and unauthorised-transfer protections. ACH rules have their own return processes. Card disputes follow card-network and federal/state frameworks. Checks have different law. Wire transfers can fall under UCC Article 4A or Federal Reserve rules depending on context.
A BA should identify which legal/rule layer applies and involve compliance/legal experts for product-specific conclusions.
Fraud monitoring must align with direction
A practical control matrix looks like this:
| Model | Primary pre-release fraud focus | Important post-event control |
|---|
| Push | customer identity, payee integrity, scam/account-takeover indicators | investigation, return request where available |
| Pull | Originator legitimacy, authorisation, debit velocity, account validation | returns, unauthorised debit claims, return-rate monitoring |
| RfP | requester legitimacy, request content, customer deception | link payment outcome to request, abuse monitoring |
| On-us | internal entitlement, counterparty, account relationships | internal adjustment/investigation and ledger reconciliation |
The model determines where the strongest controls belong.
13. Data, messages and state transitions
A robust payment platform should never use one status model for all four concepts without identifying what the status belongs to.
Push payment state
Typical states might include:
CAPTURED → APPROVED → VALIDATED → RELEASED → NETWORK_ACCEPTED → SETTLED → POSTED → REPORTED
with exception states such as:
REJECTED, RETURNED, HELD, REPAIR, RETURN_REQUESTED.
Pull collection state
A pull may require two linked state machines:
Authority state
PENDING → ACTIVE → AMENDED → REVOKED → EXPIRED
Debit state
CREATED → SUBMITTED → ACCEPTED/SETTLED → POSTED → RETURNED
A debit can be technically valid while the underlying authority record is missing or defective. That is an operational and compliance problem even if the file format passed.
RfP state
Request state:
CREATED → SENT → DELIVERED → PRESENTED → ACCEPTED | DECLINED | EXPIRED | CANCELLED
Then, if accepted, payment state starts separately.
The request response is not the payment settlement confirmation.
On-us state
An internal transfer might use:
CAPTURED → APPROVED → VALIDATED → INTERNAL_POSTING → COMPLETED → REPORTED
The bank still needs a durable transaction reference and two-sided ledger evidence.
Message identity must survive handoffs
At minimum, consider preserving:
- customer reference;
- request ID;
- mandate/authorisation ID where relevant;
- bank transaction ID;
- file/batch ID;
- network message ID;
- end-to-end ID;
- settlement reference;
- ledger booking IDs;
- return/reversal/cancellation reference;
- investigation case ID.
The exact identifiers differ by rail, but the principle is universal: you should be able to reconstruct the entire story without searching by amount and date alone.
ISO 20022 does not make all models identical
Fedwire, RTP and FedNow use ISO 20022, and RfP uses ISO 20022 messages in instant-payment contexts. That common syntax does not make the business meaning identical.
pain.013 represents a request for payment in FedNow/RTP contexts; pacs.008 represents a credit transfer. A common data standard improves structure and interoperability, but the business event still matters.
14. Routing, reachability, settlement and fallback
Direction alone does not determine route.
A payer wants to send $25,000. It is a push. The bank still has to decide whether the executable route is ACH credit, Same Day ACH, RTP, FedNow, wire or on-us.
A biller has an authorised recurring debit. It is a pull. The bank still needs to know whether ACH debit is supported for that account, whether the Originator is enabled, and whether the instruction passes controls.
An RfP is accepted. The bank then needs to determine whether the resulting payment can be executed through the relevant instant rail.
On-us should normally be resolved before external routing
If both accounts are internal and the product permits it, an internal book transfer may be the most efficient route.
The routing engine should make this decision using authoritative account ownership and product rules—not a guess.
Reachability matters for instant payments
A valid US routing number does not prove that the destination is reachable on RTP or FedNow for the required capability.
The sending bank needs current reachability data.
For RfP, capability is even more specific: the institution may participate in the instant rail but not receive RfPs.
Fallback must preserve customer intent
Suppose a customer accepts an RfP expecting instant payment. If the instant rail is unavailable, should the bank automatically send ACH?
There is no universal answer. The product must define it.
Possible behaviours:
- reject and tell the customer;
- offer ACH as an explicit alternative;
- queue until the instant rail recovers;
- use another instant rail if permitted and reachable;
- use on-us if both accounts are internal.
The wrong design is silent fallback that changes timing, finality or fee expectations without customer awareness.
Settlement model still matters
Push/pull describes initiation. Settlement still depends on the chosen rail.
ACH settles in batches/cycles.
Fedwire is gross settlement in central-bank money.
RTP uses its prefunded model.
FedNow settles through Federal Reserve accounts.
On-us uses internal ledger movement.
A common front-end “Pay” button can therefore hide very different settlement economics and liquidity needs.
15. Exceptions, returns, reversals and cancellations
The most reliable way to avoid confusion is to ask what event is being undone or rejected, and at what stage?
Reject
A push or pull instruction may be rejected before successful processing because data, account, entitlement, risk or network validation failed.
An RfP can also be rejected/declined at the request layer.
Return
ACH uses returns extensively. An ACH debit can be returned for unauthorised or administrative reasons. An ACH credit can also be returned for reasons such as invalid destination accounts.
Instant-payment systems can support payment returns or return-of-funds processes, but those do not mean the original payment lacked finality.
Reversal
ACH reversals are corrective Entries permitted only under defined circumstances.
Do not implement a generic “reverse” button that can reverse any payment.
Request cancellation
An RfP sender may cancel a request under the relevant network/process rules before the request has resulted in a completed payment.
Cancelling the request is not the same as cancelling a payment already settled.
Payment cancellation
For many push rails, the window to stop a payment is before release or acceptance.
After final settlement, the sending bank may need to request return of funds rather than “cancel” the payment.
On-us adjustment
An internal bank error may be corrected through bank ledger adjustment according to internal controls and account agreements.
That is different from an external network return.
Duplicate handling
Direction models also affect duplicate control.
A payer retrying a push after a timeout can accidentally create two payments.
A biller retrying a returned pull can create an unauthorised or excessive debit if retry rules are wrong.
An RfP can be duplicated even before any money moves, creating multiple payment prompts.
An on-us API retry can double-post if idempotency is weak.
Every model needs stable identifiers and replay protection.
16. End-to-end cases, BA checklist and testing
This final section applies the models to realistic situations.
Case 1 — monthly insurance premium
An insurer wants to collect the same customer’s premium every month.
The business need is recurring collection with predictable timing.
ACH debit is a natural pull model.
The system needs to capture and retain customer authority, schedule the debit, submit through the ODFI, process returns, manage retries, reopen the receivable if the debit fails and support customer revocation.
An RfP would create a different experience: the customer would need to approve each requested payment. That may be desirable for some products but is not operationally equivalent to autopay.
Case 2 — supplier invoice
A corporate receives a $180,000 supplier invoice.
The corporate wants to control exactly when funds leave.
That points toward a push model.
The ERP creates the instruction, bank approvals are completed, beneficiary details are validated, and the bank routes through an appropriate credit rail.
If the supplier had instead sent an RfP, the request could help present invoice details, but the corporate would still approve the resulting credit push.
Case 3 — utility bill with RfP
A utility sends a structured RfP for $186.42.
The customer sees the utility name, account reference, amount and due date in the bank app.
The customer accepts.
The bank creates a separate instant credit transfer.
The utility closes the receivable only when the resulting payment is confirmed and reconciled.
If the customer declines, no debit occurs.
If the request expires, no debit occurs.
If the payment fails after acceptance, the request can be accepted while the receivable remains unpaid.
This case demonstrates why request state and payment state must remain separate.
Case 4 — two customers at the same bank
A tenant and landlord both bank with the same institution.
The tenant selects “Pay rent.”
The bank identifies both accounts as internal, performs payer authentication, fraud and funds checks, debits the tenant, credits the landlord, creates internal ledger references and reports the movement to both customers.
The transaction is a payer push and an on-us transfer at the same time.
No external ACH or instant network is needed.
Case 5 — corporate concentration sweep
A corporation wants cash moved nightly from operating accounts into a concentration account, all held at the same bank.
The receiving treasury account may be configured to collect from subaccounts under standing agreements.
The behaviour is pull-like but executed on-us.
The bank needs explicit authority, sweep rules, thresholds, account eligibility, posting logic, exception handling and reporting.
Calling it “internal transfer” without the authority model would be incomplete.
Case 6 — instant refund
A merchant wants to send a refund directly to a customer’s bank account late at night.
That is a push from the merchant side.
If the bank supports RTP or FedNow sending and the destination is reachable, the payment can be routed instantly. If both accounts are internal, the bank may use on-us.
An RfP is not appropriate because the merchant is sending money to the customer, not asking the customer to pay.
BA requirement checklist
For every push/pull/request/on-us requirement, answer:
Business intent
- Is this payment, collection, refund, payout, transfer, sweep or request?
- Who economically owes whom?
- Is the transaction one-time or recurring?
Direction
- Who initiates the value movement?
- Is it push, pull or request-led?
- If request-led, what actual payment method follows acceptance?
Authority
- Who authorises the debit?
- Is authority real-time or stored?
- What evidence must be retained?
- How is authority revoked or amended?
Participants
- Who holds payer and payee accounts?
- Are both accounts at the same institution?
- Which institution participates in the external rail if interbank?
Routing
- What rails are eligible?
- Is on-us checked first?
- What reachability data is required?
- Is fallback allowed?
Controls
- Authentication?
- Entitlement?
- Funds?
- Fraud?
- sanctions/compliance?
- beneficiary/account validation?
- debit-block/filter checks?
- limits?
State
- What are request states?
- What are payment states?
- What are mandate/authority states?
- Which IDs link them?
Settlement and posting
- When does interbank settlement occur?
- When is the customer account posted?
- When are funds available?
- What does the product call “complete”?
Exceptions
- What can reject?
- What can return?
- What can reverse?
- What can be cancelled?
- Can the bank request return of funds?
- What is the retry policy?
Reporting and reconciliation
- What status does each party see?
- What references are preserved?
- How does the biller close the receivable?
- How does the bank reconcile network and ledger?
- How does operations investigate?
If any answer is vague, the requirement is not ready.
Testing matrix
A serious test pack should include:
Push
- valid payer-authorised credit;
- invalid beneficiary;
- insufficient funds;
- fraud hold;
- duplicate retry;
- unreachable instant destination;
- network outage;
- successful settlement but reporting failure;
- customer claims scam after authorised payment.
Pull
- valid recurring authority;
- missing authority;
- revoked authority;
- invalid account;
- debit blocked by commercial customer filter;
- insufficient funds;
- return;
- permitted retry;
- prohibited or excessive retry;
- unauthorised debit claim;
- mandate/account change.
RfP
- valid request;
- duplicate request;
- request to unsupported receiver capability;
- decline;
- expiry;
- cancellation;
- accepted request + successful payment;
- accepted request + failed payment;
- payment succeeds but request state not updated;
- mismatched request/payment reference.
On-us
- valid internal push;
- internal pull-like sweep;
- invalid internal beneficiary;
- one account closed;
- fraud hold;
- duplicate API retry;
- debit posted but credit failed;
- reporting mismatch;
- reversal/adjustment under bank-error process.
Testing must verify customer experience + payment state + ledger + network or internal posting + reporting + reconciliation.
Deep-dive: authority is a data object, not a sentence in terms and conditions
In mature payment architecture, authority should be modelled as something the system can identify, validate and evidence. That matters most for pull collections, but the principle helps across all four models.
For a recurring ACH debit, the authority record should not be hidden inside a scanned PDF that only operations can find after a dispute. The payment service should be able to identify which authorisation supports which debit. That may require an internal mandate or authority identifier linked to the customer, account, Originator, payment purpose, amount rule, frequency, start date, expiry or revocation state.
This does not mean every bank needs a universal “mandate engine” for all payment products. It means the design must preserve enough structured evidence to answer a later question: why was this debit allowed?
For a push, the authority record may be different. It can be the authenticated session, transaction-signing evidence, maker-checker approval, API credential, corporate file signature and approval chain. The important question is still the same: why was the debit allowed?
For an RfP, there are two authority questions. First, was the requester permitted to send the request? Second, did the payer authorise the resulting payment? Those are separate evidence objects.
For on-us transfers, the bank may hold the authority entirely inside its own systems. A treasury sweep agreement may define standing internal debit rights. A consumer transfer may rely on one-time authenticated approval. The absence of an external scheme does not reduce the need to prove authority.
This modelling becomes extremely useful in investigations. Instead of asking an operations user to read multiple systems and infer what happened, the payment record can link directly to the authority evidence that supported release.
Deep-dive: one-time, recurring and standing instructions are not interchangeable
A one-time payment and a recurring arrangement can use the same rail but require different product behaviour.
A one-time ACH debit may have authority for one specific transaction. A recurring debit arrangement permits repeated collection according to agreed terms. A standing internal sweep may run every day based on treasury rules. A scheduled push can be created today but released on a future date.
The bank therefore needs to separate:
- instruction creation — when the customer or collector creates the instruction;
- authority creation — when permission to debit or release is established;
- execution date — when the bank attempts the payment;
- recurrence rule — whether execution repeats;
- termination rule — when the arrangement ends.
If these are collapsed into one record, product teams struggle with common cases such as “change the amount but keep the mandate”, “pause next month only”, “revoke future collections but do not undo the last settled debit”, or “cancel the scheduled credit before it has been released”.
This is especially important for user interfaces. A button labelled “Cancel payment” may need to do three completely different things depending on state:
- delete a future scheduled instruction;
- cancel an outstanding RfP;
- request return of a payment that has already settled.
The label may be simple; the backend semantics must not be.
Deep-dive: the payer experience can hide a different direction model
Modern payment products often use customer experience language that does not reveal the underlying direction.
A consumer can click “Pay bill” in a biller portal and the result may be an ACH debit initiated by the biller. The consumer feels like they initiated a payment, but the network instruction is collector-originated.
A consumer can click “Pay now” in their bank app after receiving an RfP. The biller initiated the request, but the resulting funds movement is payer-originated.
A “Pay by Bank” button can use an ACH debit in one provider and a payer-approved RTP/FedNow credit in another.
A card-on-file subscription looks like a merchant-initiated collection from the customer’s perspective but follows card-network credential and merchant-initiated transaction rules, not ACH debit rules.
This is why a BA should never derive the payment model solely from the screen journey. The functional design must explicitly state the underlying authority and settlement mechanism.
A useful workshop question is:
After the customer presses the button, which party creates the executable funds-movement instruction?
That one question often reveals whether the model is actually push, pull, request-led or a card/check process being described loosely.
Deep-dive: RfP customer presentation is part of payment safety
A Request for Payment can be technically valid and still create a poor or unsafe customer experience if the payer cannot understand what is being requested.
The payer should be able to identify the requester, amount, purpose and relevant reference before approving. If the request contains a confusing trade name, truncated account reference or vague free text, the customer may approve the wrong obligation or be more vulnerable to social engineering.
The bank’s RfP product therefore has a presentation responsibility as well as a messaging responsibility.
Questions include:
- Which requester name is displayed?
- Is that name verified or supplied as free text?
- Is the biller’s customer reference shown?
- Is the due date visible?
- Is the amount editable?
- Are warnings shown for unusual requests?
- Can the customer report a suspicious request?
- Can the customer block a requester?
- Does the bank distinguish a request from a normal incoming message?
- What happens when multiple requests reference the same invoice?
These are not merely UX details. They influence fraud prevention and customer confidence.
The Clearing House’s RTP framework includes specific RfP customer-display and permissible-use material. FedNow operating procedures likewise define RFP processing expectations and participation capability. A bank product should respect those service rules while also defining its own customer experience.
Deep-dive: request expiry and payment due date are different clocks
An RfP can have a request expiry, while the underlying invoice has its own due date.
Suppose a bill is due on Friday, but the RfP expires Thursday evening. The customer who opens the request Friday morning may no longer be able to act on that request even though the invoice is still due.
Or the opposite: a request may remain valid after the commercial due date, allowing late payment.
The product therefore needs at least two concepts:
- commercial obligation timing — when the bill is due;
- message validity timing — how long the request can be acted upon.
This matters to collections reporting. A request marked EXPIRED does not necessarily mean the receivable is cancelled. It means that particular request can no longer be used.
Likewise, a cancelled request does not automatically cancel the invoice.
Deep-dive: on-us accounting must remain double-sided and reconcilable
Because on-us transfers do not leave the bank, teams sometimes treat them as operationally trivial. That is a mistake.
The bank still moves value between liabilities on its own balance sheet. The sending customer’s deposit liability decreases and the receiving customer’s deposit liability increases. Depending on the core architecture, the entries may post directly or pass through internal clearing accounts.
The bank needs to ensure that both sides post atomically or with controlled compensation logic. A debit without the corresponding credit creates a serious accounting break. A credit without the debit can create an unintended bank exposure.
The preferred technical design is usually to treat the internal movement as one business transaction with linked ledger legs and one durable transaction identity, even if the underlying ledger produces separate entries.
Reconciliation should prove:
- payer debit amount;
- payee credit amount;
- value date;
- fees;
- transaction reference;
- customer reporting on both accounts;
- any internal clearing/suspense movement;
- general ledger impact.
If the transfer crosses legal entities inside a banking group, the architecture may require intercompany settlement rather than a simple one-ledger book transfer. “Same brand” does not automatically mean “same legal ledger”.
Deep-dive: internal transfers still need beneficiary controls
A bank may assume an internal beneficiary is safer because the recipient is another customer of the same institution. That can reduce some routing uncertainty, but it does not eliminate fraud.
Fraudsters can control mule accounts at the same bank. Account takeover can send funds internally. A customer can be deceived into paying another internal customer. Internal transfers may also move faster because there is no external network gate.
The bank therefore needs beneficiary and behavioural controls even for on-us payments.
The good news is that an on-us bank has richer information about both sides. It may know account age, KYC profile, transaction history and relationship data for payer and payee. That can support stronger real-time fraud detection if the architecture makes those signals available.
Deep-dive: payment initiation and collection initiation can coexist in one corporate product
Corporate treasury products frequently support both outbound payments and incoming collections.
The same corporate may:
- push ACH credits to suppliers;
- push wires for high-value obligations;
- receive RfPs from vendors;
- originate ACH debits against customers;
- send RfPs to customers;
- receive incoming instant credits;
- perform on-us concentration sweeps.
A bank should therefore avoid designing “payments” and “collections” as isolated universes with incompatible status models and reporting.
The customer may want one treasury dashboard showing all cash movements while still preserving the functional differences between each model.
A good canonical model can share common fields such as amount, currency, customer reference, counterparty, account, status, timestamps and audit information, while retaining model-specific fields for authorisation, mandate, request lifecycle, network and return data.
This balance is important. Over-generalise and you lose rule-specific meaning. Over-specialise and every rail becomes a silo.
Deep-dive: control placement follows who can cause irreversible harm
A useful architecture principle is to place the strongest preventive control before the actor who can cause an irreversible or expensive financial event.
For payer pushes, the dangerous action is release. Controls therefore sit before the bank transmits the credit.
For collector pulls, the dangerous action is origination without valid authority or excessive/abusive debiting. Controls therefore sit around Originator onboarding, mandate evidence, debit creation, exposure and monitoring.
For RfP, the dangerous action at the request layer is deceptive prompting; at the payment layer it is payer release. Controls exist at both points.
For on-us transfers, the dangerous action is internal ledger posting. There may be no external participant to reject a bad instruction, so internal controls must be complete before posting.
This approach helps teams avoid copying the same control sequence onto every payment method.
Deep-dive: customer funds and bank settlement liquidity are different
A payer can have sufficient account balance while the bank lacks the settlement capacity to use a particular interbank rail at that moment.
This distinction is most visible in instant and high-value payments, but it is conceptually important across the models.
The payer’s funds check asks whether the customer is entitled to spend the amount.
The bank’s liquidity check asks whether the bank can settle the interbank obligation.
For an on-us transfer, no external settlement liquidity may be required because the bank is simply moving liabilities internally. That can make an on-us route operationally attractive.
For RTP, prefunded settlement capacity matters.
For FedNow, Federal Reserve account arrangements and liquidity matter.
For Fedwire, master-account/intraday liquidity matters.
For ACH, settlement positions are managed around settlement windows.
A routing engine should not confuse these two balance concepts.
Deep-dive: acceptance, settlement and posting should have named timestamps
Customer disputes become much easier to investigate when the product stores precise lifecycle timestamps.
For a push:
- instruction received time;
- customer approval time;
- bank release time;
- network acceptance time;
- settlement time;
- beneficiary posting time;
- customer notification time.
For a pull:
- authority effective time;
- debit creation time;
- file/network submission time;
- settlement/posting time;
- return time if applicable.
For an RfP:
- request creation;
- request delivery;
- payer presentation;
- payer response;
- resulting payment initiation;
- settlement;
- payee posting.
For on-us:
- instruction capture;
- approval;
- debit posting;
- credit posting;
- reporting.
This makes SLA definitions much more precise. “Payment completed in two seconds” is meaningless unless the start and end events are named.
Deep-dive: reconcile the business obligation, not only the rail
Banks often reconcile the network message to the ledger and consider the technical transaction complete.
Corporates care about another layer: did the cash settle the intended obligation?
For a supplier push, can the beneficiary match the payment to the invoice?
For an ACH debit, can the biller apply the collection to the correct customer account?
For RfP, did the payment preserve the request reference?
For on-us rent, did the landlord receive enough narrative to identify the tenant and month?
A transaction can be perfectly reconciled at bank level and still fail the customer’s cash-application process.
This is why remittance design belongs in the initial requirement.
Deep-dive: avoid double payment when RfP and other channels coexist
A biller may send an RfP while also accepting ACH debit, card, check and portal payments.
Suppose a customer pays the invoice by card after receiving the RfP but before opening it. If the RfP remains active, the customer might later approve a second payment.
The biller or request platform therefore needs lifecycle coordination.
When the receivable is paid through another channel, should the outstanding RfP be cancelled? How quickly? What if cancellation reaches the payer after they already accepted? Which system is authoritative for invoice status?
The same issue occurs when multiple RfPs are sent for one invoice or when a reminder creates a second request.
Collection orchestration should prevent duplicate economic settlement, not just duplicate network messages.
Deep-dive: cross-channel idempotency is harder than API idempotency
An API idempotency key prevents the same technical request from being processed twice.
It does not prevent the same invoice from being paid once by ACH debit and once by RfP-triggered instant credit.
A mature collections platform may therefore need both:
- technical idempotency — same message/request not processed twice;
- business idempotency — same economic obligation not settled twice unintentionally.
Business identifiers such as invoice ID, billing account, due period and receivable ID help.
Deep-dive: what “collection successful” should mean
The definition of collection success depends on the model.
For ACH debit, the bank may report successful settlement, but the biller may still account for return risk.
For RfP, request acceptance is not collection success; payment settlement/posting is closer.
For card, authorisation is not merchant funding.
For check, deposit is not final collection.
For on-us, successful two-sided ledger posting may provide a stronger immediate completion point.
The corporate product should expose the right state instead of using one green tick called “Collected”.
A useful layered status model is:
- instruction/request status
- funds movement status
- customer posting status
- economic collection status
- reconciliation status
That model may feel more complex, but it mirrors reality and prevents false reporting.
Deep-dive: operational ownership when something breaks
The payment model also changes who should own the first investigation.
If a push fails before network release, the sending bank or customer channel usually owns the immediate problem because no external movement has occurred yet. The team should inspect authentication, approval, funds, limits, beneficiary validation, fraud decisions and routing.
If a push is network accepted but the beneficiary does not see funds, the investigation moves downstream: network status, settlement, receiving-bank posting and beneficiary-account state become relevant.
If a pull is returned, the collector side needs to know whether the problem is administrative, financial or authority-related. The Originator may need to correct customer data, stop retrying, contact the customer or reopen the receivable.
If an RfP is not acted upon, there may be no payment investigation at all. The issue can be at the request layer: delivery, presentation, expiry, customer decline or unsupported receiving capability.
If an RfP was accepted but no payment settled, the investigation must pivot from request evidence to the resulting credit transfer.
If an on-us transfer has only one ledger leg posted, the bank has an internal accounting incident rather than a network investigation.
This is why support tools should let operations search by business event and then show linked technical events. A customer should not need to know whether their problem is “pain.013”, “pacs.008”, an ACH return or an internal ledger exception before the bank can help.
Deep-dive: design the audit trail before production
Every model should leave evidence that answers five questions:
- Who acted?
- What authority supported the action?
- What did the bank decide?
- What financial event occurred?
- What did the customer see?
For push payments, retain the authenticated actor, approvals, beneficiary details as presented, risk decisions, release decision and network outcome.
For pull payments, retain the Originator, authority evidence, debit terms, file/entry identity, return information and any retry decision.
For RfP, retain requester identity, request payload, delivery/presentation status, payer response, and linkage to the resulting payment.
For on-us, retain both ledger legs, internal transaction identity, account ownership, approvals and reporting.
Audit evidence should be immutable enough for investigations and controlled enough to protect sensitive customer data. It should also have a retention policy aligned with the payment product, legal requirements and bank policy.
Deep-dive: the best architecture keeps business meaning visible
Payment modernisation often introduces a central payment hub. That can improve routing and reuse, but the hub should not flatten meaningful differences.
A canonical payment object can represent common elements while preserving direction-specific semantics.
For example:
businessPurpose
initiationModel
authorityType
settlementScope
requestedRail
selectedRail
payerAccount
payeeAccount
requestId
authorityId
paymentId
networkReference
status
settlementStatus
postingStatus
reconciliationStatus
The point is not these exact field names. The point is to prevent the architecture from forcing an ACH debit mandate into a field designed for a real-time payer approval, or treating an RfP as though it were already a settled credit transfer.
A good canonical model simplifies integration without erasing business truth.
Deep-dive: decision tree for choosing the model
A useful requirement workshop can follow this sequence.
Question 1: who should control the moment funds leave?
If the payer must explicitly control each release, favour a push or request-led model.
If the collector needs predictable recurring initiation under standing authority, a pull may fit better.
Question 2: does the payer need a prompt or bill presentation before paying?
If yes, RfP may add value. If no, a normal push or scheduled payment may be simpler.
Question 3: are both accounts at the same bank?
If yes, evaluate an on-us route before using an external network.
Question 4: what are the required timing and finality characteristics?
This narrows the eligible rail but does not change the underlying authority model.
Question 5: what exception rights are required?
A collection business comfortable with ACH returns may choose differently from a high-value transaction requiring stronger settlement certainty.
Question 6: what data must travel with the transaction?
Invoice-level remittance, customer references and request linkage can materially affect the product choice.
Question 7: what fraud scenario is most dangerous?
A recurring debit product must protect against bad Originators and invalid authority. A push product must protect against compromised or deceived payers. RfP must protect both the request channel and the eventual payment release.
Only after those questions should the team say, “Use ACH,” “Use RTP,” “Use FedNow,” or “Use an internal transfer.”
Deep-dive: what not to duplicate in later chapters
This chapter intentionally stops before the detailed scheme mechanics begin. It establishes the authority and direction model so later chapters can go deeper without repeating the same foundation.
The ACH chapters will explain SEC codes, authorisation classes, returns, reversals, Same Day windows, fraud controls and operator mechanics in detail.
The high-value chapters will go deeper into Fedwire and CHIPS routing, ISO 20022 data, correspondent banking, liquidity and investigations.
The instant-payment chapters will explain RTP and FedNow message flows, participant capability, liquidity, Request for Payment rules and return-of-funds processes at scheme level.
The card and check chapters will explain their own authorisation, clearing, settlement, dispute and return models.
The rule for the learner is therefore: use Chapter 3 to decide what kind of authority and initiation model you are looking at. Use later chapters to understand how the selected US rail implements that model.
That separation is deliberate. It keeps the academy from teaching the same payment lifecycle five times with different labels, while still giving each rail enough room for genuine depth.
Practitioner checkpoint
Before moving to Chapter 4, you should be able to explain:
- Why push/pull and on-us/interbank are different dimensions.
- Why an RfP does not move money.
- Why accepting an RfP is not the same as successful settlement.
- Why ACH debit authority is part of the product, not just legal paperwork.
- Why an ACH credit can be returned even though it is a push.
- Why Same Day ACH does not change payment direction.
- Why instant payments require strong controls before release.
- Why card transactions should not be formally modelled as ACH-style pulls.
- Why a check can feel pull-like without being an ACH debit.
- Why a valid routing number does not prove RTP/FedNow reachability.
- Why RfP capability can differ from general instant-payment participation.
- Why on-us transfers still need fraud, accounting, reporting and reconciliation.
- Why a corporate sweep can be on-us and pull-like simultaneously.
- Why request cancellation and payment cancellation are different.
- Why one generic “reversal” status is dangerous.
- Which identifiers should link request, payment, settlement and ledger evidence.
If those answers are clear, you have the correct mental model for the deeper clearing, settlement, ACH and instant-payment chapters that follow.
Precision clarifications before you move on
On-us does not mean outside regulation
An on-us transfer describes where the value movement is executed, not whether legal or regulatory obligations disappear. If an internal electronic transfer falls within the scope of applicable consumer-protection requirements, those requirements can still apply even though no external clearing network is used. For example, Regulation E can be relevant to covered consumer electronic fund transfers. The bank therefore must not treat ON_US as a shortcut meaning “internal, therefore unregulated.” Product, legal, consumer-protection, error-resolution and disclosure obligations still have to be assessed for the actual use case.
Account validation is not debit authority
For ACH debit collections, confirming that an account exists, is open, or appears to belong to the customer does not by itself give the Originator authority to debit that account. Account validation answers a data or account-confidence question. Authorisation answers the legal and contractual question: why is this Originator permitted to cause this account to be debited? Both can matter, but they are separate controls and should be modelled separately in requirements, evidence and testing.
A push can be delegated without becoming a pull
A push does not require the economic payer to personally press “send” at the exact execution moment. A corporation may authorise a payroll processor, treasury platform, payment factory or other agent to create and transmit credit instructions within agreed limits and approval rules. The payment remains a push because the payer side is causing value to be credited to the beneficiary. The delegated party may perform the initiation step, but that delegation does not convert the transaction into a collector-initiated debit. Requirements should therefore distinguish the economic payer, the authorised initiator, the approver, and the bank releasing the credit.
An RfP does not create the underlying debt
A Request for Payment is a mechanism for asking the payer to settle an existing or intended commercial obligation. The invoice, contract, subscription, rent agreement or other business relationship creates the underlying amount owed. The RfP carries or references that obligation; it does not normally create the debt merely by being sent. Therefore an RfP that is declined, cancelled or expired does not automatically cancel the invoice or erase the amount due. The receivables system must keep commercial obligation state, request state, and payment state separate.
One sentence to carry forward
Push, pull, Request for Payment and on-us are not competing rail names: they describe who initiates value, how authority works, whether a request is only messaging, and whether settlement stays inside one bank or crosses an interbank network.
Official and primary references
Nacha — The importance of compliant ACH authorizations
https://www.nacha.org/news/importance-compliant-ach-authorizations
Nacha — 2026 risk-management rules now in effect
https://www.nacha.org/news/new-nacha-risk-management-rules-now-effect
Nacha — fraud-compliance responsibilities for organizations sending ACH payments
https://www.nacha.org/news/new-nacha-rules-new-fraud-compliance-responsibilities-all-organizations-sending-ach-payments
Nacha — ACH debit sample authorization and Direct Payment concepts
https://www.nacha.org/system/files/2021-07/DP-Authorization-Form.pdf
Federal Reserve Financial Services — FedNow Service Operating Procedures
https://www.frbservices.org/resources/financial-services/fednow
Federal Reserve Financial Services — FedNow participants and service providers
https://www.frbservices.org/financial-services/fednow/organizations/
Federal Reserve Financial Services — FedNow 2026 fee schedule, including RFP and on-us RFP items
https://www.frbservices.org/resources/fees/fednow-2026
The Clearing House — RTP document library and current operating rules
https://www.theclearinghouse.org/payment-systems/rtp/document-library
Federal Reserve — Regulation E / Electronic Fund Transfer Act material
https://www.federalreserve.gov/boarddocs/supmanual/cch/cch.pdf
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.