Money movement and financial logic

ACH, wire, SEPA, and ISO 20022 payment rails testing

Payment rails testing verifies how a product builds, sends, and reads bank payments on ACH, Fedwire, FedNow, RTP, SEPA, Swift, and Canadian AFT rails. The service covers Nacha and ISO 20022 formats, cut-off times, returns, rejects, and recalls. Buyers receive a format validation suite, timing scenarios, return and recall test cases, and bank file reconciliation checks.

What payment rails testing includes

We test what a product sends to banks, when banks accept it, and how money comes back. Sources below were checked on 2026-09-16.

Files and messages

Nacha ACH files. 94-character records in the order 1, 5, 6, 7, 8, 9, a blocking factor of 10, control totals, and the Entry Hash, per the Nacha ACH Guide for Developers. A batch control record that still counts a cancelled payment no longer matches its entry detail records, which breaks the Nacha file definition. The Nacha testing requirements page maps these checks to rule sections.
ISO 20022 messages. pain.001 and pain.002 to and from banks, pacs.008, pacs.002, and pacs.004 between banks, and camt.052, camt.053, and camt.054 reports, each checked against its schema and network usage guideline. The ISO 20022 testing requirements page lists the usage guideline rules we run.
Swift MT to MX. Since 22 November 2025, Swift routes MT 103 and MT 202 payment instructions sent between banks to contingency processing, which is chargeable from 1 January 2026, and rejects MT 102, MT 103 REMIT, MT 201, and MT 203 (Swift ISO 20022 FAQ). We check that the outbound mapping produces the MX message. Where the client runs its own Swift connection, the transaction limit and back-office flow tests follow the Swift CSP testing requirements.
Canadian AFT files. Payments Canada Standard 005 (2024 edition) sets a record length of 1464 characters for logical record types A, C, D, E, F, I, J, and Z.

Cut-off times and settlement windows

Same Day ACH. The FedACH processing schedule sets deposit deadlines of 10:30 a.m., 2:45 p.m., and 4:45 p.m. ET with settlement at 1:00, 5:00, and 6:00 p.m. ET. The ACH Operator does not reject an entry above $1,000,000 submitted in a same-day window and processes it for next-day settlement instead (Nacha guidance, 1 March 2022). A payroll run that counts on same-day settlement for such an entry delivers the wages one day late. The limit rises to $10 million on 17 September 2027 (Nacha).
ACH funds availability. From 18 September 2026, an RDFI must make a non-Same Day credit available by 9:00 a.m. RDFI local time on the Settlement Date (Nacha).
Fedwire Funds. The service opens at 9:00 p.m. ET on the preceding calendar day, with cut-offs of 6:45 p.m. ET for customer transfers and 7:00 p.m. ET for bank transfers, and does not run on Saturdays, Sundays, or Federal Reserve holidays (operating hours).
FedNow and RTP. The FedNow Operating Procedures (April 2026, version 3.6) set a network limit of $10,000,000 per pacs.008 and a 20-second timeout clock. The RTP network limit is $10 million per transaction since 9 February 2025 (The Clearing House, 4 December 2024).
SEPA SCT and SCT Inst. The SCT Rulebook 2025 v1.1, section 4.2.3, requires the amount on the Beneficiary PSP's account within one Banking Business Day. Under Article 5a(4)(c) of Regulation (EU) No 260/2012, as amended by Regulation (EU) 2024/886, the payee's PSP shall make the funds available and confirm completion within 10 seconds of the time of receipt. The SCT Inst Rulebook 2025 v1.1, section 4.2.3, has the Originator PSP lift the reservation when no confirmation arrives within 10 seconds, yet a positive confirmation can still arrive later. A product that ignores that late confirmation pays the beneficiary while the payer keeps the funds.
Canada. Lynx has used ISO 20022 since 22 November 2025 (Payments Canada, 14 January 2026). For the Real-Time Rail, Payments Canada lists a Q4 2026 launch, and the RTR By-law and Rules came into force on 24 August 2026 (Payments Canada, 30 June 2026). Status verified on 2026-09-16: the RTR is not live.

Returns, rejects, and recalls

ACH returns. R10 and R11 unauthorised returns use the extended 60-day return timeframe (Nacha). A late R10 after the customer has spent the provisional credit leaves a negative balance. The NACHA return code testing guide shows the matrix.
SEPA SCT. The Beneficiary PSP must send a Return within three Banking Business Days after Settlement Date (section 4.3.2.2). The Originator PSP must send a Recall within 10 Banking Business Days for duplicate sending or technical problems and within 13 months for fraud, and the Beneficiary PSP must respond within 15 Banking Business Days (section 4.3.2.3).
FedNow. A camt.056 return request should be sent within 60 calendar days after the pacs.008 settled, except for fraud reports and Request for Payment warranty claims, and the camt.029 response carries IPAY, RJCR, PDCR, or PECR (Operating Procedures, section 15.2).
Canadian PADs. Rule H1, section 24(a), requires best efforts reimbursement of declared-condition claims made up to 90 calendar days after a Personal PAD debit or 10 Business Days after a Business PAD debit.

Segments

Standards

Guides

Scenarios

Deliverables

Payment file format validation suite (NACHA, ISO 20022 pain and camt, SWIFT MT and MX)
An automated suite that checks every generated Nacha file, ISO 20022 pain and camt message, and Swift MT or MX message against its layout, schema, and network usage rules, for use by the engineering lead in CI.
Cut-off time and settlement timing scenarios across time zones
A scenario set that submits payments before and after each rail's cut-off, on weekends, and on bank holidays, and records the expected settlement date for the product owner and the partner bank.
Return, reject, and recall test cases
Test cases for each Nacha return code, ISO 20022 reject and return reason, and recall path in scope, with the expected customer status and reversal entry for the engineering lead and an ODFI reviewer.
Bank file reconciliation checks
Automated checks that match every sent payment to its acknowledgement, settlement, return, or statement entry and list the unmatched items for the operations lead.

How rails testing fits your release process

On every commit. The format validation suite runs in CI against the code that builds Nacha files, AFT files, and ISO 20022 messages. It compares output with approved reference files and fails the build on a changed control total, a schema error, or a usage guideline rule. Test files use synthetic routing numbers, IBANs, and BICs, and no live account data enters the pipeline.

Before release. The timing scenarios run with an injected clock across each rail's business day calendar: a payment at 4:44 p.m. and 4:46 p.m. ET, a Fedwire customer transfer at 6:46 p.m. ET, and an SCT Inst confirmation at 11 seconds. The settlement timing guide describes the calendar set. Return and recall cases replay synthetic return files and camt.056 messages into the staging environment and check the customer status after each one.

At bank or network onboarding. We run the suites against the partner bank's certification environment and package the results with message versions and test dates, for the sponsor bank or the network testing team.

After release. On the first production day, the reconciliation checks confirm that the first sent file has an acknowledgement and that the next return file loads. Returned payouts that miss the end-of-day ledger break RPAR 15(2)(b)(ii) for Canadian PSPs, as the RPAA testing requirements page sets out.

Cadence and handover. We rerun the suites before each Nacha rule effective date, each Swift Standards MX release, and each EPC rulebook version. Suites live in your repository, and evidence goes to your shared evidence folder. Your team owns the bank relationship, production credentials, cut-off configuration, and the decision to send a recall.

Sample deliverable

Sample, synthetic data

payment flow mapPayment flow map: card, ACH, and instant pay-ins and payouts

Payment flow map: card, ACH, and instant pay-ins and payouts
Step ID	From state	Event (webhook or file)	To state	Ledger effect	Test cases
PFM-CARD-01	Card pay-in created	Webhook payment.authorised for 150.00 XTS	Card pay-in authorised	No journal entry; the 150.00 XTS authorisation hold is stored as a memo record	TC-PF-001, TC-PF-002 (duplicate webhook delivery)
PFM-CARD-02	Card pay-in authorised	Webhook payment.captured for 150.00 XTS	Card pay-in captured	Dr Processor receivable 150.00 XTS / Cr Merchant payable 150.00 XTS	TC-PF-010, TC-PF-011 (capture retried with the same idempotency key)
PFM-CARD-03	Card pay-in captured	Processor settlement file line for the capture, with a 4.35 XTS fee line	Card pay-in settled	Dr Settlement bank cash 145.65 XTS and Dr Processing fee expense 4.35 XTS / Cr Processor receivable 150.00 XTS	TC-PF-020, TC-PF-021 (settlement line with no matching capture)
PFM-ACH-01	ACH debit pay-in pending	Nacha return file entry with return code R01 (Insufficient Funds)	ACH debit pay-in returned	Dr Customer available balance 200.00 XTS / Cr ACH clearing 200.00 XTS, reversing the provisional credit	TC-RL-030, TC-RL-031 (return received after the customer spent the provisional funds)
PFM-ACH-02	ACH debit pay-in settled	Nacha return file entry with return code R10 (unauthorised debit), inside the 60-day extended return window	ACH debit pay-in returned as unauthorised	Dr Customer available balance 200.00 XTS / Cr ACH clearing 200.00 XTS, with any shortfall moved to a negative balance receivable	TC-RL-032, TC-RL-033 (return that drives the customer balance below zero)
PFM-ACH-03	ACH credit payout sent	Nacha return file entry with return code R03 (No Account/Unable to Locate Account)	ACH credit payout returned	Dr ACH clearing 500.00 XTS / Cr Beneficiary payable 500.00 XTS, restoring the amount owed to the beneficiary	TC-RL-040, TC-RL-041 (payout retry blocked until bank details change)
PFM-INST-01	Instant payout submitted	ISO 20022 pacs.002 with transaction status ACSC	Instant payout completed	Dr Instant payout clearing 75.00 XTS / Cr Settlement bank cash 75.00 XTS	TC-RL-050, TC-RL-051 (pacs.002 received after the client timeout)
PFM-INST-02	Instant payout submitted	ISO 20022 pacs.002 with transaction status RJCT and reason AC04 (Closed Account Number), sent to the client as webhook payout.failed	Instant payout failed	Dr Instant payout clearing 75.00 XTS / Cr Customer available balance 75.00 XTS, reversing the payout debit	TC-RL-052, TC-RL-053 (payout.failed webhook delivered before payout.submitted)

Amounts use XTS, the ISO 4217 code reserved for testing. States, webhook names, and ledger accounts are generic, and no real account or card data appears.

Questions

How to create a NACHA file?

To create a NACHA file, write 94-character records in the order file header 1, batch header 5, entry detail 6, optional addenda 7, batch control 8, and file control 9. Compute entry counts, debit and credit totals, and the Entry Hash from the entry detail records. Pad the NACHA file with lines of 9s to a multiple of 10 lines, then validate it before sending.

What is a NACHA file format?

The NACHA file format is the ACH file layout that Appendix Three of the Nacha Operating Rules defines and the Nacha ACH Guide for Developers summarises. Every record in the NACHA file format holds 94 characters, the blocking factor is 10, and the first character sets the record type. The batch header Effective Entry Date is the banking day on which the Originator intends the batch to settle.

Can a wire be recalled?

A wire can be cancelled before the receiving bank accepts the payment order. Under UCC 4A-211(c), cancellation after acceptance is not effective unless the receiving bank agrees or a funds-transfer system rule allows it. After the beneficiary's bank accepts, a wire recall also needs an unauthorised order or a sender mistake that produced a duplicate, a wrong beneficiary, or an excess amount.

Scope your payment rails testing

Tell us which rails, file formats, and partner banks your product uses. We return a test scope with the deliverables and the first files we validate.

Scope your testing