FiDA in Trilogue: Why Permission Management Becomes a Customer Interface

FiDA is not adopted law. The Financial Data Access framework remains in trilogue between the European Parliament, the Council and the Commission. Institutions should therefore avoid both extremes: treating a future rulebook as if it were already binding, or postponing all preparation until the legislation is complete. The practical task lies between them: build a sound target state for permission management and label every design choice clearly as a Commission proposal, Parliament position, Council position or possible future law. The Commission presented its proposal on 28 June 2023. The Council adopted its general approach on 4 December 2024. Parliament's ECON committee adopted its negotiating mandate on the same date, and plenary confirmed it on 18 December 2024. Negotiations continue. European Commission: Framework for financial data access European Parliament: Legislative Train Schedule

This is a wider question than adding another consent screen. The Commission proposal is intended to enable secure access to customer data across financial services beyond payment accounts. Parliament's mandate addresses data processed by financial institutions across the financial sector. Its scope is discussed in connection with loans, savings, investments, pensions and non-life insurance; Parliament's mandate would exclude sickness and health-cover data. European Commission: Framework for financial data access European Parliament: Legislative Train Schedule

For banks, insurers, wealth managers and data users, the design question therefore changes. It is not simply, “Can an interface make data available?” It is, “Can the customer understand at any time what is happening to their data?” A permission dashboard should not be a compliance appendix. It should be a customer interface through which a data-access request is explained, granted, monitored and ended.

Keep the four legislative layers separate

The Commission proposal is the starting point. It sets out the possibility, but not the obligation, for customers to share their data with data users. It would also require data holders to make data available through the required technical infrastructure when customer permission exists. The proposal refers to customer control over who accesses data and for what purpose, and to standardisation of customer data and the required technical interfaces. This is the Commission's proposed architecture; it is not FiDA law in force. European Commission: Framework for financial data access

Parliament's negotiating mandate makes that direction more specific for the interinstitutional process. Access should rest on the customer's explicit permission. Data users would have to state what they intend to do with the data. Data could not be transferred to a third party without permission, and consent could be withdrawn at any time and free of charge. The mandate also calls for scheme members to agree contractual liability for potential data breaches and for customer compensation where data is misused, including transfer to a third party without explicit permission. European Parliament: Legislative Train Schedule

The Council's general approach broadly supports the Commission's initial proposal, while suggesting phased, step-by-step implementation and flexibility for Member States. That position is not a final timetable. Specific final deadlines should not be presented as fixed in either delivery plans or customer communications. European Parliament: Legislative Train Schedule

Only a text agreed in trilogue and then formally adopted can define final obligations. Until then, programmes need version discipline: what comes from the Commission proposal, what comes from Parliament's mandate, what comes from the Council position, and what is simply the organisation's service or operating objective? That distinction keeps forward-looking product work from becoming an unsupported legal claim.

Permission is a customer instruction that must be understood

Good permission management does not translate access into generic legal wording. It translates it into an understandable customer instruction. It starts with a specific purpose. If a customer is asked to allow data use for a financial overview, comparison or advice service, that purpose needs to be visible in the customer's own terms. Parliament's position specifically requires data users to say what they intend to do with the data. The purpose therefore belongs at the decision point, not only in a long privacy notice. European Parliament: Legislative Train Schedule

The data scope is equally important. “Financial data” is not a useful explanation for an individual. A dashboard should show clearly which data domains are requested for which service. In a framework expected to extend beyond payment accounts, this distinction matters: data about a loan, an investment or an insurance policy can create different expectations. The eventual legal scope and each permission will determine the detail, but the interface should not conceal the difference. European Commission: Framework for financial data access European Parliament: Legislative Train Schedule

A permission also needs a named recipient. Customers should be able to see which data holder provides the data and which data user is intended to receive it. If other parties are involved, that must not become an invisible chain: Parliament's mandate says that data could not be transferred to a third party without customer permission. This is a strong reason to show recipients not only in the first request, but again in the persistent status view. European Parliament: Legislative Train Schedule

The time dimension has two parts: the duration of an active permission and the ability to withdraw consent at any time and free of charge, as Parliament proposes. An interface should not suggest that a permission is permanent. It should make clear whether access is requested, active, withdrawn or ended, and whether the customer needs to take an action. That status model is a product principle, not a claim about FiDA's final technical design.

Design the dashboard as a service surface

When permission is treated only as evidence of a control, the likely result is a list of approvals that may be accurate but is hard for a customer to use. A customer interface answers six everyday questions: What is access used for? Which data is included? Who receives it? How long does it apply? What is its status? How can I end it? These items belong together because they give practical meaning to the customer control described, with different levels of detail, in the proposal and Parliament's mandate. European Commission: Framework for financial data access European Parliament: Legislative Train Schedule

Withdrawal also needs to work as a customer process. “Withdraw” is not a complete journey if the customer cannot tell whether access has stopped, what happens to the connected service, or where help is available. The target state should therefore provide confirmation, a visible status change and clear service information. The final legislation may settle retention and follow-on requirements differently; that uncertainty is no reason to make withdrawal obscure.

Make standardisation visible in the customer experience

The Commission identifies standardisation of customer data and the required technical interfaces as part of the proposed framework. This is not simply a back-office concern. Standards deliver value when customers recognise recurring information across services: purpose, data scope, recipient, permission status and withdrawal should not be explained in an entirely different way every time. European Commission: Framework for financial data access

Parliament's position also proposes that the European Banking Authority establish a register of authorised financial information service providers and a register of financial data access schemes agreed between data holders and data users. That may later provide useful orientation on roles and arrangements. While negotiations remain unfinished, it should not be treated as an already available or fully defined source of checks. European Parliament: Legislative Train Schedule

Do not hide liability behind the interface

Permission management is not only a transparency issue. Parliament's mandate proposes contractual liability arrangements for potential data breaches among scheme members and compensation for customer data misuse. Crucially, that compensation would also cover transfer to a third party without explicit permission. This remains Parliament's position for trilogue, not a FiDA rule currently in force. European Parliament: Legislative Train Schedule

For the operating model, that supports keeping permission events traceable: who requested access; what purpose and scope were presented; when was permission granted, changed or withdrawn; and through which channel did the interaction occur? These are not legal advice or a prediction of future evidentiary rules. They do help business, privacy, service and risk teams discuss the same sequence when a problem occurs.

The executive task is therefore focused. Organisations can build a central permission-lifecycle capability now without translating an unadopted legislative text into binding customer promises. Those that plan purpose, data scope, recipient, duration, withdrawal, status and service as one customer interface will be better prepared for different legislative outcomes. Those that keep every requirement tied to its source will remain precise in the present.

Illustration: AI-generated. AI-assisted content: We use AI technologies and automated agents in the creation of our articles, including from Microsoft, Google, OpenAI, Anthropic and other providers. Topics, editorial direction and final approval remain with our team.