How Fiserv protects billions in daily transactions with PKWARE.
1 million files encrypted every day. 45,000 endpoints. 180+ Active Directory domains. 16 petabytes under management. Five years in production. One encryption layer holding the financial plumbing together.
The Fiserv environment is harder than yours. That's the point.
When Fiserv's security architect talks about downtime, he doesn't talk in hours. He talks in transactions held up. That's the dependency a five-year deployment of PKWARE produces.
If PKWARE goes down at Fiserv, billions of dollars in financial transactions stop moving.
That's not marketing language. That's Fiserv's own security team describing the dependency. It is the cleanest statement of what encryption at scale actually looks like.
Four pillars. One control plane.
Fiserv didn't deploy PKWARE all at once. The platform layered in over five years, consolidating what could have been a fragmented set of platform-specific encryption tools into one control plane. The four pillars below are how PEM does that work today.
Smartkeys: identity-bound encryption at the endpoint.
The problem
45,000 employees generate sensitive unstructured data every day. Spreadsheets, exports, ad-hoc files, attachments. The old way of solving this, asking users to decide what to encrypt, fails the second you scale past a few hundred people. Humans forget. Humans rush. Humans don't read security policies.
What PEM does
The agent runs on every endpoint. Smartkeys handle identity and authorization. Users don't manage keys, they just work, and access is granted based on who they are. Encryption and decryption happen transparently. Policy enforcement happens at PEM, not at the desktop. The default is protected.
Providing a mechanism to protect the data is definitely a key aspect. Encryption is central to compliance, especially in financial services.
The SDK: encryption built into the applications that actually run the business.
The problem
End-user encryption covers what people create. It doesn't cover what applications create, and at Fiserv, applications create most of it. Batch jobs. File exchanges with partner banks. Internal data pipelines. Transaction processing. Without an SDK, this data gets written to disk before encryption, expanding the exposure window and breaking any process that needs to read encrypted data on the fly.
What PEM does
The SDK gives Fiserv's developers a direct programmatic interface to PEM. Applications encrypt and decrypt in-stream, without writing unencrypted data to disk. PEM handles policy, key management, audit logging, all of it. Batch jobs overnight. Bank file exchanges on schedule. Transaction data flowing through pipelines. All of it stays encrypted with AES-256, consistent across every data flow.
MTA integration: inspect what you couldn't see before.
The problem
Encrypted email attachments are a security blind spot for most organizations. You can't inspect what you can't decrypt. Most companies handle this by blocking encrypted attachments at the gateway, which breaks legitimate business workflows and trains employees to find workarounds. Both outcomes are bad.
What PEM does
Fiserv integrated PKWARE's MTA infrastructure directly with Proofpoint. When Proofpoint sees an encrypted attachment, it routes it to the PKWARE MTA, which decrypts it specifically for inspection. The content gets scanned for malware, DLP, and policy issues, then re-encrypted and delivered, quarantined, or escalated. Inspection and encrypted workflows, both intact.
Discovery: a condition you manage, not a project you finish.
The problem
You can't protect data you don't know exists. Sensitive files hide on endpoints, in network shares, in legacy systems whose owners left the company five years ago. At Fiserv's scale, with 180+ AD domains and M&A history going back decades, this isn't a project you finish. It's a condition you manage.
The honest take
A hybrid model. PKWARE handles discovery where the agent footprint fits. BigID sweeps network shares and cloud databases where more agents don't scale. Findings feed ServiceNow for tracked remediation. Endpoint discovery has been paused at times when agent overhead became a concern. Real deployments have trade-offs. Real customers talk about them.
We've got gaps on server devices. Laptop endpoints. Network shares we're kind of leveraging BigID for that.
What Fiserv built isn't a point solution. It's an encryption fabric.
PKWARE plays the central role for unstructured data and integrates with the adjacent tools that are stronger at the edges. Voltage for structured database field-level encryption. BigID for broad discovery. Proofpoint for mail security. ServiceNow for workflow. The architecture call here is worth paying attention to.
The four pillars only work because of what sits underneath them.
Most encryption vendors stop where their marketing slides stop. Endpoints. Cloud. Maybe network shares. That works fine until you're running a company like Fiserv, where the systems that actually move the money don't live on a laptop.
Mainframe, midrange, and the systems financial services actually runs on.
PEM handles the endpoint and application encryption story for Fiserv. But financial services infrastructure runs on platforms most encryption vendors quietly skip: z/OS mainframe, IBM i, AIX, P-series. These are the platforms where high-volume transaction processing actually happens, and they're not going anywhere.
PKWARE covers them through PK Protect for z/OS and the broader PK Protect platform. One vendor, one platform brand, one set of policy and key-management practices spanning the entire technology stack. The security team doesn't have to integrate three different platform-specific encryption tools and reconcile their key management across each one.
Crypto agility and the post-quantum transition.
Fiserv is standardized on AES-256 today. That's the same algorithm protecting financial data across most of the industry, and it'll be the working standard for years to come. What's coming next is what makes the architecture matter.
NIST has finalized the post-quantum standards. ML-KEM, ML-DSA, SLH-DSA. The math is settled. The question for any company encrypting at Fiserv's volume isn't whether to migrate. It's how to inventory 1 million daily encryption events and execute a coordinated migration without breaking the financial plumbing.
The same infrastructure that handles today's AES-256 will handle tomorrow's post-quantum algorithms, with policy-driven control over which algorithm runs where and when. Migration becomes a configuration change, not an architecture project.
Theoretical benefits don't matter. Operational reality does.
Four things show up consistently in the day-to-day experience of running this stack, in conversations with regulators, partner banks, auditors, and engineering teams.
Compliance posture
Regulators, partner banks, internal and external auditors all ask the same question: is the sensitive data protected? When encryption is the default state, that question has a default answer. Compliance stops being a separate workstream and becomes how the platform works.
Breach posture
The "not if, but when" mindset only works if encryption is the default. When data is encrypted at the endpoint, by applications through the SDK, and inspected even when it moves through email, a breach doesn't expose plaintext. That's the difference between a breach and a disclosure event.
Developer experience
The SDK is the underrated piece. When developers can call encryption like any other library without becoming key-management experts, encryption stops being the thing security has to fight for. New applications inherit the encryption layer by default instead of being retrofitted later.
Scale posture
1 million files a day. 45,000 endpoints. 180+ AD domains. Billions in daily transactions. None of this works if encryption requires human decisions or per-application implementations. PKWARE scales because it was architected to. A focused team manages it across the entire environment.
Fiserv doesn't talk ROI in spreadsheet math. They talk in what didn't happen.
Their reference point is what happens when the encryption layer becomes unavailable for any reason. The business impact isn't measured in IT hours. It's measured in transactions that didn't move. When you process billions of dollars in daily volume and encryption is a hard dependency, downtime translates directly to revenue impact, and to the kind of conversation with partner banks that nobody wants to have.
The ROI at this scale isn't "we saved X hours of manual encryption work." It's "we moved billions of dollars in regulated, sensitive transactions today, and the encryption layer was invisible the entire time."
If you're in a vendor evaluation right now, the Fiserv deployment answers the questions you actually need answered.
Fiserv runs about 1 million files per day through it across 16 petabytes of data. Whatever your number is, it's almost certainly smaller.
Fiserv integrated PKWARE with Proofpoint, BigID, ServiceNow, Voltage, Sterling File Gateway, SFTP infrastructure, and 45,000 endpoint agents. The integration story isn't theoretical.
The SDK is the answer. Fiserv's developers call it like any other library. PEM handles the parts they shouldn't have to think about.
Fiserv has 180+ AD domains and overlapping IP spaces from decades of acquisitions. They had to build an internal translation layer just to manage their own network. PKWARE works inside that mess. Yours is probably cleaner.
Adam Coelho's interview wasn't a scripted reference call. It was a candid working session about scale, limits, and what's next. It's the kind of relationship that survives the rough quarters every long-term partnership has.
The Fiserv story isn't interesting because PKWARE works at scale. It's interesting because encryption gets treated as infrastructure, not a feature.
Three ways to go deeper.
Technical walkthrough with engineering
A direct session with PKWARE engineering on how the SDK and Smartkey architecture would fit your specific environment.
Book a walkthroughPilot in your environment
A scoped pilot focused on a representative sensitive-data use case, validating that encryption fits cleanly into your existing workflows and doesn't add friction for end users.
Scope a pilotArchitecture review against the Fiserv model
An architecture review that references the Fiserv deployment and adapts it to your stack: multi-cloud, on-prem, mainframe, or all three.
Book the reviewHow PKWARE encryption works at enterprise scale.
PK Endpoint Manager is PKWARE's encryption control plane. It manages policy, identity-bound keys (Smartkeys), and audit across endpoints, applications, email gateways, and discovery agents from one platform. At Fiserv, PEM is the layer that ties together end-user encryption on 45,000 endpoints, application-level encryption through the SDK, and email-attachment inspection through the MTA integration.
Yes. Fiserv runs PKWARE across 45,000 endpoints, 180+ Active Directory domains, and 16 petabytes of data, encrypting one million files every day. That deployment underpins billions of dollars in daily financial transactions. If your environment is smaller, encryption infrastructure isn't the limit. If it's larger, PKWARE's mainframe and IBM i coverage extends the architecture further than most platforms reach.
Smartkeys are PKWARE's identity-bound encryption keys. They tie access to who someone is, not what password they remember. Users don't manage keys directly. The agent encrypts and decrypts files transparently based on policy in PEM, so encryption becomes the default state without asking employees to make decisions.
Yes. The PKWARE SDK gives developers a direct programmatic interface to PEM, so applications encrypt and decrypt in-stream without writing plaintext to disk. Fiserv uses the SDK for batch jobs, partner-bank file exchanges, and transaction pipelines, which is how one million files per day get encrypted without human decisions in the loop.
PKWARE's MTA integration sits behind your existing mail gateway. Fiserv routes encrypted attachments from Proofpoint to the PKWARE MTA, which decrypts them for inspection (DLP, malware, policy), then re-encrypts and delivers, quarantines, or escalates. The result is full inspection of encrypted mail without blocking legitimate business workflows.
Yes. Fiserv runs PKWARE alongside Voltage (structured database field-level encryption), BigID (broad discovery across network shares and cloud databases), Proofpoint (mail security), and ServiceNow (workflow and incident tracking). PKWARE is the central control plane for unstructured-data encryption and integrates with adjacent tools that are stronger at the edges.
Yes. PK Protect covers z/OS mainframe, IBM i on Power, AIX, and P-series alongside endpoint, server, and cloud. One vendor, one key-management layer, one set of policy and audit practices spanning the full technology stack. For a company at Fiserv's scale, that single control plane is the prerequisite that makes a unified encryption strategy viable.
Yes. PKWARE supports the NIST post-quantum standards (ML-KEM, ML-DSA, SLH-DSA) with hybrid classical-and-post-quantum mode by default. Algorithm updates ship through the same agent-update mechanism as any other release, so the same infrastructure protecting AES-256 today handles post-quantum algorithms tomorrow as a configuration change rather than a re-architecture.
Database-only encryption protects the structured tier. Most enterprise data exposure isn't there. It's in the unstructured files that endpoints, applications, partner exchanges, and email generate every day. Fiserv runs PKWARE for unstructured data and Voltage for structured database fields, because the two layers solve different problems. Picking one isn't a strategy.
Get the full case study.
Fourteen pages on how Fiserv built an encryption fabric across endpoint, server, mainframe, and partner-bank transfer, with the architecture diagrams and the candid trade-offs the page above couldn't fit.
21 of the 25 largest U.S. commercial banks. 30% of the Fortune 100.
