Embedded finance can enable a wide variety of business opportunities, but the future potential is often unknown to business customers. How can incumbent banks showcase the opportunities that APIs could offer, to business people in order to stretch their imagination and stimulate innovative thinking?

Continuing with our series of embedded finance interviews, we spoke to Koen Adolfs, Head of API Portfolio | Future Customer & Payments Domain at ABN AMRO, to find out how they are approaching the problem.

We all know ABN AMRO, and people in the open banking space probably all know Koen Adolfs. You have been taking the lead for almost 10 years in adopting APIs and open banking. What makes the current embedded finance offering so different from what you've already offered in the API developer portal so far?

That's an interesting question because it's not so different, and it is. So, it's both.

We have created the ABN AMRO Developer Portal. We started with offering the Tikkie API, to be followed by the PSD2 APIs, and with time passing by a growing set of other solutions.

The developer portal is great to showcase our APIs and what they can offer. However, to get third parties to use your API, you often need to attract several people, both on the business and technical side. Especially attracting business people to your technical solutions requires attention. Where do you share what information?

With Tikkie, for example, we have found a great user journey to do so. On the Tikkie website we tell the story of how corporate customers can use Tikkie via the Tikkie Portal, App, and API. Similarly to what Meta is doing with its WhatsApp/Instagram business pages and their developer portal, for the Tikkie API, we are redirecting visitors of the Tikkie business pages to the technical pages on the ABN AMRO Developer Portal. That is a flow I am very fond of, and works well.

We didn't have a similar convenient flow on our own main ABN AMRO website. A link to the developer portal was there, but it was hard to find, and it was also hidden under the chapter innovation. It took quite some convincing in the organisation that it was no longer an innovation project. With the growing interest in the market for embedded finance, we saw an opportunity to showcase that we are already doing embedded finance in so many ways.

We have business account APIs, PSD2 APIs, the Tikkie APIs, and foreign exchange trade services. Beyond these, ABN AMRO has more solutions and is working on innovations that could become APIs in the future. We had a good and complete offer ready for publication on abnamro.nl, to funnel the partners and API conversations and to tag them with a business term that triggers interest. We have open banking, and honestly, I see Banking-as-a-Service and embedded finance more as business-friendly terms for what we want to achieve and wanted to achieve for years.

Open banking and PSD2 triggered a debate and a claim of FinTech to share all our data for them to build superior customer experiences with that data. Banking-as-a-Service is also a business that takes place more behind the scenes, looking at providing white-label products. Embedded finance, on the other hand, is much more a matter of finding new cooperation models and partnerships.

So, am I correct that you would define embedded finance as kind of an umbrella term over banking-as-a-service, open banking offerings, etc.?

It is a difficult question. Because, for me, the definition is not the relevant question to ask, it doesn’t really matter. There is an overlap between these terms, and in the end, companies need to integrate, and ultimately, an API is the technology to do so, and the developer needs to know which API to use.

I look at how I can trigger partners and third parties to start having the business conversation with ABN AMRO so that in the end, the developer is going to integrate with our APIs. Embedded finance is a more friendly term internally and externally on how to cooperate in that sense.

Our current API portfolio targets corporate customers and partners of ABN AMRO. With embedded finance we spread the word how we can collaborate for success. Using our APIs and other solutions, we help them to unlock new revenue possibilities and enhance customer experiences by seamlessly integrating ABN AMRO’s products and services.

Embedded Finance of ABN AMRO is for companies looking for a new way of doing business through financial integrations. Via the Embedded Finance integrations (Embedded Services), banking services can be offered directly to end users without navigating to a bank's digital environment (app or website).

I see a lot of opportunity in building more API propositions on top of the existing portfolio, but it takes time to build the right business propositions and technical solutions. Embedded finance is not as a stand-alone proposition. Propositions should work seamlessly together across own channels, solutions and third-party integrations. This means a lot of things need to come together to offer a successful API product to the market. Nonetheless, as said before, we already have great propositions to offer and see third parties build great innovations on top of them (see: use cases).

What I consider one of the fundamental differences between the traditional open banking offering and embedded finance today, is that the open banking offering mostly focuses on payments, which is relatively commoditised and straightforward, whereas embedded finance also looks into credits, etc., where you give much more ownership to your partner.

OK, but where in the terminology of open banking was there a limit to payments? We made it something about payments because PSD2 was said to be open banking. In my perception, and in the older strategy documents that I created for the bank in 2014-2016, open banking was already a broader term.

Point taken. So I can imagine that the additional ownership that banks hand over to their corporate clients to serve their end customers can be an issue in terms of risk management or perceived additional risks, compliance etc. How do or did ABN AMRO look at that challenge, for example, in the context of an embedded finance value proposition in the lending space?

We have propositions to make the payment processes more convenient today, and APIs to improve the safety of business accounts, and for each service, we defined the operational model, the onboarding process and security etc.

Although ABN AMRO offers multiple lending solutions, we don’t have a lending embedded finance proposition yet the way I would like it to be. So I don’t have a specific answer to risk management, perceived additional risks, compliance, etc.

However, looking at the API products we do have, one can see the onboarding processes are different per product. This is for a reason. Looking at, for instance, the FX trade service in our API offering, we just showcase rates of ABN AMRO’s currency conversions. So, basically, everybody can now be onboarded, as the currency conversion itself will happen via our own channels. This process is different when someone wants to use the Business Account Payment API to initiate payments. The same will be true in case we would build a lending offering via an API.

Just like when we develop applications for our own channels, the products are different and so risk and onboarding processes are different as well. In the case of open APIs, open finance, open banking, or embedded finance, no matter its tag, you still need to go through the same development cycle to define the products and detect the risks, internally and externally, and find out the optimal way of building a great service.

That said, I would like credits to be a proposition on the portal, but we're not there yet.

Regarding the biggest challenge in embedded finance, I raised a poll a couple of weeks back in Innovation in Payments, my LinkedIn group. That poll showed that 55% of respondents saw compliance as the biggest pitfall. Another 23% said it's technology. What's your take on that?

I think that both are true. I also have those conversations internally. Can you do embedded finance without APIs? My personal position is you can't. Alternative technology solutions like widgets are not scalable, it's old technology, and it does not allow others to embed you in their proposition.

An API, in my view, is a digital contract between two parties and how you cooperate. And that's also where compliance and technology come together. Because finally, in the digital contract, which is technology, you make the agreements between two parties, what you can do and what you cannot do once you get onboarded.

So compliance and technology are connected, and so is the business mindset. That's my personal addition to this. It requires an organisational transformation inside out to build an embedded finance offering successfully on every level: business-technology-compliance. Everything needs to be connected in one digital contract that you are not going to create for a short-term win. But once it is out there, it is for years to be supported and to be integrated and should be stable, reliable, scalable and secure.

So the biggest challenge is about internal alignment rather than pointing at certain departments?

Yes, exactly. That is basically also the transformation that I try to achieve: how can we change the internal culture of the bank in favour or an API-friendly environment? So once you have done that, eventually, you can make steps outwards as well, based on the change that you already made.

Earlier this year, Roland Berger published a report stating that the biggest concerns in embedded finance for consumers are data security with 61%, transparency about service conditions and pricing (42%), and trusting the company security stability (33%). Does this sound familiar to you? And more importantly, does it make sense or is the wrong perception by consumers according to you?

These perceptions are totally valid. A lot of industries have proven that companies cannot be trusted in many ways. Just think about cases like Facebook and Cambridge Analytica.

Looking at my personal situation: at my own house, I have more and more smart applications connected with APIs. I hope that Philips Hue, Apple, Google, and Home Assistant are protecting my house correctly. They have a technology that I trust because the technology stack is quite similar to what we have in the bank, or I have under my control. However, I also have a doorbell camera, which I disconnected from the internet because I know it's a Chinese brand. I can only access it locally.

So as a consumer, I also think about that in different domains based on what I hear in the news, etc.

Regarding banking, customers have also been educated for all the valid reasons that you shouldn't share your bank details with everybody and that you should keep your codes safe. Basically, that's also where the whole PSD2 regulation started from: to secure and better secure screen scraping.

One last question. What makes your proposition, so different from other companies that position themselves in the embedded finance market?

We were the first major Dutch bank to launch a developer portal. Many other banks looked at it, saw the value and made similar kinds of iterations. Own versions of the Tikkie API (payment request services) were also included in those developer portals, which makes sense.

Just like they are, we are, of course also keeping an eye on the competition and constantly evaluating what they offer and how we can navigate our own organisation to have the right propositions. So you could say, banks can be boring because the offerings are growing to be alike. That's basically because a lot of smart people are looking at what customers want and what we can offer to fill those needs. However, the choices that you make within the offer can be different from provider to provider.

If I look at Tikkie, we see that we provide a bit more flexibility in branding for third parties compared to when you would be sending a Rabobank payment request or an ING payment request. So, branding-wise, there can be a difference, although the functionality can be similar. In the mind of the customer, that can be a big difference.

What I find interesting, though, is non-banks, technology-based companies that didn’t have a front-end that start an embedded finance offering. They don’t have their own brand to protect, and their core business is to be embedded. There I see differences in terms of positioning and how comfortable people are with these propositions.

I've studied partnerships and learned that there are a lot of scenarios in how you can partner. There are also a lot of types of relationships people have in their personal lives, and the same is true in business. If you don't feel the need to protect your branding in a market, then you don't feel the need for a certain branding strategy in relation to the APIs you offer. The result is you are more likely to take a different position in the market of digital ecosystems.

To come back on Tikkie... What I'm happy about is the creativity which I see currently on some of the API iterations that we built in 2017. Jumbo supermarkets just released recycling machines, where you can deliver your cans and your plastic bags and get a Tikkie refund via a QR code. That is physical-digital-QR-connected, and both Tikkie and Jumbo are contributing to sustainability.