Open Banking, Open Finance and Embedded Payments

Open banking proved that regulated access to financial data changes who can build financial products. Open finance extends that logic well beyond payment accounts, and embedded finance puts banking-like services inside non-financial products. For a firm on any side of this — bank, fintech, or a business embedding payments into its own product — the strategic question is how to position for a shift that is part opportunity and part obligation, and whose regulatory shape is still settling.

Where the regulation actually stands

The EU is mid-transition, and the detail matters for planning. The revised payments framework — PSD3 (a directive) and the PSR (a directly applicable regulation) — reached political agreement in late 2025 and is expected to apply from around 2027, tightening open-banking API performance, fraud and authentication rules and merging the e-money regime into the payment-institution one. The broader open-finance step, the Financial Data Access framework (FIDA), was separated from the payments package and remains on its own, slower track — extending data-sharing beyond payments to savings, investments, pensions, insurance and more, and creating a new class of information-service providers, most likely operational toward the end of the decade. The practical reading is that payments-side change is near-term and open-finance change is real but further out, and both reward firms that build for data-sharing as a capability rather than a compliance afterthought.

The opportunity and the obligation, together

Open finance is a two-sided change. For firms that hold financial data, it is an obligation — you may be required to make data available securely, with consent, through regulated interfaces, which is an engineering and governance commitment. For firms that can use financial data, it is an opportunity — to build products that were impossible when the data was locked inside incumbents. Embedded payments and finance sit on top: the ability to offer payment, lending or insurance inside a non-financial product, which turns a software business into a distributor of financial services with the compliance weight that implies.

What to actually build for

• Treat data-sharing as a capability. Secure, consented, well-governed APIs are the foundation of both the obligation and the opportunity; building them properly once beats retrofitting under a deadline.
• Get consent and permission governance right. Open finance runs on user consent to share data; the systems that manage, evidence and revoke that consent are where trust and compliance both live.
• Understand what embedding finance actually imports. Putting payments or lending in your product imports regulatory obligations, partner dependencies and fraud exposure; the convenience hides real weight.
• Watch the two clocks. Payments-side rules are near; open-finance rules are further out. Plan for the sequence rather than treating it as one event.

Open finance and embedded payments are reshaping who provides financial services and how. The firms that benefit build the data-sharing, consent and integration capabilities deliberately — positioned for the near-term payments changes and the later open-finance expansion — rather than waiting for each obligation to force a scramble.

Who this is for

This reading is for:

• CTOs and product leads at financial and fintech firms
• Boards weighing the open-finance opportunity and obligation
• Compliance leads tracking PSD3, the PSR and FIDA
• Non-financial firms considering embedded payments and finance

Sixteen Pillars helps firms build the data-sharing, consent and integration capabilities open finance rewards, positioned for the near-term payments changes and the later FIDA expansion. Pricing is published at /pricing/. If this is live for your organisation and you would like an independent reading, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.