Since the turn of the century, the FinTech industry has seen exponential growth that has been equally matched by the threat of payment fraud. As online credit card transactions and wireless payments gain popularity and demand across the world, new FinTech ventures have appeared. However, in this competitive market, those ventures which lack rigorous security standards will attract malicious actors.
FinTech developers are constantly under pressure to deliver value to customers, but they are also expected to adhere to required standards of data privacy, security, and regulatory compliance. At times, these priorities conflict with one another, and it can be challenging to achieve one without sacrificing the other.
One solution is to rely on third-party services that have already implemented stringent security best practices and achieved the necessary industry certifications. Of course, this does not take away the need for a well-architected solution and due diligence on your end, but it does allow you to safely isolate and outsource parts of your business.
In this article, we will cover best practices for FinTech application development. We’ll also see how developers can take advantage of the Marqeta platform to reduce development time while being assured that their implementation adopts security best practices.
Security should be at the core of any application development process, not just the ones used in FinTech. Any application should be secure by design, meaning some best practices and strict measures should always be present throughout the software development life cycle.
Ensuring security at every stage will reduce the overall development and maintenance cost of the application. For example, a critical vulnerability in a production application, which requires a major design change, can result in substantial costs in terms of time, money, and resources. Surfacing such issues during the design, development, or even testing phase would reduce their negative impact.
Fortunately, today’s organizations are bringing in both DevOps and SecOps together, ensuring development teams are more responsible for not only the infrastructure but also the security.
Let’s briefly cover some of these secure by design development best practices.
The FinTech industry and its privacy standards have strict requirements for information protection by data custodians. One of those requirements is the use of encryption to ensure data protection against eavesdropping, data leaks, and data tampering.
An encryption standard like TLS v1.2, with a strong cipher (such as AES-GCM), will provide a robust protection mechanism for data in transit—not only in external networks (for example during client communications) but also within your corporate network. This needs to be accompanied by a strong Public Key Infrastructure (PKI) to generate trustworthy certificates and keys that can be validated and trusted by the client initiating the connection. There are many PKI providers available on the market, including Let’s Encrypt, GoDaddy, or AWS.
The Marqeta platform enforces TLS v1.2 (or above) to secure all communication with all its APIs. These APIs include functionalities like:
That means any data you share and receive from Marqeta for these and other APIs will be protected against theft or tampering.
Similar to encryption in transit, practicing data encryption at rest—using standards like AES-256—will ensure that stored data is not accessible to any application or user unless they present the decryption key.
When it comes to information protection, it’s not just data that should be encrypted. Organizations should also put measures in place for secrets management. Secrets management handles private keys, authentication tokens, passphrases, or other metadata used in applications, protecting these stored secrets from unauthorized access. This can be done with an encrypted and authenticated vault. Examples of such vaults include the following:
Authentication, authorization, and accounting (AAA) should be at the core of any application security, whether for humans or third-party applications. Authentication ensures only known, registered users and systems can use the application. The simplest way to perform authentication is through a single-factor mechanism, such as a username and password. However, other secure methods include multi-factor authentication, PKI, or signed tokens. The implementation will vary based on business requirements and specific use cases.
Once authenticated, the application should authorize user requests based on mechanisms like role-based access control (RBAC) and use the principle of least privilege to allow only the expected operations.
Finally, we have accounting. Each operation performed by applications and users should be logged and audited. Auditing allows proactive threat hunting and alerting as well as an incident response following a breach.
Apart from application controls, a FinTech application vendor should also ensure security at the infrastructure level. The underlying infrastructure can be on-premise or in the cloud. If you are using public cloud providers, you need to ensure they have the necessary industry security controls and certifications in place. For example, the three major cloud providers are certified for PCI-DSS:
Other than PCI-DSS, your business may have to implement further controls and policies to comply with industry regulations and standards such as:
Selecting a cloud vendor with existing security certifications and standards allows you to outsource some security and compliance tasks, helping you to bring your product to market faster.
It’s worth noting that public cloud services providers usually have a shared responsibility model, whereby the vendor is responsible for the physical security of their data centers, network, infrastructure, software platforms, and storage; meanwhile, the client is responsible for its application and data security. One such shared responsibility model is provided by AWS.
Marqeta’s data centers deploy the latest in hardware and software security best practices. It also maintains PCI DSS level 1 and SSAE-18 compliance certifications. As a trusted FinTech vendor, it also uses banking-grade encryption for PII, PCI, PIN data-in-transit, and data-at-rest.
Securing applications also involves the supply chain. Many organizations feel concerned that outsourcing parts of a critical application may increase the exposure to attacks if the vendor does not provide sufficient guardrails. However, those same organizations face time, budget, and resource constraints when they attempt to implement those safeguards in-house.
By using a robust due diligence process to carefully evaluate vendors and partners, you can minimize the risk of negative impact. Vendors that can present ISO/IEC 27001 or SSAE16 certifications like Marqeta can be better trusted as having robust security controls.
The FinTech industry, like the healthcare industry, is extremely sensitive about data security—and especially the threat of a data breach—when it comes to sending their data to managed service providers.
Naturally, financial institutions want to ensure their customers and other sensitive data are not seen by their competitors or any unauthorized users. That’s why organizations are often hesitant about multi-tenancy SaaS solutions, in which multiple customers' data and applications share the same physical server or even the same network. Some examples of accidental data breach scenarios when using such shared environments include allocating uninitialized detached volumes to other tenants or using a common subnet to host multiple customer servers.
As a developer, you certainly want to segregate your production environment from other customer environments. Beyond that, however, you also should ensure that production datasets are inaccessible from any lower environment such as development, testing, or staging. It’s necessary to secure your environments to eliminate the possibility of accidental or malicious data leakage.
Marqeta takes these concerns seriously, ensuring that each customer:
If your organization is planning to receive or process card payments, it’s required to comply with the PCI DSS standard by law. The certification involves an incredibly rigorous process, which means additional work in implementing your security strategy. Unless your business is already well underway in achieving this certification, the resource drain for this effort can be a problem.
Fortunately, Marqeta removes that concern.
Marqeta is PCI-DSS certified, and its PCI-compliant widgets can provide all the functionalities expected from a card management solution. These functionalities include card activating, PIN updating, sensitive information display, encryption in transit, and authentication. The financial web applications you build internally can display these widgets in iFrames, ensuring regulatory compliance and limiting your liability in case of card fraud.
3D Secure (3DS) is a protocol designed to provide an additional layer of security against fraud when processing card-not-present transactions. The protocol is now widely required for any card issuing organization to protect against card fraud for online transactions.
3DS involves the payment application first checking if the card details entered by the user are correct, and then whether 3DS is enabled for the card. If it is enabled, then the user is redirected to another part of the application (perhaps an embedded iFrame or another page) where they are asked to prove their identity. This can involve answering a specific security question or entering a verification code that has been sent to the cardholder by email or text message.
Marqeta provides a secure and flexible 3D Secure API to implement this functionality in applications that accept card payments. With this functionality, businesses can simply provide the final approval for Marqeta to allow or deny the 3DS transaction.
Payment card information (such as the card number, expiration date, and CVV) is highly sensitive and should never be stored in the same database or device in cleartext. A good security practice is to hash such information upon storage, making it impossible for unauthorized or malicious users to read the information. This process is known as tokenization and reduces the risk of identity theft and credit card fraud.
Marqeta implements a secure and intuitive digital wallet provisioning flow for its customers to use in managing the digital wallet token lifecycle. The workflow explicitly describes the steps where the tokenization process is performed—either in the digital wallet or in Marqeta’s systems. From a business perspective, your application only stores an indirect reference to the card object in the database.
This ensures that sensitive card information is securely stored in Marqeta’s database, while your application database only stores cardholder private information like names, addresses, and so on. This separation not only makes it difficult for malicious users to get complete details about cards and their users from one place, but it also offloads the entire tokenization process to a trusted third party.
Managing security in any FinTech organization is a full-time job, requiring continuous improvement to address the perpetual threats of scams, frauds, and theft. The ever-increasing volume of online transactions likewise increases the complexity of the security task. Meanwhile, more and more customers demand simpler integration, ease of use, and advanced features with built-in security.
In this article, we have provided some general best practices to help you manage the associated risks in payment card processing. As we saw, developers can outsource a significant portion of their card processing workflow to Marqeta as a trusted third party. With Marqeta’s industry-standard, secured systems, your FinTech developers will be free to concentrate on creating new features for your core business instead of worrying about security.
Don't miss more tips on how to manage security requirements for Fintech application development. Join Marqeta’s developer community, to get the latest Fintech security news straight to your inbox!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.