An Originator that transmits a credit Micro Entry with an offsetting debit Micro Entry to a Receiver’s account must use the same value in the Effective Entry Date field for both Micro-Entries. The files containing those entries for the same Receiver must be submitted simultaneously, so that the entries may be submitted into the same processing window. If the Originator’s process separates the files for debits and credits, those files must be submitted one immediately following the other, as soon as possible. A slight difference in submission time (for example, seconds between) can be considered reasonable if the files are submitted close together and allows for the transactions to be submitted to the ACH Operator in the same processing window.

Yes.  Although the intent of this rule is to provide credit and offsetting debit Micro Entries to the RDFI within the same distributed file so that the RDFI can control the impact to the Receiver’s account, differences in RDFIs’ posting systems may result in credit and offsetting debit Micro Entries being posted to the Receiver’s account at different times. The Originator has nevertheless met its obligation by transmitting these transactions simultaneously for the same settlement date.

As with any other ACH credit or debit entry, the Originator must obtain the Receiver’s authorization to transmit Micro Entries to the Receiver’s account. The minimum authorization requirements are based upon the type of entry (consumer or corporate), method of authorization (internet, telephone, paper, etc.), and any applicable requirements specific to the Standard Entry Class (SEC) Code for the Micro-Entry. (See the Nacha Operating Rules Section 2.3 Authorization and Notice of Entries for general authorization requirements and Section 2.5 Provisions for Specific Types of Entries of the Nacha Operating Rules for requirements specific to SEC Code.)

Based upon the practice of Micro-Entry verification, the Originator may not wish to provide the specific dollar amount to the Receiver up front in the authorization. However, to meet the Rule obligations and to ensure that the Receiver is clear about the transaction(s) being authorized, Originators must provide a description of how the Micro Entries will be used, and the general dollar amounts that can be expected (e.g., credit entries in amounts less than $1.00, and any offsetting debits not to exceed the total amount of such credits).

The new rule provides a standardized description for Micro-Entries (ACCTVERIFY), but it does not define the use of a specific SEC Code. As with any other ACH entry, the SEC Code is determined by the account type of Receiver and the manner in which authorization is obtained. See the Nacha Operating Rules Section 2.5 Provisions for Specific Types of Entries for requirements specific to SEC Code.

The rule requires an organization using Micro-Entries to use reasonable methods to recognize and prevent suspicious activity. This requirement is different from the WEB Debit account validation requirement in that the account number for a Micro-Entry does not need to be individually validated, and Originators are not required to perform an entry-by-entry review. However, at a minimum, Originators should understand forward and return volumes to establish a baseline of normal Micro-Entry activity. Velocity monitoring, recognizing the number of times an account number is used (in various formats), in addition to the number of transactions, can also be an important tool in Originator’s fraud monitoring efforts.

No. The fraud detection requirements for Micro-Entries are in addition to and distinct from the return rate threshold monitoring required under Article Two, Subsection 2.17.2. The new rule does not impose a specific return threshold for Micro-Entries but instead requires Originators to understand and establish a baseline for normal forward and return volumes and to recognize and react to activity outside of those levels.

An ODFI is ultimately responsible for its Originators’ compliance with the Nacha Operating Rules. While the rule imposes the requirement for commercially reasonable Micro-Entry fraud detection directly on the Originator, the ODFI should also follow the current language in Article Two, Subsection 2.2.3 regarding monitoring origination and return activity for Originators and Third-Party Senders. ODFIs may want to have ACH Origination Agreements reviewed by their compliance area along with the Rules language to determine if any additional steps need to be taken.

The Micro-Entry rule permits an Originator to initiate future entries to the Receiver’s account as soon as the Originator’s process for verifying the amounts of the Micro-Entries has been completed.  Although the Rules allow the Originator to determine the specific requirements and manner in which the Receiver must confirm with the Originator the required Micro-Entry transaction information, the expectation is that the Receiver must validate the information with the Originator, who will know whether the information was correctly provided.  If the Originator has not received a response from the Receiver, the verification process is not complete, and the Originator is not permitted to originate future entries. If a return has been received, future entries cannot be originated without remedying the reason for the return.

No. Completion of the Originator’s validation process requires the Receiver’s validation of the Micro-Entry information or the return of the entry. If there has been no response from the Receiver and no return, the verification process is not complete and future entries cannot be originated. If a return has been received, future entries cannot be originated without remedying the reason for the return.

No. The rules for Micro-Entries require the name of the Originator in a Micro-Entry (as identified in the Company Name field or the Originator Name field) to reflect the same Originator that will be identified in future Entry(ies) to the Receiver’s account. The Originator may make minor variations to the content of the Company Name field or Originator Name field, such as for accounting or tracking purposes, provided that the name of the Originator remains readily recognizable to the Receiver. The Originator of a Micro-Entry must be the same entity entering into an agreement with the Receiver for future ACH entries.

No. An ACH Operator will not reject a Micro-Entry solely because it does not comply with the formatting requirements specific to Micro-Entries (example: the Micro-Entry contains an incorrect company entry description or an invalid dollar amount). Additionally, ACH Operators will not match offsetting Micro-Entries. However, RDFIs may return an improper Micro-Entry and may choose to submit Micro-Entry rule violations to Nacha’s rules enforcement process.

No, however the subject continues to be reviewed for the future. RDFIs may consider providing equal treatment to credit and offsetting debit Micro-Entries in posting and return decisions, where possible. RDFIs may consider, if repairing credit Micro-Entries, also repairing corresponding debit Micro-Entries or returning both entry types.

There are not dedicated Return Reason Codes (RRC) for Micro-Entries; RDFIs should follow the existing requirement to utilize the RRC that most closely resembles the reason for return. The chart attached provides guidance to RDFIs under certain circumstances, and Originators and ODFIs may also find it useful in interpreting returned Micro-Entries.

Yes. Debit Micro-Entries that are not properly authorized may be returned as unauthorized in accordance with the Nacha Operating Rules (as R10 within 60 days with WSUD for entries to consumer accounts, and as R29 within 2 banking days for entries to non-consumer accounts). The RDFI may return an unauthorized Micro-Entry credit using Return Reason Code R23.

If a consumer Receiver recognizes the issues with a Micro-Entry transaction, the RDFI may return the improper Micro-Entry within 60 days using Return Reason Code R11 with the completion of a Written Statement of Unauthorized Debit. If a business Receiver recognizes that the Micro-Entry is improper, or if the RDFI identifies an improper Micro-Entry to any Receiver’s account, the RDFI may return the entry as R17 within the standard, two-day return time frame.

Yes.

No. By rule, the use of Micro-Entries cannot result in a net debit to the Receiver’s account, and one or more debit Micro-Entries may not be transmitted without simultaneous transmission for settlement at the same time one or more credit Micro-Entries that, in aggregate value, are equal to or greater than the amount of the debit micro-entry(ies).

No. By rule, ACH debit Micro-Entries are permitted only in tandem with ACH credit Micro-Entries. Debits to offset non-ACH credits would be “regular” (i.e., non-Micro-Entry) ACH debits and require the Receiver’s express authorization for such entries and compliance with the terms of the Originator’s ACH Origination Agreement.

No. Although both types of entries can be used to validate a Receiver’s account, they function slightly differently, and each has unique formatting requirements that ensure its proper identification as an account validation tool.

Prenotification Entries can be easily identified by a unique transaction code and a dollar amount of zero. For these entries, a specific company entry description is not needed to identify these entries as an account validation tool, and Originators have discretion over the content of the company entry description field.

By contrast, Micro-Entries are like any other live transaction that posts to the Receiver’s account. Unlike prenotes, Micro-Entries do not have a unique set of transaction codes to distinguish them from other live transactions and require the use of other means to flag them as account validation transactions. For clear identification of these payments as an account validation tool, Originators are required to include the specific descriptive statement “ACCTVERIFY” in the company entry description field.