APIs Are the Building Blocks of Bank Innovation. But They Have a Risky Dark Side

The proliferation and deployment of APIs has been critical to making digital transformation at speed a reality. But are banks paying enough attention to the downsides? Why your APIs may be the chink in your security and fraud defenses.

Depending on your historical source, the claw hammer was invented somewhere in the late 1700s.

Even today, “the claw hammer has two functional purposes,” says Richard Bird, chief security officer at Traceable AI. “It was designed to drive nails and pull nails.”

“Interestingly enough,” continues Bird, “the same physics, geometry and energy required to drive a nail can also be used to crush a skull. Yet there was nobody in the history of the claw hammer who said, ‘I’m designing a murder weapon’.”

Bird cites this vivid bit of history to make a point about APIs — application programming interfaces. Much of the digital transformation of financial services that is increasingly taken for granted relies on APIs, and has done for roughly 15 years. The largest financial institutions incorporate thousands of APIs in their operations. (A 2023 McKinsey study of leading banks around the world found that they were allocating 14%, on average, to API development.)

In many ways, APIs resemble books of reference and instruction that can be pulled off a library shelf for a specialized need. However, there’s an important difference that Bird illustrates with an anecdote.

He was sitting in with a group of “pen testers.” These are white-hat hackers who companies hire to attempt to infiltrate software like APIs — penetration testers.

“So the pen tester takes one of the APIs that that company plans to adopt and he begins to abuse it, and he begins to mutate it to do his bidding,” Bird recounts.

After watching his creation go through this, the developer who wrote the API could stand no more.

He jumped out of chair and shouted, “That’s not what it’s supposed to be used for!” Of course, that was the point of the exercise, to see what the bad guys could potentially do with the API before it went live.

Real criminals attempting to abuse APIs for fraud explore weaknesses and simple forgetfulness, such as the equivalent of failing to remember to lock a door behind you after adjust an API.

API breaches are a leading cause of infiltration.

One dramatic real-world example: An API developed to encourage customer referrals in exchange for a cash bonus. According to Bird, the attack began with the hackers opening a massive number of fraudulent accounts. Then those fake accounts referred other fraudulent accounts, and so on and so on.

In this particular case, the scam had been running for months before it was detected, says Bird.

“From a security standpoint, it looked like normal traffic. And that’s one of the big problems with APIs. You can exploit an API to do what it is supposed to do, and does it well,” says Bird. In this case, there weren’t any humans behind the accounts, but millions of dollars in referral fees went out before it was shut down.

A new survey of bankers by Traceable AI found that 26% of the respondents have had a data breach in the last two years that was caused by API exploitation. Among these institutions, 42% blamed the breach on fraud, abuse and misuse of the APIs.

The issue of API security is becoming more important as the federal government begins an official push for open banking.

Read more: Today’s Internet Is a Vulnerable Home for Our Money

Measuring Key Banking Risks in the API Arena

A key point is that it’s not just institutions suffering. Frequently APIs used by banks draw on PII (personally identifiable information) such as social security numbers, driver’s license data, medical information and personal financial data.

APIs may also handle device and location data.

“While this data may not seem as sensitive as PII or payment card details at first glance, it can still be exploited by malicious actors to gain insights into a user’s behavior, preferences and movements,” the report says. “In the wrong hands, this information could be used for targeted phishing attacks, social engineering, or even physical threats.”

“Everything in the financial transaction world today is going across the internet, via APIs,” says Bird.

Traceable AI’s study reported that 35% of institutions admit to having lost customers as a direct result of API-related data breaches. Bird thinks this will get worse in time, and notes that one of his primary financial institutions remains so specifically because he finds its security protocols to be at the gold-standard level.

In a related finding, the report found that 41% of respondents suffered reputation damage in the wake of API breaches, with many also experiencing financial losses as a result.

Read more: Some Top Fintechs Value This Function as Much as They Do Innovators and Engineers

Keeping Track of API Exposure Is Critical (and Expected)

Traceable AI’s study found that 82% of the banks are concerned about compliance with federal financial regulators’ expectations regarding APIs and relevant controls.

A key document worth reviewing is “Authentication and Access to Financial Institution Services and Systems,” issued by the Federal Financial Institution Examination Council, an interagency group that works on many common regulations, exam protocols and standards.

An important section that Bird points to concerns an example given of effective risk management. This is an inventory of information systems. This covers APIs, including those that an institution may be using that are provided by a third party. Later in the document the interagency group cites APIs as a potential source of risk.

He says he has heard that some major banks were simply providing lists of APIs they used to examiners.

“The OCC examiners came back and said, ‘Absolutely unacceptable. You need to show us a continuous inventory’,” says Bird.

In spite of that warning, 64% of the study’s respondents still lack a comprehensive view of their API “attack surface.” (The term refers to the system entry and access points that can enable abusers to crack the API or APIs.) As a point of reference, 13% of the study sample uses more than 2,500 APIs — quite a wide front to defend.)

Bird was surprised. He had expected to see at least half of the respondents reporting that they have the inventory and risk assessment together for APIs. He feels the data says the institutions understand that this can be a problem but haven’t taken decisive action.

“We’re looking at one of the largest cognitive dissonance gaps in security that I’ve seen in my working career,” says Bird. He says about 30% of the industry is moving to address the gap, but he doesn’t feel that’s nearly sufficient.

A classic answer to such security issues has been data encryption, but Bird scoffs. “We have a 40-year body of history that shows that encryption really stinks. It hasn’t saved us from anything.” He sees the heavy reliance on the internet and APIs as “putting the fox in the henhouse.”

Bird points out that the bad guys have more than just tools from the dark web to help them do their business. Frequently they tap the same mainstream tools that bankers would use. He laughs when he recalls demonstrating to a reporter how a particular fraud would have been assisted using Excel pivot tables. The journalist didn’t think of criminals using legitimate software. “Why wouldn’t they?” said Bird.

Read more: Mastercard’s Innovation Chief Talks GenAI, eCommerce and Fighting Fraud

How To Move Forward with Improvement in API Management

Should a bank get API risk religion, and move forward to plan solutions, who should be at the table?

One point is to recognize that API developers have not typically had their eyes on security issues, apropos of the shocked developer jumping out of his chair at the beginning of this article. Often, says Bird, they’ve seen security issues as a constraint on their innovations. Even now that greater awareness of security risks is permeating the industry, says Bird, developers are talking about looking at new APIs.

“That doesn’t account for the thousands of APIs that are already in production that may have been built incorrectly,” Bird explains.

Developers should probably be in the room, but Bird says they will never be intensively focused on security — “and security people will never become developers.”

Bird thinks chief technology officers and chief information security officers both belong at the table. The chief information officer should also be there.

“There’s a lot of talk across all industries that all we need to do is make people smarter about security,” says Bird. “But I say that’s going against human nature and behavior.”

This article was originally published on . All content © 2024 by The Financial Brand and may not be reproduced by any means without permission.