An API (Application Programming Interface) is a set of functions and procedures that enables two applications to talk to each other by sending requests and receiving responses.
APIs in Open Banking
APIs are relevant to finance and treasury professionals because of Open Banking and PSD2 (Payment Services Directive 2).
Open Banking requires that banks make their APIs available for individuals and third parties to access personal financial data securely. And according to PSD2, nearly all banks in the EU will have to enable access to customer data via APIs.
So the real question here is: how secure are APIs for transacting and sharing your financial data?
Until recently, banks have typically created financial silos, forcing customers to rely on their services in order to access their financial data securely. But APIs and Open Banking are changing all that.
Through a rich API, financial institutions can gain a competitive advantage and put their customers in control of their finances by providing real-time, secure data.
There are plenty of examples of how businesses and consumers are already embracing APIs to make life easier:
With digital transformation at the top of the agenda for corporates around the world, APIs can bring several benefits to corporate treasurers. APIs open-up advanced technologies to smaller treasury teams which were only previously available to larger enterprises; enabling real-time business, quicker decision making and enhanced customer experiences.
APIs can provide corporates with direct banking connections to banks from enterprise resource planning (ERP) systems or through live data integrations with business intelligence tools.
For consumers, APIs deliver speed and simplicity to create improved financial experiences.
Yolt is a perfect example of consumer-based Open Banking in practice as it uses APIs to centralise disparate accounts to help users keep a closer eye on their spending habits.
What are the risks?
The introduction of open APIs makes banks dependent on the security of the TPPs (third party providers) using these APIs, which poses a few questions – or concerns – for banks and service-users:
- With more consumers using third party tools, the number of transactions performed through bank-owned channels is reduced. This has a negative impact on the volume of data that banks can collect, which they use to distinguish between legitimate transactions and fraudulent ones.
- New open banking tools pave the way for new types of transactions, which could make fighting payment fraud even more difficult.
- There’s potential for fraudsters to target data as it’s being transmitted by APIs. If successful, unauthorised customer data could be used in an account takeover (ATO) or another form of cyber attack.
- Banks are interacting with TPP’s without fully understanding their security measures, which poses a new risk of where the data will end up being held. As a result, banks may be exposed to hundreds of new threats outside of their normal areas of control.
- If a TPP is compromised, then hackers can send requests to the banks that appear to be authorised. And with scams becoming more sophisticated than ever, it won’t be long before someone finds a way to spoof customer consent.
“APIs offer another way for cybercriminals to attack…if I can’t attack the banks’ front doors, maybe I can pose as a small developer and find an alternative side door that still gets me through to the bank, one way or another.” Sumit Agarwal, Shape Security
How are APIs secured?
Despite these concerns, a well-designed API will provide a secure connection to third-party applications.
It’s important to remember that it’s the banks themselves who build and test their API endpoints.
So, banks can mitigate the risk of attacks themselves by implementing a sound architecture that integrates security requirements and tools into the API itself. Ultimately allowing banks to be proactive, rather than reactive, when it comes to securing APIs.
TPPs are highly regulated
The first thing to remember is that APIs are permission based. So whether you’re a consumer or a business, you don’t have to share your data with a TPP if you don’t want to.
This is core to APIs in Open Banking. The rules say that banks must allow your data to be shared with TPPs, but ONLY if you permit them to do so. That means TPPs can’t just access accounts freely – they must get your consent, which can be withdrawn at any time.
TPPs are also subject to data protection laws like GDPR, as well as PSD2 regulatory technical standards, which means they are responsible for protecting any personal data they process.
What are AISPs and PISPs?
Following the introduction of the EU Payment Services Directive (PSD2), online services that use APIs to access your account data or make payments on your behalf are now regulated by the Financial Conduct Authority.
For a financial service provider to be fully authorised through PSD2 to use Open Banking APIs, they must be registered as either an AISP, a PISP or both.
An authorised Account Information Service Provider (AISP) can ask for permission to connect to a bank account and use that account information to provide a service. AISP’s are authorised ‘read-only’ access of bank account information, so they can look but not touch.
Common examples of AISPs include price comparisons, credit checks, money-saving apps like Yolt and accounting packages like Sage and QuickBooks for businesses.
Authorised Payment Initiation Service Providers (PISPs) can ask for permission to connect to a bank account and initiate payments from the customer’s bank account on their behalf.
Though PSD2 rules make it clear that PISPs will “not use, access or store any data for purposes other than for the provision of the payment initiation service as explicitly requested by the payer”.
Common examples of consumer-based PISPs include instant checkout facilities often used by retail and eCommerce stores, which exist to improve the customer experience of regular shoppers.
It’s always a good idea to check on the Financial Services Register that a company providing Account Information Services or Payment Initiation Services is authorised first.
You can check if a company’s authorised on the FCA Register or the Open Banking Directory.
Authorised TPPs will only ever be able to access the data required for the service you’ve signed up to. So if you’ve asked a registered TPP to look at your current account with one bank, it won’t have any visibility over any other services you hold with that bank.
And because all TPPs must comply with data protection laws, the provider should tell you which data it will use, how long for and what it’ll do with it before you sign up.
If you use a third-party provider that’s not regulated, you won’t get the same levels of fraud protection. Meaning if you lose money using an unregulated service, there’s a chance your bank may not pay out.
APIs vs Screen Scraping
APIs are generally far more secure than alternative solutions. One such example is screen scraping.
Apps that use screen scraping ask you to hand over your bank login details and require your permission to collect or ‘screen-scrape’ your data.
Essentially, they pose as you, the customer, which can expose highly sensitive personal data and leave you open to fraud. The use of screen-scraping will continue for a transition period until around September 2019, when it will be banned due to fears it’s not as safe as APIs.
So, are APIs secure enough for transacting financial data?
When considering the security of APIs, openness should not be confused with poor security. By doing some research and choosing the right TPPs, businesses and consumers can reap the benefit of APIs to simplify financial management.
But whilst some TPPs remain unregulated and techniques like Screen Scraping are still available to consumers, it’s clear the industry still has some way to go with ensuring that API usage is as safe and secure as possible.