PSD2: Blessing or Curse for Banks?

PSD2 is a new European regulation that forces all banks in the European Union to open up their systems to outside players. Banks have to offer 3 APIs free of charges to all 3rd parties approved by the ECB: Accounts, Transactions and Payments. By forcing banks to open up a number of their core systems, the ECB hopes to stimulate innovation into the financial industry through an open API ecosystem.

So it’s quite obvious that PSD2 offers a lot of potential for fintechs and other 3rd parties: they no longer need to negotiate with every bank individually for access and no need any more to rely on grey area techniques such as screen-scraping for getting financial data.

But is PSD2 also an opportunity for the European banks? The story that follows next is about banking, but similar analogies can be made to any other industry.

PSD2: Blessing or a Curse for Banks?

PSD2 brings a lot of challenges and investments for banks without any financial compensation in return:  they have to invest in an API gateway, API security, modernizing some of their core systems to expose APIs, etc. and they have to offer the same performance for their APIs as for their existing banking app and website (meaning no throttling allowed). So, as bank, you can definitely consider PSD2 as a legal obligation similar to GDPR.

On the other hand you can also see it as a first step in opening up your core systems and becoming a digital player. If you were planning to strive for an Open API business strategy, than the PSD2 investments are anyway necessary. PSD2 forces you to offer the 3 APIs for free, but PSD2 also doesn’t prevent you from monetizing other APIs (credits, investments, identity, etc.)

An Open API Ecosystem

There are roughly four different roles an actor can play in an open API ecosystem:

• You can be ignorant to any open API ecosystem in your industry
• You can be the consumer of APIs offered by others and use these in your solutions and products to offer higher added value services to your customers.
• You can be a provider of APIs: either you get revenue from your APIs directly because you monetize them.  Either you use APIs as a way to increase the attractiveness and added value of your existing products and you use APIs as a way to increase their sales.
  • If you are active in a regulated industry, you might also be forced provider. Maybe you don’t believe in APIs at all, but you have to offer them to be compliant.
• You can act as platform: linking providers to consumers, aggregating providers, allowing different providers in the industry value chain to exchange information through your platform etc.
  • It’s hard to become a platform player but once you are a platform you can tap in the economics of scale and have a very high competitive advantage over everybody else.
  • Most of the successful Silicon Valley companies are platform companies (Google, Uber, Facebook, etc.). If this subject interest you, I highly recommend to read the book Platform Revolution.

Of course a given company can take up multiple roles: it can act as consumer, provider or platform at the same time.

Next to the roles you take up in an Open API ecosystem, each company is also influenced by its digital maturity. Ranging from being a digital immigrant/ignorant to a digital native company. This is all about the business-IT alignment and the IT awareness on business level. Does business consider technology to be the problem of the IT department or do they really see technology as a strategic differentiator. Of course: the more you shift towards being a digital native provider, the more you transform into an IT company.

Coming back to banking and PSD2: banks can look to PSD2 in multiple ways depending on their digital maturity on business level. Ranging from: 

1. It’s a legally obligation like GDPR; I only do it to be compliant 
2. It allows me to engage more easily in partnerships with FinTech's 
3. It’s an opportunity to start monetizing certain internal digital capabilities 
4. I am the heart of a digital platform that allows organizations to exchange digital capabilities with each other

Banking 2.0

So how will the bank of tomorrow look like? For sure the bank of tomorrow will be different than today. Competition will become tougher. In the past, the main competitors of a bank were others banks: they had a similar historical background, similar way of operating, same compliance rules to follow, etc.

But the playing field is changing: new entrants with new business models driven by modern technology are entering. These new entrants will take over a part of the industry value chain (probably the most profitable part). So as a bank, like it or not: but you will have to become a full digital player. This also mean that if you would no longer be an ‘A’ player, you cannot have ‘A’ level ambitions. Either you lower your business ambitions and your positioning in the industry value chain, either you improve your technical maturity. 

In essence, there might be nothing wrong if you settle in a role as utility provider. You offer the mandatory APIs as dictated by PSD2 and you remain responsible for the core banking and you ensure that the necessary compliance is met. But being an utility provider means that others will build (innovative) solutions on top of you. The customer might no longer see your ‘products’ but will actually mainly make use of the products build on top of you. So the main risk is that you will become easy interchangeable by other utility providers. Margins will be under pressure and in order to succeed as utility provider an operational excellence strategy will be important.

If you want to successfully compete against the digital native new entrants, it’s important to have an alignment between your digital maturity on business level and your ability to execute on technical level. A high ability to execute on technical level without any digital business strategy will only frustrate your technical high-potentials and you will lose them. A strong digital vision without technical skills to realize it, will not work neither.

How to Transform?

In order to successfully transform into a digital player, it’s important that you evolve on 3 axes:

• Culture & People
• Technology & Skills
• Technical debt

Culture & People: “Culture eats strategy for breakfast.”

If you have strong digital business ambitions, you will have to compete against digital native providers. Requiring 12 months to construct an API in a semi-waterfall process will not work. You need to evolve towards an agile way of working: from big bang releases, to a continuous stream of smaller releases allowing you to pivot and fine-tune your digital products rapidly based on customer feedback.

This also mean that you should no longer rely on the cheapest IT resources you can find on the market. You should know and accept that IT and software development is an engineering discipline were talent and creativity makes the difference. You should also question why you outsource the development of strategic applications: Google would also never outsource the development of its search-engine, Google Maps, etc.

Technology & Skills

Start investing more in modern technology and the skills to support it. Don’t expect to win tomorrow’s battle with yesterday’s technology. You might have relied for decades on pre-relational DB’s, batch processing, Cobol, etc. But day+1 updates are no longer OK, customers are now expecting near real-time updates and processing, machine learning based assistance, etc. Your legacy stack might be fine for yesterday’s requirements, but I highly doubt it will help in solving tomorrow’s challenges. And even if you are convinced your legacy stack is still perfectly ok, don’t think it will help in attracting new technical talents.

More concretely if you want to become a competitive API provider, you should definitely invest into the following technologies:

• API Gateway: for the secure exposure of your different internal APIs. Next to handling security, a gateway will also offer throttling, metrics, 3rdparty management, etc.
• API Sandbox: a fully isolated environment that allows others to test your APIs. Ideally this sandbox is fully disconnected from your actual production environment and works on fake data. An API sandbox is an ideal platform to attract new 3rdparties: they can easily test and evaluate your APIs.
• API Portal: your APIs need a ‘shop’ were all the documentation, usage and billing metrics are available for 3rdparty consumers.
• Modernize your architecture: is your current architecture and way of working scalable to handling a massive load increase needed to process the API requests of 1000s of 3rdparties? Having APIs with a good performance will be a crucial non-functional for successfully becoming an API Provider.

Technical debt

If you made the explicit choice or implicit because you just ignored your legacy: Having technical debt is a choice. Don’t cover yourself behind being in business for decades. If an assembly line in production environments would still rely on production practices from 20 years ago or make use of equipment /machines of 30 years ago they would also suffer. It’s important that the business is also aware of the impact of technical debt. It’s not sufficient to invest in modern technology if it is being built on decades of legacy held together by duct tape.

In the past banks were lucky that their competitors had the same historical legacy and issues. But the new entrants in the market will have not. So they should act.

Conclusion

Marc Andreessen already said this in 2011: Software is eating the world. The competition in the financial sector will become more fierce. PSD2 is forcing all banks to offer open APIs, it will allow an entire new ecosystem of technology driven products and solutions to exist. Banks need to determine their role and positioning in this new open API ecosystem. But if they don’t want to fall back into an ‘utility’ positioning, they will have to increase their IT skills and expertise. If not,  the new players in finance will benefit the most of the PSD2 opportunities.

About the Author

Pieter De Rycke is an IT architect with multiple years of professional experience in SOA, APIs, micro-services, ... Pieter is a huge believer in the new opportunities made possible by modern technology. He is always open to share his vision and his insights on how to apply modern technology to make the difference on business level. Pieter blogs here.