The same neobank that just received its full banking license in Colombia confirmed, three days earlier, a data breach that didn’t involve a single hacked server.
The institution that takes this scenario seriously and builds the discipline of measurement, governance, and continuous testing necessary to respond to it with evidence will not only avoid the error that science has already documented.

On September 12, a British neobank with over 80 million global customers confirmed that sensitive data from 680 accounts—passports, verification selfies, transaction histories—had reached unauthorized third parties. Just three days later, on September 15, the Financial Superintendency of Colombia granted that same entity its full banking license to operate as a regulated bank in the country, marking its sixth global banking jurisdiction.
That contrast, unfolding within a seventy-two-hour window, is far more than an uncomfortable anecdote for a single company. It serves as a perfect snapshot of the exact scenario every digital bank entering Colombia, Mexico, Ecuador, and Panama must confront: what actually protects a financial institution when its core technology already meets every international standard?
What makes this case critical is not its size—680 accounts is a tiny fraction of any major digital bank's customer base. It is the mechanism. There was no system intrusion, no software vulnerability exploited, and no passwords stolen. An unauthorized party used a legitimate government email domain—presumably compromised in another country—to request data on specific customers, claiming it was required for an active police investigation. The financial institution answered that request just as it would for any legitimate official order, because on the surface, it was.
That is precisely the blind spot no cybersecurity architecture, no matter how robust, can close on its own. A genuine government email domain triggers no firewall alerts. Intrusion detection systems miss it entirely. End-to-end encryption cannot block it. The vulnerability was not in the code. It was in the process that decides, on the other side of the screen, whether a request that looks legitimate should be treated as legitimate without secondary verification.
Over the past decade, the security conversation in digital banking focused almost entirely on infrastructure: encryption, multi-factor authentication, zero-trust architectures, and cybersecurity budgets as a percentage of overall IT spend. All of that investment is necessary, and no serious financial institution should scale it back. However, recent events demonstrate something the industry consistently underestimates: technology can be flawless, yet the institution remains vulnerable if the process governing who gets access to data isn't designed with the same rigor as the system storing it.
That distinction—robust technology versus robust processes—is not an academic nuance. It is the boundary between building a system that survives a technical attack and building an institution that survives a breach of trust. A bank can pass any penetration audit with top marks while remaining completely vulnerable to a spoofed official request processed by an untrained staff member. The two layers are not interchangeable, and neither can replace the other: an organization must lock down its code with the exact same discipline it applies to the human decisions authorizing every exception.
Colombia, Mexico, Ecuador, and Panama are each experiencing, at their own pace, the exact same wave: international neobanks entering with new licenses, fresh capital, and modern tech stacks. That momentum brings genuine innovation and competitive pressure that ultimately benefits the end user. However, it also introduces a operational responsibility that is rarely discussed with the same enthusiasm as a commercial launch: every financial institution setting up operations under a new regulatory regime needs its identity verification processes, external request validation protocols, and escalation paths for ambiguous cases to be just as battle-tested as its core platform.
This is neither a call to mistrust digital banking nor a critique aimed at any single player. It is a reminder that while regulatory authorities evaluate capital reserves, corporate governance, and regulatory compliance before granting a license, operational resilience against sophisticated deception is rarely certified with the same rigor applied to a balance sheet. Closing the gap between what gets audited and what actually exposes an institution to real-world risk is currently one of the single biggest operational priorities for expanding digital banks.
At Q-Vision, we have spent over two decades supporting quality assurance, data governance, and technology modernization across financial institutions in Colombia, Mexico, Panama, and Ecuador. The pattern behind these incidents recurs with a consistency that should alarm any risk committee: testing discipline is applied almost universally to software, yet rarely to the human processes that take over when software lacks an automated response.
An institutional identity verification workflow can—and must—be tested with the exact same rigor as a software module: leveraging test cases that simulate sophisticated fraudulent requests, establishing out-of-band verification protocols that look beyond seemingly legitimate email domains, and running audits that evaluate whether the entire organization, including its staff, can withstand well-crafted deception. That is the standard of quality assurance we consider essential for digital banking expanding across the region: an approach that never separates technology from process—because to an attacker, that distinction simply does not exist.
No financial institution will ever achieve absolute immunity against a well-executed social engineering attack—not the largest, not the best-capitalized, nor the one with the world's most advanced technology. That is not an avoidable failure; it is a reality the entire industry must live with. What is avoidable, however, is an institution discovering—only after an incident occurs—that its operational verification workflows were never tested with the same rigor applied to its underlying tech stack.
Digital banks expanding across Colombia, Mexico, Ecuador, and Panama have a clear opportunity to address these operational blind spots before a breach forces their hand. Beyond avoiding an embarrassing headline, prioritizing process-level quality assurance builds the only form of institutional trust that no regulatory license can grant on its own.
Puedes configurar tu navegador para aceptar o rechazar cookies en cualquier momento. Si decides bloquear las cookies de Google Analytics, la recopilación de datos de navegación se verá limitada. Más información.