ClickSwitch is a Minneapolis-based fintech with a simple goal: Make it easier for people to switch banks. The company started with a focus on moving automatic payments between banks but soon learned the key was to move direct deposit information. Eric Edwards, chief revenue officer of ClickSwitch, explains how it works.
Q: Why did ClickSwitch make payroll deposits its focus?
Eric Edwards: Deposits are a substantial sticking point in the market. I moved a banking relationship recently in Wisconsin. They didn’t offer me a way to move my direct deposit, and all the banks know a customer doesn’t consider it its main financial institution unless you have their payroll. Once you get that, you’re in the prime spot to get loans, mortgages, you name it. This really is the friction point in moving from one bank to another. From a customer’s perspective changing direct deposit can be hard to do.
Q: How does your process work?
E.E.: There are two ways to use our solution. One is basically a desktop program at the branch level. A customer service person at the bank can use it to walk a new customer through the switch. The customer is there to authenticate accounts. For deposits we have a growing database of employers. A request hits that database and pulls up the necessary documentation to identify where they want their deposits to go. We can fulfill those electronically, although some require manual effort because that’s what the employer requires. We notify the employer to switch from this bank to that bank. On the payments side, while they’re engaged, we have the ability to look at auto debits. If you have, say, 12 different payments, we have an aggregation resource to collect them and the customer also verifies which autopayments to move. If we encounter a business or employer not in our database we reach out to them to get the needed documentation on file. So the database is growing over time.
Q: So the customer is not using ClickSwitch?
E.E.: There is the desktop application and there is also an API banks can use to build into their existing new account opening workflow. But no, a customer may interact with our database in the API, but otherwise it’s a banker assisting the customer and they simply sign off on the requested changes as the banker does the work for them. If there are things that can’t be figured out while the customer and banker are sitting together, like a particular payment, it stays in their file as unresolved. And if the customer has to return on their own to complete the switch they can log into our technology and use a code to finish. In that instance a customer is able to interact directly with ClickSwitch. But mostly it is going to be done for them by a banker or through the API.
Q: If a banking giant doesn’t want a service like yours helping its customers leave, could they stop you?
E.E.: I don’t really know how they would get in the way because consumers control where their employer sends a deposit or what companies receive payments. The bank doesn’t really have a stake in that. We use an aggregation service when it comes to payment information, and theoretically a bank or company could do something with the way the aggregation service can authenticate some of that information. But that would be the aggregation service provider’s problem.
Q: I assume the bank absorbs any cost for the customers’ use of ClickSwitch. What’s the pricing like for, say, a $500 million bank?
E.E.: Yep. Banks choose between the desktop or building the API into their website. For your average community bank, the price will differ depending on which solution you choose. A bank that size would be looking at $15,000-$20,000 for the initial setup. It’s sort of hard to calculate the price thereafter; it depends on the bank’s size. There are some monthly minimums based upon what a bank calculates is its rate of new customers, number of employees using it, a few things like that. Monthly fees are based on the bank’s numbers, not on ours. But then it’s mostly priced on a per-use basis, and it breaks down to about $30 per switch.