[edited to deal with formatting] Genuinely looking for clarification - what does "untestable claim" means to you in this context? If it means that you persona

[edited to deal with formatting] Genuinely looking for clarification - what does "untestable claim" means to you in this context? If it means that you personally can't test it, then yes, it is an "untestable claim" and you are right, the whole thing is effectively a magic black box. If it means that some other party/authority can't test it, then no, it is the opposite - a "testable claim" - to use the nomenclature put forward. As a counterpoint to illustrate this, others who can, and do, test include: 1) internally (within the bank itself) + risk management: they define acceptable level of risk for login architecture & management + enterprise security: they define standards for login architecture among other things based on risk standards + infosec - they enforce ent. security standards + finance/analytics: test stuff like "what did we/our customers lose to this type of fraud before/after we implemented this black magic box" + internal auditors (IT): assess and report on compliance 2) externally (outside the bank) + external auditors (who believe it or not, actually test this stuff) + regulators (who can mandate security levels in some jurisdictions - esp true outside the US) + pen-testers: banks hire them to ensure that the security posture works In large bank environments, developers cant simply put out a username/password login architecture and expect to see it deployed to production. There are a ton of other groups defining what they MUST do. The degree of functional separation in (large) banks is astounding - but it mostly works - because everyone has to toe to requirements defined by other functional groups. I would argue that another CS-related analogy to this is machine learning. Everyone says they do "ML", most people don't understand it, some do understand it and a few understand it deeply; from an execution perspective, most are doing it ML badly, some doing it OK but there are a few are doing it really well because they understand it really well. As with ML, for the case of user access management, the fact that *most" are doing it badly does not negate its (very real potential) value if done right.