0% found this document useful (0 votes)
125 views46 pages

Hype Cycle For Open Banking 251123

This document provides an analysis of open banking strategies and technologies through a hype cycle. It discusses how open banking shifts power from banks to individuals by enabling third parties to build products and services through public APIs, open source, hackathons, and app stores. The hype cycle evaluates emerging open banking technologies on the basis of their potential benefit and maturity, finding technologies like community source banking systems, OpenID Connect, and business models to be on the rise. Public web APIs, banking apps, and micrometered revenue models are sliding into the trough of inflated expectations.

Uploaded by

Fernando Lima
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
125 views46 pages

Hype Cycle For Open Banking 251123

This document provides an analysis of open banking strategies and technologies through a hype cycle. It discusses how open banking shifts power from banks to individuals by enabling third parties to build products and services through public APIs, open source, hackathons, and app stores. The hype cycle evaluates emerging open banking technologies on the basis of their potential benefit and maturity, finding technologies like community source banking systems, OpenID Connect, and business models to be on the rise. Public web APIs, banking apps, and micrometered revenue models are sliding into the trough of inflated expectations.

Uploaded by

Fernando Lima
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 46

This research note is restricted to the personal use of [email protected].

br

G00251123

Hype Cycle for Open Banking, 2013


Published: 23 July 2013

Analyst(s): Kristin R. Moyer

Open banking is the provision of services in the context of users through


API platforms, app stores and apps. Use this new Hype Cycle to identify
ways to deliver services that revolve around the digital lives of customers.

Table of Contents

Analysis.................................................................................................................................................. 2
What You Need to Know.................................................................................................................. 2
The Hype Cycle................................................................................................................................ 4
Overhyped and Undervalued Technologies and Strategies......................................................... 5
Why This Hype Cycle Is Front-Loaded........................................................................................ 6
Multigeography, Multicontext Analysis........................................................................................ 6
The Priority Matrix.............................................................................................................................8
On the Rise...................................................................................................................................... 9
Community Source Banking Systems.........................................................................................9
OpenID Connect.......................................................................................................................10
Business Models...................................................................................................................... 11
Bank-Branded App Stores........................................................................................................13
Integration PaaS....................................................................................................................... 15
Open Bank Project................................................................................................................... 17
Business Strategy.....................................................................................................................18
Vendor Readiness.................................................................................................................... 20
API Marketplaces..................................................................................................................... 22
Open-Source Banking Systems................................................................................................24
OAuth.......................................................................................................................................25
Application PaaS (aPaaS)......................................................................................................... 27
Cloud API Management............................................................................................................28
Crowdsourcing......................................................................................................................... 30
Apptrepreneurs........................................................................................................................ 32

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

Application Services Governance..............................................................................................34


At the Peak.....................................................................................................................................36
Hackathons.............................................................................................................................. 36
Sliding Into the Trough....................................................................................................................37
Public Web APIs....................................................................................................................... 37
Banking Apps........................................................................................................................... 39
Micrometered Revenue Models................................................................................................ 41
Appendixes.................................................................................................................................... 43
Hype Cycle Phases, Benefit Ratings and Maturity Levels.......................................................... 43
Recommended Reading.......................................................................................................................45

List of Tables

Table 1. Hype Cycle Phases.................................................................................................................43


Table 2. Benefit Ratings........................................................................................................................44
Table 3. Maturity Levels........................................................................................................................44

List of Figures

Figure 1. Growth of Financial Services Public Web APIs......................................................................... 4


Figure 2. Hype Cycle for Open Banking, 2013........................................................................................ 7
Figure 3. Priority Matrix for Open Banking, 2013.....................................................................................8

Analysis
(This document was revised on 24 July 2013. The document you are viewing is the corrected
version. For more information, see the Corrections page on gartner.com.)

What You Need to Know


The convergence of mobile, social, cloud and information is driving a radical shift in power away
from the enterprise and toward the individual (see "The Nexus of Forces Changes Everything:
Gartner Symposium/ITxpo 2012 Keynote"). Individuals (retail customers, commercial customers or
other external parties to the bank) increasingly expect products and services to be delivered in a
way that meets their specific needs, and in a way that revolves around their digital lives — in other
words, digital banking. In this environment, IT spending is moving rapidly outside of IT (see
"Gartner's Top Predictions for IT Organizations and Users, 2012 and Beyond: Control Slips Away").
Quite often, this is because IT is not able to respond quickly enough (or sometimes not at all) to new
market opportunities, or is limited by bandwidth constraints. Traditional applications are

Page 2 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

foundational to this problem because they are becoming increasingly costly and time-consuming to
change and maintain (see "Banking on APIs and Apps, Not Applications"). CIOs need new
strategies and technologies to increase revenue, reduce costs and respond to new market
opportunities more quickly (see "Agenda Overview for Banking and Investment Services, 2013").

Open banking provides CIOs with a new approach. Open banking includes strategies and
technologies that shift power from the bank to the individual and other external parties. The
individual may be a retail/commercial/investment services banking customer, third-party partner,
third-party developer or even another bank. Power is shifted to the individual through public Web
APIs, open source, developer communities, hackathons, app stores, and other strategies and
technologies that let others (like customers, partners, third-party developers — even employees)
build the products and services that they want and need. Open banking provides CIOs with the
ability to:

■ Enable mobility and innovation — For example, creating a third-party developer community that
can access public Web APIs to build mobile apps, and using a bank-branded app store to
discover/download apps and share ideas.
■ Increase product and service accessibility — For example, providing public Web APIs that
make products and pricing available for comparison and consumption through social media
sites, online stores and other digital media. Also, providing public Web APIs that let partners,
customers and third parties embed banking services into their products (for example, letting a
mobile commerce provider customize the way a payment occurs for its customers, with the
bank processing the transaction).
■ Create new business models — For example, providing banking services as a platform that lets
partners, customers and third parties create and market their own services (for example,
creating and offering a digital identity management service, peer-to-peer lending via a network
of friends, etc.).

The role of IT changes dramatically with the adoption of open banking. Applications are no longer a
barrier to the quick pursuit of new revenue opportunities. IT becomes less focused on developing
and deploying the applications and apps that are required to run, grow and transform the business.
IT becomes more focused on enabling others to execute these tasks by creating and nurturing a
third-party developer community and by enabling developer onboarding, API exposure, API testing,
software development kits (SDKs), security, regulatory compliance, interactive API documentation,
sample code, and review and testing of what other developers build (for security and regulatory
compliance). This will require substantial changes to IT strategy, governance, as well as skills
retooling.

Open banking is not without risk, especially in the manner that many banks are approaching it
today. The need for rapid time to market has often resulted in the lack of a clear, documented
strategic direction and business model for monetizing open banking. App testing is often insufficient
to ensure adequate regulatory compliance, security and impact analysis on the bank's overall
system performance. App hosting and support by developers also carries risk, especially as usage
increases. Intellectual property rights have yet to be adequately addressed. Intellectual property
issues, already a thorny issue when it comes to banking software, become extremely complex in a

Gartner, Inc. | G00251123 Page 3 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

more open environment. Many open banking initiatives are also additive to already highly complex
bank architecture, infrastructure and operations, and are, therefore, increasing IT mass. This is just
one reason why innovating bank operations needs to continue to be a top priority (see "Hype Cycle
for Bank Operations Innovation, 2013").

If these risks are addressed, open banking enables CIOs to take new approaches to increasing
revenue, reducing costs and responding to new market opportunities more quickly. This Hype Cycle
examines the strategies and technologies available to execute open banking. While some of these
strategies and technologies (like open source) have been in existence for a long time already, many
(such as hackathons and bank-branded app stores) are relatively new and, therefore, more
expensive and complicated to implement than will be the case within two to three years as they
become more mature and proven.

The Hype Cycle


The deployment of open banking strategies and technologies has accelerated dramatically. For
example, the number of new financial services public Web APIs (an enabler of open banking)
deployed in 2012 increased greater than 250% growth year over year (see Figure 1).

Figure 1. Growth of Financial Services Public Web APIs

Number of New Public Web APIs


200

180

160

140

120

100

80

60

40

20

0
2005 2006 2007 2008 2009 2010 2011 2012

Source: ProgrammableWeb

Open banking supports digital banking strategies by enabling transparency, participation,


collaboration, empowerment and needs-based financial services that revolve around a customer's
digital life. It is deployed and supported through a collection of strategies (like hackathons) and
technologies (such as SDKs). Early deployments of open banking have been primarily focused on

Page 4 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

retail banking (especially in the area of payments and data) and investment services, and much of
the focus of this Hype Cycle is centered there. However, Gartner has predicted that, by 2016, 50%
of B2B collaboration will take place through Web APIs (see "Predicts 2013: Application
Development"). We expect to see more usage of API platforms in areas like commercial transaction
banking (to a private network between one group of businesses and another group of businesses)
within the next one to two years.

CIOs and business leaders at individual banks need to develop their own approaches to open
banking based on their banks' unique business strategies, differentiators, customer needs, market
reach, architectures, infrastructures, and IT skills and availability. For example, an open banking
initiative focused on expanding addressable market share does not necessarily need to create and
nurture a developer community. Rather, this initiative may most benefit from creating a business
development strategy that relies on pursuing social commerce, digital content, mobile gaming and
other emerging players, and providing these new customers with APIs to let them customize which
banking services they use and how they use them. Contrastingly, an open banking initiative that is
focused on enabling mobility and innovation might require creating a third-party developer
community. However, even in this case, public Web APIs are not the only technology that can
support open innovation — open-source could also be an alternative.

The focus of this Hype Cycle is the provision of services (in the context of users) through API
platforms, app stores and apps, and is targeted specifically to CIOs; however it is also relevant for
other CxOs, IT leaders, and digital marketing and line-of-business executives. We have seen open
banking adopted in nearly all geographies in the world (less so in Africa to date), with the greatest
levels of activity in Europe and North America. "Hype Cycle for Bank Operations Innovation, 2013"
includes strategies, practices, and technologies to facilitate operations innovation that enables
intelligent, open banking systems.

Overhyped and Undervalued Technologies and Strategies


One of the ways CIOs can use Gartner's Hype Cycle is to identify technologies that are overhyped,
and, therefore, a potential risk. A new financial institution or vendor is deploying open banking
strategies and technologies nearly weekly, which is leading to some overhyped areas within this
emerging area. Some examples are:

■ Public Web APIs — Avoid the temptation to launch a public Web API as a "me too" response;
rather, ensure it is aligned to an open banking strategy (see "Maverick* Research: Banking on
APIs and Apps, Not Applications" and "Extend the Enterprise With Public Web APIs").
■ Banking apps — Narrow the focus of new mobile apps; adapt software development practices
to ensure better user design and less bloated apps (see "Banking Apps Need to Be Awesome,"
"App Explosion: Lessons From the Top 20 Banks," "Software Development for Banking Apps
Needs a Diet" and "A Decision Framework for Deploying Banking Apps").
■ Hackathons — While hackathons garner media attention today, developers will become easily
fatigued as the number of hackathons increases without clear benefit and financial reward for
the community.

Gartner, Inc. | G00251123 Page 5 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

CIOs should be cautious in their approaches to these overhyped technologies and avoid rushing to
market with underdeveloped open banking strategies. Undervalued technologies deserve similar
attention. Perhaps due to the slow-moving nature of some technologies, banks have a tendency to
disregard long-term value and pay too much attention to other technologies with only short-term
value. The recent open banking programs started at some banks are exposing the lack of financial
return associated with an "if we build it they will come" approach.

These emerging strategy technologies deserve more attention to ensure open banking strategies
are more than just a way to show that your bank is innovative, but actually improve net profits:

■ Business strategy — Many banks are launching public Web APIs and other open banking
technologies before creating an open banking strategy. This could result in wasted investment
and failure to achieve a return on investment, let alone improve net profits.
■ Business model — Many banks are launching public Web APIs without a clear business model.
As with strategic direction, this could result in a negative impact on net profits.
■ Micrometered revenue models — Many banks are launching public Web APIs without a clear
monetization strategy.
■ Application services governance — This should be deployed prior to launching public Web
APIs, rather than as an afterthought.

Why This Hype Cycle Is Front-Loaded


Apart from these technology standouts, this Hype Cycle (which is a new addition to Gartner's
lineup) is rather front-loaded, with the vast majority of emerging technologies positioned between
the Technology Trigger and just past the Peak of Inflated Expectations (see Figure 2). This is
because open banking is an emerging trend in banking and investment services, and many of the
technologies in this Hype Cycle are, therefore, relatively new. Open banking implementations in the
2013 time frame will, therefore, be somewhat more expensive and complicated for CIOs to
implement, and, consequently, more risky. However, these strategies and technologies will rapidly
become more mature, with many of them becoming mainstream in two to five years.

Multigeography, Multicontext Analysis


It is important to remember that this is a multigeography, multicontext analysis. As such, individual
use cases are likely to result in changes in speed to maturity, as well as changes in position on the
Hype Cycle. Client inquiry can be used as a way of identifying such reconfiguration.

Page 6 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

Figure 2. Hype Cycle for Open Banking, 2013

expectations
Hackathons

Application Services Governance

Apptrepreneurs
Crowdsourcing
Cloud API Management
Application PaaS (aPaaS)
OAuth

Open-Source Banking Systems


API Marketplaces
Public Web APIs

Vendor Readiness

Open Bank Project


Business Strategy
Integration PaaS Micrometered Revenue Models
Bank-Branded App Stores
Banking Apps
Business Models
OpenID Connect
Community Source Banking Systems
As of July 2013

Innovation Peak of
Trough of Plateau of
Trigger Inflated Slope of Enlightenment
Disillusionment Productivity
Expectations
time
Plateau will be reached in:
obsolete
less than 2 years 2 to 5 years 5 to 10 years more than 10 years before plateau

Source: Gartner (July 2013)

Gartner, Inc. | G00251123 Page 7 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

The Priority Matrix


The technologies included in this Hype Cycle offer different levels of benefits over different time
frames. The open banking Priority Matrix for 2013 (see Figure 3) defines these additional dimensions
that identify the value and impact to the business, as well as the time span until the technologies
are commonly adopted.

Banking apps will have a transformational impact on the ability of CIOs to enable banking to revolve
around the digital life, especially as the focus of apps becomes more narrow and context-aware.
Apptrepreneurs (third-party developers) will enable CIOs to meet high demand for banking apps,
particularly the long tail of app development requirements. Public Web APIs will enable CIOs to
deliver mobility and innovation, increased product visibility, and accessibility and new business
models. Bank-branded app stores will enable CIOs to crowdsource new ideas and the discovery of
apps built by third-party developers, as well as bank-branded apps (reducing user anxiety about
fraudulent apps).

Figure 3. Priority Matrix for Open Banking, 2013

benefit years to mainstream adoption

less than 2 years 2 to 5 years 5 to 10 years more than 10 years

transformational Banking Apps Apptrepreneurs


Bank-Branded App
Stores
Public Web APIs

high Application Services Application PaaS (aPaaS)


Governance
Business Models
Business Strategy
Cloud API Management
Crowdsourcing
Micrometered Revenue
Models

moderate API Marketplaces Integration PaaS Community Source


Banking Systems
OAuth Open Bank Project
Open-Source Banking
OpenID Connect Systems
Vendor Readiness

low Hackathons

As of July 2013

Source: Gartner (July 2013)

Page 8 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

On the Rise

Community Source Banking Systems


Analysis By: Kristin R. Moyer

Definition: Community source banking systems are banking-specific applications (like core
banking), components (like relationship pricing) or infrastructure (like a user interface widget
container) that are developed by banks or commercial companies that sign an agreement and
provide financial and/or human resources and get exclusivity in influencing the development of the
banking system during an initial closed stage (based on definition provided by OSS Watch,
"Community Source vs. Open Source," Gabriel Hanganu, 13 March 2012).

Position and Adoption Speed Justification: Community source banking systems are different
from open-source banking systems. With open-source, software code is made available for free to
everyone for inspection and modification. With community source, a consortium of companies
contribute resources (financial and human) during an initial closed stage. After the initial closed
stage, code is then made available, as is the case with open source. Both community source
banking systems and open-source banking systems are at an early stage of development. The
Lodestone Foundation is an example of a community source banking system. A few examples for
the plans for this community source initiative include reference data platforms, market data
platforms, order management systems, algorithm containers, trade repositories, grids for risk and
pricing. Some of those services could even be offered as a shared infrastructure on the cloud.

There is less incentive for large banks to participate in community source banking systems because
they often consider applications and components a competitive differentiator, though community
source at an infrastructure layer and also for commoditized functions (like public reference data
access, cleansing and validation) may be more appealing. Operational risk is also a concern, since
banks have less control over community source banking systems. Software vendors may be
somewhat more inclined to participate in community source than open source, given the ability to
influence development during the initial closed stage, establish expertise and reputation with the
system, and therefore set themselves up for revenue streams in areas like maintenance and
support. However, the focus on short-term returns will preclude many vendors from deploying
substantial resources to community source. These factors are likely to delay growth in open-source
banking for more than 10 years, and technologies like public Web APIs may make this obsolete
before reaching the Plateau of Productivity.

User Advice:

■ Monitor the emergence of community source banking systems and consider participation if the
objective is to reduce standard application, component and infrastructure efforts, and extend
application development bandwidth for bank applications, as opposed to develop apps for
customers.
■ Evaluate opportunities to leverage community source components like UI widgets for spot
liquidity, orders or trade repositories as they become available that may enable faster time to

Gartner, Inc. | G00251123 Page 9 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

market and lower costs than are involved in evaluating, selecting and implementing a packaged
application that includes more functionality than needed.
■ When facing the replacement or retirement of an application, identify community source
banking system alternatives as part of the RFI process.

Business Impact: Community source banking systems enable CIOs to influence the development
of the banking system during an initial closed stage with multiple other banks and vendors involved.
After the closed period, they enable CIOs to have direct customization control over applications,
components and infrastructure, as well as leverage the power of open innovation — as is the case
with open source. In theory, community source banking systems could reduce the total cost of
ownership of applications, components and infrastructure because they are available for free.
However, because vendors will often be involved during the initial closed stage, they may set up the
community source banking system to operate best under traditional maintenance-and-support-type
contracts.

Benefit Rating: Moderate

Market Penetration: Less than 1% of target audience

Maturity: Embryonic

Sample Vendors: The Lodestone Foundation

OpenID Connect
Analysis By: Kristin R. Moyer; Gregg Kreizman

Definition: OpenID Connect is a suite of lightweight specifications that provides a framework for
identity interactions via RESTful APIs. The simplest deployment of OpenID Connect allows for
clients of all types — including browser-based, mobile and JavaScript clients — to request and
receive information about identities and currently authenticated sessions. The specification suite is
extensible, allowing participants the option to support encryption of identity data, discovery of the
OpenID Provider and advanced session management, including logoff.

Position and Adoption Speed Justification: OpenID Connect entered the market in 2011, and its
current status is that of an implementer's draft specification championed by the OpenID
Foundation. Despite having the slightly more mature Internet Engineering Task Force (IETF) draft
standard OAuth as its underpinning, OpenID Connect is in its earliest stages of development and
adoption. OpenID Connect's promise is that it will meet the needs of organizations needing to
protect APIs, provide service discovery and session management, and do so using a more
lightweight RESTful approach than XML-based standards such as SAML and WS-Federation. This
is why we believe OpenID will be appealing for open banking strategies. RESTful approaches are
increasingly favored by the newer class of developers because representational state transfer
(REST) uses familiar HTTP GET, PUT and POST operations, and the encoding scheme is less
verbose. OpenID Connect will improve security compared with OpenID 1.0 and 2.0, and OpenID
Connect includes functional specifications to gain users' consent before allowing access to their
resources. OpenID Connect will eventually replace earlier versions of OpenID. The security for Open

Page 10 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

ID Connect is still being tweaked by spec writers and is unproven, however, which is why we
believe it is just past the Innovation Trigger and will take five to 10 years to reach the Plateau of
Productivity.

User Advice:

■ CIOs should monitor developments and watch for the incorporation of OpenID Connect into
access management products and services.
■ Type A organizations launching open banking strategies may wish to prototype or test OpenID
Connect in a lab or limited pilot environment as open-source and commercial implementations
become available.

Business Impact: OpenID Connect will provide users with convenience and control. It will reduce
the data entry burden on users registering and revisiting service providers. OpenID Connect will also
be leveraged by other specifications, such as the nascent User Managed Access, that help users
and enterprises control access to resources. If the goals of OpenID Connect's developers are
realized, then enterprises should be able to conduct identity interactions more seamlessly, with less
friction than with today's XML-based standards, and with purely proprietary implementations.

Benefit Rating: Moderate

Market Penetration: Less than 1% of target audience

Maturity: Embryonic

Recommended Reading: http://openid.net/connect

Business Models
Analysis By: Kristin R. Moyer; Dave Aron

Definition: A business model for open banking identifies how the bank creates value for its
customers through the deployment of public Web APIs, software development kits (SDKs) and
apps, and how it retains some of that value.

Position and Adoption Speed Justification: The customers, partners or enterprises/banks


increasingly expect products and services to be delivered in a way that meets their specific needs
and contexts, and revolves around their digital lives. This requires CIOs to have architectures and
infrastructures that are based on modularity, standards, business process management (BPM) and
other technologies. It also requires them to adopt digitalization, which is not just about digital
technologies but, more importantly, about business model transformation. A digitalized business
creates value and revenue from digital assets (see "Digitalizing the Business"). This involves finding
new business models that make digitally delivered value accessible and addressable. Financial
institutions are spending more money on digital technology than almost any other industry, but have
so far left business models mostly untouched. Wasted IT investment is a major concern, especially
in light of a CEO's top business priority being to reduce costs (see "CEO and Senior Executive
Survey 2013: Financial Services CEOs Grapple With Costs and Uncertainty"). The lack of business

Gartner, Inc. | G00251123 Page 11 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

model transformation is also the situation for open banking. The industry is adopting open banking
strategies and technologies, but for the most part is not transforming business models so that full
business value can be realized. For example, open banking requires new monetization strategies,
but this is not being addressed in most bank rollouts of public Web APIs and other open banking
strategies and technologies.

A business model differs from strategy. Strategy defines the highest-level choices a company
makes (where to play and how to win), including the choice of business models and business model
changes, but the strategy is not the business model itself. A business model for open banking
should include six key elements that are critical to the success of open banking strategies (see
"Introducing the Gartner Business Model Framework"):

■ Ideate: Where ideas for open banking strategies and technologies come from, how decisions
are made, and how CIOs are informed and use that information to make decisions.
■ Create: How open banking is deployed, how the service is created and how the community is
managed.
■ Engage customer: How the interaction between the customer and the open bank is initiated,
including conventional push models (marketing and logistics) and pull models (customer
searching/seeking out the open banking strategy or technology).
■ Offering: The open banking customer value proposition, product and service. This includes and
extends conventional ideas of product and service design, for example open innovation and
crowdsourcing via open banking technologies.
■ Monetize: How value gets exchanged and transferred among retail and commercial banking
customers, third-party partners, citizen developers, bank employees and even other banks. This
includes and extends conventional ideas of pricing and payment. For digital content, the
"freemium" model is an example innovation, where the majority of customers get a free, basic
version of the service, and the profit comes from a minority who are prepared to pay a premium.
Stock price information services are an example of this.
■ Learn and change: How you go about learning, sensing and executing change for open
banking.

A business model for open banking should be leveraged for the creation and deployment of open
banking strategies. However, business models for open banking are currently at a much earlier
stage of adoption than the deployment of open banking technologies like public Web APIs,
hackathons and app stores. This is a matter that urgently needs to be addressed for open banking
strategies to be successful. We also believe that CIOs and business leaders will address strategic
direction first, but may continue to fail to address business model innovation, given how difficult it is
to achieve this level of change and transformation within banks (especially large banks). The risk is
that CIOs will build something that fails to gain traction or improve net profits — wasting precious IT
budgets and hurting bank reputation. We, therefore, believe that business models for open banking
are still five to 10 years from the Plateau of Productivity.

User Advice:

Page 12 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

■ Leverage the business model framework (see "Introducing the Gartner Business Model
Framework") while creating strategic direction for open banking, and before deploying an open
banking strategy.
■ Use a business model for open banking as the basis for a CEO-CIO dialogue regarding the
business opportunities inherent in open banking strategies and technologies.

Business Impact: Creating a business model for open banking is an urgent imperative for CIOs, IT
leaders, digital marketing and line-of-business executives that have launched, or will launch, an
open banking initiative in order to fully realize business value. Failure to do so will result in limited
traction with the value network, and, therefore, dramatically increase the risk of wasted IT budgets,
negative impact on net profits, reputation risk and customer trust.

Benefit Rating: High

Market Penetration: Less than 1% of target audience

Maturity: Embryonic

Recommended Reading: "Introducing the Gartner Business Model Framework"

"Business Model Innovation: Unleashing Digital Value Everywhere"

Bank-Branded App Stores


Analysis By: Kristin R. Moyer; Monica Basso

Definition: Bank-branded app stores support app discovery, downloads and collaboration between
customers and developers through a local storefront client or browser, and include ratings and
comments. They are primarily used by banks to deploy mobile apps that third-party developers
have built through an open banking strategy (via public Web APIs and software development kit
[SDKs]), but they could also be used to deploy apps that banks have developed for customers.

Position and Adoption Speed Justification: Banks use app stores in four different ways:

■ Public stores (for example, Apple App Store, Google Play, BlackBerry World and Windows
Store) — Banks and nonbanks use public stores to deploy mobile apps they have built for
banking customers. Apps that banks provide through public stores enable their own customers
to access information or initiate, confirm or complete transactions. Just a few examples include
Deutsche Bank (Global Prime, db-x Trading & Investment), ICBC (Mobile Securities) and BNP
Paribas (Mon Assistant Auto). However, some banks have developed apps that noncustomers
can use, for example the Barclays Pingit app can be used for peer-to-peer payments by
customers or noncustomers. Apps that nonbanks provide through public stores can usually be
used by anyone, regardless of whether or not they are even participating in the formal banking
system. Just a few examples include Mint.com, Check and Dwolla.
■ Enterprise app stores — Private, cloud-based or on-premises stores enable banks to deploy
apps for employees and partners.

Gartner, Inc. | G00251123 Page 13 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

■ Bank-branded app stores — Cloud-based or on-premises stores that are sponsored and
branded by a bank enable customers to discover and download banking apps. Bank-branded
app stores are usually provided by a bank that has deployed public Web APIs and SDKs for
third-party developers to custom build apps.
■ Vendor app stores — Cloud-based or on-premises stores that are sponsored and branded by a
banking technology vendor to enable licensed customers to discover and download banking
apps.

The focus of this Hype Cycle entry is bank-sponsored app stores. Banks that decide to adopt an
open banking strategy and deploy public Web APIs and SDKs face the choice of whether or not to
also deploy a bank-sponsored app store. If a bank is adopting an open banking strategy to expand
addressable market share, for example by letting mobile or social commerce providers customize
the way a payment happens on its site, a bank-sponsored app store is not necessarily needed.
However, if a bank is adopting an open banking strategy to leverage open innovation, a bank-
sponsored app store will usually be needed for developers to make their apps available for
customers. An exception would be if a bank decides to leverage third-party developers to build
apps for internal bank use. In that case, however, an enterprise app store would be more
appropriate. Bank-sponsored app stores are at an early stage of development, with Crédit Agricole
(CAStore) being one of the first to deploy its own app store as part of an open banking strategy.

Creating, launching and nurturing a third-party developer require focused effort and skills, which
most banks lack today. However, for banks that desire to harness the power of open innovation
through public Web APIs and SDKs, a bank-branded app store will be required to control testing
and fast removal of an app from the store if problems occur. As banks deploy more apps for their
customers, and the total number of apps available (across all categories, not just banking)
continues to grow dramatically, they may also find it easier for customers to discover their apps
from a bank-branded website, rather than a public app store. Fraud is also a major concern, and will
likely push banks to provide their own app stores. Customers may also feel more comfortable using
a bank-branded website when downloading a banking app due to fraudulent apps that are
increasingly being posted to public stores. For this reason, we believe bank-branded app stores will
reach the Plateau of Productivity within two to five years.

■ User Advice: Provide a bank-branded app store for open banking strategies that include third-
party developers when the objective is to make apps available for customers to use.
■ Collect customer feedback and preferences, and use this data to improve apps that the bank
builds for customers.
■ Provide support for third-party developers through bank-sponsored app stores (for example,
advertisement support [like the Google model] to allow vendors to be "top of deck"), user
reviews, rankings and recommendations (as with Amazon), billing (that enables payment in a
timely manner), reporting and business analytics.

Business Impact: Bank-branded app stores enable CIOs to launch open banking strategies and
nurture third-party developer communities. They provide banks with control (for example, to test
apps for compliance and security issues before posting to the store, and to quickly remove an app

Page 14 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

from the store when necessary). Bank-branded app stores can trigger a wave of innovation by
creating a new, highly competitive market for banking apps.

Benefit Rating: Transformational

Market Penetration: Less than 1% of target audience

Maturity: Emerging

Sample Vendors: AirWatch; AppCentral; Apperian; BoxTone; Fiberlink; MobileIron; Partnerpedia;


Symantec; Zenprise

Recommended Reading: "Two Foundations of a Successful App Store"

Integration PaaS
Analysis By: Kristin R. Moyer; Massimo Pezzini

Definition: Integration platform as a service (iPaaS) is a cloud services suite providing a platform to
support application, data and process integration projects, usually involving a combination of cloud
services (cloud-based applications or Web APIs) and on-premises systems. It is one method for
publishing and integrating public Web APIs as part of an open banking strategy. An iPaaS delivers a
combination of capabilities typically found in ESBs, data integration tools, B2B gateways, managed
file transfer products and governance platforms.

Position and Adoption Speed Justification: The iPaaS market is emerging from the convergence
of technology segments — cloud services integration (CSI), e-commerce B2B integration, API
management, platform as a service (PaaS), and traditional application and data integration
middleware (see "What IT Leaders Need to Know About Integration PaaS for Cloud Services
Integration (and More)"). iPaaS functionality is increasingly provided as "embedded" features in
broader cloud services, such as software as a service (SaaS), PaaS and possibly infrastructure as a
service (IaaS). Moreover, B2B specialists that deliver integration brokerages (IBs) and cloud services
brokerages (CSBs) sometimes provide iPaaS features for their own use in IT service offerings (see
"Benefits and Drawbacks of iPaaS as an 'Embedded' Feature of Cloud Services"). Here, we only
consider stand-alone iPaaS offerings that can be used to publish public Web APIs as part of an
open banking strategy.

Over the past five years, many organizations have successfully used iPaaS for basic cloud services
integration because of its simplicity, ease of use and affinity with the SaaS model. However, during
the past 12 months, several Global 2000-class organizations have approached iPaaS, primarily in
the wake of SaaS adoption, to support increasingly complex use cases. Some user organizations
also have adopted iPaaS as a replacement for traditional on-premises enterprise service buses
(ESBs) for internal integration. Emerging scenarios for iPaaS use include publication and
management of Web APIs (to support open banking strategies), mobile application integration and
machine-to-machine scenarios. The growing popularity of iPaaS has prompted the emergence of
new vendors, and has gained the attention of established application infrastructure vendors to this
opportunity, which they have entered (or have plans to enter) via acquisitions (for example, IBM's

Gartner, Inc. | G00251123 Page 15 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

acquisition of Cast Iron), cloud renditions of their established platforms (such as Informatica,
MuleSoft, Pervasive Software, Tibco Software, Software AG) or new developments (Microsoft and
SAP).

User organizations' growing adoption of SaaS applications further favors iPaaS utilization, given the
similarities between SaaS and iPaaS in technology, deployment styles, and purchasing models.
Their ease of use and fast time to integration characteristics, as well as the range of deployment
options available (see "iPaaS Expands Beyond Cloud Services Integration Through Flexible
Deployment Topologies"), also make them attractive for publishing public Web APIs. In the future,
iPaaS features will be incorporated in broader platform as a service (PaaS-platform in the cloud)
offerings, including application platform as a service (aPaaS-development in the cloud), which is
another method of building and managing public Web APIs. Using iPaaS to publish and manage
Web APIs is an emerging scenario that we expect to see gain momentum during the next 12 to 24
months as the number of new financial services APIs continues its rapid growth. These factors will
drive iPaaS adoption, especially in small and midsize organizations, and in the departments and
business units of large organizations, with minimal investments and skills in traditional integration
platforms.

Drivers for the use of iPaaS in deploying open banking strategies include:

■ The financial benefits (operating expenditures versus capital expenditures) typical of cloud
services
■ Faster time to integration
■ Greater ease of use, compared with traditional integration middleware and the set of cohesive
and integrated capabilities previously found in multiple discrete integration products.

A number of factors limit iPaaS adoption, including fragmentation, lack of skills and industry best
practices, and lack of trust in a new paradigm (security, privacy and availability concerns, and
anxiety about ownership of and access to integration development assets stored in the cloud).
These concerns are compounded by still-limited industry experience in the use of iPaaS for more
traditional internal application and data integration and service-oriented architecture (SOA)
scenarios, and this is especially true as it relates to publishing public Web APIs in open banking,
which is still emerging. These factors are especially prevalent among large organizations with
established investments in traditional integration platforms that have comparatively less SaaS use,
and see iPaaS only as an in-the-cloud rendition of the integration infrastructures they already have.
However, as adoption of open banking strategies grows, iPaaS will become a commonly used
publishing method. For these reasons, we have placed iPaaS in this context just past the Innovation
Trigger and expect it to reach the Plateau of Productivity within five to 10 years.

User Advice:

■ Use iPaaS when a low-cost and easy-to-use alternative to traditional integration platforms (like
ESBs, adapters, message-oriented middleware [MOM], etc.) is needed. This can be an
especially good approach to launch low-budget and time-constrained open banking strategies.

Page 16 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

■ Use iPaaS to publish public Web APIs when faster time to deployment is needed, especially if
established on-premises integration platforms don't support the required adapters, message
formats, communication protocols and other specific capabilities.

Business Impact: By using iPaaS offerings, user organizations can quickly and cost-effectively
integrate the business processes encompassing cloud services and on-premises applications
without acquiring, deploying and managing complex and expensive integration platforms. This will
help users reduce the time to deployment of new public Web APIs, increase the efficiency of
business processes, better and more deeply integrate with their business partners, and control on-
premises IT costs.

Benefit Rating: Moderate

Market Penetration: Less than 1% of target audience

Maturity: Emerging

Sample Vendors: AppPoint Software Solutions; Dell Boomi; IBM-Cast Iron; Informatica; Jitterbit;
Microsoft; MuleSoft; Pervasive Software; Software AG; Tibco Software; WSO2

Recommended Reading: "What IT Leaders Need to Know About Integration PaaS for Cloud
Services Integration (and More)"

"iPaaS Expands Beyond Cloud Services Integration Through Flexible Deployment Topologies"

"Benefits and Drawbacks of iPaaS as an 'Embedded' Feature of Cloud Services"

"What IT Leaders Need to Know About Cloud Services Integration: Proactively Address the
Challenge"

"Refresh Your Practices, Governance and Technologies to Tackle Cloud Services Integration"

"How to Identify the Right Basic Approach for Your Application Integration Project"

Open Bank Project


Analysis By: Kristin R. Moyer

Definition: The Open Bank Project is open-source API management software that provides data
APIs (via GitHub), governance, intermediation, metadata, registry/repository and security through
open-source software created specifically for the banking industry. The Open Bank Project operates
under the Affero General Public License (APGL), which permits free use, access to the source code,
modification and redistribution.

Position and Adoption Speed Justification: API management is available through both proprietary
and open-source software. A number of non-industry-specific open-source API management
platforms have emerged in 2012 and 2013 — for example, apiGrove and WSO2 API Manager. The
Open Bank Project focuses specifically on the banking industry, and provides and manages REST

Gartner, Inc. | G00251123 Page 17 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

APIs using OAuth so that a bank's customers do not disclose their credentials with any third party.
The Open Bank Project provides a form of canonical message/data model that sits in between
applications and the bank's internal IT systems. It abstracts the complexities of different core
banking systems so that developers and vendors can securely connect their applications to multiple
banks. The Open Bank Project revenue model includes a commercial licensing option or revenue
sharing (by API usage) model for banks, through which the Open Bank Project can manage APIs,
leverage its developer community, execute hackathons and build new apps for banking clients.
Examples of banking apps that have already been developed by the Open Bank Project include
nongovernment organization (NGO) transactions made publicly available, voice recognition that
speaks balances to the visually impaired, and 3D visualization of transaction origins and
destinations. Several personal financial management (PFM) and ERP vendors have also integrated
with the Open Bank Project API. We are aware of several Tier 1 banks that are doing a proof of
concept with the Open Bank Project.

We believe that the Open Bank Project will be appealing to developers because of the ability to
build an app that can be used by any bank or customer through the use of connectors that interface
between the open-source API management platform and the bank's internal systems. However, we
expect that the Open Bank Project will be less appealing initially to large, commercial banks than
NGOs and microfinance institutions that are less concerned with differentiation. Because of this, we
believe that it will take at least 5 to 10 years for the Open Bank Project or other banking-specific
open-source API management platforms that emerge to reach the Plateau of Productivity.

User Advice:

■ Evaluate opportunities to participate in the Open Bank Project for nondifferentiated data
visualization or transactions.
■ Use the Open Bank Project and apps built from this platform to close competitive gaps quickly.

Business Impact: The Open Bank Project can enable developers to write an app once and have it
used by any bank. This enables open innovation, easier integration, and the ability to monitor and
monetize APIs.

Benefit Rating: Moderate

Market Penetration: Less than 1% of target audience

Maturity: Embryonic

Recommended Reading: "Govern Your Services and Manage Your APIs With Application Services
Governance"

Business Strategy
Analysis By: Kristin R. Moyer

Page 18 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

Definition: A business strategy for open banking includes the vision, mission, goals, incentives,
value network, priorities, approaches, skills and tools for achieving business value for opening up
bank systems to external parties.

Position and Adoption Speed Justification: Challenging economic, political and regulatory
conditions have dramatically reduced fee income and net interest income, while increasing capital
requirements in the global banking industry (see "Agenda Overview for Banking and Investment
Services, 2013"). Increasing revenue and decreasing costs are top CEO business priorities for 2013
(source: 2013 CEO survey). Applications are making it difficult for CIOs to deliver against these
priorities, because they are becoming increasingly cost prohibitive to maintain, and prevent the
ability to quickly pursue new revenue opportunities. Open banking is becoming an appealing
alternative to overcome the limitations of traditional, closed and proprietary applications, and not
only provides opportunities for CIOs to drive new revenue at lower costs, but also provides the
opportunity to harness the power of open innovation and crowdsourcing.

The banking industry has been opening up bank systems to external parties quite rapidly during the
past 12 months, but has generally failed to so far develop a clear business strategy for open
banking. For example, public Web APIs are currently much more mature than either a clearly
defined business strategy or business model framework. Furthermore, the offering of public Web
APIs and apps often are not aligned with banks' internal architectures and initiatives related to the
broader opening up of bank systems across internal and external audiences (see "Hype Cycle for
Bank Operations Innovation, 2013"). We sometimes hear CIOs say that they have deployed an open
banking technology, like public Web APIs, to appear innovative or to keep pace with competitors.
The identification of specific goals and performance metrics is extremely rare.

The problem with this approach is that it is not tied to specific goals and performance metrics,
vision and incentives regarding why people would want to participate, or a road map that includes
priorities and actions required to achieve goals or how value will be created and captured. Other
hidden risks have yet to be addressed as well — for example, intellectual property, supporting the
app (bank or developer) and hosting the app. In addition, open banking has so far mainly been
additive to already complex bank architecture, infrastructure and operations. This lack of alignment
to overall architectural and business goals is a problem.

The risk with open banking is that CIOs will build something that fails to gain traction or improve net
profits — wasting precious IT budgets and hurting bank reputation. We believe that creating a
strategic direction for open banking is an urgent imperative, particularly given continued economic,
political and regulatory volatility. For banks that have launched open banking initiatives without a
business strategy that is in alignment with broader enterprise architectural, application, and
enterprise strategies, we expect to see some fairly visible failures. We would define these as open
banking initiatives that are launched and then later retracted, because review and testing processes
were not rigorous enough and resulted in security problems or system outages. We, therefore,
believe that the creation of a business strategy for open banking will take two to five years to reach
the Plateau of Productivity.

User Advice:

Gartner, Inc. | G00251123 Page 19 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

■ Identify the mission and goals of an open banking initiative. Identify what will be achieved, as
well as specific goals and performance metrics. Examples of what will be achieved may include
things like expanding addressable market share, pursuing new market opportunities more
quickly and less expensively, and harnessing the power of open innovation and crowdsourcing.
Examples of goals might be to increase net profits by 1% to 2% within 18 months, the creation
of a developer community consisting of 1,000 people within 12 months, and a reduction of
internal application development and maintenance costs by 10% within 24 months.
■ Develop vision and incentives for why retail or commercial banking customers, third-party
partners, citizen developers, bank employees or even other banks would want to participate. An
example of a vision for open banking might be to shift power from the bank to the individual in
order to deliver needs-based financial services that increase net profits.
■ Define the value network and with whom value will be created and captured. Examples of who
will create the value may be citizen developers and a developer network. Examples of how the
value will be captured may include things like hackathons and an app store for retail and
commercial customers to access apps built by citizen developers.
■ Create a business strategy for open banking at the enterprise level, and align it to architecture,
infrastructure and operations innovation. Siloed approaches to open banking will result in
increased costs, operational risk and an inconsistent experience for customers.

Business Impact: A business strategy increases the potential to improve net profits and customer
experience for open banking strategies. It will help CIOs reduce risk and align open banking
strategies with enterprise architecture, infrastructure and operations innovation.

Benefit Rating: High

Market Penetration: Less than 1% of target audience

Maturity: Emerging

Vendor Readiness
Analysis By: Kristin R. Moyer

Definition: Vendor readiness is the degree to which applications have made open banking
strategies and technologies available to customers. This includes providing component-based
applications that adhere to service-oriented architecture and industry service-level and messaging
standards, public Web APIs, private Web APIs, SDKs, app stores and other open banking strategies
and technologies to enable the functionality of an underlying banking platform to be exposed and
leveraged by banks, partners, third-party developers and customers.

Position and Adoption Speed Justification: Banking-specific vendor solutions (for example, core
banking, card management software, etc.) that support open banking strategies and technologies
will include some or all of the following:

■ Public or private APIs that expose the functionality of an underlying banking platform (for
example, a retail core banking system).

Page 20 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

■ Software development kits (SDKs) or application development tools, such as integrated


development environments (IDEs), which can be used to develop apps.
■ Rules regarding the use of the development tools or APIs to design banking processes that are
enforced in the design of the app and the development environment, at a technical level and at
a copyright/intellectual property level.
■ Support for app marketplace submission workflow. Some tools include the process of app
marketplace submission as part of the service they provide. Even when the tool does not
support submission directly, it may assist developers with submission deliverables or
workflows.
■ Review after the developer submits an application, including a technical review, but also to
comply with various government regulations.
■ Security services — For example, screening for developer-built programs that could steal a
user's personal information before an application goes live.
■ Sample code — For example, for developers to use or learn from.
■ A sandbox or testing page where developers can debug their applications.
■ Documentation and training modules to help developers get started.
■ App stores where developers can post apps for use by others.

Supply is not keeping pace with demand when it comes to open banking. The use of public Web
APIs by banks is more mature than vendor readiness on this Hype Cycle. The number of new
financial services public Web APIs deployed in 2012 was explosive, with more than 250% growth
year over year (source: Programmable Web [April 2013] and Gartner). However, few banking
application vendors have solutions that enable open banking strategies and technologies. The
supply side has only gone from approximately 15 vendors and service providers to 20 since last
year's Hype Cycle.

We expect to see slow progress with banking application vendors and services providers because
of concerns about intellectual property, monetization, fraud, security, and the cost and effort to
develop open banking strategies and technologies. For this reason, we expect the vendor
landscape to mature more slowly than financial institutions themselves. However, this puts the
banking vendor landscape at high risk. We believe that open banking strategies and technologies
will introduce a level of hypercompetition and enable banks to get many of their needs met (via
custom-built apps from other developers) without the involvement of a technology vendor, and for a
lower cost.

User Advice:

■ Evaluate vendor readiness for open banking among your key application and service suppliers.
■ If your key suppliers do not have a strategy for open banking, identify alternatives to deploy
open banking strategies and technologies. Alternatives include build approaches like
application platform as a service (aPaaS) or API management software, as well as a buy

Gartner, Inc. | G00251123 Page 21 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

approach like acquiring new application or service providers that do provide open banking
strategies and technologies.
■ For new application and service acquisition, ensure the providers you select have open banking
capabilities or will have them soon.

Business Impact: The lack of vendor readiness for open banking could potentially slow its
adoption. However, many banks have taken control of this situation already and have found
alternatives — such as using aPaaS to expose a public Web API. Continued lack of progress on the
part of vendors in this area puts their relevance and viability at risk.

Benefit Rating: Moderate

Market Penetration: 1% to 5% of target audience

Maturity: Emerging

Sample Vendors: Bloomberg; Braintree; Compass Plus; FICO; Intuit; Ixaris; MasterCard; Open
Solutions; PayPal; Standard Treasury; Visa

API Marketplaces
Analysis By: Paolo Malinverno; Kristin R. Moyer

Definition: An API marketplace is a developer portal that can be used to discover, access, test,
sign up to, and include public or private Web APIs in new Web or mobile applications. API
marketplaces can be implemented via a cloud API management platform.

Position and Adoption Speed Justification: API marketplaces enable developers to distribute
Web APIs and include published Web APIs in the applications they develop. Accordingly, two types
of developers use API marketplaces:

■ Those belonging to the company that provides the API for usage (provider developers)
■ Those looking for specific public functionality in the applications they are implementing, who
want to source it through public APIs that some provider has published (user developers)

Provider developers can publish a Web API for public use or for private use within a company. Web
APIs that are made available for public reuse can be provided for free or monetized through basic or
premium-type plans, depending on the type of API provided and its role within the business model.
User developers can also use API marketplaces to discover Web APIs that are available for reuse.
API marketplaces earn revenue when provider developers monetize an API — for example, by
taking a percentage of revenue earned by the API provider. Frequently — especially when the
functionality or the data provided by the API is sensitive or of high value — user developers have to
go through some process of authentication and screening before they can test or use the API,
which is enforced through policies in API management platforms.

Some marketplaces provide additional services as well (generally delivered through a social
platform), such as:

Page 22 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

■ Communication among developers — for example, to comment on an API or suggest ways of


using it
■ Support for APIs — for example, trouble tickets and escalation procedures when there is an
issue, or to simply a need for clarification
■ Code samples for optimal use of the API
■ API testing — for example, how to test an API before using it
■ Basic analytics — for example, to track the use of an API, latency, uptime and errors (although
this is generally part of wider API management functionality)
■ Billing engine — for example, for provider developers that want to monetize their APIs

API marketplaces are at an early stage of development. Vendors such as Rackspace and AppDirect
have built service catalogs that include APIs and developer tools. GitHub also provides a service
catalog for APIs. ProgrammableWeb, now acquired by MuleSoft, traditionally listed thousands of
Web APIs. Some offerings, such as Mashape, are born only to be API marketplaces. Developer
portals supporting API marketplaces are quickly becoming strongly emerging functional
requirements for application services governance vendors — for example, Intel (Mashery), Axway/
Vordel and Layer 7. This will increasingly turn API management vendors into cloud service
brokerages (not only aggregation, integration and customization), pushing the other cloud service
brokerages that come to the market from a different angle — for example, generalized independent
software vendors to offer similar functionality and focus more on community management.
However, a lack of standards and vertical-specific public Web APIs (in banking, for example) will
slow the adoption of API marketplaces. For these reasons, we believe API marketplaces will take at
least two to five years to reach the Plateau of Productivity.

User Advice:

■ For user developers: Expect API marketplaces to proliferate. Exploit "hackathons" and your
social connections to find the APIs you need, and choose the API marketplace that most closely
matches your development style and needs.
■ For business managers and provider developers: Evaluate the business opportunities a
public Web API could offer as a new channel of distribution for your products or your data, once
it has been deployed and is operating well, by making it available through an API marketplace.
Your choice of which one will depend on the profiles of its users.

Business Impact: API marketplaces will simplify the discovery of APIs for reuse, and provide a way
for user developers and provider companies to monetize public Web APIs. They can also be used
as repositories to simplify API discovery inside provider companies. If the value system of the APIs
you publish is related to mass consumption, finding out which API marketplaces will work for you as
a provider will be a difficult process, but a key one to get right to meet your business objectives.

Developers' portals in API management (and in general application services governance) and API
marketplaces will offer similar functionality going forward and are highly related. This functionality
set will be used also by cloud service brokerages and will frequently be part of iPaaS platforms.

Gartner, Inc. | G00251123 Page 23 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

Benefit Rating: Moderate

Market Penetration: 1% to 5% of target audience

Maturity: Emerging

Sample Vendors: 3scale; Apigee; GitHub; Intel (Mashery); Mashape; MuleSoft

Recommended Reading: "Devise a Systematic API Management and Governance Strategy for
Long-Term CSB Success"

Open-Source Banking Systems


Analysis By: Kristin R. Moyer

Definition: Open-source banking systems are banking-specific applications (like card management
software or core banking), components (like relationship pricing) and infrastructure (like user
interface widgets) that are made available through an open-source license process. Open-source
software is available under license and distribution conditions specified by the Open Source
Initiative. An open-source license typically permits free use, access to the source code, modification
and redistribution, subject to the conditions of the entity distributing it.

Position and Adoption Speed Justification: Open-source banking systems make code available
to everyone, and let CIOs take advantage of open innovation, which capitalizes on knowledge and
expertise that lie beyond an enterprise's boundaries. Open-source banking systems may be
especially appealing in areas of commoditized functionality, components and infrastructure — as is
the case with packaged applications relative to homegrown applications. Some examples of open-
source banking solutions include Cyclos (online and mobile banking), MyBanco (microfinance),
Microfinance Open Architecture Program (which also includes software, not just standards) and
Mifos (core banking). However, the lack of a broad open-source vendor ecosystem available today
may lead banks to increasingly consider alternatives such as public Web APIs, cloud computing
and outsourcing. Lack of structured governance, support, standards (impacting interoperability) and
security vulnerabilities are barriers to adoption. There is less incentive for large banks (relative to
microfinance institutions, for example) to participate in open-source initiatives, because they often
consider their core applications and components competitive differentiators, although open-source
at an infrastructure layer may be more appealing. On the supply side, software vendors benefit from
the prevalence of the traditional licensing model, which provides them with an annuity stream for
customization and support. These factors are likely to delay growth in open-source banking for
more than 10 years, and technologies like public Web APIs may make this obsolete before reaching
the Plateau of Productivity.

User Advice:

■ Evaluate open-source banking systems as an alternative to deploying public Web APIs. Both
will enable CIOs to take advantage of open innovation, although once a bank has adapted an
open-source application to its environment, this would become more difficult. Open-source
banking systems may be more applicable in situations where CIOs want to extend application

Page 24 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

development bandwidth, but for internal bank applications rather than apps that customers
would use.
■ Do not adopt open-source software to execute an open-banking strategy if the primary
objective is to tap into third-party developers for the development and deployment of apps to
customers. Public Web APIs and software development kits (SDKs) are easier for third-party
developers to use, because they will usually include documentation, sample code and other
support not available via open-source software.
■ Evaluate opportunities to leverage open-source components like merchant-funded rewards or
relationship pricing that may enable faster time to market and lower costs than are involved in
evaluating, selecting and implementing a packaged application that includes more functionality
than needed.

Business Impact: Open-source banking systems enable banks to have direct customization control
over applications, components and infrastructure, as well as leveraging the power of open
innovation. In theory, open-source banking systems could reduce the total cost of ownership of
applications, components and infrastructure because it is free. The continuing focus on cost
reduction on the part of CEOs will create an opportunity for increasing the interest in open-source
banking systems. However, corporations often desire maintenance and support services for open-
source software (as is the case for Linux and providers like Red Hat and others), which then
reduces the cost-benefit of open source and can create the same type of vendor dependence
involved with proprietary applications.

Benefit Rating: Moderate

Market Penetration: Less than 1% of target audience

Maturity: Embryonic

Sample Vendors: Cyclos; JPOS; Micro-finance Open Architecture Project; Mifos; MyBanco; Open
Smart Card Development Platform

OAuth
Analysis By: Kristin R. Moyer; Gregg Kreizman

Definition: By orchestrating an approval interaction between an end user and the application, the
OAuth authorization framework makes it possible to grant third-party applications limited access to
resources on behalf of end users. The OAuth authorization framework separates the access request
from the resource being requested, allowing an independent authorization service to manage the
use of credentials on behalf of client and resource.

Position and Adoption Speed Justification: The OAuth specification was originally developed to
enable users to grant others access to the users' Web-based information resources without the
users being required to divulge passwords. (The sharing of password-protected photographs was
an early example.) However, OAuth has evolved to support more use cases in open banking
deployments, social networking interactions and document access control. This authorization

Gartner, Inc. | G00251123 Page 25 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

framework is needed to support the increasing requirements for multiparty interactions and the use
of mobile-resident applications. OAuth 2.0 allows for any HTTP-based authentication protocol to be
used.

OAuth 2.0 is an Internet Engineering Task Force (IETF) Internet Draft Specification. OAuth has
considerable support and adoption by large Internet technology providers, such as Facebook,
Google, Microsoft, salesforce.com and Yahoo. Identity and access management (IAM) software and
identity and access management as a service (IDaaS) providers are increasingly implementing
OAuth support in their products and services. However, enterprise adoption remains nascent.
OAuth 2.0 serves as the basis for implementing OpenID Connect, a specification that adds
authentication flows and other properties using a RESTful approach. For now, despite the
considerable momentum of OAuth, banks launching open development strategies relying on the
specification will do so in a dynamic environment, likely requiring frequent updates during the next
year to stay current. Despite this, OAuth is being used in many recent open banking deployments to
CIO satisfaction.

OAuth use on mobile devices is proving to be an emerging growth opportunity for the specification
set. Browser-based applications can make use of established mobile device browsers,
authentication methods and federation protocols. However, as specialized apps make inroads on
different mobile devices and OSs — each with its own access methods — enterprise users and
consumers could be faced with an ever-growing number of stand-alone proprietary access
methods. Standard authentication and authorization capabilities could help enterprises avoid lock-
in for any given access method. We expect OAuth to reach the Plateau of Productivity within two to
five years for open banking deployments specifically because of its robust uptake so far in initial
open banking deployments.

User Advice: CIOs and digital technology professionals that are launching open banking strategies
should evaluate OAuth 2.0 as a means of abstracting authorization.

Business Impact: OAuth will likely be relevant as a method of supporting authorization for
consumer-, commercial- (in the case of mobile apps) and partner-facing applications, and it may be
particularly suitable for increasingly prevalent mobile device platforms as part of an open banking
strategy. Its benefit rating is listed as Moderate this year, because it is a behind-the-scenes access-
enabling protocol set. It is still early in the cycle for its development and adoption, and more proof
points are needed.

Benefit Rating: Moderate

Market Penetration: 1% to 5% of target audience

Maturity: Emerging

Recommended Reading: "A Guide to Making the Right Choices in the Expanding IDaaS Market"

"User-Centric Identities Need Identity Proofing and Other Controls for Sensitive Data Access"

Page 26 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

Application PaaS (aPaaS)


Analysis By: Kristin R. Moyer; Yefim V. Natis

Definition: Application platform as a service (aPaaS) offers application development and cloud
deployment services, and is one deployment method for exposing public Web APIs as part of an
open banking strategy. It is an extended application server "in the sky," and is one of multiple types
of PaaS, along with integration PaaS (iPaaS), bpmPaaS and others (Gartner tracks 15 xPaaS
categories; see "Platform as a Service: Definition, Taxonomy and Vendor Landscape, 2012").
However, it is often mistakenly understood to be the whole PaaS.

Position and Adoption Speed Justification: aPaaS can be used as a generic environment to build,
test and deploy public Web APIs for bank applications (this is in contrast to iPaaS, where integration
as a platform can also be used to publish a Web API). Industry megavendors (such as IBM and
Microsoft) and small innovators (for example, Engine Yard and CloudBees) compete in this new
market. The offerings run the gamut of multitenancy types, from shared hardware to shared
everything (see "Gartner Reference Model for Elasticity and Multitenancy"). At the start of 2013,
most leading application infrastructure vendors have begun offering production aPaaS. This can
enable banks to build components of open banking software and then manage a public Web API
after deployment.

The process of establishing the platform architecture and standards for aPaaS is in its early stages.
Most leading vendors are still developing their insights into cloud computing and are investing first
in backward compatibility with on-premises skills and programming models where they have a
larger customer base. The aPaaS available today from the industry megavendors is relatively slow in
coming (prolonged betas and limited availability periods, infrequent updates). Most other aPaaS
comes from small providers, with a limited ability to execute, or are proprietary. The degree of cloud
usage and standardization in available aPaaS trails behind users' expectations.

Users choose aPaaS instead of the traditional on-premises application server environment
expecting higher productivity, faster time to results, ease of self-service management, escape from
notorious and never-ending version control issues, lower entry costs and lower total costs.
However, many of these benefits remain hard to get. For example, users looking for backward
compatibility find that aPaaS does not significantly improve productivity, and users looking for high
productivity find that aPaaS requires training and new skills. However, this has been the experience
of non-banking-specific users. Open banking is an emerging trend, and so we place aPaaS as
being just past the trigger given its limited use so far — whereas aPaaS across all industries is
sliding toward the Trough of Disillusionment.

User Advice:

■ Evaluate using aPaaS to deploy an open banking public Web API if you desire rapid time to
market. For projects that need to be completed quickly, the aPaaS option can't be beaten for
the short time to initiate the project and, often, the short time to deliver value as well.

Gartner, Inc. | G00251123 Page 27 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

■ Ensure your application integration infrastructure (including possibly the use of iPaaS) is
prepared to manage on-premises, private PaaS and public aPaaS-based cloud application
services.

Business Impact: Open banking is a major new development in the financial services industry.
aPaaS is a well-positioned foundation for building open banking services with high levels of
productivity, quality of service and agility.

Benefit Rating: High

Market Penetration: 1% to 5% of target audience

Maturity: Emerging

Sample Vendors: Appistry; CloudBees; Cordys; Engine Yard; GigaSpaces; Google; Mendix;
Microsoft; Pivotal; Red Hat; salesforce.com; Software AG; WSO2

Recommended Reading: "Platform as a Service: Definition, Taxonomy and Vendor Landscape,


2013"

"What IT Leaders Need To Know About Application PaaS Models and Use Patterns"

"Gartner Reference Model for PaaS"

"Gartner aPaaS Report Card: Choose Your Cloud Application Platform Wisely"

Cloud API Management


Analysis By: Paolo Malinverno

Definition: API management is a subset of application services governance and significantly


overlaps service-oriented architecture (SOA) governance. The current concept of API is an evolution
of the concept of a service in SOA (see "Govern Your Services and Manage Your APIs With
Application Services Governance").

Position and Adoption Speed Justification: API management's basic functionality includes:

■ Implementation and publication of an API that opens new business opportunities (or
consolidates existing ones) and is easily consumable in a secure, process-like fashion by the
developers being targeted. Features typically include API discovery, documentation, developer
access provisioning and key generation, testing and collaboration through a developer's portal.
■ Operational management, security, format translation and the collection of statistics associated
with the use of the API.
■ Support of API life cycle management (for example, versioning and packaging).

Additional API management functionality or services — not everyone feels they need them, but in
general they do — relate to:

Page 28 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

■ The planning and design of value-generating APIs


■ The promotion of API usage, targeting all the communities of developers that might be
interested in it
■ The assessment of the real value (for example, monetization) of the API
■ The instrumentation and analytics of the API

API management offerings have been maturing in the market for at least five years, but only in the
past two years (largely because of the rise of mobile apps and the increasing influence of the Nexus
of Forces) has usage really ramped up. Most of the APIs are B2B by nature, so these offerings are
generally cloud-based managed services. Some SOA governance technology (part of application
services governance) is run in the cloud, which — for the sake of this document — is considered
part of cloud API management services.

Competition to share the growth of API management as a phenomenon has been heating up
considerably recently, with Axway acquiring Vordel (see "Axway/Vordel Deal Could Be Greater Than
the Sum of Its Parts"), Intel acquiring Mashery (see "Intel's Acquisition of Mashery Bridges SOA
Governance and API Management"), CA Technologies acquiring Layer 7 (see "Sensing a Growing
API Management Market, CA Technologies to Buy Layer 7"), and MuleSoft acquiring
ProgrammableWeb. Acquisitions in this space will continue to be commonplace, as larger players
will want to buy themselves a slice in a rapidly growing market. Also, APIs usage will spread much
wider than it is now: that's why the peak of the hype has not been reached yet.

User Advice: The importance of APIs will increase steadily in the coming years. More and more
B2B interactions will be API-based (see "Predicts 2013: Application Development"). Cloud services
brokerages base their entire business model on Web APIs, and will increasingly need API
management (see "Devise a Systematic API Management and Governance Strategy for Long-Term
CSB Success").

In addition, corporate applications and mobile apps will be more API-based. IT departments have
less time and fewer resources to develop/buy/maintain all the applications their company needs. It
is only going to get worse:

■ Users will increasingly demand personalized features.


■ More and more digital natives will be joining the company.
■ Mobile will keep pulverizing the current concept of application.
■ Different apps suit different users.
■ The number of channels is multiplying (bring your own device adoption will explode this even
further)
■ Web, tablets, smartphones, TVs, video game consoles, cars and more (for example, Google
Glasses)
■ Each one of them sports several technology platforms

Gartner, Inc. | G00251123 Page 29 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

Companies will not be able to afford to provide different experiences for every user. As a result, IT
departments need to package data and logic from the system or record applications they have
today (and the few they will acquire/build in the next year or two) into APIs/services and find win/win
scenarios where someone else — outside IT and frequently outside the company — will build them
into winning user experiences.

Start thinking about which APIs are good to have, how they can open up new customers and new
ways of doing business, and you will be thriving in what is already been called the "API economy."

Business Impact: Cloud API management is useful for organizations publishing APIs to expand
their reach to social, media, mobile and other emerging marketing communication channels. These
organizations often need help planning, deploying and managing their API initiatives. It is also useful
to the (frequently mobile application) developers embedding the APIs in their apps. A full-featured
developer portal is — and increasingly will be — fundamental to drive API usage. As the number of
public APIs grows, cloud services brokerages will offer more and more services built on top of them
(according to the three CSB roles: aggregation, integration and customization), and will need
sophisticated API management to scale their businesses properly.

APIs are new distribution channels. No CIO can ignore their business potential and the
transformation they will cause in IT departments in the future.

Benefit Rating: High

Market Penetration: 1% to 5% of target audience

Maturity: Emerging

Sample Vendors: 3scale; Apigee; IBM (Cast Iron Systems); Intel (Mashery); Layer 7; MuleSoft; SOA
Software; WS02

Recommended Reading: "Govern Your Services and Manage Your APIs With Application Services
Governance"

"Devise a Systematic API Management and Governance Strategy for Long-Term CSB Success"

"How to Understand the Criteria for the 2013 Application Services Governance Technologies Magic
Quadrant"

"Predicts 2013: Application Development"

Crowdsourcing
Analysis By: Kristin R. Moyer; Carol Rozwell

Definition: Crowdsourcing describes the processes for delegating a task or challenge to a broad,
distributed set of contributors using the Web and social collaboration techniques. Crowdsourcing
applications typically include mechanisms to attract the desired participants, stimulate relevant
contributions, and select winning ideas or solutions. When applied to open banking strategies,

Page 30 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

crowdsourcing is used to directly connect users with developers to gather ideas and feedback on
apps built through public Web APIs.

Position and Adoption Speed Justification: Crowdsourcing is being successfully applied to


narrowly defined tasks, open-ended challenges or simply calls for ideas. Banks that deploy public
Web APIs and other open banking strategies and technologies are using crowdsourcing to gather
input and ideas from customers, partners and employees. In the case of apps, crowdsourcing can
be used to gather ideas that enable third-party developers to meet the long tail of application
development requirements, and identify new and innovative ways to deliver banking services that
revolve around the digital life of the customer. Crowdsourcing can also be used for idea generation
prior to the full-scale development of an app. This can enable banks to identify especially attractive
apps in order to fund the development and deployment of these apps by third-party developers, or
to provide IT specifications and support if needed.

Successful crowdsourcing for open banking requires the banks to:

■ Specify the task or challenge (including time frame for responses, guidelines and rules) and
notify potential contributors
■ Manage payments
■ Assess intellectual property implications
■ Ensure some level of quality control regarding access, contributions (particularly if prizes or
payments are involved) and voting.

Crowdsourcing has been applied in a range of areas in government and private-sector organizations
for nearly a decade, with rapid acceleration in its use during the past two to three years for idea
generation in organizational innovation programs. For example, Crédit Agricole has used
crowdsourcing as a cornerstone of its CAstore initiative. Innovation activities where customers or
"the collective" creates and ranks ideas, or designs marketing campaigns, are the most popular.
These crowdsourcing activities generate ideas that are increasingly selected through voting by
participants — with the final selection made and developed by the organization's employees. In the
context of open banking, crowdsourcing could first be used to identify ideas for apps, and then be
used for third-party developers to create prototypes that are then selected for further development.

There is a large, untapped potential in applying crowdsourcing to a much broader range of tasks
and goals; however, there is still more to be learned and experienced about where the practice is
most effective compared with other approaches. The tools to establish a crowdsourcing
environment, particularly those involving recognition incentives or micropayments, are becoming
widely available. However, as with any technology, effective practices in crowdsourcing remain the
critical success factor. Challenges around managing intellectual property, regulatory compliance
and operational risk management are also barriers to using crowdsourcing for open banking
strategies. We believe the benefits outweigh the challenges., For that reason, it will take two to five
years for open banking crowdsourcing to reach the Plateau of Productivity.

User Advice:

Gartner, Inc. | G00251123 Page 31 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

■ Use crowdsourcing to generate ideas for how APIs and apps can be used to deliver banking
services that revolve around the customer's digital life.
■ Identify unmet customer wants and needs for banking apps through crowdsourcing, and then
commission third-party developers to create prototypes.
■ Let customers vote on app prototypes built by third-party developers. Provide investment and
support for the most popular prototypes. Keep in mind that at times consumers are lousy at
picking good ideas (what to build), but great at rejecting bad deliverables (what to throw away).

Business Impact: Crowdsourcing provides the potential to stimulate and capture creative ideas as
part of open banking initiatives. It dramatically increases the available human resources that can be
applied to a task or challenge — well-designed crowdsourcing efforts will attract interest and
creativity to a task. Crowdsourcing extends the access to key capabilities needed to make open
banking strategies successful, and can reduce the cost structure associated with the development
and deployment of apps.

Benefit Rating: High

Market Penetration: 1% to 5% of target audience

Maturity: Emerging

Sample Vendors: Amazon; Clickworker; CloudCrowd; Crowdcast; CrowdFlower; Directly;


IdeaScale; InnoCentive; Quora; TopCoder

Recommended Reading: "Maverick* Research: Crowdsource Your Management of Operational


Risk (The Supply Chain View)"

"Who's Who in Innovation Management Technology"

"Predicts 2013: CRM for Customer Service and Support in the Age of the Everywhere Customer"

"Market Insight: Future of IT Services, 2020; the 'Survival of the Fittest' Scenario"

Apptrepreneurs
Analysis By: Kristin R. Moyer; Ian Finley

Definition: The app stores of Apple and Google are both expected to eclipse 1 million apps this
year. A new generation of software entrepreneurs, which we call "apptrepreneurs," created the vast
majority of these apps. Open banking apptrepreneurs are a new generation of software
entrepreneurs that create apps that extend open banking platforms.

Position and Adoption Speed Justification: Evidence is growing that the banking and investment
services industry is in the midst of an app explosion (see "App Explosion: Lessons from the Top 20
Banks"). We believe the total number of mobile banking apps will grow at a 78% compound annual
growth rate (CAGR) between 2013 and 2016 (see "A Decision Framework for Deploying Banking
Apps"). CIOs and digital technology leaders will struggle to respond to this demand for new apps

Page 32 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

quickly enough because of development backlogs, time to deploy applications within the bank,
enterprise and consumer demands, and the nature of apps versus applications that demand faster
time to deploy. The current use of public Web APIs to support open banking strategies grew even
more quickly than in 2012, at 250% year over year. Banks that decide to adopt an open banking
strategy and deploy public Web APIs and software development kits (SDKs) face the choice of
whether or not to encourage the growth of an ecosystem of apptrepreneurs to help meet the
growing need for banking apps. The use of public Web APIs and SDKs, or "open banking," by
apptrepreneurs (third-party developers) is one application of open innovation (see "Maverick*
Research: Banking on APIs and Apps, Not Applications"). By providing public Web APIs and SDKs,
bank CIOs and digital technology leaders can tap into third-party developer talent outside of the
bank and harness the power of open innovation. This will help CIOs meet the long tail of app
development needs and is particularly relevant for "nice to have" functionality — but at times is also
very relevant for must-have functionality (for example, Capital One deployed public Web APIs for
loyalty and rewards; see "A Decision Framework for Deploying Banking Apps").

We have positioned open banking apptrepreneurs as a less mature open banking strategy than
hackathons because of the lack of effort on the part of banks in mobilizing third-party developer
communities. Without formally mobilizing apptrepreneurs into third-party developer communities, it
is unlikely that CIOs will get significant traction for their open banking initiatives. "If you build it, they
will come" will not work, given the large number of potential opportunities for apptrepreneurs to
monetize their skills. It is also crucial that CIOs create a monetization strategy for apptrepreneurs
that will be lucrative enough for them to want to participate. To date, we only know of one financial
institution that has done this, Crédit Agricole, with its CAstore initiative. Despite these challenges,
we expect to see the use of apptrepreneurs mature rapidly, within two to five years, due to the
extremely strong growth trajectory of open banking strategies.

User Advice: Aside from the challenges of staffing for and building an open banking platform, a
thriving ecosystem requires the enthusiastic participation of apptrepreneurs. Start with software
firms that know you well, and make sure writing apps for your open banking platform makes real
business sense for them. Provide good technical and marketing support, and once you have
success with your initial apptrepreneurs, you will be able to recruit more apptrepreneurs, expand
your ecosystem and rapidly expand your app portfolio.

Business Impact: To compete successfully for customers, banks and investment services firms will
need many more apps than their IT and digital budgets can supply. When provided with an open
banking platform and good ecosystem support, apptrepreneurs can satisfy these app needs, but
engaging them requires building a healthy developer ecosystem.

Benefit Rating: Transformational

Market Penetration: Less than 1% of target audience

Maturity: Emerging

Recommended Reading: "Maverick* Research: Banking on APIs and Apps, Not Applications"

"Citizen Developers Are Poised to Grow, 2011"

Gartner, Inc. | G00251123 Page 33 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

"Case Study: Citizen Developers Can Help Business Keep Pace"

"New Developers Can Help Deliver More"

Application Services Governance


Analysis By: Paolo Malinverno

Definition: Gartner recently introduced the term "application services governance" to refer to the
union of service-oriented architecture (SOA) governance technology functionality and API
management, thus preserving the terminology differences between the two, with the view that these
aspects will eventually be unified (see "Govern Your Services and Manage Your APIs With
Application Services Governance" for a more precise definition).

Position and Adoption Speed Justification: Application services governance admittedly strings
together three of the most abused (and misused) terms in IT, but this is ultimately what the two
functionality sets (SOA governance technology and API management) do, and the new name should
help clear up the confusion, not generate new doubts. After all, in the majority of cases, those who
talk about SOA services and those who talk about APIs mean the same thing. Remember that an
API, strictly speaking, is defined as an access method to a service (or a service interface, to use
SOA terminology).

All APIs and services go through several stages in their life cycles (as shown in Figure 2 in "Govern
Your Services and Manage Your APIs With Application Services Governance"). Application services
governance is a management discipline that rules how APIs and services evolve from one stage to
the other.

The characteristics of the two streams of application services governance are quite different when it
comes to positioning them on the Hype Cycle:

■ Traditional SOA governance technologies have been around for about 10 years. They are
typically used in on-premises, classical SOA projects, which are now mainstream. However,
SOA governance technologies have always trailed SOA maturity by at least two years, because
(wrongly) the bulk of SOA projects do not see the necessity for governance until one or two
years after the project starts. Two years ago, SOA governance technologies were sliding into
the Trough of Disillusionment.
■ API management, as a discipline, is maturing rapidly but still nascent, and is typically used in
the cloud to manage APIs that companies publish for use by mobile and Web business-to-
consumer (B2C)/B2B applications.

API management is moving on the Hype Cycle very quickly and will probably catch up with SOA
governance technologies (which are moving much more slowly) in approximately two to three years.
By that time, the two functional spaces will have morphed into each other, and it will be difficult to
distinguish between them. However, for now, it is good to separate the cloud API management
Hype Cycle entry on its own, even if it is a proper subset of application services governance.

Page 34 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

The current positioning of the application services governance technology analysis (and its maturity)
is a weighted average of the two different Hype Cycle positions, and takes into account the still
growing hype around API management, proved by a flurry of recent acquisitions, with Axway
acquiring Vordel (see "Axway/Vordel Deal Could Be Greater Than the Sum of Its Parts"), Intel
acquiring Mashery (see "Intel's Acquisition of Mashery Bridges SOA Governance and API
Management"), CA Technologies acquiring Layer 7 (see "Sensing a Growing API Management
Market, CA Technologies to Buy Layer 7"), and MuleSoft acquiring ProgrammableWeb.

User Advice: Despite the functional overlap, especially at the operate/run stage, SOA governance
technologies and API management are still referred to using completely different vocabularies —
what is a service on one side is an API on the other side — but they both refer to the same thing: a
piece of functionality that is called by a consumer, does some work and returns a result. On one
hand, you want to govern the design and the running of services. On the other hand, you want to
manage the design and the running of APIs. In one instance, you try to push reuse of services by,
typically, internal users who do not want to be governed. In the other instance, you try to guide Web
and mobile app developers to use the APIs, by applying light and largely human-free levels of
management. And the list of differences in naming goes on (see Table 1 in "Govern Your Services
and Manage Your APIs With Application Services Governance").We increasingly see clients looking
for application services governance functionality contacting SOA governance technology vendors
and API management vendors, frequently being uncertain of the offerings on both sides. Virtually all
the vendors on both sides are well-aware of this overlap, and they market to both communities.
Clients should not be confused by the different terminologies used. They should simply look for the
governance or management functionality they need, no matter how it is labeled. As previously
pointed out, it will take years for the differences in terminology to smooth out.

Application services governance is your insurance policy to get value out of your services/APIs.
Without it, you won't even be able to measure what value you are getting out of them (if anything).

Business Impact: The business impact of lack of governance in SOA projects has been discussed
at length in Gartner research (see the Recommended Reading section). SOA projects either won't
deliver value or the value they deliver is not measured and known (which is even more frustrating).
Also, publishing services and APIs have been traditional ways to participate in multienterprise B2B
processes. This type of usage is rapidly increasing. Cloud service brokerages will also be big users
of application services governance going forward (see "Devise a Systematic API Management and
Governance Strategy for Long-Term CSB Success").

The use of Web APIs is increasing even more, generally supporting new sales channels through
mobile applications. This has made API management more popular as a new way of informing and
selling to end customers. In particular, Type A organizations keen on exploring new ways to connect
with their customers increasingly equate a Web channel to a new business opportunity. For them,
having good API management is initially just a way of opening a new opportunity on a new sales
channel, and evolves into an advanced way of collecting customer behavior data.

Benefit Rating: High

Market Penetration: 5% to 20% of target audience

Gartner, Inc. | G00251123 Page 35 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

Maturity: Emerging

Sample Vendors: 3scale; Apigee; Axway (Vordel); IBM; Intel; Layer 7; Managed Methods; Mashery;
MuleSoft; Oracle; Software AG; SOA Software; Tibco Software; WSO2

Recommended Reading: "Govern Your Services and Manage Your APIs With Application Services
Governance"

"Devise a Systematic API Management and Governance Strategy for Long-Term CSB Success"

"Magic Quadrant for SOA Governance Technologies"

"How to Understand the Criteria for the 2013 Application Services Governance Technologies Magic
Quadrant"

"Predicts 2013: Application Development"

At the Peak

Hackathons
Analysis By: Kristin R. Moyer

Definition: Hackathons for open banking are short, focused events (typically one to two days)
during which many individual or team participants quickly develop and showcase their ideas. In the
context of open banking, hackathons typically involve third-party developers using APIs and other
tools and services to develop apps, visualizations and other outputs for areas like mobile banking,
social media, big data, trading, risk management, retail banking and commercial banking.

Position and Adoption Speed Justification: The purpose of a hackathon is to rapidly develop new
ideas and prototypes. Hackathons usually begin with a breakfast or other meal, followed by
networking and a presentation of the objectives of the event. Sometimes there are workshops and
other educational opportunities, but often the hacking begins next. Eating is usually informal,
though sometimes meals are provided. Sleeping can also be informal, with some participants
working long into the night with their sleeping bags nearby. When the time designated for hacking is
completed, the participants demo their apps. Demos are usually very short — for example, a three-
minute demo of the app and then two minutes for questions. A panel of judges evaluates the demos
and selects winners. For example, the panel of judges at a recent FinTech Hackathon in New York
City included executives from Bain Capital, GE Capital Markets, Barclays and Goldman Sachs.
Winners receive prizes such as cash, iPads, Kindle Fires and gift cards. Recent open banking
hackathons include the Open Bank Hackathon (London), The FinTech Hackathon (New York City)
and Digital Wallet Foundry (London). Many more hackathons are planned. For example, PayPal has
a series of Battlehacks planned in cities around the world that will then culminate with winners
going to Silicon Valley for a final competition, with the winner receiving $100,000.

We believe that hackathons will continue to increase in number, therefore reaching the Plateau of
Productivity within two to five years. However, we expect hackathons to begin to slide into the

Page 36 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

Trough of Disillusionment over the next 12 months as developers become fatigued by their use.
Organizers will need to ensure clear goals and financial benefits for participants or risk lackluster
attendance and participation. In addition, creating a third-party developer community should be a
higher priority for banks to ensure sustained innovation over time, with well-defined and monetized
hackathons used as a way to nurture the developer community.

User Advice:

■ Use hackathons to develop and nurture open banking developer communities and quickly
stimulate new ideas, apps, visualizations and other outputs.
■ Provide a predetermined level of technical support for the top three to five ideas and prototypes
generated in the hackathon so that they can become commercially viable.
■ Review hackathon demos to stimulate internal innovative thinking.

Business Impact: Hackathons can result in location/context-specific solutions and ideas. For
example, a good idea from a hackathon in Los Angeles is not necessarily a good idea from a
hackathon in India or even from a hackathon at another location in the U.S. Hackathons can
generate solutions and ideas that are truly at the convergence of mobile, social, cloud, information
and gamification as part of their DNA — not as afterthoughts, which is what is most commonly
occurring in the banking industry today. This might jump-start some innovative thinking within the
bank. Hackathons can also generate interest in the technology community for working in financial
technology (e.g., "Banking development is not just boring technology and programming"). This
could help banks attract new employees with fresh skills.

Although hackathons garner press attention today, developers could become easily fatigued as the
number of hackathons increases unless there is a clear benefit and financial reward for the
community. We believe hackathons can play a positive role in nurturing a third-party developer
community, but they alone will not ensure the success of an open banking initiative. For example,
unless ideas that are generated at hackathons are further developed, they will remain good ideas
that fail to generate net profits for the bank.

Benefit Rating: Low

Market Penetration: 1% to 5% of target audience

Maturity: Emerging

Sliding Into the Trough

Public Web APIs


Analysis By: Kristin R. Moyer; Gordon Van Huizen

Definition: Public Web APIs expose data, business processes and application capabilities through
interfaces typically based on Web-oriented architecture (WOA) principles. Banks use public Web

Gartner, Inc. | G00251123 Page 37 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

APIs to expand their addressable market share and harness the power of open innovation. As the
use of public Web APIs expands, banks that do not have solid API strategies will find themselves
increasingly disadvantaged.

Position and Adoption Speed Justification: Public Web APIs are one of the primary technologies
banks are using to pursue open banking strategies. However, the use of public Web APIs is not
new. Financial institutions began providing public Web APIs in 2005; however, less than 15 were
provided by 2007. Adoption accelerated in 2012, when the number of new financial services public
Web APIs increased more than 250% year over year. We attribute this growth to a number of
factors. At the Nexus of Forces of mobile, social, cloud and information, banks need a platform that
enables others to build their own solutions. Platforms that provide private and public Web APIs and
apps will better support the composition and delivery of needs-based banking solutions that
address specific customer needs by device, location and context. Private and public Web APIs
enable developers to quickly respond to new sales opportunities. They enable customers and third-
party developers to build solutions that meet their specific needs — for example, allowing a social
gaming provider to customize payments and account top-up. CIOs are better able to meet the long
tail of application development needs by providing public Web APIs to third-party developers. The
financial impact of public Web APIs is potentially profound, because they provide new revenue
opportunities for banks — new partners, new customers, localization, globalization or market
expansion (through faster and easier customization), and best practices distribution (through
enterprise app stores).

Despite their great potential, we believe public Web APIs for banking are quickly sliding into the
Trough of Disillusionment. Many banks are launching public Web APIs prior to developing a clear
strategic direction, business model or governance structure for deployment. We also see a lack of
attention to the need for robust internal testing teams that evaluate the apps developed from APIs
for things like regulatory compliance and security. For these reasons, we expect many banks that
have deployed public Web APIs to have the need to go back and create strategic direction,
business model and application services governance "after the fact" (given they have already
deployed one or more public Web APIs), or retreat from public Web APIs temporarily until some of
these important issues are in place. However, we expect to see more than 50% of banks deploy a
public Web API within the next two to five years, at which time they will be at the Plateau of
Productivity.

User Advice:

■ Provide public Web APIs to quickly pursue new revenue opportunities (for example, social
commerce), provide deeper localization specificity, facilitate market expansion, harness the
power of open innovation and create a "stickier" customer relationship.
■ Don't assume that "if we build it, they will come." Establishing traction for a public Web API
requires a clear strategic direction, business model and application services governance
(including API management). Additionally, it requires creating developer awareness and making
the API easy to consume via a self-service developer portal.
■ Before releasing your Web API to the outside world, consider the traffic and resource
implications for your data center. Complement your infrastructure with Web API management

Page 38 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

products and cloud services as required, and ensure that you have an adequate funding model
in place for its ongoing operation.
■ Put application services governance in place, including API management, prior to launching an
open banking strategy. Also involve the enterprise architecture team and security team, for
example taking into consideration dynamic application security testing (DAST) and static
application security testing (SAST; see "Magic Quadrant for Dynamic Application Security
Testing" and "Magic Quadrant for Static Application Security Testing").

Business Impact: Public Web APIs provide the foundation for a vibrant ecosystem of business
partners and independent developers that apply their own ingenuity and effort to expand the use of
your bank's services and data. As a result, IT organizations can become central players in helping
their organizations expand top-line growth, improve service delivery, drive competitive advantage
and reimagine the banking industry.

Benefit Rating: Transformational

Market Penetration: 5% to 20% of target audience

Maturity: Adolescent

Sample Vendors: Apigee; Mashery; SOA Software

Recommended Reading: "Maverick* Research: Banking on APIs and Apps, Not Application"

"Extend the Enterprise With Public Web APIs"

"Adopt These Six Traits of Highly Effective Web API Programs for Business Advantage"

"Designing a Great Web API"

Banking Apps
Analysis By: Kristin R. Moyer; Christophe Uzureau

Definition: An app is a new type of software packaging construct where value is derived from
purposefulness. The more focused an app is on doing one thing well, the more valuable it's deemed
to be. This contrasts with the traditional "application" packaging construct where value is tied to
capabilities — the more things it does the better it's perceived to be. Apps are not miniapplications.
They represent an entirely different approach to conceptualizing and delivering a software solution.
The terms should not be used interchangeably.

Position and Adoption Speed Justification: Apps have emerged over the last 15 years against a
backdrop of traditional applications that have grown complex and difficult to use due to their
functional density. Google was the first organization to understand and exploit the app metaphor
through the use of "addressable function points." Rather than integrate numerous capabilities into a
single portal model, as its competitors were doing, Google linked well-defined solutions — such as
search, mail, calendar, RSS reader — to discrete URLs. The app metaphor became widespread

Gartner, Inc. | G00251123 Page 39 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

with the advent of iOS, but not because there was a wholesale understanding by the developer
community of the concept. Rather, developers stumbled into the creation of purposeful software as
a necessity of the limited screen size they were developing to.

Evidence is growing that the banking and investment services industry is in the midst of an app
explosion (see "App Explosion: Lessons From the Top 20 Banks"). Mobile app downloads across
industries and categories increased by more than 80% in 2012 (see "Market Trends: Mobile App
Stores, Worldwide, 2012"). We believe the total number of mobile banking apps will grow at a 78%
compound annual growth rate between 2013 and 2016 (see "A Decision Framework for Deploying
Banking Apps"). For this reason, we believe banking apps will reach the Plateau of Productivity (that
is, when 20% to 50% of banks have deployed apps that are single purpose with strong user design)
in less than two years.

The rapid growth of banking apps will not be without its challenges. The current quality of banking
apps is low (see "Software Development for Banking Apps Needs a Diet"). While 45% of Android
apps receive a 5.0-star rating from users (source: AndroLib, 3 December 2012), only 1% of iOS and
10% of Android apps from the top 20 banks in the world receive comparable ratings (source:
Gartner secondary research analysis of the top 20 banks in the world by assets, December 2012 to
January 2013. Apps with a rating of 4.5 and above were counted as having a 5.0-star rating). Most
banking app strategies to date have relied on using mobile channel servers and other techniques to
replicate online banking application functionality for mobile devices. The next phase of banking app
maturity will embrace minimalist design and enable users to personalize the functionality they want
in their digital banking life. This level of extreme simplicity requires new governance models and
development practices for banking and investment services' CIOs and business leaders. Some
banks have begun moving in this direction already, and are producing narrow, focused apps with
solid user design.

User Advice:

■ Educate business leaders on the changing needs of users, who have become accustomed to
using apps with narrow functional footprints that do one thing very well.
■ Engage competent user experience design agencies to create apps that revolve around the
digital life of the customer by taking the context of the user into account (need, technology and
location).
■ Create an app road map that identifies customer need/context and impact on net profits.
■ Enable users to configure and personalize the functionality they want to use, and provide them
with only that functionality.
■ Use open innovation, through public Web APIs and software development kits (SDKs), to meet
the long tail of app development needs.
■ Begin exploring the observe-define-build-refine model as an alternative to the solicit-iterate
loop.
■ Retool the application development process so that more time is spent identifying and refining
personas and meeting unmet needs than is spent asking for feature requests.

Page 40 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

Business Impact: Apps are transformational because they will enable banks to deliver services that
revolve around the digital life of the customer. For example, it is largely through apps that banks will
deliver need-based services based on the context of the customer. Apps enable faster time to
market and lower costs given their narrow focus, and are therefore disposable. This is in contrast to
banking applications that require months to years to implement and are therefore often used for five
to seven years or more (in some cases for decades).

Benefit Rating: Transformational

Market Penetration: 5% to 20% of target audience

Maturity: Adolescent

Sample Vendors: Kony;SAP;Vipera

Recommended Reading: "App Explosion: Lessons From the Top 20 Banks"

"A Decision Framework for Deploying Banking Apps"

"Banking Apps Need to Be Awesome"

"Software Development for Banking Apps Needs a Diet"

"Maverick* Research: Banking on APIs and Apps, Not Applications"

Micrometered Revenue Models


Analysis By: Kristin R. Moyer; Mark Raskino

Definition: A micrometered revenue model for open banking is the business capability of
incrementally charging a customer for precision-monitored use of an app, consumption of an API
through electronic tracking and recording, or remunerating developers for apps that customers use
and like.

Position and Adoption Speed Justification: Micrometered revenue models can be used in a
number of different ways for developers and banks to monetize open banking strategies (for
example, the use of public Web APIs and bank-branded app stores to build and deploy apps):

■ Customers could be charged: (1) to download an app, (2) with a small monthly fee to use an
app, and/or (3) with a pay-per-use of a service. Banks could take a percentage of the revenue
earned (for example, 30%), with the rest going to the developer. However, we believe the
willingness of customers to pay for a banking app is years away, at best.
■ Developers could be paid based on app usage and customer ratings. This would enable banks
to cut the costs of app development while motivating developers to build apps that users like so
much that they use them frequently.

Gartner, Inc. | G00251123 Page 41 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

Technology advances enable banks to track and record consumption activity in finer detail,
economically. This improvement in information granularity can make more-market-efficient
incremental pricing and charging models viable. At the extreme, individual "micropayments" may be
only a few cents — which is likely to be the case for open banking. The value comes from
persuading more customers to buy, or increase their use of, the product or service. Upfront capital
risk or contractual commitment by the customer is reduced, making it attractive. This can be
particularly valuable when addressing lower-income groups and in developing countries.

Currently, most banking apps are provided for free. It remains to be seen how, and if, banks will be
able to charge customers for apps and other services created from open banking strategies.
However, if banks are aggressive with finding ways to monetize the apps that developers build, this
technology could reach the Plateau of Productivity within two to five years.

User Advice:

■ Include micrometered revenue models in the creation of a strategic direction and business
model for open banking.
■ Test the willingness of customers to pay small fees for using apps developed by citizens and
other developers. For example, what is the viability of charging a small monthly fee, pay-per-
app fee, pay-per-use fee or other fee?
■ Pay developers for apps that receive high usage and customer ratings. This will reduce the
costs of app development for banks, and help banks better meet the long tail of app
development needs.

Business Impact: The ability to monetize an open banking strategy will ultimately be its success or
failure. Micrometered revenue models can help banks cover costs with the initial launch of an open
banking strategy. If market acceptance and customer usage reaches a critical mass, which is what
will ideally happen, micrometered revenue models can then enable banks to improve net profits.

Benefit Rating: High

Market Penetration: 5% to 20% of target audience

Maturity: Adolescent

Recommended Reading: "Findings: U.S. Demand for Pay-as-You-Drive Auto Insurance Greatly
Surpasses Supply"

"Seismic Market Shifts Will Force Newspapers to Become News Hubs"

"Four Scenarios for Mobile Financial Services in Southern Africa"

Page 42 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

Appendixes

Hype Cycle Phases, Benefit Ratings and Maturity Levels


Table 1. Hype Cycle Phases

Phase Definition

Innovation Trigger A breakthrough, public demonstration, product launch or other event generates
significant press and industry interest.

Peak of Inflated During this phase of overenthusiasm and unrealistic projections, a flurry of well-
Expectations publicized activity by technology leaders results in some successes, but more
failures, as the technology is pushed to its limits. The only enterprises making
money are conference organizers and magazine publishers.

Trough of Because the technology does not live up to its overinflated expectations, it rapidly
Disillusionment becomes unfashionable. Media interest wanes, except for a few cautionary tales.

Slope of Focused experimentation and solid hard work by an increasingly diverse range of
Enlightenment organizations lead to a true understanding of the technology's applicability, risks
and benefits. Commercial off-the-shelf methodologies and tools ease the
development process.

Plateau of The real-world benefits of the technology are demonstrated and accepted. Tools
Productivity and methodologies are increasingly stable as they enter their second and third
generations. Growing numbers of organizations feel comfortable with the reduced
level of risk; the rapid growth phase of adoption begins. Approximately 20% of
the technology's target audience has adopted or is adopting the technology as it
enters this phase.

Years to Mainstream The time required for the technology to reach the Plateau of Productivity.
Adoption

Source: Gartner (July 2013)

Gartner, Inc. | G00251123 Page 43 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

Table 2. Benefit Ratings

Benefit Rating Definition

Transformational Enables new ways of doing business across industries that will result in major shifts in
industry dynamics

High Enables new ways of performing horizontal or vertical processes that will result in
significantly increased revenue or cost savings for an enterprise

Moderate Provides incremental improvements to established processes that will result in


increased revenue or cost savings for an enterprise

Low Slightly improves processes (for example, improved user experience) that will be
difficult to translate into increased revenue or cost savings

Source: Gartner (July 2013)

Table 3. Maturity Levels

Maturity Level Status Products/Vendors

Embryonic ■ In labs ■ None

Emerging ■ Commercialization by vendors ■ First generation


Pilots and deployments by industry leaders High price
Much customization

Adolescent ■ Maturing technology capabilities and process ■ Second generation


understanding Less customization
Uptake beyond early adopters

Early mainstream ■ Proven technology ■ Third generation


Vendors, technology and adoption rapidly More out of box
evolving Methodologies

Mature ■ Robust technology ■ Several dominant vendors


mainstream Not much evolution in vendors or technology

Legacy ■ Not appropriate for new developments ■ Maintenance revenue focus


Cost of migration constrains replacement

Obsolete ■ Rarely used ■ Used/resale market only

Source: Gartner (July 2013)

Page 44 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

Recommended Reading
Some documents may not be available as part of your current Gartner subscription.

"Understanding Gartner's Hype Cycles, 2013"

"Maverick* Research: Banking on APIs and Apps, Not Applications"

"Banking Apps Need to Be Awesome"

"App Explosion: Lessons From the Top 20 Banks"

"Software Development for Banking Apps Needs a Diet"

"A Decision Framework for Deploying Banking Apps"

More on This Topic


This is part of an in-depth collection of research. See the collection:

■ Gartner's Hype Cycle Special Report for 2013

Gartner, Inc. | G00251123 Page 45 of 46

This research note is restricted to the personal use of [email protected]


This research note is restricted to the personal use of [email protected]

GARTNER HEADQUARTERS

Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
USA
+1 203 964 0096

Regional Headquarters
AUSTRALIA
BRAZIL
JAPAN
UNITED KINGDOM

For a complete list of worldwide locations,


visit http://www.gartner.com/technology/about.jsp

© 2013 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This
publication may not be reproduced or distributed in any form without Gartner’s prior written permission. If you are authorized to access
this publication, your use of it is subject to the Usage Guidelines for Gartner Services posted on gartner.com. The information contained
in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy,
completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This
publication consists of the opinions of Gartner’s research organization and should not be construed as statements of fact. The opinions
expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues,
Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company,
and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner’s Board of
Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization
without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner
research, see “Guiding Principles on Independence and Objectivity.”

Page 46 of 46 Gartner, Inc. | G00251123

This research note is restricted to the personal use of [email protected]

You might also like