Payment account — the PSD2 definition and its edges
The definition is one line long, and a surprising amount of regulatory perimeter hangs off it. Article 4(12) of Directive (EU) 2015/2366 defines a payment account as “an account held in the name of one or more payment service users which is used for the execution of payment transactions”. Two conditions, both necessary. Whether a product is a payment account decides access rights for third-party providers, the information duties owed to the user, and in several member states whether the account switching and fee-transparency regime applies.
1. The two-part test
| Limb | What it requires | Where firms get it wrong |
|---|---|---|
| Held in the name of one or more payment service users | The account is the user’s, not the institution’s | Pooled or omnibus structures where the user has a ledger position rather than an account in their name |
| Used for the execution of payment transactions | The account is a means of making and receiving payments | Products that store value but cannot originate or receive third-party payments |
Neither limb refers to the product’s name, its marketing, or whether interest is paid. A savings product that can send and receive third-party transfers can meet the definition; a “current account” that cannot execute payment transactions at all would not.
2. What turns on the answer
Several regimes attach to the classification rather than to the licence:
- Access by third-party providers. The PSD2 access regime for account information and payment initiation is framed around payment accounts that are accessible online, so the classification determines whether an interface obligation exists at all.
- Information and transparency duties. The Title III information requirements are structured around framework contracts for payment accounts and single payment transactions.
- Fee transparency and switching. The EU payment accounts regime for comparability of fees and account switching operates on payment accounts, which is why a product-classification decision can pull in a whole disclosure workstream.
Because the consequences sit in different regimes, the classification decision should be recorded once, centrally, with reasons — rather than re-derived by each team that needs an answer.
3. Payment accounts and e-money
E-money and payment accounts are different concepts that frequently sit in the same product. Electronic money is defined by Directive 2009/110/EC and carries its own duties — issuance at par value on receipt of funds and redemption at any moment and at par value on the holder’s request under Article 11. A stored-value balance that is also used to execute payment transactions in the user’s name can be both e-money and a payment account, and the two sets of obligations then apply together rather than one displacing the other.
FAQ
Is an e-money wallet a payment account?
It depends on the two limbs, not on the label. Where the balance is held in the user’s name and is used to execute payment transactions, the definition is capable of being met — and the e-money duties continue to apply alongside.
Does a pooled or omnibus structure create payment accounts?
The first limb asks whether the account is held in the name of the payment service user. Where the user holds a ledger position within an account in the institution’s name, that limb needs careful analysis rather than assumption.
Why does the classification matter so much?
Because third-party access, the Title III information duties, and the fee-transparency and switching regime are all framed around payment accounts rather than around the type of licence the provider holds.
Related: Fees and switching under the Payment Accounts Directive · Safeguarding accounts · The limited network exclusion
