WHITEPAPER





Open Banking and the Future of Financial
Services
Are you a survivor or thriver?



2

Setting the scene

Every day there is a new article that discusses the sea change
disrupting the banking industry. This change, they say, will
fundamentally disrupt the financial services value chain for
customers, intermediaries, and incumbents alike. There is no
avoiding the signs.

Across the world there are pressures, both regulatory and
customer-led, that are opening up the market to new entrants
and disrupting what and how customers buy. In Europe
specifically, the Revised Payment Services Directive (PSD2) is
set to unleash a transformation in how financial services
organizations view themselves, and each other. This isn’t
unique to Europe - in the United States, aggregators such as
Mint.com have already dis-intermediated banks and now own
the ‘last mile’ of the customer banking relationship, disrupting
traditional players.

The success of Mint.com in the US highlights the appetite from
consumers for account aggregation, or Account Information
Service Providers (AISPs), in PSD2 language. Starting in 2006,
it now says its customer base for its aggregation and personal
finance services is over 10 million strong. Traditional banks are
already feeling the competition with a number of high profile
temporary bans on access to data from such services. Under
PSD2, in Europe, this ban would not be legal; it’s only a matter
of time before other global markets follow this route.

PSD2, through both intermediating and dis-intermediating the
bank, provides a legislative mandate for more open data and
an increased open data interchange between financial services
organizations. By January 2018, European banks must provide
access to customer information (e.g. account balances and
details) to AISPs, introducing another entity to the customer
relationship. In addition, banks must expose customer
information and payments services to Payment Service
Providers (PSPs), dis-intermediating the traditional payments
model. Most importantly, banks and financial services
institutions may also take on the role of AISPs and PSPs
themselves. This will all be enabled through the effective use of
APIs; setting the scene for the API economy to play a
disruptive role in the future of financial services.

This need to drive a more open set of business practices will in
turn accelerate the adoption of Open Banking. How
organizations respond to this change will shape their future.
Those that underestimate these waves of change may be
survivors; but those who treat Open Banking as an opportunity
to re-define and prioritize what value they add in the value
chain will be thrivers, and will win, both short- and long-term.
Common approaches to Open Banking

With the rising importance of APIs, and banks waking up to the
strategic implications, some typical approaches can be
observed. The approach an organization selects depends on
the organizational history, context, and, more importantly, how
they wish to survive and grow. In particular, for large
incumbents, where there are different lines of business and
entities, they may be acting on more than one approach in
parallel across the organization.

The most obvious and prominent, at least in the media, is that
of the Challenger; a new entrant who does not have an
existing technology estate to ‘anchor’ them to a particular
solution. Typically, they are selecting fit-for-purpose, often
white labelled, platforms to quickly build capability and
products. These are embracing and usually defining the
opportunity for change and transformation, centered on
providing a better customer experience in banking. The hurdle
will be combining scale with this innovation. If and when this
can be addressed, they are primed to thrive in the new
landscape.

On the other side, there are various approaches being taken by
incumbent organizations, who have the scale already, but are
trying to grasp the innovation that Open Banking presents. For
some traditional large banks, a common route is to embrace
existing technology investments completely and selectively
transform these to compete effectively. For Transformers to be
successful, the key element is ensuring that these
transformation initiatives do not remain siloed. With the right
abstraction, legacy platforms can ‘plug and play’ in the Open
Banking environment but it is often costly upfront and can bear
higher risk. Therefore, with little re-use of a platform or
approach across lines of business then it could be a costly and
ineffective way to compete. The same challenge applies to
those organizations who are already running in-flight
modernization programmes. These Modernizers have already
“Open Banking is about making
everything for sale. It provides a new
way to increase digital revenue for the
banks that are willing to think differently
... Open Banks and FinTechs will
continue to erode margins and customer
relationships for those banks that don’t.”

- Kristin Moyer, Gartner, Research Vice President &
Distinguished Analyst

3

made the decision to significantly update or replace core
systems over the coming years and are anxious that an
investment in PSD2 and Open Banking today shouldn’t be
discarded in the near-term as their modernization programme
progresses; how can they continue with wider investments
whilst future-proofing their architecture for future technical
standards.

More radical, yet maybe the extent to which some will have to
go to thrive, is the approach some banks are taking to build a
complete new ‘digital’ bank outside the walls of the current
infrastructure. These Revivers have recognized that they will
never be able to, within reasonable constraints of budget and
time, compete with Challengers using their current systems so
are developing new operations and brands in parallel, which
they can shift everything across to potentially in the future.

Whatever the approach, traditional banks know that ultimately
to compete, they must develop digital capabilities to avoid
being dis-intermediated completely by new entrants with
superior, more agile offerings. By helping their customers to
manage their financial affairs, make better decisions, and save
money, banks can drive deeper 'trusted adviser' relationships
that ultimately will result in stickier customers as well as
product up-sell and cross-sell. These organizations can take
advantage of the opportunities that AISPs present and move
from a transactional customer relationship to a more engaged,
valuable and ultimately more profitable relationship.


Three challenges to overcome

Whether an established bank, new entrant or FinTech, how
then should business and technology leaders respond? How can
they simultaneously meet requirements to open data to third
parties yet maintain differentiation in a hyper-competitive
market?

PSD2 is, after all, just the latest in a long line of initiatives that
are putting pressure on banks. Refreshing core banking
systems, developing digital capabilities, and responding to
previous legislative mandates have already stretched
organizations to breaking point. These initiatives are further
complicated by the adoption of new technologies and new
development processes. Against this backdrop, the most
critical differentiator is often the speed at which the IT function
is expected and can deliver on these initiatives.

When it comes to approaching PSD2 and Open Banking, three
challenges must be met:


1. Culture shift and future proofing of technology
investments

Open Banking and the use of APIs is fundamental and not to be
underestimated. Some banks have chosen to embrace
concepts such as R&D and innovation incubation teams,
unbundling monolithic IT systems into reusable service
components and hackathons to spark innovation in order to
gain that agility. This may address today’s concerns, but how
can banks build for tomorrow with uncertainty on the technical
standards that will be defined in months and years to come? As
described with the Modernizers, the last thing that any
technology leader wants is to have to rewrite a solution in
three years’ time because the technology they implemented
today isn’t fit for purpose in the short or medium term.

2. Contributing value to and from the API economy

The new ecosystem is comprised of not only financial
institutions, but also retailers, high-tech companies, social
media, crowdsourcing platforms, and potentially anything that
involves financial information or transactions.

In this new ecosystem, APIs are a new channel for doing
business and need to be given that importance. The
monetization of the API economy presents a new source of
revenue, but only if a bank’s APIs are adopted and used by
other organizations and developers. They should be
productized and marketed as a source of competitive
advantage, like any other traditional product. There is no value
in having the best banking platform if developers don’t want to
open the front door. Successful APIs require healthy internal
and external developer communities and so APIs also need to
be easily found, understood, and used.

Banks need to both offer their services to be consumed by
external third parties, but also think creatively how to use
third-party services for their own offerings. Thriver banks will
not only astutely open their own systems for others to
consume but also look how to innovate and enrich their
services by using other organization’s APIs.

3. Coping with increased, new and future demand

Requirements for API platforms are numerous and future
generations of customers will make new demands on these
platforms that are unclear today. They must support security
measures such as encryption, strong customer authentication
and auditing to keep financial transactions and information
secure. They must be scalable and efficient. When payments

4

are invoked through APIs and are revenue generating, poor
availability and reliability are not an option. In a world where
third-party partners are exponentially nudging a bank’s
infrastructure with requests for payment permission and for
live data feeds, the heightened risk of an overload on a bank’s
network is very real.

Banking-as-a-service: API-led
Connectivity

To address these challenges and harness the opportunities
presented, a new construct is needed. API-led connectivity is
an approach that defines methods for connecting and exposing
your assets. API-led connectivity builds on the central tenets of
SOA, yet re-imagines its implementation for unique challenges
and opportunities like the one that PSD2 and Open Banking
present. The approach shifts the way IT operates and promotes
decentralized access to data and capabilities while not
compromising on governance and security. It shifts the culture
of the organization to one of reuse and composability. This is a
journey that changes the IT operating model and which
enables the realization of an application network, a seamless
network connecting applications, data and devices.


Figure 1. API-Led Connectivity in Open Banking

Technically, from an IT perspective, while banks have largely
built their IT on proprietary systems and ran dedicated in-
house, over the years an increasing number of supporting and
now core services have gradually been moved to private cloud
or even public cloud infrastructure as well as reliance on the
growing number of SaaS services operated by third parties.
The cost/benefit ratio of leveraging a best of breed approach
between internal and external systems operated on-premise
or in the cloud leads-to an increased complexity in integrating
heterogeneous components consistently, rather than point-to-
point. Using point-to-point approach not only doesn't scale with
the number of systems needing to cooperate one with another
but also creates ever growing technical debt as additional
complexity is layered on top of each other over time.

From an integration perspective, given the regulatory and
security challenges of a pure cloud approach, Hybrid
integration is the way to progress at speed today. Hybrid cloud
integration provides the perfect compromise, assuring that
data from on-premises legacy systems can integrate with cloud
data. Coping with new and increased demand, the third
challenge aforementioned, is resolved as when capacity
reaches critical levels, additional capacity can be spun up from
the cloud rapidly. A mutual benefit, alluded to in the second
challenge above, is that a Hybrid integration enables FinTech
partners to be loosely coupled to your core platforms and
systems but not so much that it requires lengthy on-boarding.
This allows accelerated innovation as third party partners will
be able to interact on an instant basis. In other words, it
makes it easier for someone in the organization or developer
community to create a useful application, use of data, or an
experience API, and then expose that value to the wider
network. Already, a handful of banks are leveraging their
application networks to run hackathons with partners, including
MuleSoft, to realize this vision, and to quickly create potential
use cases.

In API-led connectivity, whatever you create, to ensure the
quality remains high, it crucially comes down to “Purposeful
Design”. You need to always design with the consumption of
data top of mind, APIs are the instruments that provide both a
consumable and controlled means of accessing connectivity.
They serve as a contract between the consumer of data and
the provider of that data that acts as both a point of
demarcation and a point of abstraction, thus decoupling the
two parties and allowing both to work independently of one
another (as long as they continue to be bound by the API
contract). APIs play an important governance role in securing
and managing access to that connectivity.

This is why the integration application must be more than just
an API; the API can only serve as a presentation layer on top
of a set of orchestration and connectivity flows. This
orchestration and connectivity is critical: without it, API-to-API
connectivity is simply another means of building out point-to-
point integration. This wouldn’t future-proof the solution and
would provide limited short-term goals. You need to decouple
and approach integration with layers in mind. This also enables
true cost savings and increased efficiency as it minimizes costly
re-engineering and design work at a later date.






5



























‘Three-layered’ API-led approach

In this context, putting in a framework for ordering and
structuring these building blocks is crucial. Banks have
complex, interwoven connectivity needs that require multiple
API-led connectivity building blocks. Agility and flexibility can
only come from a multi-tier architecture containing three
distinct layers

• System Layer: Underlying all IT architectures are core
systems of record (e.g. core banking system, key
customer and billing systems, proprietary databases etc).
Often these systems are not easily accessible due to
connectivity concerns. APIs provide a means of hiding that
complexity from the user. System APIs provide a means of
accessing underlying systems of record and exposing that
data, often in a canonical format, while providing
downstream insulation from any interface changes or
rationalization of those systems. These APIs will also
change more infrequently and will be governed by Central
IT, given the importance of the underlying systems.

• Process Layer: The underlying business processes that
interact and shape this data should be strictly
encapsulated independent of the source systems from
which that data originates, as well as the target channels
through which that data is to be delivered. For example, in
a purchase order process, there is some logic that is
common across products, geographies and retail channels
that can and should be distilled into a single service that
can then be called by product-, geography- or channel-
specific parent services. These APIs perform specific
functions and provide access to non-central data and may
be built by either Central IT or Line of Business IT.

•
Experience Layer: Data is now consumed across a broad
set of channels, each of which want access to the same
data in a variety of different forms. For example, a bank
branch teller, online banking site and mobile application
may all want to access the same customer information
fields, but each will require that information in very
different formats. Experience APIs are the means by
which data can be reconfigured so that it is most easily
consumed by its intended audience, all from a common
data source, rather than setting up separate point-to-point
integrations for each channel.

Each API-led connectivity layer provides context re function
and ownership:

Layer
Ownership
Frequency of
change
System
Layer
Central IT
6-12 months
Process
Layer
Central IT and Line
of Business IT
3-6 months
Experience
Layer
Line of Business IT
and Application
Developers
4-8 weeks; more
frequently for
innovation-led
business
Case study: Top 5 Global Bank

Digital transformation is often considered as external
to the firm. However, whether in terms of enabling
transformation outside the company, or in and of
itself, digital transformation is a powerful phenomenon
inside organizational boundaries also.

This multinational financial services company wanted
to drive a firm wide architecture driving application
development consistent with one of six best practice
messaging patterns.

This approach has initially seeded into one line of
business. This success prompted subsequent rollout
across 13 lines of business globally, connecting more
than 1,000 applications in production.

In the initial startup mode, the enterprise seeded
adoption via a central group which was better able to
seed adoption and prove out the approach. As the
company continues to scale across the business
however, it is looking towards API-led connectivity as
the means to decentralize elements of the architecture
to drive scale, yet maintain control.

Central to the ability to realize this vision was a center
for enablement which helped to codify knowledge and
disseminate best practice.


6


Next steps

Realizing API-led connectivity is not a discrete goal, but rather a continuous journey, much like Open Banking itself. Moreover, it is a
goal that can be only be realized in incremental steps. Through partnering with dozens of Fortune 500 companies and four of the top
nine global banks on their API-led connectivity and Open Banking journeys, we have distilled best practice into the following steps:


1. Start-up mode: In order for the API-led connectivity vision to be successful, it must be realized across an organization. However,
in large enterprises it is simply not possible to wipe the slate clean and start from scratch. Consequently, the API-led connectivity
customer journey must start with a set slice of the business, for a specific use case or for a specific line of business. By bounding
the problem, the scope of change is reduced and the probability of success increased. Training and coaching to drive role modeling
of new behaviors is critical at this stage.


2. Scale the platform: Once initial proof points have been established, these use cases will naturally become lightning rods within
the organization that will build mindshare and become a platform to leverage greater adoption. In addition, the service oriented
approach results in the natural creation of reusable assets which exponentially increases the value of the framework as the
number of assets increases.


3. Shift to a Center for Enablement (C4E): Once scale has been established, it’s critical to quickly codify best practice and provide
a platform for discovery and dissemination through the organization. The result of such a process is mass adoption across the
enterprise. The core of this C4E may also be built during the start-up mode and scaled as required.


For banks, the end result is a 2x to 5x faster time to launch new initiatives, connect systems, and unlock data across the enterprise and
a 30% reduction in integration costs. This pace of change and agility is fundamental to an Open Banking environment, and with PSD2
and new competition acting as a formal starting point, building foundations now is vital. No matter which of the observed approaches is
best for an organization, it has been proven that delivering on this vision through API-led connectivity supports both control and agility
and helps organizations thrive, not simply survive, in this rapidly-evolving environment.

MuleSoft’s mission is to connect the world’s applications, data and devices. MuleSoft makes connecting anything easy with Anypoint Platform™, the only
complete integration platform for SaaS, SOA and APIs. Thousands of organizations in 60 countries, from emerging brands to Global 500 enterprises, use
MuleSoft to innovate faster and gain competitive advantage.