FiDA in Trilogue: Why Permission Management is Becoming the Customer Interface

FiDA is not yet passed legislation. The Financial Data Access Regulation is currently in the trilogue process between the European Parliament, the Council, and the Commission. Therefore, institutions today should neither claim a completed list of obligations nor postpone the topic to a later legislative act. The sensible mandate lies in between: develop a resilient target state for permission management and clearly label every product decision as a concept, Parliament position, Council position, or later final law. The Commission presented its proposal on June 28, 2023; the Council adopted its general approach on December 4, 2024. The Parliament adopted its negotiating mandate in the ECON Committee on December 4, 2024, followed by plenary confirmation on December 18, 2024. Negotiations are ongoing. European Commission: Framework for financial data access European Parliament: Legislative Train Schedule

The core of the discussion is bigger than just another consent dialogue. The Commission's proposal aims to create a framework for secure access to customer data in the financial sector beyond payment accounts. The Parliament's position extends access to data processed by financial institutions across the entire financial sector. This includes, among others, data on loans, savings, investments, pensions, and non-life insurance; data on sickness and health coverage are to be excluded under the Parliament's mandate. European Commission: Framework for financial data access European Parliament: Legislative Train Schedule

For banks, insurers, asset managers, and data users, this shifts the design question: Not just "Can an interface provide data?", but "Does the customer understand at all times what is happening with their data?" A permission dashboard must therefore not be a compliance appendix. It must become the customer interface through which data access can be clearly explained, granted, monitored, and terminated.

Four levels that must not be mixed up

The starting point is the Commission's proposal. It describes the possibility, but not the obligation, for customers to share data with data users. At the same time, it provides that data holders make data available via the required technical infrastructure, provided customer permission is granted. The proposal also speaks of control over who accesses data and for what purpose, as well as standardized customer data and technical interfaces. This is the Commission's architectural intent, not current FiDA law. European Commission: Framework for financial data access

The European Parliament's mandate clarifies this direction for the interinstitutional negotiations. Access should be based on the explicit permission of the customer. Data users would have to state what they intend to do with the data. Sharing with third parties without permission would not be permitted; consent should be revocable at any time and free of charge. In addition, the mandate calls for contractual liability arrangements among members of financial data sharing schemes and compensation for customers in the event of misuse, including unauthorized sharing with third parties. European Parliament: Legislative Train Schedule

In its general approach, the Council largely supports the Commission's basic approach but proposes a phased implementation and wants to grant flexibility to member states. The Council's position is not a final timeline. Concrete final deadlines should therefore not be treated as fixed in either roadmaps or customer information. European Parliament: Legislative Train Schedule

Only the legal text agreed in the trilogue and subsequently formally adopted can define the final obligations. Until then, projects must work with versions: what comes from the proposal, what from the Parliament mandate, what from the Council position, and what is merely an internal operational or service goal? This labeling prevents forward-looking product work from appearing as an anticipated legal claim.

Permission is an explainable customer mandate

Good permission management does not translate access into legal platitudes, but into a comprehensible customer mandate. It starts with a concrete purpose. If a customer is to share data for a financial overview, a comparison, or advice, this purpose must be visible in their language. The Parliament's position explicitly requires data users to state what they intend to do with the data. For design, this means: the purpose does not belong in a long privacy notice, but in the moment of decision. European Parliament: Legislative Train Schedule

Just as important is the scope of data. "Financial data" is not a useful explanation for an individual. The dashboard should therefore clearly show which data areas are being requested for which service. In a framework that is intended to extend beyond payment accounts, this classification is particularly important: data on a loan, an investment, or an insurance policy can trigger different expectations. The concrete scope depends on the later legislation and the respective consent; the interface should not obscure these differences. European Commission: Framework for financial data access European Parliament: Legislative Train Schedule

A permission also needs a clear recipient. Customers should see which data holder is providing data and which data user is to receive it. If other parties play a role, this must not become an invisible chain: the Parliament's mandate stipulates that data may not be transferred to third parties without permission. This is a strong argument for a display that not only names recipients during initial contact but makes them findable again later in the status area. European Parliament: Legislative Train Schedule

The necessary time dimension consists of two parts: the duration of an active permission and the possibility of revocation at any time and free of charge, as demanded by the Parliament's mandate. An interface should therefore not create the impression of a final consent. It should make it clear whether access is requested, active, revoked, or ended, and whether an action is pending. This status logic is a product principle, not a claim about the final technical implementation of FiDA.

Designing the dashboard as a service area

Those who think of permission only as proof of control easily build a list of consents that is technically correct but hardly usable for customers. In everyday life, a customer interface answers six questions: What is the access used for? Which data is included? Who receives it? How long is the access valid? What is its status? And how can I end it? This information belongs together because together they convey the control over data access that the proposal and the Parliament's mandate provide for in varying depths. European Commission: Framework for financial data access European Parliament: Legislative Train Schedule

Revocation also needs a customer-friendly design. "Revoked" is not a complete process if it remains unclear afterwards whether access has been terminated, what happens to the connected service, and where help can be found. The target state should therefore provide for a confirmation, a visible status change, and clear service information. What data retention or follow-up processes the final legislative act will require remains open; however, communication must not obscure the revocation.

Standardization must reach the customer experience

The Commission identifies the standardization of customer data and the required technical interfaces as part of the proposed framework. This is not just a back-office task. Standards can only fulfill their purpose when customers recognize recurring information across different offerings: purpose, scope of data, recipient, permission status, and revocation should not be explained completely differently every time. European Commission: Framework for financial data access

This does not mean that all interfaces must look the same. It means that the same questions are reliably answered. A product team can define a business permission object that maintains the same core elements for the app, web, contact center, and back-office processing. The interface remains understandable; operational teams see the same context. A clear distinction is crucial: this object is an internal target concept, not the claim that FiDA already prescribes a concrete data standard or a specific dashboard.

The Parliament's position also contains the proposal that the European Banking Authority should establish registers of authorized Financial Information Service Providers as well as registers of financial data sharing schemes agreed between data holders and data users. For later design, this can offer guidance on roles and access. However, as long as the negotiations are not concluded, it should not be planned as an already available or conclusively defined source of verification. European Parliament: Legislative Train Schedule

Do not hide liability behind the interface

Permission management is not just a matter of transparency. The Parliament's mandate provides for contractual liability rules for potential data protection violations among scheme members and compensation in the event of data misuse. Especially important: the mentioned compensation also covers the case of a data transfer to third parties without explicit permission. This remains a position of the Parliament for the trilogue, not an active FiDA rule. European Parliament: Legislative Train Schedule

For the operating model, this supports keeping permission events clearly traceable: Who requested what access? What purpose and scope were shown? When was permission granted, changed, or revoked? Through which channel did the interaction take place? Such questions are not legal advice and do not anticipate future rules of evidence. However, they help ensure that business, data protection, service, and risk functions talk about the same process in the event of a problem.

The management task is thus clearly outlined. Companies today should build a core permission lifecycle capability without translating a legislative text that has not yet been passed into binding customer promises. Anyone who plans purpose, scope of data, recipient, duration, revocation, status, and service as a coherent customer interface is better prepared for various negotiation outcomes. And those who consistently map each requirement to its source remain legally sound in the present.

Illustration: AI-generated. AI-supported content: We use AI technologies and automated agents, including those from Microsoft, Google, OpenAI, Anthropic, and other providers, to create our posts. Topics, professional orientation, and final approval remain with our team.