PSD2 is, at its core, a data portability regulation dressed in financial services clothing. The right it establishes — a customer's right to share their bank account data and initiate payments from it with authorised third parties — is architecturally significant, but the regulation says nothing about how reliably banks must implement the APIs that make that right exercisable. The OBIE's implementation standards improved this materially in the UK, but the gap between a well-designed Open Banking API and a production payment product is still substantial, and it is commercial infrastructure — aggregation, fallback handling, reconciliation, identity — that bridges that gap.
Consider what a business actually needs to collect payments via Open Banking in late 2020. It needs a connection to the UK's nine largest bank APIs, each with their own authentication UX, session token behaviour, and error response taxonomy. It needs fallback logic for when those APIs return ambiguous errors that may indicate a failed payment or a timeout. It needs reconciliation tooling to match payment receipts against invoices, because the payment reference field in Faster Payments is limited and often truncated. It needs identity verification at the account level to confirm that the payer account matches the expected counterparty. None of this is provided by PSD2. All of it must be built or bought.
The commercial layer above Open Banking is not yet a mature market. There are aggregators who provide connectivity to bank APIs — typically charging a fee per call or per payment — and there are point solutions for specific use cases like mortgage application data retrieval or invoice reconciliation. What does not yet exist is a comprehensive infrastructure stack that covers connectivity, reconciliation, identity, and dispute resolution in a coherent product. The analogy to early cloud infrastructure is imperfect but instructive: the raw compute existed, but the tooling — logging, monitoring, cost management, identity — had to be built piece by piece before cloud became genuinely usable for production applications.
We are particularly interested in the reconciliation and cash application layer. The fundamental problem for any business collecting B2B payments is matching received funds to outstanding invoices. In the card world, this is partially solved by payment processors who pass a reference. In Open Banking, the Faster Payments reference is free-form and limited in length, meaning large payment operations routinely deal with unmatched receipts that consume significant operational time. Solving this with deterministic logic — using account number, sort code, expected amount, and timing to probabilistically match receipts — is a genuine infrastructure problem that has been poorly addressed. The companies building this well will have a long sales cycle but exceptional retention: once a mid-sized business has integrated its receivables workflow around a reconciliation system, switching costs are high.
The identity layer is equally underbuilt. PSD2 authentication establishes that a customer has consented to share their data, but it does not verify that the account holder is who they say they are for AML or KYC purposes. The connection between an Open Banking session and a verified identity remains a manual step in most implementations — often involving a separate identity verification product and a review queue. Infrastructure that closes this loop, verifying account ownership and identity in a single consented flow, will be essential as Open Banking migrates from a data-sharing mechanism to a payment and credit infrastructure. We expect significant investment in this layer over the next several years.