Moving Money - Direct Debits & ACH

I recently had reason to educate myself how the US ACH (Automated Clearing House) funds transfer system works. This exercise reminded me that transactions can be both 'pull' and 'push' in nature; both drawing funds from accounts on demand, as well as transferring them at the account holder's request. 

So far in this series, for simplicity, we have assumed that the person, or entity, initiating a payment also has the direct ownership or authority over the source funds. Indeed this seems to be a given that the payer must authorise the payments from their account rather than the payee being able to take money arbitrarily!

However the ACH payments system, along with its UK and EU equivalents, BACS and SEPA respectively, regularly conduct 'pull' transactions (known as Direct Debits) that draw funds from accounts without specific authorisation from the account owner. In this article we will use the ACH system to examine how these transfers are authorised and executed.

The ACH Standard

Firstly let's understand the basics of ACH. The ACH system itself is not a single network; it’s a set of rules and standards for deferred settlement managed by NACHA (the organization that governs ACH operations in the U.S.). ACH support two modes of payment:

• ACH Credit - A Push payment that money moves from the payer’s account to the recipient’s account, e.g. Employer sends salary payment to an employee.

• ACH Debit - A Pull payment where the recipient withdraws funds from the payer’s account, .e.g. A utility company pulls your monthly bill payment.

The institution that initiates the transaction, sending the payment instruction into the ACH network, is referred to as the Originating Depository Financial Institution (ODFI). The institution that receives the transaction, from the ACH network, is known as the Receiving Depository Financial Institution (RDFI). Both institutions adjust the balance of their respective account holders (either as a Credit or a Debit) with the ACH network settling the net balance between the institutions once the batch of payments received in the time window have been processed (deferred settlement).

Direct Debits

An ODFI can therefore initiate both ACH Credit and ACH Debit instructions. In the former case the ODFI also holds the payer account from which the funds are transferred whereas in the later case the RDFI is the payer. But hang on, why does the RDFI obey instructs from the ODFI to withdraw funds from one of it's customer's accounts? What if their customer subsequently objects to the transfer? 

The reason this type of transfer is permitted is that the RDFI trusts that the ODFI has directly, or more likely indirectly, been authorised by the account holder to withdraw funds from their account under certain conditions. When instructing a transfer to take place the originator of the payment (e.g. a utility provider) warrants to their payment institution, acting as the ODFI, that they posses such authorization, and therefore the ODFI can issue the appropriate legitimate instructions to the RDFI who holds the account of the utility customer.

Authorizing Debits

The permission for ACH debit transaction(s) to take place is typically provided as a written agreement from the customer authorizing periodic recurring payments, whose amounts may vary, to be withdrawn from their account. Alternatively a one-time electronic authorization for a single defined amount transfer maybe granted. Here the challenge of identity presents itself. How does the Originator know that the person or entity providing the authorization is in the fact the authorized holder of the account, with a third party financial institution, that they claim to own?

Traditional techniques to establish account ownership rely on the provision of sample documentation that only the account holder would be expected to posses, e.g. a printed bank statement for the account in question. In the age of Generative AI this maybe deemed less reliable! Alternatively a firm may send micro-deposits (e.g. $0.11) to the account the customer claims to own and ask them to confirm the amounts sent as evidence that they have visibility of, and therefore presumably authority over, that account.

Regardless this presumed authorization mechanism represents a weak link in the chain of trust that the RDFI relies upon to carry out payment instructions as mandated by the ODFI. If the Originator fails to verify properly and fraudulent debits occur, liability flows back to the ODFI — which is why banks scrutinize their Originators’ fraud controls carefully.

Although conceptually straightforward this reversal of the flow of funds with respect to the flow of the instruction can cause havoc for monitoring systems. The terminology can also introduce uncertainty as systems may refer to the Originator of a transaction as being synonymous with the provider of the funds, which clearly may not be the case!