The browser you are using is not supported. Please consider using a modern browser.
Build or Buy? Five Questions to Consider When Weighing Your Bank’s Data Solution Options
Should your community bank build a technology solution in-house or partner with a fintech? Ask yourself these five questions when faced with the age-old “Build vs. Buy” dilemma.
By Ashley Fiore | May 25, 2023
Build or buy? For years, that has been the inevitable question for financial institutions undertaking almost any new initiative. It’s a consideration we often hear about when financial institutions are wrestling with how to gather real-time data and unlock its power with analytics.
Financial institutions certainly understand the desirability of harnessing their vast storehouses of data. Doing so is a vital step to gaining insight into their customers and making more informed business decisions. But, very often, they hesitate to upgrade their analytical capabilities because they’re not sure where to start, not ready to invest, or reluctant to give up their traditional approach to looking at customer data.
So, they wonder: Will an out-of-the-box solution work? Will it meet our needs? Or is it better to build on the foundation of what we’re already doing? What if we created our own highly customized data dashboards? What would that involve?
These are valid questions, and financial institutions should certainly weigh them carefully before locking in on any particular solution. As financial institutions parse the build versus buy decision, we believe there are some factors they should keep in mind. We’ve boiled it down to five questions.
How fast do you want to move?
How urgently do you need to harness customer data? If a financial institution has a “good-enough” solution in place and can afford to wait, speed may not be a critical consideration. But many financial institutions feel competitive pressure to gain customer insights that they can act upon–and time is money. If the financial institution makes it a priority to develop its own data solution, is it prepared to let implementation take a back seat for an indeterminate amount of time? While busy building, is the financial institution able to manage without having actual data and information? It’s important to be realistic: An out-of-the-box solution might take as little as 90 days to implement, and seldom more than 180 days. A custom solution can take three years or longer to develop, let alone implement, and that’s after the financial institution has recruited, hired, and trained the right people.
Are you ready to cultivate data and software talent?
Taking data analytics to the next level is an investment, and financial institutions that are stepping up these capabilities, will generally need to train or hire a few people. This includes business analysts who understand the bank’s data and how it flows through their systems, and report writers who craft data queries across large data sets and identify where gaps may lie. But building custom technology requires a much bigger staffing commitment, as well as a more expensive breed of talent. Software engineers will be needed to write, debug, and maintain programs. Data visualization specialists must be hired to convert raw data into well-designed, actionable information. DevOps engineers will have to be recruited to make sure software development and deployment is constantly being improved. And project managers will be hired to keep entire teams and initiatives on track. And no, it’s not realistic to assume that a few incumbent IT staffers with a little time on their hands are interchangeable with these knowledgeable specialists in the fast-moving technology field.
Can you tolerate the upfront investment, hidden costs and overruns, and delays?
Ideally, all software development plans would consistently be executed on time and on budget. In financial services, however, 47% of software delivery projects blew their deadlines, 41% overshot their budgets, 39% suffered from scope creep, and 37% failed altogether and squandered the investment, according to a report by the Project Management Institute. Some financial institutions will beat those odds, but it’s not a sure thing. On the other hand, as Deloitte has noted, it takes far less time to evaluate the best software solution than it does to build software, and contracted pricing can eliminate cost overruns and reduce the risk of delays. Many financial institutions have embarked on building because it thought it would save money, but at the end of the day it ended up spending significantly more money to develop and build software than it would have spent to buy it.
Are you prepared to continue to maintain and improve what you built?
Technology becomes obsolete quickly. Financial institutions can definitely build a one-off report and maybe have it resemble a dashboard of sorts — but that’s not where the job ends when they’re the software developer, because they can’t just build it and leave it. Quality assurance is an ongoing process of ensuring that nothing is changing that isn’t supposed to change. And breakthrough technologies have to be updated. A financial institution that builds its own dashboards, analytics platform, or other system will need an IT group for helpdesk and issue support, as well as a development team for new feature upgrades and innovation implementations required to stay relevant.
Is being unique all it’s cracked up to be?
When you’re building a house, it can be gratifying to pick out every appliance, every tile, and every piece of trim. But it’s also possible to become paralyzed by all the choices. The clear attraction for a financial institution in building its own system—whether it’s a data and analytics solution or a digital banking platform—is that it allows for complete customization. The tradeoff is that there is no template and doing it yourself means you’re on your own. Is it possible that customization is not a necessity, but a vanity project? Is it possible that the financial institution could adapt to and learn from new approaches? And are there efficiencies and insights a financial institution can gain by leveraging the collective experience that a partnership can provide, rather than resting entirely on its own experience? Plus, there is the opportunity cost to consider: What is the financial institution not doing because it has tied up resources on developing its own data and analytics solution? Should you focus internal staff on initiatives that are distinct to your bank?
These questions are worth asking, because no two financial institutions are exactly alike; different cultures, priorities, and resource limitations must be considered when deciding to build or buy a new software solution. Some financial institutions will voyage into software development, but many will conclude that there are significant resource efficiencies and industry knowledge to be gained by partnering with a firm that is expert in software development for financial institutions.