FAQs on the digital euro pilot

FAQs on the digital euro pilot Skip to: Skip to navigation Skip to content Skip to footer ANYTIME PAST MONTH PAST YEAR Search Options Image Preview Sort by ANYTIME PAST MONTH PAST YEAR Suggestions Home Media Explainers Research & Publications Statistics Monetary Policy The €uro Payments & Markets Careers Suggestions Sort by Relevance Date FAQs on the digital euro pilot Updated on 14 July 2026 Pilot overview Roles and responsibilities during the pilot Participation in the pilot For payment service providers: preparation and development For payment service providers: pilot payment services For payment service providers: technical aspects Pilot overview Q1 What is the digital euro pilot? The digital euro pilot is a limited practical exercise to help the Eurosystem (i.e. the ECB and participating national central banks) 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, for example 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. Pilot preparation phase (first half of 2026): the call for expression of interest was published on 5 March 2026 and closed on 14 May 2026. The ECB and participating national central banks (NCBs) have evaluated PSP applications and notified applicants of the selection outcome at the end of June 2026. Pilot development phase (starting in the third quarter of 2026): after signing the PSP participation agreement, pilot PSPs will start preparing for the pilot. This entails 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. 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 Could the pilot be extended? 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. Q6 What is the geographical scope of the digital euro pilot? The pilot will take place at the ECB and 19 participating national central banks across the euro area, namely in Belgium, Germany, Estonia, Ireland, Greece, Spain, France, Croatia, Italy, Cyprus, Latvia, Lithuania, Luxembourg, the Netherlands, Austria, Portugal, Slovenia, Slovakia and Finland. The pilot takes into account that selected PSPs may provide pilot services in countries other than the one in which they are established. All pilot PSPs have signed a PSP participation agreement with the NCB of a country where their headquarters or a legally established subsidiary is located. Q7 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 . These guidelines ensure alignment with the Eurosystem's official timing and publications. PSPs are not allowed to publish or disclose any information before the European Central Bank releases its official statements. 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. 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 Q47-Q53. 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 referred 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 referred 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 during the pilot 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 merchants and 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 in the pilot 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 have applied 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 that applied 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). 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 How many PSPs have been selected for the pilot? The Eurosystem has selected 36 PSPs from across the euro area to participate in the digital euro pilot. More information on the selected PSPs can be found in the related press release . Q23 Were there specific eligibility requirements for PSPs to be selected to join the pilot? How were PSP applications assessed? Yes. The Eurosystem received more than 50 applications and assessed them 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 licence and technical and operational capabilities were eligible to proceed to the weighted evaluation stage. PSPs that did not meet all the eligibility requirements were not considered for selection. The weighted evaluation criteria were used to assess eligible PSPs based on factors relevant for achieving the objectives of the pilot to ensure that the pilot has comprehensive coverage, for example in terms of geographical footprint, use cases and end users. PSPs were not required to meet all the weighted evaluation criteria to be considered for selection. The selected participants, including banks and non-bank service providers, span a broad range of business models and sizes and offer broad geographical coverage, ensuring a diverse and representative testing and learning environment for the digital euro. While participation in the pilot is limited to selected participants, all PSPs will play a key role in supporting the digital euro if it is introduced. The ECB remains committed to engaging with all interested PSPs – regardless of whether they participate in the pilot – to foster collaboration and ensure readiness across the payments ecosystem. This includes sharing technical information and promoting a level playing field so that all PSPs are well prepared for the potential issuance of a digital euro. For payment service providers: preparation and development Q24 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 Q21 and Q28). Q 25 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 Q59 and Q60), supporting reusability beyond the pilot context. Q26 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. Q27 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. Q28 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 Q29). 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. Q29 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. 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 . Q30 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 (for example 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. Q31 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. Q32 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 selected pilot PSPs. Q33 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. Q34 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. Q35 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. For payment service providers: pilot payment services Q36 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. Q37 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. Q38 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. Q39 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. Q40 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). Q41 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 Q43). 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. Q42 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. Q43 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. Q44 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. Q45 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. For payment service providers: technical aspects Q46 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. Q47 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. Q48 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. Q49 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). Q50 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. Q51 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. Q52 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. Q53 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 Q47). Pilot PSPs can decide their preferred implementation approach. Q54 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). Q55 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. Q56 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. Q57 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. Q58 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 Q53). Q59 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. Q60 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. Q61 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. Q62 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. Q63 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. Q64 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. Q65 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. Q66 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. Q67 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. Q68 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. Q69 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. Q70 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 have been prepared to support payment service providers (PSPs) by addressing common questions and providing clarifications related participation in the digital euro pilot. 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. A unique pseudonymous identifier that is used to protect the user’s identity when processing payments. It can only be attributed to an identifiable natural or legal person by the pilot PSP distributing the beta digital euro or by the beta digital euro end user. The compulsory unique identifier of a beta digital euro account with technical and design elements similar to the digital euro access number (DEAN) provided for in the proposed Regulation on the establishment of the digital euro. SoftPOS (software point of sale) is a software-based solution facilitating contactless payment acceptance via a commercial off-the-shelf device, for example a smartphone. The DESP is the technical platform which enables issuance and redemption of beta digital euro and provides functions such as access management and alias look-up services. A more detailed overview of the DESP can be found in the high-level architecture of the beta digital euro. Are you happy with this page? Yes No What made you unhappy? Page not working Information not useful Design not attractive Something else Thank you for letting us know! Our website uses cookies We use functional cookies to store user preferences; analytics cookies to improve website performance; third-party cookies set by third-party services integrated into the website. You have the choice to accept or reject them. For more information or to review your preference on the cookies and server logs we use, we invite you to: Read our privacy statement Learn more about how we use cookies I understand and I accept the use of cookies I do not accept the use of cookies Thank you! Thank you! We have updated our privacy policy We are always working to improve this website for our users. To do this, we use the anonymous data provided by cookies. See what has changed in our privacy policy I understand and I accept the use of cookies I do not accept the use of cookies Your cookie preference has expired We are always working to improve this website for our users. To do this, we use the anonymous data provided by cookies. Learn more about how we use cookies I understand and I accept the use of cookies I do not accept the use of cookies This feature requires cookies. Modify