Blog
Security questions to ask a prospective open banking provider
Merchant
Friday, March 31, 2023
Security is the fundamental thing to get right for any fintech. And — if you want to offer pay by bank as a payment method — partnering with an open banking provider that puts security at the heart of their solutions is critical for several reasons.
First and most obviously, it is critical that your customers’ Personally identifiable information (PII) and funds are protected. Second, it is critical for you as a merchant in terms of managing reputational and financial risk. And third, security is important for general open banking adoption. If a highly publicized data breach or worse occurs, there is a significant risk that open banking adoption will slow down as a whole and along with it, merchants and customers alike will lose out on the lower transaction costs and greater convenience offered by pay by bank.
Open banking is more secure than cards — but there are always risks
When implemented properly, open banking-powered pay by bank solutions are more secure than most comparable payment methods, particularly cards. In fact, ACH payment fraud, which is comparable to pay by bank since the transactions run over the ACH payment network, is orders of magnitude lower than that of cards.
However, there are always security risks. For example, targeting APIs is a common tactic of cybercriminals today. In fact, some of the biggest security breaches of recent years were due to an API issue, including the Cambridge Analytica breach, in which a Facebook API vulnerability exposed personal data of over 50 million people. Furthermore, when it comes to sensitive financial data, there are risks involved in access and storage. It is important that your prospective open banking provider has a sophisticated approach to managing security to mitigate the risks above.
With this in mind, here are six questions you can ask your prospective open banking provider about their security practices.
What kind of data do you store on your servers, and in what manner?
Your open banking provider should not store (or even access) any login credentials. However, a number of open banking providers do in fact access these sensitive data, through practices such as screen scraping and reverse engineering of APIs. Any data that is stored should be encrypted, segregated, have access to it tracked, as well as limit access to specific use cases.
What steps have you taken to reduce your attack surface?
The attack surface can be defined as “the sum of vulnerabilities, pathways or methods that hackers can use to gain unauthorized access to the network or sensitive data, or to carry out a cyberattack.” Reducing the attack surface reduces the potential for a cyberattack, and there
are a number of ways open banking providers can do this. Some include:
Apply a WAF (Web Application Firewall) at all entry points to their services. This creates a shield between a web app and the Internet, which mitigates many common attacks.
Perform a fresh vulnerability scan every time they change or update their software.
Employ adaptive anti-virus and malware protection across device endpoints.
Store service and privileged credentials in vaults providing zero touch use.
Encrypt sensitive data at rest with best practice standard encryption algorithms, such as AES256 (a virtually impenetrable specification for the encryption of electronic data).
Proactively monitor external presence to ensure that only services intended to be visible are present.
What kinds of third party audits and pen tests do you do?
A penetration test is a simulated cyberattack that is designed to identify weaknesses, including the potential for unauthorized parties to gain access to a system's data.
Providers should go through an external assessment (such as penetration testing) at least annually and also on major code or underlying infrastructure changes. Further, they should randomly survey infrastructure for vulnerabilities and other weaknesses. In parallel, they should have (near) real-time analysis tools on attack paths to ensure a full understanding of their attack surface, and that misconfigurations or any other inadvertent exposures do not exist.
What compliance certifications do you have?
Open banking providers should have at least SOC 2, a voluntary compliance standard for service organizations, developed by the American Institute of CPAs (AICPA), which specifies how organizations should manage customer data. They should also have a governance framework that is aligned with ISO27001, which is an international standard to manage information security to ensure that risks are properly assessed and mitigated.
What kind of visibility do you have into your API endpoints and infrastructure to protect against attacks?
An API endpoint is a point at which an API — a software intermediary that allows two applications to talk to each other — connects with a program. Today, web apps come with multiple API endpoints which use different protocols, so when an API expands its feature sets, managing security becomes complex. Without robust security, APIs are vulnerable to a variety of attacks that can lead to data breaches and compromised networks.
It is important for open banking providers to have tools that provide as near real time insight as possible into interaction points in the environment, so that anomalies can be detected for security risks, as well as other risks such as availability.
How do you identify and act on suspicious activity?
Your prospective provider should have tools and sensors to identify unusual activity in close to real time, which alert them to take a second look. They should also have processes in place to act, such as a security team that reviews the alert and then decides whether or not follow-up action should be taken.
What Link Money offers
Having robust security in place, and being transparent about how they manage security, is an important attribute of any open banking provider. If you’d like to learn more about security at Link Money, and what security initiatives to consider before implementing pay by bank, contact us.