PSD2 & CMA : APIs and changing IT demands

PSD2 is clear in policy terms. Its goal is to foster innovation and remove barriers to trade. It may be a headache in the shorter term for banks but it is also an opportunity for banks to put the structures in place that will allow them to deliver more convenient services tailored for specific customer segments, albeit through cooperation with Fintech companies, third party software houses and PSPs.

The banks put APIs in place that provide access to the bank services. Developers and software houses create a wide range of apps that rely on those APIs, but that are tailored to suit the needs of different bank customers.

One perspective on PSD2 is that it sets the scene for a new era in banking, where the banks reinvent local services and reconstruct a knowledge of their customers. Banks traditionally invested in bricks and mortar, and maintained a connection with customers through their network of local branches. Banks can insert their services into the local again, this time within the fabric of online and mobile commerce. Local no longer relates to a physical space, but now relates more to the space that a customer inhabits online.

UK CMA : focus on technology choices

PSD2 is clear in policy terms, but it is not prescriptive in technology terms. In the UK, the Competition and Marketing Authority (CMA) is pushing a similar agenda for its banking industry (see more). But CMA has been much more explicit about technology choices. Ease of adoption is important if new entrants and smaller providers are to compete fairly in the banking space, and technology is a critical factor here. The CMA has mandated that banks implement open banking APIs by early 2018 and are working on technical standards. European authorities have similar motivations to the CMA, and will surely adopt similar measures at some point.

The API Economy

Regulatory authorities are demanding that banks put technical infrastructure in place to allow smaller players to deliver innovative banking services to consumers. But there are also clear commercial reasons for banks to provide access to its services through APIs. Developers and small software houses are much more likely to be the innovators in this area, and to create appealing, targeted and convenient app-based banking services. Those apps need to connect into bank services via APIs. Banks can expect hundreds, if not thousands, of mobile apps to be connecting into their API-based services. To maintain relevance with end consumers, banks need to be engaged in the API economy.

Traditional roles involved in providing IT access to bank services

Banks have delivered banking services to clients through technology integration for many years. For example, corporate treasuries access bank payment services by submitting SEPA payments files.

Parties at the bank involved in delivering these IT-based services include product management, business development, IT development, IT testing, and the onboarding and support team.

Product Management are responsible for structuring the IT-based services as a valuable and useful product for bank customers. Their most valued customers have traditionally been corporate treasuries.

Business development need to easily promote the services and require high quality technical material that explains the services, traditionally an implementation guide provided in PDF format.

IT Development manage the implementation in the bank systems, often based on some sort of standard e.g. SEPA, national payments standards, or CGI-MP. They provide integration points e.g. to allow clients to ftp payments files to the bank, or to submit using the EBICS transmission protocol.

IT Test need to ensure that the bank systems are robust enough to gracefully handle any content submitted by clients, that the integration point is secure, and that the systems are performant. But the security threats and the likelihood of receiving poor quality files from IT departments at large corporate clients are relatively low.

The onboarding and support team provide support to the clients through the integration phase. Once clients go live with the bank, they help with issues such as failed payments, as they arise.

Figure 1

Technology Integration: a part of the customer / bank relationship

Traditionally, technology integration has been seen as a small part of a large customer / bank relationship. Customers consider many other factors besides technology when selecting a bank. For example, a corporate treasury may take account of how well a bank can support them in terms of  liquidity, foreign exchange services, and global banking.  In these circumstances, the effort involved in a bank integration is simply seen as the cost of doing business.

The world of APIs is different. Technology integration is much more likely to be a large part of a small customer relationship. An early stage Fintech company won’t want to negotiate significant banking services for itself. Their main concern will be accessing the bank API services. They may decide to launch a new App in the marketplace. Revenue streams will be zero at the outset, and the preferred long term business model may involve small monthly subscriptions. Unless and until the company can demonstrate good takeup among consumers, the value to the bank will be very limited. Added to this is the fact that we can expect a high failure rate among such companies.

New Expectations

In this new world, the traditional technique used to get two systems to talk, “my guy will call yours and they’ll figure it out”, is just not feasible. The bank IT team just doesn’t have the bandwidth to talk to all those App developers, investigate errors, and send out emails with examples of correctly formatted requests.

Moreover, developer expectations are changing. In the API economy, the developer’s experience is as important as end user experience. A Fintech company may want to understand and evaluate whether the bank services are suitable for their needs even before approaching the business development team at the bank. They will expect to be able to implement and debug an API integration with minimal interaction from the bank’s teams.

High costs, low level of automation

The current support model has too high costs and little automation for small Fintech companies onboarding to bank APIs.
Banks need to streamline the way in which they engage with third parties, because of PSD2 and other regulatory initiatives, and if they want to play in the API Economy. As part of an API programme, they need to consider how different parties at the bank, from product management to support, can adapt and engage in a professional and efficient fashion with new types of customers.

About XMLdation

XMLdation is a global service provider of XML management, end-to-end testing and simulation services for payment-related XML messages.

Our solutions Request a demo today

Stay up to date

Subscribe to our newsletter

Error: message

Result message

Menu