Micro-deposits are an easy way to verify a customer bank account. It’s a method used in various services to ensure that the individual owns the bank account they are adding to your service.
To make micro-deposits a normal workflow looks something like this:
- Acquire routing number and account number from your customer
- Acquire basic account information from your customer
- Use our white label ACH API to send money (small deposits) to that account
The deposits sent via bank transfer will show your company name on your customer bank account so they know exactly who the deposit came from.
If you decide to provide micro-deposit verification yourself, you can select the amounts to deposit into the customers’ bank accounts. It could be pennies, dollars, or any variation. If you choose the micro-deposit method of bank verification with Dwolla, Dwolla will transfer two deposits of less than $0.10 to your customer’s linked bank or credit union account.
A different combination of multiple deposits should be used for each customer. For example:
- Deposit #1: $0.12
- Deposit #2: $0.01
- Deposit #1 – $0.05
- Deposit #2 – $0.07
- Deposit #1 – $0.06
- Deposit #2 – $0.02
If you’d like to avoid managing the deposit amounts, you can use our micro-deposit endpoint and we will calculate and track the micro-deposits for you to make things easy. After initiating micro-deposits, two random amounts will post to your customer’s bank account in 1-2 business days. Once your customer sees these deposits in their account, they need to verify the two amounts in your application.
When working with our ACH API to make micro-deposits you also will not have to worry about formatting an ACH file. You simply send instructions to a API endpoint to make the ACH transfer programmatically.
How Micro-Deposits Can Lead to Salami Attacks
Micro-deposits can be leveraged for “salami” attacks when fraudsters abuse the normal process.
A salami attack is a series of small fraudulent transactions that might otherwise escape detection, but when aggregated can result in large losses. These attacks are not new to the payments industry, but fraudsters have found the ability to automate processes with modern technology which can exacerbate damage that can be done before a human can take action.
For ACH bank transfers, it’s important to consider how micro-deposit verification of accounts can be abused for this purpose. Because micro-deposits, by design, happen before an account is verified, a bad actor can use this opportunity to fraudulently accumulate funds. Normally, micro-deposits are only a few cents at a time, so the damage is small.
But let’s put on our fraudster hats and think about how micro-deposits could be abused.
Salami attacks can be done with the creation of thousands of new accounts with bank account and routing numbers that are either stolen or being tested against the system. Fraudsters will ensure the information is valid by looking for any successful transfers or return codes.
Imagine thousands of new user sign-ups happening within a few hours, each initiating micro-deposits for verification. The result might be only a few hundred dollars in direct losses, but indirect losses from time spent cleaning up the mess can add up quickly.
Beyond stealing what could amount to a fairly small amount of money, why might fraudsters perpetrate an attack like this?
- To identify active bank accounts they can further victimize. If they are able to determine that the micro-deposits weren’t returned, even if they can’t actually see the amounts, they know they have a valid account and routing number combination. Failure to be proactive in this area, even if the direct costs are small, can have an impact on consumers–maybe even those you don’t have a relationship with.
- To probe your defenses and determine if and how you respond to suspicious activity. This can be preparation for a secondary and larger attack later. Advanced fraudsters know how to stay below the radar until they’re ready to make their big move.
- To draw your attention away from a more impactful concurrent attack, or to bury it in your logs and alerts to make it harder for you to detect and respond to it.
Protecting Your Business From a Salami Attack
As your application provides payment capabilities to your users, you are the primary defender of your end users and it’s your responsibility to take appropriate actions to prevent, monitor and respond to fraudulent activity in your application. But what if you’re a Dwolla client without a lot of resources to combat these types of scenarios? What should you do to prevent or stop this type of activity?
Dwolla provides capabilities to help you, and there are some other best practices you should follow to protect your platform.
- Monitor for multiple accounts sharing the same funding source by utilizing bank account fingerprinting.
- Deactivate or Suspend unusual activity or suspicious accounts, when detected, via the API.
- Follow Dwolla’s integration guidelines, including requiring validation of email addresses upon end user sign-up and multi-factor authentication for user sign-in. This makes automation of account abuse significantly harder.
- Apply limits to the number of bank accounts any end user can attach. In combination with the controls above, this will significantly hamper a fraudster’s ability to execute attacks.
- Monitor for anomalies in the number or rate of account sign-ups or funding source additions, especially those sharing similar attributes such as name, email or bank account.
- Keep apprised of the use of disposable email domains that may indicate attacker activity, particularly when associated with an unusually large number of user sign-ups.
Find additional information about Dwolla’s security program at www.dwolla.com/security.
Looking to embed Dwolla’s payment technology into your product? Get started today.