API Strategy for Open Banking

Insights and case studies from leading open

banking experts and API strategists.

Nordic APIs
© 2018 - 2022 Nordic APIs
Contents

Supported by Curity . . . . . . . . . . . . . . . . . . . . i

Foreword: Embracing Open Banking . . . . . . . . . . . . ii

Preface: APIs Support the Open Banking Movement . . . v

The Premise of PSD2 And Open Banking . . . . . . . . . . 1

Open Banking: The Premise and Promise . . . . . . . . 2
What PSD2 Means For Banks . . . . . . . . . . . . . . . 3

6 Reasons to Embrace an API Strategy for Open Banking 4

1. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Improved Digital Agility . . . . . . . . . . . . . . . . . 5
3. Premium API Products . . . . . . . . . . . . . . . . . . 6
4. Increased Customer Satisfaction . . . . . . . . . . . . 7
5. Potential for Collaboration . . . . . . . . . . . . . . . 7
6. Wider Client Base . . . . . . . . . . . . . . . . . . . . 8
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Bring on the Players: Who Wins in Open Banking? . . . . 9

What Open Banking Really Means . . . . . . . . . . . . 10
Comply-first Providers . . . . . . . . . . . . . . . . . . . 11
Protectionists . . . . . . . . . . . . . . . . . . . . . . . . 12
Open-first Providers . . . . . . . . . . . . . . . . . . . . 13
Plotting the Opportunity . . . . . . . . . . . . . . . . . . 14
Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . 16
CONTENTS

Case Study: Nordea’s Journey to PSD2 Compliance, 300

Signups in 72 Hours . . . . . . . . . . . . . . . . . . . . 17
A World Beyond PSD2 Compliance . . . . . . . . . . . . 20
Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . 20

FinTech and APIs: Making the Bank Programmable . . . 22

What is FinTech? . . . . . . . . . . . . . . . . . . . . . . 23
Advantages of Exposing a Bank with an API . . . . . . . 24
Banks and FinTech Can Play Nice . . . . . . . . . . . . . 24
Use of APIs: In-Account App Marketplace Concept . . . 25
Data Transparency and the Rise of Open Banking . . . 26
New Platforms Lead to Unexpected Innovation . . . . . 27
More Advances in the Financial Sector . . . . . . . . . . 28
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 29

How Can Consumers Relate To Open Banking? . . . . . . 30

Building Context for Consumers . . . . . . . . . . . . . 31
Open Banking Must Foster Trust With End Users . . . . 33
Control Matters . . . . . . . . . . . . . . . . . . . . . . . 34
The Open Banking Marketplace . . . . . . . . . . . . . . 35
Final Thoughts: How to Establish Consumer Faith in
Open Banking . . . . . . . . . . . . . . . . . . . . 37

How Banks Are Becoming Uberized . . . . . . . . . . . . . 38

APIs are Nothing New . . . . . . . . . . . . . . . . . . . 39
Smartphones: Kindling a Change . . . . . . . . . . . . . 40
Time to API Up . . . . . . . . . . . . . . . . . . . . . . . 41
Building with Purpose . . . . . . . . . . . . . . . . . . . 41

How Does Open Banking Apply to US Banks? . . . . . . . 45

Regulation in Europe . . . . . . . . . . . . . . . . . . . . 46
Regulation in the US . . . . . . . . . . . . . . . . . . . . 47
The Role of the Market . . . . . . . . . . . . . . . . . . . 49
Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . 51

Case Study: From API Doing to API Thinking at ING Bank 52

CONTENTS

APIs versus Web Services: What’s the Difference? . . . . 53

API Doing vs API Thinking . . . . . . . . . . . . . . . . . 54
APIs and Customer Journeys . . . . . . . . . . . . . . . 54
Why API Doing is Equally Important . . . . . . . . . . . 55
From API Doing to API Thinking . . . . . . . . . . . . . . 57

Open Banking Amplifies the Need For Definition Driven

APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Adjusting Practices With The Shifting API Landscape . . 60
How OpenAPI Specification (OAS) Accelerates API De-
velopment . . . . . . . . . . . . . . . . . . . . . . 61
Supporting OAS Throughout the API Lifecycle . . . . . 62
Final Thought: Drive Open Banking API Strategies with
OAS . . . . . . . . . . . . . . . . . . . . . . . . . . 64

High-Grade API Security For Banks . . . . . . . . . . . . . 65

Regulatory Compliance Considerations . . . . . . . . . 66
Identifying Vital Data . . . . . . . . . . . . . . . . . . . . 67
Potential Vulnerabilities . . . . . . . . . . . . . . . . . . 69
API Security Methodologies . . . . . . . . . . . . . . . . 70
Security is The API Provider’s Responsibility . . . . . . 74
Recent Exploits and Breaches . . . . . . . . . . . . . . . 74
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Is OAuth Enough for Financial-Grade API Security? . . . 76

Can OAuth Make The Grade? . . . . . . . . . . . . . . . 77
Some Tokens Are Unbearer-able . . . . . . . . . . . . . 78
Away With The PKCEs . . . . . . . . . . . . . . . . . . . 79
Signed, Sealed, Delivered . . . . . . . . . . . . . . . . . 80
What’s Next For Financial Grade API Security? . . . . . 81

OpenID Connect: Overview of Financial-grade API (FAPI)

Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
What is FAPI? . . . . . . . . . . . . . . . . . . . . . . . . 83
Adding Resilience: The Read-Only Profile . . . . . . . . 85
Bullet-Proofing: The Read-Write Profile . . . . . . . . . 86
CONTENTS

Improving OAuth 2.0: JWT-Secured Authorization Codes 88

Decoupling Authentication: Client-Initiated Backchan-
nel Authentication . . . . . . . . . . . . . . . . . 88
Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . 91

Case Study: Growing Internal API Consumption in Danske

Bank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
The Path Towards APIs . . . . . . . . . . . . . . . . . . . 93
Set-and-Forget Performance . . . . . . . . . . . . . . . 94
Identifying Setbacks… and Addressing Them! . . . . . 94
The Results . . . . . . . . . . . . . . . . . . . . . . . . . 96
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 97

It Started With PSD2 and Personal Data . . . . . . . . . . 98

The Status Quo . . . . . . . . . . . . . . . . . . . . . . . 99
Regulatory Impact . . . . . . . . . . . . . . . . . . . . . 101
The Open Banking (and Data) Landscape . . . . . . . . 102
Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . 103

Nordic APIs Resources . . . . . . . . . . . . . . . . . . . . . 105

CONTENTS i

Supported by Curity

Nordic APIs was founded by Curity CEO Travis Spencer and has
continued to be supported by the company. Curity helps Nordic
APIs organize two strategic annual events, the Austin API Sum-
mit in Texas and the Platform Summit in Stockholm.
Curity is a leading provider of API-driven identity management
that simplifies complexity and secures digital services for large
global enterprises. The Curity Identity Server is highly scalable,
and handles the complexities of the leading identity standards,
making them easier to use, customize, and deploy.
Through proven experience, IAM and API expertise, Curity builds
innovative solutions that provide secure authentication across
multiple digital services. Curity is trusted by large organizations
in many highly regulated industries, including financial services,
healthcare, telecom, retail, gaming, energy, and government
services across many countries.
Check out Curity’s library of learning resources on a variety of
topics, like API Security, OAuth, and Financial-grade APIs.
Follow us on Twitter and LinkedIn, and find out more on cu-
rity.io.
Foreword: Embracing Open
Banking
by Eyal Sivan
It is with great pride that I write this foreword, for it is no exagger-
ation to say that Nordic APIs played a pivotal role in my journey,
which led me to dedicate my life to open banking.
The first time I ever heard of open banking was while presenting
at the Nordic APIs Summit event in Stockholm, where I met
Gunnar Berger from Nordea, featured here in this book. After
listening to him speak, describing large banks as battleships and
fintechs as speedboats, I discovered he had a curious title that I
had never heard of before: Head of Open Banking.
After speaking to Gunnar, doing some reading, and listening to
European politicians argue about PSD2 on YouTube, I became
immediately fascinated with open banking and its seeming con-
tradictions. Here was a situation where governments were the
ones driving innovation while market forces were slowing it
down, a situation where regulation was trying to reduce barriers
to entry instead of erecting them. In open banking, there seems
to be an attempt to create a financial system that is both more
competitive and healthier at the same time. In short, a better
way to handle money.
Upon further research, it became clear open banking activity
was taking place everywhere, not just in Europe. Moreover, re-
gardless of whether the approach being taken was driven by
regulation or by the market, the aim seemed to be the same:
to develop a common standard, enabling all the players in the
Foreword: Embracing Open Banking iii

financial ecosystem to communicate with each other seamlessly

and universally, acting as a foundation not only for great innova-
tion but also for the establishment of modern data rights.
So, what exactly does this common standard called open bank-
ing look like? If you are reading this book, you probably already
know that open banking standards are implemented as a set
of open APIs. Today, in most open banking implementations,
there are two main types of APIs: one to get information about
you or your banking activity and another to move money around
using payments. But that is just the beginning. Already, based on
those two basic functions, we are seeing moves into premium
APIs, data-driven aggregation, and AI-powered smart money.
Mature markets like the UK are seeing exponential growth in
usage. Despite some bumps in the road, open banking has al-
ready proven that a strong standard acting as a base can lead to
explosive innovation, increased competition, and a modernized
financial market. Make no mistake: open banking is here now,
and it is here to stay.
To those building the APIs that power open banking, understand
that you are building the future. The APIs you build will form
the digital economy’s roads and bridges, the bedrock of the
21st century. Your APIs will control how all of us trade, save,
and invest to build ourselves better lives. In this book, you will
find articles by some of the smartest open banking pioneers out
there, like Chris Wood, who was one of my early teachers. But
rest assured, much of this story has yet to be written, and much
of open banking has yet to be built. Perhaps you will be the next
one to add a piece of the puzzle.
Open banking appears to be a rare opportunity to raise all boats
if done right - a true nonzero-sum gain. Creating a common
standard for the financial services ecosystem means that: Con-
sumers win through better, cheaper, more innovative financial
products; governments win through effective regulation that de-
fends both competition and consumer data rights; technology
Foreword: Embracing Open Banking iv

companies, large and small, win because they can create and
build on open standards; and banks win (although many don’t
know it yet) because there is more banking activity overall. A
win-win-win-win.
Today, I am fortunate enough to hold the same title as my friend
Gunnar, Head of Open Banking, and I cannot help but smile at
the thought of it. Not merely because I have a good job at a
great company, but because it feels like I am helping to build
something bigger.
It is my distinguished pleasure to assist Nordic APIs in spreading
knowledge of open banking. I sincerely hope that you come
away from this book as excited as I am about the possibilities
of open banking and the open data future it makes possible.

– Eyal Sivan
Head of Open Banking at Axway
Mr. Open Banking
mropenbanking.com
Preface: APIs Support the
Open Banking Movement
by Bill Doerrfeld
Since Nordic APIs ran our first story on open banking and FinTech
in 2016, our writers have been carefully attuned to the world of
banking software architecture.
We’ve traced the EU’s Payment Services Directive 2.0 (PSD2)
regulation, and the rise of Application Programming Interfaces
(APIs) to help externalize personal data for end consumers. We’ve
also followed the modularization of banking components, as
valuable infrastructure becomes reusable through modern mi-
croservices designs.
Not only are financial institutions opening up with APIs to meet
global regulations, but innovative banks are finding success in
fully-fledged API-driven banking products, supplementing core
business models. Though there are many new opportunities,
banks must apply a keen strategy to accel in this new paradigm.
New entrants must be made aware of open banking pitfalls and
marketing gaps.
At Nordic APIs, we live for new strategies and technologies and
strive to introduce the benefits of API-first platforms to technical
and non-technical audiences. In our volume, API Strategy for
Open Banking, we compile our top articles on open banking from
the Nordic APIs writing team.
Within each chapter of API Strategy for Open Banking, a Nordic
APIs blogger digs into a niche aspect of open banking, covering
Preface: APIs Support the Open Banking Movement vi

PSD2, open banking benefits, developer experience tips, frame-

works for high-grade security and access management, and more.
We’ve featured best practices as well as case studies from our
conference speakers, who represent some of the largest open
banking initiatives in the world.
So, please enjoy API Strategy for Open Banking, and let us know
how we can improve. If you haven’t yet, consider following Nordic
APIs and signing up to our newsletter for bi-monthly blog up-
dates and event announcements. We also accept blog contribu-
tions from the community - if interested, please visit our Create
With Us page to submit an article.
Thank you for reading!

– Bill Doerrfeld, Editor in Chief, Nordic APIs

Connect with Nordic APIs:

Facebook | Twitter | Linkedin | YouTube
Blog | Home | Newsletter | Contact
The Premise of PSD2 And
Open Banking
by Thomas Bush

Open banking brings agility to modernize the finan-

cial sector

There’s a particularly apparent trend in today’s economy: we’re

moving away from large, centralized systems towards collabo-
rative, access-based ones. It’s changed the way we shop with
websites like eBay, the way we travel with apps like Uber, and
the way we get a good night’s rest with portals like Airbnb.
The Premise of PSD2 And Open Banking 2

One industry that’s been slow to change in this global movement

is banking, where it’s all the more critical. We still use massive
institutions, like JPMorgan Chase, Citi, and HSBC, to manage our
finances — and what’s more, we use them to manage all aspects
of our finances, from investment to insurance to mortgages.
However, it’s somewhat of a double-edged sword with banking:
we want the trustworthiness and reliability of a big bank, but
with the agility and innovativeness of a hundred startups.
The solution? — open banking.

Open Banking: The Premise and Promise

The premise of open banking is to put the power of financial

institutions in the hands of others. On the one hand, this means
increased transparency. It also means the development of APIs
to allow third-party developers to build their own financial ser-
vices and platforms using all the data and functionality that
banks usually keep to themselves.
While open banking may not sound so attractive for big banks
or the major payment service providers like Mastercard and
Visa, it’s mostly good news for everyone else. Consumers get a
better choice of financial services without sacrificing on security,
FinTech startups get to explore otherwise impossible ideas, and
governments get to tackle the issue of having large, hegemonic
financial organizations.
In fact, most governments in Europe — and even the European
Union itself — are already pushing for open banking. The UK has
its own Open Banking momentum while the EU has passed PSD2,
the second edition of the Payment Service Directive, which will
encourage APIs that “unlock customer data” and “enable con-
sumer choice.”
The Premise of PSD2 And Open Banking 3

What PSD2 Means For Banks

The original Payment Service Directive was enacted in 2007 to

regulate payment services across the European Union and en-
courage competition across borders. The revised edition — PSD2
— was passed in 2015 and shifts the directive’s focus from broad
safety regulation of the financial world to the development of
more innovative and transparent financial services.
So what exactly does PSD2 mean for European banks? To be
compliant with these new rules, they’ll have to implement a
significant amount of specific, robust functionalities, which will
ultimately require an overhaul of much of their technical infras-
tructure, including security concerns associated with doing so.
Fintech group Difitek compiled this PSD2 compliance checklist
for banks, which includes, among other things:

• An API function allowing users to grant others access to

their data
• An API authentication process which verifies both the
user and application
• API documentation, developer SDKs, code samples, and
tutorials
6 Reasons to Embrace an API
Strategy for Open Banking
by Thomas Bush

Outside of compliance, there are many business rea-

sons to adopt an API-first open banking.

Open banking is an initiative that allows third-party financial

services companies to access users’ banking data. The primary
goal of open banking is to put power back into the hands of
customers, enabling them to securely use third-party financial
products and services that rely on banking data or functionality.
Web APIs are the technology underpinning much of this new
ecosystem.
6 Reasons to Embrace an API Strategy for Open Banking 5

With the introduction of new regulations like the European Union’s

Second Directive on Payment Services (PSD2), many banks have
no choice but to open up, giving others access to their users’
data for not much in return… or so it may seem! In reality, there
are plenty of strong reasons for banks to embrace open banking,
with concrete financial incentives. Let’s look at six of them.

1. Compliance

Of course, the main reason banks are implementing open bank-

ing practices is compliance — or at least preparation for compli-
ance. While the European Union’s PSD2 is the best example of a
sweeping regulation that requires banks to share customer data
with third parties (this is known as X2SA — Access to Account),
it’s not the only one. For example, Hong Kong has its Open API
Framework, while Australia has the Consumer Data Right (CDR)
act. Other major jurisdictions are moving in the same direction:
the US Treasury has recommended the introduction of financial
data sharing regulations, despite the country’s hitherto market-
driven approach.
How it affects the bottom line: Of course, compliance isn’t
about driving additional revenue: it’s about staying in business.
Compliance improves profitability by avoiding unnecessary fines
and fees.

2. Improved Digital Agility

A major challenge of open banking is being able to share data

securely, quickly, and efficiently. As a result, many banks are
having to redesign their entire data architectures, often employ-
ing an API-based microservices approach to make data more
6 Reasons to Embrace an API Strategy for Open Banking 6

accessible. Greater digital agility, then, is both a necessity and

benefit of open banking.
In turn, improved digital agility has its benefits. Not only does
open banking improve security and transparency, but it also
makes it easier for banks to leverage their own data internally
— e.g., for service personalization or to create frontend applica-
tions — where it may have been impractical, or even impossible,
to do so previously.
How it affects the bottom line: An improved digital infrastruc-
ture enables data to be better used internally to improve the cus-
tomer experience, thereby increasing customer lifetime value.

3. Premium API Products

One particularly exciting benefit of open banking is the potential

to create new, revenue-generating API products with relative
ease. For an example, look no further than Nordea’s developer
program. Nordea used the open banking shift as a springboard
from which to create paid banking APIs for its corporate cus-
tomers. Offering API-driven payments, instant reporting, and
various foreign exchange tools, these “Premium” APIs go well be-
yond compliance, building on the hard work that was involved
in opening up their systems for open banking.
How it affects the bottom line: By developing and selling ac-
cess to new API products, banks are able to create additional
direct revenue streams. These premium APIs can also be used
as up-sells or cross-sells for other banking products (such as
certain corporate accounts).
6 Reasons to Embrace an API Strategy for Open Banking 7

4. Increased Customer Satisfaction

Open banking gives customers huge amounts of freedom as to

the number and scope of financial services available to them.
On the one hand, this appears to be a clear negative for banks,
as it allows third-party organizations to capitalize on user data,
where previously only they could. However, a greater selection
of financial service integrations — whether or not they are the
bank’s own — ultimately improves the customer’s banking expe-
rience, making them less likely to seek alternatives. As they say,
a rising tide lifts all boats!
How it affects the bottom line: Since the customer is more
satisfied with their banking experience, they are less likely to
look for alternatives. This increases customer lifetime value, im-
proving long-term profitability in a predictable way.

5. Potential for Collaboration

As mentioned earlier, open banking is designed to make it pos-

sible for third-party financial services companies to gain access
to customer data. If banks are willing to take this a step further,
they can actively assist these third-party companies in doing
so for a whole host of benefits. For example, banks can offer
additional functionality, dedicated support, or even develop-
mental collaboration to chosen third parties. In exchange, these
third parties can return the favor with various non-monetary
offerings, such as additional product functionality for the bank
in question or cross-branding.
How it affects the bottom line: By building collaborative rela-
tionships with third-party financial services companies, banks
are able to create unique value propositions and employ cre-
ative marketing strategies, thereby winning new customers.
6 Reasons to Embrace an API Strategy for Open Banking 8

6. Wider Client Base

Until now, we’ve focused on the benefits of sharing data with

others. However, it’s important to recognize that open banking
is a two-way street: in other words, it will allow banks to gain
access to user data from other participating financial institutions
(especially other banks). This creates a massive opportunity for
banks to create their own integration-based financial products
and services.

“Banks able to move fast to develop a modular busi-

ness and technical architecture can leverage their
brands to dominate parts of the value chain - whether
front, middle or back, while dynamically integrating
offerings and data from other players.” - PWC

How it affects the bottom line: Whereas banks could previously

only offer additional financial products and services contingent
on banking data to their own customers, they can now serve
customers of other banks, with the potential for significantly
more revenue.

Conclusion

It may be compliance that has pushed banks to invest in open

banking, but there’s no doubt that the movement has numerous
other benefits with tangible financial impacts. Many of these
benefits, such as direct improvements to customer satisfaction
and digital agility, result in increased customer lifetime value.
However, open banking also improves security, opens new doors
for collaboration, and allows banks to make bigger plays with
additional financial products and services of their own.
Bring on the Players: Who
Wins in Open Banking?
by Chris Wood

Simply being an API provider doesn’t guarantee an

open banking advantage.

It’s fair to say that the current noise around open banking is
almost deafening. We constantly hear about the potential of this
new market — driven by APIs — to change financial services
by increasing consumer choice, crushing incumbent banks, or
making a barrel of cash for a cool startup.
There is, however, more to open banking than hyperbole. The
opportunities and challenges – for the incumbent banks and
Bring on the Players: Who Wins in Open Banking? 10

“Fintechs” alike – offer a means to reshape an operating model

that has typified banking for many years. Equally, there are other
reasons for entering the market, such as legal or regulatory co-
ercion that will result in naturally cautious financially-regulated
entities being forced into becoming API providers with “open”
interfaces that need to be managed, maintained, and protected.
Standing on the cusp of this revolution, we, therefore, have
an evolving marketplace being shaped by both regulation and
market forces. The reaction to both of these is defining how
the protagonists are forging an open banking identity and the
behaviors that go with it.
In this post, we characterize the players in the Open Banking
market with three levels of action: Comply-first, Protectionist,
and Open-first. By understanding why providers are in the mar-
ket and what they expect to get out of it, we’ll get an idea of
how it might evolve in the future. We’ll find that merely being
an API provider in this market won’t be enough to guarantee a
competitive advantage.

What Open Banking Really Means

Open banking is first-and-foremost a means for increasing con-

sumer choice in financial services through regulation. You may
have thought that the phrase “open banking” means “open to
everyone” — a field day for the geeks who have longed to have
an API to populate their Warhammer budgeting spreadsheet
without all the nasty downloading of CSV files from online bank-
ing. Joking aside, what it actually means in its current form is
pretty far from that ideal. “Open” in this context is “open (via
an open API) to regulated entities” as defined by legislation like
PSD2 or the CMA Order. These regulations decree new roles in
financial services, which can be summarized in the term third-
party provider (TPP).
Bring on the Players: Who Wins in Open Banking? 11

Given this context, Open Banking implies API usage. However, it

supplies banking customers more rather than complete choice.
More choice means we, as customers, can work with a variety of
companies to help fulfill our banking needs. In the case of our
aforementioned geek, they’ll need to work with a TPP to help
them aggregate the data via APIs for their spreadsheet. Some
of these companies will be the organizations we already know
as our account providers. Others will be new companies that
provide products to make our lives easier. These organizations
can be characterized in one of three different ways:

• Comply-first Providers
• Protectionists
• Open-first Providers

Comply-first Providers

While regulatory deadlines like PSD2 have been approaching for

many years, many large banking organizations are still strug-
gling to meet their obligations. Comply-first providers are the
financial institutions who are being compelled to deliver on
these regulations to open up customer accounts to TPPs.
Banking as an industry has historically had limited forays into
the API economy, with a hesitation driven by their risk-averse
and project-driven corporate culture that typifies so many large
banks. Their API-related initiatives have largely been piecemeal,
with little cohesive drive towards API delivery and limited buy-
in or sponsorship from senior leadership to make being an API
provider a success.
This culture, which tends to result in delivering the bare mini-
mum through open APIs, means that these organizations are al-
ready playing “catch-up” both in their API delivery mechanisms
Bring on the Players: Who Wins in Open Banking? 12

and in the API economy at large. The first and most important
goal for comply-first providers is to meet regulatory deadlines
and avoid fines, penalties, or bad press.
An interesting side note that lends weight to this argument is
a report conducted by Paysafe. In Open Banking and PSD2: A
confused roadmap to innovation, they cite current impasses
in the landscape and the fact that banks “have had a mixed
approach to PSD2. The majority have treated it as an exercise
in minimum compliance rather than looking for customer-led
outcomes.”
Examples of such organizations are not hard to find. Some qual-
ities of comply-first providers include:

• Do not market their API.

• Have a boilerplate or no developer portal.
• In Europe, they only offer APIs that facilitate access to the
core PSD2 roles (Account Information Services Provider or
Payment Initiation Services Provider).

Despite their false start as an API provider, many of these orga-

nizations are also uniquely positioned in that they are directly
responsible or have a significant influence in shaping the market.
For example, the CMA Order in the UK made the nine largest
banking institutions directly responsible for the writing of open
banking standards. The largest incumbents, therefore, have a
huge amount of influence on the direction of the market.

Protectionists

Protectionists take a step up from Comply-first providers in at-

tempting to seize a slice of the pie as they meet their regula-
tory commitments. Their motivations, however, do not gener-
ally lean towards openness per se: Their goal is to protect what
Bring on the Players: Who Wins in Open Banking? 13

they already have by wooing their existing customer base. In

this guise, Protectionists often take up the TPP role, effectively
dogfooding their own APIs while taking advantage of their com-
petitors.
Examples of Protectionists in the market are found in the UK. Bar-
clays released an aggregation feature in their mobile app while
HSBC introduced Connected Money in May 2018. The premise of
both is simple — to offer existing customers account aggregation
features via their existing banking provider — and in doing so,
taking some of the heat out of customer demands for “shiny new
toys.”
The Protectionist provider, therefore, delivers just enough of
open banking, safely dipping a toe in the water in a risk-averse
manner while delivering on their regulatory commitments. They
can also influence their customers’ perceptions of open banking
by associating their first experience with the bank’s tooling. This
perception in a nascent market might prove highly beneficial to
Protectionists.

Open-first Providers

There are, of course, the players for whom open banking is the
reason they get up in the morning. Open-first providers are the
API consumers and providers who are at the bleeding edge of
open banking, looking to take advantage of or exploit opportuni-
ties in the new market. Most of the open-first protagonists carry
the “FinTech” label, but that’s not to say they have to. There
are the new kids on the block — the likes of the Starling Bank
— who are opening developer portals to be at the forefront of
Open Banking as a banking services provider. Established banks
like Nordea are also taking a plunge into this market, with or
without the major standards wrappers like UK Open Banking or
the Berlin Group Standards.
Bring on the Players: Who Wins in Open Banking? 14

Of course, the consumers of the APIs, the Account Information

and Payment Initiation Service Providers (AISP/PISP) enshrined
in the PSD2 regulation, are the big news as they directly interact
with real human beings. Aggregators like Yolt, who was the first
AISP to connect to CMA APIs in the UK, are making waves in the
marketplace. Likewise, Zopa is bolstering its offering by using
open banking data to help consumers prove their income when
applying for a loan.
Whether an API consumer or provider, Open-first providers have
some tough challenges in the market:

• As consumers of open banking APIs they need to deliver

products that are so good they become a byword for in-
novation in the banking space and offer a credible, con-
venient alternative for customers to their existing bank.
They are also — to a certain extent — at the mercy of the
Comply-first providers, as they have a dependency on the
availability of their APIs.
• API providers need to deliver APIs that allow them to dif-
ferentiate their product set and make them attractive to
consumers. It’s more than just providing the regulatory
minimum; it adds value by offering features that drive con-
sumers.

Given the size of the challenge, it’s no surprise that Open-first

protagonists are coalescing into organizations like FDATA, to give
them greater clout against the incumbents.

Plotting the Opportunity

Looking across the players, the diagram below shows where

they sit in the current state of the market in terms of both their
influence and the opportunity available to them:
Bring on the Players: Who Wins in Open Banking? 15

The ideal in this diagram (without trying to be too much like

Gartner) is to be in the top-right quadrant i.e., influential and
with a great deal of opportunity. In this context:

• The Comply-first providers will need to extend their initial

offerings to bring new, API-powered open banking prod-
ucts and services to the market to add competitiveness to
their offerings. In doing so, they should look to leverage the
qualities of their organizations that make them successful
– for example, the enormous amount of collateral they hold
or their ability to acquire or clear a variety of currencies.
• The Protectionists will need to leverage their position as
a both a TPP and API provider to differentiate their services
by offering them outside their existing customer base –
holding a current account should not be the only criteria
for entry. These organizations are also uniquely positioned
given their duel role of TPP and API provider.
• The Open-first providers need to carry on doing what
Bring on the Players: Who Wins in Open Banking? 16

they do best: innovating, moving quickly, and delivering

great products that delight their customers and enhance
their reputation. By producing killer apps and experiences,
they become synonymous with what’s innovative in open
banking.

Final Thoughts

Open Banking still has some way to go before the market reaches
anything near a state of maturity. In its current guise — with
multiple technical standards being developed and APIs coming
into the market all the time — it’s hard to see exactly how it will
develop. The key activity for many has been all about regulatory
compliance. So, when all the banks become API providers, what
happens next?
The most likely scenario is the Comply-first, and Protectionist
players will realize how big the opportunity really is. By provid-
ing APIs, they have already begun the transition to becoming
banking service providers. If they accept that as their raison
d’etre and accept that APIs can be used as a means to deliver
on their strengths, the developments in the next phase of open
banking could be positively seismic.
Case Study: Nordea’s
Journey to PSD2
Compliance, 300 Signups in
72 Hours
by Thomas Bush

The financial industry has opened up, to much Fin-

Tech excitement.

For most, Nordea needs no introduction. As one of the biggest

banks in Europe and the biggest bank in the Nordic region,
Nordea serves over 10 million private customers. Of course, like
all other European banks, Nordea is subject to PSD2 regulations.
Case Study: Nordea’s Journey to PSD2 Compliance, 300 Signups in 72 Hours 18

Gunnar Berger, Head of Open Banking at Nordea, told the story

of their journey to PSD2 compliance at our 2017 Platform Sum-
mit in Stockholm, Sweden.
Nordea was one of few European banks that chose to take a
proactive approach to compliance. PSD2 was coming whether
they liked it or not, and as Gunnar was well aware, Nordea is “sort
of a supertanker when it comes to changing course; — it takes a
while,” so when it came to building an open banking platform,
they were going to do it well and in good time. Development on
their PSD2 open banking platform began in Autumn 2016.
As with any behemoth project, Nordea was bound to run into
some problems while building this platform. In this case, the
issue was trying to balance the very real requirement of basic
legal compliance with the desire to build new opportunities.
Since developers would pick innovation over compliance any
day of the week, the open banking team slowly started falling
behind on the main aim of their project: to make Nordea PSD2
compliant.

No Presents This Year

Come Christmas, Gunnar realized it was only a year until the re-
quirements for PSD2 had to be fulfilled — or so he thought. With
that in mind, he asked his development team to focus just on
the compliance aspect of their new open banking infrastructure,
setting aside the more creative work.
While this wasn’t much fun for the developers, it got the project
back on track and meant that Nordea could start looking for
beta testers from February of 2017. Without giving it too much
thought, they published a signup page where external devel-
opers could apply for early access, expecting to get only a few
signups. Who would want to test out the boring new legal stuff,
anyway?
Case Study: Nordea’s Journey to PSD2 Compliance, 300 Signups in 72 Hours 19

Within 72 hours, the page had garnered 300 signups, with devel-
opers both big and small leaving enthusiastic comments about
what they wanted to build with the platform. Supposedly, Nordea
was the only bank communicating with the Nordic FinTech world
at the time, although by this point, the “communication” was
limited to just a signup form.

The Results Are In…

By the time signup closed, 700 applications were tallied. Clearly,

FinTechs were much more interested in the possibilities of open
banking than had been anticipated — and this was evidenced in
just one of the hundreds of banks trying to meet compliance.

“Now we had created an expectation in the market

— not that we will deliver some really crappy compli-
ance APIs by the end of this year — an expectation of
something much more.”

It was only right that Nordea matched the enthusiasm of the

applicants, and so they created blogs and newsletters, met up
with developers, and decided to let everyone access the plat-
form. Needless to say, this stirred up even more excitement
and helped Nordea gauge — with minimal investment — the
feasibility of developing their open banking platform beyond
basic compliance.
Thankfully, they had realized by now that they had until late
2019 to meet the technical requirements for PSD2, and so by
now, Nordea could even begin collaborating with 3rd parties on
more innovative aspects of the project.
Case Study: Nordea’s Journey to PSD2 Compliance, 300 Signups in 72 Hours 20

A World Beyond PSD2 Compliance

With this huge influx of enthusiasm and now great expectations

for the platform, Gunnar’s vision changed completely. This was
the perfect medium to connect an old, big bank with nimble and
innovative FinTechs.
It was the open banking system that could leverage Nordea’s
huge client base and reliable infrastructure against the FinTechs’
brains and fast footedness. It would allow FinTechs to put their
products in the hands of ordinary people — not just the young
or tech-savvy — without having to spend millions of euros on a
sales team.
The vision for what was previously a PSD2 compliance platform
is now to create an open banking marketplace — or perhaps an
even more universal developer platform. Gunnar wants to work
with third parties across the ecosystem, with partners not only
using the new solutions but also creating them or even creating
the APIs needed to create them!
If you’ve ever wondered how big banks will stay relevant into
the future, now you know. Instead of doing the very minimum
to meet legal requirements, Nordea opened up access to their
platform early, collected feedback, and then decided to dive in
with both feet when they saw an opportunity.

Final Thoughts

Open banking is allowing financial services to extend into a

comprehensive network of services. The world of banking may
no longer be closed behind locked doors, operating separate
to all other technology — and is there anything really stopping
banks like Nordea from expanding their open banking hub into
a flexible, cross-industry development platform?
Case Study: Nordea’s Journey to PSD2 Compliance, 300 Signups in 72 Hours 21

Even banks not legally affected by PSD2 might benefit from

building similar development platforms, as they’ll be able to
stay relevant into the more dynamic, universal service markets
that Gunnar predicts. In an age of endless consumer electronics
and worldwide interconnectivity, it’s no wonder that banks are
starting to redefine themselves as technology companies.
FinTech and APIs: Making
the Bank Programmable
by Bill Doerrfeld

Making the bank programmable is a win-win-win for

banks, developers, and end consumers.

Banking institutions are usually portrayed as monoliths, slow

to change even amidst obsolescence and new technological
advances. This won’t be for long, as the financial sector is becom-
ing increasingly open and programmable.
Even large US banking institutions like Citigroup, BBVA Compass,
Bank of America and Capital One acknowledge the benefits of
opening internal systems for third-party developers to integrate
into new apps. And, as alternative banking services like Simple
FinTech and APIs: Making the Bank Programmable 23

or Holvi emerge, we are seeing more of a diversity of services

that embrace new consumer expectations brought on by the
Internet and mobile devices.
In this article, we tune into FinTech experts to hear what organi-
zations like Fidor, the Open Bank Project, and others did to lead
the banking revolution. We’ll find that we’re moving toward a
new financial market of customer choice, third party services,
and open data — all powered by APIs. Essentially this means
making the bank programmable.

What is FinTech?

FinTech stands for financial technology; a broad sector of inno-

vative and emerging financial services. Examples include crowd-
funding platforms like Kickstarter, new online-based currencies
like Bitcoin, virtual wallets, micro stock investment apps like
Robinhood, account aggregation and analysis services like Per-
sonal Capital, payment splitting services like Splitwise, mobile-
optimized peer-peer payment transfer apps like Venmo — the
list goes on.
Replacing paper checks, physical charities, paper money, and
even investment firms, FinTech services are suitable to the digi-
tal times we are living in now, and are shaking existing banking
infrastructure and international financial systems.
According to Stefan Weiss, head of APIs at Fidor:

“The customer expects a different behavior from ser-

vice companies, and banks, somehow, are stuck in
the last century, and the movement of money is stuck
in the last century.”

Weiss sees the Fintech craze as not simply a short-lived phe-

nomenon. The technologies being developed now are going
FinTech and APIs: Making the Bank Programmable 24

to have everlasting impacts on the future financial and bank-

ing industry, and institutions need to adopt change or face de-
struction. FinTech activity is international but very apparent in
London, where FinTech venture capital investments are hitting
record highs.

Advantages of Exposing a Bank with an

API

APIs are yet again another vital cog driving disruption, now fu-
eling FinTech startups and open banking data initiatives world-
wide. According to Weiss, Fidor decided to build their banking
platform with a community of third party developers in mind for
the following reasons:

• A bank API allows the end-user to have a quicker onboard-

ing experience.
• An API enables a bank to acquire partners that specialize
in niche FinTech services with optimized front-end user
interfaces.
• A bank API allows seamless integration with crowdfund-
ing platforms, payment splitting apps, and more — great
for startups with innovative financial-oriented products
that may lack the budget and legal counsel to hold funds
or establish their own bank.

Banks and FinTech Can Play Nice

Weiss stresses that banking licenses are tough to acquire. Even

smaller legal licenses to transfer payments or handle credit,
likely needed to start a FinTech, are difficult to mitigate for most
FinTech and APIs: Making the Bank Programmable 25

small developer teams unfamiliar with the many laws that regu-
late these handlings. Banks can provide this knowledge via APIs
and partnerships to help FinTech companies excel, especially
those who are creating APIs themselves.
Banks need to create well-designed, standardized APIs, along
with self-serving adoption processes complete with documenta-
tion, sandboxes, simulated account structures, and more to get
in the hands of developer users quickly. Onboard more partner-
ships and make it cheaper for FinTech startups to launch, and
you’ve got a recipe for a banking API success.

Use of APIs: In-Account App Marketplace

Concept

Weiss recognizes a long term goal for Fidor is leveraging their API
to allow developers to create add-on services in a marketplace
format, enabling the end-user to customize their banking expe-
rience. The idea is that a bank can provide an API and open app
store (i.e. appstore.mybank.com) and pair apps with specific
accounts. Win-win-win. Banks can acquire new partners, third
party developers bring innovation, and customers are empow-
ered with more choice and customization. It’s true that for banks,
building an application manager is no easy task, however, but
API management solutions exist to aid this process.

“Just because you can offer an API for something

doesn’t mean that you have to offer an API for some-
thing. APIs are products, have to be handled as prod-
ucts. You must have a customer, and a reason for the
customer to buy the product”

Weiss admits that even though their full production API is mak-
ing 30,000 requests daily, the team consistently strives to reit-
FinTech and APIs: Making the Bank Programmable 26

erate their product, tuning into the customer and considering

“what is a beautiful API?”

Proof of Concepts

Open Banking Project is a separate organization striving to rein-

vent how banks handle their data. The Open Bank Stack, written
in Scala and running on the JVM, is secured with OAuth and
is a “semantic API vertical for the banking space”. They’ve had
numerous FinTech apps developed that tap into their API ser-
vice. Examples include Savetastic, which pulls data from a bank
to calculate potential savings, and Social Finance application,
which enables account users to choose who they want to share
account data with.
In a session with Nordic APIs, Simon Redfern, Founder and CEO
of Open Bank Project, even demonstrated The Singing Bank,
which produces varying tonalities associated with withdrawals
and deposits. Combining FinTech with musical composition —
now that’s a tough act to follow.

Data Transparency and the Rise of Open

Banking

From timestamps to transaction IDs, banks collect enormous

amounts of data. In fact, it was this information that led the Fidor
team to consider how it could be used to create a better bank.
To Redfern, “better” means more open, more transparent, and
less corrupt. Apathy in companies perpetuates distrust, which is
bad for society in general. With the philosophy that transparency
can increase empowerment, Simon was inspired to reevaluate
how banks handle and expose their data. Could company bank
accounts be open for everyone to see? What if all personal bank
FinTech and APIs: Making the Bank Programmable 27

holdings were open for the public eye? How could this data be
used programmatically to create new, ethical services?

New Platforms Lead to Unexpected

Innovation

What’s the similarity between a violin and a smartphone? In a

session with Nordic APIs, Redfern, a composer at heart, argues
that they’re both platforms.
A violin and iPhone are both standardized interfaces. Yet, stan-
dardization doesn’t inhibit musical creativity any more than the
current smartphone design channels app developer curiosity
and innovation. With platforms, weird things can happen, such
as a rising class of Instagram entrepreneurs in Kuwait using the
platform to sell their sheep. In FinTech, the idea is that an open
standard API could revolutionize banking with unprecedented
consequences.
Xignite CEO Stephane Dubois acknowledges that:

“The role of technology in advancing the financial

service industry is more critical than ever before. The
use of APIs by today’s banks is becoming increasingly
common as they help to drive speed and cost-effec-
tiveness compared to traditional legacy systems.”

Just as Facebook and other social media giants have become

platforms, Redfern believes that banks will inevitably become
platforms as well. The idea is that banks can push innovation
and allow developers the ability to create brand new products,
and the Open Bank Project can allow banks to easily adopt an
API. To Redfern, open banking is made up of four distinct facets:
FinTech and APIs: Making the Bank Programmable 28

• Open standards
• Open Source
• Open data options
• Open innovation

“APIs are great for abstracting away aging IT systems

which are barriers to innovation….We think banks
need to open up their infrastructures, and they should
be developing ecosystems so they can better respond
to their customers and so they can compete better in
the market”

It’s been proven that customers are interested in using new en-
trant services rather than their own. According to the Millenilal
Disruption Index, “71% would rather go to the dentist than listen
to what banks are saying” — proof to some that the industry is
ripe for “seismic” change.

More Advances in the Financial Sector

We find many accounts that the FinTech industry is growing at

an enormous rate. Further indication that people desire alter-
natives to the politics of brick and mortar banks, Bitcoin has
altered the state of the monetary conversation on a fundamental
level. As Weiss puts it:

“Bitcoin changed many things. It changed the con-

versation, it changed technology, because Bitcoin is
more or less an internet payment system that is much
more suitable to the times we are living in now, than
banks, credit cards, interchange fees, etc. It really
shook the foundations of international payment streams.
It opened a discussion on security as well, and what
FinTech and APIs: Making the Bank Programmable 29

internet protocols are capable of… Probably in 50

years from now, there will be no reason for a bank
anymore.”

Weiss acknowledges that what banks actually can do today is

regulate and certify trust and knowledge about financial trans-
actions. If banks wish to remain competitive, many argue that
through opening up APIs to outsiders, they can form new ecosys-
tems that encourage innovative product creations and new end-
user experiences.

Conclusion

To put it simply, making the bank programmable is a win-win-

win.
For developers, they get to mess around with the power and
knowledge of banks to create innovative services and terminate
compliance issues.
For end-users, they can experience a new breed of services that
tie into their accounts. Politically, it could be argued that open
banking transparency could decrease corruption.
For banks, they open new revenue streams by monetizing part-
ner resources and experience increased customer satisfaction.
So, why not make the bank programmable?
How Can Consumers Relate
To Open Banking?
by Chris Wood

92% of consumers haven’t heard of open banking. So

how do we make them care?

Open banking has garnered a lot of attention recently. With the

introduction of UK open banking and Payment Services Direc-
tive 2 (PSD2) becoming law across the European Union, regula-
tions are fundamentally altering the way banks handle personal
data. The movement is also not restricted to Europe, with regula-
tors in the USA having released their intentions in October 2017
on access to bank accounts.
How Can Consumers Relate To Open Banking? 31

Open banking promises a revolution in how we consume finan-

cial services products. At the heart of the paradigm shift is APIs
exposed by financial institutions. These APIs allow us to share
access to our accounts with apps and platforms of our choice.
We might, for example, choose to securely share financial data
with an app that gives us an aggregated visualization of our
finances, helping us better plan our lives. Alternatively, we may
choose to take advantage of payment initiation direct from a
checking account and use this from an online accounting pack-
age. Opening banks with standardized APIs will alleviate a lot of
friction between financial services.
However, most end consumers don’t even know this great trans-
formation is occurring. There is a sense in the media — in the
UK, at least — that open banking is a “quiet revolution”. A recent
survey conducted by the consumer organization Which? found
that 92% of consumers had not heard of open banking. Of
those surveyed, 51% were unlikely to share their account infor-
mation with third parties. Mainstream media outlets, including
The Guardian, also question the concept as a whole. They cite
concerns over fraud and liability once data has been shared.
Given the huge investments made in open banking across the
EU, how can technology providers and legislators bring open
banking up the consumer agenda and make it more than just
some clever enabling technology?

Building Context for Consumers

The greatest challenge the open banking initiative faces is break-

ing down the technology barrier. Open banking is usually linked
with the technology that makes it possible, including the relative
merits of APIs over the practice of screen scraping. This fact
foists the enabling technology front-and-center and, in many
cases, makes the protagonists focus on it rather than the solu-
How Can Consumers Relate To Open Banking? 32

tions open banking makes possible. Instead, we need simple

use cases and explanations to help set a context for end users.
An example is the European Banking Authority’s publication of a
video guide on the disadvantages of screen scraping. While tech-
nology is an important part of the debate for the technologist,
the regular consumer will simply want to know: What’s in it for
me?
Answering that question is not always at the forefront of the
debate. Generally, those involved seek to profit, disrupt, or regu-
late financial services, and their message is tailored accordingly.
Obviously, those who seek to profit — by providing the apps
and services that leverage open banking — want to paint a con-
sumer-focused picture. For others, it’s not so straightforward.
For example, the European Union message on PSD2 focuses
on delivering choice and flexibility in how customers access
financial services and who they choose to access their account,
regardless of who they bank with. However, there is a subtext
that introducing payment initiation services direct from a con-
sumer’s account may break the hegemony of Visa and Master-
card in payments. Recent research tends to support a decline in
card payments in a post-PSD2 world.
This introduces a significant issue, namely: How can PSD2 — or
any open banking scheme — engineer a payments “network”
in a few short years and foster the same trust, reliability, and
security that Visa and Mastercard promise? The advantage the
payment networks have at the moment is that they “just work”.
This is juxtaposed to the fledgling open banking solutions that
are composed of many moving parts.
How Can Consumers Relate To Open Banking? 33

Open Banking Must Foster Trust With End

Users

The possible journeys for customers to authenticate themselves

to pay from their bank vary from one implementation to the
next, with many banks forcing a user to use a physical passcode
device. Such journeys are likely to involve redirection to online
banking with multiple brands; for example, a merchant, the
bank themselves, and possibly an aggregator providing PSD2-
compliant payment services that a consumer may have never
heard of.
By this rationale, what is open banking really giving consumers
other than the perception of greater risk and a more fragmented
customer experience? For it to resonate with consumers, open
banking needs to be marketed by its champions as more
than just a technology solution. It needs to be successfully
evangelized with the message refocused in several ways:

• Emphasis user control: The technology slant needs to

take a back seat, and the protagonists instead focus on how
consumers are at the heart of open banking, controlling
access to their accounts on their own terms.
• Evangelize great use cases: The champions of open bank-
ing need to evangelize how the technology allows con-
sumers to unlock the potential of banking services from
a myriad of different providers. Focus on how consumers
can start to take advantage of the account data that — in
the EU at least — *they legally own**.
• Ease any doubts regarding security: Finally, they need
to imbibe consumers with trust in the approach and con-
fidence of the solutions built on open banking.

Doing all of the above will have significant effects on the current
How Can Consumers Relate To Open Banking? 34

open banking approach. They are also likely to have long-term

benefits that far outweigh the cost of addressing them.

Control Matters

Many of the concerns expressed by consumers focus on who can

access their account. These include:

• How do I give access to my accounts?

• Who should I trust?
• How do I stop third parties accessing my account?
• Who is held responsible if there’s a problem?

These concerns expose a structural issue with how open banking

is manifested. It models itself on the infrastructure that under-
pins it — the internet and a collection of APIs. This decentralized
and dispersed model means that consumers lack a cohesive
view of what they have consented to. In most implementations
that are either live or planned, this information is siloed across
multiple repositories and is likely hosted in online banking plat-
forms.
Without this centralized element of control, the user is forced
to aggregate this information by hand, which is inconvenient,
impractical, and makes understanding harder. To foster trust in
open banking, the underwriters of the schemes across the world
will need to address this by providing schema-sponsor facilities
to allow citizens to see and manage what they have consented
to clearly. Enabling this comes in two forms:

• A digital identity scheme: Already present and very suc-

cessful in many countries, a standardized digital identity
can be used by consumers to attest who they are when
How Can Consumers Relate To Open Banking? 35

consenting to account access, binding each consented ac-

tivity with a common identifier. The Nordics provide great
examples of the success of digital identity. For example,
over 60% of the population in Sweden use BankID as a
means of digitally proving who they are.
• A means for consumers to collate and manage consent
in a cohesive way: This either means a centralized repos-
itory or — more practically — a network that allows con-
sumers to manage consent from a repository they own. A
personal data store would provide the perfect vehicle for
this.

Lastly, high-grade API security is paramount for open banking

to thrive. Delegated authority protocols like OpenID Connect
and it’s financial services extensions being built by the OpenID
Foundation will help build faith for the technophiles in the so-
lutions that underpin open banking. However, for the average
consumer, security means control and the subject control needs
to be addressed for open banking to be successful.

The Open Banking Marketplace

The flipside of control for consumers is building trust in the third

parties that access their accounts. Understanding the role an
app takes in your financial ecosystem should not be an act of
blind faith.
Take the UK open banking initiative as an example. All inte-
grators are businesses regulated by the Financial Conduct Au-
thority (FCA). If a consumer wants to check if an organization
is registered for open banking, they need to look them up on
the FCA register — an impenetrable mechanism even for those
that know what they’re looking for. This offers little convenience
How Can Consumers Relate To Open Banking? 36

to the consumer. Compare that to a payment card in a bricks-

and-mortar shop. The customer needs to do nothing to check
the merchant’s status other than put their faith in the Visa logo
displayed in the store.
For open banking schemes to build a perception of trust for
consumers, they could create some “signage” — markers that
help consumers easily recognize the status of any organization
professing to integrate with their account via open banking.
Such markers might include:

• An open banking kitemark would be a quick indicator that

a third party is legally registered for open banking. The
implementation of this requires some thought, of course,
given how easy it is to spoof websites, URLs and images on
the internet. However, with the right construct, this could
not only boost consumer confidence but also add an open
banking brand that helps foster a scheme’s identity in a
given country.
• An easily accessible directory of open banking participants,
designed with consumers in mind. This may be the finan-
cial services equivalent of the UK Checkatrade website
intended for finding tradespeople.
• The development of an open banking marketplace that
extends the directory idea and brings together all the so-
lutions that use the open banking APIs in a searchable,
consumable way. This has benefits for the consumer, who
can easily search for and consume offerings from different
providers in one place. It also would benefit providers,
who get an accessible shop-window for their wares. This
also benefits the regulators of any open banking scheme,
as they can easily assess, monitor, and certify solutions
entering the marketplace.

If the open banking schemes can co-create a semblance of fron-

tend signage, it could help foster the open banking mission.
How Can Consumers Relate To Open Banking? 37

Final Thoughts: How to Establish

Consumer Faith in Open Banking

Open banking represents a significant opportunity for many

parties in financial services. The large incumbent banks can
differentiate their offerings. Fintech will benefit massively from
APIs created expressly to access accounts. Regulators across the
world will shake up the hegemonistic practices of large incum-
bents in financial services.
However, this promise will only be realized if consumer concerns
on trust and security are addressed. Open banking needs to be
marketed by its champions so that consumers understand what
the technology actually means for them. This is important for
right now — for building trust in consumers as they start to use
solutions that integrate with open banking. But it is doubly im-
portant for the future, as the services offered to expand and the
opportunities grow. If this can be achieved, then open banking
just might cause the financial services revolution it promises.
How Banks Are Becoming
Uberized
by Thomas Bush

As banks treat their assets more like products, mono-

lithic infrastructure is decomposing into an amalga-
mation of reusable components.

You’ve probably heard the whole “banks are becoming tech com-
panies” sentiment. The “X are becoming tech companies” idea
has been around for years, and used to depict the uberization of
various industries. It captures evolution in the way we consume
and use everything; from food to money. As consumers, we want
options at our fingertips, and perhaps it’s this forcing banks
across the world to open up their services with APIs and mi-
croservices, and ultimately turning them into tech companies.
How Banks Are Becoming Uberized 39

In a previous role, Eyal Sivan was Senior Director of Enterprise

Architecture at the Canadian Imperial Bank of Commerce (CIBC).
At our 2018 Austin API Summit, he told the story of how and
why one of Canada’s Big Five adopted an API and microservice
architecture.

APIs are Nothing New

Another statement you’ll have certainly heard is that APIs are

“nothing new,” which is true. Eyal acknowledges this — APIs
have been around since the ’70s — but back then, enterprise
architecture could be described by a single, dreaded word…
monolithic.
Monoliths were big and bothersome. As Eyal says, “sometimes
they were on mainframes that filled entire buildings, and you
would speak to these things however you could speak to them.”
More an artifact of early digitization than anything else, mono-
liths had too many interfaces, systems kept breaking down, and
were thus costly to maintain.
Enter the ERP, or Enterprise Resource Planning solutions. These
were proprietary building blocks that you could use to cut up,
package up, and clean up your “spaghetti” (as Eyal so affection-
ately remembers it). Needless to say, arbitrarily boxing up code
didn’t really add much to the systems architecture; ironically, it
ended up costing more.
Next came the EAI, or Enterprise Application Integration. While
this was an improvement over the ERPs thanks to a slightly
more standardized framework, it still fell short in time — fixing
none of the problems but being equally expensive and equally
proprietary.
Finally, Service-Oriented Architecture (SOA) rolled around. The
industry now had a standard for API contracts, and with the in-
How Banks Are Becoming Uberized 40

troduction of an enterprise service bus, each piece of the puzzle

could be connected, albeit indirectly. However, as the service
bus inevitably began to take on more logic, it grew big and messy
in the same way an EAI would.
Part of the problem was everyone interacting with the enterprise
service bus in their own way. So, the next step was to federate
the different schools of thought and give each party their own
domain service bus, which could contain whatever logic and
follow whatever rules, while still connecting to the main service
bus.
Finally, there was a system that worked well for everyone…

Smartphones: Kindling a Change

…that is, until smartphones were invented — completely chang-

ing the way we interact with IT services. Consumers now had a
device that could perform any digital action from everywhere.

“Everything changed. Suddenly people could order

a taxi, a hotel room, a pizza, with a couple of taps
on their phone. And consumers expected exactly the
same kind of interaction from everyone they do busi-
ness with, probably most of all the banks.”

This changed the landscape of software development forever.

Cost was no longer the deciding factor — speed was. Developers
now wanted to create flexible software: easy to maintain and
easy to upgrade.
To Eyal, the obvious solution was to break things apart, replacing
every monolith with a whole suite of APIs and microservices
which could be worked on individually.
How Banks Are Becoming Uberized 41

Time to API Up

Once it was clear that an API and microservice architecture was

the one to pursue, the bank pulled out their wallet and went to
market. As Eyal explains, buy-over-build was the natural posture
at a bank with plenty of money.
Analysts soon discovered that there were no leading solutions in
the field, even after exploring the open-source projects, which
are usually at the cutting edge of any new technologies. So CIBC
took the bold decision to build.
They started with an open-source core — the Light framework
— before employing the owner of that project around whom to
build an entire team. With this, they created an API Foundation,
and shared it amongst stakeholders to review. While analysts
unanimously agreed that the documentation “sucked,” the plat-
form was something new — and it held up to tests extremely
well.
Eyal justifies the decision to build their own solution with three
reasons:

• It hedges against an incredibly volatile market.

• It allows you to steer the direction of your platform (in this
case, it was CIBC’s only solution for supporting GraphQL).
• It cultivates critical development skills (OAS, Swagger —
now OpenAPI, DevOps, daily releases, automated testing/de-
ployment, and so and so forth).

Building with Purpose

The decision had been made. CIBC was going to build their own
microservice and API architecture, and now it was time to get
How Banks Are Becoming Uberized 42

work. But before they could do so, they’d need to establish their
guiding principles — among other things — Eyal explains.

Guiding Principles Come First

Every organization has its own priorities, so there’s no one-size-

fits-all approach to building any kind of network architecture —
this is another advantage of developing your own solution.
With that in mind, you need to establish your guiding principles
before you get going. The dichotomy Eyal focuses on is prolifer-
ation versus standardization and governance. That is to say, do
you value a solution that’s easy to build upon (with, say, adding
new functionality every day), or a solution that’s well-kept and
easy to maintain?
For the record, the right principle is probably somewhere in
between.

The Goal Product

Next up, it’s important to appreciate the nature of the product

goal. Eyal stresses that they did not build a “magic box” that
takes care of everything, which would be a modern repackaging
of SOA that eventually hits a wall.
Instead, they took a distributed gateway approach to embrace
microservices — the “secret sauce.” Let’s note here that while
you might be able to package all the same functionality into a
monolithic mainframe and expose that with APIs (which would
be significantly simpler), you’d then stuck with no space to grow.
CIBC then took the microservices and gave each one an em-
bedded gateway. That way, the microservices can act and be
managed independently from one another in every aspect, from
security to analytics. There’s no blanket ban on centralized gate-
ways, but let them be used for the stuff that really is centralized.
How Banks Are Becoming Uberized 43

According to Eyal, the rise in popularity of these architectures, or

service meshes, could worsen volatility — yet another reason to
cultivate development and management skills in-house.

CIBC’s Service Mesh Plus

Aside from the embedded gateways, CIBC has purpose-built

plenty more features into their service architecture to make
things as smooth-sailing as possible — hence the label of Service
Mesh Plus.
For one, they’ve chosen to move away from the typical homoge-
nous mesh (where each user shares the same mesh), including
a series of light proxies and routers to improve compatibility.
What’s more, they’re looking to implement federated authoriza-
tion — a trusted network across OAuth servers. ##Acting Like a
Tech Company While some of these things might seem foreign to
you, Eyal notes that doing APIs and microservices the right way
forces you to act like a tech company. That is “the critical skill
here; treat your assets more like products.”
The uberization of banks is coming, so acting like a tech com-
pany is “the shift for banks to survive,” he goes as far as to say.
That’s presumably why Eyal’s not afraid to share how far CIBC
has come in that regard:

• The API Foundation is used across the bank, with a gover-

nance council mandating its use — unless there’s a good
reason not to.
• There’s a managed container environment with a develop-
ment network already in place.
• They’ve created an adjacent developer training program,
with the goal to create an internal community around the
platform.
How Banks Are Becoming Uberized 44

• There’s a pilot of the API marketplace available today, with

a self-serve model allowing developers to use the API with-
out a single meeting or call (allowing cost savings of 50-
70% per integration). ##Eyal’s Tips for Your API Platform
Here are some of Eyal’s tips for building your own high-
yield API platform, with the fantastic metaphor of a brick-
and-mortar building:
• The four pillars: Developing a powerful network is a bal-
ancing act. Grow your API, cloud, DevOps, and agile strate-
gies together to keep things running smooth.
• The foundation: Your solution needs to be built onto a
solid foundation, which runs from your technology and
operations team, through the company’s organizational
structure, down to corporate values and culture. Can you
convince bank officials that innovation is the right focus to
have?

Eyal finishes with what he considers the single most important

idea for success: build for change. IT systems are changing, and
while we can’t know where they’re headed, we can build with
that uncertainty in mind.
How Does Open Banking
Apply to US Banks?
by Chris Wood

The future of open banking in the US market is more

likely to be driven by demand than by regulation.

Open Banking has been on our radar for several years now, with
Nordics APIs first publishing a post on PSD2 back in 2016. Since
then, there’s been continual coverage in the financial industry
press on the promise of Open Banking, with predictions of a
“revolution” as FinTechs unlock the banking market and provide
the tools, apps, and banks do not offer functionality that bank
customers want yet.
How Does Open Banking Apply to US Banks? 46

Banking APIs are hitting the European market in earnest in 2019

to meet the deadline for delivering PSD2. The potential for this
revolution to become a reality has never been greater. It’s no
secret that Open Banking is most advanced in Europe because
of PSD2, which has brought with it standardization through stan-
dard API specifications developed to deliver it. This has led
banks down the path from private, closed APIs to public, open
APIs, and allowed them to become functioning members of the
API Economy.
Most commentators agree – including recent discussions in a
Senate Committee — that it’s high time that the US got in the
Open Banking game. However, the context of Open Banking in
Europe — with regulation currently driving the market — could
be met with suspicion by many US citizens. Regulation from the
center has overtones of socialism, a highly divisive word in US
culture, and attempts at a top-down Open Banking implemen-
tation would leave many questioning its value. Banks and their
customers alike, therefore, need to understand what’s in it for
them, relying on influences that resonate with the market.
Therefore, in this post, we take a look at the prospects for creat-
ing such a market. Without the regulatory drivers, unlocking the
potential of Open Banking in the US may be more complicated
than it first appears.

Regulation in Europe

Before discussing the US market, it’s worth noting the scope of

European regulations. The need for banks to provide open APIs
in the European market has mostly been driven by the require-
ments of the Second Payment Services Directive (PSD2), which
concerns itself with access to payment accounts. The context
for change is centralized and driven by the European Union,
How Does Open Banking Apply to US Banks? 47

responsible for legislating in many areas across the 27 member

states.
In this context, encouraging an Open Banking market through
regulation is relatively “straightforward,” especially in a market
where openness is already written in law. For example, pass-
porting of financial services – which allows an organization au-
thorized by the competent local authority in one member state
to operate in any across the EU – is one such a regulation that
enables an open market to work across national boundaries.
PSD2 introduced roles to enhance this open market, allowing
third-party providers (TPPs) to become regulated as either an Ac-
count Information Service Provider (AISP) or Payment Initiation
Service Provider (PISP).
PSD2 is also a maximum harmonization directive. This means
national law may not exceed what the legislation intends to
deliver. As each member state must provide an implementa-
tion that is equivalent to the law requirements, standards help
massively as each member state essentially attempts to achieve
the same thing. The market has been supported by standards
bodies that have built API specifications for them to adopt – the
Berlin Group, UK Open Banking and STET – easing the process
of bringing APIs to market.

Regulation in the US

Where central legislative bodies take a less active role - or where

there are several bodies with overlapping responsibilities - API-
enabling banks to open the market is more complicated. US
legislation is generally dealt with federally, with further laws
set on a state-by-state basis. Top-down change is rare, with
central government institutions often setting guidelines but less
frequently enacting legislation aimed at wholesale, nationwide
regulation.
How Does Open Banking Apply to US Banks? 48

The driver for Open Banking in this environment is Section 1033

of the Dodd-Frank Act which legislates that US citizens can per-
mit access to their financial data. Open Banking is being “encour-
aged” in this context by a central body, the Consumer Financial
Protection Bureau (CFPB). In October 2017 they outlined their
principles for “Consumer-Authorized Financial Data Sharing and
Aggregation” which, in the words of the document itself:

… recognizes that many consumer protections ap-

ply to this market under existing statutes and regula-
tions. These Principles are not intended to alter, inter-
pret, or otherwise provide guidance on — although
they may accord with — the scope of those existing
protections.

The document goes on to lay out the principles by which con-

sumer-authorized access should be achieved, including grant-
ing access itself, the scope of access, and how consent is ob-
tained. In general, the principles are high-level and are in stark
contrast to the exhaustive (although still subject to interpreta-
tion) detail of PSD2 or the Regulatory Technical Standards that
govern customer authentication. The nature of the principles
indicates that US government agencies are unlikely to seek cen-
tralized regulatory means to foster Open Banking.
In lieu of regulatory pressure, some bodies are seeking to set
standards that will encourage open API adoption across the US
market. For example, the National Automated Clearing House
Association has released standards under the banner of Afinis
with account validation and bank contact APIs. However, it is
early days for these efforts given key features, such as payment
submission (via ACH) and transaction status APIs, are still under
development. The initiative also lacks the impetus that maxi-
mum harmonization offers, as the CFPB principles indicate that
federal law will always take precedence. The same could also
How Does Open Banking Apply to US Banks? 49

be said of the Financial Data Exchange with the Durable Data

API, a similar group primarily aimed at providing consolidated
account access.
From an objective viewpoint, it is difficult to assess whether
these initiatives serve the principles of the CFPB document, or
whether they are aimed at the interests of the participants in the
groups. The immaturity of the standards and weaker regulatory
drivers also means there is less impetus for banks to participate
in developing and adopting common standards. On this basis, it
appears that an Open Banking revolution led from the center is
unlikely. Consumers in the USA are therefore likely to be more
reliant on market forces to bring them Open Banking and the
benefits it delivers.

The Role of the Market

When Open Banking is discussed in the context of any market,

there is a tendency to lightly gloss over what’s gone before.
Perhaps this is down to the fact that the “Open” in Open Banking
is the same “Open” in open API. In the manner of the Old Testa-
ment, Open Banking is the Word, and the Word is API…
Regardless of whether open APIs are (obviously) a good thing
and (of course) should be implemented, a marketplace for shar-
ing account data with third parties already existed in Europe.
Local initiatives such as HBCI/FinTS in Germany, direct collabo-
ration with banks (API-driven or not), or screen-scraping made it
possible. The examples of successful third parties in this space
are too numerous to mention. The role of Open Banking in this
market - and the legislation that drives it - is to standardize the
interfaces and ensure their adoption, making access for third-
parties - and by proxy, banking customers - ubiquitous.
Despite the obvious advantages of open APIs that the standards
How Does Open Banking Apply to US Banks? 50

brought, many protagonists in the market argued against the

proposed (now rejected) ban on screen scraping in Europe, which
we covered in a previous post.
If the strong regulatory drivers are missing in the US market,
then third parties with compelling products must fill the space
in the same manner as the pre-PSD2 market in Europe. The
development of Open Banking in the US will rely on the play-
ers to ubiquitously open up bank accounts for customers as it
already does today. For example, Yodlee provides access to 99%
of US banks, delivered to API consumers through a single API.
Similarly, Plaid delivers a single banking API for third parties
and connects to over 1700 banking institutions for both account
access and authentication. Behind the scenes, such providers
are responsible for connecting their API platform to the myriad
of systems supported by the banks to deliver a seamless ex-
perience for customers. On the payments front, the success of
players like Stripe is well documented. However, The Clearing
House (TCH) is also standardizing how real-time payments are
made in the US, which has historically been fragmented across
multiple platforms. While this platform is currently not an open
API - being message-driven in a closed network - the messaging
interfaces are based on ISO 20022. They could provide the basis
for open payments APIs.
Organizations like Plaid, Yodlee, and TCH provide a live proving
ground for the value of Open Banking. By delivering compelling
solutions in the marketplace - which many US consumers want
and use - they offer a persuasive argument that providing access
to an account can only be a “good thing”. Such evidence mirrors
that found in Europe, where providers like Figo were already
delivering near-complete coverage of the German market before
the rollout of PSD2-compliant APIs. Therefore, the success of
such providers is critical to the success of Open Banking in the
US. In the absence of regulatory-driven API standards, they will
provide the de facto Open Banking APIs for early adopters.
How Does Open Banking Apply to US Banks? 51

Final Thoughts

The future of Open Banking in the US market is more likely to

be driven by the market than regulation. However, there is still
an opportunity to introduce standardization through open APIs
behind the scenes. As TPPs like Plaid and Yodlee continue to
increase their footprint, a means for banks to easily offer an
interface and a go-to API standard will help increase penetration.
A partnership model could develop, with TPPs proactively work-
ing with banks and providing the interface on their behalf. In this
context, it might be that TPPs can help bring standardization and
open APIs to the banks, and organizations like FDATA would do
well in establishing a US footprint.
However, there is also an equal opportunity for a BigTech to
steal a march on the Open Banking market. While this is equally
possible in Europe, the regulatory aspect to the Open Banking
market means that exceeding the provisions of an AISP or PISP
to introduce the “killer” app might be difficult. In the US, the
constraints on what Open Banking can do are not defined by
regulatory roles, and the authorities are far more accepting of
big business influence. In the same way, as Apple influenced Visa
and MasterCard to provide a solution to introduce Apple Pay,
one of the FAANG groups might find a way to broadside the US
Open Banking market. If this comes to fruition, the hype might
become a reality, and Open Banking really will revolutionize
financial services.
Case Study: From API Doing
to API Thinking at ING Bank
by Thomas Bush

“API thinking” takes a holistic outside perspective

that considers developer consumer needs.

In any sizable organization, it’s hard to feel like you can make
a difference with just your tech skills. There’s no surprise that
software engineer Flavia Sequeira felt precisely that when she
joined ING, the multinational banking firm with over 50,000
employees, in 2013.
You see, building an impactful IT product can take a lot of time
and effort. So, it’s hard for management to get excited about
that when it doesn’t offer an immediate value proposition. Who
Case Study: From API Doing to API Thinking at ING Bank 53

needs an API when we can be fixing server downtime, or getting

the user interface all dressed up for next month’s holiday?
That was the case with APIs when Flavia joined ING. The business
folks were aware they wanted a more open approach to technol-
ogy, one that could potentially change the face of 21st-century
banking, but it wasn’t obvious where to start. Surprisingly, build-
ing an API wasn’t an obvious solution to that, especially since the
IT team had already created a web service.
As Flavia described in her session at the Nordic APIs Platform
Summit, it was quite the journey to educate her coworkers on
the benefits of an API thinking, as opposed to just an API doing.
And it all starts with a case of semantics…

APIs versus Web Services: What’s the

Difference?

Flavia tells of an early API community session at ING, where

overwhelming negativity towards APIs filled the room. The ex-
perienced developers simply couldn’t see what APIs had to offer
that their web service didn’t.
The common consensus is that web services offer a more limited
range of functionality than APIs, delivering particular data in a
standardized format. This is opposed to providing a comprehen-
sive development suite for building onto an existing IT product.
Flavia had (and still has) her own take on the matter:
“APIs are built outside-in”, she announced in the meeting, fol-
lowed by a long silence.
When asked to expand on what she meant, Flavia explained
that APIs are built from the customer’s perspective, to the cus-
tomer’s needs, while web services are built from the organiza-
tion’s perspective, offering what they perceive as important.
Case Study: From API Doing to API Thinking at ING Bank 54

This means that, whereas web services might offer just a single
service or set of services for customers to make use of, public-
facing APIs allow for much more interactivity with your product,
such as tracking customer journeys.

API Doing vs API Thinking

The above anecdote makes it clear that Flavia joined ING with
a completely different mentality towards APIs. She wasn’t as
much interested in API doing as she was API thinking, and that
was an entirely novel approach.
She didn’t ask herself: * What data and functionality do we think
is useful for users? * How can we provide them with that data and
functionality? (In other words, how we do we build this API?)
Instead, she asked herself: * How do our users want to engage
with our services and what do they want to build? * How can we
make it as easy as possible for them to do so? * How will that
better help us understand and serve the needs of our customers?
Of course, that first set of questions — the API doing questions
— are just as important as the second set of questions. In fact,
they’re the more practical questions for a developer to ask.
However, it’s the second set of questions — the API thinking
questions — that really justify an organization to build an API.
What’s more, they solve that initial dilemma of convincing man-
agement what APIs have to offer.

APIs and Customer Journeys

Flavia’s anecdote continues, in parallel with what we’ve just said

above. She recalls how a senior employee then asked her to
Case Study: From API Doing to API Thinking at ING Bank 55

expand on her thoughts on customer journeys, presumably won-

dering why a software engineer would be tracking a customer’s
experience with ING from start to finish.
The truth is that well-designed IT products are tightly linked to
an awareness of customer behaviors, requirements, and desires.
Not only does the latter help to build products that the user will
love, but products that the user loves will themselves help to
flesh out customer behaviors, requirements, and desires. This
occurs by encouraging open thinking in developmental stages
and providing empirical data in operational stages.
This is why customer journeys from the business department
at ING help to build better APIs, and why better APIs help the
business department to create fuller, more effective customer
journeys.
APIs share that same symbiotic relationship with other business
tools, like service blueprints, and business practices, like design
thinking. These pave the way for a more functional, complete
API, while the API helps to visualize and facilitate new opportu-
nities.
What’s more, APIs can be a solution to decoupling front and back
ends — allowing the end product to link up closely with its inner
workings, without making the two entirely reliant on each other.
This is API thinking. It’s understanding what APIs can do for the
organization, from a holistic perspective, and not just meaning-
lessly building APIs because they are trendy.

Why API Doing is Equally Important

When you’re tracking this kind of high-end thinking, it’s easy to

forget about the true value that APIs can provide in modern-day
banking — and that’s very much in the doing.
Case Study: From API Doing to API Thinking at ING Bank 56

See, unlike the business tools mentioned above, APIs offer just
as much to the user as they do to the bank itself. API usage in
banking, which is part of a greater movement called open bank-
ing, allows FinTech services to draw from the huge information
base and varied functionality that banks already have.
Think about it — there are thousands (if not millions) of third
and first-party apps built into our mobile phones, social media
platforms, and even houses. Yet there’s hardly an equivalent for
today’s banking services.
Imagine having an app store for your bank account. You could
choose from thousands of services, built with the collective
thinking power of third-party developers — big and small — that
would solve a multitude of problems and change banking for
good.
The possibilities for this are endless: collect all your accounts in
one place, send cash over social media, manage your spending
patterns, verify past transactions, and so forth.
With the way things are today, it’s not that it can’t be done,
but more that it’s impractical. Of course, any financial services
— banks included — need to be well-secured, with information
locked away in internal systems. This is why the existing (and
highly limited) model of giving FinTech services direct access
to your account (known as screen scraping) simply can’t go on.
The finance management service Mint performs screen scraping
regularly — gaining direct access to your bank accounts — but it
feels safe enough knowing their parent company, Intuit, already
holds millions of social security numbers.
However, requiring user login information is a significant barrier-
to-entry for smaller FinTech developers. These applications may
only need a limited scope of data to operate, such as your spend-
ing dates or locations your credit card has been used at.
APIs are an obvious solution to this, allowing third-party services
Case Study: From API Doing to API Thinking at ING Bank 57

to interact with banks, drawing only the necessary information,

and performing only the necessary services. With standardized
authentication and delegation protocols widely established for
APIs, not only would it be more secure — it would be more
effective.
Changes in regulation, like with PSD2 in the European Union, are
already pushing for and preparing for this change. Ultimately,
though, it’s up to banks to open themselves up to the world in
a way that is usable.

From API Doing to API Thinking

When Flavia joined ING, they didn’t just lack in API execution, or
“API doing”, but they also lacked in API understanding, or “API
thinking.” This was making it hard to execute a definite platform
strategy.
She’s solved this by encouraging others to look at APIs holisti-
cally — to understand what they bring to an organization and its
clients or partners, and to employ that same information to then
build better IT products.
Along Flavia’s journey, her career description has changed from
“software engineer” to “API thinker.” She doesn’t just build IT
products at ING; instead, she educates fellow developers on how
those products, especially APIs, can be designed true to both
ING’s values and its customers’ experiences. This, in turn, will
allow them to create a better overall customer experience.
Ultimately, APIs aren’t made from doing or thinking alone — it
should be a mix of the two. Despite Flavia being an API thinker,
there has to be a number of API doers at ING, too.
Open Banking Amplifies the
Need For Definition Driven
APIs
by Saoirse Hinksmon

Adopt an API specification like OpenAPI to organize

and standardize API design practices across an org.

In today’s global economy, it’s no secret that consumer power

is growing. Organizations all over the world are rethinking their
digital strategies to maximize their customer focus and engage-
ment. Customer engagement is the catalyst that jumpstarts digi-
tal transformation, mobile-first, and other strategic initiatives to
bring legacy systems into the modern digital age. To accomplish
Open Banking Amplifies the Need For Definition Driven APIs 59

these initiatives, many companies look to APIs as the primary

building blocks, rapidly increasing the number of internal, exter-
nal, and partner APIs they rely on for critical business transac-
tions.
A tangible representation of consumer power and API growth
lies in the acceptance and promotion of the Open Banking Stan-
dard. In recent months, open banking has been the buzzword
for FinTech organizations worldwide. The Open Banking Stan-
dard tackles concerns for more institutional transparency and
more options for consumers when selecting banking services
and providers. Under the Open Banking Standard, banking data
is shared through secure open APIs to promote consumer con-
trol and lower entry barriers into a market that has historically
has been difficult to break into.
With the promise of a cultural revolution, Open Banking Stan-
dard requires financial institutions to expose APIs for consumers
and vendors alike. However, creating and exposing public-fac-
ing APIs to a variety of consumers would require standardization
to ensure that people are able to understand what the API does
and what information it is supposed to return.
The tricky thing about creating and deploying valuable APIs is
that they need to serve both human and machine needs, both
of which are inherently different. Humans prefer more instinc-
tual, easily understandable instructions, while machines require
more explicit, logic-driven instructions. Implementing an API
standard that both humans and machines can understand, espe-
cially with the lens of open banking, is essential to finding long-
term success with exposed and internal APIs.
Open Banking Amplifies the Need For Definition Driven APIs 60

Adjusting Practices With The Shifting API

Landscape

As financial organizations increase their reliance on APIs, a vari-

ety of different challenges arise. We’ve mentioned the challenge
of designing an API so that both humans and machines can
understand their functionality, but the challenge does not end
there. Some of the hindrances that can impact API development
and growth include:

• Collaboration
• Quality
• Scalability
• Availability
• Performance
• Security
• Compliance

With the mounting challenges, organizations also have to keep

in mind that practitioners sometimes have different needs from
stakeholders, and striking the right balance between practitioner
and stakeholder requirements is the only way to progress as an
organization.
How can financial organizations manage all these factors, while
maintaining the right balance for practitioner and stakeholder
needs?

• Use OpenAPI: Take a definition driven approach to API

development.
• Share responsibilities: Ensure quality is a shared respon-
sibility for Dev, Test, and Ops teams.
• API Virtualization: Consider using service virtualization to
accelerate development.
Open Banking Amplifies the Need For Definition Driven APIs 61

• Keep iterating: Monitor end-user experience and perfor-

mance in pre and post-production.

How OpenAPI Specification (OAS)

Accelerates API Development

In Definition Driven API Development, you design the API defini-

tion before any other lifecycle operation. The design of the API’s
interface, requests, and responses are finalized before other life-
cycle functions, like building the API’s business logic or testing
the API for errors or defects. The definition-driven approach
brings with it some great benefits, such as better developer expe-
rience, team collaboration with independence, and a faster go to
market time. All these help create a consumer-centric approach
to API development.
The OpenAPI Specification (OAS) is to REST what WSDL was to
SOAP, providing a common framework that designers, develop-
ers, testers, and DevOps teams can use to build and maintain
APIs. The specification offers a set of rules to develop and im-
plement a REST API. It is language-agnostic and is both human
and machine-readable. OAS offers a way for all stakeholders to
discover and understand the capabilities of a service without
requiring access to source code, additional documentation, or
network traffic inspection.
For financial institutions, the OAS framework can help bridge
the gap between consumers and institutions, without requiring
much additional effort from either party. Adopting this frame-
work can help re-frame negative consumer perception of ex-
posed APIs. It can also help break down the technology barrier
between consumers and banking providers to build trust with
end-users. All of which will be increasingly vital for finding suc-
cess with an open banking initiative.
Open Banking Amplifies the Need For Definition Driven APIs 62

Supporting OAS Throughout the API

Lifecycle

Instilling quality in the Organization

Typically, software teams are segmented by responsibility, al-

though now, there is a shift to make organizations more interop-
erable. Sharing duties with explicitly defined metrics empower
teams to collaborate while maintaining responsibility and ac-
countability. Sharing quality metrics can help promote rapid de-
velopment cycles, reduce the number of bugs, and ensure that
the APIs pushed to production retain their quality throughout
the entire lifecycle.

Service Virtualization

Rather than mocking and sandboxing, which can limit how many
scenarios can be tested at a time, service virtualization empow-
ers teams to use virtual services instead of production services,
enabling frequent and comprehensive testing even when key
components are missing from the system architecture. It is es-
pecially useful in the development of complex cloud, API, and
SOA-based systems, as well as at any point in a production cy-
cle where important hardware and software components aren’t
readily available for testing purposes. For API design and devel-
opment in the financial industry, service virtualization offers a
variety of benefits:

• Rapid creation
• Virtualization can be pre-packaged, modified, and reused
• Is not heavily manual
• Import real data into tests for more realistic results
Open Banking Amplifies the Need For Definition Driven APIs 63

More and more companies are using service virtualization to

improve productivity, reduce testing costs, and deploy higher-
quality software in a shorter timeframe. In addition to emulat-
ing major software applications, third-party services, and even
whole backend systems, the virtual assets can also be reliably
shared and used by the entire production team, facilitating more
efficient parallel development practices.

Monitoring End-User Experience in Pre and Post

Production

For most companies, API monitoring is a relatively new concept.

However, for companies relying on APIs for critical business
transactions, understanding the availability, performance, and
functional correctness of their APIs is paramount for their digital
experience delivery.
Monitoring key API transactions, whether they are a simple end-
point call or APIs called in sequence, allows organizations to
fully understand how their APIs are behaving. Identifying per-
formance problems, remediating issues, and fixing functionality
mishaps is easier than ever when you choose an API monitoring
tool that can reuse functional test scripts and OAS files, and per-
haps even natively add new chained API transaction monitors.
Another trending strategy is to monitor APIs in pre-production
environments. These monitors do not replace testing efforts, but
rather complement the testing process. Pre-production monitor-
ing offers benefits such as:

• Ensure that any new updates or changes will not break the
monitors in production
• Gain a view of performance from an on-going perspective
• Capture performance and functionality metrics outside of
the specific test case
Open Banking Amplifies the Need For Definition Driven APIs 64

• Insight into the state of your test environments themselves,

so you can maintain the environment stability

Final Thought: Drive Open Banking API

Strategies with OAS

The implementation of open banking and PSD2 will only serve to

heighten the pressure financial services feel to create and deploy
new or additional public-facing APIs. Fostering trust and trans-
parency with both practitioners and stakeholders is only the
beginning of the challenges teams will face in crafting great APIs,
but using a framework like OAS can help streamline consistency
and collaboration. Thanks to a vibrant community, many tools
are available to support OAS defined APIs from development
to deployment, making the adoption decision clear and the
transition easy.
High-Grade API Security For
Banks
by Kristopher Sandoval

Consider these data regulations and API security

open standards to address them.

Financial institutions occupy an exclusive zone for APIs primarily

because of how stringent the regulatory compliance rulesets are.
The data that financial institutions leverage is protected widely
by a variety of regulatory ordinances. As such, this data has to be
stringently controlled, secured and managed – hence why high-
grade API security is such a serious concern.
In this chapter, we’re going to discuss the regulatory severe
compliance considerations inherent in financial data exchange
High-Grade API Security For Banks 66

and management. We’ll then look at some methods for securing

such data when it comes to APIs (like API keys, OAuth and JWTs).
We’ll see what can be done (and should be done) to ensure
consumer security and protection.

Regulatory Compliance Considerations

To contextualize our conversation, here are some of the most

common regulatory guidelines financial sector providers may
come across.

• Basel II is a set of international standards that requires fi-

nancial organizations to evaluate and mitigate operational
risk losses of financial data. It is concerned explicitly with
insufficient security for data and system failures due to
improper configuration or poor expectations of system de-
mands. As such, it is a good starting point for many systems
planning to utilize financial data.
• PSD2 - The second revision of the Payment Services Direc-
tive hails from the European Union, and was designed by
the European Commission to regulate payment services
throughout both the EU and the European Economic Area.
The regulation is primarily concerned with consumer pro-
tection and establishing rights, obligations, and expecta-
tions for payment providers and financial institutions.
• The FFIEC Uniform Rating System for Information Tech-
nology (URSIT) is a US federal standard for examining a
company for proper Auditing, Management, Development,
Acquisition, Support, and Delivery processes. URSIT is a
great tool for setting up a process to identify security con-
cerns and can serve as a type of framework for such a
process.
• The Gramm-Leach-Blilely Act is a US federal act that re-
quires financial institutions to ensure the security of both
High-Grade API Security For Banks 67

financial and personal data. This act is the foundation of

the data Safeguards Rule as issued by the FTC, which re-
quires an information security plan that incorporates risk
assessments as part of a total security auditing process.
• PCI-DSS is a regulatory standard that requires vulnerability
scanning and source code review to ensure that payment
card industry data and processes meet the stringent se-
curity processes needed by providers and payment ven-
dors. PCI-DSS is critical for many online organizations, es-
pecially those managing payment processing for a product.
As such, any API that has a monetization approach that
integrates card payment natively should be very aware of
PCI-DSS and its requirements.
• Sarbanes-Oxley requires that internal controls report to
the provider as a means to track the accuracy and security
of financial data. It includes rather stringent audit mecha-
nisms for internal controls and demands the examination
of IT assets, software, and solutions for resistance to data
breaches and exposures.

This is only a small selection of the most common and top-

level regulatory standards. Depending on where you regionally
do business, regulations can be narrower, and these variations
can become even more marked in separate fields within the
same industry. That being said, understanding these top-level
regulatory structures can help frame the conversation moving
forward.

Identifying Vital Data

We also need to identify what specific data is protected. We

can sort our data into one of three categories: Personal Data,
Financial Data, and Transactional Data.
High-Grade API Security For Banks 68

Personal Data is exactly what it sounds like. This data type is

specific to each user, like Social Security Numbers or National
Identification systems, addresses, names, and more. This type
of data isn’t necessarily dangerous to expose on its own (though
Social Security Numbers and other related content are often
federally significant). In combination with other data on the
system, it can be used for personalized and directed attacks.
Financial Data is all data related to the accounts held by Per-
sonal Data, and typically has more to do with the funds available
to a person, their standing in the bank, credit information, and
other data. Again, while not specifically dangerous on its own, in
combination with Personal Data, it can quickly become a huge
security concern for the user.
Transactional Data is intimately related to Financial Data, but
it is separated here due to the nature of its data generation.
Transactional Data is the data that dictates transfers of funds,
purchases, movements from account to account, and more. This
data is often required to be kept for organized crime prevention
and fraud investigations, but could also be used to capture au-
thorization codes for replay attacks, track purchases for fraud
and blackmail, or even be used as a means of monitoring an
individual’s approximate location.
It should be noted here that individually, none of this data is nec-
essarily dangerous on its own (though certainly, the potential
for single-vertical damage is indeed present). While they should
always be secured as stringent as possible, knowing someone’s
address is a security exposure for sure, but not one that could
result in the kind of massive crimes that are possible in financial
theft.
The danger comes when these data types are combined – know-
ing account holdings, addresses, names, and more can result
in massive fraud and damage to the user. As such, the highest
weakness should be considered allowing any data at all to leak,
High-Grade API Security For Banks 69

regardless of perceived importance or value.

Potential Vulnerabilities

While financial data has its own set of caveats and considera-
tions, it is ultimately just data, and as such, can be considered
the same as any set of data would be regarded as when it comes
to potential vulnerabilities. Every data set is governed by three
simple letters – CIA.
As any security professional can tell you, CIA is an acronym that
represents the security scope when it comes to secured sys-
tems – Confidentiality, Integrity, and Availability. Understanding
these three concepts will help highlight vulnerabilities, and can
expose serious issues that are often hidden away from more top-
level audits.
In Confidentiality, the concern is keeping data private and ex-
posing it only to those who have the right to view it. This is a
significant part of financial protection, as the account holders
will not be the only people accessing the data. Investigators,
auditors, bank managers, employees, and others may have to
access bank data from time to time. As such, ensuring different
levels of Confidentiality is key to ensuring vulnerabilities are
kept to a minimum.
Integrity is concerned with data being stored and unaltered
between uses. This is majorly important for banks, as data in the
ledger states the value of holdings – allowing amounts, points of
origin, transactional information, and more to be altered would
nullify the entire purpose of a financial institution and would
result in absolute abject confusion and panic. Thus, securing sys-
tems from incorrect write actions and backing up these ledgers
in secure form for restoration is key to ensuring these vulnerabil-
ities do not propagate.
High-Grade API Security For Banks 70

Availability is an essential aspect of banking as well, as there is a

significant amount of regulation concerned with ensuring users
and investors have access to their systems and funds. Down-
time is often associated with additional cost, loss of investor
confidence, and exposure to systems to attack; thus, ensuring
Availability by distributing server load and filtering fuzz traffic is
key to any banking institution.
While there is a wide range of vulnerabilities that are not dis-
cussed herein, these vulnerabilities will broadly fall into one of
these three categories.

API Security Methodologies

Now that we understand our vulnerabilities, we can begin to

look for new solutions to mitigate them. No single solution is
going to be perfect here. As such, each solution as presented is
going to represent only a single part of a greater solution, and
should be contextualized as such. No solution is going to apply
to every level of the financial institution. This should be kept in
mind while cost-averaging and contextualizing the solutions for
their given use cases.

API Keys

API Keys are a fundamental mechanism of API security and are

used for low-level and low-security APIs around the world. The
concept is simple – generate a key for the user that identifies
them to the system so that when a request is issued, the system
itself can identify the key and note the user is who they claim to
be.
The problem is that API Keys themselves are not entirely secure.
API Keys are not meant to serve as a method of securing access,
High-Grade API Security For Banks 71

but only as a method of proving the user is who they say they are.
Compound this with the fact that API Keys lack control in granu-
larity (often either being a “yes or no” option for identification),
and you very quickly run into a situation where your API Key is
not enough.
The vast problems with API Keys come when end users, not
developers, start making API calls with these Keys, which more
often than not expose your API to security and management
risks. What it comes down to is that API Keys are, by nature, not a
complete solution. While they may be perfectly fine for read-only
purposes, they are too weak a solution to match the complexity
of a high-use API system. Whenever you start integrating other
functionality such as writing, modification, deletion, and more,
you necessarily enter the realm of Identification, Authentication,
and Authorization.
In other words, API Keys serve a particular purpose, and can
be used to significant effect for read-only functions of publicly
exposed endpoints on insecure data (such as verifying server sta-
tus or beginning a more stringent authorization/authentication
process), but should not be considered a “security solution.”

OAuth and JWTs

For secure data, a combination of OAuth and JWTs can be very

useful in securing data.
JWTs, or JSON Web Tokens, are very small, self-contained pack-
ages that contain all the information the server will need to
process a request, and then later all the data generated by the
server that the user needs. As such, the JWT represents a very
efficient, lightweight communication methodology in the API
network, and it offers all of the perks of JSON (both machine and
human readability is a key perk of JSON-type structures).
JWTs are not encryption, however, and serve only the process
High-Grade API Security For Banks 72

of encoding the data – as such, they are only as secure as the

system they reside on. This is one caveat of JWTs. There is
indeed a specification for JWT encryption, known as JOSE –
JSON Object Signing and Encryption – that can offer greater
security, especially when paired with more stringent encryption
and security methods.
With our encoded package out of the way, we can begin to look
at other methods of securing access to the system itself. OAuth is
a token-based system for authentication and authorization first
proposed in 2007 by various developers of Ma.gnolia and Twit-
ter. Since the official publishment in 2010 of RFC 5849, which
defined the standard, all Twitter applications – as well as a great
many online applications in general – require the use of OAuth.
RFC 6749 created OAuth 2.0, an updated framework evolution
that is paired with a Bearer Token Usage definition in RFC 6750.
While it’s true that OAuth is a system of “authentication and
authorization,” it should be said that OAuth by itself does not
actually provide an authentication protocol. Instead, it sets a
framework for authentication methodologies and decisions. Its
native authorization protocol, or more specifically its authoriza-
tion-through-delegation protocol, uses four general entities to
control data access:

• A Resource Owner (RO) controls the data being exposed by

the API and is considered the “owner” of said data.
• The Authorization Server (AS) is a Security Token Service
(STS) that issues, controls, and revokes tokens for access
– this is often also referred to as the OAuth Server in the
internal system.
• The Client is the application, user, website, etc. that re-
quests data on behalf of the resource owner.
• Finally, the Resource Server (RS) is the service that exposes
and stores the data and is typically the API itself.
High-Grade API Security For Banks 73

The “basic flow” of OAuth is the “implicit flow,” and functions

like this. The Client requests access to a resource by contacting
the Authorization Server. The AS then responds to this request
with its own request for data, namely the user and password in-
formation. The AS passes this data, once received, to the Authen-
tication system, with either responds to the AS with approval or
denial. From here, if approved, the AS allows the client to access
the Resource Server. This can be further extended using a Bearer
Token, which essentially gives the client a revocable, often time-
limited token that can be used to access resources over time
with a given scope of rights.
OAuth has some great benefits for banking institutions, but the
best aspect is that it fits with the natural organization of a finan-
cial institution. The Client functions as a teller or manager, the
AS functions as an internal server verifying account ownership.
The token functions as a sort of ID card verifying ownership and
rights – in this way, at least insecure situations, OAuth is a great
solution for mirroring bank organizational structures in the way
it handles its own data.

OpenID Connect

OpenID Connect is a simple identity layer that is designed to

lay over OAuth. OpenID Connect is actually the third revision of
the OpenID approach. More specifically, it was built to overcome
the earlier design limitations of OpenID 2.0 concerning Relying
Parties, XML reliance, and more. OAuth 2.0 is the substrate for
OpenID Connect and utilizes HTTPS (specifically TLS/SSL) infras-
tructure for data security. We’ll cover OpenID Connect more in-
depth in the following chapter.
High-Grade API Security For Banks 74

Security is The API Provider’s

Responsibility

It’s important to discuss exactly where the responsibility for data

security actually exists for the financial industry. In theory, re-
sponsibility for security should exist at all levels of the API space,
with users securing their devices, clients implementing strong
encryption, and so forth. While this is a lofty goal, the reality
is often that someone, somewhere, is going to do something
counter to the overall security of the system – and in the financial
industry, this can be extremely damaging.
Accordingly, the best approach to security in the financial sec-
tor is to assume nobody is going to “do their job” besides the
provider – and as such, the weight of security rests solely on the
institution’s shoulders. In other words, both in terms of compli-
ance with regulations and in moral responsibility, security rests
chiefly as a concern for the API provider.

Recent Exploits and Breaches

This isn’t all just theoretical nonsense, either – failure to incor-

porate and internalize these issues has resulted in some major
recent exploits and breaches from some rather large organiza-
tions.
An attack in 2014 was leveled against Chase bank, exposing the
financial and personal information of 76 million households and
7 million small businesses. The breach was somewhat of a sore
spot considering that Chase spends over $250 billion annually
on cybersecurity, especially considering that the cost of the
breach has been estimated at $1 Billion USD.
Not all breaches are just from financial institutions, either. Home
High-Grade API Security For Banks 75

Depot was subject to a cyberattack in 2014 as well, with hack-

ers using partner information from a vendor to expose a great
amount of data from purchasers and businesses. The cost, be-
fore insurance reimbursements, is estimated at $80 Million USD.
The Home Depot breach is a great example of how institutions
can’t necessarily trust others in the chain to provide adequate
security. In this case, it was the vendor specifically that exposed
the data internally.
Both of these cases are chump change compared to perhaps
the biggest breach in recent years, the Equifax breach. In 2017,
Equifax revealed that a cyberattack revealed credit card num-
bers and personally-identifying information of almost 143 mil-
lion Americans – almost half of the entire country. The breach in-
cluded names, Social Security Numbers, birth dates, addresses,
driver’s licenses, credit card numbers, and other financial infor-
mation, leading to massive insurance claims and widespread
fraud. As of September 2017, the breach has cost Equifax almost
$4 Billion in lost market share, with insurance claims and puni-
tive measures still being calculated.
Ultimately, these are just three of many breaches in recent years
– and as technology dramatically advances, and the attacks
leveled against institutions becomes more mature and complex,
the number of breaches will likely increase.

Conclusion

Ultimately, API security is squarely on the shoulders of the API

provider, and thereby the financial institution itself – failure to
understand the vulnerabilities inherent in such business func-
tions and the fundamental concerns of CIA within the greater
ecosystem, can result in massive losses and exposures. If a finan-
cial institution internalizes these concerns, such functions can
be provided securely and efficiently.
Is OAuth Enough for
Financial-Grade API
Security?
by Art Anthony

OAuth is a mature protocol sufficient for safe-guard-

ing bank data in transit.

“If you think about where OAuth started, it was really

about securing comments on blog posts, and now
we’re talking about enterprises, so it’s a whole differ-
ent class of security.”
Is OAuth Enough for Financial-Grade API Security? 77

This is how Travis Spencer, CEO at the identity company Curity,

opened his talk at our 2019 Austin API Summit. It’s an astute
summary of how many products (particularly in the tech scene)
are tweaked or re-engineered beyond their original purpose.
As Spencer clarified in his talk, “when we say banking grade,
we’re not just talking about banks; we’re talking about health-
care, government, and high security.” In other words, financial
grade security is relevant to any data-centric API.
It’s often true that products struggle to adapt to tasks they were
not originally designed for. In this post, we’ll be looking at whether
or not that’s the case here. Knowing OAuth evolved from humble
beginnings, is it competent for use in financial grade protection?

Can OAuth Make The Grade?

Early in his talk, Spencer provides a summary of some things

you can do with your OAuth implementation to provide financial-
grade security:

• Mutual TLS constrained tokens

• PKCE (Proof Key for Code Exchange)
• Consent
• Signed request/response objects
• Pairwise Pseudonymous Identifiers (PPIDs)
• Phantom tokens
• Strong authentication
• Prefix scopes
• Dynamic clients

There’s no denying that’s a pretty comprehensive list and sug-

gests that OAuth is more than capable of holding its own when
it comes to security. In other words, OAuth shouldn’t be seen
Is OAuth Enough for Financial-Grade API Security? 78

as insufficient when it comes to securing data. In fact, Spencer

outlines many ways in which it works very well for financial
grade protection.
For example, Spencer mentions how PPIDs can be used to pre-
vent collusion between separate apps while allowing interaction
between, say, sites, and their associated mobile apps. He also
describes how phantom tokens (vs., say, a JSON web token)
allow for a smaller regulated space while preventing clients from
accessing any Personally Identifiable Information (PII) and front-
end clients from depending on the content of access tokens.

Some Tokens Are Unbearer-able

The way developers use OAuth isn’t, however, always perfect.

The two main vulnerabilities of OAuth, as seen by Spencer?
Bearer tokens and the redirect. “Those two things are the pri-
mary attack vectors in OAuth.”
Spencer likens the former to bearer bonds; “if you bear the
bond, then…you can get a million dollars for each piece of paper
and have a great life!” That’s particularly problematic because,
unlike bearer bonds, there’s no way to lock tokens away in a
physical safe.
“That’s the Achilles heel because, if I can snatch someone else’s
token, I can become them.” So what’s a solution that can get
around this? “The opposite of this is a holder of key token or
proof of possession token, and that’s what mutual TLS con-
straint tokens are.”
Is OAuth Enough for Financial-Grade API Security? 79

From “Financial Grade APIs Using OAuth and OpenID Connect,” by Travis
Spencer, CEO at Curity.

In simple terms, the addition of a hash of a certificate to the

token exchange process means that works something like using
a cipher to decode a message; without the proper credentials,
the token won’t function properly when used for an API call.
Unfortunately, that isn’t the end of the story…

Away With The PKCEs

When talking about redirects, Spencer refers to the vulnerability

in callbacks that exists if…

• It’s not confidential, i.e., not done over TLS

• There’s no authentication done on the token endpoint
• The callback is not unique per client, or per client operator

“In cases where it’s possible for a bad actor to intercept the
credentials, they may be able to entirely sidestep the use of
mutual TLS tokens outlined above.” He also highlights that this
is something particularly prevalent in mobile devices.
Is OAuth Enough for Financial-Grade API Security? 80

The solution? Proof Keys for Code Exchange (PKCE). “We can
add a step 0 into this process…The legitimate application uses
a proof key to prove that it is the actual application that started
this flow, with the OAuth server refusing to finish it unless that
proof is verified.”
You could think of this as a more robust version of Dennis Nedry’s
“ah ah ah, you didn’t say the magic word” in Jurassic Park…

Signed, Sealed, Delivered

Spencer highlights the issue that, in most cases, OAuth flows go

through the user agent. Malware installed in the browser, for
example, on the user side, can undermine all of the measures
taken above.
“How do we know that OAuth flows aren’t being tampered with
in flight?” Spencer asks. “We sign the request from the client
sent to the server and back…We can also sign the response
that’s sent back to the client as well so they know nothing was
tampered with on the way back.”
All of this signing and hashing is something that’s already proven
its worth in recent years: read an article about data leaks by big
companies, and you’ll notice, in cases where it’s been done, how
eager they are to talk about hashing passwords.
Although hashing passwords, signing requests, etc. isn’t always
100% secure, there are cases, for example, in which weak hash-
ing has been cracked. It is, at this point in time, about the best
thing we can do.
Is OAuth Enough for Financial-Grade API Security? 81

What’s Next For Financial Grade API

Security?

It seems likely, for now at least, that the status quo will continue
as the norm in the world of financial and financial grade APIs.
From PayPal and Stripe to Coinbase, and probably Facebook’s
Libra in the not too distant future, there are plenty of financial
services utilizing APIs that are built around existing frameworks
and services like OAuth.
If actual financial services are already relying on these, then
there’s very little incentive for other API developers to go be-
yond what already, in effect, constitutes financial grade API se-
curity…barring massive data leaks or the exposition of serious
vulnerabilities.
In the meantime, we would expect to see OAuth continue to
be one of those rare exceptions: a service built with something
minor (securing blog comments) has effectively expanded to
something much more robust than its original intent.
OpenID Connect: Overview
of Financial-grade API (FAPI)
Profile
by Chris Wood

OpenID Connect, and the FAPI profile, will play a

pivotal role in tracking identity to keep open banking
architecture secure.

Open banking continues to be a subject of keen interest in finan-

cial services, reaching “buzz word” status over the last few years.
We’ve covered the growth of the ecosystem on the blog several
times before, but haven’t yet studied the standards emerging
both within and across open banking markets. It comes as no
surprise open banking initiatives have spurred several notable
OpenID Connect: Overview of Financial-grade API (FAPI) Profile 83

advancements in standards. In this post, we’ll look at a suite of

standards that focus on improving API security: The Financial-
grade API (FAPI) Profile.

What is FAPI?

FAPI is a working group of the OpenID Foundation, the body

responsible for the development and maintenance of a family
of protocol standards centered around OpenID Connect. FAPI
was initiated in 2017 and sought to bring enhanced security to
the new API standards being created to deliver PSD2 regulations
across Europe, one of the key drivers in the buzz around open
banking.

The scope, however, is not limited to PSD2 and the regulatory

aspect of open banking. According to FAPI, its goal is to provide
a “higher level of security than provided by standard OAuth or
OpenID Connect.” The standards also frequently refer to screen-
scraping and the purpose of replacing this method with “an API
model with structured data and a token model, such as OAuth.”
To existing adopters of OAuth and OpenID Connect the benefits
OpenID Connect: Overview of Financial-grade API (FAPI) Profile 84

might seem obvious, but for the uninitiated, here are some key
points:

• One of the primary goals of OAuth is to ensure that the End

User – a real human being – does not have to give their
confidential credentials when sharing data with another
app.
• By offering a delegated access model, OAuth ensures that
the Client app – the “Relying Party” never sees those cre-
dentials but instead uses an access token.
• OpenID Connect adds to this model by providing proofs-
of-authentication that the app both has delegated access
to an API on behalf of the End User and proof that the
real human being actually authenticated. As we covered
in our introduction to OpenID Connect, not having proofs-
of-authentication may be fine for Tweeting your best score
on Wordscapes, but it’s not so great when accepting a
payment instruction from an app that may or may not be
acting on behalf of an authenticated End User.

OAuth has its detractors, especially in how the redirection mech-

anism for authenticating the End User introduces friction. How-
ever, arguments for the security benefits are sound. FAPI, there-
fore, uses OAuth as its base profile for a good reason. FAPI
currently incorporates four standards, all currently specified as
Implementer’s Drafts (in the parlance of standards an Imple-
menter’s Draft means “stable enough to implement, but not
quite formally approved”). These are:

1. Read Only API Security Profile

2. Read & Write API Security Profile
3. JWT Secured Authorization Response Mode for OAuth 2.0
(JARM)
4. Client-Initiated Backchannel Authentication (CIBA) Profile
OpenID Connect: Overview of Financial-grade API (FAPI) Profile 85

Generally speaking, Parts 1 and 2 and JARM are concerned with

hardening the implementation of OAuth 2.0 and OpenID Con-
nect, while CIBA provides a new means of requesting the authen-
tication of an End User. Each profile has implications for both the
API Provider and Consumer, which we’ll discuss below.
The Read-Only and Read-Write Profiles are effectively the “base”
specifications for organizations wanting to attest to the level
of security perceived as being required for operating financial
services APIs. The entry criteria is OpenID Connect 1.0; both
these standards use this as its core building block.

Adding Resilience: The Read-Only Profile

The Read-Only Profile is aimed at read-only access to an End

User’s account and introduces features that are carried into the
other profiles. The goal is to specify behaviors that the actors will
adopt when interacting to provide account-based data. These
include:

• Enforcing strong levels of authentication for Clients, in-

cluding Mutual Transport Layer Security (TLS) and a JSON
Web Token (JWT) based mechanism for authenticating the
Client at an application level.
• Enforcing levels of authentication for the End User, specif-
ically at Level 2 from the ISO specified Entity authentica-
tion assurance framework. This is important for providing
the Client application with certainty on how the End User
authenticated.
• Implementing levels of cryptography strong enough to pro-
tect the parties involved, such as enforcing minimum key
lengths of 2048 bits for RSA algorithms.
• Tightening up on other behaviors allowed inside the core
OAuth 2.0 specification, such as requiring that all redirect_-
uri settings are pre-registered at the Authorization Server.
OpenID Connect: Overview of Financial-grade API (FAPI) Profile 86

• Ensuring that short lifetimes are used for Access Tokens

that are bearer tokens, given the number of different end-
points they may be exposed to in an account-access sce-
nario.

At a very practical level, the Read-Only Profile also mandates

the use of JSON in request/response payloads. It introduces sev-
eral headers that allow consistent identification and tracking of
events, with the subjects being fairly typical in financial services
APIs:

• x-fapi-interaction-id: A UUID that provides a unique ref-

erence to be created for each request/response.
• x-fapi-auth-date: The date and time that the End User was
last authenticated by the Client application.
• x-fapi-customer-ip-address: The IP address of the End User,
if available.

The Read-Only Profile, therefore, provides standards for tighten-

ing the operating parameters to a degree deemed suitable for
the sharing of account access.

Bullet-Proofing: The Read-Write Profile

The Read and Write Profile adds further constraints that are
considered applicable for creating or updating account data
through – for example – initiating a payment. Arguably the most
important additional constraints introduced by the Read-Write
Profile are:

• Enforcing the use of a signed-JWT (JWS) to encapsulate

Request parameters when a Client application sends an
End User to the Authorization Server to be authenticated
OpenID Connect: Overview of Financial-grade API (FAPI) Profile 87

(the request parameter). We touched on this in our OpenID

Connect introduction. This is important as it adds cryp-
tographic proofs of the identity of the Client application,
meaning the Authorization Server can verify it. This is an
optional aspect of OpenID Connect that becomes manda-
tory with the Read and Write Profile. The standard also
specifies a REST API that can be used to send parameters
securely to the Authorization Server and then reference
them using the request_uri parameter.
• Mandating that Client applications are proved to be a “holder
of key.” Key-based authentication mechanisms (for the
Client) are permitted, through either Mutual TLS for OAuth
or a JWS minted from a private key. This improves security
as direct access to the private key must be sought by the
miscreant in order to impersonate a valid Client and is
enforced at both the Authorization Server and the Token
Endpoint.
• Increasing the End User authentication assurance level
to Level 3, enforcing multi-factor authentication which –
in the context of PSD2 – means multiple things the user
knows, possesses, or is part of them (“Inherence”), such as
a biometric gesture.
• Restricting the cipher suites that can be used for Mutual
TLS to reduce the risk of a compromised transport layer.

The Read-Only and Read and Write Profiles, therefore, provide

important general additional protections to both the API Con-
sumer and Provider. The JARM Profile looks to complement this
by protecting one of the more vulnerable areas of OAuth, namely
the exchange of authorization codes.
OpenID Connect: Overview of Financial-grade API (FAPI) Profile 88

Improving OAuth 2.0: JWT-Secured

Authorization Codes

The JWT Secured Authorization Response Mode (JARM) Profile

does – largely speaking – what it says on the tin; it aims to
secure authorization response parameters through the use of a
signed and optionally encrypted JWT. In this mode, a secured
authorization code is requested by the Client application, with
the Authorization Server providing the response signed using
a private key it owns. The Client application has access to the
public certificate corresponding to this key so it can verify the sig-
nature (if the JWT is signed and encrypted, the Client will require
access to both the signing and encryption public certificates).
The signing and optional encryption of the authorization code
delivers additional protections for the Client against code re-
play style attacks in an OAuth-only implementation, similar to
the benefits of the Request parameter in the Read/Write pro-
file. Arguably it is the least pervasive standard within the suite,
with Client-Initiated Backchannel Authentication breaking the
newest ground.

Decoupling Authentication:
Client-Initiated Backchannel
Authentication

Client-Initiated Backchannel Authentication (CIBA) is the latest –

and arguably most complex – of the FAPI profiles. It attempts to
address two of the primary sticking points in the Open Banking
ecosystem at the moment, namely:
OpenID Connect: Overview of Financial-grade API (FAPI) Profile 89

• To allow a user to authenticate and authorize an operation

on a different device to the one they are using. For example,
if an End User is using a desktop application but can only
authenticate via a biometric stored on a mobile device,
which is tied to the mobile operating system (rather than
an open standard like Webauthn.)
• To allow for multiple real human beings to authorize the
sharing of data or initiation of payment. This is important
as the majority of corporate internet banking implementa-
tions adopt an “x-eyes” approach to authorizing sensitive
operations, with associated workflows, queues, and notifi-
cations for the participants involved.

Both these needs are at odds with the majority of Open Banking
implementations. Most processes expect to redirect a single user
to perform the acts of authentication and authorization either
within the browser or via a claimed URL to a mobile banking app.
Some standards have loosely addressed some aspects of this;
for example, the UK standards exposes a “MultiAuthorization”
property in their Consent resource. However, the authorization
workflow in this scenario is a facet of the API standards rather
than the security protocol, which seems somewhat orthogonal
and relies on the client polling an API to discover changes in the
authorization state.
CIBA provides the flexibility to address these needs elegantly.
Rather than expecting a synchronous or semi-synchronous re-
sponse, CIBA anticipates an entirely asynchronous workflow:

• The Client application makes an Authentication request

to the Authorization Server, using a hint to indicate the
user they would like authenticated. The hint is provided
through knowledge known to both parties – an email ad-
dress, a shared identifier, or proofs-of-authentication pre-
viously offered, such as an ID Token.
OpenID Connect: Overview of Financial-grade API (FAPI) Profile 90

• If the Authentication request is successful, the Authoriza-

tion Server initiates backend workflows – either directly
or through other components – to ask one or more End
Users to authenticate themselves and authorize the re-
quest, through whatever means (mobile, desktop, etc.) are
required by their internal application infrastructure.
• When all required End Users have completed authentica-
tion and authorization, the Authorization Server calls the
Client application at a known webhook to indicate autho-
rization is complete.
• The Client application can then visit the Token endpoint to
retrieve a new token that allows them to access a protected
resource.

The workflow for Client-Initiated Backchannel Authentication (CIBA), the

latest FAPI profile.

There are permutations to this flow. For example, the Client

application can poll the Authorization Server if no webhooks
can be made available. But, the specification can offer Relying
Parties a completely decoupled means to request user authenti-
cation and authorization. This massively increases usability and
gives Clients many different options as to how they design their
OpenID Connect: Overview of Financial-grade API (FAPI) Profile 91

user experience with redirection no longer being a fundamental

requirement.

Final Thoughts

The prevalence of the FAPI is, of course, only as good as its adop-
tion. There will be a lag between Implementers Drafts becoming
available and their inclusion in supporting open source and
vendor solutions. Hopefully, adoption will continue to increase
as the suite of standards can only serve to provide more secure
implementation in Open Banking ecosystems.
Developers cannot view security as a static notion that, once
dealt with, can simply be marked “Done” and forgotten. Open
Banking ecosystems will continue to evolve, especially as we
move from solely banking-focussed APIs into the realms of Open
Finance. As such, how we define and apply appropriate security
protocols must also evolve. This is especially true when we
consider the role of digital identity and its relationship with the
OpenID Connect stack. The union of identity and “open every-
thing” ecosystems means security profiles such as FAPI will only
become more critical.
Case Study: Growing
Internal API Consumption in
Danske Bank
by Thomas Bush

Encourage adoption by improving the developer on-

boarding process and evangelizing an internal API
mindset.

An unfortunate truth of APIs is that they rarely sell themselves.

Even internally, many organizations find themselves met with
subpar adoption when they take a set-and-forget approach to
rolling out new APIs. However, the good news is that there are
plenty of ways to mitigate this, ensuring steady API consumption
among both internal and external developers.
Case Study: Growing Internal API Consumption in Danske Bank 93

In this chapter, we’ll look at three reasons an API development

team at Danske Bank — the largest bank in Denmark — saw poor
adoption of their internal APIs, and the steps they took to set
growth on a much steeper gradient.
We based this chapter on a talk given by John Madsen, API Product
Owner for Customer Information at Danske Bank, at the 2019
Platform Summit in Stockholm.

The Path Towards APIs

Before they adopted APIs, Danske Bank’s technical architecture

very much fit the stereotype of any bank: monolithic and slow-
moving. With some systems that were over fifty years old — and
continually expanding — it wasn’t easy to improve, fix, or build
anything. Not to mention, many of the systems were built on
outdated technologies. John jokes that many issues could only
be solved by that one specific person.
Naturally, this heavy IT architecture resulted in a poor speed of
change. It could easily take half a year, a year, or even longer to
develop new products and services. As a result, the organization
decided enough was enough — and it was time to untangle the
mess.
John briefly explains the process of how Danske Bank managed
to silo their technical systems into API-ready subdomains. To
start with, they divided their existing stack into three layers: a
foundational layer (mainly consisting of a system of records),
a process or function layer (providing meaningful data to con-
sumers), and an experience layer (responsible for individual
customer touchpoints such as apps).
Then, at the foundation layer, the bank broke down its system
of records across object-oriented subdomains — for example,
Case Study: Growing Internal API Consumption in Danske Bank 94

customers. Each of these objects then became the basis for an

API (or set of APIs).

Set-and-Forget Performance

Danske Bank was able to build an extensive suite of intuitive in-

ternal APIs after successfully abstracting away from the complex-
ity of its mainframe. Having created these APIs, they expected
consumption to grow, without all too much promotion quickly.
Unfortunately, the team was met with a slow, steady consump-
tion graph — and not the hockey stick curve they had hoped
for. John imagines that this is the case for many banks and
financial institutions that took the same approach. But what did
Danske Bank do wrong to be met with this sub-par internal API
consumption?

Identifying Setbacks… and Addressing

Them!

In hindsight, John identifies three particular setbacks in the

consumption of their internal APIs: old habits, friction, and a
lack of marketing. He explains each of these issues in-depth, also
discussing some of the solutions used to tackle them.

Old Habits

Despite a suite of brand-new, sleek REST APIs, the team found

that developers were unenthusiastic to change. This is because,
elsewhere in the organization, separate teams were continuing
to support alternative integration forms. The mentality of if I can
still use this point-to-point integration, why change? was rife.
Case Study: Growing Internal API Consumption in Danske Bank 95

The Fixes

A definite solution to this reluctance for change was simply to

deadline older integration methods. John found that developers
were quick to react and adopt the new APIs by announcing that
they would drop support for a specific point-to-point integration
in three or six months’ time. Of course, this harsh approach
requires managers’ buy-in, but the timeframes involved can
always be used as a bargaining chip.
Perhaps a more accommodating fix, the team also pushed for
changes in company culture. By encouraging others to build
longer-term solutions with the APIs — and defending the impor-
tance of doing so with managers — the team was frequently able
to nudge developers onto a more strategic course.

Friction

Developers who did want to adopt the new APIs were met with
another issue: friction. To start with, there was friction in dis-
covering the new APIs. Indeed, the team offered an API discov-
ery tool, but John says that simply too much “stuff” had been
pushed into there, leading to early frustration.
A subsequent cause of friction was security tokens. Developers
were unsure how to create them, which should come as no
surprise, as they knew that they were generated from the main-
frame. This made the new REST APIs difficult to consume from
separate platforms.

The Fixes

The natural solution to this friction was to improve the developer

journey. One particular pain point, John says, was everything
that led up to consuming the APIs: discovery, security tokens,
Case Study: Growing Internal API Consumption in Danske Bank 96

and more. By focusing on these areas and making the onboard-

ing process easier, developers were more likely to pursue API-
based solutions. One area Danske Bank did not struggle with
was API-specific documentation, but others might.

Marketing

It should come as no surprise that the team — a group of techies

“down in the dungeon” — completely overlooked the impor-
tance of marketing. Battling a tight schedule, they did almost
no promotion for their new APIs. Naturally, this meant fewer
developers knew the APIs existed in the first place.

The Fixes

The fix for this lack of marketing was simply: the team had to
get out and sell their new APIs. This meant knocking on plenty
of doors — development directors’, engineers’, architects,’ CIOs,’
and even business folks’ — and sharing their latest develop-
ments. John found that with each meeting, the initiative gained
momentum.

The Results

So, what were the results of Danske Bank’s many maneuvers

to improve API consumption? Fortunately, growth quickly sped
up. While it wasn’t the exponential growth John had hoped for,
he could sense that the new APIs were gaining traction through
the organization. Tell-tale signs of this new-found growth, he
reminisces, were when developers began to call him — saying
things like “I heard from him/her that you have some new APIs
— or when business folk began to invite him to present the new
APIs to others.
Case Study: Growing Internal API Consumption in Danske Bank 97

Summary

Even the best APIs can suffer from slow adoption. In this post,
we looked at three reasons why Danske Bank’s internal APIs
were slow to gain traction. According to John Madsen, a Prod-
uct Owner who fought on the frontline, old habits, onboarding
friction, and a lack of promotion are major causes of poor API
growth. With any luck, the solutions presented herein should
help to minimize these issues, ensuring sure and steady adop-
tion.
It Started With PSD2 and
Personal Data
by Chris Wood

EU regulation unlocked consumer data, stimulating

an open banking global response.

On the European FinTech stage, initiatives and regulations have

fostered tremendous innovation in the banking sector of the API
economy. The most significant of these is the Payment Services
Directive 2 (PSD2), a regulation that was applied across the Eu-
ropean Union and has resulted in a huge increase in the number
of APIs for banking products.
Making banks programmable is significantly altering the engage-
ment model for accessing a consumer’s account. What is less
It Started With PSD2 and Personal Data 99

clear is how this may affect the consumer themselves, including

their level of access to the data (that in theory they own), and
their ability to use their data in any way they see fit. In this post
we’ll look at how PSD2 and the growth of APIs for banking are
affectin affect personal data ownership.

The Status Quo

Most banks lock customer data away in internal systems with

very limited access, restricted to tightly controlled channels.
This state of banking data accessibility is widely viewed by in-
dustry commentators and even banks themselves as nothing
short of a travesty, epitomizing the hegemony banking giants
have held for a long period of time. According to Andres Wolberg-
Stok, global head of emerging platforms and services at Citi,
APIs present an opportunity to “break a few windows to let free
air and light in.”
While disrupters and innovators (especially challenger banks)
will be prone to hyperbola, the common consensus is that banks
should open up to provide APIs for a number of compelling
reasons:

• To enable consumer choice: There are many consumers

who want to be selective about banking products without
having to choose a single banking provider, instead simply
picking from a marketplace. APIs provide a mechanism to
enable such selectivity of product. Supporting this notion
is the great deal of coverage to the “narrowing” of banking
(where the portfolio of bank activities is restricted), as well
as the lack of trust millennials place in traditional banking
establishments;
• To unlock customer data: Internet banking has become
the key customer engagement point during the last two
It Started With PSD2 and Personal Data 100

decades, but the digitization of the customer experience

has made it clear that the vast majority of banks consider
this data to be a vault with only one entrance and two
sets of keys — theirs and the customers. This is juxtaposed
with the wants and needs of customers, who are keen to
exploit what is essentially their data in any number of dif-
ferent ways: Personal Financial Management (PFM), credit
checks, digital notarization, and more. However, banks
simply don’t provide facilities for third-parties to work at
the delegated authority of the customer, forcing many third
party solutions to use the customer’s internet banking lo-
gin credentials and web scraping to function (examples
include Mint and Xero). While this provides customers with
useful solutions, by sharing their credentials with a third
party they may actually break the terms and conditions of
their bank’s internet banking platforms;
• To unlock themselves: Anyone who has worked in the
IT department of a large bank will be familiar with the
architecture and approach that typifies them — extreme
risk adversity with large amounts of governance on top of
legacy systems and monolithic applications. An API-based
architecture, built incrementally with many small steps
could help unlock and decouple these architectures, mak-
ing them more accessible and providing an environment
to foster innovation.

The core theme is that banks could be doing much more to

open customer data up to new use cases and business mod-
els. Naturally there are disrupters and innovators who are hav-
ing some success trumpeting down the walls of Jericho, and
the Open Bank Project is clearly the poster boy for the open
banking movement. Another example is Figo in Germany that
delivers a single API that integrates with the German FinTS/HBCI
banking network. These initiatives show what can be achieved
without a standardized API network, but a lot of hard yards are
It Started With PSD2 and Personal Data 101

involved in creating the solutions with a myriad of different in-

tegrations across the banking ecosystem. Such efforts could be
significantly reduced if each bank offered a standardized suite of
APIs.

Regulatory Impact

The rationale for standard banking APIs is clear, and there has
always been the potential for a large bank to “break cover” and
offer a suite of APIs with access to customer data in advance of its
rivals. However, in the absence of this early mover encouraging
other banks to offer APIs by way of market competition, regula-
tory forces are now likely to coerce many into taking action.
PSD2 requires banks to allow third parties to access a given
customer’s data, where that third-party is acting as a data con-
sumer or a delegated authority: The EU describes these as “third
party providers (TPPs) [who] offer specific payment solutions or
services to customers”. As this could include making a payment
on a customer’s behalf, PSD2 grants third-parties considerable
power. There is a great deal of debate how this might be imple-
mented from a technical perspective, but an obvious solution
for anyone familiar with the API economy is the use of APIs to
facilitate access. Moreover, APIs could be coupled with a rich
framework such as JSON Web Tokens under the guise of OpenID
Connect to provide strong authentication and non-repudiation.
It is an oversimplification to say using APIs and OpenID Connect
would immediately provide the framework for implementing
PSD2, and some of the logical architecture has already been
framed: it includes the introduction of Account Information Ser-
vice Providers that will provide a single view across multiple cus-
tomer accounts. However, with the right governance framework
these technologies could provide the bedrock of a new open
It Started With PSD2 and Personal Data 102

banking landscape, supporting a wide range of new entrants to

the market.

The Open Banking (and Data) Landscape

The open banking landscape will allow customers to unlock

their data and give delegated authority to their payment instru-
ments, empowering them to share it with whomever they saw
fit via an API. The value in this unlocked data isn’t restricted to
banking — clearly other solution providers see much value in
it. For example, frameworks like Figo will become much more
commonplace with initiatives like PSD2 and possibly draw in
data sources that aren’t financial in nature, again via APIs.
Customers will have a single window on all their data, finan-
cial or not: while solutions already exist in this space, such as
Trunomi and Mecco, who offer federated personal data stores
and mechanisms to produce different views of an individuals’
personal data, the integration effort is fraught with difficulty.
With standardized APIs there is an opportunity to view, under-
stand, and control a unified view of our data.
The consolidation of our digital persona into a single construct
is both a risk and an opportunity for individuals: a risk, because
without the right governance we offer ourselves up to solicita-
tion on a huge scale, but an opportunity because we can enable
the genuine usage of our data for our own benefit, truly empow-
ering consumers to make insightful decisions. With such insight
at our disposal concepts like the Secco Aura could become a
reality for more people than just Secco bank customers, with a
broadcast of interests possible across many different service
providers, financial or otherwise. Such possibilities are so rele-
vant in the data sphere that large organizations like Visa Europe
are researching them, with their innovation lab currently run-
ning their “Me2B” theme. Howard Elsey, the innovation partner
It Started With PSD2 and Personal Data 103

running this theme describes such a personal data network as:

“the connective tissue and nervous system of the

data economy. This has ramifications into all cur-
rent areas of technical innovation, from big data to
blockchain, identity, and IOT but is so interesting …
because of the impact that it will have in overcoming
something that computerization has managed lose
— the personal nature and trust in the relationship
between business and the individual and the disre-
spect of third party companies that exploit the value
in an individual’s data without returning value to the
individual.”

In architectural terms, APIs underpin this framework as both the

personal data source, federated into what Mecco calls “the API
of me” and the service delivery point. However, there is a new
paradigm, the carrier for the broadcast of interests which, at
face value looks and smells like massively distributed publish-
subscribe network: the NATS technology for the personal data
network. It is to this network that both consumers and providers
broadcast their interests with APIs providing the delivery mech-
anism for data or services; requests can be serviced either di-
rectly from the consumer’s data stores or via aggregators that
pull together and consolidate the data in a myriad of different
views. Some initiatives already exist that could grow into the
backbone of this system, such as the Open Mustard Seed project,
but however it comes about, the “network of me” will make the
personal API economy truly revolutionary.

Final Thoughts

The opening of banking through APIs, whether through compet-

itive pressure or regulatory enforcement, has massive implica-
It Started With PSD2 and Personal Data 104

tions across the data ecosystem:

• for consumers it empowers their ability to access products

and their data;
• for solutions and services providers it allows them to
engage with customers in a much more seamless fashion;
• for IoT it provides the network for devices to make au-
tonomous actions based on an individual’s preferences,
wants, and needs.

It will take work to come to fruition but these are exciting times
for us all as consumers. It will be fascinating to see how banks
receive the PSD2 regulation, and how this personal data network
develops into the future.
Nordic APIs Resources

More eBooks by Nordic APIs:

Visit our eBook page to download these eBooks for free!

GraphQL or Bust: Everything GraphQL! Explore the benefits of
GraphQL, differences between it and REST, nuanced security
concerns, extending GraphQL with additional tooling, GraphQL-
specific consoles, and more.
How to Successfully Market an API: The bible for project man-
agers, technical evangelists, or marketing aficionados in the
process of promoting an API program.
The API Economy: APIs have given birth to a variety of unprece-
dented services. Learn how to get the most out of this new
economy.
API Driven-DevOps: One important development in recent years
has been the emergence of DevOps — a discipline at the cross-
roads between application development and system adminis-
tration.
Securing the API Stronghold: The most comprehensive freely
available deep dive into the core tenants of modern web API
security, identity control, and access management.
Developing The API Mindset: Distinguishes Public, Private, and
Partner API business strategies with use cases from Nordic APIs
events.
Nordic APIs Resources 106

Visit our Youtube Page for

Deep Dives

For more, watch full videos of high impact API-related talks on

our Youtube Channel.

Create With Us
Nordic APIs Resources 107
Nordic APIs Resources 108

Nordic APIs is an independent blog and this publication has not

been authorized, sponsored, or otherwise approved by any com-
pany mentioned in it. All trademarks, servicemarks, registered
trademarks, and registered servicemarks are the property of their
respective owners.
Nordic APIs Resources 109

Nordic APIs AB ©
Facebook | Twitter | Linkedin | YouTube
Blog | Home | Newsletter