Ensuring Data Security in Fintech Applications

Main Thoughts

• In Fintech all data must be protected.
• Strong data encryption algorithms include Twofish, Blowfish, AES and RSA, and you can use more than one for the same data.
• Sometimes, you need to secure access to your Fintech app with something more than conventional 2FA and Iris Recognition works best.
• In some cases, Data Tokenization can and should be used as an alternative or in addition to Data Encryption.
• It makes sense to store some of your Fintech data separately.

In Fintech, the security, privacy, and integrity of data means the world. This goes equally for trade information, transaction data, and any personally identifiable information (PII) that is to be kept confidential in accordance with the compliance regulations that exist in different geographies.

Frequently, it’s hard to say which is a lesser evil for a financial market player – getting exposed to, and losing a hefty amount in a transaction data breach upfront, or suffering reputational damages and running the risk of having to shell out tens of millions of dollars as a result of non-compliance later.

To be able to keep the risks to a minimum and use the various data security-related options to the full, Fintechs must have a clear and deep enough understanding of the modern data security techniques they can employ in the development of their Fintech applications. This article will tell you about these techniques, as well the more optimal ways to apply them.

Implementing Encryption and Secure Data Storage

Data encryption and secure data storage are the cornerstones of data security that is so important for any financial market player and financial application.

To gain a thorough enough understanding of the data encryption area, one needs to take a close look at:

• Data encryption, the present-day data encryption means or algorithms, and the ways these data encryption algorithms are different from one another.
• The secure storage measures that must be implemented during the Software Architecture Design phase and DevOps security.
• The other existing secure storage techniques and approaches.

Data Encryption and Present-Day Data Encryption Means

So, what is data encryption?

Data encryption is a security method based on transferring data into a coded form that prevents its unauthorized or negligent use.
Based on the encryption approach that underlies them, all modern encryption algorithms fall into two types: symmetric encryption algorithms and asymmetric encryption algorithms.

Symmetric encryption (also referred to as private-key cryptography) is the kind of encryption whereby the sender and the receiver have access to the same encryption key. To gain access to encrypted data, the receiver first needs to have this key. While being overall faster than asymmetric encryption, symmetric encryption creates the need to ensure secure storage of the cryptographic key at two locations simultaneously. The key must also be available only to the software it is intended for. All this creates some additional security risks that frequently make asymmetric encryption more preferable when it deals with less closed systems and when lower processing speeds are allowed.

Asymmetric encryption (also referred to as public-key cryptography) is the kind of encryption that uses two encryption keys – a public encryption key and a private one. Essentially, these keys represent two large numbers that are paired with one another.

Each user has their own public and private keys. The private key is stored solely with them, while the public key сan be used by any user who wants to send them a message. The sender uses the recipient’s public key to encrypt their message and the receiver uses their private key to decrypt this message.

While being more preferable in some specific use cases, algorithms of both the types can be robust and efficient enough: rather, the level of security you get depends on the specific algorithm and its specific application.

Let’s take a look at some of the data encryption algorithms that are considered to be sophisticated and robust enough to be used in the Fintech and Financial Services industries:

• AES (Advanced Encryption Standard) – is a symmetric encryption algorithm that splits information into 128-bits and has three different key lengths: 128, 192, and 256 bits. AES has been recognized as a Federal encryption standard in the U.S. and is widely used to secure data storage and transmission.
• Twofish – is a popular symmetric encryption algorithm that splits data into 128 blocks and has the key length of up to 256 bits. One of the top 5 finalists in the Advanced Encryption Standard contest, Twofish was not selected to become the encryption standard. Notably, Twofish is free to use without any restrictions.
• 3 DES (or 3DEA – Triple Data Encryption Algorithm) – is a symmetric encryption algorithm that was one of the most popular data encryption algorithms prior to the advent of AES. 3 DES encrypts data blocks with three 56-bit keys three times, and provides a level of security that can be considered high only if it uses three distinct keys.

Due to the arrival of better alternatives like AES and Twofish, 3 DES has lost its erstwhile popularity.

• RSA – is a public-key asymmetric encryption algorithm that uses two keys and provides robust and reliable encryption by creating a vast amount of rubbish that makes hacking attempts extremely time-consuming and effort-intensive.
• Blowfish – is a symmetric encryption algorithm that splits data into 64-bit blocks, uses 32-bit keys, and provides a high level of security.

AES, Twofish, Blowfish, and RSA alike are powerful enough encryption means that can all ensure a high level of security. Still, how to understand which of these advanced encryption algorithms is more suitable for your Fintech application?
Each of the main encryption algorithms has its advantages.

AES is a good choice for virtually any purpose and use case. However, it should be remembered that it is frequently considered to be preferable to Twofish because of the latter’s slower performance, and not because AES offers better protection. Furthermore, Twofish can even provide a somewhat higher level of security, being virtually immune to brute force attacks. Aside from that, Twofish is also a good fit for hardware environments.

RSA often becomes an encryption method of choice for Internet data transmission. Importantly, it allows creating very long encryption keys: currently, the largest practicable and sufficiently secure RSA key is believed to be approximately 3072 bits -long(the number that is enough to counter hacking attacks from quantum computers). However, the number of bits a RSA encryption key can contain is virtually unlimited as long as you have the computational power to support this key length.

Just like Twofish, Blowfish is free to use by anyone who wants to do so. Take a note of this if you want to reduce your data-processing costs.

Important Note: In most instances you can also use more than one encryption algorithm in relation to the same data. For example, one can first use some symmetric algorithm, like AES, and then apply the asymmetric RSA, thus creating an extremely robust encryption combination.

Security-Friendly Software Architecture Design and DevOps Security

Ensuring secure data storage and access in a Fintech application must start as early as during the Software Application Design phase. At this time, you can put in place several important data security fundamentals, some of which can later be implemented only by means of a significant (and, possibly, costly) system redesign.

What exactly must be envisaged and implemented during Software Architecture Design?

1. The database that holds your sensitive data must reside in a closed LAN network.
2. One must make this database available only to your own, correspondingly authorized services.
3. Your backend services that retrieve and present sensitive data must be available only to your app’s frontend, and, if required, to your other authorized apps.
4. The frontend of your Fintech operation must work via a LAN network.

As an additional move that can significantly improve the data storage security of a Fintech app one can store their especially important sensitive data on a separate server. How can this help?

First, it is possible to secure this server with some additional or just stronger encryption. Secondly, it is possible to make this server available only from a LAN network. In essence, this kind of a solution allows creating several additional authorizations that serve as robust barriers, protecting your data.

Also, it is certainly important to safeguard your LAN networks with robust firewalls. These firewalls should preferably have tools for detecting dangerous queries like SQL injections, as well as a breach notification capability.

If your Fintech application is planned to provide any APIs that will be publicly available, it is essential that one determine the types of data one can obtain from these API, as well as the types of data that must be made available only in an encrypted form.

Lastly, all your application pages that display data to the user must use the https:// protocol.

Data Access and Some Other Important Secure Storage Techniques and Approaches

In addition to data encryption, there are several more fundamental data security approaches one must necessarily pay attention to while securing the data a Fintech app holds. Part of them have to do with safeguarding user access to Fintech applications.

Input Data Validation

To begin with, your Fintech application must be capable of validating the credentials your users enter against a set of predefined criteria in order to prevent any possible attempts by malicious actors to dupe the system or cause it to misbehave.

Quite frequently, hackers use automated means to identify websites that are likely to be vulnerable to spurious data inputs. As they find such websites, hackers manually concoct inputs that allow them to gain access to sensitive data. Because of this, any Fintech app must have a well-designed input validation capability that reliably tells authentic data inputs from those specifically designed by fraudsters.

Password Creation and Password Management Policy

Next, it is essential to have a firm password creation and management policy in place. While all your passwords should expire at 60 to 90 days, they must be complex enough regardless of whether any other security factors are used. This means that your passwords should contain characters, capitals, and digits – preferably, a total of no less than 13 characters – the number that, in most instances, is large enough to keep your hackers busy for years.

Role-Based Access (RBA)

Role-based access is another absolute must for virtually any Fintech application.

With Role-Based Access, your employees must be allowed to access any sensitive data your app holds solely in accordance with their access privileges, duties, and responsibilities.

Please note that Role-Based Access rules can include the possibilities to access certain parts of your database, modify data assets, share data with users outside your corporate system, and invite other system users to collaborate on data assets.

Two-Factor and Multifactor Authentication

Simultaneously, it is important to understand that no password alone – no matter how intricate or lengthy – can ensure the security of your data: passwords are not immune to theft or accidental compromise. Also, most users tend to simplify them within the bounds the application allows.

Because of this, a combination of two security factors, referred to as two-factor authentication (2FA) has become the mainstream over recent years. In most instances, this combination includes a password and a SMS, sent to the user’s mobile device. While this provides a level of security most financial market players consider as sufficient, one can still say its relative – with due effort, a highly qualified hacker, who has a grasp of the right techniques can both pilfer one’s password (for instance, by launching a Man-in the-Middle attack) and intercept the SMS, sent to one’s mobile device (incidentally, SMS messages are not encrypted in any way).

Increasing the number of security factors or replacing either of the two most popular ones with another security factor (like, for instance, a USB token that contains an electronic signature, digital certificate, or biometric data) tends to make the authentication procedure more complicated. Having an overcomplicated authentication procedure can severely impact the size of your Fintech application’s audience and its popularity. At the same time, this doesn’t have to mean you cannot offer this kind of protection to some of your clients in relation to some of their accounts or operations.

Identity Verification

The need to provide a higher level of security than the one conventional passwords and conventional 2FA can ensure without making the authentication procedure more cumbersome has given birth to the approach called Identity Verification.

Identify Verification is a range of sophisticated techniques, aimed to determine whether the identity of the person accessing an application is the same as that of the account holder.

As fraudsters use increasingly sophisticated methods and means to throw Identity verification systems, it is vital to know that Identity Verification apps vary widely in sophistication and reliability, depending on the specific Identity Verification method or methods they use.

The more wide-spread methods to verify identity such apps use include:

• Photo-based verification
• Online Face Recognition
• Biometric Identity Verification (Iris Recognition and several more other biometric methods).

Photo-based verification is a popular identity Verification method that is largely unsuitable for the level of security Fintech apps require: it is relatively easy for fraudsters to trick an app that requests the user to take a selfie to be authenticated. For example, one can do this by using the account holder’s authentic photo.

Although generally more reliable than Photo-based verification, Online Face Recognition solutions must include advanced protection against sophisticated scams (like, silicone masks or 3D masks and other AI-enabled deep fakes). However, given AI-enabled scams are constantly getting more and more sophisticated, it still seems to be more prudent to use Facial Recognition as just one in a combination of security factors.

One can say with confidence that Iris Recognition is the most reliable of the more commonly used Identity Verification approaches. It boasts an approximately 95,6 % identity recognition accuracy.

Iris Recognition uses a unique human biometric – the iris of the human eye to verify identity virtually unerringly, including those cases, which involve glasses or contact lenses. Well-suited to user authentication in financial applications, Iris Recognition helps eliminate the risk of one of the security factors getting lost or stolen. Simultaneously, just like any other security factor, it can be used in combination with one or more other, additional security factors – just to be on the safe side or give you more confidence.

It should be said that there are several less widely used Identity Verification techniques one could use as additional security factors by coupling them with Face Recognition or Iris Recognition. One of such techniques is Voice Recognition that has been used in the Financial Services industry for close to two decades now. The technique is often considered to be robust enough to serve even as the primary security factor.

Also, it is also possible to employ Behavioral Biometrics. This technique can use the user’s lips movements and average geographical location to help verify their identity. One awesome trait of Voice Recognition and Behavioral Biometrics is that one can add these techniques as additional factors without making the security combination less user-friendly or time-consuming. In fact, this way one can seamlessly turn 2FA into the more reliable multi-factor authentication.

Unfortunately, both Iris Recognition and some other reliable techniques, like Fingerprint Scanning or Vein Recognition require some specific types of devices or additional equipment. Iris Recognition can be performed using a special camera or a mobile device with an iris scanner. For Fingerprint Scanning, a mobile device with a fingerprint scanner is required.

Vein Recognition that focuses on the patterns in the human palm, finger, or eyeball, has become possible with the advent of mobile devices that can authenticate users by the veins in their palms.

Data Tokenization

Sometimes, it is more expedient to replace data encryption with data tokenization – a technique that replaces sensitive data with insensitive substitutes (or tokens) to make it unreadable. In particular, data tokenization can help:

• Avoid bottlenecks with data-processing in legacy and intermediate systems – the technique does not alter the length and type of data, making it possible to process them in these kinds of applications.
• Reduce the amount of processing power required to process data.
• Tangibly cut one’s data-processing costs.
• Increase the data-processing speed.

The traits of data tokenization as a technique make it a good choice for safeguarding data in the processing of gift cards, NFC payments, and online money transfers.

To be able to benefit from data tokenization, you need to implement a token vault that will allow replacing the various types of your sensitive data with substitutes.

Separate Storage of Sensitive Data and Storage Compliance

In some cases. one can achieve a higher level of security by splitting data into several parts and storing and encrypting these parts separately. For example, in card processing, you can use three different databases to store the CVV (if one is legally authorized to store this element), card number, and expiration date.

It should also be mentioned that as far as credit card holder data is concerned, its storage must be PCI-DSS-compliant, which involves secure access controls, use of a secure network, and system monitoring and testing.

In those cases, when a Fintech decides that the storage and security of their data should best be entrusted to an external data provider, one should be aware of one important nuance too. Under this scenario, your data will be protected against any possible unauthorized access from the outside, but your storage provider and, correspondingly, their employees will likely still have access to it.

To iron this out and be able to securely benefit from this storage option, you should bring Blockchain into play. In this case, you can store your cryptographic keys in a Crypto wallet and become truly the only party that has access to your data.

Miscellaneous Useful Techniques

The best practices that allow ensuring an overall high level of data security in Fintech app development include implementing several more quite simple, but, nevertheless, useful approaches.

More specifically, it makes all the sense to implement shorter user sessions. Also, one should implement tracking of failed user log-ins. Your log-in tracking capability should lock out the user after the number of their failed log-ins has exceeded a predefined limit. Ideally, this capability should also notify your security staff about the more suspicious failed attempts to log in, as well as automatically offer some reliable alternative ways of user authentication.

Compliance with data protection regulations, user consent, and data-handling best practices

Not only banks, but also all other businesses, handling customer data are to comply with the data compliance regulations that are in place in their geographies and markets.

Let’s take the example of GDPR to see what these regulations can stipulate and try to outline some of the best practices for the secure handling of customer data.

First and foremost, you need to obtain your customers’ consent to collect, store, and handle their personal and other sensitive data.

After the data is collected, it is to be stored in your databases in an encrypted form. As far as EU customers are concerned, one can store their data only on the territory of the EU.

It’s important to bear in mind that the pivotal principle that applies to your storage of customer data is the so-called “right to be forgotten.” This means that you must always be prepared to erase ASAP the whole set of data that pertains to a customer upon their request, unless you have a legal agreement with them to the effect that you can hold and process their data for a specified period of time and this period has not yet expired. Therefore, it is essential that your systems provide the technical ability to quickly find all the data for a specific customer and erase it centrally.

If you process somebody else’s, it is also imperative that you erase all of this data for a specific customer as your contract agreement with them on the processing of this data expires. Here, and in some other cases, it would probably be best to implement some Retention Schedule functionality with a data deletion capability. This functionality can either be set to automatically erase data that has become obsolete, or send notifications to your employees in charge for them to take action in relation to this data.

Another requirement you must comply with is the ability to provide to a customer a list of all the data related to them that you hold. Obviously, being able to comply with this requirement takes corresponding automation too.

If a data breach still does occur, you are required to notify the authorities accordingly within 72 hours, while also notifying the subjects whose business activity may be affected by the breach.

To minimize the data storage-related risks, it can make sense to reduce the amount of customer data you need to hold. For example, if you need to import customer data from a business partner and could use remote access to this data instead, allow for this opportunity in your agreement with your business partner, or just arrange for such remote access with them otherwise.

Conclusion

Secure data storage is paramount to Fintech. It must be ensured profoundly enough in several different areas, which takes a good grasp of a host of important nuances, as well as deep enough knowledge of the available security options in each of these areas.

Because of this, when looking to develop a Fintech app, you should first discuss these matters with qualified experts at sufficient depth.

SPD Technology’s Fintech development team has more than once dealt with data encryption and other secure data storage-related tasks while developing several large-scale Fintech applications. They may well know the answers to the related questions that you may have – just contact us and we will shortly be in touch.