Mobile and online banking have already taken their place as conventional banking channels. But banks are constantly looking for new, alternative delivery methods to sell their products and distribute their services. This new channel seems to be application program interface (API) banking. As always, emerging opportunities come with emerging risks.

Transitioning to API Banking

The most common and well-known banking API is online point-of-sale (POS) systems. Banks developed a remarkable amount of experience developing and managing them. However, these APIs are relatively unchanging due to regulations and players in the payment card industry.

Payment System Directive 2 (PSD2) is forcing institutions to enter the API banking environment. Payment initiation service providers and account information service providers will be connected to banks through these APIs. In addition to that payment universe, a vast array of services are waiting to be offered through APIs, such as bill payments, loan applications, insurance sales, locational services and more.

As new actors in the API and cloud landscapes, banks must understand the risks they are carrying and the attack surface they are exposing to the outer world. Compared to pure tech companies and startups, banks must manage massive amounts of financial and reputational risk. Besides the risks, banks must deal with various local and international regulations as well. Taking all this into account, a solid security and risk governance framework is indispensable.

Let’s take a look at some new concepts and challenges banks must deal with as the landscape evolves.

Social Engineering Attacks

As mentioned before, there will soon be an ocean of banking services and products offered through various platforms. For example, a bank can offer a travel insurance policy attached to a holiday tour on an agent’s webpage or a personal loan through a digital equipment store’s site.

These channels will attract customers used to submitting their credentials without proper authentication. Methods other than SSL certificates must be developed for a two-way authentication. By two-way authentication, we mean customers should be able to verify banks just as the banks are verifying customers.

Banks Were Using Client-Side Controls — Now What?

When institutions have full control of their environments, it is easy to implement controls and respond to new vulnerabilities. Input, output and logical controls are working efficiently when they are designed at both the client and server sides.

The first line of defense starts at the border of a bank’s demilitarized zone (DMZ) instead of customers’ mobile devices or browsers. Distributed denial-of-service (DDoS) protection, input controls and logical controls must work more efficiently than ever. Even users are potential attackers in API banking environments.

Keeping Track of APIs and Software Development Kits

Banks cannot enjoy the comfort of providing open APIs to whomever they want like other API providers. Due to local and international regulations such as the Know Your Customer (KYC) principle, internal policies of the bank and international rules such as embargo, they should know with whom they are working.

API providers and users usually communicate through application servers at the user’s side and API gateways at the provider’s side. Banks should develop ways to limit sources of these requests and the number of requests to which they are responding. Of course, a periodic content check of the user side should be in place. A reputable bank would not enjoy having its APIs served in black market.

Change Management

Bug, vulnerability and version management is relatively easy if you are running the platform for your business services; you can handle everything in-house. Utilization of APIs will take this to a whole new level. Banks must have internal and external procedures that answer questions such as:

• What kinds of environments should banks provide?
• How can developers submit bug reports?
• Are users ready for a new version of the API?
• How much advance notice should banks provide to developers before promoting the API to the production environment?
• How many versions of the same service should be active simultaneously?

Developing a Governance Framework

It is unfortunate that a Google query of “API Banking Governance” still does not return satisfying results. Taking software-as-a-service (SaaS) governance models and fine-tuning them for the banking industry can be a good starting point.

When developing this governance framework, banks should divide the whole process into two parts — API development and maintenance and API user management — and manage them separately. Here are some key components to look at during the API development and maintenance process:

• Business line evaluation;
• Legal evaluation;
• Anti-money laundering (AML) controls;
• Logical security controls;
• Development (e.g., technical security controls must be in place);
• Going live;
• Change management;
• Monitoring; and
• Decommissioning.

For API user management, banks should start by examining the following areas:

• Communication methods;
• Evaluation of API users;
• Monitoring of API user resources;
• Monitoring of content; and
• Legal obligations of parties.

A Shifting Landscape

API banking can benefit both banking customers and financial institutions if implemented, operated and secured properly, but failure to do so could result in social engineering attacks and other forms of fraud. As the landscape shifts toward this rapidly evolving technology, banks must stay abreast of the cyberthreat landscape and the various local and international regulations that affect their customers and business interests.

Read the white paper: The Impact of PSD2 on Authentication and Security in European Financial Institutions