Banks invest billions in their IT security. Firewalls are hardened, systems segmented, access controlled. And yet, damages from cybercrime continue to rise. In Germany, most recently to €289 billion per year according to Bitkom.

The reason is structural: attacks are increasingly targeting not individual institutions, but the connections between them. APIs, third-party providers, integrated services—precisely where data flows and responsibility is shared. The attack on the crypto exchange Bybit in early 2025 demonstrated this exemplarily. Not the platform itself was compromised, but the user interface of a connected service provider. A single weak link was enough to cause damage of approximately $1.5 billion.

The new reality: attacks target connections, not systems

How deep this vulnerability runs is shown by a second incident that only became known at the end of March 2026: attackers compromised the maintainer account of the npm package axios, one of the most popular HTTP libraries in the JavaScript world with over 100 million weekly downloads. Through manipulated versions, they injected a backdoor that affects Windows, macOS, and Linux alike. The entry point was not a technical exploit, but social engineering against a single person: the email address associated with the maintainer account was secretly changed to an attacker-controlled account. Google Threat Intelligence attributes the attack to the North Korean group UNC1069. The case shows: even those who perfectly secure their own infrastructure import potential vulnerabilities with every open-source package from sources over which they have no direct control. The attack surface no longer ends with one’s own code, but extends deep into build pipelines and dependency trees.

For API-based financial infrastructures, this is a systemic risk. Security can no longer be thought of in isolation. It is a property of the entire ecosystem. In networked financial systems, it emerges—or fails—at the interfaces. This is precisely where wealthAPI comes in. As a BaFin-regulated account information service, we aggregate and process financial data from thousands of banks and brokers daily. For us, security is not a downstream process and not a single feature. It is an architectural decision. And one deliberately made where we must relinquish control: at the interfaces to third parties.

This article shows how we translate this perspective into concrete systems, processes, and standards—from ISO 27001 certification to managing third-party risks in an increasingly networked financial world.

Why traditional security approaches are no longer sufficient

New quality of attacks

Attacks have changed qualitatively: AI-powered phishing is personalized and barely detectable, state-sponsored groups operate at enterprise level, and ransomware is evolving from loud attacks to silent data theft. The goal is no longer the disruption of systems, but the undetected compromise of data flows.

Open Banking expands the attack surface

What particularly affects us as an industry: API-based business models and Open Banking integrations significantly expand the attack surface. Fintechs today have a broader and more fragmented data base than many traditional banks—and at the same time often less mature security structures. This leads to a structural imbalance: maximum data availability with simultaneously increased attack surface.

Vincent Haupert, PhD in computer science, former hacker, and founder of Yaxi, who became known ten years ago for uncovering vulnerabilities at N26, recently put it succinctly in the FinanceFWD Podcast : many fintechs have hardly learned anything in terms of security. Limited budgets and other priorities stand in the way. This gap is not an operational problem, but a structural one. And it cannot be closed through individual measures, but only through architecture.

Regulatory pressure as a catalyst

Regulators have also responded. Since January 2025, the Digital Operational Resilience Act ( DORA) has been in effect, making BaFin the central reporting hub for ICT incidents across the entire financial sector. In addition to banks and payment service providers, insurers and securities firms must now also report ICT incidents.

Furthermore, the ECB and BaFin have announced targeted reviews and threat-led penetration tests for 2026. Weaknesses in IT governance or third-party risk management are considered serious compliance violations. And with the upcoming Financial Data Access ( FiDA) regulation, requirements for the protection of financial data will be further tightened and extended to new data types.

Our foundation: security from day one

When I first wrote extensively about cybersecurity at wealthAPI in April 2024, I formulated ISO 27001 certification as a concrete goal. Today, nearly two years later, we have achieved this goal. The journey there has elevated our entire security architecture to a new level.

But the fundamental principles that have guided us since our founding have remained the same. Security at wealthAPI was never a retrospective add-on, but part of our DNA from the beginning. ISO 27001 certification was neither an end in itself nor a pure compliance project. Rather, it was a means to systematize and harden our architecture.

What security means in practice

1. Quality as the first line of defense

Many security problems arise from internal vulnerabilities in code. To combine the highest code quality with agile release cycles, we have relied on test-driven development (TDD) from the start. The application is fully and automatically tested with every single change, no matter how small. In addition, mandatory peer reviews following the four-eyes principle apply to all code changes. No code reaches the production environment without at least one other developer having reviewed it. Additionally, we use AI-powered analysis to detect patterns, anomalies, and potential vulnerabilities in complex code dependencies early on. These systems extend traditional static analysis but do not replace human review.

2. Infrastructure: standardization instead of custom builds

We deliberately chose standardized, hardened cloud infrastructure in Google Cloud Frankfurt instead of operating our own systems. Not because custom solutions are inherently insecure, but because standardized platforms are continuously hardened at a level that is hardly economically achievable internally.

Within Google Cloud, we use an encapsulated infrastructure: all components run in their own Virtual Private Network (VPC) and are not visible from the outside. Our backups are encrypted with data-at-rest encryption, particularly sensitive data such as login credentials are separately encrypted again within this overall encryption. Furthermore, we consistently separate sensitive and less sensitive systems.

This network segmentation provides defense-in-depth: even if one component is compromised, other systems remain protected.

3. Data classification: knowing what you protect

In a rapidly growing fintech, new systems, databases, and services are regularly added. Maintaining an overview of all assets and classifying them consistently is not trivial. We work with a three-tier data classification:

• Confidential includes usernames and banking information, transaction data in SEPA format, securities positions, and identified contracts.
• Restricted includes the financial data master such as stock prices and fund profiles, spending categorizations, and internal policies.
• Public refers to marketing materials, product descriptions, and external policies.

What matters less is the categorization itself than its consistent implementation: every system is automatically captured, classified, and assigned to a clear data owner. Data classification is not a one-time process, but a continuous alignment with reality—especially when new data types are added through the upcoming FiDA regulation.

4. Access: consistent least-privilege principle

In an API-based business model, access control is a central risk factor. We have implemented a multi-layered access control strategy based on a formalized Target Operating Model (TOM). The TOM operationalizes the need-to-know principle through a strict role model: Role-Based Access Control (RBAC) instead of individual user permissions, Multi-Factor Authentication (MFA) for all production systems, time-limited and audited access for highly sensitive operations, and centralized API key management through a dedicated secrets management system, in which secrets and API keys are never stored in code or repositories.

Access rights are always tied to current roles. When employees change departments, rights change automatically. Historically grown permissions do not exist. Quarterly reviews additionally ensure that no “zombie accounts” remain. The formalization through the TOM has helped us turn an initially rather implicit need-to-know into a measurable, auditable system.

5. Incident response: responsiveness instead of illusion of security

Complete security does not exist. What matters is how quickly and systematically incidents are responded to. Our Incident Response Plan is based on four severity levels:

• P0 (Critical) includes actively exploited vulnerabilities with immediate escalation.
• P1 (High) designates probable threats, such as a lost laptop without encryption or malware suspicion.
• P2 and P3 (Medium/Low) cover suspected cases that are systematically investigated through our ticket system.

Each level has defined escalation paths, communication channels, and post-mortem processes. However, the focus is not on preventing every incident, but on the ability to quickly limit impact and systematically learn from it. Quarterly incident response exercises under realistic conditions are not a formal process, but a central component of our security strategy.

6. Third-party risks as a systemic issue

The greatest vulnerability in networked systems often lies outside one’s own organization. The Bybit case has shown the entire industry how quickly a compromised service provider becomes one’s own problem.

We have therefore established a structured third-party management process: before integrating a new service provider, we conduct a security assessment. Providers that process Confidential or Restricted data must demonstrate that they meet our security standards—ideally through their own ISO 27001 certification. Data protection and security requirements are an integral part of all contracts, including audit rights and incident notification obligations. Vendor risks are not only assessed at contract conclusion, but regularly re-evaluated.

The central insight: security does not end at one’s own system boundary. In networked systems, the greatest risk often lies precisely where control is relinquished: with third-party providers, interfaces, and dependencies.

Security culture: the decisive factor

Technology alone is not enough. The greatest success factor for our Information Security Management System (ISMS) was creating a security culture that is supported by all employees. Four principles shape our approach:

1. Security begins in the organization. Even the best security architecture is ineffective if those who interact with it do not have the necessary qualifications. All employees undergo security awareness training during onboarding and then annually—from phishing detection to secure password practices. Our clear-desk/clear-screen policy ensures that mobile devices are automatically locked after five minutes. A binding code of conduct defines clear expectations for the online and offline behavior of all employees.
2. Organization determines security. We have no historical access rights, only current role profiles. This organizational discipline is a prerequisite for technical security measures to be effective at all. Quarterly access reviews are an indispensable tool against creeping rights expansion.
3. Security by design. Consideration of the security aspect is of crucial importance in service design—from the very first line of code. Every new feature, every new service at wealthAPI is developed with security in focus from the start. This applies to architecture as well as to the data model and API interfaces.
4. Early detection instead of perfection. People make mistakes. Systems are therefore designed to make errors visible early and limit their impact. We rely on multi-layered controls, automated alerts, and a culture in which reporting errors is seen as an opportunity for improvement. This is complemented by systematic AI use in code review, which acts as an additional safety net.

These principles are formalized within our ISMS, but above all anchored in daily operations. Technical measures create security, organizational discipline maintains it.

Outlook: regulation as minimum standard, not as goal

With the upcoming FiDA regulation, the next major wave of regulatory changes is imminent. FiDA will further tighten requirements for financial data aggregation and protection and go far beyond pure PSD2 payment account data: securities, cryptocurrencies, insurance, and other financial products will be covered.

Our ISO 27001 certification is a crucial building block for being “FiDA-ready.” The processes established through the ISMS already cover many of the expected FiDA requirements. Our flexible data classification is prepared for the diversity of extended data types. The granular documentation of who accesses which data when forms the foundation for FiDA-compliant consent management systems. And our established incident response processes enable us to quickly detect, report, and remediate security incidents.

DORA also sets the framework as a new standard. BaFin as a reporting hub for ICT incidents increases transparency requirements for the entire financial sector. Threat-led penetration tests become mandatory. Through our quarterly simulation exercises and existing incident response processes, we are well prepared here.

At the same time, we do not understand regulation as a target state, but as a framework. The PDCA cycle (Plan, Do, Check, Act) is not an ISO platitude for us, but lived practice. Quarterly risk reviews, annual policy reviews, lessons learned from every security incident—no matter how small. And one aspect that is particularly important to me: security does not end at our system boundary. We actively coach our customers and partners to ensure minimum security standards. In a networked data economy, where a compromised third-party provider can become one’s own vulnerability, security is a collective responsibility.

Conclusion: security emerges in the system

For API-based financial service providers like wealthAPI, information security is not an isolated discipline. It is a systemic property that results from architecture, processes, and dealings with partners.

Our partners entrust us with their financial data because we offer demonstrable security: through BaFin regulation, through ISO 27001 certification, and through a security culture that is visible in daily actions. In a world where 64% of top managers in the financial sector see cyberattacks as the greatest challenge until 2030, this demonstrable security is both a competitive advantage and a matter of trust.

ISO 27001 certification was not the goal. It was the starting point. What matters is the ability to continuously develop security and respond to new threats. In a networked financial world, the following applies: the security of a system is not measured by its strongest point, but by its weakest connection.

And it is precisely these connections that determine stability or risk in modern financial architectures.

Anyone dealing with securing complex data flows in the context of DORA, FiDA, and API-based business models should not view security in isolation—but as a property of the entire system.