EU Financial Data Access Regulation (FIDA): What FinTech SaaS Developers Must Build Now (2026)

The EU Financial Data Access Regulation (FIDA, COM/2023/0360) is the next wave after PSD2. Where PSD2 forced open access to payment account data, FIDA extends the same logic to the entire financial data universe: savings accounts, investments, pension products, insurance policies, mortgages, and non-life insurance. If you build FinTech SaaS, personal finance apps, financial data aggregators, or any tool that accesses customer financial data beyond payment transactions, FIDA will redefine how you operate.

This guide covers the FIDA architecture, developer obligations, the Financial Information Service Provider (FISP) authorization regime, permission dashboards, CLOUD Act jurisdiction risk, and what EU-native infrastructure means for FIDA alignment.

What FIDA Is and Why It Matters

FIDA was proposed on June 28, 2023 as part of the EU retail financial services package, alongside PSD3 and the new Payment Services Regulation (PSR). The three regulations form a coherent stack:

• PSR/PSD3: Payment account access (successor to PSD2)
• FIDA: All other financial data (savings, investments, insurance, pensions, mortgages)
• DORA: Operational resilience for financial entities (applies to all of the above)

FIDA's core mechanism is permission-based data sharing through standardized schemes. Unlike PSD2's direct API mandate, FIDA works through industry-developed Financial Data Access Schemes (FDAS) that set technical standards, liability allocation, and commercial terms. The regulation sets the legal framework; the industry fills in the technical details.

Legislative status (2026): FIDA is in trilogue between the European Parliament, Council, and Commission. Substantive negotiations are ongoing. The current timeline suggests formal adoption in 2026-2027, with a transition period placing full applicability around 2028-2029. However, FISPs and financial data holders are already preparing compliance architectures — and the technical obligations are largely stable.

The FIDA Entity Map

FIDA defines three primary entity types that developers need to understand:

Financial Data Holder (FDH)

FDHs are entities that hold financial data as part of their core business: banks, investment firms, insurance companies, mortgage lenders, pension funds, payment institutions. FDHs must:

• Make customer financial data available to authorized FDUs/FISPs upon customer permission
• Provide standardized interfaces (APIs) within FDAS requirements
• Maintain interface documentation
• Not discriminate between internal and third-party access (structural separation principle from PSD2)

Financial Data User (FDU)

FDUs are entities that access financial data through FDAS-compliant interfaces — typically FinTech apps, personal finance managers (PFMs), financial advisors, credit scoring services. FDUs must:

• Obtain explicit customer permission through a FDAS-compliant permission dashboard
• Access only data covered by the granted permission
• Not use data for secondary purposes beyond what the customer authorized
• Register in a FDAS and comply with scheme rules

Financial Information Service Provider (FISP)

FISPs are a new authorization category for entities whose business model centers on financial data aggregation and analysis. If your SaaS provides financial data aggregation as a service (not just as an ancillary feature), you will likely need FISP authorization from a national competent authority.

FISP authorization triggers (indicative from COM/2023/0360 Art.19):

• Your core service aggregates financial data from multiple FDHs
• You provide consolidated financial overviews to customers
• You offer financial data analytics based on multi-source data
• You provide financial data to third-party FDUs as a service

The Permission Dashboard: Technical Obligation

FIDA Art. 9 requires that customers manage their data sharing permissions through a permission dashboard — a dedicated interface showing:

• Which entities have access to which categories of their financial data
• The purpose of each access grant
• The duration of each permission
• The ability to withdraw any permission in real time

FDHs must provide permission dashboards as part of their customer interface. FISPs and FDUs that act as intermediaries in the permission flow must integrate with FDH dashboards or provide compliant equivalents.

Developer implications:

from dataclasses import dataclass, field
from datetime import datetime, timezone
from enum import Enum
from typing import Optional
import uuid


class FinancialDataCategory(Enum):
    PAYMENT_ACCOUNT = "payment_account"          # Also covered by PSR
    SAVINGS_ACCOUNT = "savings_account"
    INVESTMENT_PORTFOLIO = "investment_portfolio"
    INSURANCE_POLICY = "insurance_policy"
    PENSION_PRODUCT = "pension_product"
    MORTGAGE = "mortgage"
    CONSUMER_CREDIT = "consumer_credit"
    NON_LIFE_INSURANCE = "non_life_insurance"


class PermissionStatus(Enum):
    ACTIVE = "active"
    WITHDRAWN = "withdrawn"
    EXPIRED = "expired"
    PENDING_CONFIRMATION = "pending_confirmation"


@dataclass
class FIDAPermission:
    """
    FIDA Art. 9 — permission record for financial data access.
    Each permission must be granular: one data category, one purpose, one duration.
    """
    permission_id: str = field(default_factory=lambda: str(uuid.uuid4()))
    customer_id: str = ""
    fdh_id: str = ""                          # Financial Data Holder
    fdu_fisp_id: str = ""                     # Requesting entity
    data_category: FinancialDataCategory = FinancialDataCategory.SAVINGS_ACCOUNT
    access_purpose: str = ""                  # Must be specific, not generic
    granted_at: Optional[datetime] = None
    expires_at: Optional[datetime] = None     # Mandatory for FIDA
    status: PermissionStatus = PermissionStatus.PENDING_CONFIRMATION
    data_residency: str = ""                  # EU jurisdiction required for CLOUD Act compliance
    scheme_id: str = ""                       # Which FDAS governs this permission

    def is_valid(self) -> bool:
        if self.status != PermissionStatus.ACTIVE:
            return False
        if self.expires_at and datetime.now(timezone.utc) > self.expires_at:
            return False
        return True

    def withdraw(self) -> None:
        """Customer can withdraw permission at any time — FIDA Art. 9(4)."""
        self.status = PermissionStatus.WITHDRAWN


@dataclass
class PermissionDashboardRecord:
    """
    Aggregated view for the customer-facing permission dashboard.
    FDHs and FISPs must be able to render this in real time.
    """
    customer_id: str
    active_permissions: list[FIDAPermission] = field(default_factory=list)
    withdrawn_permissions: list[FIDAPermission] = field(default_factory=list)
    last_updated: datetime = field(default_factory=lambda: datetime.now(timezone.utc))

    def get_active_by_entity(self, entity_id: str) -> list[FIDAPermission]:
        return [p for p in self.active_permissions if p.fdu_fisp_id == entity_id]

    def revoke_all_for_entity(self, entity_id: str) -> int:
        """Customer revokes all permissions for a specific FDU/FISP — one-click revocation."""
        count = 0
        for p in self.active_permissions:
            if p.fdu_fisp_id == entity_id:
                p.withdraw()
                self.withdrawn_permissions.append(p)
                count += 1
        self.active_permissions = [p for p in self.active_permissions
                                   if p.fdu_fisp_id != entity_id]
        return count

Financial Data Access Schemes (FDAS)

FIDA does not mandate a single technical standard — it mandates that industry stakeholders develop Financial Data Access Schemes that govern technical and commercial terms. FDAS must be recognized by the European Banking Authority (EBA) and must meet minimum requirements set in FIDA Art. 28-33:

• Common technical standards for data interfaces
• Liability allocation between FDHs and FDUs/FISPs
• Commercial terms (FDHs can charge reasonable cost-based fees)
• Dispute resolution mechanisms
• Onboarding and exit rules

Developer implication: Your product must implement the technical specifications of whichever FDAS governs the data types you access. This is analogous to payment scheme rules (SEPA, Visa) — the scheme rules are mandatory for participants.

Data Minimization and Purpose Limitation

FIDA Art. 10-12 impose strict purpose limitation on financial data access:

• FDUs and FISPs may only use data for the specific purpose stated in the permission request
• No secondary use, no profiling beyond stated purpose, no training ML models on financial data without explicit permission
• Data retention: financial data accessed under FIDA must be deleted when the permission expires or is withdrawn
• Re-identification prohibition: derived data and analytics must not enable re-identification of individuals

GDPR intersection: FIDA data sharing operates on top of GDPR, not instead of it. The legal basis for processing is typically:

• Art. 6(1)(b) GDPR: Processing necessary for the performance of a contract (the financial data service)
• Art. 6(1)(a) GDPR: Consent — but the FIDA permission mechanism is distinct from GDPR consent (FIDA permission is a contractual arrangement; GDPR consent is separately required for any processing beyond contract performance)

from dataclasses import dataclass
from enum import Enum
from typing import Optional


class GDPRLegalBasis(Enum):
    CONTRACT_PERFORMANCE = "6(1)(b)"
    LEGITIMATE_INTEREST = "6(1)(f)"
    CONSENT = "6(1)(a)"


@dataclass
class FIDADataProcessingRecord:
    """
    Combined FIDA permission + GDPR RoPA entry.
    Both regimes must be satisfied simultaneously.
    """
    permission_id: str
    customer_id: str
    data_category: str
    access_purpose: str
    gdpr_legal_basis: GDPRLegalBasis
    gdpr_retention_period_days: int
    secondary_processing: bool = False        # False = FIDA-compliant
    ml_training_use: bool = False             # Must be explicitly permitted
    cross_border_transfer: bool = False       # True = CLOUD Act risk if US entity
    data_residency_country: str = "DE"        # EU member state required
    encryption_at_rest: bool = True
    encryption_in_transit: bool = True

    def is_fida_compliant(self) -> tuple[bool, list[str]]:
        issues = []
        if self.secondary_processing:
            issues.append("Secondary processing prohibited without explicit permission")
        if self.ml_training_use:
            issues.append("ML training use requires separate explicit permission")
        if self.cross_border_transfer and not self.data_residency_country.startswith("EU"):
            issues.append("Cross-border transfer to non-EU jurisdiction triggers SCCs/adequacy check")
        if not self.encryption_at_rest or not self.encryption_in_transit:
            issues.append("Encryption required for financial data at rest and in transit")
        return (len(issues) == 0, issues)

FISP Authorization: What It Involves

If your SaaS needs FISP authorization, expect a process analogous to PSD2 AISP (Account Information Service Provider) authorization, but broader in scope:

Authorization requirements (FIDA Art. 19-27, indicative):

• Application to national competent authority (NCA) — the financial regulator in your establishment member state
• Proof of financial resources (initial capital requirements — expected in the range of PSD2 AISP: €50,000)
• Professional indemnity insurance
• Governance arrangements: fit-and-proper directors, compliance function
• Security policy documentation
• Data protection compliance evidence (DPA, GDPR records)
• FDAS membership confirmation

Timeline: PSD2 AISP authorization took 3-6 months in major EU jurisdictions. FIDA FISP authorization is expected to be similar.

Geographic note: Your FISP authorization covers all EU member states under passport rights — you authorize once and operate across the EU. This makes the choice of establishment member state (and its NCA) strategically important.

The CLOUD Act Exposure Problem for FIDA

Financial data is among the most sensitive categories of personal data. FIDA creates a structured, permission-based framework for accessing it — but that framework says nothing about what happens when a US government authority issues a demand under the CLOUD Act.

The structural conflict:

Under the CLOUD Act (18 U.S.C. § 2713), US authorities can compel US companies and their subsidiaries to produce data stored anywhere in the world — including financial data accessed under FIDA permissions. The compelled disclosure does not require:

• Notification to the data subject (customer)
• Notification to the FDH that granted the permission
• Notification to the NCA that authorized the FISP
• Court order in the EU jurisdiction

Under FIDA, customer permissions are explicit and granular. The customer granted permission to use their savings account data for personal finance management. They did not grant permission to disclose it to US law enforcement. The FIDA framework has no mechanism to reflect or account for CLOUD Act compelled disclosure.

Consequence for FISP developers:

If you build a FISP on US infrastructure (AWS, Azure, GCP, or any US-headquartered entity's cloud):

• Your data access infrastructure is subject to CLOUD Act demands
• Compelled disclosure would likely violate the purpose limitation in FIDA Art. 10
• It would likely violate GDPR Art. 5(1)(b) purpose limitation
• Your NCA (financial regulator) would not be notified
• Your authorization could be at risk

EU-native infrastructure alignment:

A FISP built on EU-native, non-US-owned infrastructure:

• Has no CLOUD Act exposure (no US nexus)
• Operates under a single legal order (EU/EEA)
• Can credibly represent to FDHs, FDAs, and NCAs that data sharing occurs within a defined legal perimeter
• Removes a category of regulatory and reputational risk that US-infrastructure FISPs carry structurally

This is not a marketing claim — it is an architectural fact that affects FIDA authorization applications and ongoing supervisory assessments.

DORA Intersection

FIDA entities (FDHs, FISPs) that are also regulated financial entities will face the full requirements of DORA (Digital Operational Resilience Act, ITRE/ECON committee) — ICT risk management, incident reporting, third-party risk management, and digital operational resilience testing.

DORA Art. 28 is particularly relevant: it requires financial entities to assess and manage ICT third-party risk — including the risk that cloud providers or data infrastructure operators are subject to legal demands from non-EU authorities. A FISP using US cloud infrastructure would need to:

• Document the CLOUD Act risk in its ICT third-party risk register
• Assess the probability and impact of compelled disclosure
• Define mitigating controls (encryption, key management)
• Report this risk in the annual DORA ICT risk report to the NCA

Note: Encryption-only mitigations have limits. If the FISP operates the infrastructure (and thus holds the keys), US authorities can compel production of both the data and the keys.

Technical Implementation Checklist

from dataclasses import dataclass, field
from enum import Enum


class FIDAComplianceStatus(Enum):
    COMPLIANT = "compliant"
    PARTIAL = "partial"
    NON_COMPLIANT = "non_compliant"
    NOT_APPLICABLE = "not_applicable"


@dataclass
class FIDAComplianceAssessment:
    """30-item FIDA developer compliance checklist (2026 pre-application)."""
    entity_name: str
    assessment_date: str
    checks: dict[str, FIDAComplianceStatus] = field(default_factory=dict)

    def run_checklist(self) -> None:
        """Self-assessment against key FIDA obligations."""
        self.checks = {
            # Entity classification
            "entity_type_determined": FIDAComplianceStatus.PARTIAL,
            "fisp_authorization_needed": FIDAComplianceStatus.PARTIAL,
            "fdh_obligations_assessed": FIDAComplianceStatus.NOT_APPLICABLE,

            # Permission architecture
            "permission_dashboard_designed": FIDAComplianceStatus.PARTIAL,
            "granular_permission_model_built": FIDAComplianceStatus.PARTIAL,
            "permission_expiry_enforced": FIDAComplianceStatus.PARTIAL,
            "one_click_revocation_implemented": FIDAComplianceStatus.NON_COMPLIANT,
            "permission_audit_log_maintained": FIDAComplianceStatus.PARTIAL,

            # FDAS membership
            "target_fdas_identified": FIDAComplianceStatus.NON_COMPLIANT,
            "fdas_technical_standards_reviewed": FIDAComplianceStatus.NON_COMPLIANT,
            "fdas_membership_application_prepared": FIDAComplianceStatus.NON_COMPLIANT,

            # Data handling
            "purpose_limitation_enforced": FIDAComplianceStatus.PARTIAL,
            "secondary_processing_blocked": FIDAComplianceStatus.PARTIAL,
            "ml_training_separation": FIDAComplianceStatus.NON_COMPLIANT,
            "data_deletion_on_expiry": FIDAComplianceStatus.PARTIAL,
            "re_identification_prevention": FIDAComplianceStatus.PARTIAL,

            # GDPR alignment
            "gdpr_ropa_updated_for_fida": FIDAComplianceStatus.NON_COMPLIANT,
            "legal_basis_documented_per_category": FIDAComplianceStatus.PARTIAL,
            "dpa_agreement_with_fdhs": FIDAComplianceStatus.NON_COMPLIANT,
            "dpia_completed_for_financial_data": FIDAComplianceStatus.NON_COMPLIANT,

            # Security
            "financial_data_encrypted_at_rest": FIDAComplianceStatus.COMPLIANT,
            "financial_data_encrypted_in_transit": FIDAComplianceStatus.COMPLIANT,
            "key_management_eu_only": FIDAComplianceStatus.PARTIAL,
            "access_controls_per_permission": FIDAComplianceStatus.PARTIAL,
            "incident_response_plan_fida": FIDAComplianceStatus.NON_COMPLIANT,

            # Infrastructure jurisdiction
            "cloud_act_exposure_assessed": FIDAComplianceStatus.NON_COMPLIANT,
            "eu_native_infrastructure_used": FIDAComplianceStatus.NON_COMPLIANT,
            "dora_ict_risk_register_updated": FIDAComplianceStatus.NON_COMPLIANT,
            "no_us_parent_company_data_access": FIDAComplianceStatus.NON_COMPLIANT,

            # Authorization preparation
            "nca_target_jurisdiction_selected": FIDAComplianceStatus.NON_COMPLIANT,
            "professional_indemnity_insurance": FIDAComplianceStatus.NON_COMPLIANT,
        }

    def compliance_score(self) -> tuple[int, int]:
        compliant = sum(1 for v in self.checks.values()
                       if v == FIDAComplianceStatus.COMPLIANT)
        total = sum(1 for v in self.checks.values()
                   if v != FIDAComplianceStatus.NOT_APPLICABLE)
        return compliant, total

Key Differences from PSD2: What Changes for Developers

Practical Next Steps for FinTech SaaS Developers

If you build personal finance apps, financial aggregation, or multi-bank dashboards:

1. Classify your entity now. Are you an FDU (accessing data as ancillary feature) or a FISP (financial data aggregation is your core service)? FISP authorization is a multi-month process.

2. Audit your data categories. Map which FIDA categories you currently access or plan to access. This determines which FDAS you need to join.

3. Design your permission dashboard. This is not optional — FIDA mandates granular, revocable permissions with a customer-facing interface. Design it into your data model now, not after authorization.

4. Assess your infrastructure jurisdiction. If you operate on US infrastructure: document the CLOUD Act risk formally, assess whether EU-native migration makes sense before your FISP authorization application. NCAs will assess infrastructure risk as part of the authorization process.

5. Align your GDPR records. FIDA data sharing requires distinct GDPR legal basis documentation per data category and per processing purpose. Update your RoPA now.

6. Track FDAS development. The industry schemes are being developed now. The EBA is coordinating. Subscribe to EBA consultations on FIDA implementation.

FIDA Timeline (Current Assessment)

The window to prepare is now — FISP authorization processes will be competitive, NCAs will prioritize well-prepared applicants, and FDAS membership terms favor early participants.

FIDA creates a new regulatory layer on top of your FinTech SaaS architecture. The permission dashboard, FDAS membership, FISP authorization, and CLOUD Act exposure assessment are not items to defer to 2028. The entities that prepare compliance architectures now — including infrastructure jurisdiction decisions — will have the clearest path through FISP authorization when NCAs open their doors.

For SaaS developers building on EU-native infrastructure: FIDA is one more structural argument for why your architecture aligns with the regulatory trajectory of the EU financial services sector.