Open Banking and the Future of Financial Services

The future of financial services is under pressure from profound digital disruption. Across the globe, there are forces, both regulatory and customer-led, that open up the market to new entrants and disrupt what customers are buying — and how. The advent of Open Banking is one major influence, with Open APIs paving the way for third-party developers to build applications and services independently.
This whitepaper outlines the challenges facing financial services firms and how a new approach to enterprise integration can help banks and financial services firms not only survive, but thrive in an increasingly competitive future.
About Techcelerate Ventures

Tech Investment and Growth Advisory for Series A in the UK, operating in £150k to £5m investment market, working with #SaaS #FinTech #HealthTech #MarketPlaces and #PropTech companies.
bank API API led connect Open bank data Service System approach organization
About Techcelerate Ventures

Tech Investment and Growth Advisory for Series A in the UK, operating in £150k to £5m investment market, working with #SaaS #FinTech #HealthTech #MarketPlaces and #PropTech companies.
bank API API led connect Open bank data Service System approach organization
<p>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.  
 
</p>