shift happens image

Hard Lessons Learned: The Evolution of a Digital Bank

The concept of a digital bank has a certain kind of sex appeal these days, but it hasn’t exactly been smooth sailing getting here. In our evolution, we discovered early on that there are not many community banks that have transformed into digital banks. Digital banks usually take shape via either a fintech which begins to act or look like a bank, or via the creation of a new, de novo, digital bank. So our first challenge was blazing our own path—and we tripped a lot. But with those mistakes, we’re learning, growing, and ideally pushing the industry forward.

I feel that I’m acutely aware of the mistakes we made along the way and that it’s my responsibility to share the lessons we learned, to help other banks starting on this journey.

My first piece of advice is to realize that the core provider you have is not inherently better or worse than the other cores providers, especially in terms of customer services. Don’t be tempted by “the grass HAS to be greener on the other side.”

If you’re tasked with innovation, you need to start by assessing your core provider. What you shouldn’t do is fall into the trap of thinking that if a competitor’s core is better than yours, that the experience will be any better. All cores have their values and their downfalls. A formal RFI (request for information) process helps during the selection process. If you’re trying to solve a flexibility with customer service or a speed-to-market problem, switching to another core isn’t always the best solution. First, consider building on what you have to get there.

But me, I looked around at new technologies and that’s where I made my next mistake. I fell in love with one of them, so hard that I agreed to a 5-year term when I signed them on.
When I accepted the term, I was correct in my assumption that the tech was better than what we had, but wrong in my assumption that it would be better in the long term (even for 1 year). In that moment, I could have accepted a shorter term, but it would have been more expensive upfront. I didn’t want to try to convince my boss that we should pay more money for a shorter term. They’re coming from a banking mentality, and would have said, “Why are we buying it?” In the end, though, I had to pay a really expensive breakage fee to get out of it. We learned that it’s better to keep your term short: Get it in, see if it improves metrics, or determine whether it’s just “nice’ to have, and not “great” to have.

You also won’t wear out your team by changing things on a dime. Upfront, make sure all teams (including your ops team, compliance team, and IT) know that you’re trying something out. Set the expectation with all teams that you’re testing something, but that you don’t know if it’s the right solution. Ideally, but not critically, seek buy-in from the team so you can all own the wins and the losses.

Here’s another one: If you want to be a digital bank, you need to have developers on your staff that can do API integrations. We tried to outsource it, and in the end, it was more expensive and the integrations didn’t work as well. We ultimately ended up using an in-house team to get it done, but it took a lot longer. In both cases, you’ll get results, but it won’t be optimal. The takeaway is that you can’t outsource integrations or bulldoze your way through them.

Lastly, we didn’t find enough people that had “been there, done that” to help as advisors, mentors, and consultants. Or rather, we assumed that we’d have a hard time finding them or that the ‘the adult versions of ourselves’ wouldn’t want to take the time to help us. It was a faulty premise.

We tried to do it on our own, but when we started talking to others in the industry, they wanted to help us, and the industry, out. They weren’t afraid of competing. So my advice is to go find mentors; don’t wait. No project you want to do is too small. People are out there and they want to help. You just need to ask for it.

Share on facebook
Share on twitter
Share on linkedin
Share on email