Fintech and Insurtech in EU Regulatory Terms – A Practical Reality Check

By Mikołaj Otmianowski, co-developer RED INTO GREEN

The terms fintech and insurtech are widely used in the technology and financial services industries, yet they have no legal meaning in regulatory frameworks. This misunderstanding leads many technology firms to underestimate their regulatory exposure - an error that is becoming increasingly costly in the era of DORA and NIS2.

Regulation does not recognise “fintech” or “insurtech” as categories. Instead, it distinguishes between financial institutions, ICT service providers, and entities classified as essential or important under cybersecurity law. What matters is not the label a company uses, but its legal status and the nature and criticality of the services it provides. The same product can therefore fall under very different regulatory regimes depending on who provides it and how it is used.

Role and criticality determine regulatory scope

A payments platform may be a licensed financial institution directly subject to DORA, an unlicensed ICT service provider indirectly subject to DORA through its clients, or a non-regulated application if it is fully interchangeable. The determining factors are whether the firm holds a financial licence and whether its ICT services are critical to a client’s operations.

The same logic applies to insurtechs. An insurance undertaking authorised under Solvency II, an insurance intermediary, and a provider of a customer-facing portal each fall under different legal regimes. Under NIS2, applicability is driven by infrastructural character, scale, and systemic importance.

A common misconception: DORA applies only to banks and insurers

Many firms assume that DORA is relevant only to regulated financial institutions. This is a serious cognitive error. Providers of critical ICT services - such as core banking systems, cloud infrastructure, or processing platforms - are within the scope of DORA as ICT service providers. Their obligations arise indirectly, through the contractual requirements imposed by regulated clients.

Large technology firms may eventually be designated as Critical ICT Third-Party Providers (CTTPs), which would place them under direct EU-level supervision. However, such designation requires a formal decision by a European supervisory authority; it is not automatic. Until then, these firms remain indirectly subject to DORA.

To understand their exposure, firms should ask three basic questions:

• Are we a financial institution?

• Do we provide ICT services to financial entities?

• Would a failure of our services halt a client’s operations?

Only a negative answer to all three places a firm clearly outside DORA’s perimeter.

The “small and non-infrastructural” trap

Smaller SaaS providers often assume that limited scale shields them from regulation. While a genuinely interchangeable application with no operational impact on clients may fall outside NIS2 and DORA, this assessment is frequently overly optimistic.

If a service - such as a credit risk engine, AML system, or core banking integration - is treated by a financial client as critical, then that provider becomes part of the client’s regulatory risk profile. The financial institution must manage and document that risk and impose contractual obligations under Article 30 of DORA. Size and industry classification codes are irrelevant if the service is.

The practical rule is simple but uncomfortable: if a service is “non-substitutable like infrastructure,” it is likely within scope; if it is “substitutable like an application,” it generally is not. The assessment must be evidence-based.

From implementation to enforcement

The relatively lenient implementation phase of recent years is ending. With DORA, NIS2, the AI Act, GDPR, and the CRA, regulatory requirements are expanding rapidly. Periods of adaptation are being replaced by active enforcement, inspections, and audits.

Regulators will no longer accept compliance “in progress.” They will require current, auditable evidence of risk management and governance. Outsourcing does not transfer responsibility: regulated entities must conduct and continuously update their own risk assessments.

Consequences of regulatory ignorance

Failing to understand one’s regulatory status creates both regulatory and commercial risks.

Commercial consequences are often even more damaging. Responsibility for security incidents remains with the regulated institution, which means financial clients will rigorously vet their ICT providers. A supplier unable to demonstrate compliance becomes a liability and may be excluded from tenders or terminated.

Cybersecurity and regulatory compliance are therefore no longer just costs. They are becoming competitive advantages, formal selection criteria, valuation factors in M&A, and key elements of trust and reputation.

Final message

Calling yourself a fintech or insurtech does not determine your regulatory obligations. Your actual role in the financial ecosystem does.

Firms that fail to recognise this reality risk penalties, lost clients, and reputational damage. Those that understand and address their true regulatory exposure position themselves to survive - and compete in an increasingly regulated digital financial sector.