Chapter 13

Deciding Whether to Build, Buy, or Partner

IN THIS CHAPTER

Changing your company digitally

Digging into reasons to build or buy

Picking out a FinTech partner

Sorting through licensing models

Acompany decides it needs a new piece of software. So begins the traditional build versus buy versus partner discussion.

For what is potentially a major budgetary spend, the decision-making process can be subjective and inconsistent. Within most organizations, big or small, vested interests will argue vehemently for one approach or the other, and everyone believes he is right!

When faced with an important business decision — such as how to acquire new software capabilities — it’s helpful to start by asking, “What problem are we trying to solve?” A small start-up business will understand its problems very clearly. However, as businesses grow and require more technology development, it’s surprising how many forget that basic, core question. In many cases, decision-making becomes more about internal politics than problem-solving.

A major financial decision should always be based on how best to meet the company’s requirements. Moreover, firms need to decide how critical the development is to their business and what revenue or profitability it might generate. Based on this evaluation, they can decide how critical it is to prioritize the development now and whether the company has the domain expertise to build and maintain the solution itself.

What shouldn’t happen is that the internal IT department decides that it can roll out a major new IT initiative without any special expertise in that area. The project then invariably takes longer, costs more, and is of inferior quality compared to a solution from a third-party vendor.

Many IT projects end up being a combination of build and buy. The decision can become more of an art than a science, figuring out which pieces to build and which pieces to buy. In this chapter, we walk you through the points to consider when deciding the best way to acquire new software capabilities. While some of the points may seem like common sense, many companies overlook quite a few important considerations.

Transforming Your Company Digitally

The “build, buy, or partner” decisions are all part of the overarching digital transformation strategies that financial institutions across the world are currently pursuing.

Digital transformation is a recurring point of debate for board members. Analysts are valuing digital companies more favorably than traditional financial institutions. At the same time, the majority of large-scale digital innovation programs fail, and therefore businesses see digital transformation as a significant risk factor. Research has shown that 70 percent of complex, large-scale change programs don’t reach their stated goals.

Here are some of the top reasons digital transformation programs fail:

• Lack of ownership and digital transformation skills at the top: A company’s CEO and all senior management personnel must drive its digital transformation. Success is determined not only by keeping up with business challengers but also by adopting the applicable strategies to compete with tech giants and cooperate with FinTech start-ups. Companies that don’t have appropriate FinTech and digital governance at the helm are likely to face ongoing complicated and costly issues.
• Not changing the business model when change is needed: While developing and launching new services and products profitably is difficult, reinventing a bank’s or asset manager’s business model is even harder. Business model changes are often necessary, however, because of the way technological changes affect systemic processes. Senior management must be integrally involved in business model changes, as such changes often involve reallocating capital across various business units. The new model must be integrated across the entire institution.

  NUMERIX: THE THIRD PIVOT

  Numerix CEO Steve O’Hanlon faced several challenges as a chief executive during times of swiftly changing market environments. These were times when we witnessed the convictions of a man and entrepreneur on the front lines who, in the end, turned bold situations into positive opportunities, even if it required reinventing Numerix. As any good entrepreneur, Steve possesses a strong sense of confidence, built on years of leading, experimenting, taking risks, and always pushing hard for a company’s growth — whether it’s turning around a Numerix that was deeply struggling prior to 2004 or being the first in the industry to introduce new risk analytic offerings in 2009 in response to the global financial crisis.

  Steve’s goal was and is currently to position Numerix as a dynamic financial technology company providing a next-generation risk platform. In 2015, the company pivoted again, which started the process of establishing Numerix as a FinTech brand in the market. During this time, Steve positioned Numerix in a direction that broadened its visibility as a pricing and risk-calculation company into a provider of trading and risk management systems that are unique and disruptive to the status quo. As an example, he realized that legacy trading systems were too costly and time-consuming to upgrade from one major release to another. Banking consumers’ needs and expectations had changed to real-time, on-demand responses. As a result, Steve has had Numerix leverage all the technological breakthroughs in the area of open source to ensure that the company doesn’t reinvent the wheel with certain aspects of the technology stack but instead evolves in the areas that offer a competitive advantage. As such, a goal for Numerix development is to evolve its platform and core applications in the same manner as any SaaS offering, which is to ensure that upgrades happen on the fly and actually occur while people are using their products. At the time of this writing, Numerix is living the vision and offering early aspects of this.

  This move to a transformative and disruptive identity can be accomplished only by someone who embraces and leads change in an organization. When dissatisfaction occurs with the present, Steve acquires a vision for how things should be and develops a clear plan for the steps that need to be taken. But he also understands that change is uncomfortable, which is why he cultivates an open, transparent culture that supports Numerix employees during transitions to accept the changes. Employees know why the changes are inevitable and important and why the company as a unit needs to get over the mental hurdle that change represents.

• A lack of customer focus: Many firms focus on the internal benefits that the latest technologies can offer and forget the main reason for digitally transforming the business: their customers. They should be asking “Why are we doing this?” and understanding that the ultimate priority is to improve the customer experience and provide customers greater value.
• Inability to build a FinTech ecosystem: McKinsey, one of the largest strategy and management consulting firms, has suggested that companies facing challenges need to consider the power of ecosystems, claiming that “by 2025, almost a third of total global sales will come from ecosystems.” Your FinTech ecosystem is your network of relationships with start-ups, scale-ups, key industry partners, financial regulators, and the investment community. Financial institutions developing strategies focused on a digital platform need to offer the technology and operational infrastructure to attract the top FinTech firms, to collaborate via open APIs, and to present their services (either as a white-labeled offer incorporating the institution’s brand or under the FinTech firm’s brand) to the institution’s clients.
• Skills deficits: Employees must receive appropriate training to enable them to understand and apply the benefits of FinTech, lean start-up methodologies, and Agile development frameworks. Investing in a diverse and knowledgeable group that has adopted such skills can provide a crucial competitive benefit.
• Compensation models that don’t reward intrapreneurship: It’s important that successful “intrapreneurs” — that is, people who take creative initiative for the benefit of the company — are appropriately compensated. However, many institutions maintain traditional rewards programs and bonus systems, in which taking risks and participating in effective change programs isn’t highly valued. Such organizations will find that the best and brightest employees won’t find in-house corporate transformation positions appealing. That means that employees who would excel in those positions may leave the firm to go work for a FinTech company.

Exploring Reasons to Build or Buy

Put yourself in the role of a chief technology officer (CTO) at a large bank. Your technology architecture is very old, and neither you nor your IT team wants to change too much too quickly. To rip out the old system and replace it immediately would be too costly and too risky. (If this were to go wrong, you’d have to look for another job!) You need a new technology solution that solves a given technology problem or meets a given opportunity, within a given budget, and that works on top of the old legacy system.

Table 13-1 summarizes the build versus buy decision-making process. Check out the details in the following sections.

TABLE 13-1 Building versus Buying

When to Build	When to Buy
You require control over development and functionalities, including regulatory requirements.	Third-party software is critical to maintain your business operations.
You need ad hoc applications specific to your business.	Available software addresses your problem, so there’s no need to reinvent the wheel.
Your problem is unique to your firm, and there are no third-party vendor solutions.	The application can be used throughout the organization and interacts with core systems.
You need to solve a specific problem in a given silo of your business.	You want the greater flexibility and adaptability that comes with ready-made solutions.
The company has the resources to build, maintain, and support an application that is built by a team with relevant expertise and loyalty.	Your IT department doesn’t have the relevant expertise to build, maintain, and support a custom application. Your IT department doesn’t have the time and resources to continually collect user feedback and enhance the software.
A customized application gives your company a competitive advantage over competitors.
You want to own the source code.

Looking at reasons to build

Developing new software can be expensive, particularly if the build is large and complex, and can require a large team to build it. Nevertheless, many banks have traditionally opted for the build option, arguing that in-house development ensures better delivery. Internal IT teams tend to agree with that reasoning, having both a vested interest in job security and a delight at the prospect of building something new and interesting.

But is that really the best approach? Often it isn’t. Why?

• Research from the independent Forrester Group has shown that more than 50 percent of all banking consumer experience projects took longer than expected to complete, resulting in overspending. They also found that projects using (or reusing) internally built modules are more likely to suffer from overspend issues.
• A financial domino effect occurs later in the process, as internal projects are more likely to need further fixes and suffer from high maintenance costs. This ongoing burden takes time and resources from a team that should be focused on keeping the product up-to-date with the latest technological changes. This inevitably leads to architectural inflexibility in the software, with too many elements being hard coded, resulting in frustration both internally and externally. Moreover, because a project has cost so much initially, there’s a natural tendency for management to continue to support it, even when the maintenance costs are quite high.

So if building is such a quagmire, why would any company want to do it? Two compelling reasons to build are (1) that the built software will differentiate you from your competitors in a meaningful way, and (2) that what you want isn’t available from a third party and can be considered an extension of an existing in-house application.

Consider what problem you’re trying to solve by developing the technology. Is the particular issue you’re attempting to answer connected in specific ways to your primary value proposition? If yes, or if you need a solution that’s unique to your business, then you should build it as an ad hoc application that’s specific to your business needs.

Of course, this assumes that you have a strong IT team capable of building and maintaining it, so you’ll have total control over any development and features. Having control is particularly important if your team will need to install, integrate, support, and update the new software themselves. Because your team will have access to the source code, they can identify and fix any bugs internally to reduce downtime and promptly release updates that resolve any problems. Moreover, in today’s environment, many firms are paranoid about data leakage, so maintaining both product and data within their own environment and having control of their own cybersecurity are priorities.

Some financial institutions will also want to maintain control of proprietary development that provides them with an edge over their competitors. For example, a company may have algorithms built by its internal quant teams that provide enhanced trade execution or insight into the market. In such cases, additional costs are justifiable to protect the associated intellectual property. Furthermore, integrating an external solution with such legacy technology can be a potential obstacle to buying external FinTech technology.

Checking out reasons to buy

Is buying the better option? In many cases, it is, but the right answer depends on the factors we explain earlier in this chapter. We review those now from a “buy” perspective.

The pros of buying

First of all, is the particular issue you’re attempting to answer connected in specific ways to your primary value proposition? If no, or if the answer isn’t obvious, then buying an existing technology is frequently the better decision in today’s technology environment. Your internal resources should be devoted to projects that directly support your core business practices.

Buying can also relieve your internal IT team of the burden of getting and staying up to speed on the latest technologies. Internal development teams are typically less familiar with the required code for a new initiative than third-party specialists are, and they are likely to underestimate the resource or time commitments required.

Buying can save money, which is important in today’s financial industry. Capital adequacy requirements have increased to meet regulatory obligations post-2008/2009, and interest rates are low. These factors have led to a contraction in bank balance sheets. Financial institutions don’t have the budgets to constantly finance new technology builds, so there’s no appetite to build custom software that reinvents the wheel when it’s readily available from third-party vendors.

The cons of buying

Buying isn’t a perfect solution, of course. The license costs to deploy the software can be significant, including annual maintenance costs and version upgrades or new modules further down the line. In addition, choosing a FinTech company can involve risks. If you go with an external provider that ultimately can’t deliver on the project, or can’t meet performance or security requirements, you’re out considerable time and money. To avoid such problems, a tortuous onboarding process may be required, in which FinTech firms are subject to rigorous due diligence from the institution’s procurement department and a full-scale information security audit to ensure that they meet the technology, cybersecurity, and/or encryption prerequisites. All of that vetting further extends an already long sales cycle and can seriously challenge a FinTech’s company’s ability to stay in business while it’s waiting for the associated revenues from the contract.

As a result, a potential buy decision requires both the buyer and the FinTech provider to carefully evaluate the benefits of the proposed relationship. The buyer needs to reconcile the licensing costs for the product relative to an internal build. The FinTech provider needs to feel sufficiently rewarded by the licensing and other revenues to go through the onboarding pain imposed by the institution. The real benefit for both, though, is the shared cost of development among all the FinTech firm’s clients. This sharing ultimately enables the FinTech firm to continue developing and enhancing the product.

NUMERIX: MEETING EVOLVING DEMANDS

Breaking through the mental hurdles brought about by the financial crisis and its subsequent regulatory remedies enabled Numerix by 2017 to absorb and overcome changing markets and quickly develop industry-leading products and services to meet evolving industry demands.

Steve O’Hanlon took this as an opportunity to figure out the 21st-century incarnation of what would make the company more successful as Numerix advanced toward the next decade. The major goals of Steve’s turnaround plan were a new product strategy, a stronger focus on strategic partnerships with complementary technology firms, the development of the industry’s strongest pool of quants, employing financial/software engineers and technology platform architects, and building out a more significant global presence.

There’s no question each of these goals has been achieved. Today, Numerix is a global force in FinTech, with more than 20 offices, 700 clients, and 90 partners across more than 26 countries. Numerix is now recognized across the industry for its many breakthroughs in quantitative research and its dynamic stack of analytic capabilities, technology, and business services. The company is proud of its reputation for being able to price and risk-manage any derivative instrument — from vanillas to the most sophisticated exotic products. Numerix products and services are utilized in many forms on both the sell side and buy side, including banks, broker dealers, insurance firms, hedge funds, pension funds, and asset managers.

Generally speaking, a FinTech firm will deliver better technology than an internal team, largely because it has a more developed knowledge of the new technology requirements and can deliver in a more agile way (certain top-tier banks with 10,000-plus developers may be exceptions to this rule). That’s not to say that you couldn’t hire a few IT specialists with the needed skills in data science, machine learning, blockchain, and other modern technologies, but they wouldn’t be cheap, and you’d have to keep them on payroll full time, even when you weren’t using their special skills. You’d also have to train your existing staff on the needed technologies, at even more expense. Buying IT expertise is very often a much better value than building internal expertise.

Finding the balance between new and legacy software

Legacy systems are a big problem for financial institutions. They spend a lot of money maintaining legacy systems that probably won’t be able to handle future customers’ needs. To survive and thrive in the FinTech era, traditional financial services firms have put digital-transformation projects at the top of their agendas. However, while most companies recognize the need to transform their businesses with technology, they struggle to understand how to implement that change and securely move away from their legacy systems.

Here’s a very public example of failing to migrate from a legacy platform successfully. The U.K.-based TSB Bank attempted to migrate from its outdated, core banking system to a new digital platform. However, the new system failed, resulting in a period of operational chaos and consumer complaints that continued for more than a month. The magnitude of the problem was so great that the CEO lost his job and the Bank of England (BoE) and the Financial Conduct Authority (FCA) published a paper outlining the significance of operational requirements, warning banks that they would levy fines if service disorders lasted for a prolonged period. Fearing such a scenario in their own companies, many IT leaders have delayed implementing new digital transformation projects, even though they know they need those new technologies to survive.

Thorough strategic planning is required to replace legacy systems with modern technology. You can’t just abandon your current systems. While transitioning from the old system to the new, the new technology stack must peacefully coexist with the legacy systems, at least on a temporary basis. Many established players use FinTech firms as their development sandboxes, reviewing proofs of concept (or proofs of value, as has been more recently coined) using lab-style environments within hybrid cloud solutions. Being able to lab-test a new solution can help organizations plan system upgrades and apply new technologies in a “safe” environment.

Many financial institutions have also invested in application program interfaces (APIs). APIs can specify how software components should interact using a set of routines, protocols, and tools for building software applications. They enable banks to support new technologies more efficiently, work with FinTech firms, and potentially build out their own disruptive offerings. Established firms can add more agile solutions around their core legacy systems, as if they were “satellites” around the core. Banks can adopt alternative digital solutions to replace siloed technology, one at a time. Core technology can also be combined with FinTech firms’ solutions through APIs to design market-ready digital products.

As part of this API economy, some financial institutions and larger vendors have developed a digital layer on top of their legacy platforms. This digital layer facilitates API integration with many FinTech firms, allowing them to introduce or withdraw digital offerings based on market response. However, at this point, the number of established players that consistently embrace such approaches is still quite limited.

Finding a FinTech Partner

Picking the right FinTech firms to team up with — the topic of this section — remains challenging for banks, because they’re still developing their innovation culture for the new digital environment. For their part, FinTech firms need to better articulate the clear benefits of their technologies and better explain how they can work with banks to deliver change. More banks are lately building FinTech partnerships, motivated by shortages of in-house expertise and the desire to save time and money. In addition, the perception barriers that have previously prevented banks from partnering with FinTech firms seem to be diminishing as the partnerships increase.

The results of such partnerships have been mixed. Banks are still developing the innovation partnership model, and there are still major impediments, such as the time taken for procurement and information security onboarding and the difficulty in contractually defining a longer-term technology retention. This engagement process is also influenced by the contrasting sizes and cultures of the respective organizations, although many of the staff at the FinTech firms have come from banking backgrounds, so finding aligned expectations should be possible.

As part of this process, banks are steering or participating in many accelerators, incubators, and training programs. These initiatives ensure the banks early access to technology and talent without having to take an equity stake in the FinTech companies. Such arrangements offer FinTech companies access to resources, data, space, and networking opportunities to test and showcase their minimum viable product (MVP) while sometimes leading to funding as well.

There’s no single best approach on how to engage with FinTech firms. However, while banks are increasingly looking to such firms to drive innovation, whichever way they choose to partner, banks are still struggling to implement new technology successfully. Many banks are paying lip service to a partner approach in which a head of innovation is employed without having any specific remit or budget. This situation results in a gap with other areas of the organization that have the issues and the budget. Consequently, banks should evaluate whether their partnership models are aligned with their goals and should ensure that any innovation labs are addressing problems that business areas are actually experiencing. It’s also critical that the banks commit to providing the necessary budget to implement the solutions if the proof of value proves successful.

All financial institutions that are looking to partner with FinTech firms need to review the onboarding processes that would be used when deploying the new technology. Procurement and information security processes could be better standardized for most onboarding across all financial institutions. In particular, the onboarding for a proof of concept should be immediate so that both partners can quickly (within a month or so) discover whether there’s a fit.

CORPORATE VENTURE CAPITAL AND FinTech

Assuming there’s a fit, corporate venture capital (CVC) entities should consider buying minority stakes in the most relevant FinTech firms. Doing so would fully acknowledge the importance of the technology and drive internal engagement with the FinTech firm. However, the CVC should be sufficiently removed from the FinTech firm so that the firm can continue to run its external business and potentially sell to the CVC’s competitors. The main benefit that the CVC and its parent bank receive is the shorter time to market of deployment. This gives them a competitive advantage in delivering a product or service. However, that shouldn’t preclude the FinTech firm from continuing to build its business.

Longer term, the ideal scenario should be that a consortium of banks owns a stake in the business. They would all enjoy an overall reduction in cost, due to the long-term efficiencies and returns that the FinTech solution provides. The FinTech company can then distribute the improvements to its other clients, who can equally benefit from the technology.

Weighing the pros and cons of partnership

Of course, any transformation project involves risks, and regulatory requirements ensure that senior managers focus on minimizing those risks. However, not participating in the digitalization of the industry also involves risks. For example, think about what happened to Kodak, which doggedly kept focusing on film long after digital cameras made film cameras obsolete, even though the digital camera was invented by Kodak!

An organization needs to have a clear idea of what it wants to achieve from a digital transformation instead of thinking that more engagement will magically improve its competitiveness somehow.

In principle, a financial institution should be in a stronger position the more it digitizes the processes that enhance the customer experience and provide cost and workflow efficiencies. As we explain earlier in this chapter, it’s often logical for a financial institution to partner with FinTech firms instead of reinventing a product that’s been commercially proven in other organizations. This is particularly true if the product isn’t vital for its competitive advantage and it’s a new technology domain for which the firm’s existing staff doesn’t have the necessary domain expertise.

In the new API economy, if banks ensure their integration processes with their core technology work well, they can determine best-of-breed solutions to solve their problems. However, FinTech solutions aren’t the nirvana for all issues. If the company’s processes are inefficient, automating or digitizing them won’t fix them. Companies should review their day-to-day operations to determine whether current processes are inefficient and in need of modification. Smaller financial services firms may not experience this issue, as their processes may be less complex.

FinTech firms’ solutions tend to be specific to a given problem that multiple organizations experience. If a large firm requires a customized solution to meet multiple needs, they’re probably not going to benefit from a FinTech partnership. FinTech solutions generally aren’t easy to modify, so they may cover fewer functions than an in-house or broader vendor solution may provide. Furthermore, newer FinTech technology may have more difficulty interoperating with older or legacy software than a customized solution would.

For larger financial institutions, building custom software rather than partnering is still the way forward for specific solutions where they need greater customization and where it can provide them with a competitive advantage. In building your own software, it’s also possible to integrate with a wider set of APIs from different partners, because it’s designed to specifically accommodate those requirements. However, such firms need to get sufficient coverage from the solution so that they spread the cost of such proprietary systems over many functions and clients and justify the time, resources, and money spent to build it.

Researching and scouting potential FinTech partners

The following sections provide points on how to research what you need in a partner and where to find suitable candidates.

If a partnership between a large financial institution and a FinTech firm goes well, the institution may consider investing in the company as well as having a commercial agreement for the use of its services. Many examples show where investment banks, or consortia of investment banks, have taken minority stakes in FinTech firms to fully support their engagement, if not buying the FinTech outright, in the same way that the BigTech firms (such as Google and Facebook) have effectively made “acqui-hires” (purchasing companies to recruit and acquire its employees).

NUMERIX: INNOVATIVE APPROACHES

From 2013 to 2017, Numerix was stuck in the $60 million annual revenue range. In fact, in 2016, the company had its first year of down revenue since 2004. The revenue growth trend all but halted, and all employees could see was the reversal trend. In the beginning of 2017, Steve O’Hanlon changed all aspects of the company, and through a series of open meetings, told Numerix employees that stumbling wasn’t a liability but a test and that only the great find a way to get quickly to their feet.

Numerix had stumbled for the first time, but in 2017 it would rise again. The struggle to break the $70 million barrier became just as much a mental hurdle as a business one, especially coming off a down year. Every day of 2017, Steve pushed harder, intensely determined to break through that ceiling. As result of three initiatives he introduced and commanded, Numerix achieved the major revenue milestone of exceeding $70 million in revenue by year end and went on to secure its most significant growth of $80 million.

Steve’s three initiatives that brought about this success were

• Directing the development team in enhancing the company’s solution stack, with the mantra of bringing intelligence to every level, and identifying new and innovative ways clients and partners can apply them. Central to this initiative has been the enhancement of the overall business services focus of the platform, with a greater emphasis on business user workflows and standardizing browser-oriented user interfaces. To put it more simply, the company builds software that customers love.
• Advancing a hands-on and direct approach at integrating the technologies and people into the Numerix culture. This led to the assimilation of TFG Financial Systems into the company (molding different people and skill sets into the Numerix culture), harmoniously bringing together new technologies and new approaches. The success of this effort not only provided Numerix with a unique and market-leading real-time offering but also enabled the company to expand more affirmatively into the hedge fund market, further tapping into a source of company growth and additional revenue.
• Building and introducing a highly competitive managed service offering. Market participants today are continuing to face multiple challenges, such as controlling IT costs, reducing risk, improving operational efficiency, and enabling greater scalability. They are finding that managed services, in contrast to an on-premises system, provide them with the cost efficiency, support, and room they need to achieve their objectives. Agility enabled Numerix to quickly capitalize on this growing trend in 2017 by building and deploying multiple technology solutions through a new managed services platform. This platform offers a range of diverse applications in a microservices format to support valuation, risk, and infrastructure requirements. This was a groundbreaking effort, as was attempting to become a risk company at the fall of Lehman. Today, 30 clients rely on Numerix for managed services, making it the company’s fastest growth area.

Performing initial research

The initial primary research when looking for a FinTech partner should focus on FinTech firms that provide the services that the company needs. They can then investigate potential partners in areas where they believe they don’t have internal expertise or where it makes more sense to share the development cost of the solution with others.

The secondary research should then focus on a deeper analysis, including evaluating the technology stack strength. They must determine whether the solution fully meets the requirements and evaluate how easily it can be integrated into some of the internal core systems. They should also undertake a deeper analysis of the company itself, including the credibility of the founders and their offerings and the business’s financial health. It’s important to feel confident that the company will be around next year — and the next.

This inevitably leads to reviewing the size and success of the firm. Some institutions may be happy to partner with seed stage companies that have developed a specific new-technology solution, such as machine learning. Other institutions will require a minimum level of annual recurring revenue and/or number of employees, both of which can indicate that the company is relatively well established. This is a consideration because well-established companies should be able to scale up to meet procurement requirements.

Potential customers will also want to undertake a detailed information security review on the FinTech. This includes asking them to respond to an in-depth survey on their technology, explaining its capabilities and assessing how secure the application is. Security is an important consideration, given that the customer will be deploying and distributing the application throughout its organization.

Knowing where to look

Many FinTech firms claim to provide a solution to given problems, and not all of them are capable and reputable. Therefore, a general Internet search isn’t the most efficient way of identifying the right companies. Institutions should search the following types of sites and forums to scout for the most relevant and respected firms to partner with:

• Databases: For later stage firms that have raised funds already, look in databases provided by firms such as CrunchBase (www.crunchbase.com) or PitchBook (https://pitchbook.com). These databases tell how much a firm has raised to date and which investors were part of those rounds. A certain bank investing in the firm suggests that the bank will also be using its product.
• Accelerator programs: For earlier stage start-ups, sourcing accelerator programs such as Accenture’s FinTech Innovation Lab (www.fintechinnovationlab.com) or TechStars (www.techstars.com) can be useful. These programs can help you find firms that have already been prevetted as part of the process to get into the program.
• Incubators: Incubator programs can help you find companies that have structured programs to help firms grow within the given vertical/technology being considered.
• Associations: Look at trade associations such as the Investment Association (https://www.theiaengine.com/) or quasi-government-led initiatives such as Innovate Finance (www.innovatefinance.com). These have several FinTech members and run sandboxes or hackathons around given problems. Platforms such as FINTECH Circle (https://fintechcircle.com) also offer custom scouting services for financial players to scout for the most relevant FinTech companies.
• Awards lists: The top FinTech companies in given sectors or regions are highlighted in various awards lists as some of the rising stars in the FinTech world. If a firm appears among the award winners for several years, and across different awards providers, they’ll have shown their worth on multiple occasions. Generally, awards also have an element of vetting, because an industry panel will have nominated and/or voted for the most relevant firms.

These forums can help verify your initial research findings. To be more confident in what you learn about a company, cross-reference between multiple sources to get additional validations.

Companies have several sources to help identify the right partners to provide a given solution. More institutions are running their own challenges or in-residence-type programs that help them identify relevant firms before they have a specific requirement to keep FinTech firms that provide interesting technology on their radar.

Working with partners on evolving solutions

In 2017, mobile applications overtook desktops as the most popular channel for applying for new services within banks. This triggered a ramp-up in technology investments to adapt and compete in the new digital environment. Banks felt the pressure to make financial products as accessible and convenient as products offered by the BigTech customer service giants.

NUMERIX: COMPANY INITIATIVE AND CULTURE

One could easily argue that only an entrepreneurial CEO could enable a company to spin on a dime to react quickly to new market opportunities. Such rapid response requires new business strategies and new ways of thinking around technology innovation and its early adoption. The key for Steve O’Hanlon’s success was to continually and proactively broaden his views on the trends and activities in the capital markets beyond just software applicability. His intention was to focus on broader ways that Numerix could help the entire capital markets space increase trading business, optimize productivity and efficiency, enhance profitability, and meet growing regulatory requirements.

Doing all of this required an in-house enabler. What is that enabler? Adopting a FinTech culture that nurtures and pushes innovation and thinking out of the box. Fostering and maintaining a climate where entrepreneurial thinking, idea generation, risk taking, and the ceaseless quest for innovation are highly encouraged has helped Numerix attract and retain some of the best talent — across several functions — in the industry.

Steve’s goal is to continue disrupting the industry. One way he does this is to continue cementing Numerix’s position as a dynamic financial technology company that provides a next-generation technology platform built on top of the award-winning and industry-leading CrossAsset software. This also helps Numerix in its continued efforts to pivot to a position as a formative leader in the FinTech industry.

One particularly notable development in 2017 was Oracle entering into a collaboration with Numerix to develop and bring to market solutions that enable financial institutions to meet the computational and business requirements needed to comply with FRTB rules (FRTB stands for Fundamental Rules of the Trading Book). As one of the largest and most powerful tech companies in the world, for Oracle to have selected Numerix as its partner of choice to leverage its analytics in its new market risk solution was an absolute honor.

Steve’s entrepreneurial strengths drive Numerix to innovate, enter new markets, and transform old technologies. He has positioned Numerix for sustained success and has proved once again that Numerix isn’t a company that shies away from reinvention but embraces it.

The push to digital in today’s more complex development landscape, where change needs to be made quickly, leads many institutions to a buy and build approach — in other words, a hybrid of both. Where services and offerings are generic and not unique to the bank, they can be sourced from specialist vendors with a proven product. This results in a shorter development cycle and quicker time to market. It also frees up internal resources to concentrate on building functionality unique to the bank’s overall offering. The new API economy and platform environments also allow greater comingling of the two approaches.

Digital transformation can’t be a series of one-off projects. As customer needs and expectations are constantly evolving, solutions need to continuously evolve as well. Sourcing and extending components reduces internal customization and spreads the cost of research and development across external players. APIs and a platform approach make it easier for banks to adapt external modules to their own brands and circumstances and make amendments to future needs less difficult. This removes the tendency to revert to big and costly projects on a regular basis.

Describing the Licensing Models

A software licensing model defines how the product will be used. What rights will the customer have to use the product? How many people or devices may use it simultaneously? How will updates and new versions be received and paid for? What support is included? It’s all in the license.

Enterprise software providers within the financial services industry have traditionally employed a license and maintenance model in which customers bought per-seat or per-user licenses for a particular product release. However, Software as a Service (SaaS; see Chapter 6), a software delivery model where software is centrally hosted and delivered via the cloud, has lately become popular, and much of the industry has moved to a subscription-based model. In fact, Gartner, one of the largest research and advisory companies, foresees that all new vendors, and the vast majority of existing vendors, will provide subscription-based business models, no matter where the software is deployed.

While the subscription model is most popular today, it’s far from the only model available. The following sections explain the various licensing models you may encounter when shopping for FinTech products.

Subscription

A subscription is just what it sounds like: You buy the right to use the product for a fixed time period. Subscription licenses are renewable, usually on an annual basis, and include software support and updates during the coverage period. The license is automatically terminated unless it’s renewed.

The subscription model makes license management simple, as it provides the flexibility to pay only for what you use, adding and scaling back respective licenses in line with demand. In addition, upgrades and new features are released in real time and rolled into the monthly price, ensuring that no compatibility or obsolescence issues occur. A subscription model is affordable and offers a predictable payment schedule, which becomes part of operational expenditure.

Ideally, the subscription model allows for a lower initial cost for the user and a faster approval cycle for the provider. This also allows for short-term licenses, with policies subject to amendment at renewal time, and limits problems with duplicate license counts when machines are decommissioned or upgraded. Both parties benefit from an ongoing client-vendor relationship that includes regular dialogue around usage requirements.

However, in comparison to other license types, the subscription model can increase the administrative burden of license management, because it requires accurate record keeping, auditing, and management during the license life cycle. Moreover, some vendors complicate the pricing process by adding usage requirements on top of the normal per-user (or per-server) license. Such policies may in some cases be appropriate to prevent excessive data usage, particularly where usage racks up greater costs from the software firm’s cloud provider or where the service is specifically data related. However, such policies may create administrative headaches for the client, who must then do extensive auditing and monitoring to avoid racking up excessive extra charges.

Perpetual

Perpetual licenses are nonexpiring licenses to use a given application, where the customer has no obligation to pay for support or update services. Users pay one large upfront fee, which ensures that they “own” the application/software. (They don’t really own it, but they own the right to use it in perpetuity.)

However, in today’s changing environment, although perpetual licenses can in principle be used forever, they tend have a short life cycle as the software becomes obsolete. Consequently, customers must upgrade periodically to ensure compatibility with other applications or supported hardware.

If you continue to use a product that has reached its end of life, you won’t be able to get updates, patches, and hotfixes. Not receiving security-related updates can expose a firm to risks such as viruses, spyware, and other malicious software that can steal or damage data. This is particularly true when customers end up using very old software versions to save money and elect to forego maintenance. They then blame the software provider, whose reputation may suffer from it.

Another issue with perpetual licenses is that customers must pay for the software upfront, which requires a larger initial outlay. As a result, the upfront cost for larger software deployments can be significant and need to be attributed to capital expenditure. Then, if they want support, they must pay more annually. In some agreements, the required annual maintenance fee is as much as 20 percent per year of the upfront purchase price.

Term

A term agreement isn’t bought outright. However, the user does pay a large upfront fee, which is generally based on an annual license rate multiplied by the maturity of the term (generally a five-year term). In almost all instances, the customer is required to take a maintenance agreement, which for a five-year term is generally 20 percent of the one-time initial fee. At the end of the term, the user can either upgrade and pay for another term or stop using the software.

Source code transactions

One of the important questions to ask about a start-up FinTech firm is whether it will still be around in the future. Given that smaller firms are more likely to suffer from short-term cash flow issues, large financial institutions have to consider the risks associated with deploying a start-up’s product in the long term if they have a smaller balance sheet.

To help mitigate such risks, some larger firms require access to the source code of the software product as part of the license agreement. The traditional way of securing access is to put the source code into escrow. In other words, they place the software into custody or trust until a specified condition has been fulfilled, such as the original owner going bankrupt or being bought out by another company. An escrow agreement ensures that if the vendor is unable to manage the product or provide a support service, the purchaser will have access to the code to support its day-to-day operations and ensure it won’t be put at risk.

Having access to source code can also be helpful when purchasing from a larger software provider that requires a long-term maintenance and support license to service, update, or reinstall the software. Because the source code required for most software applications is unique, customers may ask for the required information to be put into escrow. If the software provider is unable to carry out a suitable level of support for the software product, customers can gain access to the code via escrow. Offering software escrow as an option assures that customers will always have access to some level of service on their software purchase.

Code escrow is also quite common where a smaller FinTech firm receives an equity investment from a traditional or corporate venture capital investor. If the firm goes into liquidation, the investor wants to have access to the software information, including the documentation and source code necessary to maintain a level of service on the software. To recoup part of its investment, the investor may consider an asset sale to another provider or the clients themselves to maintain access to the product.

An open source approach

As you discover in Chapter 10, open source software has a source code that anyone can inspect, modify, or enhance because its design and code is publicly accessible. Open source products are built on open exchange, collaboration, rapid prototyping, transparency, and meritocracy, all of which lead to a community-oriented development process.

Many FinTech firms develop proprietary applications on top of open source components. However, the suggestion that open source is free is a misrepresentation, because using open source software obliges firms to recognize the legal context of open source. If a firm fails to comply with the licensing provisions for open source, it can lead to legal proceedings. To mitigate this risk, companies need to understand open source license conditions and initiate an actionable list of best practices. Open source users need to follow the licensing conditions for each package they use, including subcomponents. Moreover, buyers of open source–driven FinTech applications need to be aware of all uses so that they can assume responsibilities for such use, subject to license conditions.

The bulk of open source licenses are protected by a few agreements, of which there are only two main license groups: copyleft, which obliges developers to ensure that any source code or documentation is obtainable, and permissive, which requires minimal provisions, such as author acknowledgment.

Companies must have a license and compliance policy that covers both categories. At a minimum, firms are required to

• Maintain documentation for the licensing conditions relating to the open source software being used, incorporating subcomponents and dependencies.
• Have a strategy for compliance that differentiates between licenses that have simple or complex requirements, such as source code delivery.

Every open source software license has notice obligations. When distributing a product that incorporates open source, those obligations may require developers to include a simple copyright notice or the complete text of the license that regulates the software.

Copyleft licenses regulate how developers can combine the open source software with privately operated software. The term copyleft is intended to both reference the well-known term copyright and to differ from it. Copyright is a law that restricts the right to use, modify, and share creative works without the permission of the copyright holder. In contrast, under a copyleft license, the author makes a claim on the copyright of the work and issues a statement that other people have the right to use, modify, and share the work as long as the obligation’s reciprocity is maintained. In short, if authors are using a component with this kind of open source license, then they too must make their code open for use by others.

NUMERIX: STANDING ALONE

Numerix’s first acquisition took place in 2017. We detail this event and its implications in Chapter 15. For now, suffice it to say that after a tremendous amount of research and due diligence, Numerix entered into a hugely strategic acquisition of TFG Financial Systems, whose unparalleled real-time technology leapfrogged Numerix over its competitors. This acquisition not only advanced Numerix into the micro hedge fund sales channel but also advanced it into a SaaS offering and into new disruptive real-time technologies.

Because this space is crowded, Numerix focused on its key differentiator, which continues to be its unrivaled analytics. In 2019, it was recognized as change advocates by creating and driving thought leadership activities that focused on innovation and disruption technology that point out legacy inefficiencies.

Numerix strategy continues by

• Expanding the applicability and diversity of its Oneview solution stack and deployment strategies
• Leveraging its unique cross-asset real-time risk and portfolio management solution to capture significant market share in the buy-side market, with a focus on global macro hedge funds
• Growing its strategic network of trusted partners as part of an increasing effort to sell more of its capabilities to more markets

Numerix’s culture, technological advancement, and unending desire to be the best software company in the world has paved a path where few can compete.

Component Lifecycle Management (CLM) is a process that allows developers to use cooperative kits, information, and control at each phase of the application development, thereby addressing licensing risk control for a module-based approach. These tools enable companies to choose applicable licensed modules during design and elaboration by

• Recognizing and controlling component licensing through the build stage to identify problems quickly and prevent expensive reworks
• Scanning current applications to recognize licenses and requirements to review dependencies with respect to corporate compliance policies