Fintech is Solving Problems in Finance, but Introducing Risk Part 3 of 3
In our previous installment, we examined fintech regulation, the industry’s trend towards increased attention to data security, and various agencies that are getting involved. Our concluding observation was that while these are positive trends, the remaining need for consistent, overarching regulation is still lacking. So, with our final installment, we will be looking at fintech data security solutions and how they secure the sensitive data moving back and forth between your environment and your chosen fintech(s). A major part of vetting data security solutions for your organization comes through the willingness of the fintech, itself, to be audited. What do these audits look like, and what is required? How do these audits translate into the highest levels of internal data security? At the end of the day, you are responsible for implementing a data security program that addresses your organizational risk appetite and meets the regulatory compliance requirements your organization must meet. With more fintech solutions hitting the financial market, how do financial institutions evaluate whether their fintech has implemented data security best practices without introducing new risks to the consumers utilizing their platforms? What are the data security solutions on the market today? How will the data security solutions hold up in a data breach?
SOC (Standards for Attestation Engagements)
One of the realities of securing fintech is understanding that the fintech solutions are evolving much faster than regulatory compliance. However, the mere presence of so much coordinated oversight, and the need to meet multiple standards, is bound to increase data protection. For example, the AICPA (American Institute of CPA’s) developed the SOC for IT organizations. “These reports are intended to meet the needs of a broad range of users that need detailed information and assurance about the controls at a service organization relevant to security, availability, and processing integrity of the systems the service organization uses to process users’ data and the confidentiality and privacy of the information processed by these systems.”
SOC 1, 2 and 3
A great place to start is with a SOC 1 Assessment (SSAE 16 – Reporting on Controls at a Service Organization). The objective of having a fintech perform the SOC 1(SSAE 16) assessment is to showcase whether “internal controls have been effectively designed to meet certain control objectives related to the service(s) provided by a service organization to customers.” Furthermore, a SOC 1 assessment will determine if the fintech is meeting these requirements in a specific timeframe. This certificate of attestation is something you should require from each of your fintech vendors. It is important to note here that a SOC 1 assessment is based on principles relevant to the fintech, so there is some flexibility in definition. A SOC 2 assessment makes sure that the controls and testing are standard across all fintech service providers. A SOC 2 report is based on five trust principles: security, availability, processing integrity, confidentiality, and privacy. The goal of SOC compliance is to showcase whether your fintech is utilizing data security best practices. A SOC 3 assessment reports the same type of information as a SOC 2, but it is intended for a general audience, and the reports are shared openly or featured on an organization’s website to showcase compliance.
Fraud Prevention/Threat Detection Not Enough
Fraud prevention is a necessary layer to defend against fraud, but it was never intended to thwart a cyber attack. Predictive analytics and data science are focused on isolating anomalistic actions and behaviors, and then rejecting transactions that might be fraudulent. One massive caveat, however–how is the financial data itself secured when moving between multiple environments? SWIFT attacks have been focused on sending fraudulent payment instructions to different financial institutions, but if the message itself is secured using encryption or tokenization, then the data becomes much more difficult to steal. Typical security alerts are not intended to secure data. For instance, in some of the SWIFT attacks, anti-virus alerts were triggered for malware, but at that point it was too late. These types of attacks become even harder to defend against when looking at the distributed ledger technology of blockchain.
Encryption to Secure Transactions
Encryption replaces sensitive data with a mathematically derived value which, ideally, can only be read by an authorized entity—machine or human—that has the keys necessary to decrypt the value. This level of security is now ubiquitous for financial transactions and helps to ensure that no “man in the middle” can read the encrypted PAN and other information. When a merchant’s IT systems are breached by hackers, the database of customer PANs can be quickly siphoned off to the far corners of the dark web to be sold for fraudulent use, even if it’s encrypted. After all, encryption is just computer-driven mathematics, and all it takes is another powerful computer and clever software to decrypt it. That’s the basic weakness of encryption—it can be decrypted. Encrypting data may make it temporarily secure while in transit, but once at rest in business systems, the data is vulnerable to breach and theft. Another weak point in using only encryption to store sensitive data is that every person or business process needs to have access to the encryption keys to decrypt the data whenever it is used in operations.
Tokenization to The Forefront
Adding tokenization to the payment stream has four distinct advantages over using only encryption. Let’s trace the same path using tokenization in addition to encryption. The first stage is the same, but once the payment information is accepted to initiate a transaction, the data either remains encrypted or is immediately re-encrypted using different keys. We see the second advantage of having a tokenization solution integrated into the transaction stream when the encrypted payment data is immediately sent to a secure data vault. Here it is stored and swapped with a mathematically unrelated token, the third advantage. Finally, the token is sent back to the merchant to use for additional processing and storage. This is the fourth key advantage of adding tokenization to your layered security processes–you can use this token securely in your business systems as if it were the original data. The real PAN is sent on by the tokenization provider to the payment processor of choice to be verified and charged, after which the confirmation is returned to the merchant to complete the transaction.
Encryption and Tokenization Are Friends
In summary, encryption alone does not irrevocably secure payment or personal information. To secure data in transit and at rest, encryption and tokenization must work together, with each performing critical security tasks to protect sensitive data from theft at different stages in the payment stream. To further that, while the technology of tokenization and encryption is actually straightforward, implementation is key to making it completely secure and tightly integrated with not only internal business processes but also with third-party payment processors and service providers, such as fraud prevention. And, while tokenization and encryption play nice together, your fintechs should be able to provide a SOC attestation of compliance to feature financial statements and their internal controls for security, availability, processing integrity, confidentiality and privacy. These attestations of compliance create the accountability your organization needs on how your fintech secures sensitive data sets in your environment.