FinanceGadget
Guide

"Bank-Level Security" and Other Claims That Mean Nothing

The short answer

Security marketing divides cleanly into claims that can be checked and claims that cannot. “256-bit encryption” cannot be checked and does not distinguish anybody. “SOC 2 Type II, report available under NDA, scope covering the production environment” can be checked, and most companies cannot say it.

The test is simple: could a company with poor security truthfully say this too? If yes, the sentence is decoration.

The phrases that carry no information

“Bank-level security.” The most common and the emptiest. It has no definition, no standard behind it and no auditor. It is also a strange thing to aspire to, since banks are breached regularly and run enormous quantities of legacy infrastructure. The phrase means “we would like you to feel the way you feel about banks”.

“Military-grade encryption.” Almost always means AES-256, which is what your browser is using to load this page and what every competitor uses. It is free, standard, and universal. Advertising it is like advertising that your car has wheels.

“256-bit encryption.” Same. The algorithm strength has not been the weak point in any consumer breach in living memory. Key management, access control and authentication are where things fail, and none of those is described by a number of bits.

“Your data is encrypted in transit and at rest.” Table stakes, offered by every cloud provider by default, frequently enabled without the company doing anything. The meaningful question is who holds the keys — if the provider does, encryption at rest protects against a stolen disk and against very little else.

“We use industry-standard security practices.” Unfalsifiable. There is no industry standard being referenced.

“Regulated by [authority].” True of every licensed firm, and it says nothing about which licence or what it covers. What a payment institution licence actually protects covers why the category is the part that matters.

“We never store your credentials.” Sometimes genuinely important, often technically true in a narrow way. It is meaningful when the app uses OAuth against your bank and therefore never sees a password. It is close to meaningless when the app holds a long-lived token that is functionally equivalent.

“Zero-knowledge.” A precise term in cryptography and a marketing term elsewhere. It is a real claim if the provider can explain what specifically they cannot decrypt and why, and it is undermined entirely if they also offer server-side search, password recovery, or web access to the same data.

The claims that do carry information

A named certification with a stated scope. ISO 27001 and SOC 2 mean something — but only in combination with scope. A certificate covering “the corporate IT environment” and one covering “the production platform processing customer data” are wildly different assurances. Ask for the scope statement, not the badge. For ISO 27001, the Statement of Applicability tells you which controls were excluded and why, and that is the interesting document.

SOC 2 also comes in two types. Type I tests whether controls are designed appropriately at a point in time. Type II tests whether they operated effectively over a period, typically six to twelve months. Type II is substantially harder and is what you want.

A published sub-processor list with change notifications. Naming your vendors is a maintenance burden and a commitment. Companies that do it are running a governance process rather than describing one.

A vulnerability disclosure policy or bug bounty. A published route for researchers to report problems, with a commitment not to pursue them legally, is a strong operational signal. It means the company has decided it would rather hear about problems than not, which is not the default posture.

Specific retention periods. Numbers, in the policy, per data category. Discussed in how to read a privacy policy in fifteen minutes and consistently the most reliable single indicator in any provider document.

A public incident history. Companies that publish post-incident writeups — including ones nobody forced them to disclose — are demonstrating something no certificate can. What a data breach notification actually tells you covers reading them.

Independent penetration testing with a date and a summary. “Annually penetration tested by an accredited third party, most recent test [date], executive summary available on request” is checkable. “Regularly tested” is not.

Five questions that get a real answer

These work in a procurement call, a support ticket, or an email to a vendor. Each is answerable by any competent provider and awkward for one that is bluffing.

  1. What is the scope of your certification, and can I see the scope statement? A company with a genuine certificate has the document to hand.
  2. Where is customer data physically stored and processed, including backups and support access? Backups and support tooling are where residency claims usually break.
  3. Who are your sub-processors, and how are customers notified of changes?
  4. What is your retention period for the specific data I care about, and what happens to it when I close my account?
  5. What was your last security incident and what changed as a result? The answer “none” from a company of any size and age is not a good answer.

The pattern across all five: they ask for specifics that exist as documents inside a functioning security programme, and cannot be improvised.

Why the empty phrases persist

They work. They are cheap, they are legally safe because they are not falsifiable, and they satisfy the large majority of readers who wanted reassurance rather than evidence.

None of this means a company using them is insecure — plenty of good companies have bad marketing copy, and the person writing the landing page is usually not the person running the security programme. The claim is simply not evidence either way, and treating it as evidence is the mistake.

Where the marketing is empty, go and find the checkable things: the register entry, the trust centre, the sub-processor list, the disclosure policy, the retention numbers. They are usually public, they are usually two clicks away, and they are the actual answer. The AI vendor security questionnaire applies the same method to software vendors more generally.