Transaction Records Need Keys Your Bank Controls, Not Your Vendor

Every core banking, payments and file-sharing vendor selling to financial institutions says client data is encrypted. That sentence hides the only detail that actually determines protection: who holds the key. If the vendor generates and stores it, encryption protects transaction records from outsiders and does nothing to protect them from the vendor itself, or from anyone who can lawfully compel that vendor to decrypt.

This is not a hypothetical concern for an institution moving client funds and confidential deal data through third-party platforms. A locked vault means nothing if the vendor keeps a spare key and hands it over the moment a court order arrives. This article looks at what key custody actually changes for financial institutions, why it is the detail most security reviews skip, and what genuine customer-owned key management requires in practice.

Executive Summary

Most conversations about data encryption in financial services stop at algorithm and key length, as if AES-256 automatically means client data is safe. It does not. The question that determines whether encryption actually protects an institution is who controls the key, because whoever controls the key controls the data, encryption or not. When a vendor generates, stores and manages the key on the institution’s behalf, that vendor retains the technical ability to read transaction data at any time, for any reason, including a reason the vendor did not choose, such as a lawful order from an authority with no relationship to the institution at all. Customer-owned key management, backed by hardware, removes that ability entirely. For risk and security leaders, this reframes encryption from a checkbox in a vendor questionnaire into an architectural decision with a specific and testable outcome: can the vendor decrypt our data, or not?

Key Takeaways

1. Encryption only protects data from parties who do not hold the key. If the vendor holds it, encryption cannot protect the institution from the vendor or from anyone who can compel the vendor.
2. Bring-your-own-key and vendor-managed-key models are not the same control. One removes the vendor’s ability to decrypt client data; the other leaves that ability fully intact.
3. Hardware security modules turn key ownership from a policy into a physical fact. A key generated and stored inside a bank-controlled HSM cannot be extracted by the platform hosting the data, even under administrative access.
4. Key rotation and cipher control determine whether ownership is real or nominal. An institution that cannot rotate keys on demand or control which ciphers are used does not have operational control, only a label on a data sheet.
5. Encryption strength is irrelevant if the wrong party holds the key. A 256-bit key managed by the vendor protects against exactly the same threats as a weaker key managed by the vendor: none of the ones that matter most to a regulator.

Why Encryption Strength Is the Wrong Question for Financial Data

Security reviews of financial platforms ask about encryption constantly, and the answers almost always describe the algorithm: AES-256 at rest, TLS 1.3 in transit. These answers are true and largely beside the point.

Encrypted Data Still Has an Owner of the Key

Every encrypted transaction record has exactly one thing standing between it and a plaintext read: the key. Whoever holds that key can read the data, decrypt it for someone else, or be compelled to decrypt it under legal process. The strength of the encryption algorithm has no bearing on any of this. A file encrypted with a strong cipher and a vendor-held key is not meaningfully more protected from the vendor than a file with weaker encryption, because the limiting factor in both cases is the same: the vendor can read it if it chooses to, or if it is ordered to.

Why Vendors Rarely Lead With This Distinction

Vendor documentation aimed at financial institutions tends to describe encryption in terms that sound complete: “encrypted at rest and in transit using industry-standard algorithms.” This is accurate and incomplete. It says nothing about who generated the key, where it is stored, or whether the vendor’s own infrastructure has a path to it. An institution reading only the encryption claim, without asking the key-custody question separately in its own vendor risk assessment, walks away with a false sense of coverage.

What Customer-Owned Key Management Actually Requires

Owning a key is not a single feature so much as a chain of conditions that all have to hold. Break any link and the institution’s control over the key becomes theoretical rather than operational.

Bring Your Own Key Versus Vendor-Managed Key

In a vendor-managed key model, the platform generates and stores the encryption key as part of its own infrastructure. The institution may never see the key at all. In a bring-your-own-key, or customer-owned key, model, the institution controls key generation and storage, typically through a hardware security module it administers or has dedicated access to. The difference is not cosmetic. It is the difference between a vendor that can technically decrypt client data and one that cannot, regardless of what either vendor’s marketing materials say about encryption strength.

Why Hardware Security Modules Matter More Than the Word Suggests

A hardware security module is a dedicated physical device built to generate, store and manage cryptographic keys in a way that resists extraction, even by someone with administrative access to the surrounding system. Integrating key management with an HSM, rather than storing keys in software alongside the application, turns key ownership from a configuration setting into a physical constraint. A software-only claim of customer key ownership can, in principle, be quietly reversed by a vendor with sufficient access to its own infrastructure. A properly integrated HSM removes that possibility by design, not by policy, which matters enormously when the data in question is client transaction records.

Why Rotation and Cipher Control Decide Whether Ownership Is Real

Holding a key once is not the same as controlling it continuously. Two operational details separate genuine key ownership from a claim that looks correct on a data sheet but breaks down in practice.

On-Demand Key Rotation

If an institution suspects a key may have been exposed, whether through a compromised credential, a departing employee, or a suspected breach, the ability to rotate that key immediately, without waiting on the vendor’s release schedule or support queue, is what makes key ownership operationally meaningful. A key the institution cannot rotate on its own timeline is a key the institution does not fully control, whatever the ownership documentation says.

Granular Cipher and Protocol Control

The ability to enable or disable specific cipher suites and control which TLS versions are permitted is a related but separate form of control. An institution that needs to retire a deprecated cipher ahead of a compliance deadline, or restrict connections to TLS 1.3 only, should not have to wait for the vendor to make that change on its behalf.

Building Key Custody Into Vendor Due Diligence

For a security team evaluating a vendor, the practical shift is straightforward to describe and easy to skip under time pressure: ask who generates the key, where it is stored, whether an HSM is involved, and who can rotate it and on what timeline. A vendor that answers all four clearly, with the institution controlling every step, has a defensible key custody model. A vendor that answers only the first question, about algorithm and key length, has told an institution nothing about who actually controls its data once it is encrypted.

How a Data Control Plane Makes Key Ownership an Architectural Guarantee

Customer-owned key management only delivers on its promise when it is built into the platform’s architecture rather than offered as an add-on that most deployments skip. A Data Control Plane that treats key custody as a foundational property, rather than an optional configuration, ensures that the vendor’s technical inability to decrypt client data holds across every channel that data moves through, including email, file sharing, APIs and AI agents, not just the ones an institution happened to configure carefully.

The Kiteworks Data Control Plane integrates customer-owned encryption keys through a hardware security module, including support for widely deployed HSM providers, so that key generation and storage sit outside Kiteworks’ own reach. Institutions retain the ability to rotate keys on demand, control which ciphers and TLS versions are enabled, and run on single-tenant architecture where that key custody is not shared with any other customer’s environment. On top of that foundation, data-aware, zero-trust controls govern every send, share and access action across every channel, and every action is captured in a tamper-proof, unthrottled audit log that feeds directly into SIEM tooling, so the key custody claim is backed by a record of enforcement rather than a line in a data sheet.

Institutions that want to test their current vendor’s key custody model against this standard can schedule a custom demo to see how customer-controlled HSM integration applies to their own encryption and compliance requirements.