Checking Account Verification Systems

The ACH or echeck world does not have an authorization component as with credit cards. When processing credit cards you are able to authorize at the time of payment that the customer has the funds available on their cards. Most importantly you are able to reserve those funds for capture and settlement. So you know you are getting paid at the point of sale.

For some businesses this lack of an authorization means that a Checking Account Verification system to mitigate payment acceptance risk and Validate a Checking Account must be put in place.

An ACH transaction processed today goes to the ACH network for debiting the customer tomorrow morning [assuming tomorrow is a banking day]. There are two banks involved: The bank initiating the debit on behalf of their merchant [ODFI] and the customer’s bank [RDFI].

Those two bank have yet one more day to approve or reject he debit eg NSF, closed account etc.

Note: Same Day ACH accelerates this time frame but does NOT authorize a payment-this means there is still risk of the payment rejecting.

So payment rejects are not known about until days after payment is accepted.

Consider a business that pays commissions for new customers. Their sales team brings on a new client and is paid. Your bank reports back 5 days later the check payment rejected.

Checking Account Verification Systems

The business has multiple problems to deal with: The commission payment may need to be pulled back. That customer must be contacted for payment. Accounting may need to be undone.

For businesses that accept checks either as an ACH, Check 21 or Remote Deposit all face the risk that the payment will result in a return [failed transaction].

Mitigating loss through third party check verification services can be an important part of the business that relies on ACH processing for check acceptance.

So what are your options to reduce check acceptance risk?

Most third party checking account verification systems include the most basic tool of routing account number validation. The bank routing number identifies the bank the check is drawn against. The databases holding this information can be checked in real time.

The next level is negative databases. Based on history [both positive/negative] of that checking account info, a response is returned regarding the account status. An example would be writing a check at Home Depot. If the check is good or bad, Home Depot can report that check status to the database. With many retailers contributing data to the network there are many millions of checking accounts to reference.

Recency becomes an issue, as the customer’s last instance of writing a check at a participating retailer becomes the last data point. This means that data can be stale or a known bad check writer may not have made it into the database in a timely fashion.

The next level of check verification comes from banks and Credit Unions contributing data from their ATM network. A daily upload of account status is made to the network and queries to the network can provide account insight. When a check verification inquiry comes in an almost immediate response can be generated. These responses can tell you:

• The account is closed
• The account # is invalid
• The account is non DDA eg Home Equity checks
• The account is in an NSF status: For some businesses this is important as they do they know they have a good account
• Account has pending NSF’s or stop payments
• The account is open and in good standing with a positive funds balance. Very importantly you do not get a balance confirmation. The account can have $25 or $25000.

**Note: There are services that can check balances. However in order to leverage these systems the customer must either log-in to their online banking or provide their credentials for logging in. This can create friction in an online setting and phone payments would not be eligible.

To learn more about Check Verification Systems [ including back testing your data ] contact AgilePayments today