News

12.08.26

Open insurance explained: a guide for Central-European P&C insurers

Hands connecting Ethernet cable in server rack

Open insurance is the API- and data-sharing model that lets insurers, intermediaries and authorised third parties access and exchange insurance-related personal and non-personal data to build new products, distribution channels and services. EIOPA confirms there is no single uniform definition, but the working concept is consistent: structured, consent-governed data flows between parties, usually via APIs. For P&C product and IT teams, the immediate implication is clear: treat standardisation, consent architecture and supervised authorisation as programme-level dependencies from day one, not afterthoughts.

Three things to keep in mind before you read further:

  • EIOPA has published position papers (2021 and 2022) framing the regulatory direction, though no binding EU insurance-specific data-sharing rule exists yet.
  • FIDA (the proposed EU Financial Data Access regulation) will bring non-life insurance into a regulated data-access regime, with authorised data users called FISPs subject to DORA-level cyber resilience requirements.
  • IBSuite, IBA’s cloud-native, API-first core platform, is designed to support exactly this kind of open, interoperable architecture.

Key takeaways

Open insurance is an API- and data-sharing model governed by consent and emerging EU standards, and Central-European P&C insurers that build the plumbing now will comply with FIDA faster and at lower cost than those who wait.

Point Details
No uniform definition yet EIOPA describes open insurance broadly; FIDA will create the first binding EU regime for non-life insurance data sharing.
Standardisation is a programme dependency Bilateral agreements are the norm today; CEN TC445 and FIDA will set the standard schemas insurers must align to.
Consent architecture is non-negotiable Every personal-data API flow needs auditable, purpose-limited consent records to satisfy GDPR and future FIDA requirements.
Start with a bounded pilot A single use case (policy dashboard, telematics feed) surfaces governance gaps before they become costly at scale.
Ibapplications IBSuite IBSuite’s API-first, cloud-native architecture provides the versioned APIs, data models and integration layer open insurance programmes require.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Table of Contents

Why open insurance matters to Central-European P&C insurers

The business case is not abstract. Open insurance creates concrete levers that product and IT leaders can pull now, even before FIDA becomes binding.

  • Faster product launch: API-first distribution lets you push a new product to an aggregator or embedded channel in days, not months.
  • Data-driven underwriting and claims: structured data exchange with IoT sensors, telematics providers and weather services enriches risk models without manual re-keying.
  • Customer dashboards and switching: policy aggregation services give policyholders a single view across carriers, which raises engagement and reduces churn friction.
  • Lower integration cost: a canonical data model and versioned APIs replace point-to-point integrations, cutting ongoing maintenance overhead.
  • Regulatory incentive: FIDA will likely make customer-initiated data sharing compulsory for non-life insurance. Carriers that have already built the plumbing will comply faster and cheaper than those starting from scratch.

A European study on open insurance strategy (Standaert & Muylle, Geneva Papers) identifies process efficiency, new product channels and ecosystem participation as the principal performance drivers, while noting that evidence remains emergent. The direction is clear; the magnitude is still being measured.

What does the EU regulatory and standards picture look like?

The honest answer: it is moving, not settled. Here is where each piece stands.

EIOPA’s position is that open insurance is a broad concept covering access to and sharing of insurance-related personal and non-personal data, usually via APIs. Its 2021 discussion paper mapped use cases from Austria, Italy and Belgium, where local API initiatives already enable policy aggregation and product creation. The 2022 roadmap was more direct: without regulatory or self-regulatory requirements, open-insurance services rely on bilateral agreements and bridging of incompatible standards, and EIOPA listed interoperability, workable API standards, supervision and digital ethics as the four pillars of any workable framework.

What does the EU regulatory and standards picture look like? — overview diagram

FIDA is the proposed EU regulation that changes the calculus. It covers non-life insurance, creates a licensing regime for Financial Information Service Providers (FISPs), and aligns data-user obligations with DORA for cyber resilience and organisational requirements. Customers would be able to request their data be shared with any authorised FISP. FIDA is still moving through the EU legislative process; supervisory rules and technical standards are expected to follow adoption, likely on a multi-year timeline.

CEN TC445 is the European standardisation committee tasked with developing voluntary standards for insurance customer data access and portability. BIPAR’s position materials confirm that CEN TC445 work is expected to support FIDA implementation directly, and that proportionality measures (opt-in for micro and SME intermediaries) are under active discussion.

Timeline note: FIDA adoption and subsequent delegated acts will take several years. The practical implication for programme planning is that bilateral agreements remain the norm today, but building to emerging CEN standards now avoids costly rework when the regulation lands.

What are the core components and P&C use cases?

Open insurance rests on five technical building blocks:

  • Standard APIs: versioned, documented interfaces that third parties can consume without bespoke negotiation.
  • Canonical data models: agreed schemas for policy, claims, customer and risk data that prevent translation errors at integration boundaries.
  • Consent and purpose framework: machine-readable records of what data was shared, with whom, for what purpose and for how long.
  • Authorisation and audit trails: registries of which parties are permitted to access which data sets, with immutable logs.
  • Security controls: authentication (mutual TLS, OAuth2), encryption in transit and at rest, and rate limiting.

The EIOPA 2021 discussion paper identifies the most relevant P&C use cases: policy information dashboards, multi-carrier switching, instant insurance distribution via embedded channels, claims data exchange between carriers and repairers, and underwriting enrichment with IoT and weather data. Industry initiatives such as Germany’s FRIDA and the Open Insurance Initiative (OPIN) are building voluntary interface standards to make exactly these flows cheaper and more reliable.

Data type Examples Personal / non-personal
Policy metadata Policy number, cover type, sum insured, premium Personal
Claims history Claim dates, amounts, fault status Personal
IoT telemetry Telematics driving scores, smart-home sensor events Personal
Risk statistics Postcode-level loss ratios, weather event data Non-personal
Product catalogue Cover definitions, exclusions, pricing rules Non-personal

What does an API-first, open-insurance-ready architecture look like?

The stack has five layers that need to work together.

API gateway and contract layer: all external data flows pass through a managed gateway with rate limiting, authentication and versioning. Every API has a published contract (OpenAPI spec) and a contract test suite that runs in CI/CD. This is the single most important structural decision: without it, you accumulate fragmented integrations that break silently.

Network cables being connected in data center

Canonical data model and event streaming: a shared internal schema maps to external partner schemas at the boundary, not inside core systems. Event streaming (Apache Kafka or equivalent) decouples producers from consumers and gives you an audit-ready event log.

Consent orchestration layer: consent records are stored as structured, queryable objects linked to data-flow identifiers. Every API call that touches personal data carries a consent reference that can be validated in real time.

Authorisation registry: a machine-readable register of which FISPs or partners are authorised to access which data sets, updated as licences are granted or revoked.

Security and resilience: DORA alignment means documented ICT risk management, tested incident response playbooks and third-party risk assessments for every data-sharing partner. OAuth2 with short-lived tokens and mutual TLS for server-to-server calls are the baseline. API integration best practices for insurers cover these patterns in detail.

Pro Tip: Treat your OpenAPI contract files and contract test suites as first-class CI artefacts, versioned alongside application code. A failing contract test in a pull request is cheaper to fix than a runtime interoperability failure discovered by a partner at 2 AM.

Running an open insurance programme is not purely a technology task. Three governance areas need dedicated ownership.

Consent and purpose limitation: every data-sharing flow needs an auditable end-to-end consent record that maps the data subject, the purpose, the recipient and the retention period. This is not a one-time setup; it is an ongoing operational process. Insurance data privacy obligations under GDPR apply to every API call that touches personal data.

Contracts and bilateral bridging: until FIDA and CEN TC445 standards are in force, data-sharing agreements are bilateral. Each agreement needs explicit SLAs, data-quality standards, incident notification timelines and termination clauses. Do not treat these as boilerplate; they are your primary risk control.

Governance roles: the table below maps the roles a programme team needs to fill.

Role Responsibility Timeline dependency
Data owner Defines what data can be shared and under what conditions Before any pilot
API owner Maintains contract specs, versioning policy and deprecation schedule Before external onboarding
Consent owner Operates consent records, handles withdrawal requests, audits flows Before any personal-data sharing
Security officer Manages ICT risk, third-party assessments, DORA alignment Ongoing
Supervisory liaison Monitors FIDA/EIOPA developments, manages NCA engagement Ongoing

A practical 6–18 month roadmap for P&C insurers

Phase 1: discovery and impact assessment (months 1–2)

  1. Run a data inventory: catalogue every insurance data asset, classify personal vs non-personal, and map existing bilateral integrations.
  2. Assess your current API maturity against CEN TC445 and EIOPA guidance.
  3. Identify two or three high-value use cases (e.g. policy dashboard, telematics enrichment) as pilot candidates.
  4. Owners: product lead, IT architect, compliance officer.

Phase 2: API and data model pilot (months 3–6)

  1. Select one use case and build a versioned, contract-tested API against a canonical data model.
  2. Onboard one internal or trusted partner consumer.
  3. Instrument the API gateway for latency, error rate and consent-reference validation.
  4. KPIs: time to onboard partner (target: under four weeks), API p95 latency, contract test pass rate.
  1. Deploy a consent orchestration layer for the pilot data flows.
  2. Build the authorisation registry and link it to the API gateway.
  3. Run a GDPR and DORA gap assessment against the pilot architecture.
  4. KPIs: consent completion rate, consent withdrawal processing time.

Phase 4: security and resilience testing (months 8–12)

  1. Conduct penetration testing and third-party risk assessments for all pilot partners.
  2. Test incident response playbooks end-to-end.
  3. Document ICT risk management in line with DORA requirements.

Phase 5: scale and standardise (months 12–18)

  1. Extend the canonical data model to cover all priority data sets.
  2. Align API contracts to CEN TC445 schemas as they are published.
  3. Engage FRIDA and OPIN working groups to contribute to and consume emerging standards.
  • Procurement note: the choice between building an in-house API platform, adopting a platform partner, or a staged lift-and-shift of a legacy core depends on your current architecture. An API-first core insurance platform reduces the build burden significantly for carriers without a modern core.

What are the principal risks and how do you mitigate them?

  • GDPR and consent errors: a single misdirected data flow can trigger regulatory action. Mitigation: auditable consent records, purpose-limitation checks at the API gateway, regular consent audits.
  • Cyber incidents and third-party risk: every new API partner is a new attack surface. Mitigation: mutual TLS, short-lived tokens, contractual security SLAs, DORA-aligned third-party risk assessments and tested incident playbooks.
  • Fragmented standards leading to operational debt: bilateral integrations built before CEN TC445 standards are finalised may need rework. Mitigation: build to the most current EIOPA/CEN drafts, use backward-compatible versioning, and track standards progress actively.
  • Competition and consumer-protection concerns: EIOPA explicitly notes the tension between consumer benefit and data protection or financial stability risk. Mitigation: engage national competent authorities early, document consumer-benefit rationale for each data-sharing flow.
Risk Control pattern
Consent error / GDPR breach Consent audit logs, gateway-level purpose validation
Cyber incident via partner API Mutual TLS, OAuth2, contractual SLAs, DORA playbooks
Standards fragmentation / rework CEN TC445 alignment, backward-compatible versioning, contract tests
Consumer-protection challenge NCA engagement, documented consumer-benefit rationale

Pro Tip: Embed OpenAPI contract tests and schema-version checks directly in your CI/CD pipeline. A breaking change caught before merge costs minutes; one caught by a partner in production costs days and damages trust.

Which Central-European initiatives should you monitor or join?

  • FRIDA (Free Insurance Data Initiative, Germany): building a voluntary, industry-wide API interface standard to cut operating costs and accelerate secure data exchange. Relevant for any Central-European carrier wanting to adopt common schemas before FIDA mandates them. Join the working groups or at minimum consume the published specifications.
  • OPIN (Open Insurance Initiative): coordinates open insurance adoption across markets, with a focus on international standards alignment. Worth monitoring for cross-border use cases and regulatory developments.
  • CEN TC445: the European standardisation body developing voluntary standards for insurance customer data access and portability, expected to underpin FIDA implementation. Follow the work programme and respond to public consultations.
  • EIOPA outputs and national competent authorities (NCAs): EIOPA’s open insurance pages and position papers remain the primary regulatory reference. Engage your NCA early if you are planning a FISP authorisation or a significant data-sharing programme.
  • BIPAR: the European federation of insurance intermediaries publishes detailed positions on FIDA proportionality and scope, useful for distribution-focused carriers and MGAs.

The single most time-sensitive action: register to follow CEN TC445 progress through your national standards body (e.g. DIN in Germany, ÖN in Austria, ČSN in the Czech Republic). The schemas TC445 publishes will define what “compliant” looks like under FIDA.

How does IBSuite support open insurance goals?

IBSuite is built API-first from the ground up, which means the architectural patterns open insurance requires are structural features rather than add-ons.

  • API-first architecture: every IBSuite capability is exposed via versioned, documented APIs, making it straightforward to connect aggregators, FISPs or IoT data providers without custom middleware.
  • Policy administration: the IBSuite policy administration module covers the full lifecycle, with data models designed for structured external exchange.
  • Cloud-native deployment on AWS: Evergreen updates mean the platform tracks regulatory and technical changes without disruptive upgrade cycles.
  • Consent and integration orchestration: IBSuite’s integration layer supports the consent-reference and audit-trail patterns that GDPR and FIDA require.

For a deeper technical view, the API-first approach in insurance whitepaper covers data model dependencies, versioning strategy and interoperability patterns in detail.

A pragmatic perspective on where to start

The most common mistake Central-European P&C teams make is treating open insurance as a future problem. FIDA is not yet in force, so the temptation is to wait for the standards to settle. That logic is backwards.

The insurers who will comply quickly and cheaply are the ones who have already built versioned APIs, canonical data models and consent infrastructure, even if only for internal or bilateral use. When CEN TC445 schemas are finalised, they will need to map their existing models to the standard, not build from scratch.

Do: start with a single, bounded pilot. A policy dashboard or a telematics data feed is enough to surface the consent, versioning and governance gaps that will matter at scale. Prioritise consent architecture and API versioning over feature breadth.

Don’t: build point integrations as a long-term plan. Every bilateral integration you build outside a canonical model is technical debt you will pay when FIDA arrives. Standardisation is not a technical task; it is a programme governance decision that needs a named owner and a budget.

First 30 days checklist:

  • Complete a data inventory and classify personal vs non-personal assets.
  • Map all existing bilateral integrations and assess their alignment to EIOPA/CEN guidance.
  • Identify one pilot use case with a willing internal or external partner.
  • Assign governance roles: data owner, API owner, consent owner.
  • Register to follow CEN TC445 and EIOPA open insurance updates.

Ready to explore open insurance with IBA?

IBA has been building API-first core insurance platforms for P&C carriers since 2010. IBSuite’s architecture is designed for exactly the kind of structured, consent-governed data sharing that open insurance requires, and the team has practical experience helping European carriers modernise core systems without big-bang replacements.

If you are scoping a pilot or assessing your API maturity, the most useful next step is a focused conversation rather than a generic product demo. Request a tailored pilot scoping session with the IBA team, or explore the IBSuite policy administration capabilities to see how the platform maps to your open insurance roadmap. Book a conversation and come with your data inventory and use-case shortlist.

Sources

FAQ

What is open insurance in simple terms?

Open insurance is a model where insurers share policy, claims and risk data with authorised third parties via APIs, under customer consent, to enable new products and services. EIOPA describes it as accessing and sharing insurance-related personal and non-personal data, usually via APIs.

How does open insurance differ from traditional insurance data practices?

Traditional insurance keeps data siloed within the carrier. Open insurance uses standardised, versioned APIs and consent frameworks to make that data available to authorised partners, aggregators and FISPs, enabling comparison, switching and embedded distribution.

What is FIDA and why does it matter for P&C insurers?

FIDA is the proposed EU Financial Data Access regulation that will bring non-life insurance into a regulated data-sharing regime. It creates a licensing model for authorised data users (FISPs) and aligns their obligations with DORA-level cyber resilience requirements.

What is the role of CEN TC445 in open insurance?

CEN TC445 is the European standardisation committee developing voluntary standards for insurance customer data access and portability. Its output is expected to provide the technical schemas that FIDA implementation will rely on, making it the practical reference point for API design decisions today.

How can IBSuite help a P&C insurer adopt open insurance?

IBSuite is an API-first, cloud-native core platform that exposes every capability via versioned, documented APIs, covering policy administration, claims, underwriting and billing. Its architecture aligns with the consent orchestration and interoperability patterns that open insurance programmes require.