Back to stories

From Open Banking to a complete financial workflow: Why embedded banking is the next natural step in your journey

Learn why Open Banking falls short for B2B payments, what changes when you embed the banking layer, and how to move from insights to fully owned payment workflows inside your platform.

500,000

homeowners communities managed

80%

of property managers in Spain using it

40%

reduction of banking cost for communities

Industry

Use case

Location

Most platforms start with Open Banking, but eventually realize it wasn't the right infrastructure for payments, especially in B2B where variable amounts, bulk payments, and reconciliation complexity don't fit into what Open Banking was designed for.

Open Banking is a strong starting point, right up until users need to make a payment. That's when there's a change in their experience: from smooth to clunky, unpredictable, and unreliable. And no matter how much teams try to optimise around it, the frustration keeps coming back. Because the problem isn't in your product, it's in the infrastructure underneath it.

In this article, we'll explain what Open Banking can do for your platform, why it struggles with B2B payment initiation, and why Embedded Banking has become the natural next step for software platforms when it comes to integrating financial services.

Understanding Open Banking: Account Aggregation vs Payment Initiation

We often hear about Open Banking as a catch-all term, but it actually covers two fundamentally different capabilities: Account Aggregation and Payment Initiation. They do different things, deliver different outcomes, and when it comes to payments, that distinction matters more than most companies realise.

In a nutshell: Account Aggregation (AISP) is the first step, as it gives you visibility into user financial data, whilst Payment Initiation (PISP) is what enables payment. Here's an explanation in detail:

AISP (Account Information Service Provider) allows companies to read account data including balances, transactions, and account details. It lets you access account data from a user's existing account, with their consent. But the value goes beyond just seeing data. In fact, AISP can educate your product decisions by providing in-depth knowledge of transactions and spending habits of users. It also helps with segmentation and sales opportunity detection: you can see which users are increasing their revenue and which are processing the most payments.

Let's say you're building an accounting software for freelancers. With AISP, a freelancer can connect their banking or business accounts to your platform, and you can read their incoming and outgoing transactions in real time. Your platform can display that data, categorise it, and surface insights. But to actually make a payment or transaction, your user has to switch to their banking app. That extra step breaks the experience they have with your product and reminds them that your platform isn't yet the one place they can do everything.

That's where PISP (Payment Initiation Service Provider) steps in. It allows you to initiate a payment from a user's account to a recipient's account, with their authorisation. Still,  there's a fundamental gap: it only makes it possible to initiate a payment, and not actually own it. Here's why:

As soon as your platform sends a payment request, you lose control over it: the external bank owns the approval, the execution, and the errors. When a payment fails, you have no visibility and no way to fix it. PISP also only handles one transaction at a time, and since bulk payments were optional under PSD2, most banks never built them. And there’s more: every payment redirects users to their bank's interface, re-authentication is required every 180 days, and each extra step pushes them closer to abandoning the payment altogether. This is a known problem, and regulators have been trying to address it.

PSD3, the successor to PSD2, will introduce mandatory bulk payments, enforceable API standards, and streamlined authentication flows across Europe.  But it won't arrive before 2028, and it still doesn't resolve the fundamental issue: banks have no financial incentive to invest in API quality. It tightens the rules, but incentives remain unchanged.

A real life example: Why fulll moved beyond Open Banking to embed the workflow

fulll, a financial operating system for accounting firms and SMBs, tried Open Banking as their only financial infrastructure, but they quickly discovered it wasn't enough. They set out to build a single platform where financial services, payments, and accounting would finally work together, combining Open Banking for real-time account data with an external payment processor for invoice collection. But transactions arrived late, reconciliation broke constantly, and SMBs had to manually move finances between tools just to pay their suppliers. Instead of simplifying financial operations, it added a new layer of complexity.

"Originally, we wanted to aggregate all bank accounts via Open Banking and integrate payments into our clients' journeys. For accounting firms, we also needed these elements to reconcile cleanly. But Open Banking proved unreliable for handling multiple payments." — Thomas Petitberghien, Lead Product Manager at fulll

So fulll made a decisive shift: instead of connecting to financial services from the outside, they embedded it. By partnering with Swan, they brought accounts, payments, and reconciliation into the same platform their users already worked in. The result was exactly what they had been trying to build from the start: a single workflow where banking and accounting happen together, in real time. See how fulll built it with Swan.

Embedded banking: what changes when you control the infrastructure

Embedded banking is a financial infrastructure integrated directly into your platform, allowing you to provide accounts, payments, and cards through your product, so users can also run financial operations there. Unlike Open Banking, which connects to accounts that live elsewhere, embedded banking makes finances a native part of your platform. And if payment initiation in Open Banking has significant limitations for B2B, owning that infrastructure isn't just a nice upgrade: it's the only way to become the financial powerhouse for your customers.

Here's what changes when you own the infrastructure:

1. Compliant-by-default

Building embedded banking without a partner means obtaining a banking licence, hiring a dedicated compliance team, and absorbing significant costs, a process that can take years before you serve a single user. With an embedded banking provider like Swan, compliance comes built-in: identity verifications, anti-money laundering checks, and all regulatory requirements are handled at the infrastructure level, so you can move fast without building the compliance layer from scratch.

2. More ways to pay, built for the complexity of B2B transactions

Embedded banking goes far beyond standard bank transfers. Your platform can offer SWIFT transfers to over 40 countries, standing orders for recurring flows, and SEPA Instant for speed. And when your customers need to pay multiple suppliers at once, they can do it in a single consent flow, which is a core use case in B2B Payments.

3. One product, one place, everything your customers need

With embedded banking, you build and host the entire workflow, from account creation to payment execution and reconciliation, directly inside your product: no redirects, no app-switching, no friction. And because everything happens inside of the software you own, your users never have to rely on an external system. The more financial operations they run through your platform, the harder it becomes to replace, making your software indispensable.

Where to start and why now is the right time for your business

If you already use Account Aggregation (AISP), you're further along than you think. The best approach is to keep it and leverage everything you've learnt about your users to build your embedded banking layer. The next step is simply to embed payments directly into your software, so you can finally own the full workflow.

To win at B2B payments, embedded banking isn't optional. Payment initiation within Open Banking has significant limitations that banks have little incentive to address, and PSD3 isn't coming until 2028. The longer you rely on infrastructure you don’t control, the more your product depends on someone else’s system. This is why many platforms are starting to move towards embedded banking now instead of waiting for Open Banking payments to get better.

Ready to take control of your payment infrastructure? Talk to our team at Swan. We'll help you find the right approach for your platform.

Anastasiia Glotova
March 30, 2026
Share article

Summary

Customer stories

How Europe’s leading business platforms use Swan

500+

Lorem ipsum dolor sit

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Discover customer story

500+

Lorem ipsum dolor sit

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Discover customer story

500+

Lorem ipsum dolor sit

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Discover customer story

To use Apple Pay you need a supported card from a participating card issuer. To check if your card is compatible with Apple Pay, contact your card issuer. Apple Pay is not available in all markets. View Apple Pay countries and regions. Features are subject to change. Some features, applications, and services may not be available in all regions or all languages and may require specific hardware and software. For more information, see Feature Availability.