Financial Data Access Regulation (fida) Romania 2026: Compliance Roadmap for Banks, Fintechs and Insurers

Financial data access regulation Romania is entering an important planning window in 2026, as the EU’s proposed Financial Data Access Regulation (FiDA) moves through the legislative process toward adoption and eventual phased implementation, prompting data holders to prepare in earnest. FiDA is designed to establish a framework for the controlled, consent-based sharing of customer financial data across the EU through secure, standardised interfaces, extending the logic of open banking into a broader “open finance” ecosystem (see EUR-Lex and the European Commission digital finance pages).

For Romanian banks, non-bank institutions, insurers and fintechs, the practical question is increasingly how to translate anticipated EU obligations into operational controls aligned with the expectations of the Autoritatea de Supraveghere Financiară (ASF) and the Banca Națională a României (BNR). This article sets out a practitioner’s compliance roadmap, mapping likely obligations to supervisory expectations, data protection duties and the technical architecture firms are expected to build.

Who this is for: heads of compliance, risk, product, data and technical leads at Romanian banks, non-bank lenders (NBIs), insurers and fintechs who need a concise explanation of FiDA’s intended obligations, a step-by-step readiness plan and a clear view of how ASF, BNR and data protection expectations intersect. The guidance below reflects advisory interpretation and operational practice, it is not legal advice, and firms should confirm the final text and timing of FiDA once adopted.

What FiDA requires, scope, key definitions and timelines

The financial data access regulation Romania firms are preparing for is an EU-level instrument that would create rights for customers to authorise access to their financial data and corresponding obligations for the entities that hold that data. In its most compact form: FiDA would require designated data holders to make specified categories of customer financial data available, upon the customer’s permission, to authorised recipients through secure technical interfaces (EUR-Lex; European Commission). The stated aim is to enable new data-driven products while protecting consumers and preserving financial stability.

Scope and entities covered, data holders and third-party providers

As proposed, FiDA would apply across a broad swathe of the financial sector rather than being confined to payment accounts. The entities that hold customer financial data, banks, insurers, investment firms, pension providers and others, would fall within scope as data holders. Alongside them would sit the authorised recipients of data, often described as financial information service providers, which access data to deliver services to customers. For Romanian institutions, this means the obligation landscape is expected to extend well beyond the retail banking functions familiar from earlier open banking rules, reaching into insurance, lending and investment data held by regulated firms (EUR-Lex).

A single banking group may act simultaneously as a data holder for some datasets and a data recipient for others, which materially complicates governance.

Key definitions, shared data, consent and APIs

Three concepts anchor the proposed regime. First, the categories of shareable data: FiDA identifies defined datasets that would be made accessible, drawing a boundary between data that falls within the sharing obligation and data that does not. Second, customer permission: data may only be shared where the customer has granted a valid, specific and revocable permission, giving the individual or business control over which recipient receives which dataset and for how long. Third, the technical interface: sharing is expected to occur through secure, machine-readable interfaces, typically application programming interfaces (APIs), built to common standards so that the ecosystem is interoperable rather than fragmented (European Commission). These definitions drive the technical and consent-management work streams later in this roadmap.

High-level timeline and phased obligations

FiDA is expected to be implemented in phases rather than switching on in a single moment, with obligations for data holders, the development of common standards through industry schemes, and supervisory readiness staggered over time. The precise dates depend on the final adopted text and any transitional periods, which were still being negotiated at EU level. Romanian firms should treat 2026 as a foundational planning year: the practical effect of a phased approach is that governance, data mapping and architecture decisions taken now will determine whether an institution can meet later technical go-live obligations.

Because the precise sequencing and dates are set at EU level and refined through delegated and supervisory instruments, compliance teams should monitor the authoritative sources directly, the EUR-Lex text and European Commission implementation pages, and align internal milestones to confirmed timelines rather than to assumptions.

Action required: appoint an accountable owner for FiDA readiness now, establish a monitoring routine for EUR-Lex and Commission updates, and begin scoping which datasets your institution holds and shares.

How financial data access regulation Romania interacts with supervisors (ASF and BNR)

FiDA, once adopted, would be an EU regulation with direct effect, but it would operate within a national supervisory architecture. In Romania, two authorities shape how financial-sector rules are supervised in practice: the Autoritatea de Supraveghere Financiară (ASF, the Romanian Financial Supervisory Authority) and the Banca Națională a României (BNR, the National Bank of Romania). Understanding the division of responsibilities is essential to engaging supervisors correctly and avoiding gaps.

ASF role, insurers, market conduct and data sharing

The ASF supervises the insurance, capital markets and private pensions sectors in Romania, and its remit extends to market conduct and the protection of consumers and investors (ASF). Under FiDA, insurers and insurance intermediaries would become data holders for defined categories of customer data, which would bring their data-sharing practices within the ASF’s conduct supervision. Firms in these sectors should anticipate that the ASF will expect robust consent mechanisms, clear customer disclosures, fair treatment in how shared data is used, and demonstrable governance around which recipients obtain access. For insurance intermediaries and NBIs operating in parallel sectors, the ASF’s expectations on internal control and conduct will shape how data-sharing processes are documented and audited.

Engaging early with ASF communications and sectoral guidance allows insurers to align product design and consent flows with local conduct expectations rather than retrofitting them.

BNR role, banks, prudential considerations and operational resilience

The BNR is the prudential and operational supervisor for credit institutions in Romania and oversees the stability and sound functioning of the banking system (BNR). For banks, FiDA readiness is not only a conduct and data question but an operational resilience question: exposing customer data through always-on APIs creates new availability, security and third-party dependency risks. The practical effect for banks is that the BNR’s expectations on operational resilience, outsourcing, incident management and ICT risk, including those arising under the EU Digital Operational Resilience Act (DORA), will frame how FiDA interfaces are built and maintained.

Banks should expect scrutiny of their API availability, their ability to detect and respond to incidents affecting data-sharing services, and the resilience of arrangements with third-party providers and technology vendors. Aligning FiDA architecture with existing resilience frameworks avoids duplicated controls and demonstrates coherent governance.

Who to notify and expected supervisory engagement

Firms should map their supervisory touchpoints early: banks engage primarily with the BNR on prudential and resilience matters, while insurers and market participants engage with the ASF on conduct and data-sharing practices. Supervisory attention is likely to focus on consent integrity, API availability, security incident handling and the fairness of data use. Treat these as the likely supervisory priorities and build monitoring and reporting capabilities to evidence them.

Data protection and consumer rights, GDPR and EDPB interplay

FiDA does not operate in isolation from data protection law. Because shared financial data will frequently constitute personal data, the General Data Protection Regulation (GDPR) and the guidance of the European Data Protection Board (EDPB) apply in parallel, and firms must reconcile the two frameworks carefully (EDPB). In Romania, the national supervisory authority for data protection is ANSPDCP (Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal).

Lawful basis and controller/processor roles

A recurring design question is the relationship between FiDA’s permission mechanism and GDPR’s lawful basis requirements. FiDA would require customer permission for data sharing, but firms must still determine the correct lawful basis under GDPR for each processing activity and define clearly who acts as controller and who as processor across the data-sharing chain. Where a data holder transmits data to a recipient, both parties must understand their respective roles and responsibilities, including transparency obligations to the customer. Misclassifying controller and processor relationships is a common source of compliance gaps, so these roles should be documented in writing and reflected in contracts (EDPB).

EDPB guidance and proportionality checks

The EDPB provides guidance on data minimisation, purpose limitation and proportionality that is directly relevant to open finance. Data holders should ensure that only the data the customer has authorised, for the purpose specified, is shared, and that recipients cannot obtain more than is necessary. Proportionality assessments should be built into the consent architecture so that permission scopes map precisely to the datasets and purposes presented to the customer. This alignment reduces the risk of over-sharing and strengthens the firm’s position in any supervisory review.

Data subject rights, DPIAs and records

Where data sharing is likely to result in a high risk to individuals, a Data Protection Impact Assessment (DPIA) is required under GDPR, and the EDPB has set out expectations on when and how DPIAs should be conducted (EDPB). Financial data sharing, given its sensitivity, scale and the involvement of third parties, will often warrant a DPIA. Firms must also maintain records of processing, honour data subject rights (access, rectification, erasure and objection where applicable), and ensure that the withdrawal of a FiDA permission is reflected promptly in the cessation of data sharing.

Action required: schedule DPIAs for each significant data-sharing use case, document controller/processor roles for every data flow, and align permission scopes with GDPR purpose limitation before any technical build.

Obligations by data holder type, banks vs insurers vs fintechs

Although FiDA would apply across the sector, the operational weight of each obligation differs by institution type. The comparison below helps firms prioritise. It reflects how the financial data access regulation Romania institutions must prepare for is likely to land differently on banks, insurers and fintechs or NBIs.

Practical actions per institution type

Banks should plan to extend existing open banking and SCA infrastructure to the broader datasets FiDA would cover, and integrate FiDA interfaces into the operational resilience framework the BNR already supervises. Insurers may need to build consent journeys and data-sharing controls largely from first principles, paying close attention to ASF conduct expectations and the fairness of how shared policy data is used. Fintechs and NBIs, which often rely on third-party technology platforms, should concentrate on vendor due diligence, contractual SLAs and demonstrable end-to-end logging, since their regulatory accountability is not diminished by outsourcing the technical build. Across all three types, the common thread is that data-sharing capability must be matched by governance and evidence.

Operational controls and technical requirements

The technical core of the financial data access regulation Romania firms are preparing to build rests on secure interfaces, disciplined consent management, strong authentication and comprehensive monitoring. These controls determine both compliance and customer trust.

API standards and interoperability

FiDA envisages data sharing through standardised, secure interfaces so that the open finance ecosystem is interoperable rather than a patchwork of proprietary connections (European Commission). Firms should design APIs to common standards as they develop under the regime and relevant industry schemes, ensuring consistent data formats, error handling and versioning. Interoperability reduces integration cost for recipients and lowers the risk of fragmented implementations that supervisors may view unfavourably. Where industry schemes develop shared technical specifications, aligning early avoids costly rework.

Consent management and user experience

Consent is the gatekeeper of the entire regime. A robust consent management layer must capture specific, informed permissions, present scopes clearly to the customer, record the permission with a timestamp and purpose, and allow straightforward revocation. The user experience must make it obvious which data will be shared, with whom, for what purpose and for how long. When a customer withdraws permission, the system must stop the corresponding data flow promptly and record the change. Poor consent UX is both a conduct risk and a data protection risk, so product, legal and compliance functions should design it together.

Authentication, MFA and PSD2/FiDA alignment

Access to financial data must be protected by strong authentication. Banks can often extend the strong customer authentication (SCA) mechanisms built for payments under PSD2, but FiDA’s broader scope means authentication must cover datasets and recipients beyond payments. Multi-factor authentication (MFA), secure recipient onboarding and credential management are essential. Firms should map where existing authentication can be reused and where new controls are required, ensuring consistency across the data-sharing estate rather than divergent approaches per product line.

Logging, audit trails, monitoring and incident response

Comprehensive logging underpins both supervision and security. Firms should log consent events, data access requests, the datasets shared, recipient identities and the outcome of each request, retaining records in a form that supports audit and supervisory enquiry. Continuous monitoring should detect anomalous access patterns, potential fraud and availability issues. A tested incident response capability is critical: because APIs are externally facing and continuously available, incidents affecting data-sharing services must be detected, contained and reported in line with operational resilience expectations the BNR supervises for banks (BNR) and conduct expectations the ASF holds for insurers and market participants (ASF).

The Financial Stability Board has highlighted that the operational dependencies created by data sharing can carry wider stability implications, reinforcing the need for resilient architecture (FSB).

Action required: define logging and retention standards, stand up continuous monitoring, and rehearse an incident response playbook specific to data-sharing interfaces before go-live.

Compliance roadmap and project plan, a 12 to 18 month readiness checklist

A structured programme is the most reliable route to readiness. The phased plan below gives compliance, risk, product and technical leads a sequence with clear ownership, turning the financial data access regulation Romania obligations into deliverable work streams.

Phase 0, governance and gap analysis

• Accountable owner. Appoint a senior sponsor and establish a cross-functional FiDA steering group spanning compliance, risk, data protection, product, security and technology.
• Regulatory monitoring. Set up a routine to track EUR-Lex, European Commission, ASF and BNR updates so milestones track confirmed timelines.
• Gap analysis. Assess current capability against anticipated FiDA obligations across data, consent, authentication, logging and vendor management, and produce a prioritised remediation backlog.

Phase 1, data mapping, DPIAs and vendor contracts

• Data inventory. Map which likely in-scope datasets the institution holds, where they reside and how they would be shared, identifying where the firm is data holder versus recipient.
• DPIAs. Conduct Data Protection Impact Assessments for high-risk data-sharing use cases and document controller/processor roles for each flow (EDPB).
• Vendor review. Review existing technology and third-party contracts for FiDA-relevant clauses and begin renegotiation where gaps exist.

Phase 2, build APIs, consent flows and security testing

• API development. Build interfaces to common standards, with robust versioning, error handling and documentation for recipients (European Commission).
• Consent architecture. Implement the consent management layer and customer-facing UX, ensuring scopes map to datasets and purposes, with prompt revocation.
• Security testing. Subject interfaces and authentication to penetration testing and resilience testing before any external exposure, aligning with BNR operational resilience expectations.

Phase 3, testing, supervisory engagement and go-live controls

• End-to-end testing. Validate the full journey, consent, authentication, data retrieval, logging and revocation, with recipient partners in a controlled environment.
• Supervisory engagement. Engage the relevant supervisor, BNR for banks, ASF for insurers and market participants, to confirm expectations and demonstrate readiness (BNR; ASF).
• Go-live controls. Establish monitoring dashboards, incident response readiness, SLA tracking and a post-go-live review cycle to address issues quickly and evidence ongoing compliance.

Action required: assign a named owner and target date to every phase, and treat Phase 0 and Phase 1 as the critical path for 2026.

AML, KYC and fraud mitigation under FiDA

Data sharing changes how firms can access customer information, but it does not transfer or extinguish anti-money-laundering responsibilities. The Financial Action Task Force makes clear that AML obligations rest with obliged entities, and firms must integrate FiDA readiness with their AML and KYC frameworks rather than treating them separately (FATF). Romanian firms should also account for the EU Anti-Money Laundering framework, including the AML Regulation and the EU Anti-Money Laundering Authority (AMLA), as these continue to shape national obligations.

Which AML checks change

Shared financial data can enrich customer due diligence and know-your-business (KYB) processes by giving authorised recipients a fuller, customer-permissioned picture. This can improve the quality of KYC inputs and reduce friction in onboarding. Crucially, however, access to richer data does not remove the obligation to perform independent verification, ongoing monitoring and reporting, the responsibility remains with the obliged entity (FATF).

Practical mitigations for fraud and screening

Firms should use data-sharing capabilities to strengthen rather than replace controls: cross-reference customer-permissioned data against existing records to detect inconsistencies, apply sanctions and watchlist screening to new data flows, and monitor for anomalous access that may indicate account takeover or fraudulent recipients. Governance should ensure that the AML function is represented in the FiDA steering group so that consent scopes, data use and screening logic are coordinated. Because open finance introduces new third-party relationships, due diligence on recipients and vendors becomes part of the fraud-mitigation perimeter.

Costs, vendor selection and contracting checklist

FiDA readiness is expected to carry real cost, in technology, change capacity and ongoing operations, and much of the delivery risk sits with third parties. Disciplined procurement and contracting protect the institution.

Procurement considerations, SLAs and security warranties

When selecting vendors or third-party partners, firms should assess technical capability against emerging common standards, security posture, and track record on availability and incident handling. Contracts should specify service level agreements for API uptime and performance, incident notification timelines consistent with operational resilience expectations, and security warranties backed by independent testing or certification. Given the BNR’s supervision of banks’ operational resilience, banks in particular should ensure vendor arrangements fit within existing outsourcing and ICT risk frameworks, including DORA obligations (BNR).

Contract clauses, liability, data minimisation and audit rights

Key clauses include clear allocation of liability for data breaches and service failures; data minimisation obligations that restrict recipients to the data and purposes the customer has authorised; audit rights allowing the institution and, where relevant, supervisors to inspect compliance; sub-processor controls; and termination and exit provisions that ensure data is returned or deleted. Data protection terms must reflect the controller/processor analysis conducted in Phase 1 and the EDPB’s expectations on roles and safeguards (EDPB). These provisions should be drafted before, not after, technical integration begins.

Conclusion, next steps and supervisory engagement

The financial data access regulation Romania firms are preparing for is a strategic programme, not a box-ticking exercise, and 2026 is a sensible year to lay the groundwork even as the final text and timing are confirmed. Three priorities stand out. First, establish governance now, a named owner, a cross-functional steering group and a live link to EUR-Lex, Commission, ASF and BNR updates. Second, do the foundational work early: map likely in-scope data, run DPIAs, document controller/processor roles and review vendor contracts before building anything.

Third, treat technical controls, standardised APIs, robust consent management, strong authentication and comprehensive logging, as the backbone of both compliance and customer trust, and engage the relevant supervisor (BNR for banks, ASF for insurers and market participants) to confirm expectations before go-live. Firms that sequence these steps through a 12 to 18 month plan will meet the phased obligations with confidence rather than scrambling at deadlines. Specialist advisory and consulting support can accelerate gap analysis, roadmap design and supervisory engagement for institutions preparing for FiDA.

Sources

1. EUR-Lex, EU legal database
2. European Commission, Financial Stability, Financial Services and Capital Markets Union
3. ASF, Autoritatea de Supraveghere Financiară (Romanian Financial Supervisory Authority)
4. BNR, Banca Națională a României (National Bank of Romania)
5. EDPB, European Data Protection Board
6. FATF, Financial Action Task Force
7. FSB, Financial Stability Board