Australia’s banks de-risk data sharing by monitoring for API abuse
By Shreyans Mehta (pictured), Chief Technology Officer at Cequence Security.
The future growth of open banking use cases is driving Australian banks to reconsider their security postures and data-sharing capabilities.
One of the established use cases stemming from open banking in Australia to date is the emergence of budgeting and financial apps, initially developed by fintech companies but now also by the banks themselves.
The idea is simple: users of financial services have become accustomed to managing each service through distinct portals. That could be one or more bank accounts—Australians typically hold two or more—credit cards, or alternative credit services such as ‘buy now, pay later’. It makes sense to want to simplify that by being able to view all financial data in one place.
According to one survey, about 12% of Australians intended to use a budgeting app this year to alleviate financial stress. The figure may be slightly higher as budgeting functionality is increasingly offered by banks natively in their mobile and online banking apps. That trend has emerged in part to counter the threat of third-party fintech-developed apps, which are populated with data from the banks anyway (along with data from other financial services providers).
A second emerging use case is facilitation of home loan applications. Lenders want to understand the financial profile of prospective borrowers, including spending habits, to determine the size of loan the borrower can realistically service, and to de-risk the lending process. Open banking allows prospects to consent to their financial data being shared as part of the application process. This is becoming more common as banks move into digital home loan offerings, with shortened pre-approval times.
Australian banks are estimated to have spent about $1 billion so far on enabling systems and technology to share or receive data in these circumstances, upon request by a customer.
While there are a few key enabling technologies, one of these is the application programming interfaces (APIs) that are used to fetch data from its holder and transfer a copy of it into the custody of the party authorised by the customer to receive it.
APIs will become even more critical in planned expansions of open banking: “action initiation” is intended to allow authorised third parties to open or close banks or make payments on a customer’s behalf. Again, this is only possible via secure APIs.
The threat of API abuse
For banks as the holders of customers’ financial data and accounts, it’s important to be able to understand the nature of all requests for data (or to initiate other actions) via APIs. As the utility of open banking grows and customer take-up increases, banks are likely to field more and more API calls. As this occurs, there will be a growing need to understand the legitimacy of each API call by tracking patterns of call behaviour.
Abusive API calls may exhibit correct syntax and appear legitimate. What’s important is the intent behind that request: and that if the intent is wrong or is flagged as potentially fraudulent, that it can be stopped.
Awareness of the potential for API abuse is particularly heightened, especially in the Australian context, where significant data loss to threat actors has been witnessed in large-scale incidents.
Research by Cequence shows more than half (53%) of businesses across all sectors were impacted by more than three API attacks per month, while 5% said they were hit with more than six attacks per month. Viewed on an annual basis, this finding means the security team is battling between 36 and 72 API attacks every year.
Within this context, banks are increasingly turning to unified API protection platforms to catalogue their API landscape, understand the risk that each API poses, and to swiftly detect and remediate any instances of API abuse.
The three steps to boost API protection
Securing APIs is a three-step process. It involves discovering and cataloguing APIs, determining the relative risk that each pose, and then determining whether any are being abused.
Many organisations, including financial services institutions, often face a challenge of insufficient awareness around API security, including the detection and prevention of abuse. There is also complexity because banking data is held in many different source systems and applications. That means many different APIs, both internal and external facing, to query systems and extract or exchange data.
So, the first step is to understand where APIs exist in an environment and catalogue them. This will naturally be a point-in-time exercise initially, but there’s also an ongoing requirement to ensure any new APIs are also captured and catalogued. Maintaining an up-to-date inventory of APIs is crucial for ensuring effective oversight.
Once catalogued, organisations will then seek to understand what risk each API poses. For banks operating under the open banking scheme, the types of data being requested or that can be requested from other institutions on behalf of a customer are well-defined. However, as transaction data holds value, the risk of exposure needs to be factored in. Banks should recognise which APIs pose the highest risk, as identifying these serves as a solid starting point for risk remediation.
The final step involves implementing systems capable of recognising if or when the API might be being abused, discerning normal and abnormal API behaviour. There’s often a false sense of security that a Web Application Firewall (WAF) can protect against API abuse. However, its capabilities are ineffective at detecting sophisticated or crafted API requests that look legitimate but that are betrayed by the intent of the pattern of requests. A unified API protection platform is needed to handle this nuance.
By following these three steps, banks can get on top of their API landscape and be more confident that they can operate in an open banking world, resilient against API abuse and attacks.
