Open Banking and API-based business models have fundamentally changed how financial data is aggregated, processed, and used. The technical possibilities are impressive—but they come with a core responsibility: protecting sensitive financial data. For API-based financial service providers, information security is non-negotiable. It is the foundation on which trust, business relationships, and ultimately the entire business model rest.

At wealthAPI, we process financial data from more than 3,500 banks and brokers every day. As a BaFin-regulated account information service provider, we know: The question is not whether, but how well you implement information security. The ISO 27001 certification was therefore not an end in itself for us, but a deliberate step to harden our technical infrastructure and systematically formalize and continuously evolve our processes—at a level that not only meets, but exceeds, the requirements of our partners and regulators.

This article highlights why ISO 27001 is essential for fintechs, which technical challenges must be overcome on the path to certification, and what others can learn from our journey.

 

 

Why ISO 27001 is more than “just” compliance

For many companies, engaging with ISO 27001 starts as a response to customer requests or regulatory requirements. But that doesn’t go far enough. ISO 27001 is far more than a checkbox on a compliance list. It is a systematic approach to embedding information security holistically into a company’s DNA.

 

The regulatory reality

Let’s start with the hard truth: In the financial industry, there is no room for negotiation when it comes to data security. As a BaFin-regulated account information service provider, we are already subject to strict requirements under PSD2, DORA, ZAG and, in the future, FiDA. But regulatory compliance alone is not enough. Banks, brokers, and institutional partners expect not only that we meet minimum standards, but demonstrable excellence in information security.

ISO 27001 provides exactly that: an internationally recognized standard that shows security is not handled reactively, but proactively, in a structured way, and with continuous improvement. For our partners, the certification is a clear signal: this is a company that takes security seriously—not just on paper, but in every process, every line of code, and every architectural decision.

The technological competitive advantage

What many overlook: ISO 27001 is also a technological catalyst. Implementing an Information Security Management System (ISMS) forces you to critically question and optimize systems, processes, and infrastructure. For us, that led to tangible technical improvements:

• Systematic risk management: Instead of reacting to threats ad hoc, we established a structured process that identifies, assesses, and prioritizes risks.
• Incident response excellence: Our multi-stage incident response plan (P0 to P3) ensures we can respond rapidly and in a coordinated manner in an emergency—from the initial report and escalation through to post-mortem analysis.
• Privacy by design: By classifying our data (Confidential, Restricted, Public) and defining clear handling processes, we built privacy into our systems from the start.

These improvements are not theoretical constructs. They have measurable effects on our incident response times, the quality of our security architecture, and ultimately the trustworthiness of our entire platform.

 

The path to certification: Technical challenges and solutions

The path to ISO 27001 certification is a structured but demanding process. At wealthAPI, we didn’t see it as a necessary evil, but as an opportunity to systematically review and optimize our technical infrastructure. Here are the biggest challenges we faced—and how we solved them.

 

1. Data classification and asset management

In a fast-growing fintech, new systems, databases, and services are added regularly. Keeping an overview of all assets and classifying them consistently is anything but trivial.

Our solution: We implemented a three-tier data classification (Confidential, Restricted, and Public) and defined clear rules for which data belongs in which category.

• Confidential: Username and banking information, transaction data in SEPA format, securities positions, detected contracts (derived PII)
• Restricted: Financial data master (e.g., stock prices, fund profiles), spending categorization (derived, non-PII), internal policies
• Public: Marketing materials, product descriptions, external policies

We implemented this technically via a central asset register in our ISMS, complemented by an external data inventory to map data to IT services. The ISMS uses automated inventorying of cloud resources combined with tagging mechanisms in our cloud infrastructures. Every new system is classified during setup, and data owners are explicitly responsible for their assets.

Learning: Data classification is not a one-off exercise. Alongside ongoing real-time capture, we established an annual review process to ensure classifications remain up to date and new data types (e.g., through FiDA) are correctly categorized.

 

2. Access control and least privilege

In an API-based business model, different teams and services access different data sources and systems. Implementing the “least privilege” principle—each user and system gets only the minimum necessary permissions—requires granular control and continuous monitoring.

Our solution: We implemented a multi-layer access-control strategy based on a formalized Target Operating Model (TOM). The TOM operationalizes the “need-to-know” principle through a strict role model: each role is linked to precise data policies that define what that role may view and edit. When employees change departments or take on new responsibilities, access rights change automatically—there are no historical access rights with us.

Specifically, this means:

• Role-Based Access Control (RBAC): Access is controlled exclusively via predefined roles, not individual user permissions. New employees automatically receive the rights of their role; when roles change, old rights are revoked immediately.
• Multi-factor authentication (MFA): Mandatory for all access to production systems, including VPN, cloud consoles, and admin tools.
• Time-limited access: For highly sensitive operations (e.g., production database access), temporary, audited access is granted with automatic expiry.
• Central authentication: All systems use Google services for centralized authentication, which technically enforces the strict role concept.
• API key management: Secrets and API keys are managed centrally in a secrets management system and are never stored in code or repositories.

Learning: Access control is an ongoing process. Quarterly reviews of all access rights ensure there are no “zombie accounts” and that the least-privilege principle is upheld. Formalizing this through the TOM helped us turn an initially rather implicit “need-to-know” into a measurable, audit-ready system.

 

3. Encryption: at rest and in transit

As an account information service provider, we process extremely sensitive data that must be maximally protected both in transit and at rest.

Our solution: We implemented a comprehensive encryption strategy based on our Cryptography Policy, reinforced by an encapsulated infrastructure architecture:

• Encryption at Rest: All Confidential data is encrypted with AES-256. This applies to databases, backups, and any form of persistent storage. Our backups are additionally protected with data-at-rest encryption. All employees’ laptop drives are protected with full-disk encryption (FDE).
• Encryption in Transit: All data transfers over public networks use TLS 1.2 or higher. Internal communication between microservices also uses encrypted connections.
• Encapsulated Infrastructure: All critical components—especially our databases—run in their own isolated networks and are not reachable from the outside. This network segmentation significantly reduces the attack surface.
• Hosting in Frankfurt: All systems run on Google Cloud in Frankfurt. This not only ensures GDPR compliance, but also gives us access to modern Google security services such as intrusion detection and a web application firewall.
• Separation of Systems: We consistently separate sensitive and less sensitive systems within our infrastructure. This separation allows us to tailor security measures precisely to the required level of protection.
• Key management: Encryption keys are stored in a dedicated Key Management Service (KMS), with automatic rotation and audit logging.

Learning: Encryption is not “set and forget.” The combination of encryption and network segmentation provides defense in depth: even if one component is compromised, other systems remain protected. In addition, we run regular penetration tests to proactively identify vulnerabilities.

 

4. Incident response and business continuity

In an emergency—whether a security incident, a system outage, or a natural disaster—every move has to be spot on. But without clear processes and regular training, chaos is inevitable.

Our solution: We developed a multi-stage incident response plan based on four severity levels.

• P0 (Critical): Actively exploited vulnerabilities, immediate threat to people or systems. Immediate escalation to IT/engineering management.
• P1 (High): Likely threat, not yet actively exploited (e.g., lost laptop without encryption, suspected malware). Ticket creation and management notification.
• P2/P3 (Medium/Low): Suspicious cases or vulnerabilities without immediate risk. Structured investigation via the ticketing system.

Each severity level has defined escalation paths, communication channels, and post-mortem processes. Critical incidents go through a root-cause analysis to identify and remediate systemic weaknesses. In addition, we implemented a Business Continuity & Disaster Recovery Plan to ensure that, in the event of a major outage, we are operational again within defined Recovery Time Objectives (RTOs).

Learning: Theory and practice are two different things. We run quarterly incident response exercises in which we simulate realistic scenarios. These exercises are an indispensable tool for testing our readiness and proactively improving processes—long before a real incident occurs.

 

5. Vendor management and third-party risk

No fintech operates in isolation. We use cloud providers, other multibanking partners, analytics tools, and additional third parties. Each of these partners can represent a potential security risk.

Our solution: We established a structured third-party management process.

• Vendor Assessment: Before onboarding a new service provider, we conduct a security assessment. Vendors that process Confidential or Restricted data must demonstrate that they meet our security standards (e.g., through their own ISO 27001 certification).
• Contractual obligations: Data protection and security requirements are an integral part of all contracts, including audit rights and incident notification obligations.
• Continuous monitoring: Vendor risks are not only assessed at contract signing, but regularly re-evaluated.

Learning: A third-party outage can quickly become your own problem. We learned to identify critical dependencies and, where possible, build redundancies.

 

From certification to lived practice

Achieving ISO 27001 certification is one thing. Living it day to day and continuously improving it is another. We are clear that an Information Security Management System (ISMS) must not be a static rulebook, but a living system that evolves with the company.

Four core beliefs that shape our security culture

Before we talk about specific measures, it’s important to understand the beliefs that guide our approach to information security. These four principles are the foundation of our ISMS:

• Security starts with the organization: Even if a system has an excellent security architecture, it is ineffective if the people interacting with it don’t have the necessary qualifications. Technology alone doesn’t protect. People must understand why security measures exist and how to apply them correctly.
• Organizational security determines IT security: As soon as employees change departments or take on a new role, their access rights must change. With us, there are no historical access rights—only role profiles. This organizational discipline is the prerequisite for technical security measures to be effective.

• Security must follow a design principle: Considering security is critical in service design. That’s because it is extremely difficult to change existing systems retroactively. Security by Design is not a buzzword for us, but lived practice: every new feature and every new service is developed with security in mind from the start.

• People make mistakes—an early warning system helps: People make mistakes. It is therefore necessary to design systems so that errors are detected early and their impact on security is minimized. We rely on layered controls, automated alerts, and a culture where reporting mistakes is not punished, but seen as an opportunity to improve.

 

Culture of information security

The biggest success factor for our ISMS was creating a security culture embraced by all employees. Information security is not solely the responsibility of the CTO or the security team—it is part of everyone’s daily work.

Concrete measures:

• Security awareness training: All employees complete security training during onboarding and then annually, covering everything from phishing detection to secure password practices.
• Clear desk, clear screen policy: Mobile devices auto-lock after 5 minutes; sensitive documents must not be left unattended on desks.
• Code of Conduct: Our Code of Conduct defines clear expectations for all employees’ behavior (online and offline) and creates a work environment where security and respect go hand in hand.
• Peer reviews for all code changes: No code reaches production without being reviewed by at least one other developer. These peer reviews are a core element of our quality assurance and prevent individual misconduct.
• Systematic use of AI in quality control: all code changes are checked by AI for consistency and vulnerabilities
• Test-driven development: We rely on test-driven development to ensure high quality even in a dynamic environment. Automated tests ensure that security requirements are continuously met.

Continuous improvement

ISO 27001 explicitly requires a continuous improvement process (PDCA cycle: Plan-Do-Check-Act). At wealthAPI, we have internalized this approach:

• Quarterly risk reviews: Management regularly reviews the risk landscape and adapts measures to new threats.
• Annual policy reviews: All policies and processes are reviewed at least once a year for relevance and effectiveness.
• Lessons learned from incidents: Every security incident, no matter how small, is documented and analyzed. The insights flow directly into process and technology improvements.
• Close collaboration with partners: We actively coach our customers and partners to ensure minimum security standards. Security doesn’t end at our system boundary—it extends across the entire ecosystem.

 

FiDA, Open Wealth, and the future of information security

With the upcoming Financial Data Access Regulation (FiDA), the next major wave of regulatory change is on the horizon. FiDA will further tighten and expand requirements for financial data aggregation and protection. For wealthAPI, this is not a threat, but an opportunity.

FiDA readiness through ISO 27001

Our ISO 27001 certification is a key building block for being “FiDA-ready.” The processes established through the ISMS—from data classification and encryption to vendor management—already cover many of the expected FiDA requirements.

Specifically, this means:

• Extended data types: FiDA will go beyond pure PSD2 payment account data and also include securities, crypto, insurance, and more. Our flexible data classification is already prepared for this diversity.
• Granular consent management: ISO 27001 forces us to document precisely who accesses which data and when. This granularity is essential for FiDA-compliant consent management systems.
• Incident reporting: The incident response processes established through ISO 27001 enable us to detect, report, and remediate security incidents quickly—a core FiDA requirement.

Open Wealth as a technological promise

At wealthAPI, we don’t see “Open Wealth” as just a marketing term, but as a technological promise: we bring a wide range of financial data together in one virtual place and make it usable for our partners—securely, efficiently, and compliantly.

ISO 27001 is the foundation of this promise. Without a robust information security architecture, Open Wealth would remain an idea without a solid base. With ISO 27001, we have the infrastructure, processes, and culture to deliver on this promise every day.

 

Conclusion: Information security as an enabler for growth

For API-based financial service providers like wealthAPI, ISO 27001 is not an option—it’s a necessity. The certification signals not only regulatory compliance, but also technological maturity, operational excellence, and a company culture that takes security seriously.

The path to certification was challenging, but it made us stronger as an organization. We optimized processes, hardened systems, and established a security culture that positions us extremely well for the future of Open Banking—FiDA, Open Wealth, and beyond.

At wealthAPI, we are proud of our certification—not because it was the goal, but because it is the starting point for a continuous journey toward even higher security and quality standards.

 

Practical recommendations for other fintechs

To wrap up, I’d like to share a few practical recommendations from our certification journey—learnings that can make the path easier for other fintechs:

• Start early
  Don’t wait until a partner or regulator demands ISO 27001. The earlier you start building an ISMS, the more naturally it integrates into your company culture. Retrofitting it later is significantly more time-consuming and expensive.

• See it as an investment, not a cost driver
  Yes, ISO 27001 certification takes time and money. But it pays off many times over: faster partner onboarding, higher system stability, improved incident response capabilities. At wealthAPI, the investment paid for itself in less than a year.

• Bring everyone on board
  Information security is not an IT task. Involve all departments from the start—from Sales and Legal to Customer Success. An ISMS only works if everyone lives it.

• Automate where possible
  Many aspects of an ISMS can be automated: access reviews, vulnerability scans, backup verification, compliance checks. Choose an ISMS that takes most of this work off your hands—even if the license may be a bit more expensive.