A Notification of Change (NOC) — SEC code COR — is a non-dollar entry sent by an RDFI to the ODFI to flag information that needs correcting on a previously posted entry. NOCs do not reject the original entry; they tell the Originator what to update before the next entry to that Receiver.
Use this module to triage NOCs quickly and consistently:
- Section 1 gives a scanable index of all NOC codes (corrections C01–C14 and refused NOCs C61–C69).
- Section 2 explains each code with official description, practical scenario, the field(s) to update, and handling timing.
For production decisions, always follow your ODFI/RDFI guidance and the latest NACHA Operating Rules.
Section 1 — All NOC Codes
Coverage: C01–C14 corrections plus C61–C69 refused NOCs (C08 reserved/unused).
Incorrect DFI Account Number
Incorrect Routing Number
Incorrect Routing Number and Incorrect DFI Account Number
Incorrect Individual Name / Receiving Company Name
Incorrect Transaction Code
Incorrect DFI Account Number and Incorrect Transaction Code
Incorrect Routing Number, Incorrect DFI Account Number, and Incorrect Transaction Code
Incorrect Individual Identification Number
Incorrect Company Name
Incorrect Company Identification
Incorrect Company Name and Incorrect Company Identification
Addenda Format Error
Incorrect SEC Code for Outbound International Payment
Misrouted Notification of Change
Incorrect Trace Number
Incorrect Company Identification Number
Incorrect Individual Identification Number
Incorrectly Formatted Corrected Data
Incorrect Discretionary Data
Routing Number Not from Original Entry Detail Record
DFI Account Number Not from Original Entry Detail Record
Incorrect Transaction Code
Section 2 — Code Details and Use Cases
Each entry includes the official NACHA description, practical use case, the field(s) to correct, direction (RDFI→ODFI for C01–C14, ODFI→RDFI for C61–C69), and required action timing.
Wording below is grounded in NACHA Notification of Change definitions; always cross-check against your processor and your licensed copy of the Nacha Operating Rules.
C01
AccountIncorrect DFI Account Number
Official NACHA description
The DFI account number on the original entry is incorrect or formatted incorrectly. The corrected account number is provided in positions 1–17 of the Corrected Data field of the Addenda98 record.
When this is used
The most common NOC. Triggered when the Originator captured an account number that differs from what the RDFI has on file — typically a typo at enrollment, a transposed digit, or an account number that has been reissued. The original entry posted (or will post) successfully because the RDFI was able to identify the correct account; the NOC is the bank telling the Originator to fix the record so the next entry carries the right number.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. RDFI → ODFI → Originator sends a Notification of Change using C01, within 2 banking days from Settlement of the original entry. Originator must apply the correction before the next entry to the Receiver.
Clarification: NACHA requires the Originator to apply the correction within 6 banking days of receipt of the NOC, or before the next ACH entry to that Receiver — whichever is later.
C02
AccountIncorrect Routing Number
Official NACHA description
A once-valid Routing/Transit Number must be changed. The corrected 9-digit routing number is provided in positions 1–9 of the Corrected Data field.
When this is used
Issued when the routing number used on the entry is no longer valid for the destination institution — most often because of a bank merger, acquisition, or routing-number consolidation where the surviving institution uses a different RTN. The account number itself remains unchanged. Originators should not assume the new RTN applies to all accounts at the old RTN; it only applies to the specific Receivers identified in NOCs.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. RDFI → ODFI → Originator sends a Notification of Change using C02, within 2 banking days from Settlement of the original entry. Originator must apply the correction before the next entry to the Receiver.
Clarification: NACHA requires the Originator to apply the correction within 6 banking days of receipt of the NOC, or before the next ACH entry to that Receiver — whichever is later.
C03
AccountIncorrect Routing Number and Incorrect DFI Account Number
Official NACHA description
A once-valid routing number must be changed, and that change has cascaded into a change to the DFI account number structure as well. Both fields must be updated. Corrected Data positions 1–9 carry the new RTN; positions 13–29 carry the new account number.
When this is used
Combination of C01 and C02. Most often the result of a bank merger where the surviving institution renumbered both the routing number and the customer account numbers — for example, mapping legacy account numbers into a new core banking system. Both pieces must be applied in the same update.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. RDFI → ODFI → Originator sends a Notification of Change using C03, within 2 banking days from Settlement of the original entry. Originator must apply the correction before the next entry to the Receiver.
Clarification: NACHA requires the Originator to apply the correction within 6 banking days of receipt of the NOC, or before the next ACH entry to that Receiver — whichever is later.
C04
IdentityIncorrect Individual Name / Receiving Company Name
Official NACHA description
The Individual Name (consumer entries) or Receiving Company Name (corporate entries) on the original entry is incorrect or has changed. The corrected name is provided in the Corrected Data field.
When this is used
Triggered by name changes (marriage, divorce, legal name change) or by name mismatches at enrollment where the Originator captured a nickname rather than the legal name on the account. Identifying-information NOCs are important for entries that depend on name matching — federal benefit payments, payroll, and any entries where the RDFI cross-checks name against account.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. RDFI → ODFI → Originator sends a Notification of Change using C04, within 2 banking days from Settlement of the original entry. Originator must apply the correction before the next entry to the Receiver.
Clarification: NACHA requires the Originator to apply the correction within 6 banking days of receipt of the NOC, or before the next ACH entry to that Receiver — whichever is later.
C05
FormatIncorrect Transaction Code
Official NACHA description
The Transaction Code on the entry is incorrect for the destination account type. The corrected two-digit Transaction Code is provided in the Corrected Data field.
When this is used
Most often a checking-vs-savings mismatch — the entry was sent with a checking transaction code (e.g., 22 or 27) but the destination is a savings account, or vice versa. Originator typically captured the wrong account type at enrollment. The fix is updating the Transaction Code mapping for the Receiver record.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. RDFI → ODFI → Originator sends a Notification of Change using C05, within 2 banking days from Settlement of the original entry. Originator must apply the correction before the next entry to the Receiver.
Clarification: NACHA requires the Originator to apply the correction within 6 banking days of receipt of the NOC, or before the next ACH entry to that Receiver — whichever is later.
C06
AccountIncorrect DFI Account Number and Incorrect Transaction Code
Official NACHA description
Both the DFI Account Number and the Transaction Code must be changed. Corrected Data carries the new account number plus the new Transaction Code.
When this is used
Combination of C01 and C05. Typical scenario: the Originator routed a payroll deposit to what they believed was the employee's checking account, but the employee actually maintains a different savings account at the same RDFI — both the account number and the account-type code need to be updated.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. RDFI → ODFI → Originator sends a Notification of Change using C06, within 2 banking days from Settlement of the original entry. Originator must apply the correction before the next entry to the Receiver.
Clarification: NACHA requires the Originator to apply the correction within 6 banking days of receipt of the NOC, or before the next ACH entry to that Receiver — whichever is later.
C07
AccountIncorrect Routing Number, Incorrect DFI Account Number, and Incorrect Transaction Code
Official NACHA description
Three-field correction: routing number, account number, and transaction code all need to change. The Corrected Data field carries all three pieces in positions defined by the NACHA Operating Rules.
When this is used
The full three-field NOC. Almost always tied to a major bank merger or core-system migration — the surviving institution has new RTNs, renumbered accounts, and a different policy on which transaction codes map to which account types. Originators handling large recurring volumes (payroll providers, billers) typically see C07 cluster around merger events.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. RDFI → ODFI → Originator sends a Notification of Change using C07, within 2 banking days from Settlement of the original entry. Originator must apply the correction before the next entry to the Receiver.
Clarification: NACHA requires the Originator to apply the correction within 6 banking days of receipt of the NOC, or before the next ACH entry to that Receiver — whichever is later.
C09
IdentityIncorrect Individual Identification Number
Official NACHA description
The Individual Identification Number on the entry — used by the Receiver's bank to map the entry to a specific customer record — is incorrect. The corrected Individual ID is provided in the Corrected Data field.
When this is used
Common in payroll and bill-pay scenarios where the Originator carries a customer-facing ID (employee ID, account suffix, customer reference) that the RDFI uses to identify the specific party. Most often arises when the RDFI changed its internal customer numbering, or when the Originator originally captured a wrong ID. Note: C08 is reserved/unused by NACHA — the sequence skips from C07 to C09.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. RDFI → ODFI → Originator sends a Notification of Change using C09, within 2 banking days from Settlement of the original entry. Originator must apply the correction before the next entry to the Receiver.
Clarification: NACHA requires the Originator to apply the correction within 6 banking days of receipt of the NOC, or before the next ACH entry to that Receiver — whichever is later.
C10
IdentityIncorrect Company Name
Official NACHA description
The Company Name carried in the Batch Header (positions 5–20) is no longer valid and must be changed. The corrected Company Name is provided in the Corrected Data field.
When this is used
Sent when the Originator's company name has changed (rebrand, merger, legal name change) but origination is still going out under the old name. Receivers and RDFIs use the Company Name as the customer-facing identifier on bank statements; a stale name causes customer-service confusion and increases unauthorized-debit (R10/R11) risk because Receivers may not recognize the Originator on their statements.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. RDFI → ODFI → Originator sends a Notification of Change using C10, within 2 banking days from Settlement of the original entry. Originator must apply the correction before the next entry to the Receiver.
C11
IdentityIncorrect Company Identification
Official NACHA description
The Company Identification (Batch Header positions 41–50) is no longer valid and must be changed. The corrected Company ID is provided in the Corrected Data field.
When this is used
The Company ID is the unique 10-character identifier — typically Tax ID prefixed with a designator — that ties batches back to the Originator. Triggered when an Originator's tax ID has changed (entity restructuring) or when the agreed Company ID with the ODFI has been updated. Receivers can place blocks on specific Company IDs; using a stale ID can cause unexpected returns.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. RDFI → ODFI → Originator sends a Notification of Change using C11, within 2 banking days from Settlement of the original entry. Originator must apply the correction before the next entry to the Receiver.
C12
IdentityIncorrect Company Name and Incorrect Company Identification
Official NACHA description
Both the Company Name and Company Identification in the Batch Header must be changed. The Corrected Data field carries both.
When this is used
Combination of C10 and C11. Typical of corporate-restructuring events where the Originator both rebranded and changed tax-identification structure — for example, a parent company absorbing a subsidiary, or a holding company taking on the operating identity. Both Batch Header fields must be updated together.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. RDFI → ODFI → Originator sends a Notification of Change using C12, within 2 banking days from Settlement of the original entry. Originator must apply the correction before the next entry to the Receiver.
C13
FormatAddenda Format Error
Official NACHA description
The format of an Addenda Record on the original entry was invalid. The Originator must review the addenda format and correct it using only ANSI standards or NACHA-endorsed banking conventions before originating the next entry.
When this is used
Specific to entries that carry addenda — most often CTX (with multiple addenda for remittance), CCD with single addenda, or IAT (which mandates an extensive addenda chain). The RDFI could process the entry but flagged the addenda content as malformed. Common causes: non-ANSI characters, mis-positioned subfields, or invalid CTX X12-820 segments. Resolution lives in the Originator's file-construction logic.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. RDFI → ODFI → Originator sends a Notification of Change using C13, within 2 banking days from Settlement of the original entry. Originator must apply the correction before the next entry to the Receiver.
C14
FormatIncorrect SEC Code for Outbound International Payment
Official NACHA description
The RDFI or Gateway has identified the entry as an outbound international payment (the Receiver's account is held outside the U.S. or the funds are destined for a foreign correspondent) and is requesting that future entries to this Receiver be identified as IAT entries.
When this is used
Critical compliance NOC. The Originator sent a domestic SEC code (PPD, CCD, or CTX) when the underlying payment was actually cross-border. NACHA rules and BSA/OFAC compliance require all cross-border ACH activity to be coded as IAT, which carries the additional addenda chain identifying foreign correspondents. Failure to convert future entries to IAT exposes the Originator to BSA/AML and OFAC violations.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. RDFI / Gateway → ODFI → Originator sends a Notification of Change using C14, within 2 banking days from Settlement of the original entry. Originator must apply the correction before the next entry to the Receiver.
C61
RefusedMisrouted Notification of Change
Official NACHA description
The financial institution preparing the NOC entry placed the incorrect routing number in the Receiving DFI Identification field. The NOC has reached the wrong ODFI and is being refused.
When this is used
Used by an ODFI to refuse an incoming NOC that does not belong to it — the RDFI sent the COR entry to the wrong institution. The RDFI must correct the destination routing and resubmit the NOC.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. ODFI → RDFI (refused NOC) sends a Notification of Change using C61, within Within 15 days of receipt of the NOC. Originator must apply the correction before the next entry to the Receiver.
Clarification: refused NOCs travel ODFI → RDFI. Originators do not act on these directly; the RDFI must correct and resubmit the NOC.
C62
RefusedIncorrect Trace Number
Official NACHA description
The Original Entry Trace Number contained in the Addenda98 record does not match a trace number originated by this ODFI, or is otherwise invalid.
When this is used
The ODFI cannot match the NOC back to an original entry. Typically a transcription error in the Addenda98 by the RDFI, or an attempt to issue an NOC against an entry that did not originate from this ODFI. RDFI must identify the correct Original Entry Trace Number and resubmit.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. ODFI → RDFI (refused NOC) sends a Notification of Change using C62, within Within 15 days of receipt of the NOC. Originator must apply the correction before the next entry to the Receiver.
Clarification: refused NOCs travel ODFI → RDFI. Originators do not act on these directly; the RDFI must correct and resubmit the NOC.
C63
RefusedIncorrect Company Identification Number
Official NACHA description
The Company Identification Number on the NOC does not match the Company ID associated with the original entry as recorded by the ODFI.
When this is used
The Company ID carried on the COR does not align with what the ODFI has on file for the original entry, so the ODFI cannot route the NOC to the right Originator. Often the result of an RDFI staff entry error when constructing the NOC.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. ODFI → RDFI (refused NOC) sends a Notification of Change using C63, within Within 15 days of receipt of the NOC. Originator must apply the correction before the next entry to the Receiver.
Clarification: refused NOCs travel ODFI → RDFI. Originators do not act on these directly; the RDFI must correct and resubmit the NOC.
C64
RefusedIncorrect Individual Identification Number
Official NACHA description
The Individual Identification Number on the NOC does not match the Individual ID associated with the original entry.
When this is used
Mirrors C63 at the individual level — the COR's Individual ID does not match what was on the original Entry Detail. ODFI cannot reconcile the NOC against its origination history.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. ODFI → RDFI (refused NOC) sends a Notification of Change using C64, within Within 15 days of receipt of the NOC. Originator must apply the correction before the next entry to the Receiver.
Clarification: refused NOCs travel ODFI → RDFI. Originators do not act on these directly; the RDFI must correct and resubmit the NOC.
C65
RefusedIncorrectly Formatted Corrected Data
Official NACHA description
The Corrected Data field of the Addenda98 record is formatted incorrectly — wrong field positions, invalid characters, or content that does not match the Change Code's required format.
When this is used
The COR is structurally correct, but the actual correction payload is unusable. For example, a C03 NOC where the Corrected Data does not respect the 1–9 routing / 13–29 account positional format. The Originator cannot apply a correction it cannot parse.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. ODFI → RDFI (refused NOC) sends a Notification of Change using C65, within Within 15 days of receipt of the NOC. Originator must apply the correction before the next entry to the Receiver.
Clarification: refused NOCs travel ODFI → RDFI. Originators do not act on these directly; the RDFI must correct and resubmit the NOC.
C66
RefusedIncorrect Discretionary Data
Official NACHA description
The Discretionary Data field on the NOC contains invalid or unexpected content.
When this is used
Less common refusal. The discretionary-data position is intended for ODFI-defined content; an NOC arriving with content the ODFI cannot interpret may be refused at the ODFI's option, particularly when that content is needed for routing the NOC to the right Originator internally.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. ODFI → RDFI (refused NOC) sends a Notification of Change using C66, within Within 15 days of receipt of the NOC. Originator must apply the correction before the next entry to the Receiver.
Clarification: refused NOCs travel ODFI → RDFI. Originators do not act on these directly; the RDFI must correct and resubmit the NOC.
C67
RefusedRouting Number Not from Original Entry Detail Record
Official NACHA description
The Original DFI Identification field in the Addenda98 record does not match the routing number of the original Entry Detail Record.
When this is used
The RDFI populated the NOC's Original DFI Identification with a routing number that does not correspond to the actual original entry. Frequently caused by RDFI systems substituting their current RTN rather than echoing the original RTN that the Originator used. Refused because the ODFI cannot reconcile this NOC against its origination history.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. ODFI → RDFI (refused NOC) sends a Notification of Change using C67, within Within 15 days of receipt of the NOC. Originator must apply the correction before the next entry to the Receiver.
Clarification: refused NOCs travel ODFI → RDFI. Originators do not act on these directly; the RDFI must correct and resubmit the NOC.
C68
RefusedDFI Account Number Not from Original Entry Detail Record
Official NACHA description
The Original DFI Account Number on the NOC does not match the DFI Account Number that was on the original Entry Detail Record.
When this is used
Account-number counterpart to C67. The RDFI may have substituted the corrected (post-merger / new-customer-system) account number in the Original DFI Account Number field, when it should have echoed the original number from the Entry Detail. ODFI refuses because cross-reference fails.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. ODFI → RDFI (refused NOC) sends a Notification of Change using C68, within Within 15 days of receipt of the NOC. Originator must apply the correction before the next entry to the Receiver.
Clarification: refused NOCs travel ODFI → RDFI. Originators do not act on these directly; the RDFI must correct and resubmit the NOC.
C69
RefusedIncorrect Transaction Code
Official NACHA description
The Transaction Code on the NOC entry itself is invalid or inconsistent with the COR SEC code requirements.
When this is used
NOCs use Transaction Code 21 (credit COR) or 26 (debit COR) per NACHA rules. A Transaction Code outside this set will cause the ODFI to refuse the NOC as malformed at the protocol level.
Rule-based flow
Originator submits an ACH entry that posts (or would post) successfully. ODFI → RDFI (refused NOC) sends a Notification of Change using C69, within Within 15 days of receipt of the NOC. Originator must apply the correction before the next entry to the Receiver.
Clarification: refused NOCs travel ODFI → RDFI. Originators do not act on these directly; the RDFI must correct and resubmit the NOC.
Operational notes
- 6 banking-day rule. Originators must apply the correction within 6 banking days of receiving the NOC, or before the next ACH entry to that Receiver — whichever is later. Failure to comply may result in fines passed through your ODFI.
- C03 / C06 / C07 are multi-field corrections. The Corrected Data field carries each piece in defined positions; do not partially apply.
- C08 is reserved/unused. The sequence skips from C07 to C09 — this is intentional, not a gap.
- C13 (addenda format) and C14 (IAT coding) are file-construction fixes that live upstream in your ACH builder, not in the Receiver record.
- C61–C69 are refused NOCs, traveling ODFI → RDFI. Originators do not act on these directly; they signal that the RDFI’s NOC was malformed and must be corrected and resubmitted.
- NOCs do not reject the original entry. The original entry posted (or will post) successfully — the COR is forward-looking guidance for subsequent entries.