Scenario Walkthroughs
This section walks through twelve common operational scenarios across all five US payment rails. Each scenario includes the triggering event, step-by-step processing flow, key dates, compliance checkpoints, and the expected resolution. Use these walkthroughs for training, procedure validation, and exception handling reference.
S-01: Standard ACH Credit — Payroll Direct Deposit
Rail: ACH | SEC Code: PPD | Type: Credit
Scenario
ABC Corporation runs biweekly payroll for 500 employees. Payroll is processed by their third-party payroll provider and submitted to the ODFI as an ACH PPD Credit batch. Effective Entry Date is Friday.
Processing Timeline
| Date | Day | Event | Action / Outcome |
|---|---|---|---|
| Wednesday | D-2 | Payroll file submitted to ODFI | ODFI validates NACHA file format, hash totals, Effective Entry Date. File accepted. |
| Wednesday | D-2 | ODFI transmits to FedACH | File transmitted in FedACH evening window. FedACH sorts entries by receiving institution. |
| Thursday | D-1 | RDFI receives entries | Entries delivered to each employee's RDFI. RDFIs queue entries for Friday posting. |
| Friday | D (Effective Date) | Settlement | Net settlement occurs between ODFI and RDFIs through Federal Reserve accounts. Funds move. |
| Friday | D | RDFI posts credits | Employee account balances updated. Funds available to employees by 9:00 AM (per NACHA rules). |
Operations Note
The "2 banking days before Effective Entry Date" rule is NACHA's recommended earliest submission. Some ODFIs allow submission up to 5 days in advance (held in a queue). Confirm your ODFI's holding rules before scheduling recurring payroll files.
S-02: Same-Day ACH Credit — Urgent Vendor Payment
Rail: ACH | SEC Code: CCD | Type: Same-Day Credit
Scenario
A corporate treasury team needs to pay a vendor $85,000 today. Standard ACH would settle tomorrow. The payment qualifies for Same-Day ACH (amount under $1M, CCD entry, both banks participate in SDA).
| Time (ET) | Event | Action / Outcome |
|---|---|---|
| 10:00 AM | Treasury initiates same-day payment | Payment entered in corporate banking portal. CCD entry flagged for Same-Day ACH. |
| 10:20 AM | ODFI validates and queues | ODFI confirms: amount ≤ $1M, CCD code eligible, Receiving Bank participates in SDA. Entry held for Window 1 cut-off. |
| 10:30 AM | SDA Window 1 cut-off | ODFI transmits batch to FedACH before 10:30 AM deadline. Same-Day ACH fee of $0.052 applied. |
| ~12:00 PM | RDFI receives entry | FedACH delivers entries to RDFI. RDFI queues for posting. |
| 1:30 PM | Funds available at RDFI | NACHA requires RDFI to make funds available by 1:30 PM for Window 1 entries. Vendor account credited. |
| 1:30 PM | Settlement | Net settlement between ODFI and RDFI through Federal Reserve accounts. |
S-03: ACH Return — Insufficient Funds (R01)
Rail: ACH | Return Code: R01 | Type: Debit Return
Scenario
A consumer has a monthly recurring debit authorization (PPD) for a gym membership of $49.99. On the debit date, the consumer's account has insufficient funds. The RDFI initiates an R01 return.
| Date | Event | Action / Outcome |
|---|---|---|
| D | Originator submits PPD debit | Gym's billing system submits debit file to ODFI. ODFI transmits to ACH Operator. |
| D+1 | RDFI posts debit — NSF detected | RDFI attempts to post $49.99 debit. Account balance is $12.33 — insufficient. RDFI initiates R01 return. |
| D+2 | R01 return sent to ODFI | RDFI must return within 2 banking days of settlement. Return transmitted to ACH Operator, routed to ODFI. |
| D+2/D+3 | ODFI notifies Originator | ODFI posts R01 return credit to Originator's account and notifies the gym's billing system. |
| Within 180 days | Originator re-presents | Originator may re-present the entry up to 2 more times within 180 days of the original return. Must use new effective date. |
Return Rate Monitoring
If this Originator's R01 return rate for consumer PPD debits exceeds 3.0% in the prior 60 days, the ODFI must take action — which may include suspending the Originator's ACH origination access. Monitor return rates daily.
S-04: ACH Unauthorized Debit Dispute (R10)
Rail: ACH | Return Code: R10 | Type: Consumer Dispute
Scenario
A consumer contacts their bank (RDFI) 15 days after their monthly statement, claiming they never authorized a $120 debit from a subscription service.
| Date | Event | Action / Outcome |
|---|---|---|
| D | Original debit posted | PPD debit of $120 posted to consumer account. |
| D+45 | Consumer files dispute | Consumer calls bank. Claims no authorization was given. Bank opens investigation per Regulation E. |
| D+45 to D+55 | Bank investigates | Bank contacts Originator via ODFI to request proof of authorization (written authorization or recorded consent). |
| D+55 | Provisional credit issued | Regulation E: Bank must provide provisional credit within 10 business days of receiving the dispute. $120 credited to consumer account. |
| D+60 | R10 return initiated | Originator cannot produce authorization evidence within NACHA timeframe. RDFI initiates R10 return to ODFI. ODFI debits Originator's account. |
| D+60+ | Provisional credit confirmed | Consumer keeps the $120 credit. Investigation closed. ODFI may initiate NACHA compliance process against Originator. |
S-05: Fedwire — Large-Value Corporate Settlement
Rail: Fedwire | Message: pacs.008 (ISO 20022)
Scenario
A corporate client is closing a real estate acquisition at 2:00 PM ET today. The closing requires $4.2 million wired to the title company's account at another bank by 3:00 PM ET.
| Time (ET) | Event | Action / Outcome |
|---|---|---|
| 1:15 PM | Wire request received | Corporate banking receives wire instruction. Ops team initiates processing. OFAC screening runs — no match. |
| 1:20 PM | Compliance clearance | $4.2M wire triggers secondary review per BSA threshold. Compliance confirms: legitimate acquisition, documentation on file. Approved. |
| 1:25 PM | pacs.008 message constructed | Payment hub generates ISO 20022 pacs.008 with UETR, beneficiary details, purpose code CORT (trade settlement). |
| 1:30 PM | Submitted to Fedwire | Message sent via FedLine to Fedwire Funds Service. Federal Reserve validates and processes. |
| 1:30 PM | RTGS Settlement | Fedwire debits Sending Bank's Fed account $4.2M. Credits Receiving Bank (title company's bank) Fed account $4.2M. Irrevocable. |
| 1:32 PM | Receiving Bank posts credit | Title company's bank receives Fedwire credit notification (pacs.008). Posts $4.2M to title company's account. Closing proceeds. |
| 1:35 PM | Confirmation issued | Sending Bank generates wire confirmation to corporate client with UETR reference. Confirmation logged in core system. |
S-06: Fedwire Error — Wrong Beneficiary Account
Rail: Fedwire | Type: Wire Recall
Scenario
An operations analyst transposes two digits in the beneficiary account number for a $500,000 wire. The wire settles to an unintended account. The error is discovered 20 minutes after settlement.
| Time | Event | Action / Outcome |
|---|---|---|
| T+0 (2:00 PM) | Wire settles — incorrect account | Fedwire settles $500K to wrong account. Settlement is final and irrevocable. |
| T+20 min | Error discovered | Operations analyst identifies transposition error on post-send review. Escalates to Operations Supervisor immediately. |
| T+25 min | UETR identified | Ops team retrieves UETR from Fedwire outgoing log. This is the primary reference for all recall communications. |
| T+30 min | Receiving Bank contacted | Ops Supervisor calls Receiving Bank's Wire Operations desk directly. Provides: UETR, amount, value date, error description. Requests immediate hold on beneficiary account. |
| T+45 min | Written recall request sent | Formal recall request (camt.056 if SWIFT member; written email if not) sent with UETR and "TECH - technical error" reason code. |
| T+1 business day | Receiving Bank responds | Scenario A: Funds still in account — Receiving Bank agrees to return. Wire back sent for $500K. Issue resolved. Scenario B: Account holder has withdrawn funds — Receiving Bank cannot return. Escalate to Legal. |
| T+1 business day | Incident report filed | Ops Manager files internal incident report. Compliance reviews for SAR requirement if funds are not recovered. |
S-07: SWIFT — Cross-Border USD to EUR Payment
Rail: SWIFT | Message: MT 103 (MX migration pending)
Scenario
A US importer pays a German supplier EUR 250,000 (equivalent USD). The payment must reach the supplier's account at Deutsche Bank Frankfurt by Wednesday value date.
| Date / Time | Event | Action / Outcome |
|---|---|---|
| Monday 9:00 AM ET | Wire instruction received | Customer submits SWIFT wire request: Deutsche Bank BIC, beneficiary IBAN, EUR 250,000 equivalent, value date Wednesday. |
| Monday 9:15 AM | OFAC & Sanctions screening | All parties screened: customer, beneficiary (German entity), Deutsche Bank. No matches. Approved. |
| Monday 9:20 AM | FX conversion | USD amount calculated based on spot EUR/USD rate. USD debited from customer account. EUR nostro position checked. |
| Monday 9:30 AM | MT 103 transmitted | MT 103 message sent via SWIFT to US correspondent of Deutsche Bank. UETR assigned. gpi Tracker updated: ACSP. |
| Monday afternoon | Correspondent processes | US correspondent bank receives MT 103, performs own OFAC screening, forwards to Deutsche Bank Frankfurt via internal network or SWIFT. |
| Tuesday morning (CET) | Deutsche Bank receives | Deutsche Bank receives payment instruction. Processes it against EUR accounts. Value date set to Wednesday. |
| Wednesday | Value date — funds credited | Deutsche Bank credits German supplier's account on Wednesday value date. gpi Tracker updated: ACCC. Confirmation sent back to originating bank. |
S-08: SWIFT Recall — gSRP Process
Rail: SWIFT | Type: Cross-Border Payment Recall
Scenario
A business customer discovers that $180,000 was sent to the wrong beneficiary bank — the SWIFT BIC entered was for a bank in Singapore instead of Malaysia. The payment was sent this morning.
| Time | Event | Action / Outcome |
|---|---|---|
| T+0 | Error identified | Customer calls bank. Operations validates error: wrong BIC. UETR retrieved from SWIFT gpi Tracker. |
| T+1 hour | gpi Tracker status checked | Status shows ACSP — payment still in processing chain. Funds not yet credited to final beneficiary. |
| T+1.5 hours | camt.056 recall submitted | Operations submits Payment Cancellation Request (camt.056) via SWIFT Tracker gSRP with reason CUST (customer request). All banks in chain notified. |
| T+4 hours | Singapore bank responds | Singapore bank (wrong destination) sends camt.029 — confirms payment has not been credited. Will return the funds. Status: PDNG. |
| Next business day | Funds returned | Singapore bank sends SWIFT return. Funds received back into nostro account. Customer account re-credited. gpi Tracker: resolved. |
| Next business day | Correct payment re-sent | Operations initiates new MT 103 to correct Malaysian bank BIC. Customer notified of resolution. |
S-09: RTP — Instant Consumer Payment
Rail: RTP | Type: Credit Push
Scenario
A small business owner needs to pay a freelancer $3,500 at 8:00 PM on a Saturday. ACH would not post until Monday. Fedwire is closed. The business uses RTP.
| Time | Event | Action / Outcome |
|---|---|---|
| 8:00 PM Sat | Business initiates RTP payment | Enters amount $3,500, freelancer's account number and routing number (confirmed RTP participant). Payment submitted. |
| 8:00:02 PM | OFAC screening | Automated OFAC screening — no match. Continues. |
| 8:00:04 PM | Submitted to TCH RTP | pacs.008 message sent to TCH RTP system. TCH validates and routes to Receiving Bank. |
| 8:00:06 PM | Receiving Bank accepts | Freelancer's bank validates account — open and valid. Accepts payment. Credits $3,500 to freelancer's account. |
| 8:00:07 PM | TCH Settlement | TCH debits Business's bank prefunded position. Credits Freelancer's bank. Settlement final and irrevocable. |
| 8:00:08 PM | Confirmations sent | Business receives "Payment Sent" confirmation. Freelancer receives "Payment Received" push notification from their bank. Total elapsed: ~8 seconds. |
S-10: RTP — Authorized Push Payment Fraud Response
Rail: RTP | Type: Fraud / No Reversal Available
Scenario
A consumer was deceived by a scammer posing as their bank's fraud department. They were convinced to authorize a $12,000 RTP payment to "secure their account." They realize the fraud 30 minutes later and contact their bank.
| Time | Event | Action / Outcome |
|---|---|---|
| T+0 | RTP payment sent by consumer | Consumer authorized the payment — it was not unauthorized. RTP is irrevocable. No reversal mechanism exists. |
| T+30 min | Consumer reports fraud | Consumer contacts bank. Bank opens fraud investigation. Important: this is APP (Authorized Push Payment) fraud, not an unauthorized transaction — Regulation E protections do not automatically apply. |
| T+1 hour | Bank contacts Receiving Bank | Bank calls Receiving Bank's fraud operations team urgently. Requests voluntary freeze of beneficiary account and return of funds. |
| T+2 hours | Receiving Bank responds | Best case: Beneficiary account is a mule account. Receiving Bank freezes it voluntarily and returns funds. Worst case: Funds already moved out (second hop). Recovery unlikely. |
| T+1 day | SAR filing evaluated | Bank's BSA/AML team evaluates SAR requirement. If scammer pattern identified across multiple customers, file SAR with FinCEN. |
| Ongoing | Process improvement | Bank reviews its RTP fraud controls: Were appropriate friction points in place for $12,000 first-time beneficiary? Were behavioral analytics triggered? Review for control gaps. |
S-11: FedNow — Community Bank Instant Payment
Rail: FedNow | Type: Credit Push via Correspondent
Scenario
A small community bank (not a direct FedNow participant) uses its core banking vendor's FedNow connection to process an instant payment for a business customer.
| Time | Event | Action / Outcome |
|---|---|---|
| 10:30 AM | Business customer initiates | Customer submits $8,500 payment to supplier via community bank's mobile banking app. Bank confirms supplier's bank participates in FedNow. |
| 10:30:03 AM | Core banking vendor processes | Community bank's core banking system (via FedNow-certified vendor) generates pacs.008. Submits via vendor's FedLine connection to FedNow. |
| 10:30:04 AM | FedNow routes to Receiving Bank | FedNow receives message. Validates format and routes to supplier's bank (direct FedNow participant). |
| 10:30:05 AM | Settlement | FedNow debits community bank's settlement account (held at vendor/correspondent). Credits supplier bank's Fed master account. Settlement immediate and final. |
| 10:30:06 AM | Supplier account credited | Supplier's bank posts $8,500 to supplier account. Notification sent to supplier. Total time: ~3 seconds. |
S-12: Rail Selection Decision — Operations Reference
Type: Decision Support
When to Use Which Rail
Operations staff frequently need to advise customers or make routing decisions. This table provides the key criteria for rail selection.
| Payment Need | Recommended Rail | Key Reason |
|---|---|---|
| Domestic payroll, 500+ employees, settled next day | ACH (PPD Credit, standard) | Lowest cost, NACHA-compliant, appropriate timeline |
| Domestic payroll, urgent correction needed today | Same-Day ACH (PPD, Window 1 or 2) | Same-day settlement, low cost vs. wire |
| Real estate closing, $4.5M, needs to settle by 3 PM today | Fedwire | High-value, time-critical, same-day finality, irrevocable |
| International payment to German supplier, EUR, T+2 | SWIFT (MT 103 / pacs.008) | Only cross-border rail; SWIFT gpi for tracking |
| Consumer P2P payment on a Sunday night | RTP or FedNow | Instant, 24/7/365, ACH/Fedwire not available or too slow |
| Instant payment to a small credit union customer | FedNow | Broader community bank / credit union reach than RTP currently |
| Small consumer bill payment, non-urgent | ACH (PPD or WEB Debit) | Lowest cost, appropriate for recurring non-urgent consumer debits |
| $2M B2B urgent domestic payment, 4:00 PM | Fedwire (check Fedwire cut-off); RTP if ≤$1M | Fedwire for over $1M and time-critical; RTP if amount qualifies and Fedwire window has passed |