Share

SalesForce’s Acquisition of MuleSoft Will Enable API-Based Competition in Banking

The sales software giant Salesforce has agreed to pay $6.5 billion for business software company MuleSoft. Not familiar with MuleSoft? The company's technology is used by customers to link business apps, databases, and corporate IT infrastructure into a unified system. According to Fortune, "one way Salesforce plans to use MuleSoft’s technology is to embed it in the Salesforce Integration Cloud, a service that lets customers more easily access corporate data wherever it may be stored."

This is a big deal. Some of Cornerstone's clients are already clients--and big fans--of MuleSoft.

Cornerstone Managing Director Brad Smith thinks "Salesforce now will have much easier integration into just about any legacy system, payment system, database or device."

Building on that thought, Sam Kilmer, Cornerstone Advisors Senior Director commented, "Front office rebuilds have the intensity of a core system conversion in the back-office--banks and credit unions have had legacy websites, electronic content, and online origination systems for years."

And according to Cornerstone Director Ryan Myers, "This deal should not only lower the [SalesForce] implementation cost barrier, but encourages the use of APIs through an enterprise service bus."

My take: APIs are the big story here.

Beyond Integration to Business Process--and Model--Change

Phil Wainewright, co-founder of diginomica wrote about a conversation he had with MuleSoft CEO Ross Mason:

"We were talking about the new PSD2 open banking regulation in the EU, which requires banks to open up interfaces so that third-party payment processors and application providers can access account information and transactions. Banks could have treated PSD2 as a compliance exercise and just done the bare minimum, using manual processes or workarounds rather than a true API approach. But Mason believes most are seeing it as an opportunity to modernize infrastructure that’s long overdue for a refresh—although it does require a rethink about processes that often haven’t been touched for a long time."

Wainewright discusses the impact of a three-tier API model:

"Adopting a three-tier API model allows an IT team to gradually package up resources, functions and interactions as self-service components that the business can harness as needed. According to Mason, 'Flexible composability is the goal. The ability to compose and recompose something based on any kind of new input or new application that sits on top should be like the Holy Grail for many enterprises.' But there’s another dimension that’s much more significant for any enterprise looking to harness modern connected digital technology. This is the emergence of a new integration trend at the workflow automation layer. Once there’s an API-centric infrastructure in place, connection moves up into the experience layer, where it joins up workflow to deliver results. It’s a more flexible reinvention of what used to be called business process management (BPM)."

                             Source: https://www.slideshare.net/HarishKumar544/three-layer-api-design-architecture

The Banking Hierarchy of Needs

Wainewright's perspective on business process change is spot on. Heaven knows, plenty of financial institutions fail at changing--let alone transforming--processes when adding/replacing systems or undergoing core conversions.

From a more business (i.e., less technical) perspective, there is a 3-tier construct parallel to the API architecture. Think of it as the hierarchy of needs in banking:

  1. Security. The most basic need is security–protocols and mechanisms to ensure that account access and transaction execution is secured and protected.
  2. Movement. The next level of need is money movement–the ability to move money between accounts and/or participants. This encompasses the movement of money between businesses (B2B), consumers to business (dyslexically referred to as B2C), person to person (misnamed P2P), and between businesses/consumers and government entities (G2C?). The payment networks and ACH are examples of entities that create money movement capabilities.
  3. Performance. The highest level of need is where value is created, derived, and optimized. The performance level provides capabilities that impact: a) the speed of money movement; b) the cost of providing capabilities; and (perhaps most importantly) c) the return provided to the customer. Delivering capabilities that provide performance (or value) can–and almost always do–rely on security-level and movement-level capabilities.

A recent Innotribe competition at SIBOS provides an illustration of the hierarchy of needs. There were seven finalists, six of whom fit neatly into the needs hierarchy:

  • Security. From a security perspective, Sixscape replaces insecure username/password authentication with certificate-based authentication, while Ensygnia’s technology improves identity verification.
  • Movement. From a movement perspective, Epiphyte converts currency to bitcoins, moves the coins, then cashes them out on the other end in the local tender. TransferGo enables international money transfer without actually transferring the sender’s money internationally.
  • Performance. From a performance perspective, Stockspot provides robo-advice to investors, while Lending Robot helps investors looking for lending opportunities on P2P lending platforms like Lending Club.

The 7th finalist--and winner--of that Innotribe competition was Standard Treasury, a provider of APIs. By creating a set of APIs for industry participants, Standard Treasury makes it possible for a firm to more efficiently create a full stack (i.e., across the hierarchy of needs) solution.

But there are plenty of full stack banks out there already. Why do we need any more? Because a full stack fintech startup could, would, and should compile a set of capabilities across the hierarchy of needs that is open (versus proprietary) and more truly best-of-breed than the legacy full stack banks offer.

Competing on APIs

The ability for a full stack fintech startup to succeed isn’t dependent on building out new security or new performance features (like portfolio optimization, PFM, automated savings, etc.). It’s dependent on the ability to define service or value bundles for specific segments of the population, and then tying the needed capabilities together into the service or value bundle.

In other words, APIs become central to the competitive dynamics of the industry.

Here’s why: In a banking environment that offers a wide range of capabilities to do things like find deals on intended purchases, automate savings, provide advice on investment opportunities, etc., full stack providers must rapidly assess partial stack providers’ offerings, integrate them, and deploy them to their customer base.

If this process takes nine to 12 months (or, heaven forbid, longer) from a technology integration perspective, you’re dead in the water.

If this process requires significant time and resources to negotiate legal matters, revenue sharing, pricing, etc., you’re dead in the water.

API-based competition is about speed, agility, and personalization. By the way, for all the talk about personalization in banking, nothing we have today comes close to what’s possible in an environment with a robust set of partial stack fintech providers and smart full stack banks.

Bottom line: So, after all that, why is the MuleSoft acquisition is so important to both SalesForce and to banks and credit unions? Because it enables not just integration and process change, but business model change. It's a facilitator to a more open banking, or platform, model that has largely been out of reach for most banks and credit unions below the $100b asset level.

p.s. Wanna find out how far along your API capabilities are? Compute your score on this test from Cloud Elements.

Ron Shevlin
Director of Research
Cornerstone Advisors

Share