Financial institutions occupy a special zone for APIs largely because of how stringent the regulatory compliance rulesets are. The data that financial institutions leverage are protected widely by a variety of regulatory ordinances, and as such, this data has to be stringently controlled, secured, and managed – hence why high-grade API security is such a serious concern.

In this piece, we’re going to discuss the serious regulatory compliance considerations inherent in financial data exchange and management. We’ll look at some methods for securing such data, and what can be done (and should be done) to ensure consumer security and protection.

Regulatory Compliance Considerations

What regulatory standards exist for financial APIs? While listing every single regulatory body could be an entirely separate piece, highlighting the most common regulatory guidelines will help contextualize some of the rules financial sector API providers will come across.

• Basel II is a set of international standards that requires financial organizations to evaluate and mitigate operational risk losses of financial data. It is specifically concerned with insufficiency security for data and system failures due to improper configuration and/or poor expectations of system demands, and as such, is a good starting point for many systems planning to utilize financial data.
• PSD2: The second revision of the Payment Services Directive was designed by the European Commission to regulate payment services throughout both the EU and the European Economic Area. The regulation is largely concerned with consumer protection and establishing rights, obligations, and expectations for payment providers and financial institutions.
• The FFIEC Uniform Rating System for Information Technology (URSIT) is a US federal standard for examining a company for proper Auditing, Management, Development, Acquisition, Support, and Delivery processes. URSIT is a great tool for setting up a process to identify security concerns, and can serve as a type of framework for such a process.
• The Gramm-Leach-Blilely Act is a US federal act that requires financial institutions to ensure the security of both financial and personal data. This act is the foundation of the data Safeguards Rule as issued by the FTC, which requires an information security plan that incorporates risk assessments as part of a total security auditing process.
• PCI-DSS is a regulatory standard that requires vulnerability scanning and source code review to ensure that payment card industry data and processes meet the stringent security processes required by providers and payment vendors. PCI-DSS is key for many online organizations, especially those managing payment processing for product, and as such, any API that has a monetization approach that integrates card payment natively should be very aware of PCI-DSS and its requirements.
• Sarbanes-Oxley requires that internal controls report to the provider as a means to track accuracy and security of financial data. It includes rather stringent audit mechanisms for internal controls, and demands the examination of IT assets, software, and solutions for resistance to data breaches and exposures.

It should be noted that, again, this is only a small selection of the most common and top-level regulatory standards – depending on where you regionally do business, regulations can be broader or narrower, and these variations can become even more marked in separate fields within the same industry. That being said, understanding these top-level regulatory structures can help frame the conversation moving forward.

Identifying Vital Data

With all of this in mind, and an understanding of just how valuable our financial data can be, we need to also identify what specific data is protected. Broadly speaking, we can sort our data into one of three categories – Personal Data, Financial Data, and Transactional Data.

Personal Data

Personal Data is exactly what it sounds like. This type of data is specific user information, and links accounts with Social Security Numbers or National Identification systems, addresses, names, and more. This type of data isn’t necessarily dangerous to expose on its own (though Social Security Numbers and other related content are often federally important), but in combination with other data, it can be used for personalized and directed attacks.

Financial Data

Financial Data is all data related to the accounts held by Personal Data, and typically has more to do with the funds available to a person, their standing in the bank, credit information, and other bank data. Again, while not specifically dangerous on its own, in combination with Personal Data, it can quickly become a huge security concern for the user.

Transactional Data

Transactional Data is intimately related to Financial Data, but is separated here due to the nature of its data generation. Transactional Data is the data that dictates transfers of funds, purchases, movements from account to account, and more. This data is often required to be kept for organized crime prevention and fraud investigations, but could also be used to capture authorization codes for replay attacks, track purchases for fraud and blackmail, or even be used as a means of tracking an individual’s approximate location.

The real danger comes when these data types are combined – knowing account holdings, addresses, names, and more can result in massive fraud and damage to the user. As such, all data must be perceived as critical.

Potential Vulnerabilities

A top concern for financial data is keeping it confidential and exposing it only to those who have the right to view it. Access control is a major part of financial protection, as the account holders will not be the only people accessing the data. Investigators, auditors, bank managers, employees, and others may have to, from time to time, access bank data. As such and as such, ensuring different levels of confidentiality is key to ensuring vulnerabilities are kept to a minimum.

Banks must also insure data integrity; meaning that data is stored correctly and unaltered between uses. Allowing account holdings amounts, points of origination, transactional information, and more to be altered would nullify the entire purpose of a financial institution, and would result in chaos. Thus, securing systems from incorrect write actions and backing up these ledgers in secure form for restoration is key to ensuring these vulnerabilities do not propagate.

Availability is an important aspect of banking as well, as there is a great amount of regulation concerned with ensuring users and investors have access to their systems and funds at all times. Downtime is often associated with additional cost, loss of investor confidence, and exposure of systems to attack, and as such, ensuring availability by distributing server load and filtering fuzz traffic is key for any banking institution.

While there are a wide range of vulnerabilities that are not discussed herein, these vulnerabilities will largely fall into these above categories.

API Security Methodologies

Now that we understand our vulnerabilities, we can begin to look for solutions to mitigate them. No solution is going to apply to every level of the financial institution, and this should be kept in mind while cost-averaging and contextualizing the solutions for their given use cases.

API Keys

API Keys are a fundamental mechanism of API security, and are used for low-level and low-security APIs around the world. The concept is simple – generate a key for the user that identifies them to the system, so that when a request is issued, the system itself can identify the key and note the user as who they claim to be.

The problem is that API Keys themselves are not entirely secure. API Keys are not meant to serve as a method of securing access, but only as a method of proving the user is who they say they are – in other words, API Keys are not authentication and authorization, but rather Identification. Therefore, using an API Key as a method of security can be very dangerous.

Compound this with the fact that API Keys lack control in granularity (often either being a “yes or no” option for identification), and you very quickly run into a situation where your API Key does more harm than good. That’s not to say API Keys don’t have a purpose, however – we’ve discussed this at length in a previous piece on Nordic APIs:

…API Keys are, by nature, not a complete solution. While they may be perfectly fine for read-only purposes, they are too weak a solution to match the complexity of a high-use API system…

In other words, API Keys serve a very specific purpose, and can be used to great effect for read only functions of publicly exposed endpoints on insecure data (such as verifying server status or beginning a more stringent authorization/authentication process), but should not be considered a holistic security solution.

OAuth and JWTs

For secure data, a combination of OAuth and the use of JWTs can be very effective in securing data. This is easiest to contextualize if we work backwards by first looking at the JWT.

JWTs, or JSON Web Tokens, are very small, self-contained packages that contain all the information the server will need to process a request, and then later all the information generated by the server that the user needs. As such, the JWT represents a very efficient, lightweight methodology of communication in the API network, and offers all of the perks of JSON.

JWTs are not encryption, however, and serve only the process of encoding the data – as such, they are only as secure as the system they reside on. This is a major caveat of JWTs, and should be part of the conversation when adopting the encoding process.

A side note – there is indeed a specification for JWT encryption, known as JOSE – JSON Object Signing and Encryption – that can offer greater security, especially when paired with more stringent encryption and security methods.

With our encoded package out of the way, we can begin to look at other methods of securing access to the system itself. OAuth is a token-based system for authentication and authorization. RFC 6749 created OAuth 2.0, an updated framework evolution that is paired with a Bearer Token Usage definition in RFC 6750.

While it’s true that OAuth is a system of authentication and authorization, it should be said that OAuth by itself does not actually provide an authentication protocol – instead, it sets a framework for authentication methodologies and decisions. Its protocol uses four general entities to control data access:

• A Resource Owner (RO) controls the data being exposed by the API, and is considered the “owner” of said data.
• The Authorization Server (AS) is a Security Token Service (STS) that issues, controls, and revokes tokens for access – this is often also referred to as the OAuth Server in the internal system.
• The Client is the application, user, website, etc. that requests data on behalf of the resource owner.
• Finally, the Resource Server (RS) is the service that exposes and stores the data, and is typically the API itself.

An example of a basic OAuth flow is found within this article.

OAuth has some great benefits for banking institutions, but perhaps the best aspect of it is that it fits with the natural organization of a financial institution. The Client functions as a teller or manager, the AS functions as an internal server verifying account ownership, and the token functions as a sort of ID card verifying ownership and rights – in this way, at least in secure situations, OAuth is a great solution for mirroring bank organizational structures in the way it handles its own data. It’s like Conway’s Law in action.

OpenID Connect

OpenID Connect is a simple identity layer that is designed to lay over OAuth. OpenID Connect is actually the third revision of the OpenID approach, and more specifically was built to overcome the earlier design limitations of OpenID 2.0 concerning Relying Parties, XML reliance, and more. OAuth 2.0 is the substrate for OpenID Connect, and as such, utilizes HTTPS (specifically TLS/SSL) infrastructure for data security.

Security – The API Provider’s Responsibility?

It’s important to discuss exactly where the responsibility for data security actually exists for the financial industry. In theory, responsibility for security should exist at all levels of the API space, with users securing their devices, clients implementing strong encryption, and so forth. The reality is this utopia doesn’t exist.

Accordingly, the best approach is for the API provider to assume security responsibility. Both in terms of compliance with regulations and in moral responsibility, security rests chiefly as a concern for the API provider.

Recent Exploits and Breaches

This isn’t all just theoretical nonsense, either – failure to incorporate and internalize these issues has resulted in some major recent exploits and breaches from some rather large organizations.

An attack in 2014 was leveled against Chase bank, exposing the financial and personal information of 76 million households and 7 million small businesses. The breach was somewhat of a sore spot considering that Chase spends over $250 billion annually on cybersecurity, especially considering that the cost of the breach has been estimated at $1 Billion USD.

Not all breaches are just from financial institutions, either. Home Depot was subject to a cyberattack in 2014 as well, with hackers using partner information from a vendor to expose a great amount of data from purchasers and businesses. The cost, before insurance reimbursements, is estimated at $80 Million USD. The Home Depot breach is a great example of how institutions can’t necessarily trust others in the chain to provide adequate security – in this case, it was the vendor specifically that exposed the data internally.

Both of these cases are chump change compared to perhaps the biggest breach in recent years, the Equifax breach. In 2017, Equifax revealed that a cyber attack revealed credit card numbers and personally identifying information of almost 143 million Americans – almost half of the entire country. The breach included names, Social Security Numbers, birth dates, addresses, driver’s licenses, credit card numbers, and other financial information, leading to massive insurance claims and widespread fraud. As of September 2017, the breach has cost Equifax almost $4 Billion in lost market-share, with insurance claims and punitive measures are still being calculated.

Ultimately, these are just three of many breaches in recent years – and as technology dramatically advances and the attacks leveled against institutions becomes more mature and complex, the number of breaches will likely increase.

Conclusion

Ultimately, API security is squarely on the shoulders of the API provider, and thereby the financial institution itself – failure to understand the vulnerabilities inherent in such business functions, as well as the fundamental concerns of CIA within the greater ecosystem, can result in massive losses and exposures. If a financial institution internalizes these concerns early on, however, such functions can be provided securely and with great efficiency.

What do you think? Are there greater concerns about financial security that were not touched on in this piece? Let us know in the comments below.