The Banking Story I Tell Everyone (Written on a 7am Train, Three Cups Into Bad Coffee)

This blog post started as a Teams message to our Director of Marketing. I was on the 7am train into Manhattan, three cups deep into really bad police station-esque coffee, and I’d just finished walking a colleague through what PKWARE actually does for banks. Michael asked if he could use the line about the coffee. So here we are. The story stayed. The coffee got worse.

Here’s what I told him.

When I walk into a major bank, the question isn’t “what does your product do.” Every vendor has a product. Every vendor has a deck. The real question, the one nobody actually asks out loud, is this:

“At our scale, do we really know where every piece of sensitive data lives, and can we do something about it before someone else does?”

That’s not a question about whether the security team is doing their job. It’s a question about whether anyone can. Two hundred thousand endpoints. A dozen cloud environments. A SharePoint footprint with millions of files. Legacy systems still running mission-critical workloads. At that scale, visibility is an architecture problem, not an effort problem.

Here’s how that conversation actually plays out at the banks I work with, by name.

JPMorgan Chase runs over a quarter of a million endpoints. Trading floors, branch offices, call centers, contractor laptops, devices that live in places nobody on the asset team can fully account for anymore. On every single one of them, somewhere, is data nobody meant to leave there. PCI. PII. An old screenshot of a customer account from a help-desk session four years ago that never got cleaned up.

This is where PK Protect lives.

We don’t just find that data. We tell you what it is, how long it’s been there, whether it’s still being touched or has gone stale, and then we apply the same policy that found it to protect it. Encrypt it. Redact it. Mask it. Tombstone it. Delete it. The action depends on the data, the regulation, and what your team decides matters most.

One scan. One policy engine. Over 250,000 endpoints. That’s the floor.

FISERV has a different version of the problem. The data isn’t unknown. It’s everywhere. Every server, every share, every legacy file repo. The CISO doesn’t need a discovery tool. He needs an audit posture that makes the next exam survivable.

So we scan the same way we do for endpoints. But the action changes. Instead of just protecting data in place, we move and centralize sensitive data into finite, defined locations. Home plate. One place where the policy lives, one place auditors can point at, one place compliance can defend. Discovery still happens. Protection still happens. Now everything has a return address.

When the regulator walks in, the answer to “where is your card data” isn’t a 90-minute meeting. It’s a query.

Western Union isn’t a bank in the consumer sense. At the data layer, the problem set is identical. Hundreds of millions of customer records, PCI-regulated transactions at global scale, and a SharePoint footprint to match.

Microsoft can label files in SharePoint. Microsoft has also been transparent about the volume thresholds that come with their native labeling at scale. That’s not a complaint. That’s just what happens when you’re running a global service.

That ceiling is exactly the problem we solve at Western Union. We scan SharePoint, identify the sensitive content, and apply Microsoft Sensitivity Labels at a volume the native tooling isn’t designed to sustain. Same outcome, without the volume constraints.

And here’s what most teams miss: every PK Protect policy carries a fall-back. If a file can’t accept a label for whatever reason (file type, locked permissions, format limitation, you name it), the policy doesn’t fail. It steps to the next action. Mask the content. Redact it. Move it. Quarantine it. The data gets protected one way or another.

Most labeling tools throw an error and move on. We protect and move on.

Now scale up. Way up. We’re not talking endpoints anymore. We’re talking HDFS clusters, Hive tables, S3 buckets, Azure Data Lakes. The kind of footprint Wells Fargo and USAA run, where a single misconfigured bucket can put more PII on the open internet than some small countries hold in total.

Same scan engine. Same policies. Same protection options.

What changes is the surface. PK Protect treats a petabyte-scale data lake the same way it treats a marketing manager’s laptop: find it, classify it, protect it, prove it. The rigor doesn’t change. The format changes. That’s the whole point of the platform.

Here’s where the conversation usually gets quiet. Mention COBOL datasets, GDG files, PDS files, and most “modern” security vendors smile politely and change the subject.

We don’t.

At Truist, we apply the exact same discipline to the mainframe that we apply to a laptop. Discover the sensitive data inside the COBOL programs and the datasets they touch. Apply policy. Encrypt, redact, mask, delete. The mainframe is part of the same control plane as the endpoint and the cloud.

For banks running this kind of footprint, and there are a lot more of them than the analyst reports suggest, that’s a serious differentiator. No other vendor in this category will sit at all three tables: endpoint, cloud, mainframe. And those conversations tend to move quickly.

One interface. One product. One policy engine running across endpoints at JPMorgan Chase, file servers at Fiserv, SharePoint at Western Union, big data lakes at Wells Fargo and USAA, and the mainframe at Truist.

The promise is simple. What we found is accurate. What’s sensitive is protected. What’s proprietary is locked down. What’s unique to your customers, your transactions, and your business stays where it belongs.

Banks aren’t buying a feature. They’re buying assurance. The only way to deliver assurance at this scale is one architecture that handles every surface where data lives.

That’s the story I tell. That’s why it took me one Amtrak ride and three cups of bad coffee to write it down.

If I had been arrested at Penn Station that morning, I would’ve confessed to something just to get better caffeine. The story still stands.

If you’re running a security or data protection program at a bank, and any of this sounds like the conversation you keep meaning to have, let’s get on a call. I’ll bring my own coffee.

Which institutions use PKWARE for data protection?

Major financial institutions including JPMorgan Chase, Fiserv, Western Union, Wells Fargo, USAA, and Truist use PK Protect for sensitive data discovery and protection across endpoints, file servers, SharePoint, cloud data lakes, and mainframe environments.

Does PKWARE protect data on mainframes?

Yes. PK Protect discovers and protects sensitive data inside COBOL programs and the datasets they touch, including GDG and PDS files, using the same policy engine that protects endpoints and cloud data. No other vendor in this category covers endpoint, cloud, and mainframe in one product.

How does PK Protect handle SharePoint at scale?

PK Protect scans SharePoint, identifies sensitive content, and applies Microsoft Sensitivity Labels at volumes beyond what native Microsoft tooling is designed to sustain. Every policy also includes a fall-back action. If a file can’t accept a label, PK Protect will mask, redact, move, or quarantine the data instead.

What does data protection for banks at scale actually mean?

Data protection for banks at scale means discovering, classifying, and protecting sensitive data (PCI, PII, proprietary records) across every surface where it lives. Endpoints. File servers. SharePoint. Cloud data lakes. Mainframe datasets. One policy engine, applied consistently across all of them.

Can one tool actually handle endpoint, cloud, and mainframe data protection?

Yes, in the case of PK Protect. The same scan engine and policy logic apply across hundreds of thousands of endpoints, petabyte-scale data lakes (HDFS, Hive, S3, Azure Data Lake), and mainframe environments running COBOL programs and legacy datasets.