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

More from Banking & Finance

Kronos Malware Reemerges with Increased Functionality

The Evolution of Kronos Malware The Kronos malware is believed to have originated from the leaked source code of the Zeus malware, which was sold on the Russian underground in 2011. Kronos continued to evolve and a new variant of Kronos emerged in 2014 and was reportedly sold on the darknet for approximately $7,000. Kronos is typically used to download other malware and has historically been used by threat actors to deliver different types of malware to victims. After remaining…

Why Cybersecurity Risk Assessment Matters in the Banking Industry

When customers put money in a bank, they need to trust it will stay there. Because of the high stakes involved for the customer, such as financial loss, and how long it takes to resolve fraud and potential identity theft, customers are sensitive to the security of the bank as well as fraud prevention measures. Banks that experience high volumes of fraud are likely to lose customers and revenue. The key is to protect customers and their accounts before problems…

Cost of a Data Breach: Banking and Finance

The importance of cybersecurity has touched almost every industry. Beyond that, robust cybersecurity is table stakes for several sectors, particularly health care and the banking and finance industry. Not only is financial data at risk, but so is customer trust. In banking and finance, trust means everything. Yet, consumers are hesitant to share their confidential data. A recent McKinsey survey revealed that no industry achieved a trust rating of 50% for data protection. Here’s the most sobering stat: 87% of…

What Do Financial Institutions Need to Know About the SEC’s Proposed Cybersecurity Rules?

On March 9, the U.S. Securities and Exchange Commission (SEC) announced a new set of proposed rules for cybersecurity risk management, strategy and incident disclosure for public companies. One intent of the rule changes is to provide “consistent, comparable and decision-useful” information to investors. Not yet adopted, these new rules – published in the Federal Register on March 23 – could change reporting requirements. Take a look at some of the big-ticket items and what your organization needs to know.…