FISP Authorisation Under FIDA: The Complete Step-by-Step Guide

Introduction

If your organisation wants to access financial data held by banks, insurers, or investment firms under the EU's Financial Data Access (FIDA) framework, you will need to become a Financial Information Service Provider, or FISP.

FISP authorisation is not a single approval. It is a two-track process: you need regulatory authorisation from a National Competent Authority (NCA), and you need scheme membership from one or more Financial Data Sharing Schemes (FDSS). Both are required before you can make a single live API call to a data holder.

This guide walks through both tracks: what they require, how they sequence, and what your technical infrastructure needs to look like before you apply.

One note on scope: this guide covers how FISPs connect once authorised. It does not cover the identity verification and runtime trust layer, which is a separate function handled by authorisation verification services. The gap those services leave open is the infrastructure plumbing between your authorisation status and your ability to actually exchange data. That is what this guide addresses.

What Is a FISP?

Under the FIDA Regulation (Proposal COM/2023/0360), a Financial Information Service Provider is any legal entity that:

• Offers services to customers based on the processing of financial data

• Has been granted authorisation by an NCA in an EU Member State

• Is enrolled as a member of one or more FDSS operating under FIDA Article 10

The FISP category covers a wide range of businesses: personal finance management platforms, AI-powered financial advisory tools, credit risk analytics providers, mortgage comparison services, investment aggregators, and any other service that derives value from multi-source financial data.

FISP status under FIDA is distinct from account information service provider (AISP) status under PSD2. FIDA expands the data scope dramatically, from payment account transaction data to investment accounts, insurance policies, pension data, and consumer credit data. A FISP operating under FIDA will have access to data categories that AISPs cannot currently reach.

The Two-Track Authorisation Model

FISP authorisation operates on two simultaneous tracks that must both be completed before live data access is possible.

Track 1: NCA Authorisation Your organisation must apply to a National Competent Authority in one EU Member State for a FISP authorisation. The NCA will assess your business model, data governance framework, security controls, customer consent mechanisms, and organisational capacity. Authorisation under one NCA provides passporting rights across the EU, so you do not need separate authorisation in every Member State where you operate.

Track 2: FDSS Scheme Enrolment Separately, your organisation must enrol as a member of at least one FDSS. Financial Data Sharing Schemes are the technical and governance intermediaries that sit between FISPs and data holders. The FDSS defines the API standards FISPs must implement, certifies their technical compliance, and provides the infrastructure through which permissions and data requests flow.

The sequence matters. NCA authorisation is typically the first step, and regulators expect to see scheme membership plans in your application. FDSS onboarding then requires proof of regulatory authorisation or an advanced application. Both tracks run in parallel during the final stages.

Track 1: NCA Application, What to Prepare

Step 1: Choose Your Home Member State

FISP authorisation works on a home-state principle. Your home Member State is where you apply for authorisation and where your primary NCA supervision occurs. Choose based on:

• Where your principal operations or registered office are located

• The regulatory sophistication and processing speed of the NCA (this varies across Member States; the Irish CBI, Dutch AFM, and German BaFin are likely to develop mature FISP frameworks earliest given their existing fintech supervisory capacity)

• Proximity to your customer base and data holder counterparties

Step 2: Assemble Your Application Package

The FIDA Regulation (as drafted) requires NCA applicants to demonstrate:

Business model documentation

• Description of the financial information services you will offer

• Categories of financial data you intend to access

• Customer segments and use cases

• Revenue model and sustainability evidence

Organisational and governance requirements

• Management body composition (fit and proper requirements)

• Organisational chart with clear lines of responsibility for data access operations

• Compliance function and FIDA compliance officer designation

• Third-party management framework (including any subprocessors involved in data handling)

Customer consent and permission framework

• Technical documentation of your consent capture and management system

• Demonstration that customer permissions will be granular (data category, time-limited, revocable)

• Permission management interface accessible to customers

Data security and ICT risk framework (DORA-aligned)

• ICT risk management policy per DORA Article 5

• Incident classification and reporting procedures per DORA Article 18

• Third-party ICT risk management documentation

• Penetration testing schedule and most recent results

• Business continuity and disaster recovery plans

Financial resilience

• Minimum capital requirements (to be set in FIDA Level 2 measures; expect alignment with the AISP professional indemnity insurance model)

• Professional indemnity insurance or equivalent safeguard

Scheme enrolment plan

• Identification of the FDSS or FDSSs you intend to join

• Status of FDSS onboarding process

• Anticipated timeline to first live API access

Step 3: NCA Review and Decision Timeline

NCAs under FIDA will likely follow a review process modelled on PSD2 AISP authorisation. Expect a formal completeness check (typically 2 to 4 weeks), followed by substantive review (expected 60 to 90 working days under the Regulation), and a decision. Where applications are incomplete or deficient, the clock pauses pending supplementary information.

Practical note: Apply early and interact with your NCA before formal submission if possible. Regulators with AISP experience will assess FISP applications faster. New-to-fintech NCAs may take longer. Build NCA processing time into your go-live planning.

Track 2: FDSS Scheme Enrolment, Practical Mechanics

What Is an FDSS?

A Financial Data Sharing Scheme (FDSS) is the infrastructure and governance layer that mediates between FISPs and data holders. Under FIDA Article 10, every data holder must participate in at least one FDSS, and every FISP must belong to at least one FDSS that shares members with the data holders they want to access.

The FDSS provides:

• The technical API standards and certification framework FISPs must implement

• The permission management infrastructure (routing consent, permissions, and revocations)

• The trust register that confirms FISP authorisation status at the point of data request

• Dispute resolution and governance mechanisms

The Berlin Group's openFinance API framework is the foundational technical specification that FDSS API standards are expected to build upon. It is the technical floor from which FIDA FDSS API standards will be derived.

FDSS Onboarding, Step by Step

Step 1: Identify the relevant FDSS or FDSSsMultiple FDSS operators will emerge across the EU. Scheme selection depends on which data holders you need to access, which schemes they have joined, and what data categories each scheme covers. FDSS membership is not exclusive; you may need to join multiple schemes to access all target data holders.

Step 2: Technical certificationEach FDSS will operate a technical certification process. This involves:

• Implementing the FDSS API specification to the required version

• Completing FDSS-mandated security certification (API security, certificate management)

• Completing the FDSS sandbox testing programme

• Receiving an FDSS digital certificate that identifies your organisation in live data exchanges

Step 3: Operational onboardingAfter technical certification:

• Signing the FDSS participation agreement (contractual rights and obligations)

• Paying scheme membership fees (structure to be confirmed; expected annual plus transaction-based)

• Registering your production API endpoints with the FDSS

• Receiving live access to the FDSS trust infrastructure

Step 4: FDSS-to-NCA cross-confirmationThe FDSS will verify your NCA authorisation status before granting live access. This is the trust verification step: the FDSS confirms you appear in the NCA register before activating your scheme credentials. If your authorisation is later suspended or revoked, the FDSS is expected to receive real-time notification and suspend your scheme credentials immediately.

Infrastructure Readiness: The API Layer

Authorisation and scheme enrolment clear the regulatory and governance gates. The technical layer is where execution happens.

Your FISP infrastructure must be ready to:

Implement FDSS API specificationsEach FDSS will publish API specifications that FISPs must implement. Expect REST or GraphQL API standards, OAuth 2.0 with FAPI 2.0 security profiles, certificate-based mutual authentication (mTLS), and Berlin Group openFinance API data schemas. Design your API client layer to be specification-agnostic in its core logic, because you will need to support multiple FDSS specifications simultaneously as you join additional schemes.

Manage customer permissions at scaleYour permission management system must: capture granular customer consent at the point of FISP onboarding, store and version permission records, route permission grants and revocations to the relevant FDSS in real time, handle permission scope changes (a customer can narrow or withdraw consent), and provide customers with a readable permission dashboard.

Implement DORA-compliant ICT risk managementEvery FIDA API endpoint you build must meet DORA ICT risk requirements. DORA is already in force. This is not a future requirement. FISPs that build API infrastructure without DORA alignment will face a rebuild cycle when their NCA conducts ICT risk assessments. The key requirements for FISP API infrastructure under DORA:

• API endpoints must be included in your ICT asset register

• Connectivity to FDSS infrastructure must be covered by your third-party ICT risk management framework

• API incidents (availability, integrity, confidentiality breaches) must be classified and reported per the DORA incident taxonomy

• Your FDSS connectivity must be covered by your ICT continuity plans

Build for revocation handlingWhen a FISP's NCA authorisation is revoked or suspended, the FDSS should receive near-real-time notification and suspend scheme credentials. Your infrastructure must handle abrupt credential suspension gracefully: queueing in-flight requests, notifying affected customers, and preserving audit trails. This is a non-obvious resilience requirement that many FISP teams will discover too late.

Timeline: From Application to First Data Access

Based on analogous frameworks (PSD2 AISP authorisation, GDPR certification schemes), a realistic FISP authorisation timeline:

Phase	Duration
NCA pre-application engagement	4 to 8 weeks
Application assembly and submission	6 to 12 weeks
NCA completeness review	2 to 4 weeks
NCA substantive review	12 to 18 weeks (60 to 90 working days)
FDSS technical certification (sandbox)	8 to 12 weeks
FDSS production onboarding	4 to 6 weeks
Total: Application start to first live API call	about 9 to 15 months

This timeline is indicative and will compress as regulatory processes mature and FDSS onboarding becomes routine. First-mover FISPs will face longer timelines because NCA and FDSS processes will not yet be fully optimised.

The practical implication: If FIDA data holder obligations begin in 2028 (under an H2 2026 political agreement scenario), FISPs need to begin their authorisation process in 2026 to 2027 to be ready at the market opening window. Waiting for political agreement before starting is not a viable strategy if first-mover access matters to your business.

Post-Authorisation: Two Layers of Ongoing Compliance

After go-live, FISP compliance has two distinct layers, and different providers serve each.

Layer 1: Authorisation status monitoringYour FDSS continuously verifies your NCA authorisation status via the NCA trust register. Third-party authorisation verification services (such as Konsentus) also provide independent real-time monitoring of NCA registers. This layer answers the question: is this FISP still authorised?

Layer 2: Infrastructure operation and complianceInfraFIDA operates at this layer. Once authorised, the FISP must maintain its DORA-compliant API infrastructure, manage permissions at scale, ensure FDSS API specification compliance as standards evolve, handle NCA supervisory requests for data and audit trails, and manage scheme membership across multiple FDSS operators as the market fragments.

This is the plumbing layer. Konsentus tells you who is authorised. InfraFIDA builds how they connect.

NCA Readiness Checklist for FISP Applicants

1. Home Member State selected and NCA identified

2. Business model documentation complete

3. Customer consent and permission management system designed and documented

4. ICT risk management framework aligned with DORA (documented and implemented, not just planned)

5. Management body fit and proper assessments complete

6. Third-party ICT risk register includes all data-adjacent vendors

7. FDSS candidate or candidates identified and pre-application contact made

8. Berlin Group openFinance API specification reviewed and gap analysis complete

9. Capital requirements assessment complete (pending Level 2 confirmation)

10. Professional indemnity insurance secured or in procurement

11. Penetration testing completed on planned FISP API infrastructure

InfraFIDA's Role in FISP Infrastructure

InfraFIDA provides the infrastructure layer that connects authorised FISPs to data holders at scale. Our focus is the connectivity, API integration, and compliance infrastructure that sits between regulatory authorisation and live data access.

If you are preparing for FISP authorisation and want to understand the infrastructure requirements in detail, contact InfraFIDA or explore our FIDA compliance infrastructure services.

This guide reflects the FIDA Regulation as proposed (COM/2023/0360) and trilogue texts as of August 2026. Final technical standards will be defined in Level 2 delegated acts following FIDA adoption. All timelines are indicative.