Silicon Valley companies move fast and have essentially learned how to rebuild a car while going 100 miles per hour. Unfortunately, many of the practices that enable this rapid speed violate the core assumptions in industries like financial services. Facebook’s motto: “Move fast, break things” doesn’t really work in a heavily regulated environment that serves as the backbone to our economy.
For example, some of the databases used to serve up your social media or email or other information use a principle called “eventual consistency,” the idea that a database may at times show different information to different users but will eventually be made the same for everyone. This is fine for a free service conveying information about the latest statements of the Doge, but not fine for a bank account.
But at the Apigee FinTech API Summit at the NASDAQ Marketsite in Times Square on February 10, all the presenters agreed on one thing: Both established financial services players and new FinTech unicorns must find a way to move at Silicon Valley speeds while maintaining the financial services perfection demanded by customers, regulators, and shareholders.
The theme of the conference was that APIs provide a way for the financial services industry to move fast, while not loosening up on critical elements like security. “APIs are one of the most important tools in digital business design,” said Peter Wannemacher, an analyst at Forrester who specializes in digital strategy and the financial services industry. “Financial services providers have been relatively slow to recognize and act on APIs as an opportunity to transform their businesses and, ultimately, better win, serve, and retain customers.”
I have been preaching the gospel of APIs for a while through a book that I co-authored with Dan Jacobson and Greg Brail, “APIs: A Strategy Guide.” While the understanding of the central role of APIs in promoting innovation and rapid but stable evolution has been gospel in Silicon Valley, it has only taken hold selectively in the rest of the business world. But the world of financial services seems like it is ready for a variety of reasons.
To this last point, for example, when Apple came calling to First Data, one of the major payment technology companies, about implementing Apple Pay, the project was moving at Silicon Valley speed. First Data didn’t really have the choice to bow out of the project or out of Android Pay, for that matter, which was also implemented at a rapid pace. It was a choice of go fast or die.
In conversations at the FinTech API Summit, it became clear that the leaders in the financial services industry are making new organizational models and innovative strategies work with the help of the agility and pace layering enabled by clever use of API infrastructure.
“We are not just making a transition from a technology standpoint; our goal is to serve consumers better where they are interacting, and APIs have been crucial to our ability to support new services like Apple Pay and Android Pay, which keep us growing,” said Patrick Howard, Director Product Management, First Data.
In a sense, the massive divergence between the need for security and reliability in the foundational applications in financial services and the breakneck pace of product development in the space shows in a crystal clear way the role that APIs play in accelerating digital transformations.
Case for Speed and Agility
In his presentation, Wannemacher made the case for both speed and agility and predicted that the financial services industry will be reshaped in the following ways.
A growing mobile mindset will put pressure on financial services to become better at recognizing “mobile moments,” the instances when someone pulls out a device to achieve an outcome. At these times, a firm must assemble all that is known about the customer’s context in order to help. Wannemacher points to the Discover app that allows customers to freeze their cards if they suspect they are lost or stolen as a perfect example of a mobile moment.
The mobile mindset is driving up consumer expectations of support for cross-channel banking experiences in which a customer or prospect moves from one touchpoint to another when completing an objective will surge.
An increase in the demand for shared finances coming from elderly parents, blended families, dependent children, multi-generation households, and pooled financial goals will break many assumptions now embedded in financial products and services.
Wannemacher said that these pressures will lead senior executives to focus far more on backend initiatives powered by APIs. Executives will figure out that they need to make this happen, just as Jeff Bezos did years ago. In addition, the mobile moments will need fresh data and up to the minute context, which will increase the demand for real-time access to data and services.
Where will all this lead? Wannemacher’s final prediction is that APIs will take center stage because of their crucial role in addressing the needs of financial services companies. APIs will become important because “you just can’t do it alone,” he said.
At the same time, Wannemacher issued a warning about focusing too much on APIs without a larger business vision. “APIs are not a strategy unto themselves,” he said. “They are an enabler of a strategy that should be informed by mapping the customer journey, having a vision for an ecosystem, and an understanding of how to set priorities as conditions change.”
Two-Speed IT: Safe at Many Velocities
The next speaker, Ed Anuff, VP of Product Strategy at Apigee, explained how modern IT organizations are adapting to the kinds of pressures Wannemacher outlined in the financial services industry.
The historical development of the financial services industry has created a landscape that is ripe for applying APIs in a variety of ways. The financial services industry has gone through many cycles of aggregation and distribution in the past decades. The idea of the one-stop shop had become supplanted by the notion of the focused boutique and vice versa. In addition, mergers and acquisitions have occurred at breathtaking speed, as elephant-sized firms have married each other and adopted smaller companies to fill in needs in their offerings.
In such combinations, the purchase is always the easy part. That can take place in a few months. Merging the operational systems, especially those used for high volume financial transactions, is rarely accomplished quickly and takes years. But, as Wannemacher’s analysis shows, it doesn’t matter whether you are presenting yourself to the customer as a one-stop shop or a boutique:
APIs are so important to the financial services industry because they enable the unification of information to occur without having to merge the operational systems. They allow tailoring of data and IT to meet the specific needs of applications or process steps.
In his analysis, Anuff picked up on the idea of “bimodal IT” made popular by Gartner (which Apigee calls, “Two-speed IT”), which has been explored by a variety of other thinkers. The idea of the bimodal or two-speed approach is that IT must be able to provide two types of services:
In a sense, the victory of Silicon Valley has been to create highly scalable systems of engagement that can be evolved as fast as possible but also maintain many properties of systems of record.
Anuff pointed out the intellectual roots of the bimodal approach in the pace layering idea invented by Stewart Brand to describe how buildings and cities learn and evolve. And just as Brand showed how in the world of architecture many layers evolve at different rates, Anuff pointed out that many different analysts have shown that bimodal IT actually can be implemented not with just mode one and mode two as Gartner describes it, but with many different modes that move at different rates of change based on the mission they are seeking to fulfill and the constraints they operate under.
The key is that the developers of the services, who will be creating the mobile apps, the cross-channel experiences, and so on, will be able to create APIs that simplify development, increase speed, and centralize any complexity inside the API layer. These simplifying APIs are called experienced-based APIs because they are designed to support a specific application or user experience. Experienced-based APIs are built on top of resource-based APIs which exist to provide access to core services. See “How a Netflix Tech Innovation Can Unleash Creativity In Your Business,” for an explanation of the structure of the Nicobar project, an open source project created by Daniel Jacobson’s team at Netflix. Jacobson, VP of Edge Engineering for Netflix, created the project to use experience- and resource-based APIs to reconcile the two modes of IT that were in use at Netflix.
How APIs Deliver Digital Transformation to Financial Service Industry
I ran across many examples of companies at the Apigee FinTech summit that illustrate how APIs are playing the role outlined in the analysis presented so far.
Tradier Brokerage is creating an API layer that provides the ability to create stock brokerage applications. Tradier’s product is essentially a set of resource-based APIs with a few sets of experience-based APIs created to support specific types of applications. By using Tradier’s APIs, a company that has a financial relationship with a customer can easily add the ability to explore stock trading activities and execute trades. (Xignite performs a similar function for financial data sources.)
Dan Raju, Tradier’s CEO, pointed out to me how the suite of APIs offered by Tradier are both resource-based APIs that provide access to the core platform, and also experienced-based APIs focused on supporting specific types of applications.
First Data is one of the leading payment processing firms in the world. First Data’s traditional products are focused on allowing merchants and financial institutions to process payments in as many ways as possible. First Data is no stranger to resource-based APIs and services. In recent years First Data has also expanded its offerings to include comprehensive solutions targeted at small and medium sized businesses. As mentioned earlier, the challenge of implementing Apple Pay and Android Pay at Silicon Valley speed moved First Data toward increasing use of API technology and implementation of practices that resemble the experience-based API pattern. First Data released a public version of experience-based APIs for development of Apple Pay applications called Payeezy.com, the goal of which is to enable software developers to quickly and easily build apps that support the new single-touch mobile payment capabilities for Apple Pay.
One key message of the conference was that APIs are fast-becoming a part of product offerings for financial services companies, not just a technical capability like a firewall. To support resource-based and experience-based APIs, which may be used in public, or private, or both, an organizations must, at a minimum, have basic API management proxying capabilities to secure incoming calls and route them to the correct endpoint. But to deliver a product offering, one that meets the expectations for developers accustomed to working with companies like Google, Amazon, and Facebook, most financial services companies will require more robust API management (not just an API gateway) that addresses both API exposure and consumption, as well as capabilities such as data transformation, caching and mediation, a portal for testing and documenting APIs, analytics, and monetization of APIs.
The challenge for companies who are getting started and those further down the road is to think of the API as a unit of digital business design, not just as a programming construct. In my next article I will explain the difference between these two perspectives and the technology needed to support APIs as a unit of digital business design.
This article was written by Dan Woods from Forbes.
This reprint is supplied by BNY Mellon under license from NewsCred, Inc.
BNY Mellon is the corporate brand of The Bank of New York Mellon Corporation and may be used as a generic term to reference the corporation as a whole and/or its various subsidiaries generally. This material does not constitute a recommendation by BNY Mellon of any kind. The information herein is not intended to provide tax, legal, investment, accounting, financial or other professional advice on any matter, and should not be used or relied upon as such. The views expressed within this material are those of the contributors and not necessarily those of BNY Mellon. BNY Mellon has not independently verified the information contained in this material and makes no representation as to the accuracy, completeness, timeliness, merchantability or fitness for a specific purpose of the information provided in this material. BNY Mellon assumes no direct or consequential liability for any errors in or reliance upon this material.