Detect fraudulent behavior in the Access API with bank account fingerprinting

Preventing fraud — the constant battle between the good and the bad actors in payments, with the good always trying to outpace the bad. As a payments company, we understand that fraud exists and acknowledge that fraud prevention is an important piece of any payments process.

In our effort to help Access API partners monitor and prevent ACH fraud, we have created “fingerprints” for bank accounts.

Being in-tune with our partners’ payments needs, we know there are areas we can lend a hand and help them better identify fraud on their platforms, so we’ve created a solution to help identify when the same bank account is tied to multiple user accounts.

Fingerprinting a bank account accomplishes many things:

• A fingerprint is merely an identifier based on a Message Authentication Code (MAC). It cannot be reverse engineered to decode a user’s bank account and routing number. Since it is only an identifier, we’re keeping sensitive banking information out of the fingerprint.
• By passing this fingerprint back to our partners, we’re empowering them. They can run any number of tests on their own internal data using fingerprints without needing to rely on Dwolla’s development to identify those bad actors.

Understanding by example

The good: There are situations where having one verified bank account tied to multiple users is completely valid. For example, if a couple shares a bank account, and both create accounts on a platform, it is likely they will connect the same bank account. And there you have it, two users with the same bank account; everything is completely kosher.

The bad: Sometimes bad actors will find a way to defraud a business and exploit that finding by setting up more than one user accounts all tied back to the same bank account. As that bad actor funnels money into the bank account — often in small amounts to avoid detection — he or she then quickly move the money out of the network for safe keeping. It isn’t until the ACH file is processed and the resulting transfers fail that our partners understand the true scope of the vulnerability.

Using Fingerprinting

Partners can use this fingerprinting in a few different ways. For example, a partner may develop an internal process that uses fingerprints across multiple accounts along with the frequency of transactions to help determine and identify bad actors. Others might use fingerprinting to help detect and, in turn, deactivate any account as a precaution if it is identified as having the same fingerprint.

With this new feature, we’re empowering our partners to take a positive step towards better ACH fraud detection.

Originally published at Dwolla by John Jackovin on October 4, 2017.