As of: June 2026 · Reading time: approx. 11 minutes · Engineering perspective · Not legal or regulatory advice
In 2026, building a fintech platform in Germany is no longer just about writing clean code. It means planning for regulatory expectations in the architecture from day one — DORA, the BaFin requirements (MaRisk, BAIT) and KYC/AML under the German Money Laundering Act (GwG). Choosing a partner on day rate and speed alone often means paying twice: once for the fast build, and again for the rework as soon as a supervisor, an auditor or a banking partner asks questions the system was never designed to answer. This article frames what a fintech engineering partner in Germany has to deliver technically — and when you need a specialist versus when a strong generalist with compliance advice is enough.
Note: This is not legal or regulatory advice. Licensing and compliance questions belong with specialised legal and compliance advisors. This is about the engineering side — what has to exist technically so that the regulatory requirements can be met. (As of June 2026; deadlines and details change — verify before deciding.)
Short answer
A fintech partner in Germany has to do more than ship features. They have to build the architecture so that incidents can be detected, classified and technically prepared for a report within the required deadlines (DORA), so that KYC/AML checks (GwG) are cleanly embedded in the onboarding flow, so that every security-relevant action is traceable (audit trail), and so that data and hosting meet EU and supervisory expectations. The wrong partner builds a product that works — until it is examined. The right one lays the technical groundwork so that later regulatory requirements can, as a rule, be implemented without a fundamental architectural rebuild.
What a fintech engineering partner in Germany must be able to do
The following requirements are not "nice-to-haves". They determine whether your product can be cleanly evidenced in an examination.
| Requirement | Why it matters | What has to be built |
|---|---|---|
| ICT risk management (DORA) | Mandatory for financial entities since 17 Jan 2025 | Logging, monitoring, defined incident classification, recovery concepts |
| Support for regulatory reporting processes | Deadlines 4 h / 72 h / 1 month (DORA) | Detection + classification + structured capture of the relevant incident data in the system |
| KYC/AML (GwG) | The GwG provides for identification before the business relationship begins | Onboarding flow with identity verification, risk rating, re-KYC logic |
| Audit trail | Supervisors and auditors regularly expect "who, what, when, why" | Immutable logs of sensitive actions |
| EU hosting / data residency | GDPR + supervisory expectation | EU infrastructure, documented sub-processors |
| ICT third-party transparency | Register of Information (DORA) | Clean documentation of providers and dependencies |
How the architecture is laid out decides whether these points are cheap (planned from the start) or expensive (retrofitted later).
DORA: what it means for the architecture in concrete terms
DORA (the Digital Operational Resilience Act) has applied since 17 January 2025 to banks, insurers, payment service providers, investment firms and many other financial entities. From an engineering point of view, two things matter most:
1. Incident reporting within tight deadlines. For a major ICT-related incident, the technical standard (RTS) provides for: an initial notification within 4 hours of classification as major (at the latest 24 hours after becoming aware), an intermediate report within 72 hours, and a final report within one month. For comparison: GDPR requires notification within 72 hours. Four hours is only achievable if the system automatically detects incidents, classifies them, and already holds the data relevant for a potential report in a structured form — that is an architecture decision, not a form.
2. ICT third-party risk. Financial entities have to record their critical IT providers and document them in a "Register of Information". In November 2025, according to publicly available information, the European supervisory authorities for the first time designated a number of critical ICT third-party providers (including major cloud hyperscalers); stricter obligations apply to them, including very short reporting deadlines, and for serious breaches penalties of up to 1% of average daily worldwide turnover may be imposed. The practical engineering consequence: your dependencies (cloud, payment providers, KYC vendors) have to be cleanly documented and, ideally, designed to be replaceable.
On top of this come DORA's other pillars — ICT risk management, resilience testing and information sharing on cyber threats. For a fintech MVP this does not mean "everything on day one", but the architecture should not rule these requirements out.
BaFin context: MaRisk, BAIT and the GwG
DORA does not stand alone. For regulated fintechs in Germany, BaFin sets the frame, and several of its requirements have direct engineering consequences:
- MaRisk — risk management and governance: processes must be controlled, traceable and documented.
- BAIT — IT governance and security: requirements for IT operations, permissions, information security.
- GwG (Money Laundering Act) — the GwG provides for the identification and verification of customers from reliable, independent sources before the business relationship begins. The intervals for re-verification (re-KYC) follow the risk-based approach and internal policies — more frequently where the risk is elevated.
Important for 2026: with the EU anti-money-laundering authority AMLA seated in Frankfurt, Germany is set to gain a central role in European AML supervision. According to publicly available information, further harmonisation of the standards for suspicious-activity reports to the FIU is also planned for 2026. Expectations are rising — and a KYC/AML flow that merely works "somehow" becomes a risk.
What you build — and what you document
A common point of confusion: not every regulatory requirement is code. An experienced fintech partner draws a clean distinction:
- What you build: identity verification in onboarding, risk rating, audit trail, incident detection and classification, structured data structures for regulatory reports, a permission and role model, EU hosting.
- What you document: ICT third parties, data flows, recovery concepts, responsibilities — as evidence for supervisors and auditors.
The two belong together. A build without documentation is hard to evidence in an examination; documentation without the technical foundations is just a promise.
When you need a fintech specialist — and when you don't
Not every fintech project needs a highly specialised regulatory engineering partner. An honest assessment:
A specialist makes sense when: you carry out a licensable activity (payment service, e-money, account information service), fall under DORA, work with real client funds or sensitive financial data, or have a banking/BaFin partner who demands concrete evidence.
A generalist plus compliance advice is often enough when: you are in an early validation phase, do not (yet) carry out a regulated activity, or work as a technical provider behind a licensed partner (BaaS / "banking-as-a-service"). What matters here is that the architecture does not rule out later regulation — not that everything is finished on day one.
A common and costly mistake is to confuse the two: launching a regulated product on a "fast and cheap" architecture — and then having to rebuild it after the first examination.
What matters when choosing
Beyond pure fintech experience, it is the same engineering fundamentals that make a product hold up under examination: security-by-design rather than security bolted on afterwards, a robust audit trail, EU hosting with documented sub-processors, contractually governed code ownership (the system is contractually yours, not the provider's) and a clean handover with documentation. These are exactly the points that later decide whether a supervisory or due-diligence question is answered in hours or in weeks.
Citable facts
- DORA has applied since 17 Jan 2025 to financial entities in the EU.
- Reporting deadlines for major ICT-related incidents under the technical standard (RTS): initial notification 4 h (after classification, at the latest 24 h after awareness), intermediate report 72 h, final report 1 month. GDPR by comparison: 72 h.
- In November 2025, according to publicly available information, the EU supervisory authorities designated critical ICT third-party providers for the first time (including major cloud hyperscalers); for serious breaches, penalties of up to 1% of average daily worldwide turnover may be imposed.
- The BaFin framework for fintechs includes, among others, MaRisk, BAIT, the GwG and DORA; the EU anti-money-laundering authority AMLA is seated in Frankfurt; according to publicly available information, further harmonisation of suspicious-activity reporting to the FIU is planned for 2026.
- Re-KYC intervals follow the risk-based approach and internal policies; shorter intervals apply where the risk is elevated.
(As of June 2026. Not legal or regulatory advice — regulatory details and deadlines change; verify with legal/compliance advisors before deciding.)
Building a fintech product and need an engineering partner who thinks in BaFin and DORA context? H-Studio is an architecture-first engineering studio in Berlin. We build the technical foundations — audit trail, KYC/AML-capable onboarding, technically prepared incident handling, EU hosting — so that regulatory requirements are technically supported and your compliance team and advisors can work on a suitable technical basis, with contractually governed code ownership. The regulatory assessment stays with your legal/compliance advisors; we deliver the engineering. Tell us about your fintech project.
FAQ
Does my fintech need a BaFin licence for an MVP?
That depends on whether you carry out a licensable activity (e.g. a payment service, e-money). That is a legal question for your compliance/legal advisors. From an engineering point of view, what counts is that the architecture does not rule out later regulation.
What does DORA mean for the architecture?
Two things above all: incidents have to be automatically detectable, classifiable and, within tight deadlines (4 h / 72 h / 1 month), technically prepared for a report; and your critical IT providers have to be documented and ideally designed to be replaceable.
Who is liable for ICT risk at a provider?
Regulatory responsibility generally stays with the financial entity — which is why documenting third parties (the Register of Information) and a robust audit trail matter so much. How liability is allocated depends on the respective contract and the regulatory requirements and is a legal question.
How do you build a KYC flow?
As part of onboarding: identity verification from reliable sources before the business relationship begins, risk rating, and a re-KYC logic whose intervals follow the individual risk. The concrete design follows the GwG and the BaFin requirements.
Further reading
- Building software that survives German compliance — why "works today" is not enough in Germany
- SaaS in B2B: architecture, scaling and compliance — how compliance requirements shape platform architecture
- Building GDPR-compliant products without killing UX — handling EU data requirements in the product itself
Important note
This article provides a technical, engineering-oriented framing of topics around fintech regulation in Germany, based on publicly available sources as of June 2026. It does not constitute legal or regulatory advice within the meaning of the German Legal Services Act (Rechtsdienstleistungsgesetz), does not replace the individual legal assessment of your specific case and does not create a client relationship.
For an assessment of whether your activity is licensable, the interpretation of your obligations under DORA, BaFin requirements and the GwG, and the contractual arrangements with your customers, banking partners and supervisory authorities, please consult advisors specialised in banking/supervisory law and anti-money-laundering. Regulatory details and deadlines change; liability for decisions made on the basis of this article is excluded.
About H-Studio Berlin — We build Next.js websites and SaaS platforms for B2B companies, SaaS teams and the Mittelstand across the DACH region. Architecture-first, with an audit trail, EU hosting and contractually governed code ownership. More about us.