1. Introduction

Due to M&A (Mergers and Acquisitions) in the banking industry, most of the times banking customers face modifications in either of account number, routing number or both. Even banking customers themselves make errors sometimes for classifying the account type, like checking or saving while either initiating the ACH payment themselves or providing details to the originator i.e. customer initiating the ACH Credit transfer to a utility company or a utility company initiates the ACH Debit transaction on to the customer account. Does this mean that the ACH payment (Debit/Credit) posted on to the customer account whose account information has been modified should be rejected? Per banking regulations, the receiving bank should still process the payment but must issue a Notification of Change (NOC) to the Originator bank so that Originator bank can make changes to ACH payment within either of six working days or before sending out the next ACH payment. We will discuss that how NOC should be entertained in the originator banking system.

2. Understanding ACH

ACH i.e. Automated Clearing House System is the nationwide network that is owned by NACHA (National Automated Clearing House Association) and which manages the Credit/Debit transactions sent over by Financial Institutions in batches. ACH transactions are accumulated and sorted for transmission during a predetermined timer period instead of processing each payment separately. In theory, we can consider ACH as network which connects all financial institutions so as to use for credit/debit transactions using the rules and regulations governed by NACHA. There are mainly two networks that operate, Fed ACH and EPN (Electronic Payments Network). There are various components of ACH as mentioned below

2.1. Originator

The originator is either Bank or Person who has initiated either of ACH Credit or ACH Debit transaction. ACH Credit means that person is sending money from his/her account to recipient account. ACH Debit means person or entity withdraws funds from a recipient’s account. For Ex: A utility company initiates ACH Debit to pull funds from customer account. A utility company initiates ACH Credit in case of refunding to the customer account.

2.2. ODFI (Originating Depository Financial Institution)

ODFI is most of the times is the centralized bank that connects with NACHA to transmit ACH transactions on behalf of Originator bank. ODFI facilitates execution of regulations that are made to protect the customers from fraud and to prevent ACH returns. Not all banks use ODFI separately because of mandates and fees. In those cases, the originator bank itself holds the responsibility to follow the regulations and connect to ACH network for sending/receiving ACH transactions.

2.3. 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). The two operators exchange files between each other as well.

2.4. RDFI (Receiving Depository Financial Institution)

An RDFI receives transaction details from an ACH operator and posts the entries (debit or credit) to the account of its receivers i.e. it either debits or credits the accounts of the customer as per ACH instruction. All U.S. financial institutions have to be acting as RDFI so as to receive entries from ACH operator.

2.5. Receiver

The receiver is the person who had 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 is the example ACH transaction flow between the five ACH participants.

Figure 1. Example of ACH flow

3. 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.

3.1. NOC Processing Deadlines

The NOC are delivered from ODFI to 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 customer’s account, whichever is later, to avoid processing delays and penalties for non-compliance with NACHA regulations. The time limit has been defined by NACHA rule 2.12.1.

Figure 2. Example of NOC flow

3.2. COR - Standard Entry Class (SEC) Code

The RDFI sends NOC to ODFI using COR Standard Entry Class (SEC) code. NACHA currently allows 13 SEC codes on ACH payment which are used to reflect nature of ACH payment. For Ex: 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.

3.3. Change Reason Codes

There are number COR/Change codes from C01 to C13 and every one of them holds a different meaning to reflect the error in the ACH payment posting details. For Ex: C01 is provided by RDFI if account number is incorrect while C02 is used for incorrect routing numbers. The financial institutions have the leverage of deciding that which one of reason codes they want to process. For Ex: Financial Institution have liberty to process only C01, C02, C03, C05, C06 and C07 codes while ignoring other codes received from ODFI.

3.3.1. C01 – Incorrect Account Number

Change reason code of C01 gets issued by RDFI to ODFI if the customer account number is incorrect in ACH instruction to RDFI.

3.3.2. C02 – Incorrect Routing Number

Change reason code of C02 gets issued by RDFI to ODFI if the routing number is incorrect in ACH instruction to RDFI.

3.3.3. C03 – Incorrect Account Number and Routing Number

Change reason code of C03 gets issued by RDFI to ODFI if the customer account number and routing number are incorrect in ACH instruction to RDFI.

3.3.4. C05 – Incorrect Transaction Code

Change reason code of C05 gets issued by RDFI to ODFI if the transaction code is incorrect in ACH instruction to RDFI. This means that if the actual account type is Saving but ACH instruction has account type as Checking then C05 will get issued. If the actual account number is Checking but ACH instruction has account type as Saving then also C05 will get issued to Originator via ODFI.

3.3.5. C06 – Incorrect Account Number and Transaction Code

Change reason code of C06 gets issued by RDFI to ODFI if the customer account number is incorrect as well as account type is incorrect in ACH instruction to RDFI.

3.3.6. C07 – Incorrect Account Number, Routing Number and Transaction Code

Change reason code of C07 gets issued by RDFI to ODFI if neither of account number, routing number and account type is correct in ACH instruction to RDFI.

4. Implementation of NOC

A Notification of Change (NOC) is part of ACH returns file that originator bank is receiving from their ODFI. This return file holds dollar entries that needs to be posted on customer accounts and this file also contains the non-dollar returns that are Notification of Change. In every financial institution, there would always be a core banking platform like GPP, Finacle etc. The implementation will depend mostly on the capability of core banking platforms.

4.1. Proactive Mode

Financial Institutions can operate in proactive mode for NOC processing which means that as and when returns file would contain the NOC for ACH instruction then core banking platform would modify all scheduled and recurring instructions that are scheduled by the customer. The ideal way would also be to add notes against the instruction so that front end customer facing banking agents can look at the reason of modifying the ACH instruction and can provide insights to the customer in case customer inquiries for the reason of modification of ACH instruction. The Financial Institution should also provide communication to the customer so that customer is informed about the modification of either the account number, routing number or transaction code depending on the NOC received from ODFI.

Financial Institution needs to be mindful that if customer is originating a new ACH instruction on the same old incorrect external account, then it has to be modified based on the new updated information received as part of NOC. For doing so, the database needs to be maintained of NOC so that banks can modify the ACH instruction during scheduling before it gets recorded in the core banking platform.

The core banking platform of Financial Institution will also need to have rails so as to update the NOC database as and when NOC is received from ODFI. This is needed because then only payment processor will know of the existing NOC while scheduling the ACH payment.

If core banking platform can have the implementation of NOC database within itself then the explicit update of external NOC database is not needed.

There might be intermediate processes that would need to be built to communicate between ODFI and Core Banking Platforms and that would depend on the IT architecture of the Bank.

Figure 3. Proactive Mode of NOC Processing

4.2. Reactive Mode

Financial Institutions can operate in reactive mode for NOC processing which means that as and when returns file is received from ODFI then NOC entries should be recorded in the database and core banking platform does not need to act on NOC immediately. During the ACH cutoff time, 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.

There might be intermediate processes that would need to be built to communicate between ODFI and Core Banking Platforms and NOC database and that would depend on the IT architecture of the Bank.

Figure 4. Proactive Mode of NOC Processing

4.3. Verdict

The proactive mode is more advantageous because NOC processing is getting done during the time of returns processing and therefore NOC processing will not be in critical path of posting the ACH transactions, which would be in case of reactive approach, which has strong SLA. Moreover, the implementation is simpler because mostly all core banking platforms provide the capability to ingest standard NACHA return files that includes NOC. The implementation of NOC database in proactive mode can be executed using Event Driven Architecture where core banking platform can generate events which can be consumed by a process to update in the database. Those events can be in readable format of either XML or JSON and therefore the processing would be much simpler to create.

4.4. Case Study

Every Bank associated and following NACHA regulations for processing ACH payments has to follow NOC rules as outlined by NACHA. To name few, “First United Bank & Trust”, “Bank Five Nine”, “Northrim Bank”, “First National Bank of Michigan” are processing NOC so as to send out the corrected information to the Fed-ACH. The implementation strategy applied within the bank is not shared publicly and dependent on the organization business and application architecture. Regardless of the strategy, every bank would have the following benefits in implementing the digital NOC processing.

4.4.1. Competence and High Efficiency

Processing NOC digitally increase efficiency and competence of the Financial Institution as otherwise the modification in the ACH instruction would need to be done manually due to NACHA mandate which turns out to be much slower.

4.4.2. Reliability and NACHA Compliance

If Banks does process NOC diligently then ACH instructions would be more reliable with reduced chance of error. The RDFI can put violation on Originator Bank and Class 1, explained later, can be in action from NACHA leading to multiple penalties and warning.

4.4.3. Lower ACH Returns

RDFI might not be hesitant to return the ACH transaction due to incorrect accounting information which would lead to diminished customer experience and hence loss to Originator in terms of customer loyalty and reputational damage.

4.4.4. Scalability

The automated NOC implementation will lead to handling NOC of huge number of ACH transactions. As per NACHA reports, there are 31.45 Billion ACH transactions has been processed in 2023 which amounts to $80.1 Trillion Dollars. The correctness of ACH transactions has to be Para mounted due to large scale ACH transactions.

Figure 5. ACH transactions growth since 2014

5. ACH Rule Violation of NOC

NACHA makes sure that ACH rules are following via warnings and fines. One Financial Institution can report violation against another Financial Institution with NACHA which are mostly resolved without fine if violations are acted upon in timely and accurately fashion. However, if the issue is not resolved then NACHA can bring down following penalties Bank associated and following NACHA regulations for processing ACH.

5.1. Class 1 Rule Violation

All Financial Institution who did not resolve rule violation within a one-year period will be fined $1000, the 2nd occurrence will be fined as $2500, 3rd occurrence will be fined with $5000 and on 4th occurrence, the issue will be moved to Class-2 violation.

5.2. Class 2 Rule Violation

The fine can be placed up to $100,000/month if the issue is escalated to Class 2 and still unresolved.

5.3. Class 3 Rule Violation

If the issue is unresolved for three consecutive months, the fine will be raised to $500,000 per month.

5.4. Suspension

In extreme circumstances, the ACH Rules Enforcement Panel may direct the Originating Depository Financial Institution (ODFI) to suspend the Originator from generating ACH transactions.

6. Conclusions

As the banking landscape is evolving, careful implementation of ACH NOC is vital for processing of ACH instructions in timely manner without hassles of cost and delays. ACH NOC implementations should be adopted by all Financial Institutions so as to comply with NACHA regulations. It enhances the customer experience and advocate use of technology for benefit of customer service delivery.

ACKNOWLEDGEMENTS

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 overwhelming attitude towards helping their colleagues, encouragement and insightful feedback were instrumental in accomplishing this task.

DISCLOSURE

This section is ONLY for those who requested disclosure. The name of the experts that reviewed your paper, in case they accepted selling disclosure to you, will appear here. Each reviewer is allowed to make their own price for that, since that is a public endorsement of your findings and may be used for varied purposes.