FAQs on the digital euro pilot

Updated on 8 May 2026

Pilot overview

Roles and responsibilities

Participation and application process

Preparation and development

Pilot payment services

Technical aspects

Pilot overview

Q1 What is the digital euro pilot?

The digital euro pilot is a limited practical exercise to help the Eurosystem learn how a digital euro could work in everyday situations. The pilot will help the Eurosystem assess its technical, operational and user readiness for a potential digital euro by validating the infrastructure in real-life conditions and gathering evidence to inform future decisions.

It will give the Eurosystem hands-on insights by enabling a limited group of individual end users (Eurosystem staff) and business end users (e.g. merchants) to make and receive payments using a beta version of the digital euro. During the pilot, an ECB staff member could use the beta digital euro to send money to a colleague, pay at the ECB canteen using their phone, or buy an item online to participating merchants, while the Eurosystem monitors the process and collects and provides feedback about their experience. This will support an assessment of the system’s robustness, scalability, and usability, and strengthen cooperation between payment service providers (PSPs), merchants, and central banks.

The pilot will also help the Eurosystem to refine the digital euro design and user experience and to assess communication and branding approaches. Updates will be communicated transparently, reflecting the Eurosystem’s commitment to building trust by preparing responsibly for the potential introduction of a digital euro, should a decision to issue be taken in the future.

Q2 Does the digital euro pilot mean that the ECB has decided to issue a digital euro?

No. Preparing for the digital euro pilot does not pre-empt any decision to issue the digital euro. The ECB will only take a decision on whether to issue the digital euro once the EU co-legislators adopt the Regulation on the establishment of the digital euro (digital euro Regulation).

In the current phase of the digital euro project, the Eurosystem is continuing to prepare for the potential introduction of a digital euro, following a flexible approach to ensure alignment with the legislative process. The pilot will ensure that the Eurosystem is technically and operationally ready to act efficiently and effectively when the legislative process concludes.

Q3 How would a beta digital euro differ from the digital euro?

The pilot will use a digital means of payment referred to as the “beta digital euro” that is different from the digital euro foreseen in the legislation.

The beta digital euro will be a digital means of payment issued by the Eurosystem central banks upon receipt of funds from pilot PSPs, leading to the creation of Eurosystem liabilities vis-à-vis third parties. It will be a liability (representation of value in the books of the Eurosystem) subject to the rules for cashless payment transfers applicable to PSPs, individual end users, and business end users. As regards the online beta digital euro exclusively, it will be considered as “scriptural money,” falling under the current definition of “funds,” under the revised Payment Services Directive (including relevant level 2 legal acts). It will not be a banknote and/or a coin, and it will not constitute an account held directly with the ECB or any other Eurosystem central bank.

Participants would hold or open a commercial bank money account with participating payment service providers (pilot PSPs) for the duration of the pilot.

Q4 What is the timeline for the digital euro pilot?

The envisaged timeline for the digital euro pilot consists of the following three phases.

1. Pilot preparation phase (first half of 2026): the call for expression of interest was published on 5 March 2026. PSPs must submit their applications by 14 May 2026. Additional relevant documentation will be provided to PSPs during the application window, including user journeys, end-to-end flows, functional requirements, and the PSP participation agreement. The ECB and participating national central banks (NCBs) will evaluate PSP applications and notify applicants of the selection outcome by the end of June 2026.
2. Pilot development phase (starting in the third quarter of 2026): after signing the PSP participation agreement, pilot PSPs will start preparing for their participation in the pilot. This entails the development of pilot payment services, digital euro service platform (DESP) onboarding and integration, user testing and back-end certification, and the onboarding of end users.
3. Pilot operational phase (starting in second half of 2027, 12-month duration): once the pilot becomes operational, pilot PSPs will provide pilot payment services in close cooperation with the ECB and their national central bank (NCB) counterpart. Their tasks will include onboarding end users, processing operational transactions for specific use cases and facilitating the collection of feedback from end users for assessment by the ECB.

Throughout all phases of the pilot, the ECB and participating NCBs will actively engage with pilot PSPs to collect feedback, clarify requirements, and ensure adequate support.

Q5 Which phases are covered by the PSP participation agreement, and in which phase will the 12-month pilot take place?

The PSP participation agreement covers both, the pilot development and the pilot operational phase (see Q4). In Art. 4 (3) it states that the pilot will be carried out over a period of 12 months "in accordance with the dates set out in the PSP Pilot Documentation Package" which shows that the twelve-month period corresponds to the operational phase.

Q6 Can PSP participation in the six-month extension of the pilot be made optional or subject to PSP agreement?

The PSP participation agreement establishes that the contracting national central bank may, at its discretion, extend the duration of the pilot by up to six months. This will provide operational flexibility to allow sufficient time to complete testing and validation activities, incorporate feedback, and help ensure a robust outcome. At the same time, the termination provisions under the participation agreement continue to apply during any extension period, ensuring that PSPs retain the ability to terminate the agreement under the agreed conditions.

Q7 What is the geographical scope of the digital euro pilot?

The pilot will take place on-site at the ECB and at participating NCBs across the euro area. All interested PSPs are encouraged to apply to participate in the pilot. The Eurosystem welcomes a broad geographical distribution of participants. Pilot PSPs must sign a PSP participation agreement with the NCB of a country where their headquarters or a legally established subsidiary is located.
There are two possible ways to do this.

• A parent company PSP (which owns or controls subsidiary companies) may sign the agreement with the participating NCB in the country where it is established and subsequently provide services to pilot end users across the euro area under the passporting regime (which allows PSPs authorised in the euro area to operate across all euro area countries).
• Each subsidiary PSP may sign a PSP participation agreement with the respective participating NCB in the country where the subsidiary is established and will operate during the pilot.

Provided pilot PSPs are authorised to operate in that country, this set-up enables cross-border participation, allows pilot PSPs to provide pilot payment services to individual end users (Eurosystem staff) in locations other than at the site of the NCB with which they have signed the participation agreement.

Q8 What payment use cases will the digital euro pilot cover?

The pilot will validate four use cases:

• Online P2P transactions using a user alias^[1] or DEAN^[2]: a payer transfers funds to a payee (both are individual end users), initiating the transaction by entering the unique identifier of the payee in the payment application. The transaction typically takes place remotely and can be completed when the payer and payee are not in physical proximity. The transaction is completed when the payer’s device is connected to the internet. Therefore, it is classified as an online payment.
• Offline P2P transactions via NFC: a payer transfers funds to a payee (both are individual end users), initiating the transaction by entering the amount in the payment application on the payer’s device without the need for either device to be connected to the internet. The transaction is completed in a proximity set-up via NFC by tapping the two devices together. Since the transaction is settled instantly between the participating devices and does not require an internet connection, it is classified as an offline payment. For additional details see Q60 – Q66.
• Online P2B transactions at the point of sale via NFC: a payer (individual end user) transfers funds via their payment application to a payee merchant (business end user) as payment for goods or services at the point of sale. The payee is equipped to accept payments via a SoftPOS^[3] application on their device. The transaction is initiated when the amount is entered in the SoftPOS application, either automatically by the cashier system or manually by the payee. The transaction is completed by tapping the devices of the payer and the payee together, allowing the transaction details to be exchanged between the devices via NFC. Since both devices must be connected to the internet for the transaction to be completed, it is classified as an online payment.
• Online P2B transactions in e-commerce or m-commerce using a user alias or DEAN: a payer (individual end user) transfers funds to a payee (business end user) as payment for goods or services on an e-commerce or m-commerce platform. The transaction is initiated when the payer selects the beta digital euro as the payment method on the payee’s mobile website or payment application. If available, the default payment application opens via overlay (seamless embedded app-to-app redirect). If no default payment application has been defined, the payer inserts their unique identifier (alias or DEAN) in the payment gateway provided by the payee and is prompted to open their payment application. In both cases, the payer verifies the payee and payment details and then confirms, authenticates, and authorises the transaction. The payer receives confirmation of the payment in their payment application and on the payee’s mobile website or payment application. The transaction is completed via the internet. Therefore, it is classified as an online payment.

Q9 The call for expression of interest refers to four prioritised use cases, while the PSP participation agreement includes “online business-to-person (B2P) refund transactions” under online P2B use cases. Does this mean a new prioritised use case has been introduced?

No. The inclusion of “online business-to-person (B2P) refund transactions” in the PSP participation agreement does not introduce a new standalone prioritised use case.

The call for expression of interest refers to four prioritised use cases (see Q8). Refund transactions are part of the existing payment flows, in particular those linked to person-to-business (P2B) use cases, and are already required under applicable regulatory frameworks such as PSD2 (see Q13).

The inclusion of B2P refund transactions in the PSP participation agreement is intended to provide additional clarity on the scope of the pilot. They should therefore be understood as part of the existing P2B use cases rather than as an additional prioritised use case.

Roles and responsibilities

Q10 What is the role of pilot PSPs in the digital euro pilot?

As key partners of the Eurosystem during the pilot, pilot PSPs will enable pilot payment services for end users and support the collection of feedback. The pilot distinguishes between two PSP roles: distributing and acquiring. Each pilot PSP will fulfil one or both of these roles.

• Distributing PSPs will enable individual end users to use pilot payment services – such as access, liquidity, and transaction management – through the Eurosystem-provided digital euro app or via integration in the PSP’s proprietary app.
• Acquiring PSPs will enable business end users (merchants) to use pilot payment services, including access, liquidity and transaction management and payment acceptance functionalities. For example, they may be asked to offer a SoftPOS solution and/or an e-commerce/m-commerce solution to enable the acceptance of beta digital euro by merchants.

The Eurosystem provides the digital euro service platform (DESP)^[4] and enables pilot PSPs to connect to it during the pilot, ensuring end-to-end product testing and validation of the value proposition. Pilot PSPs will gain first-hand experience of the beta digital euro ecosystem and provide feedback that will help to further shape its technical specifications.

Q11 What are the roles of the ECB and euro area NCBs in the digital euro pilot?

The ECB is coordinating the digital euro pilot at the Eurosystem level, with euro area NCBs acting as the main operational counterparts for pilot PSPs at the national level.

During the pilot, participating NCBs will, with support from the ECB:

• provide pilot PSPs with the documentation (e.g. technical specifications, user journeys) necessary to develop and release pilot payment services for the use cases covered in the pilot;
• facilitate liquidity operations related to the digital euro pilot on behalf of their pilot PSPs;
• collect feedback from pilot PSPs and support their collection of feedback from end users.

Q12 Who is eligible to participate in the digital euro pilot as an individual end user or a business end user (merchant)?

The individual end users in the digital euro pilot will be members of staff from participating Eurosystem central banks. To be eligible to take part, they must be or become a customer of a pilot PSP.

Merchants (both in-store and e-commerce/m-commerce) are eligible to participate in the digital euro pilot if they have both:

• a contractual relationship with the ECB or a participating NCB for the duration of the pilot;
• a contractual relationship with a pilot PSP for acquiring services.

Q13 Which regulatory requirements apply to PSP activities in the pilot?

During the pilot and in relation to the beta digital euro and the provision of related payment service, pilot PSPs will be subject to existing laws and regulations applicable to for example, the provision of payment services and payment service providers, including (but not limited to) Directive (EU) 2015/2366 of the European Parliament and of the Council (Payment Services Directive 2), Regulation (EU) 2016/679 of the European Parliament and of the Council (General Data Protection Regulation) and Regulation (EU) 2024/1624 of the European Parliament and of the Council (Anti-Money Laundering Regulation).

While this existing regulatory framework applies to the pilot, as specified in the PSP participation agreement, it is fully acknowledged that the pilot activities are designed to take place within a controlled and highly limited environment, for a restricted period of time, restricted to staff from participating Eurosystem central banks and a selected group of merchantsand testing a limited set of use cases. Given the controlled setting and distinct features of the pilot, the most appropriate approach to achieving its objectives is under exploration, with relevant stakeholders.

Q14 Are PSPs expected to bear liability towards end users during the pilot? How is liability allocated between PSPs and NCBs?

The pilot is an opportunity for PSPs to test the operational and technical readiness of the beta digital euro, which would also entail liability towards end users. 

Pilot PSPs remain responsible for their relationships with end users and for complying with all applicable legal and regulatory obligations arising from the provision of payment services during the pilot. Liability towards end users remains governed by the pilot PSPs’ own terms and conditions and by the applicable legal and regulatory framework (see Q13).

Between the pilot PSP and the participating national central bank (NCB), the PSP participation agreement establishes a liability regime under which each party is liable only for losses resulting from its wilful misconduct (including fraud) or gross negligence. As provided for in the agreement, if liability-related issues arise, the initial approach is to engage in dialogue with the aim of finding an amicable solution.

Q15 Who is responsible for drafting the terms and conditions for end users during the pilot – the Eurosystem or pilot PSPs?

Pilot PSPs are responsible for their contractual arrangements with pilot end users, including any terms and conditions required for the provision of pilot payment services during the pilot, in line with the PSP participation agreement.

PSPs may use their existing customer documents (e.g. terms and conditions) and adapt them as necessary for participation in the pilot, taking into account the requirements applicable to the pilot. This includes the requirement that end users must not be charged fees for pilot payment services (see Q17).

Q16 During the pilot, are pilot PSPs required to store data and customer activity? What data retention requirements apply, including after user offboarding?

Pilot PSPs remain responsible for complying with all applicable legal and regulatory requirements relating to data processing, record-keeping, and retention in connection with their participation in the pilot. This includes, where applicable, obligations under payment services, anti-money laundering, and data protection legislation.

Pilot PSPs should apply their existing legal and regulatory retention obligations, as well as their internal policies, unless more specific instructions are communicated during the pilot. This also applies in relation to data retained following user offboarding.

Q17 Can a PSP charge fees to end users for pilot payment services?

No. As defined in the PSP participation agreement, pilot PSPs will bear their own costs and may not charge participating end users, whether merchants or consumers, any fees for the provision of pilot payment services. This does not prevent PSPs from charging for services unrelated to the pilot in accordance with their usual terms and conditions.

Following the end of the pilot, the customer relationship may continue subject to agreement between the pilot PSP and the end-user.

Q18 If an end user opens an account with a PSP specifically for the pilot, do they need to be offboarded after the pilot?

No. End users will not have to be offboarded from the pilot PSP once the pilot concludes. They need to be offboarded (e.g. closing of the beta digital euro account) from the pilot once the pilot phase is concluded. For end users who already had an account with the pilot PSP before the digital euro pilot, the existing relationship will continue. For end users who opened an account specifically for the pilot whether the account remains open or is closed after the pilot is at the discretion of the end user and the pilot PSP in question, in line with their contractual arrangements. After the pilot ends, any ongoing relationship between the end user and the PSP would relate only to the PSP’s (non-pilot) services.

Participation and application process

Q19 Why should PSPs participate in the digital euro pilot?

Participation in the pilot offers PSPs an opportunity to actively contribute to shaping the future of payments in Europe, and to engage directly with the Eurosystem’s operational and technical teams.

The pilot provides first-hand experience with the beta digital euro, which can support PSPs’ preparation for a potential roll-out of the digital euro and enable them to develop value-added services as first-movers.

Pilot PSPs will gain early operational experience with the envisaged set-up for providers of digital euro services, including onboarding, settlement, liquidity management, incident handling, and refunds, and will be able to identify practical implications for their systems, processes, and resourcing.

Participation also provides a structured channel to share evidence-based feedback on how the digital euro infrastructure and prioritised use cases perform in real-life conditions, helping inform potential improvements. In addition, pilot PSPs will be well placed to suggest ways to optimise implementation choices (e.g. integration approach, use of existing components and partners, internal vs. external development), which can help manage costs, compliance, and capacity needs.

The pilot has already attracted interest from a range of PSPs, many of which joined the focus sessions in January and March, underlining the market relevance of the project.

Q20 How many use cases must a PSP support to participate in the pilot, and can PSPs apply for multiple roles with support from technical service providers?

The overall scope of the pilot covers four prioritised payment use cases (see Q8). Pilot PSPs are expected to support the use cases relevant to the role they apply to:

• Distributing PSPs are expected to support both P2P use cases and the distribution activities (i.e. enabling individual end users to use pilot payment services) of the P2B use cases.
• Acquiring PSPs are expected to support both of the P2B use cases.
• PSPs applying for both the distributing and the acquiring PSP roles are expected to cover all relevant use cases within the scope of the pilot.

A PSP may rely on technical service providers (TSPs) (see Q21) for certain functions (e.g. acquiring services). In that case, the PSP remains the formal applicant and, if selected, the formal pilot participant. The application should cover all the services the PSP intends to provide in the pilot.

Q21 What is considered to be a technical service provider (TSP) in the context of the digital euro pilot, and which types of entities may act as TSPs?

In the context of the digital euro pilot, a technical service provider refers to a third-party entity that supports a participating PSP in developing, integrating, operating, or providing pilot payment services. TSPs may provide a wide range of technical or operational services, depending on the PSP’s delivery model. These can include technical integration with the PSP’s systems, wallet, and front-end solutions; merchant acceptance and POS infrastructure; payment processing services; as well as optimisation of cross-border and offline payment functionalities. TSPs may include payment processors, IT service providers, software vendors, system integrators, or consultancies supporting implementation and integration activities.

Q22 Will there be a separate selection process or dedicated call for technical service providers (TSPs)?

No. There is no separate selection process or dedicated call for TSPs. Participation in the pilot is limited to PSPs, which remain the sole applicants and the sole entities evaluated and contracted (see Q27). PSPs may rely on TSPs as part of their delivery model (see Q20 and Q21), but this does not affect the evaluation or selection process. Where PSPs outsource or rely on third parties, they can indicate this in the relevant sections of the questionnaire (e.g. under Miscellaneous, M.1). This information is collected for information purposes only and is not assessed as part of the evaluation. The PSP remains fully responsible for meeting all requirements and obligations under the pilot.

Q23 How can PSPs apply to participate in the digital euro pilot? 

To apply, PSPs are required to complete a questionnaire (published as Annex 2 to the call for expression of interest) and submit it to the Eurosystem together with any evidence needed to support their application. The call and the related documentation are published on the digital euro pilot web page.

The application window opened with the launch of the call for expression of interest on 5 March 2026. Applications must be submitted to digitaleuro-pilot@ecb.europa.eu by 17:00 CEST on Thursday, 14 May 2026.

Q24 Are there specific eligibility requirements for pilot PSPs? How will PSP applications be assessed?

Yes. The Eurosystem will assess all applications based on two defined sets of selection criteria: eligibility requirements and weighted evaluation criteria. These are set out in Annex 2 to the call for expression of interest.

The eligibility requirements ensure that only PSPs with the necessary regulatory license and technical and operational capabilities are eligible to proceed to the weighted evaluation stage. PSPs that do not meet all the eligibility requirements will not be considered for selection.

The weighted evaluation criteria assess eligible PSPs based on factors that are relevant to achieving the objectives of the pilot, in order to ensure that the pilot has comprehensive coverage (for example, in terms of geographical footprint, use cases and end users). PSPs are not required to meet all the weighted evaluation criteria to be considered for selection.

Q25 Can PSPs operating outside of the euro area participate in the digital euro pilot?

Yes, PSPs operating outside the euro area are eligible to take part in the digital euro pilot, provided they are authorised to operate in the euro area. Specifically, PSPs must hold a valid EU licence to provide payment services under the revised Payment Services Directive (PSD2) as a credit, electronic money, or payment institution, in accordance with applicable regulatory frameworks.

Pilot PSPs must sign a PSP participation agreement with the NCB of a country where their headquarters or a legally established subsidiary is located (see Q7).

Q26 How should PSPs operating in multiple countries apply for the pilot?

PSPs should submit one application indicating all the countries where they are licensed (see Q7) and wish to offer pilot services. This is explained in Annex 2 – questionnaire, under weighted evaluation criteria W.2, which covers PSP presence in the participating euro area countries.

Q27 Can PSPs submit joint applications or apply as a joint venture?

No. Joint applications and joint ventures are not permitted. Organisations wishing to participate in the digital euro pilot together should instead designate one PSP as the official applicant. This PSP would submit the application and, if successful, act as the formal participant in the pilot. The other organisation(s) would act as technical service providers (TSPs), PSPs should indicate the services which are outsourced or supported by third parties in the relevant sections of the application questionnaire (e.g. under Miscellaneous, M.1).

For example, if a distributing PSP relies on a third party to provide specific services, such as infrastructure services or a front-end solution, the distributing should submit the application covering the services it intends to provide in the pilot, including those delivered with support from that third party, even if under their existing contractual arrangement, the third party would be considered a technical service provider (TSP) for the purposes of the pilot. This also includes cases where a distributing PSP relies on a third-party front-end solution (e.g. an external wallet or payment app) to provide certain user-facing functionalities (see Q20 and Q21)

Q28 How are consortium arrangements (e.g. those involving TSPs) considered in the evaluation process, given that selection is based on individual PSPs?

The evaluation and selection process is based exclusively on individual PSP applications, which are assessed against the eligibility requirements and weighted evaluation criteria set out in the call for expression of interest. PSPs are expected to present the full scope of services they intend to provide in the pilot, including cases where certain functions (e.g. acquiring services) are supported or delivered with the involvement of TSPs (see Q21). This allows the Eurosystem to assess the PSP’s end‑to‑end capability to deliver pilot payment services. Consortium or joint applications are not permitted (see Q27). Where services are outsourced or supported by third parties, PSPs should indicate this in the relevant sections of the questionnaire (e.g. under Miscellaneous, M.1). These details are used for information purposes only and are not assessed separately; the PSP remains the sole entity evaluated and is fully responsible for meeting all requirements.

Q29 Can PSPs participate in the digital euro pilot via a direct contract with the ECB?

No. Pilot PSPs must sign the PSP participation agreement with a participating euro area NCB (typically the NCB of a country where they are established or operate under passporting). Once selected, and after signing the agreement, a PSP may provide pilot payment services on-site at the ECB (e.g. by ECB staff and participating merchants) as part of the overall pilot set-up.

Q30 How many PSPs will be selected for the pilot?

It is currently expected that about 10 to 30 PSPs will be selected to participate in the pilot, covering the whole euro area. The final number of pilot PSPs will depend on several factors, including the number of eligible applications received, the roles applied for, the prioritised use case and the geographical footprint. This is to facilitate a mix of pilot PSPs ensuring the set pilot objectives are met (validate readiness before scaling, improve digital euro value proposition, improve go-to-market strategy, and prepare for subsequent market rollout).

Q31 Can PSPs amend their application after submission or join the pilot after the deadline?

PSPs can amend their submitted application up until the deadline of 17:00 CEST on Thursday, 14 May 2026 and submit it to digitaleuro-pilot@ecb.europa.eu. No further changes or new applications will be accepted after this deadline. To participate in the pilot, PSPs must follow the application procedure set out in the call for expression of interest and apply within the designated application window.

Q32 When indicating the number of individual end users, should PSPs refer to their total customer base or only those expected to participate in the pilot?

When indicating the number of individual end users in the application, PSPs should refer to their total customer base. This provides a complete view of a PSP’s overall scale and market presence.

Q33 How should PSPs report resource estimates in their application? Should the indicated effort include contributions from technical service providers (TSPs), or only internal resources?

PSPs should provide resource estimates that reflect the overall effort required to support their participation in the pilot, including activities related to development, integration, testing and operations. PSPs should provide estimates for their internal resources in Annex 2 – questionnaire. Where relevant, a PSP may take into account contributions from TSPs, particularly where these are part of the PSP’s delivery model (see Q20).

Q34 What are the requirements for submitting supporting documentation as part of the application? How can they be submitted?

PSPs are required to complete and submit the application questionnaire provided as part of the call for expression of interest (Annex 2 – questionnaire). PSPs should use the “Explanation” column to provide supporting information, while respecting the character limit. PSPs are not expected to submit additional supporting documentation as part of the application. Applications must be submitted to digitaleuro-pilot@ecb.europa.eu by 17:00 CEST on Thursday, 14 May 2026

Q35 What does a “direct or indirect connection to TARGET Services” mean in the application questionnaire?

“Direct or indirect connection to TARGET Services” refers to whether a PSP has direct access to TARGET accounts or has such access via another institution, in line with the TARGET Guideline.

Direct connection means that the PSP holds its own TARGET accounts (e.g. a main cash account or a dedicated cash account). Indirect connection refers to arrangements where the PSP accesses TARGET Services through another participant.

Preparation and development

Q36 What will PSPs need to develop when participating in the digital euro pilot?

Pilot PSPs will develop pilot payment services for the priority use cases during the digital euro pilot. They will receive detailed documentation on several aspects of the envisaged set-ups for these use cases, including connectivity setup, requirements for front-end implementation, common services, and back-end infrastructure. While pilot PSPs are expected to develop pilot payment services independently, they will be able to contact the Eurosystem for technical clarifications and support. To ensure efficient development, pilot PSPs should decide on their implementation approach and plan delivery accordingly and are invited to cooperate with subcontractors such as TSPs (see Q20 and Q21).

Q37 If the pilot is intended mainly for learning purposes, does this mean PSP investments risk becoming sunk costs if the product is later redesigned? Which elements (e.g. onboarding, interfaces, DCA) could potentially carry over to the subsequent phase?

No. While the pilot is designed as a learning and validation exercise, efforts made by participating PSPs are not expected to become sunk costs. The Eurosystem aims to ensure that investments made for the purpose of the pilot can, where possible, be reused in subsequent phases. The extent to which pilot PSPs can reuse their investments will, however, depend on their individual implementation strategy and the final digital euro Regulation.

As reflected in the PSP participation agreement, pilot PSPs may continue using their digital euro infrastructure in a potential subsequent phase. The main elements, including technical interfaces to the digital euro service platform (DESP), are intended to remain stable over time, helping to ensure operational continuity and avoid duplication of effort. This approach benefits both participating PSPs and the Eurosystem.

Furthermore, the pilot builds on the work already undertaken for a potential digital euro issuance. This applies both to the Eurosystem infrastructure and to the documentation shared with participants, which is linked to the broader digital euro framework and on the work of the Rulebook Development Group. In addition, many specifications are being developed on the basis of publicly available European standards (see Q72 and Q73), supporting reusability beyond the pilot context.

Q38 What are the expected workload and costs for pilot PSPs? 

The workload and costs of participating in the digital euro pilot will be different for every pilot PSP and will depend on their individual business model, existing infrastructure, and internal cost structures. Key cost drivers may differ according to the level of integration required, the balance between internal and external development and the scope of the PSP’s participation in the pilot. The workload required may vary based on aspects such as the extent of system modularity, prior experience with comparable initiatives, and the scope of pilot activities chosen by the pilot PSP. Additionally, pilot PSPs are invited to cooperate with subcontractors such as TSPs to support their development efforts, as well as to leverage existing technical solutions. Pilot PSPs will bear their own costs related to their participation in the pilot and no subsidy is foreseen.

Q39 Will participating PSPs be remunerated?

No. Pilot PSPs will not receive any remuneration or incentives of any kind (financial or non-financial) from the Eurosystem for their participation in the pilot, and their expenses will not be reimbursed. The same applies to business end users and individual end users.

Q40 Can PSPs outsource pilot activities to third parties such as technical service providers (TSPs)?

Yes. PSPs may outsource certain pilot activities to third parties, including TSPs, to support their development, integration, or operational efforts (see Q21). Outsourcing may give pilot PSPs more organisational flexibility and provide a means to leverage specialised expertise or implement specific functionalities more quickly, through existing technical solutions and partnerships.

In line with the EBA Guidelines on outsourcing arrangements, the PSP remains fully responsible for fulfilling its role and obligations under the pilot (see Q41).

The ECB recognises the important role played by TSPs in the retail payments ecosystem and is engaging with them directly through dedicated workshops to facilitate their critical role during and after the pilot and to ensure market readiness.

Q41 Do third parties (e.g. TSPs) engaged by a PSP have any direct contractual or compliance obligations towards the ECB/Eurosystem, or does the PSP remain solely responsible?

Third parties, such as TSPs, do not have a direct contractual relationship with the ECB or the Eurosystem in the context of the pilot. The PSP remains the formal participant in the pilot, enters into the PSP participation agreement with the relevant participating euro area NCB, and is fully responsible for complying with all applicable requirements (see Q27). Any arrangements with third parties are managed by the PSP, which remains fully responsible for ensuring that all obligations under the pilot are met, in line with the EBA Guidelines on outsourcing arrangements.

Q42 Will authorised TSPs be allowed to send and receive data from the digital euro service platform (DESP) on behalf of pilot PSPs?

Yes, as PSPs may rely on TSPs to support the delivery of their services, TSPs will be allowed to send and receive pseudonymised data from the DESP on behalf of pilot PSPs. This may include payment-related data (e.g. for initiating a payment, confirming execution, or receiving status updates) or account-related queries (e.g. for retrieving balance or transaction history information). However, the pilot PSP remains fully responsible for all interactions with the DESP and for complying with the pilot requirements.

Q43 What is the scope of user testing and how will it be organised?

User testing will ensure that pilot PSPs achieve technical and operational readiness by the start of the pilot. It will focus on validating the onboarding process, the scope of the four prioritised use cases and the operational procedures.

A dedicated digital euro service platform (DESP) user testing environment will be made available to pilot PSPs. This environment will support all pilot payment services and functional requirements, with the scope expanding progressively as additional functionalities are introduced during the user‑testing period.

User testing will allow pilot participants to validate their integration with the DESP and to confirm that the functional requirements and end-to-end process flows can be executed as intended. The scope is therefore directly aligned with the functional requirements and the end-to-end flows that PSPs are expected to support throughout the pilot.

Pilot PSPs will receive a comprehensive testing plan covering onboarding, development activities, and user testing requirements. It will follow an iterative approach, with functionalities and use cases being progressively introduced and validated, allowing pilot PSPs and the Eurosystem to gradually test, refine and stabilise services before the start of the pilot.

User testing begins several months before the start of the pilot to allow PSPs to complete all onboarding and development activities, align internal processes to the functional requirements of the pilot, and identify and resolve issues. This will ensure a unified end user experience and that the pilot can be executed in a stable and reliable manner.

Q44 Will PSPs receive operational support during the pilot?

Yes. The ECB and participating NCBs will provide operational support to pilot PSPs during the pilot development phase and operational phase of the pilot, including with liquidity management. Additionally, all pilot PSPs will be connected to the overarching pilot exercise, together with all other participating NCBs and the ECB. More detailed information (including on onboarding, testing, and training) will be shared with pilot PSPs after the selection process.

Q45 What happens if a PSP is not ready by a given milestone in the pilot timeline?

Pilot PSPs will be supported by participating national central banks in working towards pilot milestones. Both parties will maintain close cooperation to facilitate the timely execution of pilot activities. Pilot PSPs are expected to meet the agreed milestones and timelines, including those related to development, onboarding, testing and operational readiness.

In some cases, issues may arise that affect a pilot PSP’s readiness to meet a specific milestone. Where this occurs, the pilot PSP is expected to inform the relevant national central bank as early as possible. The PSP participation agreement outlines the applicable next steps. Such situations are assessed on a case-by-case basis.

Q46 Can PSPs communicate publicly about their participation in the pilot?

Yes. PSPs may communicate publicly about their participation in the pilot, subject to the communication guidelines provided as an annex to the PSP participation agreement.

All communications, whether internal or external, should remain factual, neutral, and proportionate in scale. PSPs may state that they are participating in the pilot, describe their role and activities at a general level and refer to information made publicly available by the Eurosystem, including on ECB or National Central Bank websites, social media channels, and public statements.

However, PSPs may not present pilot activities as their own products, imply independent ownership or validation of pilot activities, suggest knowledge of Eurosystem decisions or preferential treatment, or use participation in the pilot as a marketing tool for other products or services. PSPs may also not disclose confidential, operational or technical information that has not been made public by the Eurosystem.

Where there is uncertainty as to whether a planned communication is appropriate, PSPs are strongly encouraged to consult their National Central Bank. Pilot PSPs should also inform the designated Eurosystem contact(s) before publishing any external communication that includes sensitive or potentially market-relevant information.

Q47 How are possible incidents involving multiple parties (for example a PSP, DESP or technical service providers) handled during the pilot?

Possible incidents involving multiple parties are assessed on a case-by-case basis and based on the roles and responsibilities defined in the respective contracts between parties. In particular: 

• The Pilot PSP and the NCB remain responsible vis-à-vis the counterparty for fulfilling their obligations under the PSP participation agreement
• Contractual liability between the Pilot PSP and the Participating NCB is governed by the PSP participation agreement
• The relationship between supporting technical service providers and pilot PSPs is expected to be governed bilaterally between those parties. 

The pilot PSP shall remain fully responsible and liable to the participating NCB regardless of any subcontracting. The origin of the issue and the fact-finding reports of the parties involved will also be taken into account. In all cases, the Parties are expected to cooperate, mitigate impacts, and seek amicable solutions wherever possible.

Q48 What are the operating hours of the PSP service desk during the pilot operational phase?

During the pilot, pilot PSPs are expected to organise their service desk support in alignment with both their own service model and the Eurosystem’s support arrangements.

The digital euro service platform (DESP) is designed to operate continuously 24 hours a day, 7 days a week, 365 days a year in order to support use cases such as online P2B transactions in e-commerce or m-commerce and P2P transactions at any time.

However, the DESP Level 0 service desk (the first-line support provided by the Eurosystem) will operate from 09:00 to 17:00 CET/CEST on TARGET working days.

Pilot PSPs are responsible for supporting their pilot end users through their PSP service desk. The operating hours of PSP service desks should be defined by each PSP according to its own service offering and terms and conditions (see Q15) with its end users.

The availability of the PSP service desk should be at par with the support they provide to their customers for similar payment services, while the minimum being the operating hours of the DESP Level 0 service desk.

Pilot payment services

Q49 What is the difference between alias and digital euro access number, and will a unique alias type be used across all PSPs during the pilot?

The digital euro access number (DEAN) is the unique identifier assigned to a beta digital euro payment account, which uniquely identifies the end user account within the PSP domain. It is created and assigned via the pilot PSP in interaction with the DESP when an end user is onboarded.

An alias is an alternative identifier that can be optionally linked to the DEAN and used as an additional means to access the beta digital euro account. It can be something familiar and easy to remember, like a phone number.

Q50 Why is only one alias per end user allowed, including where an end user may use multiple apps or channels, and will aliases be managed by the Eurosystem alias lookup service during the pilot?

For the pilot, the alias model is a pilot design choice focused on usability and operational simplicity. Hence, the current specifications foresee the mobile phone number as the only supported alias type for the pilot, reflecting a solution that is already widely used in existing payment services.
The digital euro pilot foresees the use of an alias look-up service to support the registration/ deregistration of aliases and their mapping to the corresponding DEAN. This same service will be used to retrieve the DEAN linked to an alias provided during a transaction, enabling the user’s account to be identified seamlessly.

The front-end and related specifications are designed to enable practical testing of core functionalities in a controlled pilot environment. Starting with a single alias per individual end user helps reduce complexity for onboarding, look-up, routing and lifecycle management during the pilot.

At the same time, the data model already includes an alias type field, which allows for the possibility of supporting additional alias types in subsequent phases.

Q51 Can an end user hold more than one beta digital euro payment account during the pilot?

No. Multiple accounts per end user are not in the scope of the pilot. Each end user will hold one beta digital euro payment account, identified by a unique DEAN.

Q52 Will there be holding limits in the digital euro pilot?

Yes, holding limits will apply during the digital euro pilot, as per digital euro design. The specific limits to be applied to the beta digital euro will be communicated closer to the launch of the pilot.

Q53 Will the waterfall and reverse waterfall functionalities be available in the digital euro pilot?

Yes, both functionalities will be in the scope of the digital euro pilot:

• Funding of online beta digital euro holdings from a linked commercial bank money account, the end user has with the pilot PSP, when the transaction amount exceeds the available holdings (reverse waterfall), and
• Defunding to a linked commercial bank money account when predefined holding limits are exceeded (waterfall).

Q54 Do PSPs need to connect with external banks to support waterfall and reverse waterfall functionalities and can end users configure thresholds for these functionalities?

No, as the pilot does not intend to test the open funding functionality, PSPs do not need to establish a separate connection with other PSPs specifically for waterfall and reverse waterfall functionalities. These functionalities are implemented as part of the pilot PSP’s integration with the DESP (see Q53). They rely on a commercial bank money account linked to the end user’s beta digital euro payment account (both accounts need to be with the same pilot PSP), while the processing of funding and defunding beta digital euro is handled via the DESP dedicated cash account.

End users cannot configure custom thresholds for waterfall or reverse waterfall funding. Users may enable or disable these functionalities, but they are triggered on the basis of predefined system conditions (e.g. insufficient balance or exceeding holding limits). These conditions are defined by the system design and are not configurable by end users.

Q55 Is blocking funds on the linked commercial bank account required before funding?

No. Blocking funds on the linked commercial bank account before settlement is not a mandatory requirement in the digital euro pilot.

The implementation of such mechanisms is left to each pilot PSP, which must ensure that these comply with the overall functional and operational requirements defined for the pilot.

Q56 How will digital euro service platform dedicated cash accounts (DESP DCA) be managed during the pilot – manually or automatically?

DESP DCAs are a dedicated settlement account in central bank money that will be used by pilot PSPs to process beta digital euro transactions during the pilot.

During the digital euro pilot, liquidity management of the DESP DCA will be executed manually.

Pilot PSPs will need to fund and defund their DESP DCA through manual transfers. Automated liquidity management features, such as floor- and ceiling-based transfers, are currently not envisaged for the pilot stage.

Q57 How will the beta digital euro be treated on pilot PSPs balance sheets?

The underlying mechanisms behind the balance sheet treatment of the beta digital euro work in a similar way to those of the digital euro. However, the beta digital euro is not the same as the digital euro (see Q3). When an end user funds their beta digital euro account from their commercial bank money account, the funds move off the pilot PSP’s balance sheet and onto the Eurosystem balance sheet. Likewise, when the user defunds their beta digital euro account, the funds leave the Eurosystem balance sheet and return to the pilot PSP’s balance sheet.

Q58 Will there be a compensation model in place for the digital euro pilot?

As specified in the PSP participation agreement Pilot PSPs will bear their own costs and no fees can be charged by pilot PSPs to participating end users (merchants/consumers) for the provision of pilot payment services in the context of the pilot.

Technical aspects

Q59 What connectivity options are available to pilot PSPs for the digital euro pilot and what do they entail?

For the digital euro pilot, pilot PSPs may connect to the DESP via VPN-based connectivity or dedicated lines. There are two possible options: 

• Virtual private network-based (VPN-based) connectivity creates a secure, encrypted connection over the internet (a “tunnel”) by using authentication and encryption technology. VPNs can be used for secure, remote access at low cost. For the digital euro pilot, participants would use the VPN to connect to a network service provider, which would enable them to connect to the DESP. 
• Dedicated lines-based connectivity consists of a private (i.e. not shared with other users and not internet-based) fixed connection between two locations provided by a telecom provider. Dedicated lines are used when there are strict performance and reliability requirements. 

Q60 How does the offline beta digital euro technically work, and how can PSPs integrate the offline functionality? 

Offline P2P transactions via NFC will be tested in the pilot. When these transactions are performed, the exchange will take place between the payer’s device and the payee’s device in proximity, without the need for to be connected to the internet. The transaction is completed via NFC by tapping the two devices together.

The offline beta digital euro has three main components (see digital euro pilot business architecture): 

• User domain - the mobile application running on the phone and using its secure element. 
• PSP domain - the software service running on the PSP's premises acting as the distribution component.
• Eurosystem domain - the issuance component running in the back-end of the Eurosystem. 

The mobile application (user domain) serves as the interface for individual end users. It can be the Eurosystem-provided digital euro app or integrated in the PSP’s proprietary app. If a pilot PSP chooses to integrate the beta digital euro into its own app, it will receive a software development kit (SDK) to streamline the integration process. For offline functionality, this mandatory SDK will handle interactions with the phone’s secure element and ensure secure communication with another phone or back-end system. 

The service running on the phone’s secure element (PSP domain), which enables the secure offline use of the beta digital euro, will be provided by the ECB. This removes the need for pilot PSPs to have expertise in developing secure element applications or to implement specific security measures, such as protection against double-spending. 

The distribution component serves as an intermediary between the phone and the Eurosystem back-end. It functions as a bridge, relaying direct requests from the mobile application, such as funding or defunding operations. It enables the pilot PSP to incorporate business logic, such as transferring funds from a user’s commercial bank account in case of funding the offline beta digital euro. The ECB will provide a technical specification and a reference implementation to facilitate the PSP’s integration of the distribution component.

The offline issuance component is responsible for funding/defunding offline beta digital euro holdings with commercial bank money or online beta digital euro. This funding/defunding service is hosted by the Eurosystem. 

Q61 What functionalities are provided by the digital euro app offline digital euro software development kit, and to what extent does it support the technical implementation?

The Eurosystem provides an SDK for both Android and iOS, to support pilot PSPs in integrating offline pilot payment services into their proprietary mobile applications.

The SDK can be embedded as a software library within a PSP’s mobile banking app. It is designed to simplify integration by providing the core functionalities required to interact with the Offline Wallet applet (secure element) and the Offline Distribution component for offline digital euro operations.

To support implementation, the SDK is delivered together with documentation, including API documentation and integration guides.

PSPs that choose to integrate pilot payment services into their own application must comply with the minimum UX requirements defined in the user journeys & minimum UX requirements document, ensuring a harmonised user experience across pilot participants.

These tools and specifications are intended to streamline integration and reduce the time and effort required during the pilot development phase.

Q62 What is a secure element and why is it needed for the offline beta digital euro? 

Secure elements are needed for the offline beta digital euro because offline transactions in the pilot are P2P transactions conducted in proximity between the payer’s device and the payee’s device via NFC, without an internet connection. In this context, the secure element is a hardware component that protects the transaction processing and the stored value on the device against tampering, extraction of sensitive data and other attacks. The processing of transactions within a secure element, such as debit or credit transactions, is protected and cannot be disrupted. Attackers are unable to extract sensitive data, such as cryptographic keys, or alter critical information, such as the balance of funds, stored within an eligible secure element. These secure elements come in various form factors, including embedded SIM (eSIM) and embedded Secure Element (eSE). 

Q63 What are the functional and operational differences between the offline beta digital euro and cash, and how are these reflected in the technical architecture and distribution model? 

The offline digital euro is meant to function like a digital equivalent of cash, offering similarities while incorporating distinct features. As is the case when withdrawing banknotes from an ATM, users must fund their offline beta digital euro device to be able to use the offline functionality. Once the device is funded, users can make offline payments seamlessly, with or without connection to the internet, and benefit from immediate offline settlement in proximity. Additionally, beta digital euro received offline can be re-spent offline without needing to reconnect to the network first. However, if a user wishes to defund their device — i.e. convert their offline funds back into commercial bank money — their device connects to the pilot PSP distribution component, which in turn contacts the Eurosystem back-end. 

When the pilot PSP's distribution component is contacted, the pilot PSP can update the user’s commercial bank account. The same process applies for defunding. 

The Eurosystem’s offline issuance component will then update the dedicated cash account (DCA) based on the funding or defunding operation. 

Q64 What would be the PSPs' involvement in securing offline digital euro when it is in the PSP's app? 

When an offline payment is being made, the software running on the secure element of the end user’s phone protects against double-spending. This software is provided by the ECB regardless of the choice of integration (Eurosystem digital euro app or integration in the PSP’s app), so that pilot PSPs do not need to develop the corresponding security countermeasure on their own. 

Q65 In the PSP participation agreement, what is meant by “reasonable efforts” regarding a pilot PSP ensuring the clearance of offline balances?

Pilot PSPs are expected to make reasonable efforts to ensure that offline balances are cleared in a timely manner. Reasonable efforts would typically include having a plan for the timely clearing of offline balances, sending notifications and reminders to end users, providing clear instructions to enable defunding, and allowing sufficient time and appropriate channels for end user response.

Q66 Will the Eurosystem provide a digital euro app and a software development kit for the pilot?

The Eurosystem will provide a digital euro app as well as a software development kit (SDK) to support pilot PSP with integration into proprietary applications. This will allow pilot PSPs to either use the Eurosystem-provided app or integrate pilot payment services into their own applications (see Q61). Pilot PSPs can decide their preferred implementation approach.

Q67 What type of POS solution is required for the digital euro pilot, and which standards apply to it?

For proximity P2B payments in the digital euro pilot, acquiring PSPs are expected to provide a SoftPOS solution, i.e. a payment acceptance solution running on a commercial off-the-shelf mobile device (such as a smartphone or tablet) using NFC technology. The SoftPOS solution must support Common Payment Application Contactless Extensions (CPACE) as the applicable standard for NFC-based payment interactions. Transaction flows for proximity payments use the CPACE standard.

The acquiring PSP is responsible for ensuring that the acceptance solutions they use for the pilot meet the applicable pilot requirements. The acquiring PSP would be expected to assess readiness as part of its implementation and onboarding activities.

However, as long as the POS solution supports CPACE, PSPs may also use different solutions (e.g. an Android-based POS solution).

Q68 Will a software point of sale (SoftPOS) development kit be provided by the Eurosystem?

The Eurosystem does not currently plan to provide PSPs with a SoftPOS development kit. The Eurosystem will provide a Software Development Kit (SDK) for the digital euro app. Each PSP is free to define and implement its own acceptance solution, taking into account the relevant commercial and technical context.

Q69 Is there a defined flow for providing a CPACE-based payment instrument in the digital euro app, and which parties are responsible for its initialisation?

The mobile app provided to individual end users needs to offer a feature that allows users to pay with NFC. Pilot PSPs are responsible for providing such a feature either by using the digital euro app or by offering it as part of their own proprietary app. In both cases, the Eurosystem will provide the necessary SDK and server-side functionalities, so that PSPs can minimise their efforts to the extent possible.

Q70 Can PSPs use existing terminal integration protocols (e.g. ZVT) to connect POS devices to their back-end systems, or are they required to implement specific standards such as Nexo from the outset?

Pilot PSPs are free to use their own integration protocols for communication between the POS and the PSP back-end, provided those protocols adhere to the functional requirements outlined in the implementation specifications.

Q71 Are PSPs allowed to reuse existing mobile banking app components, or do digital euro flows need to be fully separated?

Pilot PSPs may develop their pilot payment services using their preferred implementation approach, provided that all applicable pilot requirements are met.

This means that pilot PSPs may, for example, reuse or adapt existing mobile banking app components, integrate pilot functionalities into existing channels, third-party wallets developed by the banks or develop dedicated digital euro user flows or standalone solutions.

Pilot PSPs may also use the Eurosystem-provided digital euro app to offer pilot payment services (see Q66).

Q72 What technical standards and interoperability requirements will apply to the digital euro pilot?

The digital euro pilot leverages existing open market standards wherever possible to ensure interoperability and a harmonised end user experience across pilot PSPs.

Key standards and approaches include:

• CPACE for NFC-based proximity payments:

CPACE is used for secure NFC communication between an individual end user device and a merchant SoftPOS device in online mode.

• ISO 20022 data model:

The pilot uses ISO 20022 as the basis for its data dictionary and message structure, ensuring alignment with existing payment infrastructures.

• API-based standards and data models:

Existing market standards are adapted for JSON RESTful API-based communication, including elements such as the Berlin Group’s data dictionary.

• PSP-specific solutions for merchant integration:

Communication between the business end user (merchant) domain and the PSP back-end is based on PSP-specific standards and solutions.

The standards identified for the pilot are candidate standards. Their final adoption is subject to confirmation by the Eurosystem, and the set of applicable standards may evolve over time.

Q73 Are the standards used in the pilot applied as they are, or are they adapted specifically for the digital euro?

The pilot will leverage established market standards wherever possible. These standards have been adapted to reflect digital euro-specific requirements in order to make them readily usable for participants. In principle, PSPs and terminal providers should be able to rely on the supplied specifications without needing to redesign the underlying standards themselves.

Q74 Can pilot PSPs support the European Digital Identity Wallet during the pilot?

Yes. Pilot PSPs may support the European Digital Identity Wallet (EUDI Wallet) as part of their preferred strong customer authentication method for online payment transactions where individual end users rely on the PSP’s digital instruments.

Pilot PSPs remain free to choose their preferred authentication method, provided that it complies with all applicable regulatory frameworks and associated security requirements.

Q75 Does the API request “POST/lookups/deans” allow PSPs to resolve a DEAN to the servicing PSP identifier, including a BIC, in order to route a transaction correctly?

Yes. The POST/lookups/deans endpoint is part of the alias look-up services and is intended to support payment routing where a DEAN is used as the identifier. It enables a PSP to submit a DEAN and retrieve the identifier of the pilot PSP servicing that DEAN.

This functionality is relevant, for example, for person-to-person (P2P) payments using a DEAN and for e-commerce or m-commerce payments using a DEAN. In these scenarios, the requesting PSP uses the look-up service to determine which PSP services the payee or payer, so that the transaction can be routed to the correct party.

The response includes the pilot PSP identifier and, where applicable, this identifier includes the BIC associated with the servicing PSP.

Q76 The back-end specifications refer to several identifiers such as PSP ID, BIC and “financialInstitutionIdentification”. Do these terms mean the same thing, or do they have different functions?

These terms are closely related but refer to different levels of description within the specifications.

The BIC (Business Identifier Code) is a globally recognised identifier used across payment systems and is currently the primary identifier used in the digital euro rulebook to identify PSPs. The PSP ID is a DESP-specific identifier introduced to uniquely identify PSPs within the platform, including cases where a PSP may not have a BIC.

The term FinancialInstitutionIdentification is used here in a generic sense. In the ISO 20022 message definitions, this corresponds to the data structure “FinancialInstitutionIdentification1” which is used to represent a financial institution. While this structure can theoretically contain multiple attributes (such as BIC, name, or address), in the current digital euro rulebook it is restricted to carrying the BIC only.

In short, PSP ID and BIC are identifiers of the participating PSP, while “financialInstitutionIdentification1” refers to the technical ISO 20022 data structure used to represent that identifier in API messages; currently it uses the BIC.

Q77 Are the accompanying YAML files an OpenAPI Specification (OAS) description of the interface specifications?

Yes. The accompanying YAML files are provided as machine-readable interface descriptions and follow the OpenAPI Specification (OAS) version 3.0.3.

They complement the back-end specifications by describing the relevant API endpoints, message structures, data elements and technical interface requirements in a standardised format that supports pilot PSP implementation.

Q78 The back-end specifications state that each request should have a unique Request-Id (UUID). Can one UUID ever be reused, and how does this work in the context of idempotency?

Each request must have a unique Request-Id for every new business instruction. The same Request-Id may be reused only in the context of idempotent retries – where a PSP resends the exact same request with an identical payload and identical parameters owing to technical issues (e.g. a timeout or a connectivity interruption). Idempotency ensures that repeated submissions of the same request are processed only once. When a request is resent with the same Request-Id and identical content, DESP treats it as a retry of the original request and returns the same response, without creating a duplicate transaction. If the same Request-Id is reused with a different payload or modified business content, the request is not considered idempotent and will be rejected (e.g. with a 4xx response code).

In short, a Request-Id is unique to a business instruction but may be reused for technical retries of that same instruction, provided the content of the request remains unchanged.

Q79 The back-end specifications explain that DESP can enrich partial settlement instructions received from pilot PSP requests. What does “partial” mean in this context?

In this context, “partial” means that the initial settlement instruction submitted by a pilot PSP does not yet contain all the information required for final settlement.

A PSP may submit only the data it holds (typically the debtor-side information). DESP then coordinates with the counterparty PSP to obtain the missing information (such as creditor-side details) and completes the settlement instruction.

For example, the initiating pilot PSP sends the payment instructions with debtor-side data. DESP routes the request to the creditor PSP, which provides the required creditor-side information. DESP then combines both to form the complete settlement instruction needed for processing.

In short, a “partial” instruction is progressively completed during the transaction flow, rather than being provided in-full upfront by a single PSP.

Q80 Refunds must be linked to the original payment. The back-end specifications require a refund request to include “originalPaymentInstructionId.” What does this identifier refer to exactly, and is it the same as the “originalUetr”? If not, what is the difference?

The data elements “originalPaymentInstructionId” and “originalUetr” are separate identifiers with different purposes. They should not be understood as the same value.

“originalPaymentInstructionId” refers to the “paymentInstructionId” of the original transaction being refunded. This is a resource identifier generated by DESP when the original payment is processed and returned to the PSP in the response. In the context of a refund, it is used to link the refund request to the specific original payment within DESP.

“originalUetr”, by contrast, refers to the Unique End-to-End Transaction Reference (UETR) assigned by the instructing PSP for the original transaction. This is a separate identifier used for end-to-end tracking and reconciliation across systems, rather than for identifying the transaction within DESP.

Q81 Will user portability or switching between pilot PSPs be possible during the pilot? If so, when will the full switching process be specified, including DEAN portability, alias migration, balance transfer, and validation of technical proof?

User portability or switching between pilot PSPs is outside the scope of the pilot.

As a result, the pilot does not include a full PSP switching process, including DEAN portability or reassignment, alias migration, balance transfer, or validation of technical proof when moving between providers.

The related functionalities are expected to be considered in the context of subsequent specification releases.

Q82 All API endpoints use the /v1/ prefix (e.g. /v1/fundings or /v1/users). What is the API versioning approach for the pilot, and how will version changes be managed?

The use of the /v1/ prefix reflects a versioned API approach for the pilot, which should provide a stable integration baseline for participating PSPs.

When new major versions are introduced, it is foreseen that multiple major API versions will coexist during the transition periods. This will allow pilot PSPs time to adapt their systems and migrate integrations in an orderly manner without unnecessary disruption.

Detailed deprecation timelines and notice periods have not yet been finalised. Further information on version lifecycle management, transition arrangements and any applicable migration windows is expected to be communicated in subsequent releases of the technical specifications.

Q83 Which elements that are not yet final or marked as “TBD” will be finalised before implementation begins, and how will this be communicated?

The specifications will continue to be updated, with subsequent versions being published on the ECB pilot webpage, on an ongoing basis as remaining details are finalised.

The Eurosystem will work closely with pilot PSPs during the pilot development phase to support implementation and provide the clarity needed for build activities.

Relevant documentation will be made available in a timely and accessible manner through dedicated technical communication channels.

These FAQs support payment service providers (PSPs) by addressing common questions and providing clarifications related to the PSP call for expression of interest to participate in the digital euro pilot.

If your question is not covered, please submit a new question.

The replies to the FAQs are non-binding and do not extend in any way the rights and obligations deriving from applicable legislation nor introduce any additional requirement than those included in the relevant contractual documentation for the pilot. The expressed views are not authoritative and cannot prejudge any future actions the ECB may take.