Open banking's first challenge was earning the customer's permission

Open banking businesses needed to turn access to payment accounts into services customers would trust and use regularly. Reliable connections and a clear purpose were central to that task.

Payments4 min read

Contactless bank card and payment terminal.ING Nederland · CC BY-SA 2.0

A bank account could support services beyond the bank's own application. That was the commercial opening behind the revised Payment Services Directive, known as PSD2. Member States were required to apply their implementing measures from 13 January 2018. The directive brought payment initiation and account information services within a defined regulatory framework, establishing rights of access to eligible online payment accounts under specified conditions.

For founders, the opportunity included account aggregation, financial administration and payment services built around a customer's existing account. Access alone did not guarantee adoption. Someone still had to persuade the customer to connect an account, explain what the service would do and keep it working when authentication or a bank connection interrupted the experience. Those tasks would shape the economics of the new market.

Two services with different roles

An account information service could consolidate information from one or more payment accounts held with other providers. For a business, that information might help reconcile receipts or understand cash balances across banks. A payment initiation service could initiate a payment order at the user's request from an account held with another provider. It could form part of a merchant checkout or a business payment process.

What PSD2 opened

Scroll to view all columns

Comparison	Account information	Payment initiation
Customer request	View information from designated payment accounts	Initiate a payment from an account held elsewhere
Product application	Account aggregation and cash management	Checkout and business payment services
Important boundary	Access and use limited to the requested account information service	Provider must not hold the payer's funds in connection with the service

Service boundaries from Articles 66 and 67 of Directive (EU) 2015/2366. Product applications are examples of potential uses.

The distinction affected both product design and regulatory scope. Article 66 placed conditions on payment initiation, including explicit consent and restrictions on holding the payer's funds or using data for other purposes. Article 67 required account information services to operate on explicit consent and limited access to designated payment accounts and associated transactions. The framework did not grant a general right to collect every kind of financial information a bank held.

Permission created a distribution problem

A legal right of access had to become a decision by an individual customer. That decision carried a practical exchange: permission to access an account in return for a service worth using. A cash management tool could place the request inside an established finance workflow. A new consumer application had to establish its own credibility and explain a benefit clearly enough to justify the connection.

For venture investors, the relevant comparison was the cost of reaching customers and keeping them active. An attractive demonstration using a single connected account did not establish a repeatable acquisition channel. Partnerships with accounting providers, merchants or other services could bring distribution, while creating dependence on those partners' priorities and commercial terms. Diligence needed to examine who owned the customer relationship and which party could change the route to market.

The silver back of an iPhone XS stands upright against dark acoustic foam, with its dual camera visible. — iPhone XS, 2019.Cullen Steber (opens in a new tab) · CC BY-SA 4.0 (opens in a new tab)

The security timetable came later

The detailed security framework followed under Commission Delegated Regulation (EU) 2018/389, which set technical standards for strong customer authentication and common, secure communication. Most of that regulation applied from 14 September 2019; specified interface documentation and testing provisions applied from 14 March 2019. Companies therefore had to manage a transition between the directive's implementation and the application of its detailed requirements.

Strong customer authentication required at least two independent elements drawn from different categories: knowledge, possession and inherence. The rules also provided defined exemptions. For a product team, authentication affected completion rates, support requests and the design of payment journeys. For the bank and the third party, reliable communication had to include identification, error handling and access arrangements. The existence of standards reduced uncertainty about requirements while leaving considerable implementation work.

Connections had an operating cost

A service that depended on several banks needed to understand the quality of each connection. Missing transaction information, an interrupted session or an unavailable interface could create work for its own support team. If the product supplied a finance department, that work might arrive at the moment a payment run or reconciliation process needed to finish. Reliability therefore influenced the value of the service as well as its cost of delivery.

A credible plan separated regulatory access from the engineering effort required to maintain it. It allowed for monitoring, incident response, partner management and changes to authentication journeys. Investors could then compare the revenue attached to a connected customer with the real cost of keeping that customer's workflow usable. Connection counts were informative only alongside usage, coverage and the cost of resolving failures.

Where a lasting product could emerge

PSD2 widened the set of firms able to build services around payment accounts. It left open the harder commercial questions: which problem deserved a budget, how frequently the customer experienced it and whether the service could earn continued permission. A product embedded in a recurring task had a different opportunity from a dashboard consulted once and forgotten.

The investment case in open banking rested on more than connectivity. Useful account data needed to produce a decision, a completed payment or an administrative saving. Teams that could demonstrate that progression gave investors something concrete to assess: repeat usage, dependable delivery and a plausible relationship between customer value and the cost of providing the service.