Open Banking APIs Explained: What PSD2 Compliance Actually Requires From Your Engineering Team
Every fintech founder we talk to eventually says some version of the same sentence: "we just need to connect to the bank's API." It sounds like a single integration task on a roadmap. In practice, it's a compliance program with an API attached, and the gap between those two framings is where a lot of engineering timelines quietly blow up.
We've built open banking integrations across payment initiation, account aggregation, and lending products in the UK and EU markets, plus US equivalents through providers like Plaid. This post is the technical walkthrough we wish more teams had before they scoped their first sprint — what PSD2 actually mandates at the API and architecture level, where the real engineering effort lives, and where teams consistently underestimate the work.
What PSD2 actually is, in engineering terms
The Second Payment Services Directive is an EU regulation, not a technical spec. It mandates that banks (Account Servicing Payment Service Providers, or ASPSPs) provide regulated third parties with API access to customer account data and payment initiation, provided the customer has consented. The regulation itself doesn't dictate exact API shapes — that's what the technical standards built on top of it, primarily the Berlin Group's NextGenPSD2 framework and the UK's Open Banking Standard, are for.
