Embedded finance describes financial services, such as payments, that are integrated directly into the offerings and processes of non-bank and non-financial service providers. The integration should be real, not just a simple link to an external service. An example here would be an insurance service that also handles the payments for you when needed.

Banking-as-a-service, or BaaS, is a subset of embedded finance, which focuses more on allowing companies to offer their banking services. For a more thorough discussion, please see this recent post.

Embedded finance has entered into many areas over the last few years. One of my favourites is how it can significantly simplify parking payments.

For example, with APCOA, your licence plate is automatically recognised when you drive into a parking garage. Upon leaving, you can pay the old-fashioned way at a payment machine or without user interaction (that is, if you've got the app installed and have pre-chosen automatic payments). If you choose to do neither, you get a text message about how to pay with the app, and after 48 hours, you'll be sent a paper invoice.

This type of embedded finance has also extended to street parking, with an example being the Swiss TWINT+, which can charge you based on your tracked location via the app.

Another Swiss service using embedded finance is KLARA Home, which offers a service for managing domestic workers as private citizens.Using their service, you can hire people, provide work contracts and wage slips, do social security contributions, insurance, and even log working hours and expenses.

This is a truly interesting service, as it helps avoid having to pay people under the table for doing work on your home. Going from paying someone undeclared to following the rules is only marginally more expensive, yet much more secure both for the person doing work and the employer.

But what do you do if you don't trust your customers?

If you are a regulated entity, you're required by PSD2 to secure transactions and by GDPR to limit access to customer information. Some embedded finance providers might not even deal directly with the final service provider but have a different company in between (typically an integrator or tech platform). The relationship is regulated embedded finance provider - embedded partner - the corporate customer - end user, in other words, a B2B2B2C offering. The issue is that there is no direct relationship between the embedded finance provider and the company providing the final service. 

Here are some examples of what a genuinely malicious service provider can do:

• Fake transactions on behalf of customers
• Sign up fake or impersonated customers
• Access information such as transaction records and balances for end users not signed on to their service

An example of this is an online gambling company doing transactions on behalf of the end customer without adequately informing the end customer. The final responsibility for fraud is the embedded finance provider, as they're the regulated company. While implementing Strong Customer Authentication and Know-Your-Customer can help a great deal here, it also requires that embedded finance providers are cautious when implementing their APIs and other procedures. 

Embedding payments into services allows for truly innovative new services. The challenge here is to keep the services secure and enable services that the end customer finds trustworthy. 

Some key takeaways:

• Banks and payment service providers should participate in service offerings to better understand the requirements.
  
• On the technical side, APIs should be differentiated, so only a minimum of information gets shared with the service provider.
  
• Strong Customer Authentication (SCA) and Know Your Customer (KYC) must be handled by the payment service provider.
  
• If you're an embedded finance provider, you should remember that in addition to payments, you're also a provider of trust and identity services.
  
• Branding new services are important as it lets end-users know that established companies offer payment services.

Perhaps the most critical advice is that embedded financial service providers must be involved with the service, not just an API provider. While a technical solution can solve many security requirements, a malicious customer might always be able to exploit your service. 

As always, if you need a partner for Strong Customer Authentication, we're here to help.