How should banks respond to the current disruption in software engineering?
As banks race into an AI-driven future, they should embrace a new set of approaches to software engineering, including refreshing their talent strategies and third-party relationships
Ryan Lockard
Val Srinivas
Abhinav Chauhan
Jim Eckenrode
Software engineering appears to have entered the next pivotal stage in its evolution. The new wave of artificial intelligence with the advances made in the last several years has unleashed new possibilities, including greater business efficiencies. But the new reality is also challenging some fundamental assumptions about how software is designed, developed, and deployed. Banks are not immune to these dynamics.
According to a Citigroup report, AI could propel global banking industry profits to a staggering US$2 trillion by 2028—a 9% increase over the next five years.1 A number of banks are already seeking to seamlessly integrate the latest in machine learning (ML), neural networks, natural language processing, and generative AI tools to drive more efficient business processes and enable new value creation. An AI-powered bank is expected to have a range of benefits, including revolutionizing customer experience as well as amplifying employee productivity. However, tech debt, stringent regulatory requirements, and the complexity and vulnerability of banks’ tech stack often put them at a disadvantage in achieving that vision.
But a new approach to software engineering can help in preparing banks for the AI-driven future. Banks have been early adopters of technology, yet their software engineering practices are often suboptimal, leading to inefficiencies and delays in the outcomes. To overcome these hurdles, tech leaders should consider not only embracing a leaner, more agile approach to software engineering, but also updating their talent management and third-party vendors relationships to help them harness the full potential of AI-powered banking.
Another impetus for reimagining software engineering at banks is the evolving macroeconomic environment. As these uncertainties loom large, the economics of software engineering—how technology investments are allocated to yield better outcomes—will likely become more important. A new approach to software engineering, as outlined in this report, could also boost productivity and perhaps directly lead to lower efficiency ratios.
Research methodology
We conducted in-depth interviews with 14 technology and software engineering executives at large, super-regional, and regional US banks in the first quarter of 2024. We interviewed a mix of current and former executives with an average tenure of 17 years in the industry. These discussions focused on the current state of software engineering, the challenges in the banking industry, and future expectations. The insights gathered from these interviews provided a broad overview of the industry landscape. We have incorporated direct quotes from these executives throughout the document to substantiate our findings and provide real-world evidence of the trends and issues discussed. This qualitative approach emphasizes that our analysis is grounded in the practical experiences and knowledgeable opinions of industry leaders.
Current priorities of technology leaders at banks
Before we address how software engineering at banks could adopt a new orientation to be ready for the future, it’s helpful to highlight the broader technology priorities that banks are dealing with.
The banking industry ranks as one of the largest spenders on technology.2 According to Gartner®, the banking and financial services IT spending as a percent of revenue is 6.8%, and the IT spending distribution on application development is 28%.3
But is this investment yielding the highest possible return? Anecdotal evidence suggests it may not. One possible reason could be the current state of software engineering at banks. Some of the interviewees pointed out that banks’ engineering projects are often inefficient, prone to delays, and costly.4 Developing a fully functional bank application presents specific operational, technical, and compliance complexities. In fact, despite critical investments in technology, many banking applications continue to run on legacy hardware and software, leading to a wide array of challenges including integration issues and slower runtime.5
These challenges can manifest themselves across the software development life cycle. Even with some differences in prioritization, common themes can be seen: Budget constraints, talent gaps, and technical debt are causing the most pain, as per a Deloitte survey of technology executives.6 According to these survey respondents, a more thoughtful development road map, faster delivery, and product-centric engineering are the most desired outcomes of software engineering investments.
Although many of these challenges have been around for decades, it’s different now. A remark from a former senior director of technology at a US regional bank put this into context: “What makes this digital transformation different than any changes in the past is that it’s permeable, it’s malleable. It’s ones and zeros—a change of keystrokes. It’s always changing. Previous changes were more episodic, followed by a period of maintenance or stasis. This one is constantly evolving very fast.”
Engineering for a complex banking system
To say that the US banking industry is fundamental to the global economy is not an exaggeration. By enabling financial transactions among hundreds of millions of individuals and entities, banks are vital to keeping the economy humming. Every day, transactions worth trillions of dollars take place among retail customers, businesses, and governments. For instance, in 2023, the US ACH network processed 31 billion payments totaling US$80 trillion.7 Meanwhile, bank trading rooms account for a large share of the over 15 billion trades processed in the United States daily.8 The tolerance for failure in these transactions is infinitesimally small.
The effects of any deficit in banks’ software capabilities can spread beyond the institution and often reverberate across the economy, affecting customers and counterparties. For instance, software issues, though seemingly rare, can lead to disruptions in interbank settlements, payment delays, and inaccessibility of funds for retail and business customers.9 These incidents often lead to loss of trust and brand value, and in some situations, customer attrition.
Regulatory compliance is a dominant driver
It goes without saying that to keep the banking system operating with zero tolerance for failure, banks’ digital infrastructure should be robust and secure. With keys to US$23.4 trillion worth of assets,10 regulators also demand that different applications and software adhere to strict compliance and reporting.
US banks, therefore, see to it that their software developers follow rigorous security control practices. Many customer-facing applications, for example, have multilayered authentication processes embedded in them to help defend against cybersecurity threats. Additional security frameworks should also be in place to help limit tampering with bank applications. Software development should have customer privacy considerations embedded throughout the software development life cycle (SDLC). This includes adding layers of privacy protocols in using test data to develop products. As a result, operational resilience is a focal concern, and every stage of the SDLC should embed and reinforce these principles (figure 1).
The senior vice president of engineering at a US bank made a point that illustrates how fraught this compliance can sometimes be: “There’s a lot more governance on software engineering projects than there used to be. It’s not necessarily to say that we didn’t have governance [before], but I would say that the level of governance over the last year and a half has been the highest I’ve ever seen … It has definitely impacted our team’s overall velocity and ability to deliver and drive value to the clients. I think all the banks are feeling it …”
For instance, systems should be designed in such a way that when regulatory queries arise, banks can trace their way back to the source or origin of the query.11 As the former senior vice president at a US regional bank put it, “Regulators are … asking questions about data that is really putting a squeeze on banks of all sizes. They’re a lot more familiar with cloud [and] digital. They’ve upgraded some of the people. And now … a lot of these banks are being asked, ‘Show me exactly where all these documents come from. You’re giving me these reports, but where are you getting them from? And how fresh are they? Do you know where you’ve been getting your own data for these reports? Can you validate this?’ And it’s a lot harder than you think …”
This is important for maintaining a resilient banking system. It may not be surprising that a study revealed that the quality of engineers at some banks surpasses that of some tech firms.12
Banks’ outdated technology infrastructure
One challenge software engineers at banks often face is legacy infrastructure. Several executives interviewed indicated that “zombie” platforms are burdening many banks with heavy technical debt. This can not only sap operational efficiency but also has the potential to stifle innovation. In fact, software developers spend around 33% of their time on technical debt maintenance.13 In addition, close to 78% of engineers report that excessive focus on legacy systems negatively affects morale, leading to employee and customer churn, as well as lost business.14
Legacy systems can be particularly problematic for next-gen business outcomes. Many existing tech stacks weren’t built for scale, longevity, resilience, and security. In fact, some current banking applications and software are peppered with legacy codes, which can result in clunky and sometimes weak performance.15 Consequently, deploying modern, efficient software can be a daunting task.
But shedding tech debt, especially to achieve the promise of AI, will likely require the pace of core modernization to accelerate. This may not call for a rip-and-replace strategy; banks still have many tools at their disposal to incrementally modernize their cores.16 Zions Bancorporation in Salt Lake City, for example, spent over a decade incrementally converting its core systems. It started with its consumer loan software, then moved on to commercial and construction loans before concluding with its deposit platform.17
Banks’ technology infrastructure modernization should also address deficiencies in data management. Without the right data at the right place, at the right time, banks can struggle to drive value. As a former senior vice president of software engineering at a US regional bank pointed out, “As you start to think about companies wanting to use ML and AI—and even gen AI–type of implementations—if your data [is deficient], it’s a lot harder to do it. That kind of data cleanup, data cleansing, data prep, that is an area that I think could have some benefit for companies to get some help doing. [Companies need] people who understand it from a data perspective and can then work with the organization, who can also work with the business without some of the weird things that have been created in the data landscape over the years.”
As a result of these different constraints, some banks have been remaking not only their technology platforms, but also their approach to their development.
How have banks’ software engineering practices evolved?
Over the years, banks have adopted cloud and other new technologies, methodologies, and processes to streamline the SDLC, driven in part by the need for agility, innovation, and elevating customer experience. Additionally, the adoption of agile practices has helped some banks to deliver features more rapidly and respond to evolving market demands, while fostering a product-led development approach that aligns products more closely with user expectations.18
Focus on cloud-first design principles
Cloud has emerged as very important to modernizing banking technology architectures and the general shift towards more intelligence-based applications. In particular, banks are increasingly adopting hybrid cloud, given the significant investments in on-premises systems as well as the regulatory compliance requirements. Barclays, for instance, has made substantial investments to accelerate its hybrid multicloud journey.19 The hybrid option can offer banks a cost-effective way to integrate data between on-premises, private, and public cloud environments. This approach can help in maintaining the advantages of on-premises architecture and gives more control to banks themselves.
As the appeal of cloud becomes more pervasive, modern software development is already adopting cloud-first design principles in many instances. For instance, developers could increasingly use cloud development environments (CDEs) to help streamline workflows and reduce time-to-market as well as on-premises dependencies. CDEs can also enable faster adoption of emerging technologies.
Also, cloud technology can be an important catalyst in pushing for greater rigor in software engineering. Strategic use of cloud can dictate how easily banks can shift from traditional delivery to real-time development. As banks move to the cloud, a host of other development approaches and principles have been adopted. For instance, some cloud implementations have been able to break down banks’ bigger monolithic on-prem applications into microservices, enhancing code reusability and making bug tracing easier. As a result, containerization and serverless implementation may be increasingly attractive options as cloud enables a lot of scope to transform software development and deployment process in a cost-effective way.
Cloud containerization is one such approach that some have used to help with software engineering enhance portability, scalability, efficiency, and application security. According to the former senior director of strategic technology development at a US regional bank, “Right now when there’s an alert, it’s a very manual process for software engineering. But these perturbations [can] become canaries in a coal mine. Because if I have one API that goes awry for whatever reason, and I fixed that, I may have used that same API ... Now, I can be proactive and be that much more resilient by pushing that update out to the other ones. And therein lies the benefit, the value, the resilience, the flexibility of the cloud through containers, and why software engineering is focusing there to get you more to a serverless type of environment.”
Fully embracing agile development
Agile methods in software development have been practiced for at least two decades, helping bring enhancements like accelerated software creation and delivery. Concurrently, some banks have ushered in successive waves of organizational restructuring to be more agile. They implemented agile methodologies through frameworks like Scrum and Extreme Programming, which allow for iterative development and continuous integration and continuous deployment. There are some banks that are forming cross-functional teams to include members from IT, product, and business units.20 This can enhance collaboration and confirm that “agility” can permeate the development process.
However, some banks may still struggle with the essence of agility, potentially tethered by traditional models like waterfall to meet rigorous documentation and security demands. Interviewees revealed that outdated tech stacks, unique and complex compliance requirements, and rising governance expectations often complicate the transition to agile. In particular, scaling agile with existing back-end processes can be challenging. As a senior managing director at a US super regional bank noted, “… The [question] is ‘Can a bank effectively roll out Agile and be productive at it and sustain it?’ I think the sustainability is the hardest part for a large company.”
Disconnected systems and fragmented data make it difficult. The lack of truly agile development often leads to disjointed execution, less malleable operating models, and expensive integration of both in-house and third-party software.
Shift from project- to product-led software engineering
Another way that software development has evolved is the shift to product orientation. Product-led software development focuses on creating, delivering, and continuously improving a product instead of focusing solely on projects or tasks. It prioritizes short iterations, continuous feedback, flexible budgeting, agility, and intense collaboration to ensure customer-centricity. Although, project-led development excels with fixed scope and stringent resource constraints, it can sometimes be misaligned with broader strategies. Product-led development often focuses on impactful outcomes, allowing engineers to identify opportunities, shape road maps, and take a bigger role in building a valuable product.
According to our interviews, the concept of product-led development is gaining traction in the industry, as more banks look to launch better products, more quickly. Some banks are also rearranging development structures to help allow for agile delivery, and to better empower software engineering teams to control a distinct piece of functionality all the way through to the user experience.
Yet, many banks may still struggle to establish effective product ownership. Resistance to change from traditional project management, siloed operations, resource constraints, lack of key performance indicators to measure success are some examples in what may often result in additional burden on software engineering teams. “The biggest frustration that we had was the business; they just weren't proper product owners at the end of the day. So what we ended up having to do is we basically had to have proxy product owners on the technology side. And so what we ended up having to do was we had to keep a bunch of business analysts around, which are not a part of any agile model, to basically … do the work of the business to create that product ownership. And it was maddening,” noted the former head of core engineering at a large foreign bank unit in the United States.
A product management skill set can be difficult to find in the banking industry. This needs the right mix of technology acumen as well as softer leadership and communication skills. Banks also appear to find it challenging to retain such critical talent.
Software engineering is at a major inflection point
Software engineering, by its very nature, is a highly dynamic discipline, evolving rapidly and embracing innovations in languages, computing, and techniques. However, in the last several years, traditional ways of software development have been upended by AI. The banking industry has adopted AI-driven coding tools.21 The benefits are obvious: For instance, AI-assisted coding could create cost savings of US$2 billion to US$16 billion annually for the US banking industry, according to a 2024 study by Citigroup.22
But beyond AI, a confluence of other forces are coming together to reshape how software is designed, built, tested, and deployed (figure 2). Specifically, open-source coding, low code/no code, digital twins, and possibly quantum computing in the near future, are beginning to reshape how banks do software engineering.
Quantum computing, for instance, can represent the next leap forward for software engineering. While still in its infancy, quantum technology will likely push the boundaries of developing, designing, and maintaining new software solutions to tackle more complex problems at banks. In fact, Google recently launched Willow, its latest quantum processor, which can radically decrease computing time. For instance, a complex problem that currently would take the most advanced supercomputer around ten septillion years to complete, can now be solved by Willow under five minutes.23 Similarly, the prepackaged modeling tools presented by low code/no code software could improve development time while expanding accessibility to noncoders.24
Such advances in technology-enabled solutions could present opportunities, as well as risks, for banks’ software engineering teams.
The new reality of AI-driven software engineering
New AI tools are rapidly changing software engineering: A number of large language models (LLMs) have already upended traditional approaches to software development. In fact, every stage, process, and actor in the SDLC is being transformed—at times quite radically (figure 3).
Much has been said about how gen AI is making coding more efficient. In the recent past, application programming interfaces, open-source libraries, and crowdsourcing had become common practices to boost developer productivity, and platforms such as StackOverflow.com, Experts Exchange, and Stack Exchange, were popular among software engineers to solve programing-related tasks. But now, LLMs (often trained on data sets engineers have contributed to for years) are overshadowing such platforms and tools.25
For instance, at Standard Bank, AI tools such as Amazon Web Services’ Q, IBM’s watsonx, and Microsoft’s GitHub Copilot, are boosting software engineering efficiency.26 Goldman Sachs has also equipped 12,000 of its developers with gen AI, leading to significant productivity gains.27 As these experiments mature, banks should be able to see the business impact more clearly.
Banks should gain from these productivity-enhancing tools, given the large number of developers they have internally. In fact, large banks have approximately 15% to 25% of their total workforce employed in engineering and digital product–development tasks.28
A recent survey noted that 84% of developers are occasionally or regularly using at least one of the LLM-driven tools such as ChatGPT, GitHub Copilot, JetBrains AI Assistant, or Visual Studio IntelliCode.29 Developers may no longer search for code snippets to complete tasks, but converse with GPT models to update codes or even create code from scratch. Google recently revealed that one-fourth of their new code is being generated by AI, showcasing how AI is reshaping coding.30 Tools such as Claude and Tabnine are providing suggestions and auto-completion for developers while they write code. Of course, there are other tools such as Gemini, AWS Q, Cursor, Replit, and Codiga, each with its own features.31
These coding assistants will likely only get more advanced and useful as time goes by, opening up enormous new possibilities to write faster and better programs, ultimately resulting in significant productivity gains.32 And more recently, there has been an emergence of AI agents that can autonomously33 convert ideas expressed by humans in natural language into executable code. For example, Devin was launched in March 2024, designed to autonomously perform programming jobs, based on prompts from software engineers. These jobs include designing full applications, testing and fixing codebases, and training and tuning LLMs.34
AI-assisted coding also has huge potential in addressing the challenge of modernizing mainframes and legacy codes, such as those in COBOL, which may have been written decades ago. COBOL-driven mainframes continue to govern many banking systems.35 In fact, the industry still relies on billions of lines of COBOL code to run a range of banking applications including payments and ATMs.36 Also, given that the number of experienced COBOL programmers has been shrinking in recent years due to exits from the labor force and diminishing interest among younger developers, generative AI coding assistants could prove most valuable in upgrading legacy mainframes at scale. Some gen AI prototypes, for example, are being trained to rewrite the 1960s-era code that underpins older cores to be compatible with modern software. IBM’s watsonx Code Assistant can read, understand, and rescript COBOL-coded applications in Java.37 This will likely accelerate mainframe modernization across industries by assisting developers in transforming COBOL-driven business services at scale.
One senior vice president of enterprise architecture at a US super regional bank shared their experience: “We’re using [AI coding tools to explain legacy] coding. Explain[ing] is so powerful. Because a lot of these people have left. So forget about writing new code. Even understanding the existing code is a big deal in a lot of these. Some things are like a black box for us. Somebody wrote it some years ago … nobody wants to touch [it], so we work around it, because we don’t know how to read that code.”
Beyond coding itself, software testing is another area that is rapidly being transformed by AI. Testing software has become more challenging in recent years. The rapid acceleration of release cycles, maintaining test coverage across complex architecture, reliance on third-party solutions, and the significantly high usage of APIs have resulted in higher complexities.38 To fight against these limitations, AI testing tools are becoming more common among developers. Increasingly, engineering teams are also keen to delegate a large portion of “writing tests and writing natural language artifacts” to machines. These testing tools, such as Selenium and Code Intelligence help with self-correcting, automatic test-case generation. They can have other benefits as well, including testing at scale and continuous improvement through self-learning algorithms. AI-generated test cases can also confirm the correctness of LLM-generated codes. According to another Deloitte survey, over half of the global respondents have already prioritized enhanced testing and validation protocols to address gen AI-driven software development quality needs.39 Synthetic data creation can also help banks reduce real-world data dependencies without compromising on the quality of testing.
AI-driven tools are also helping in software design. For instance, system engineers can use natural language to feed requirements into AI tools, which can propose the initial design. These tools can offer alternative design, and respective trade-offs. Generative AI tools can also assist software engineers to better understand the connections between different systems within banks. AI-powered engineering or MLOps can also help the integration of DevOps, DataOps, and ModelOps interlacing machine learning into the process of data management, model training, and software delivery.40
Engineering for an AI-powered bank
As banks become more AI-powered, they will also likely adopt large action models (LAMs) or AI agents41 (autonomous AI models that perform actions with minimal human supervision) in many aspects of the banking value chain. Autonomous AI agents in software engineering are expected to move beyond code assistants to execute various mundane tasks within the SDLC. AI agents along with AI copilots could decrease production time and enhance product value, especially as they integrate with a multiagent workflow. One AI agent, for instance, could be able to propose designs based on requirements provided by the engineers, which can then be executed by another AI agent to generate initial codes for development. Of course, this would be an iterative process between the agents and the developer but can also help developers dedicate more time to creative tasks.
However, the introduction of AI agents will likely also require stronger risk and controls. Some examples of the major risks concerning banks include data leakage, financial loss, security around intellectual property, reputational damage, conflicts of interest risk, and noncompliance with relevant bank policies. Managing these risks posed by AI agents will be a very important of AI-focused software development. Banks should also invest in AI-specific training programs to retrain the existing pool of engineers. In fact, new talent entering the banking workforce will likely require a mix of industry, risk and compliance, and tech skills. New governance policies will also be needed to supervise the actions of AI agents.
Keeping AI trustworthy
As software engineering teams incorporate AI, these systems should be designed with trustworthiness in mind. Users, regulators, and customers want to have confidence that data will be handled ethically and without bias by the organizations as well as the AI algorithms in use. Furthermore, as regulations continue to evolve, it’s crucial for banks to establish strong governance models for AI within their software engineering frameworks.
By prioritizing AI bias and ethical considerations, software engineering can safeguard customer data while building next-gen application experience. Software engineering practices should emphasize these principles throughout the development life cycle, from design and testing to implementation. The Trustworthy AI™ framework highlights critical elements such as fairness, robustness, privacy, security, and accountability in AI models. This framework offers a unified approach for organizations to identify and manage risks, facilitating quicker and more consistent adoption of AI technologies. Ultimately, this integration can lead to more effective collaboration between humans and machines across the organization. (For more details, see “Trustworthy AI: Bridging the ethics gap surrounding AI.”)
How can banks future-proof their talent models?
As banks embrace the change that is underway in software engineering, they should also consider updating their talent models. Banks will likely need engineering teams that have deep domain knowledge and expertise in achieving highly regulated objectives (figure 4). At the same time, engineers should be able to collaborate with businesses to design high-quality products. And of course, they should have the right tools for this. How banks manage the human element, and third-party partnerships will likely define their success in the future.
US banks often have to pay a premium to attract and retain some of the best software engineering talent. Nevertheless, some problems persist. “Old-school” engineers who can handle legacy systems are retiring, leaving a talent gap for banks. As the senior managing director at a US super regional bank stated, “There’s always a deficit in terms of architectural and system architects and software architects where they truly understand the history of why our architecture looks the way it is and how it’s evolved and understand why. So I think that’s always a key man risk, if you want to call it that.”
In addition, fewer new engineers are learning these legacy languages—leading to a talent rift between demand and supply. This can impact IT budgets as banks work to hire and train for legacy systems.
And when it comes to new technologies, like ML, some banks, especially smaller banks, struggle to attract such talent. Almost all executives in our interviews noted that they face a significant gap in these new skills.
Complicating matters can be an expectations mismatch between the younger generation entering the workforce and experienced managers. The new pool of engineers is ambitious, and want to work on cutting-edge applications, as most of their work is with the “plain vanilla,” extant platforms. Older performance standards that do not reward innovation and creativity further exacerbate attrition rates.42
And as banks continue to evolve, some of the more experienced developers may have a skeptical view of more agile software development methods. “Some people who’ve been in the industry for longer, they might think it’s kind of gimmicky,” said the former vice president of data engineering at a Universal bank. “They may understand agile, agree with agile philosophically, that they want to move with agility. They might think the additional ritual of a standup and the scrum boards are kind of a gimmick. Historically, if they haven’t had a scrum master, they may be less likely to think that that’s important. They’re probably going to go with how they’ve been operating historically, and that’s more lean.”
In addition, gender disparity can still be found at software engineering teams. Even though the share of women software engineers is at 23% in the United States, they are still underrepresented compared with women’s larger share of jobs in science, technology, engineering, and mathematics areas.43 Several interviewees pointed out women engineers often experience a lack of mentors, gender bias, and may face unequal growth opportunities. Banks should provide a conducive environment for developers to build products that reduce gender bias and stereotypes in their outputs.
To help bridge this divide, banks should rethink their talent strategies. Elevating their software engineers by granting them a voice in crafting product road maps, budgeting decisions, and third-party management could help morale and bring new efficiencies. They should also revamp current governance policies and elevate software engineers to think and build holistically, especially as they shift toward product-led engineering. For instance, banks should increase investments in developer experience to improve day-to-day productivity and satisfaction.44 Goldman Sachs’ “Goldman Sachs Developer” platform does this by positioning engineers as pivotal product-development contributors.45 Also, emphasizing a culture of self-learning and curiosity within budding talent to innovate and challenge existing systems and processes can be very helpful.
Banks should also equip engineers with AI tools to tackle more rewarding, value-added work. At the same time, as noted above, banks are already leveraging gen AI to simplify legacy systems, resulting in reduced training costs and seamless transitions. Some credit unions such as Golden 1 are experimenting on gen AI’s capability to bridge the gap between old coding language and newer programming language frameworks.46
Furthermore, there may be merit in revisiting the performance standards to reward pioneers and creative mindsets as well as offer equal growth opportunities. Banks should also foster an environment where engineers can experiment and invent, akin to the tech industry. In addition, banks should also consider partnering with universities to nurture next-gen talent through new programs and internships.
Banks should also prepare for the uncertainty around resource planning that often comes with modern software engineering practice. Providing clarity about their evolving roles and responsibilities across the SDLC, offering training programs, and revamping governance policies are other important steps to consider.
How can banks rethink their third-party partnerships?
Another area of reassessment in future-proofing software engineering at banks is the role of third parties.
Third-party partnerships have been critical in many banks’ digital transformation journeys.
Balancing in-house development versus external, third-party outsourcing is a perennial challenge for banks. Some banks lean into third-party providers, while others may prefer to do the bulk of software development internally, sometimes through their captive offshore units.
Vendors offer many benefits, including the ability to scale up talent and accelerate deployment. Many banks also look at third parties to help bridge the knowledge gap of new and emerging technologies. As the senior vice president and head of digital experience at a US super regional bank put it, “We’re not building as many proprietary technologies and solutions. We’re more focused on connectors, adapters, and integrating. So a lot more of our spend is with third-party providers on enterprise license agreements, and creating APIs and adapters to them, and then doing customization and implementation.” Some banks are expanding the partnerships with a new batch of providers, leveraging new AI models to develop use cases it their businesses across customer support, IT, sales, and other areas. For instance, BBVA is working directly with AI firms such as OpenAI,47 BNP Paribas announced its partnership with Mistral AI,48 and TD Bank highlighted its work with Cohere.49
Many banks may have current relationships with third parties that could improve on several dimensions. For one, these partnerships may be focused on cost arbitrage, limiting the opportunities to extract the most value from the relationships. And at least some banks may have too many vendors, who are only involved in a piece-meal fashion on a large project. Juggling too many partnerships can be suboptimal. These conditions can result in a fragmented approach to product development and impedes the speed of deployment. Integration and interoperability become a key challenge, shooting up costs in many instances.
And regulators appear to have increased their efforts to ensure that banks are managing third-party risks as well. “If you're working with a third party who’s in the cloud, and they’re working with other people in the cloud, by transitive properties you’re also tethered to other third-party customers. And so, we’ve had to take a strong look at which third parties you work with, in terms of their engineering, And now you’ve got third-party GRC, risk and governance coming out on this, because we are much more impacted by our third parties in ways we didn’t anticipate because of all the other people they dance with. And so, it’s made us want to have fewer third parties than more,” said the former senior vice president at a US regional bank.
With the evolution in software engineering, third parties are also changing. Some are updating their technologies and upskilling their workforce faster than many industry players. Consequently, the nature of these partnerships will likely change.
In the future, banks will likely look to implement some degree of self-reliant models by leveraging new technologies and tools across software engineering even as they may continue to rely on third-party partnerships.
But to extract more from these partnerships, banks may want to change their current decision-making and governance to build strategic partnerships with fewer players. They can consider looking for third-party solutions that are more value-adding, especially solutions that are transferable, scalable, and fungible across the SDLC and beyond. For instance, BNY partnered with Volante Technologies to deliver an agile, 24/7 real-time payments capability. The partnership ensures that the bank can seamlessly scale and adopt additional payment schemes in the future.50
It can be important for banks to go beyond partnerships that only augment talent to support legacy systems. While impactful in the short term, staff augmentation may only resolve half the puzzle, for example, keeping the current systems running. For long-term impact, partnerships should evolve from cost arbitrage to providing strategic value (figure 5), by focusing on vendors that can elevate their business outcomes. An ideal partner should be able to provide solutions that drive business customization and deliver value focused output, in addition to building new tech capabilities like moving to the far-right end of the chart below.
However, vendors should also consider altering their positioning in banks’ value chain. Often, banks may be looking to third parties that offer “big picture thinking” and are ambitious to grow alongside banks. Executives interviewed also cited that third parties often lack agile solutions which can deter long-term strategic commitments. Third parties should look to provide iterative and frequent value with their solutions to stay ahead of the competition and complement a banks’ engineering practice.
In addition, some banks may need to implement a new hub-and-spoke model with software engineering at the hub offering flexible solutions to different banking functions. This could embody agility within and outside software engineering by attempting to allocate optimal resources, reducing duplication, and perhaps also integrating and creating unified data streams. These efforts could result in better and faster product development, among other benefits.
Strategic use of a captive model to embrace the change in software engineering
US banks have been leveraging captives or offshoring units to manage back-end operations for at least two decades now. Banks choose locations for these units, such as India, to leverage local talent pools and manage costs effectively.51 JPMorgan, for instance, opened new campuses in India focused on technology and operations.52 However, there are some shortcomings with these models including high attrition rates, need for continuous recruitment and training, and the burden of real estate and geopolitical risks, as per some of the interviewees in our research.
Despite these challenges, offshoring units are expected to continue to be important for some banks, especially as the need to be co-located for software development teams is diminished. As banks look to enhance internal talent with modern software engineering, offshoring units’ flexibility to ramp up or down as needed can be a handy and cost-effective strategy. Talent in offshore locations can be leveraged as an extended arm to develop software with specific trainings on AI tools. They can be plugged into different parts of the development cycle, depending on the needs and requirements, and can result in faster high-quality software.
Going forward, banks can also use a hybrid model that combines offshore units with third-party providers, helping them to scale operations efficiently and manage peak demands without overstaffing.
Embracing the new future of software engineering
As banks prepare to enter this new future of software engineering—where software applications are less cumbersome, faster to deploy, and generally more efficient—they could benefit from new strategies and operating models.
But implementing these changes in the current banking environment, where regulatory compliance and other complexities are pervasive, is likely easier said than done. Having the right talent and working with third parties in this transformation journey will be important.
Furthermore, with other trends such as open banking, banking-as-a-service, embedded finance, digitization of money, digital identity, and alternate payment models reshaping banking, a modern approach to software engineering can significantly help banks thrive in the exciting new future.
