Layered data security: Balancing security and utility

With a mission to change banking for good, Capital One has always operated at the intersection of cutting edge technology and finance.

As an early adopter of cloud-native architecture within our industry, we were faced with two non-negotiable mandates: uncompromising data security and operational agility at massive scale. As we began rearchitecting our data infrastructure for migration to the cloud, Capital One made the strategic decision to tokenize our sensitive data.

To handle the scale and complexity at which Capital One operates without compromising on data security, we developed an in-house tokenization engine designed to handle billions of operations per month. Purpose-built to be as performant as it is secure, this engine also improved our security posture by protecting our most sensitive field elements across operational and analytical data stores.

As enterprises continue to navigate evolving regulatory requirements, traditional data security practices create friction. Overly restrictive approaches can unintentionally silo critical data at a time when generative AI and digital transformation demand unprecedented data utility and access. This dynamic creates a new, more nuanced challenge: How do we balance foundational security requirements with the practical, day-to-day needs of our business?

The consequences of failing to strike the right balance can create unnecessary friction. When security protocols become a barrier to strategic innovation and operational agility, it can impede key functions, stall business intelligence and hinder customer support. Analytics teams may not need to see a single byte of plaintext data to conduct business intelligence operations or train an AI model, but customer service representatives may need to verify the last four digits of a Social Security number (SSN). 

This is the new "last mile" problem of data protection: Security vs. utility.

Forcing a binary choice—either total exposure or full de-identification—creates friction and risk. A truly modern data security strategy isn't about choosing one, it's about layering both. Understanding when to use tokenization and when to layer in dynamic masking is key to unlocking the full utility of enterprise data without compromising security.

Inspired by our own data transformation journey, Capital One Software developed Databolt. Built for commercial use, it provides foundational data security by de-identifying sensitive data at rest, in transit and in use.

When data is tokenized, it is transformed into a fully de-identified non-sensitive string (the token). This token can then be stored and used in place of the sensitive plaintext data, ensuring the original, raw data is not exposed in your systems.

But what about operational use cases that require access to at least a portion of the raw data? This is where Databolt’s dynamic masking capabilities come into play. Dynamic masking builds upon tokenization and provides a critical balance between security and usability by allowing for partial visibility of sensitive data on read.

With dynamic masking, the data remains fully tokenized and secure at rest, but when an authorized user requests to view it, a predefined mask is applied securely on your server. This design prevents raw sensitive data from leaving your data store while in transit to downstream applications and helps ensure that individual users only have access to the precise data they need to perform their job.

By implementing dynamic masking alongside tokenization, organizations can avoid the “all-or-nothing” trap. This multi-layered approach maintains high security standards while granting granular role-based access to partial data visibility.

Effectively implementing a multi-layered approach to data security requires more than just the right technology; it demands a clear governance framework rooted in the Principle of Least Privilege. By pairing tokenization with Databolt’s dynamic, server-side masking, you create a mechanism to enforce this principle. The challenge then shifts to precisely defining which roles require access to specific pieces of data and what level of visibility is required in order to effectively execute business operations.  

To help navigate these decisions, we’ve shared some example guidelines and best practices below. By default, we recommend all sensitive data be tokenized at ingestion and stored, transported and processed in this tokenized form. The strategic decision then becomes: What level of data visibility meets the specific access requirement of the user or application?

Modern data protection isn't a single product; it's a layered strategy.

• Modern, format-preserving tokenization is the non-negotiable foundation. It de-identifies your data, protecting it down to its core.
• Databolt’s dynamic masking capability is the flexible utility layer. It works seamlessly on top of data tokenized by Databolt to provide controlled, partial visibility for specific operational needs.

You no longer have to choose between locking down your data and making it useful. Databolt is built upon the same security principles that Capital One developed, validated and hardened to secure billions of sensitive transactions each day. By combining Databolt’s foundational tokenization capabilities with its granular dynamic masking capabilities, you can achieve a resilient, secure architecture that also unlocks the full utility of your data.

To learn how Databolt can address your most complex data security challenges, schedule a demo today.