How Financial Institutions Can Survive the Fintech Assault

Executive Summary

Today, much is expected from internal IT teams, including new delivery models and innovative technologies–in part to reduce losing customers to competing fintech companies springing up seemingly overnight. Business managers and employees expect IT to keep systems running with little to no downtime or interruptions. Business executives require IT to help drive down costs, reduce risks, and provide competitive technologies to enable business transformation initiatives and growth. Customers and partners want IT to adopt the latest and greatest technology to make the business of doing business easier, while simultaneously reducing the cost.

Actually, the list of wants is longer than the entire content of this white paper! In complex corporations where change is dynamic, where projects compete for funding, and where priorities are continually shifting, delivery of these expectations requires creative forward thinking models to meet standards for stability, security, risk, and speed to market. 

It almost seems trite to predict that the days of old-fashioned centralized IT departments are numbered—but since many financial institutions maintain the old approach, perhaps a prediction is desperately needed!

The rise of digital technology has already significantly changed the landscape in the financial-services sector with an escalating increase in fintech (financial services-oriented technology startups). While banks continue to role out financial planning and trading applications through smartphones and social media—even incorporating cloud technologies and robotics little by little to reduce costs and increase quality—the number of startups in fintech has risen more than 50 percent since 2011.

These competing factors offer both new opportunities and new competitive threats for the financial industry. As a result, the performance expectations for technology organizations by business executives are accelerating as they see competition intensifying. 

Usually out of desperation—rather than purposeful planning—technology groups are created within demanding business units to respond to their most urgent and painful (and sometimes even critical) needs. In such circumstances, these groups function independently from the centralized technology group tasked with supporting the IT needs of the entire corporation. While they are able to be more nimble and can focus exclusively on the needs of the specific business they support, they usually end up significantly removed from corporate processes.

For instance, a strictly organic growth of decentralized IT teams often results in different standards, unique to each business, in information security, architecture, or disaster recovery being implemented. This tends to balloon the staffing, hardware, and policies throughout the company as each team addresses their unique requirements, resulting in growing costs and discrepancies in standards.

In this situation, conflict and hostility escalates between the business unit (including its specialized IT staff) and the corporate IT group. Used to the “one glove fits all” philosophy usually adopted by those tasked with setting and keeping standards, corporate IT demands compliance of the business unit IT. The business unit recognizes that those monolithic standards will cripple its performance—and those business units who drive the most revenue for the corporation have a very compelling argument of performance over bureaucracy. 

Eventually failure to adhere to policies will result in a significant corruption or compromise of data/systems (which outweighs the revenue) and crippling bureaucracy will be imposed upon the business unit(s). As time passes, and events are dimmed, the cycle will start over.

This cycle can only be broken, or avoided, with corporate recognition that some business units have specialized needs within the corporate IT and responding with careful, measured steps that address unique business requirements and sound IT standards.

This white paper will discuss the advantages and disadvantages of centralization and decentralization and highlight two recognized solutions, which focus on the advantages of both while reducing the disadvantages.

Advantages and Disadvantages of Centralization

Centralized delivery models can be aligned by functions – such as Application Development, Project Management, Networking, Information Security, Infrastructure, Architecture, Desktop Support and Field Services. 

The advantages of centralization vary in priority according to the organization’s mission, vision, goals, and delivery needs. Heavily regulated industries, such as banking and wealth management, look to centralization of standards, protocols, security, and governance as key benefits. Additionally, large companies look for benefits in cost reduction, leveraging vendor relationships, shared infrastructure, budgeting, improved resource allocation, and disaster recovery. Disadvantages revolve around slow response and a too frequent disconnect from business units’ needs. A more complete explanation of pros and cons are below.

Advantages:

•  Leveraging buying power: This is inherent in economies of scale.
• Standardizing on frameworks, standards and vendors: allows a reduction of maintenance and training costs and facilitates volume pricing.
• Creation of internal competency centers of expertise: IT builds a bench of qualified support professionals instead of being “one deep”.
• Develop more mature areas of expertise and focus on preventive vs reactive; i.e., configuration management, capacity planning, performance analysis, monitoring, automated correction and self-healing.
• Identification of IT expenses: Costs are tracked centrally and transparently, which will empower and improve the budgeting and funding process.
• Identification and managing of security and compliance risks: Such risks are much easier to notice and then mitigate when they are grouped centrally.
• Effective implementation of best (or standard) practices of production control, change management, release management, SDLC, division of labor, service management.
• Improvement in support for underfunded divisions and business units.
• Reduction in redundant resources.
• Improve chances of success for DR and lower the costs of DR.
• Centralize and “operationalize” commodity services and focus personnel on strategic initiatives.

Disadvantages:

• Sacrifices flexibility for efficiency: Individual IT managers and business units find themselves handcuffed by policies and standards. Centralized IT must focus on the entire enterprise first and individuals second; i.e., the good of the many vs. the needs of the few.
• Cannot leverage local partners and vendors: While a centralized contract may provide great pricing, local managers may be unable to leverage local vendor and partner relationships.
• Loss of control for business units.
• Loss of personalized service for business units.
• Increased bureaucracy, with little or no adaptability—inherent in centralization.
• IT further removed from understanding and aligning with business unit strategies.

Obviously, these pros and cons will be more or less numerous and more or less important based on the perspective of IT vs. business. But even business units worried about the disadvantages of centralization will be supportive of the benefits during cost reductions and increased regulatory oversight.

Advantages and Disadvantages of Decentralization

Decentralized delivery models are aligned by business units or projects—this can include separate affiliates, department specialties, one-off businesses, or big projects. Decentralization is usually tuned to address the disadvantages of centralization. Although a decentralized IT structure does help to overcome the disadvantages of centralized management, it has its own unique set of advantages and disadvantages. 

The main traits of a decentralized approach include flexibility, empowerment of business units, and service orientation. Organizational flexibility and responsiveness are also major advantages. By their very nature, however, decentralized systems lack a centralized control. This can be very dangerous as conflicting ideas arise and clashes in policy lead to delays and inefficiency. It can also expose the company to increased risks from lack of controls and/or regulatory compliance.

Advantages:

• More inclusion with IT allows business units to pursue the strategy for realizing both short-term and long-term goals—returning more control to the business.
• IT selection and configuration can be tailored to each business unit—resources are allocated and prioritized by each business unit’s needs, yielding more personalized service.
• A high degree of autonomy allows for faster responses to new IT trends or business units’ evolving strategies, products, or services.
• Faster response to problem solving and/or addressing user issues.
• More flexibility to respond to changing markets or competition.
• Able to leverage local partners/vendors to build successful relationships and synergies for the business.
• IT assumes more of a partner role than support role as it learns the business and its goals. This produces more synergy for the business to better compete and expand its products and services and increase profits and business line efficiencies.

Disadvantages:

• When built organically (immediate response to a need), decentralized IT groups function outside of proper standards, policies, and procedures necessary to govern risk, increase cost efficiencies, and provide stability.
• Increased costs through duplicated systems, applications, software/hardware, and staffing.
• Increased risk of a single point of failure within the business unit’s specialized system/platform and/or workforce.
• Inefficient budgeting for hardware/software upgrades or replacements.
• Often work in competition to the centralized IT organization.

Evolving Financial Markets Equals Evolving Strategies

In order to meet customer demands within the new financial marketplace by offering competitive products and services, with improved speed-to-market, while focusing on cost controls and industry best practices (not to mention ongoing support of legacy systems) the financial institution’s technology teams have to be agile, business savvy, and responsive. 

Sadly, this description is not accurate for most established financial IT departments. Meeting customer demands and competitive threats, while satisfying regulators, will require more than a mere reexamination of current “go-to-market” strategies; it requires company technology leaders with openness to new methodologies and courage to sell these methodologies to business and risk leaders. 

The importance of selling the changes necessary to compete in today’s financial arena can’t be overstated! Many IT professionals reading this paper have already muttered to themselves about business executives increasing demands from IT while reducing the IT budget. 

There are two agile strategies that have shown success within established financial technology organizations—Centers of Excellence and Embedded IT.

Centers of Excellence

Wikipedia defines Center of Excellence (CoE) as; “A center of excellence is a team, a shared facility or an entity that provides leadership, best practices, research, support and/or training for a focus area.”

A more appealing definition for the highly regulated financial industry could be that it is simply “a discipline of delivery within an organization.” A different discipline yes—but still a discipline.

The core principle in a Center of Excellence is to build out key standards, architectures, policies, procedures and technical/business expertise across the company. 

At the outset, the CoE is presented for introduction and acceptance across the enterprise. As the CoE develops, so will opportunities throughout the organization. The realized benefit of a CoE is small unless you go enterprise-wide, so, while it may start in one area, the beginning must consider the big picture of a whole company adoption.

As a growing evolving organism, a CoE must be viewed as an iterative practice that requires insight and feedback from all functional areas. From the outset, all stakeholders must understand and accept that introducing CoEs into the company will result in a change in company culture—making executive sponsorship of Centers of Excellence essential. The same is true for embedded IT teams.

A common approach to CoEs is to identify groups of people with specialized skills, expertise and knowledge base and assign them the responsibility of “coaching” other teams. Hence a technology Quality Assurance (QA) CoE becomes a group of QA experts establishing standards, guidelines, best practices, and evaluations for those QA professionals scattered across various specialized development teams—replacing the centralized approach of one general QA team for the entire company.

One caution needs to be highlighted. For those institutions coming from a strong historical centralized approach, there is a high tendency for CoEs to adapt more to centralization than decentralization. This will result in significantly reduced results and increased costs, nullifying the tremendous opportunities offered by CoEs. 

Embedded IT teams

Embedding IT teams can be an even bigger step for companies than CoEs. This is because Centers of Excellence can provide more comfort to leaders amid change due to their tendency to have a more centralized look and feel. 

While the rationalization of holding fast to central processes and operations remains somewhat true today (pooling resources, consolidating data, standardizing platforms, etc.), this justification is being reduced daily with maturing cloud based platforms and interoperable digital technology allowing diverse systems to work together more easily.

Enterprise standards no longer need to compete against the benefits of local business unit creativity. With agile IT capabilities growing exponentially, standards and controls can be interfaced with embedded IT teams at the business unit level. In this way, financial service companies can reap the benefits of common standards, systems, architectures, and policies while enhancing product flexibility and closeness to the business’ customers throughout the company.

However, just as CoEs are susceptible to the pull of centralization (unless consciously and aggressively evaluated), embedded teams can quickly escalate toward total decentralization.  This is especially true when the organic embedding discussed in the Executive Summary occurs. 

Allowing too much decentralization (embedded siloes) injects the risks examined in the organically grown decentralized teams previously reviewed. The intent of purposefully embedding teams is to proactively prevent this risk from developing.

Another weakness of embedded teams operating as business siloes, is that they tend to provide specific, and almost always limited, offerings. This leaves team delivery separate from the central technology organization and often leaves them waiting upon key infrastructure, security, or architecture delivery (from people far removed from the customer) before going live with their application.

The proper approach is to change the entire technology’s organizational scope to support embedded IT professionals with a wide range of applications, systems, and platforms. This allows standards, consistency, security, risk, and interoperability to be managed by an efficient enterprise architecture team—coordinated with common APIs.

Some financial firms have started down this road, only to turn away because of improper planning, lack of commitment to the change it brings, or failing to understand the full requirements (or in some cases improperly communicating them to the executive team).

Conclusion

The financial services sector is now experiencing the digital transformation that disrupted the media, retail commerce, and telecom in the 1990s and 2000s. Previous transformations clearly indicate that when the disruptive dust settles the remaining leaders will be a mix of incumbents that innovate internally and those who move aggressively to partner with strong new entrants. Incumbents that don’t change will die.

There has always been tension between IT and the business units. Business units think data center managers are slow to deliver new technology or to quickly address business needs, either proactively or reactively. Data center managers see business IT groups injecting instability and risk into the systems—both specific business systems and centralized. Each group has legitimacy in their views and this legitimacy, rather than competition, can be emphasized through a collaborative hybrid using either the CoE approach or embedding IT teams within business units.

Furthermore, such hybrids are more able to maximize the advantages of centralized and decentralized IT management by implementing a planned—rather than organic—hybrid, capitalizing on strengths and minimizing weaknesses. 

This approach will facilitate IT and business working collaboratively hand in hand and involves taking like processes and like technologies across lines of businesses and placing them within a business technology center of excellence or embedded IT units.

This would allow IT teams to focus on what they do best—delivering customized business specific technical solutions in a timely manner—while significantly improving adherence to company standards through better accountability and interdepartmental communication. 

It will also allow IT teams to participate in the evaluation of new entrants—particularly as many are now pursuing business models based on collaboration with banks or even being acquired by them. However, without IT involvement business units are less likely, and/or less capable to see ways they can improve customer service by working cooperatively with the nimble entrants—who are less constrained by layers of bureaucracy, regulation and conservative corporate cultures unused to rapid change.