2.5 Exception Record Formats: Return (Addenda 99) & Notification of Change (Addenda 98) Layouts

Nacha Accredited ACH Professional AAP

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: ACH Network Overview, Participants & Transaction Flow

1.1 ACH Network Structure, Governance & History 1.2 Five Key ACH Participants: Originator, ODFI, Operator, RDFI, Receiver 1.3 Third-Party Senders (TPS) and Third-Party Service Providers (TPSP) 1.4 End-to-End Transaction Flow, Clearing & Settlement Mechanics

2 Chapter 2: ACH File Architecture & Record Formatting

2.1 File Hierarchy: 94-Character Records, Blocking Factors & File Header (Type 1) 2.2 Company/Batch Header Record (Type 5) & Service Class Codes 2.3 Entry Detail Record (Type 6) & Addenda Records (Type 7) 2.4 Batch Control (Type 8), File Control (Type 9) & Entry Hash Calculations 2.5 Exception Record Formats: Return (Addenda 99) & Notification of Change (Addenda 98) Layouts

3 Chapter 3: Nacha Operating Rules Framework & Participant Warranties

3.1 Structure of Nacha Operating Rules, Rulemaking Process & Effective Dates 3.2 ODFI Warranties, Indemnifications & Participant Obligations 3.3 RDFI Warranties, Receipt Obligations & Statement Requirements 3.4 Nacha Return Rate Thresholds & Monitoring Requirements

4 Chapter 4: Standard Entry Class (SEC) Codes: Consumer Applications

4.1 PPD (Prearranged Payment and Deposit): Direct Deposit & Consumer Debits 4.2 WEB (Internet-Initiated Entries): Authorization, Authentication & Validation 4.3 TEL (Telephone-Initiated Entries): Inbound vs. Outbound Rules & Recording Requirements 4.4 CIE, MTE, POS & SHR: Machine and Point-of-Sale Consumer Entries 4.5 Same Day ACH: Windows, Limits ($1,000,000) & Eligibility Rules

5 Chapter 5: SEC Codes: Commercial, Check Conversion & Specialized Applications

5.1 CCD/CCD+ and CTX: Corporate Payments, Addenda & EDI / ASC X12 Formatting 5.2 Check Conversion SEC Codes: ARC, BOC & POP Rules and Notices 5.3 RCK (Re-presented Checks) & XCK (Destroyed Check Entries) 5.4 IAT (International ACH Transactions): Mandatory Addenda & OFAC Screening 5.5 Non-Monetary & Specialty Entries: Prenotifications, DNE & ENR

6 Chapter 6: Authorization Standards, Authentication & Record Retention

6.1 Fundamentals of Valid Authorization: Consumer vs. Commercial 6.2 E-SIGN Act Compliance, Electronic Signatures & Oral Authorizations 6.3 WEB Debit Account Validation Rule & Fraud Detection Systems 6.4 Authorization Retention (2 Years) & Copy Provision Rules

7 Chapter 7: Exception Processing: Returns & Return Reason Codes

7.1 Return Processing Overview: Two-Banking-Day Rule vs. Extended Return Rule 7.2 Administrative & Operational R-Codes (R01-R04, R08, R16, R17) 7.3 Unauthorized Consumer Returns: R05, R07, R10, R11 & The WSUD 7.4 Unauthorized Corporate Debits: R29, Contract Rights & the UCC Article 4A Boundary 7.5 Dishonored Returns (R61-R70) & Contested Dishonored Returns (R71-R76)

8 Chapter 8: Exception Processing: Notifications of Change (NOC) & Reversals

8.1 Notification of Change (NOC / COR): Structure & Change Codes (C01-C07) 8.2 NOC Timelines: RDFI Origination & Originator 6-Day Mandatory Action 8.3 Reversing Entries & Reversal Files: 5-Day Deadline & Erroneous Reasons 8.4 Federal Reclamation Procedures & Deceased Beneficiary Handling

9 Chapter 9: ACH Risk Management, Fraud Monitoring & Exposure Controls

9.1 ACH Risk Taxonomy: Credit, Operational, Fraud, Systemic & Compliance Risks 9.2 ODFI Originator Onboarding, Underwriting & Exposure Limits 9.3 Third-Party Sender (TPS) Due Diligence, Monitoring & Registration 9.4 Fraud Schemes: Business Email Compromise (BEC), Account Takeover & Controls 9.5 The 2026 Fraud Monitoring Rules: ODFIs, Originators, TPSPs & Third-Party Senders 9.6 RDFI ACH Credit Monitoring & the False Pretenses Definition 9.7 ACH Data Security: Article One, Sections 1.6 and 1.7 & the ACH Security Framework 9.8 Nacha's Risk Management Portal: Contact Registry, TPS & Direct Access Registration, Terminated Originator Database 9.9 ACH Risk Assessments, Regulatory Expectations & Operational Resilience

10 Chapter 10: Legal & Regulatory Framework for ACH

10.1 Regulation E (12 CFR 1005): Consumer Protections, Disclosures & Error Resolution 10.2 Uniform Commercial Code (UCC) Article 4A: Wholesale Funds Transfers & Security Procedures 10.3 BSA/AML, SAR/CTR Reporting & OFAC Sanctions Compliance in ACH 10.4 31 CFR Part 210 (The Green Book), Reg CC, Reg D & Reg J Interactions

11 Chapter 11: Nacha Rules Compliance Audit & National System of Fines

11.1 Annual ACH Rules Compliance Audit (Article One, §1.2.2): Scope & Requirements 11.2 Auditor Independence & 6-Year Audit Record Retention 11.3 National System of Fines: Complaint Process, Panel Review & Fine Classes 11.4 The Nacha Rules Effective-Date Calendar: 2026 Through 2028

12 Chapter 12: Alternative & Complementary Payment Systems

12.1 Fedwire Funds Service & CHIPS vs. ACH Network 12.2 Instant Payments: RTP and FedNow vs. Same Day ACH 12.3 Card Networks, Check 21 & Interoperability Across Payment Rails

2.5 Exception Record Formats: Return (Addenda 99) & Notification of Change (Addenda 98) Layouts

Key Takeaways Explain This Topic AI

A Return Entry is built from a copy of the original Entry Detail Record plus a single Addenda Record carrying Addenda Type Code 99, which holds the Return Reason Code, the Original Entry Trace Number and the Original Receiving DFI Identification.

A Notification of Change uses SEC Code COR with Addenda Type Code 98, carrying the Change Code and a 29-character Corrected Data field in positions 36-64 of the addenda record.

Dishonored and contested dishonored returns reuse the Addenda Type Code 99 structure with their own reason codes, and a Refused Notification of Change reuses the 98 structure with Refused COR codes.

In a Return or NOC the roles invert: the original RDFI becomes the originating party, so the batch is built under its own routing number and carries a new Trace Number while preserving the Original Entry Trace Number for matching.

Every addenda record is 94 characters and begins with Record Type Code 7; the Addenda Type Code in positions 2-3 is what tells a receiving system how to parse the remaining 91 characters.

Last updated: August 2026

2.5 Exception Record Formats: Return (Addenda 99) & Notification of Change (Addenda 98) Layouts

Quick Reference: ACH File Formatting is only 8% of the AAP blueprint , but it is dense, factual and easy to bank if you learn the layouts. Exception traffic — returns, NOCs, dishonored returns, refused NOCs — is not a separate file format. It is the same 94-character record structure with a different Addenda Type Code in positions 2-3.

1. The Addenda Type Code Is the Parser

Every Addenda Record is Record Type Code 7 and exactly 94 characters . Positions 2-3 carry the Addenda Type Code , and that two-digit value tells a receiving system how to interpret the remaining 91 characters.

Addenda Type Code Used with Carries
02 POS, MTE, SHR Terminal identification, terminal city and state, transaction serial number

05 PPD, CCD, WEB (one addenda), CTX (up to 9,999) Payment Related Information — invoice data, ASC X12 820 remittance

10 - 18 IAT Types 10–16 are mandatory; Type 17 is optional remittance data; Type 18 is conditional correspondent-bank data

98 COR — Notification of Change and Refused NOC Change Code and Corrected Data

99 Returns , dishonored returns, contested dishonored returns Return Reason Code and original entry identifiers

Memorize the pair that matters most: 98 corrects, 99 returns.

2. The Return Addenda Record (Addenda Type Code 99)

A Return Entry is not a free-form message. The RDFI takes a copy of the original Entry Detail Record , adjusts the Transaction Code as needed to reverse the direction of the item, and attaches one Addenda Record with Addenda Type Code 99 .

Field Positions Length Contents
Record Type Code 01-01 1 Constant 7
Addenda Type Code 02-03 2 Constant 99
Return Reason Code 04-06 3 The R-code — R01 , R10 , R29 and so on
Original Entry Trace Number 07-21 15 The Trace Number of the entry being returned — the audit anchor
Date of Death 22-27 6 YYMMDD . Used only where the return reason involves a deceased Receiver

Original Receiving DFI Identification 28-35 8 First 8 digits of the RDFI routing number from the original entry

Addenda Information 36-79 44 Free-form supporting detail, used sparingly and by specific R-codes

Trace Number 80-94 15 The Trace Number assigned to this return , built from the returning institution's routing number

The Role Inversion

When an RDFI returns an entry, it is originating the return. That means:

the return travels in a batch built under the returning institution's routing number;
the addenda carries a new Trace Number in positions 80-94;

the Original Entry Trace Number in positions 07-21 is what lets the ODFI, the Originator and every downstream system match the return back to the payment.

If positions 07-21 are wrong, the return is functionally unmatched no matter how correct everything else is. This is why trace-number integrity is one of the first things an auditor samples in exception testing.

Dishonored and Contested Dishonored Returns

These reuse the same 99 structure. A dishonored return is the ODFI's response when it believes the RDFI's return was untimely or improper; a contested dishonored return is the RDFI's answer to a dishonor. They carry their own dedicated reason-code ranges, but the record architecture — Type 7 record, Addenda Type Code 99 , Return Reason Code in 04-06, Original Entry Trace Number in 07-21 — is unchanged.

3. The Notification of Change Addenda Record (Addenda Type Code 98)

A Notification of Change is a zero-dollar, non-monetary entry the RDFI originates under SEC Code COR to tell the Originator that data in a live entry was posted but needs correcting for future entries.

Field Positions Length Contents
Record Type Code 01-01 1 Constant 7
Addenda Type Code 02-03 2 Constant 98
Change Code 04-06 3 C01 through the published range — identifies what is wrong
Original Entry Trace Number 07-21 15 Trace Number of the entry that prompted the NOC
Reserved 22-27 6 Blank

Original Receiving DFI Identification 28-35 8 First 8 digits of the RDFI routing number from the original entry

Corrected Data 36-64 29 The corrected value, left-justified and blank-filled
Reserved 65-79 15 Blank
Trace Number 80-94 15 Trace Number assigned to the COR entry

The Corrected Data field is the whole point of the record, and its content is governed entirely by the Change Code. A C01 supplies a corrected account number; a C02 supplies a corrected routing number; a C03 supplies both a routing number and an account number packed into the single 29-character field. A receiving system that applies Corrected Data without first reading the Change Code will corrupt the customer record — which is precisely why the Originator's 6-Banking-Day update obligation is an operational rule, not a clerical one.

Refused Notification of Change

When the ODFI receives an NOC it cannot process — bad routing data, an untimely transmission by the RDFI, an unmatched trace — it originates a Refused NOC using the same 98 addenda structure with a Refused COR code, transmitted within 15 calendar days of the NOC's Settlement Date.

4. Worked Example: Tracing One Item Through Three Records

Northbrook Bank (routing 121000358 ) originates a PPD debit for entry sequence 4 in its batch.

Original Entry Detail Record — Trace Number in positions 80-94 is 121000350000004 (first 8 digits of the ODFI routing number plus a 7-digit ascending sequence).

The RDFI returns it R03 (No Account / Unable to Locate Account). The return addenda carries 99 in positions 02-03, R03 in 04-06, and 121000350000004 in positions 07-21. Positions 80-94 carry a new trace number built from the RDFI's routing number.

Alternatively the RDFI posts the item and sends a C01. The COR addenda carries 98 in 02-03, C01 in 04-06, 121000350000004 in 07-21, and the corrected 17-character account number left-justified in positions 36-64.

In both branches, positions 07-21 are identical. That is the field that stitches the exception back to the payment.

Exam trap: the Original Entry Trace Number is in the addenda record (positions 07-21), not in the Entry Detail Record of the return. The Entry Detail Record of a return carries its own trace in positions 80-94 like any other entry. Answer choices that place the original trace in the Type 6 record are wrong.