Sharing knowledge. Creating peace of mind.

External Transfers Demystified: Authentication, Authorization, Micro-Entries, and More

Published on April 17, 2025




AUTHOR

Eric Wester, AAP, APRP, NCP
Associate Director of Education Services
 

 

These are some of the questions we often receive on our member hotline as more financial institutions begin offering external transfer products and start to experience fraud related to the service. 

Many institutions struggle to fully grasp the requirements for authentication and authorization, leading to compliance risks and potential fraud vulnerabilities. Additionally, we hear about uncertainty regarding the role of Micro-Entries in validating account numbers and their relation to the authorization process. This lack of clarity can create operational inefficiencies and increase risk exposure.

In this blog, we’ll break down the key responsibilities financial institutions must understand, clarify the differences between authentication and authorization, and explain how Micro-Entries fit into the broader framework of external transfers.

What are External Transfers?
In the context of this blog, the term "external transfers" refers to the transfer of funds initiated to or from a consumer's accounts at two different financial institutions, with the funds being transferred through the ACH Network. Generally, these types of external transfer requests are initiated by a consumer through a financial institution’s mobile banking or traditional online banking systems.

What is Required as Proof of Authorization?
If an external transfer debiting the consumer Receiver’s account at the RDFI was authorized via an online banking or mobile banking system, the debit should generally bear the WEB SEC Code. To satisfy a request for proof of authorization, the Nacha Operating Guidelines suggest the ODFI might “provide a screenshot of the authorization language and then the date/timestamp of the Receiver login and the authorization process that evidenced both the consumer’s identity and his assent to the authorization.”

It’s important to note that two components are generally required to demonstrate a WEB debit was authorized: evidence of authorization and evidence of the Receiver being authenticated.

To break this down further, let’s examine authentication and authorization independently.

What is Authentication?
Authentication: The NIST glossary defines authentication as “A process that establishes the source of information, provides assurance of an entity’s identity, or provides assurance of the integrity of communications sessions, messages, documents, or stored data.”

Appendix E (off-site) of the FFIEC's Retail Payment Systems booklet goes on to state, “A financial institution should have a process for authenticating users [of Mobile Financial Services] to protect customers against fraudulent transactions or malicious activities. Depending on the technology used and associated level of risk, financial institutions may consider biometric (e.g., voice, fingerprint, facial recognition) or out-of-band authentication processes. The financial institution should not use mobile payment applications that rely on less secure (e.g., single factor) methods of authentication.”

Article Two, Subsection 2.5.17.5 of the Nacha Operating Rules further states, “An Originator of a debit WEB Entry must establish and implement commercially reasonable methods of authentication to verify the identity of the Receiver of the debit WEB Entry.”

To satisfy the requirements of Regulation E and the Nacha Operating Rules, the authentication method chosen must evidence both the consumer’s identity and their assent to the authorization.

In other words, we should think of the authentication process as the means in which we can prove the identity of the party that signed into the online session and authorized an external transfer. 

What is Authorization?
Generally, the Originator is required to obtain authorization from the Receiver prior to originating an Entry to the Receiver’s account. However, the Nacha Operating Rules do provide exceptions to this requirement, with one notable exception being for credit Entries where both the Originator and Receiver are natural Persons.

In other words, if John Doe transferred funds from his consumer account at Bank XYZ to his consumer account at Credit Union 123, no formal authorization requirement exists for the credit being sent to Credit Union 123.

Where much of the risk typically exists, however, is with financial institutions that allow consumers to debit their linked account at another financial institution. In such cases, authorization is required.

The authorization process occurs after the consumer has been authenticated.

The authorization must include the provisions required in Article Two, Subsection 2.3.2.2 of the Nacha Operating Rules, which addresses the minimum required components for a consumer debit authorization. In the case of a WEB debit, evidence of the authorization generally includes screenshots of the authorization language the Receiver agreed to.

Where do Micro-Entries Come into Play?
A Micro-Entry is defined in Article Eight of the Nacha Operating Rules as “a credit or debit Entry used by an Originator for the purpose of verifying a Receiver’s account or an individual’s access to an account.”

We often hear misperceptions about the purpose of Micro-Entries, including the belief that as long as the Receiver validated the amounts of the Micro-Entries, the validation itself serves as authorization for any additional subsequent external transfers that the consumer wishes to initiate. To be clear, that is not the case.

Remember, each external transfer must be properly authorized, and, in fact, even any Micro-Entries initiated must themselves be authorized—an RDFI is within its rights to request proof of authorization for one or more Micro-Entries originated by an ODFI.

Many ODFIs and Originators choose to utilize Micro-Entries to satisfy their obligations under Article Two, Subsection 2.5.17.4 of the Nacha Operating Rules, which requires use of a commercially reasonable fraudulent transaction detection system to screen the debit WEB Entry, which must minimally validate the account to be debited before its first use. This process is independent and distinct from the consumer authentication and authorization processes.

Problems with Proof of Authorization Name Mismatches
Another common issue we hear about is when an ODFI furnishes a copy of the authorization for an external transfer, but the RDFI responds by indicating the name listed on the authorization does not correspond with the account ownership and said individual had no authority to initiate the transfer. When this happens, the question is raised of which participant should be responsible—the RDFI (since the ODFI was able to furnish an authorization) or the ODFI (since the authorization provided lists a seemingly random name)? To compound matters, ODFIs will sometimes push back against an RDFI by stating that clearly their Receiver validated the Micro-Entry amounts, and therefore they should assume liability.

In an October 2, 2023 blog post (off-site), Nacha indicated “The [Nacha Operating] Rules state that the ODFI must provide an accurate Record of the Receiver’s authorization. To be deemed a valid authorization, however, the name on the authorization must match that of the Receiver being debited, otherwise the proof of authorization is deemed to be invalid.”

It’s critical to remember that an ODFI is responsible for all Entries it originates, and it makes important warranties, including that the Entry was properly authorized. If the authorization was provided by someone without authority to authorize Entries to the Receiver’s account, and therefore there is a name mismatch, the ODFI has breached its warranties under Article Two of the Nacha Operating Rules.

Barring the time limits described for breach of authorization warranty claims in Article One, Section 1.15 of the Nacha Operating Rules, an ODFI generally must reimburse an RDFI for claims, demands, losses, liabilities, and expenses, including attorneys’ fees and costs, that result directly or indirectly from the breach of such warranty.

An ODFI that fails to reimburse an RDFI in these cases may be subject to fines under Nacha’s System of Fines or, depending on the dollar amount of the dispute, arbitration proceedings under the Nacha Operating Rules.

Bringing it all Together
Facilitating external transfers is not a risk-free endeavor, although understanding the requirements as an ODFI, including how authentication, authorization, and Micro-Entries interplay, can help reduce your exposure to risk.

Here are a few key takeaways to remember: 

I highly encourage taking some time now, before something goes wrong, to review your external transfer processes and procedures. Ensure that you are adequately authenticating consumers and obtaining (and retaining) sufficient authorizations that can be readily reproduced and provided to a requesting RDFI in a timely manner. Sometimes this may require working with online banking vendors or other service providers to understand how to pull together a valid response to a request for proof of authorization.

As your key partner in understanding electronic payments, our entire team at UMACHA is here to support you. If you have specific questions about your external transfer process and procedures, or any payments-related questions, please feel free to contact us at info@umacha.org or by phone at (763) 549-7000 – it’s all part of your member benefits!

Stay connected with Eric Wester and UMACHA on LinkedIn!