I spend most of my week with our channel partners, and through them with the banks, insurers and credit unions they serve. Between December 2025 and June 2026 we reviewed 45 recorded partner calls to find out what buyers actually ask before they commit.
The product fit was rarely the problem. The same questions were.
So here they are, the ten questions financial institutions ask us most, answered the way we answer them on those calls.
If you are evaluating data protection for a regulated environment, you are probably asking at least half of them.
1. Is DataStealth a DSPM tool?
DataStealth does what a DSPM tool does, and then keeps going. Partners field this question first on almost every call. Data security posture management (DSPM) finds and classifies sensitive data and tells you how exposed it is. That is useful, but it stops at the report. As our platform FAQ puts it, DSPM is a subset of the broader data security platform category. Full platforms add active protection.
DataStealth does the discovery and classification, then replaces the sensitive values with tokens so the data is protected, not just catalogued. We wrote up the difference in more depth in DSP vs DSPM.
2. How is that different from the tools we already own?
Most financial institutions already run some mix of discovery, DLP and encryption. Each answers a different question:
- Discovery and DSPM tell you where sensitive data lives.
- DLP watches data movement and blocks what looks risky. It works on the boundary, so the data behind it is still real. See DSPM vs DLP.
- Encryption hides data behind a key. Whoever holds the key can read it.
- DataStealth removes the real value from the systems that hold it, so a stolen copy of the protected fields is worthless.
If you are comparing named vendors, our breakdowns of Microsoft Purview alternatives and DataStealth vs. Varonis go product by product.
3. Why tokenization instead of encryption, and is it quantum-safe?
Encryption is a mathematical transformation. The ciphertext still contains the original data, and anyone with the key can get it back, and data protected by today's public-key cryptography is exposed once a large enough quantum computer exists. That is why harvest now, decrypt later matters to banks: data with a long shelf life, like account history or a SIN, is worth stealing today and decrypting later. NIST finalized its first post-quantum standards in August 2024, and its draft transition guidance, NIST IR 8547, proposes disallowing RSA and elliptic curve cryptography after 2035. Canada's federal PQC roadmap (ITSM.40.001) sets the end of 2031 for high-priority Government of Canada systems.
Vaulted tokenization works differently. A token is a random substitute with no mathematical relationship to the original value, which sits in a separate vault. There is nothing for a quantum computer to decrypt. As I told a room of executives at the uOttawa-IBM Cyber Range in September, an attacker who expected my first name and surname gets "Apple Banana" instead.
We also build vaultless tokenization and format-preserving encryption, which are key-based and carry different tradeoffs. Ed Leavens explains when to use each in Choosing Deliberately.
4. What happens if de-tokenization fails? Is our data gone?
A banking prospect asked this in almost exactly those words, and it is a fair question. With vaulted tokenization the original values are not destroyed. They are held in the DataStealth vault, which is distributed across nodes, encrypted, and separate from your application infrastructure. Every request to de-tokenize is authenticated and logged.
If an inline component cannot reach the policy engine or the vault, DataStealth fails closed: it blocks the traffic rather than letting clear text through. That makes vault availability a design requirement: high availability and redundancy are planned to match the systems that depend on the vault.
5. We have to send clear-text data to regulators. How does that work?
Through scoped de-tokenization. You define which users, systems and report pathways are authorized to see real values. Those pathways receive clear text, through a controlled channel with an audit record for every request. Everything else keeps seeing tokens.
Large extracts work the same way. A complete customer record set can be de-tokenized in bulk as a batch job, under the same policy, rather than one value at a time.
6. Can you protect data on our mainframe?
Yes. Mainframes are where a lot of the most sensitive banking data still lives in clear text, and they are hard to put agents on and risky to rewrite. DataStealth works without installing agents on z/OS or modifying COBOL applications. We have secured IBM DB2 databases and live TN3270 sessions with zero code changes.
If that is your environment, start with how to tokenize DB2 data without changing COBOL or CICS applications and our guide to mainframe security for banking.
7. How does tokenization reduce PCI DSS scope?
The PCI Security Standards Council's own tokenization guidelines say tokenization "may simplify a merchant's validation efforts by reducing the number of system components" PCI DSS applies to. Systems that only ever see tokens, and cannot de-tokenize them, can come out of scope.
Two caveats belong in every conversation. The tokenization system itself, including de-tokenization and the vault, stays in scope. And scope is confirmed in your assessment, not by a vendor. Our PCI DSS page covers the mechanics.
8. Do we need to change our applications or install agents?
No. DataStealth sits inline between your applications and data stores, without agents or changes to application code. Tokens are format-preserving: a 16-digit card number becomes a 16-digit token that still passes Luhn validation, and a SIN becomes a nine-digit token. Your schemas, validation rules and downstream reports keep working. Consistent tokens also keep referential integrity, so joins and analytics run on protected data.
9. Can you protect the sensitive files in SharePoint and Microsoft 365?
This is where many financial institutions start. SharePoint is where client spreadsheets, scanned forms and loan files tend to collect. Native controls such as permissions, DLP policies, encryption at rest and audit logs all help, but the sensitive content itself still sits in clear text for anyone who gets past them, including cloud admins and anyone holding a compromised admin account.
DataStealth sits inline between your users and SharePoint. Sensitive values in documents are tokenized as files are uploaded, so the repository stores tokens, and they are de-tokenized in flight only for authorized users when a file is downloaded. Versioning, search, co-authoring and workflows keep working, and the same protection covers OneDrive sync and documents shared in Microsoft Teams.
10. How does this help with Canadian privacy and data residency rules?
Canadian rules set the standard by sensitivity and risk rather than by prescribing a tool. PIPEDA's safeguards principle asks you to protect personal information in a way that is appropriate to how sensitive it is, and OSFI's Guideline B-13 sets expectations for technology and cyber risk at federally regulated institutions.
Tokenization changes where the sensitive data actually lives. The real values sit in the vault, which can stay in the jurisdiction you require, while tokens flow to applications, analytics and partners elsewhere. Deleting a vault mapping also makes that individual's tokens unresolvable everywhere they exist, which helps with erasure requests across a sprawling estate. For more, read data residency vs. data sovereignty.
Where DataStealth fits in a Zero Trust strategy
Zero Trust is a strategy, not a product, and no single platform delivers all of it. CISA's Zero Trust Maturity Model describes five pillars: identity, devices, networks, applications and workloads, and data.
DataStealth is a Data Security Platform (DSP) built on Zero Trust, and it owns the data pillar. It protects discrete sensitive values such as card numbers, account numbers and identifiers, including values inside documents, and its policy decisions draw on context from the identities and applications making each request.
The other pillars still matter. Identity, device and network controls decide who gets in, and encryption still protects whole files, backups and network connections; we deploy both in layers.
What DataStealth adds is the Zero Trust principle of assume breach: if someone does get in, the protected fields they reach hold tokens, not real data. It also does not decide your compliance scope or legal position; your assessor and your counsel do that.
Where to start
If the data was never real, the breach call ends differently. Instead of an emergency board meeting, it is: go back to bed, it wasn't real data.
You do not need to tokenize every system by next quarter. We work to an 80/20 rule of thumb: most of an enterprise's sensitive data sits in a small share of its systems, such as core banking, CRM and file shares.
Find those crown jewels first, assume you do not yet know where all of it is, and do not skip the mainframe because it is old. A SIN is as sensitive today as it was 20 years ago.
If you want the fuller version of this conversation, read what if the data that was stolen wasn't real, anyway?
Bring us your hardest question
Whether it is a regulator report, a mainframe nobody wants to touch, or a SharePoint site full of client files, we will walk through it in your environment.
Book a demo with our team to get started.
Victoria is a senior B2B sales leader who, as VP of Channel, aligns sales, marketing, and product strategies to deliver sustainable growth to channel partners and customers.
Connect on LinkedIn →