Consumer data is a vital piece of transforming business, from complex issues such as understanding pain points or unmet needs to more general approaches such as personalized advertising. Complexities arise, however, considering that holding data means increased risk of vital data theft. Compliance and regulatory standards such as Gramm-Leach-Bliley Act (GLBA), Sarbanes-Oxley Act (SOX), and Payment Card Industry Data Security Standards (PCI DSS) have long been followed by banks, businesses, and healthcare organizations for security programs. Yet it is only more recently that individuals have become increasingly aware of the amount of data they release to companies, and are now demanding ways to better protect their data and by extension, themselves.
Because the United States lacks a single, comprehensive federal law to regulate both the collection and use of personal information, the resulting regulations often create overlapping and contradictory protections. While there could be promise of such a privacy law in the US in the future, in the meantime, US commercial banks must learn how to balance privacy and protection across the various mandates relevant to the financial industry.
Read this complimentary ebook to learn more about:
- Balancing privacy and protection across differing mandates
- Factors to consider when protecting consumer data across regulations in commercial banking
- Tips on building multi-mandate compliance
Why Commercial Banking Faces Overlapping Privacy Rules
The European Union regulates personal data across every industry at once. The United States regulates it sector by sector, which leaves the definition of protected data different from one rule to the next. Banks sit where those differences collide.
There are 4,978 commercial banks in the United States, ranging from $3.4 million to $3.2 trillion in assets. The largest serve customers in every state, so they answer to industry mandates and to state-level mandates at the same time, and the two do not define personal data the same way.
What Each Mandate Actually Protects
GLBA, the Financial Modernization Act of 1999, covers general identifiers along with nonpublic personal information: data that is not publicly available and is connected to providing a financial product or service. It can be shared with affiliates and service providers, but it must be protected, and a card or account number may never be disclosed to another company.
SOX is not a privacy law. It governs financial auditing controls, and Section 404 is where it meets data protection, because public companies must assess their internal controls for reliable financial reporting and have an auditor attest to that assessment. The financial information it covers is broader than personal data.
PCI DSS protects cardholder data, and cardholder data means more than the card number. It includes the primary account number, cardholder name, expiration date, verification value and the data stored on the strip or chip. Card data should not be stored unless it must be, and where it is stored it has to be unreadable.
State laws such as CCPA, CDPA, CPA and 23 NYCRR 500 protect information that identifies or could be linked to a person, and they attach to residents of that state regardless of where the bank operates. They also grant rights: to know, to access, to correct, to delete, and to opt out of targeted advertising and the sale of personal information.
Factor One: Separate What You Collect From What You Keep
Data you never collected cannot be breached, and data you no longer hold cannot be requested. Recorded service calls are the common example, since transcription turns a call into a text file containing names, addresses and account numbers that already exist elsewhere.
Define what is collected, why, and how long it is kept before the collection starts. Hold what retention requires, protect it while it is held, then dispose of it.
Factor Two: Know Where the Data Lives
It is impossible to protect what you do not know you have. Data sits in databases, repositories, data lakes, cloud storage and on the laptops of people who saved a copy to work on a report.
Each location protects differently. A cloud provider secures data once it has arrived, which leaves the transfer as the exposed step. Automated discovery scanning is what keeps the picture current, because it reports new personal data as it appears rather than at the next audit.
Factor Three: Match the Protection to the Audience
Production data in core banking systems is generally encrypted, and access is restricted to the teams that need it. Test environments are the harder case, because they need realistic data and are not production.
Masking answers that. Account numbers, names and addresses are rendered non-identifying while the data keeps its shape, so a copied database still supports accurate measurement. Denying access to entire data sets because they might contain personal data solves compliance by stopping work.
Factor Four: Write Policies to the Highest Common Denominator
Compliance is assessed annually and has to hold continuously. Where mandates overlap, one control can satisfy several: an opt-out box on a collection form covers CCPA and GDPR, and leaving it unchecked by default satisfies GDPR’s stricter requirement.
Policy alone will not satisfy an auditor. The written policy has to describe what the institution actually does, and automated discovery, protection and reporting are what produce the evidence that it does it.
Factor Five: Be Ready for a Data Subject Access Request
Customers can require a bank to show, correct or delete what it holds on them, and a DSAR is how that request usually arrives. The form should be easy to find and easy to submit.
Answering it is the difficult half. Searching every repository for one person on demand does not scale, so discovery needs indexing behind it, holding what is known about each identity and where it sits. The right to know and the right to erasure are then two actions against the same index rather than two separate projects.