The requirements page lists all 172 rows of the EU Payments framework. Each carries an implementation status, an owner, implementation notes, evidence and a review date, and each has authored guidance describing the artefacts a reviewer asks for, what the reviewer expects to see, what is proportionate for a small institution and for a group, and the gaps that actually occur.
How requirements are cited
Every row is referenced by the instrument and the article: PSD2-95.1 for PSD2 Art. 95(1), RTS-4.3 for Art. 4(3) of the SCA RTS, EMD2-7.1 for EMD2 Art. 7(1), IPR-5C.1A for the verification of payee duty in Art. 5c of the SEPA Regulation, EAA-13.2 for the accessibility statement, ICTGL-92 for paragraph 92 of the EBA guidelines. That is how a supervisor, your auditor and your lawyers cite the duty, so evidence you produce here matches the language of the review.
Sub-paragraphs that list the factors of one duty stay inside the parent row. Sub-paragraphs that are separately evidenced, a different register, a different notification or a different deadline, are rows of their own: PSD2 Art. 70(1) is split into the issuance duties and the 24-hour loss notification channel, Art. 74 into the liability cap and the liability shift where strong customer authentication was not applied, and Art. 35a into the three documents a payment system operator asks for.
Status values
The same four values used across every Venvera framework: Not Implemented, Partial, Implemented and Not Applicable. Not Applicable matters more here than in most frameworks, because the catalogue spans six instruments and every firm has rows outside its authorisation.
| If you are | Rows you will typically scope out |
|---|---|
| A payment institution | The EMD2 rows (safeguarding of e-money, own funds under EMD2 Art. 4 to 6, redemption), unless you also hold an e-money authorisation |
| An e-money institution | PSD2 Art. 8 and 9 own funds rows (EMD2 Art. 4 and 5 apply instead), the Art. 32 small institution row, and the PISP and AISP conduct rows if you do not offer those services |
| An account servicing provider only | The PISP and AISP conduct and session rows (PSD2 Art. 66(3), 67(2), RTS Art. 35(2) to (4), 36(3)) and the professional indemnity insurance row |
| An AISP or PISP only | The account servicing provider rows on interfaces, contingency and confirmation of funds, and the safeguarding rows |
| Any firm | The SCA exemptions you do not apply, the terminal manufacturer and importer duties if you only distribute terminals, and the waived e-money institution rows if you are fully authorised |
The applies-to sentence and the Irish notes
Where a row applies to one kind of provider only, the requirement text ends with Applies to: and the provider the law names, for example "Account servicing payment service providers that operate a dedicated interface" or "Legal persons registered under the Art. 9 optional exemption". Read that sentence before deciding the status. The twenty-one EMD2 rows and the instant payments return also end with an Ireland: sentence citing the European Communities (Electronic Money) Regulations 2011 and the Central Bank of Ireland letters, notices and newsletter that set the supervisory expectation, written for firms authorised in Ireland.
Incident reporting after DORA
Directive (EU) 2022/2556 added PSD2 Art. 96(7): the Art. 96 incident reporting paragraphs no longer apply to credit institutions, payment institutions, e-money institutions or account information service providers, including exempted and waived ones, which report under DORA Art. 19 instead. The EBA repealed its major incident reporting guidelines on 17 January 2025. The module keeps one PSD2 Art. 96(1) row with its applicability limited to providers outside DORA and carries the user information duty; if your firm is a DORA financial entity, the clocks that run are the DORA clocks in the incident module, and the Art. 96(1) row records that decision.
Evidence
Attach evidence to the requirement it supports. The authored guidance on each requirement lists the artefacts a reviewer asks for and states what the reviewer expects, so use it as the acceptance test before you attach a document: a safeguarding reconciliation is evidence when it runs from the liability side and shows the same-day transfer of differences, not when it is a bank statement; a fraud rate is evidence when the methodology document says how disputed transactions are treated. One EU Payments requirement is on the crosswalk: major operational or security incident reporting under PSD2 Art. 96(1) sits in the incident reporting group with DORA, NIS2, GDPR, CPS 234, NDPA, the UAE IA, SOC 2 and NIST, so evidence attached there propagates. The rest is deliberately left unlinked: strong customer authentication protects your customers, so it is not linked to workforce MFA controls, and safeguarding, own funds and redemption at par are payment and e-money duties with no equivalent artefact in another framework. Where one document genuinely answers both, attach it to each requirement.
Owners
Owners are assigned by the responsibilities engine from the requirement's category: the compliance officer for governance, customer protection and business process rows, the data protection officer for data protection rows, the finance lead for prudential and safeguarding rows, procurement for third parties, security operations for incident response and monitoring, and the CISO for IT general controls. Change an owner on the row when the firm's structure differs; the engine does not overwrite a manual assignment.