Open banking and PSD2 APIs

Introduction to open banking APIs

Open banking gained momentum in Europe following the introduction of the Payment Services Directive (PSD2) in 2016. PSD2 requires banks to grant licensed third parties access to their customers’ payment and account data, given that the customer has provided their consent.

Unlike corporate banking APIs, which are tailored specifically for business customers, open banking APIs are primarily used for consumer services such as budgeting apps, loan applications, and account verification.

To see how open banking compares to banks’ proprietary corporate APIs and other connectivity methods, read our full guide to bank connectivity.

‍

How open banking APIs work

Here’s how a typical open banking connection works:

• Consent: The customer provides consent to a third-party provider to access their banking data.
• Authentication: The customer is authenticated using secure methods such as multi-factor authentication (MFA), specifically Strong Customer Authentication (SCA) in Europe.
• API request: The third-party provider sends a request to the bank's API to access specific banking data or initiate a payment and the bank processes the request.
• Service provision: The accessed data is used by the third party to provide a service, such as aggregating account information from multiple banks or initiating a payment.

‍

Pros and cons of open banking APIs

Open banking regulations like PSD2 mandate that banks adhere to specific API standards, but much still relies on the individual banks. The availability of open banking APIs is inconsistent across countries, and even when available, reliability issues are common. Banks in the UK and Nordic countries typically offer more mature APIs compared to those in other regions.

Since banks must provide open banking APIs free of charge, they are often less comprehensive than their proprietary corporate APIs. For instance, certain types of business accounts or financial data may not be accessible if they are not required by regulations like PSD2. Additionally, in Europe, Strong Customer Authentication (SCA) is required for every payment and at least every 90 days to access account information, potentially disrupting the payment approval process and creating operational risks.

Due to these challenges, most treasury professionals do not yet view open banking as a serious alternative. However, it might be a viable option for companies with straightforward needs, such as checking balances for a small number of accounts. Implementation can be quick if your provider is already connected to a bank’s open banking API. Still, for businesses with more complex requirements, open banking is unlikely to offer the necessary level of reliability and data quality.

• Pros: Depending on the banks and the quality of their APIs, open banking can be an option for smaller businesses that don’t require the full breadth of financial data or payment capabilities.
• Cons: Open banking is effectively limited to Europe and the US, and many banks in Europe have yet to provide a functional API. It is unlikely to offer the reliability and data quality needed by dedicated treasury teams.

‍

How Atlar can help with your connectivity

Atlar has prebuilt connections to over forty major banks globally, covering a variety of methods including host-to-host, EBICS, SWIFT, and APIs. This is because different banks specialize in different connectivity options and, as a company grows, it needs a treasury platform that can connect to all of them using the best method available. What’s more, Atlar handles all implementation work on behalf of its customers. If you’re interested in learning about our unique approach to back connectivity, get in touch.