Delivering Corporate APIs as part of Open Finance
Corporate APIs were a discussion topic among the members of Open Banking Europe during June and led to a public webinar delivered in July. Here we summarise some of the main points that came out of this work. This article looks at corporate APIs from the perspective of increasing market demand, and frustration around what is available, and the opportunity for new revenue streams.
- There is a strong demand from corporates for data via APIs.
- Banks have been providing Corporate APIs for decades in a proprietary way, but PSD2 has standardised the technical way of doing this.
- Corporate APIs delivered via PSD2 are not sufficient.
- Open Banking and Open Finance have also changed highlighted the opportunities when third parties act as a bridge between banks and corporates.
- Standardising Corporate APIs may help market uptake in the medium-term.
Who are the Corporates and what are Corporate APIs?
Corporates and Corporate APIs are common terms, however, definitions may vary, depending on who you ask. For this article, OBE considers Corporates to be the larger business clients that go beyond the SME categorisation. They can either be local Corporates (like utility or state-owned companies) or multinational Corporates. Corporate APIs are all the interfaces that allow third parties or data owners to access their financial information. Access to Corporate APIs can be made directly by the Corporate, or through a third party.
The types of Corporate APIs
Currently, in the EEA, there are multiple Corporate APIs, and they are not limited to the PSD2 mandated ones. Some APIs are Corporate APIs that predate PSD2 – the Classic Corporate APIs. Corporate “Premium” APIs, however, already existed in the market and go beyond PSD2.
The table below shows some of the technical and commercial differences between them.
Classic Corporate APIs
Classic Corporate APIs are the genesis of how corporate clients directly access their financial data. The access (that we now call APIs) has existed for years, and it is the backbone of the corporate banking that has developed over the last decades. These APIs include, but are not limited to, Host-to-Host connections and connections to the SWIFT Network. The Classic Corporate APIs have:
- Different formats, networks, and standards
- Customised functionalities (tailored to the corporate market)
- Bespoke security mechanisms, which are not necessarily advertised
The Classic Corporate APIs work, but they are expensive to maintain and monitor. Therefore, the current challenge is to update the existing APIs to take advantage of PSD2 infrastructure that resulted from considerable investment from banks.
In comparison to the Classic Corporate APIs, PSD2 infrastructure is considered to be a better alternative due to its:
- Increased Security: As part of their PSD2 Infrastructure, the banks adopted state-of-the-art security systems.
- Resource Efficiency: The APIs used for PSD2 consume use resources more efficiently.
- Ease of integration: PSD2 relies on REST APIs that are flexible and can easily be scaled.
PSD2 Corporate APIs (and their limitations)
The PSD2 corporate APIs are all those mandated under the Payment Services Directive 2 and allow access to the Corporates’ payment accounts. They are made available in multiple ways, such as through fully dedicated APIs, specific developer portals for corporate banking or generic Access-to-Account APIs.
However, the Corporate APIs present difficulties for the TPPs, namely:
- SCA Process: The SCA process for corporate accounts is not identical in all banks; therefore, TPPs need to adjust to the different flows and the different requirements to prove that they have each corporate's consent.
- Documentation: The documentation for the PSD2 APIs is more focused on the retail clients than the Corporates. Consequently, the process to access the latter group’s accounts is not as clear. To work around this, TPPs have to contact the support times, which requires additional time and effort.
- Sandbox: The difference between the Sandbox and production environment is not limited to the corporate dimension—it is general. This mismatch limits the TPPs’ ability to test and develop their interfaces before onboarding in the production environment. To mitigate this, TPPs open payment accounts are used to test the bank’s APIs in the production environment. This solution is far from ideal and is only feasible for retail accounts. Therefore, it is costly for TPPs to develop a product around Corporate APIs, as they need a Corporate Ambassador to be able to develop products.
As a result of these constraints, both the services offered and the number of APIs that have access to corporate accounts are lower than those for retail accounts.
Drivers for providing Premium Corporate APIs
Premium Corporate APIs are already a reality as most large ASPSPs offer interfaces to access corporate Accounts. There are strong drivers for providing additional Premium Corporate APIs, namely:
- the monetisation of data (by charging TPPs for the use of the APIs),
- the return on the PSD2 investment (which allows the dilution of costs resulting from the PSD2 infrastructure),
- the possibility to create more value for customers (as they allow banks to make personalised offers and to strengthen their relationships with Corporates).
Approach to the development of Corporate APIs
Unlike the PSD2 APIs, Premium APIs can be accessed directly by the data owners (i.e. the corporates) or by third parties who in turn provide services to the Corporates. ASPSPs that offer these interfaces must decide if they are building them for direct access or for third parties.
Another decision for ASPSPs is whether to just build an API that works for them, or whether to collaborate in building standard with other ASPSPs, first.
Collaboration in the development of APIs brings standardisation, scale and reach, and although it is hard to put them in place, they are extremely powerful once operational. Furthermore, Corporates would benefit from global uniformity with Corporate APIs.
In Europe today, there are already some Open Finance schemes being developed, such as the Berlin Group’s openFinance API Framework, which recognises Corporates as a type of API client that can have direct access. However, it points out that the Corporates' access should be determined bilaterally, and that the agreements between the parties go beyond the scope of the standards.
Given that many corporate clients are multinationals, Corporate APIs should be considered a global phenomenon. Therefore, standardisation faces the challenge of being too strict, as it can overlook local particularities, such as different reporting and accounting requirements, unique payment methods, and the diverse user experience expectations.
By João de Azevedo Ferreira
This article has been written as part of the Open Banking Europe Membership Program. To access our resources, join our webinars or get involved, please contact us at firstname.lastname@example.org.