While there are numerous ways to transfer money, the Automated Clearing House (AHC) is one of the most widely used for making bill payments, peer-to-peer transfers, and direct deposits of paychecks. When there is a change to a customer’s account number, routing number, account type or other identifying information about an account, banking regulations mandate that the receiving bank still process the payment but must issue a Notification of Change (NOC) to the originating bank. The article gives an overview of ACH and NOC, how the flow of information happens, and then explains two approaches financial institutions can take towards NOC: reactive or proactive.
Understanding ACH
The Automated Clearing House System is a nationwide network owned by NACHA (National Automated Clearing House Association) that manages credit and debit transactions for financial institutions.
Let's look at some common terms associated with ACH:
- Originator: Either the bank or person who initiates the ACH credit or debit transaction. With an ACH credit, a person sends money from his or her account to a recipient account. With an ACH debit, a person or entity withdraws funds from a recipient’s account.
- Originating Depository Financial Institution (ODFI): An ODFI is a centralized bank that connects with NACHA to transmit ACH transactions on behalf of the originator bank. ODFI facilitates execution of regulations made to protect customers from fraud and prevent ACH returns. Not all banks use ODFI because of mandates and fees. In those cases, the originator bank itself is responsible to follow the regulations and connect to the ACH network for sending and receiving ACH transactions.
- ACH Operator: A central clearing facility that receives entries from an ODFI, distributes entries to the appropriate RDFI, and performs the settlement functions for the financial institutions. There are two ACH Operators: The Federal Reserve Bank and the Electronic Payments Network (The Clearing House).
- Receiving Depository Financial Institution (RDFI): An RDFI receives transaction details from an ACH operator and posts the debits or credits to the account of its receivers. All U.S. financial institutions must act as a RDFI to receive entries from ACH operator.
- Receiver: The receiver is the person who provided authorization to the originator to initiate the ACH transaction to either receive funds or withdraw funds from their account with the RDFI.
The following image is an example ACH transaction flow between the five ACH participants.
Understanding NOC on ACH
A Notification of Change (NOC) is a non-dollar entry that the external bank transmits for distribution back to the ACH originator if the external bank receives a prenotification or a live dollar entry for posting that contains incorrect customer account information. The Notification of Change identifies the entry that has been received at the external bank, pinpoints the specific information on that entry that is incorrect, and provides the correct information in a precise format so that the Originator can make the change.
There are specific times defined by NACHA rule 2.12.1 with how NOCs are handled. Two to know include:
- NOCs are delivered from ODFI to the Originator within 2 banking days of the settlement date.
- The originator needs to act on NOC within 6 banking days of receipt of the NOC information or prior to initiating another ACH on a customer’s account, whichever is later, to avoid processing delays and penalties for non-compliance with NACHA regulations.
NOC codes to know
The RDFI sends NOC to ODFI using a COR Standard Entry Class (SEC) code. NACHA allows 13 SEC codes on ACH payments which reflect the nature of the ACH payment. For example, certain SEC codes can only be used for consumer or retail transactions, while others are reserved for business and government transactions. “COR” is the SEC code that is used for Notification of Change or Refused Notification of Change.
There are a number COR/Change codes and each of them holds a different meaning to reflect the error in the ACH payment posting details. Financial institutions can decide which of the reason codes they want to process.
Here's a brief overview of the change codes and what they mean:
- C01 – Incorrect Account Number
- C02 – Incorrect Routing Number
- C03 – Incorrect Account Number and Routing Number
- C05 – Incorrect Transaction Code. C05 codes are issued by RDFI to ODFI if the transaction code is incorrect in the ACH instruction to RDFI. For example, if the actual account type is Saving but ACH instruction has account type as Checking then C05 will get issued.
- C06 – Incorrect Account Number and Transaction Code. Issued if the account number and the account type are both incorrect.
- C07 – Incorrect Account Number, Routing Number and Transaction Code. Issued if the account number, routing number, and account type are all incorrect.
Implementation of NOC: Reactive or Proactive?
A Notification of Change (NOC) is part of ACH returns file that the originator bank receives from their ODFI. This return file holds dollar entries that must be posted on customer accounts, and this file also contains the non-dollar returns that are Notifications of Change. The company’s core banking platform implements how these are processed.
Financial institutions can choose whether to take a proactive or reactive approach to NOCs.
Proactive Mode
In proactive mode, when ODFI transmits the ACH returns file that also includes a NOC, the core banking platform would modify all scheduled and recurring instructions that are scheduled by the customer.
Ideally, notes would be added to the ACH instructions to describe why the ACH instructions were modified, so that agents can provide that information to users who ask. The Financial Institution should also provide communication to the customer so that the customer is informed about the modification of either the account number, routing number, or transaction code depending on the NOC received from ODFI.
Financial institutions must be mindful that if a customer is originating a new ACH instruction on an incorrect external account, it must be modified based on the new updated information received as part of NOC. To do so, the financial institute must maintain the database with NOC so that banks can modify the ACH instruction during scheduling before it gets recorded in the core banking platform.
A financial institution’s core banking platform or a dedicated NOC processor will need to maintain an NOC database to record all NOC’s received from ODFI. This is needed so that all banking applications like Personal Loans, Deposits etc. can refer to the existing NOC’s while scheduling the ACH payment. If a core banking platform implements a NOC database within itself, then there is no need to have an external NOC database.
The NOC Processor would need to be built to communicate between ODFI and Core Banking Platforms which also maintains the NOC database, and its implementation would depend on the Bank's IT architecture.
Figure 2. Proactive Mode of NOC Processing
Reactive Mode
Financial institutions can operate in a reactive mode for NOC processing. This means that when a NOC is received, the NOC entries are recorded in the database and core banking platform does not need to act on NOC immediately.
During the ACH cutoff time, the core banking platform can refer to the NOC database and modify all recurring and scheduled payments based on the entries in the NOC database before sending out to ODFI to push on to ACH network which would make it as reactive approach.
Intermediate processes might need to be built to communicate between ODFI, core banking platforms, and a NOC database, depending on the IT architecture of the bank.
Figure 3. Reactive Mode of NOC Processing
Comparing the two approaches
The proactive mode is more advantageous because NOC processing is done during the time of returns processing. This means NOC processing will not be in the critical path of posting the ACH transactions which have a strict SLA.
Proactive implementation is simpler because almost all core banking platforms provide the ability to ingest standard NACHA return files that include NOCs. In a proactive mode, the implementation of a NOC database can be executed using an event-driven architecture where the core banking platform generates events which can be consumed by a process that updates the database. Those events are either XML or JSON, which are easy to read, simplifying the processing.
At Discover, we use a proactive approach to managing NOC, optimizing our cloud platform to quickly categorize and communicate about NOC to customers.
Conclusion
As the banking landscape evolves, careful implementation of ACH NOC is vital for processing ACH instructions in a timely manner. ACH NOC implementations should be adopted by all financial institutions to comply with NACHA regulations. These proactive implementations enhance the customer experience and advocate for use of technology to benefit customer service delivery.
Acknowledgement
The completion of this article would not have been possible without the support and guidance of Brian Leonard, Discover Financial Services and Roland Sanguino, Discover Financial Services. Their dedication and great attitude towards helping their colleagues, encouragement and insightful feedback were instrumental in accomplishing this task
