This blog post was coauthored by Ben Blakely, Director of Data Intelligence & Information Security Officer.

We aren’t talking about sandwiches here, so what do we mean when we say “salami” attacks?

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.

Specifically in the case of 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.

How Micro-Deposits Lead to Salami Attacks

Micro-deposit verification is a method of ensuring that the individual inputting bank account information into an application actually has access to that bank account. A micro-deposit works by initiating small deposits (less than 10 cents, typically) into a bank account via the provided account and routing number. After this deposit clears, typically within 2-3 days per normal ACH processing times, the individual can see the deposited amounts and then provide that information back to the application to which they want to attach the account. Micro-deposits can be leveraged for “salami” attacks when a fraudster (or group of fraudsters) abuses the normal process. This 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—not to mention reputational impact.

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 for 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–what can 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.
  • Disallow micro-deposit validation as the standard first step and use Instant Account/Bank Verification (IAV/IAB).
  • 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.

You are a critical player in keeping your end users and the Dwolla network safe and secure. If you have questions about how Dwolla functionality can help you build your defenses, please reach out to your account manager or

Find additional information about Dwolla’s security program at Looking to embed Dwolla’s payment technology into your product? Get started today.

Stay Updated