PSD3 Compliance Requirements
PSD3 and PSR compliance is an offset from an unset anchor, not a calendar date. The 21 and 27 month tiers, sourced from the Council's April 2026 compromise texts, and what a build has to have ready before either clock starts.
19 min read
77 views
Key takeaways: PSD3 compliance requirements 5
The offset structure that replaces a fixed compliance date, why the 18 and 24 month figures are outdated, the interface outage presumption, the consent withdrawal quarantine and the unresolved refund evidence gap.
- There is no compliance date, only offsets from an unset anchor Neither instrument has reached the Official Journal, so entry into force has no scheduled date and nothing downstream of it does either. The PSR body applies at 21 months after entry into force, two named articles defer to 27 months and EBA delegation offsets of 9, 12 and 18 months plus a discretionary 3 month extension sit underneath those two headline figures. A build plan has to work from the offset, not from a date nobody can supply yet.
- 18 and 24 month figures trace to a superseded 2023 draft The European Commission's original 2023 proposal carried the identical article at 18 and 24 months. The Council's April 2026 compromise text kept the article's shape and moved the two figures to 21 and 27. A planning document still citing 18 or 24 months is reading the 2023 proposal rather than the text currently under negotiation.
- Interface outage detection is a five-failure presumption Unavailability is presumed once five consecutive access requests either return a server error or get no response within 30 seconds. That is a measurable detector a build can implement today, and it shifts the evidential burden onto the account servicing provider rather than declaring an automatic breach.
- Consent withdrawal needs a quarantine state, not an immediate purge Deleting withdrawn-consent data right away is non-compliant. The 48 hour window after withdrawal exists precisely so the user can reverse it, so the data has to sit in a quarantine state, unused but not yet deleted, until that floor has elapsed.
- Fraud data sharing is mandatory, and the refund evidence channel is still undefined Providers must participate in fraud information sharing arrangements once an objectively justified suspicion threshold is met, not as an optional service. Separately, a payer's provider must refund a disputed transaction unless it can evidence that the payee's institution also monitored it, and no interface defined in the provisions read for this article carries that evidence between institutions yet.
Any deadline stated for PSD3 and the Payment Services Regulation, the PSR, rests on a step that has not happened yet, publication in the Official Journal of the European Union. On 16 August 2026 neither instrument has reached the Official Journal. That changes the planning problem for a CTO or engineering lead who has to build to these rules rather than read about them. A date nobody can verify is not a deadline, it is a placeholder with a due date attached. What the compromise texts give reliably is a set of offsets measured from entry into force, itself twenty days after a publication with no scheduled date. This article treats the offset as the unit of planning and quotes the operative text directly. Every quote of operative text below is drawn from the Council's two compromise texts, the Regulation at document 8221/26 (PSR) and the Directive at document 8222/26 (PSD3), both dated 17 April 2026 and both retrieved 16 August 2026, and short-form citations below give document and page only.
Who this package reaches
ASPSPs hold the account. Payment initiation service providers, account information service providers and electronic money institutions offering a payment service connect to it, and the duties below bind different combinations of these four, tagged section by section. ATM deployers sit outside full authorization: a firm offering only cash withdrawal, with no payment account and no other Annex I service, "shall not be subject to authorisation but shall register, before taking up activity, with the competent authority" (PSD3 p.145). Electronic money tokens carry their own scope boundary, covered two sections down. Each section below is tagged with its offset and the entity it binds.
Where the texts actually stand
Neither text is a first-reading deal. Both procedure files record committee approval of an early second-reading text on 5 May 2026, with the Council still to adopt its own first-reading position before Parliament approves at second reading, signs and publishes. On 16 August 2026 the Parliament's own procedure file for the Regulation, 2023/0210(COD), reads "Awaiting Council's 1st reading position" (procedure file), and the companion Directive file carries the identical status. Parliament's own indicative plenary date is 14 December 2026, labeled indicative rather than confirmed. Neither file records a final act. Both texts fix their own entry into force the same way, "on the twentieth day following that of its publication in the Official Journal of the European Union" (PSR p.428), and there is no scheduled publication date to count that twenty days from.
Where the wrong numbers came from
The 18 and 24 month figures that still turn up for this package are not invented. The Commission's 2023 proposal, document CELEX 52023PC0367, carries the identical article at those two figures; the Council's current compromise text at 8221/26 page 428 reads 21 and 27. Three years of negotiation moved the two numbers and left the article's shape untouched, so a figure of 18 or 24 months for this package traces to the 2023 proposal, not to the text agreed in April 2026. The same superseded proposal explains a second gap, covered below.
The offsets, assembled
Seven offsets sit across the two instruments once the EBA mandates and grandfathering steps found in this reading are counted, not only the three on page 428. Every row below is a duration from entry into force, not a date.
| Offset from entry into force | What bites |
|---|---|
| 0 | PSR SCA derogation for recurring payer-initiated credit transfers; PSR electronic-money-token transitional carve-out |
| 9 months | EBA submits the dedicated-interface recovery-time RTS |
| 12 months | EBA submits the no-interface criteria RTS; EBA submits the PSD3 safeguarding RTS |
| 18 months | EBA develops guidelines on the two-inherence-factor SCA exemption |
| 21 months | PSR body applies; PSD3 transposition deadline; PSD2 and EMD2 repealed; EMI and PI grandfathering population fixed; electronic-money-token carve-out closes |
| 27 months | PSR matching-verification duty and its liability provision apply; grandfathering closes; re-authorization assessment deadline |
| 27 plus up to 3 months | discretionary extension where the competent authority could not process the submitted evidence in time |
Each section below states which row it lands in.
What has to exist before the clock even starts
0, entry into force • PSPs, EMIs.
The clearest exhibit in either text sits on page 428 of the Regulation, where three consecutive sentences set three different clocks from the same unfilled starting point.
"It shall apply from [ OP please insert the date= 21 months after the date of entry into force of this Regulation]. However, Articles 50 and 57 shall apply from [ OP please insert the date= 27 months after the date of entry into force of this Regulation]. Articles 85a and 108a shall apply from the date of entry into force of this Regulation." (PSR p.428)
The date fields are Publications Office placeholders, filled only at adoption. The article numbers are the draft numbers as the text stood on 16 August 2026, and they will move during legal-linguistic revision, so treat them as a traceability aid, not a fact to plan around. What is durable is the shape: a general application date, a further six-month deferral for two named provisions, and two provisions that bite the moment the Regulation enters into force.
Two obligations sit in that offset-zero tier. The first is a strong customer authentication exemption for recurring credit transfers the payer's own provider initiates, conditional on four cumulative requirements, including a payer-payee agreement fixing frequency and amount and stating when the amount can vary, and the payer's own consent given under strong customer authentication at setup. Three of the four conditions describe a stored mandate rather than a transaction: a system that records a recurring payment as a payee reference plus a fixed amount cannot evidence the variability clause, and the setup event needs its own retained authentication evidence, because "no additional action is required from the payer to initiate of the respective credit transfers" (PSR p.361), grammatical slip included.
The second is a transitional carve-out for electronic money tokens. Transfers made "exclusively in electronic money tokens directly from the payer to the payee, without any intermediary intervention" (PSR p.417) sit outside PSD2 from entry into force until the general application date. The identical wording also appears in the Regulation's own scope article, where the exclusion is permanent rather than time-boxed, so the correct reading is outside PSD2 during the window and outside the PSR permanently, not outside PSD2 now and inside the PSR immediately after. Anyone issuing or moving electronic money tokens needs that distinction settled first, because it decides which rulebook a given transfer answers to at all.
Monitoring on both legs, and the evidence gap the text does not close
21 months • payer's PSP, payee's PSP.
Transaction monitoring becomes a duty on both sides of a transfer, at two different moments: "The payment service provider of the payer shall carry out the transaction monitoring referred to in paragraph 1 prior to the execution of a payment transaction. The payment service provider of the payee shall also carry out transaction monitoring before the funds are made available to the payee" (PSR p.345). Skipping the check carries direct liability where "the payer incurs financial damage" (PSR p.345).
The sharpest sentence in the package follows immediately after. The refund trigger is not a failure to monitor, it is a failure to prove that the other institution monitored too: "Where the payer's payment service provider does not provide evidence to the payer that such monitoring for a transaction has been carried out by both providers, it shall refund the payer the amount of the transaction" (PSR p.346), and "The burden to prove that there was no breach of this Article shall be on the payment service provider concerned" (PSR p.346). Read together, the gap is exact: the payer's provider owes an evidentiary claim about a control run inside a different institution, per transaction, before it can refuse a refund. Nothing in the provisions read for this article creates the channel that would carry that fact across the institutional boundary, no message field, no attestation format, no registry, no shared interface. That gap is separate from sanctions screening, its own obligation on a different rail that does not substitute for it; our instant payments sanctions screening guide covers that adjacent duty on its own terms. Whether the missing channel arrives through a future EBA standard, a scheme rule or a bilateral arrangement is not something the text read for this article determines, and a build plan that assumes the evidence will simply appear at the counterparty's API is planning against a channel that does not exist yet.
Fifteen business days, and only after the police report
21 months • payer's PSP.
The impersonation-fraud liability duty is separate, with its own clock (PSR draft Article 59, p.293-294). The refund duty is conditioned on the consumer having, without undue delay after becoming aware, both notified the provider and reported the fraud to the police. Once the provider holds both, "Within 15 business days of being notified and provided with the police report by the consumer, the payment service provider shall do either of the following" (PSR p.294): refund, or issue a justified refusal naming the bodies the consumer may refer the matter to. The clock is keyed to both being held, notification and the police report together, not the fraud notification alone. Proving fraud or gross negligence is the provider's burden: it must invite the consumer to supply information before it concludes anything, and a consumer's silence "shall not in itself lead the payment service provider to conclude that the consumer acted fraudulently or with gross negligence" (PSR p.294).
The interface you have to serve, and the outage test written into the text
21 months • ASPSP, PISP, AISP.
At the general application date the dedicated interface becomes the mandated access path, and the Regulation defines unavailability as an algorithm rather than a judgment call. "Unavailability shall be presumed to have arisen when five consecutive requests for access to information for the provision of payment initiation services or account information services receive server error responses or no response from the account servicing payment service provider's dedicated interface within 30 seconds" (PSR p.248). Four components carry that sentence: the count is five, the failures are consecutive, the qualifying failure is a server error or no response at all, and the thirty seconds attaches specifically to the no-response case. The effect is a presumption, shifting the evidential burden rather than declaring an automatic breach, and it gives both sides the same supervisory trigger.
Performance carries three separate parity tests rather than one absolute service level: against the ASPSP's own authentication interface, against its direct online account-access interface including technical and IT support, and on response time specifically against that same online-access interface. None is a fixed number, and all three require the ASPSP's own customer-facing interface instrumented as a control arm, so the conformance evidence a supervisor asks for is a continuous comparison rather than a one-time measurement. On request, a competent authority can also excuse an ASPSP from the dedicated interface altogether and permit either the customer interface or "not to offer any interface at all for secure data exchange" (PSR p.251). Neither "fallback" nor "contingency" occurs anywhere in either 2026 compromise document, checked by an exhaustive case-insensitive search of the complete converted text for `fallback`, `fall-back`, `fall back`, `backup`, `back-up`, `back up`, `contingency` and `contingencies`. The word "fallback" is not merely absent, it is gone: the Commission's 2023 proposal used it, in its explanatory memorandum, for this same exemption, so its disappearance is a documented removal, not a silent one. What replaces PSD2's emergency path is not a renamed fallback. It is a supervisory derogation, granted per institution, with a genuine no-interface branch, so a third-party integration cannot assume every ASPSP exposes a machine interface at all.
What you must publish every quarter
21 months • ASPSP.
ASPSPs "shall publish on their website quarterly statistics on the availability, unplanned unavailability and performance of their dedicated interface, and, for comparison purposes, of the interfaces that the account servicing payment service provider makes available to its payment service users for directly accessing their payment account online" (PSR p.241). Two interfaces, three measures, every quarter, on the public website, and the two ratios are already defined rather than deferred to a future standard: a success count over total requests for account information, and, for payment initiation, both a success count and a success transaction volume, each over its own total (PSR p.241). Telemetry has to distinguish account information requests from payment initiation requests, carry monetary volume on the initiation leg, and be emitted from the same code path that serves the request, or the published figure and the served reality diverge. A future EBA technical standard, still to come, carries the recovery-time target for the outage detector above, so the threshold is buildable today and the recovery target is not.
The sandbox that may carry no personal data
21 months • ASPSP, PISP, AISP.
A testing facility becomes an obligation, and it has to serve applicants whose authorization is still pending, alongside providers already authorized. The constraint that turns it into a real build is absolute: "No sensitive payment data or any other personal data shall be shared through the testing facility" (PSR p.241). Not sensitive payment data specifically, any personal data at all, so a sandbox fed from masked production or a pseudonymized extract fails the test too, because pseudonymized data is still personal data under GDPR. What is left is fully synthetic data with referential integrity across accounts, transactions and identities, its own build with its own test corpus.
The permissions dashboard is a data model, not a screen
21 months • ASPSP, PISP, AISP.
The consent dashboard holds six fields, one of them an access log rather than a consent attribute, so it is fed by runtime telemetry as well as consent state. Withdrawal has to be reversible for 48 hours: the dashboard must, "within 48 hours from withdrawal of a consent" (PSR p.258), let the user restore access that was withdrawn. That same figure is where the obvious engineering instinct is wrong on the other side: the receiving provider must "delete without undue delay, but not before 48 hours from withdrawal of a consent, the data received as a result of the data access consent granted by the payment services user" (PSR p.259). Purging on revoke, the normal response to a withdrawal, is non-compliant here. The compliant shape is a quarantine state distinct from both active and deleted: stop using the data at once, hold it 48 hours in case the user reverses the withdrawal, then delete, unless the user explicitly chooses retention. Withdrawn and expired consents then move to their own archive, kept for "a duration of two years" (PSR p.258), a different object with a different clock from the underlying account data.
Twelve prohibited obstacles, and four of them move with your own product
21 months • ASPSP.
The Regulation lists twelve prohibited obstacles to data access, and the chapeau says the list is a floor, not a ceiling: "Prohibited obstacles shall include, but not be limited to, the following" (PSR p.261). Four of the twelve are defined as a differential against the ASPSP's own direct customer journey, so a conformance test cannot be run by reading the third-party journey alone. It has to instrument the direct journey as a control arm, the same discipline the interface tests above already demand. One entry is a clean absolute instead: a provider may not require "two strong customer authentications in a payment initiation service-only journey where the payment initiation service provider transmits to the account servicing payment service provider all the information necessary to initiate the payment, namely one strong customer authentication for the yes/no confirmation and a second strong customer authentication for payment initiation" (PSR p.264).
One entry deserves a lexical note, kept short. "Trusted beneficiaries" occurs zero times in either document; the payer's saved-payee list has not vanished, it sits under a different name: an ASPSP may not restrict "the possibility of a payment service user to initiate payments via a payment initiation service provider only to those payees that are on the payer's beneficiaries list, unless the payment service user is unable to perform those payments in the customer interface" (PSR p.262). Absence of the term is not absence of the mechanism. Anti-fraud and GDPR measures are carved out of the list, but only where the measure is not itself one of the twelve.
Authentication after the smartphone assumption
21 months, EBA guidance due at 18 • any PSP performing SCA.
A provider "shall not make the performance of strong customer authentication dependant on the exclusive use of a single means of authentication" (PSR p.365, printed spelling), and the same paragraph forbids making authentication depend, explicitly or implicitly, on possession of a smartphone or other smart device, unless the user has agreed to a mobile-only relationship. A FinTech whose only authenticator is its own app has to add a second, genuinely independent means, a product decision with a real cost. The counterweight sits a few pages away: two inherence factors become legal where a provider "can implement strong customer authentication using two elements only from this category, if it demonstrates to the national competent authority that the independence of the elements is at all times fully preserved and the authentication procedure ensures at all times a high level of security" (PSR p.360). That "at all times" is the operative detail: independence is a standing evidence obligation, not a launch-day audit, so the regression suite that checks the exemption logic on every release has to re-assert independence between the two factors and log the assertion, not just the outcome, on the same principle the mandate-object tests above already need.
Fraud data sharing becomes mandatory, not optional
21 months • PSPs on both legs of a transfer.
The operative verbs are mandatory rather than permissive: a provider "shall participate in information sharing arrangements with other payment service providers as referred to in paragraph 3 and shall exchange data to the extent necessary to comply with their obligations in Article 83(1), point (c), where the payment service provider has objectively justified reasons to suspect fraudulent behaviour by a payment service user" (PSR p.350). Shall participate, shall exchange, gated on the threshold, not made optional by it. One data class is expressly excluded from what may cross the boundary, "Information on the environmental and behavioural characteristics which are typical of the payer in the circumstances of a normal use of the personalised security credentials" (PSR p.350), the same behavioral signal a local fraud model is entitled to use, so the build is an outbound filter over one feature store rather than a separate model. Shared data expires "no longer than 5 years after the suspected fraudulent transaction has taken place" (PSR p.351), a clock keyed to the transaction rather than the customer relationship, so one retention policy cannot serve both this data and the ASPSP's own monitoring data. A joint impact assessment has to happen before any arrangement is concluded, not after, putting a multi-party privacy artefact on the critical path of the integration.
The matching duty you may already have built, and the license you hold ending
27 months, matching duty; 21, PSD2 repeal; grandfathering 21 to 27, plus up to 3 more • PSPs, EMIs, payment institutions.
Deferred to the second, longer tier, the payee-matching duty is not a new rule. It extends one already live: "payment service providers shall comply with provisions of Articles 5c(1) to (7) and 5b(2) of Regulation (EU) 260/2012, and those articles shall apply mutatis mutandis to all credit transfers, including those that fall outside the scope of Regulation (EU) 260/2012" (PSR p.277). The rules a builder implements are the ones already in force for the euro instant-payments rail, which our own Verification of Payee implementation guide already documents. What changes at the second tier is scope, extended to every credit transfer, plus one schema change: identifier references get "construed as referring to the unique identifier used to unambiguously identify the payment account of the payee" (PSR p.277), so a matching implementation typed strictly to IBAN needs its identifier field generalized.
PSD2 stays operative law, subject only to the offset-zero carve-outs above, until it is "repealed with effect from ... [21 months after entry into force of this Directive]" (PSD3 p.163). Existing electronic money institutions get a two-step transition: activity taken up before the general application date is grandfathered, that grandfathering closes six months later at the third tier, and a competent authority "may exceptionally decide to extend, by no longer than 3 months, the period before specific payment institutions and electronic money institutions are prohibited from providing services" (PSD3 p.161) when the authority itself could not process the submitted evidence in time. Several of the assessment points that transition leans on are DORA obligations imported by reference into the payments dossier, a point our own DORA compliance guide covers in full, so a firm that treats DORA and PSD3 as separate programmes assembles the same evidence twice. Safeguarding sits on the same dossier, and our safeguarding and reconciliation guide covers that ground rather than repeating it here.
A build order that does not need a date
Nothing above needs an Official Journal date to start. The two offset-zero items, the mandate object for recurring transfers and the electronic-money-token scope decision, can be built now, and the shape of both obligations is unlikely to move even where the numbers do. The outage detector, the quarterly ratio telemetry and the synthetic-data testing facility are all buildable against numbers already fixed in the text, independent of when the general application clock actually starts. Underneath, the messaging layer shares a rail already live: our ISO 20022 structured address migration guide covers the same SEPA messaging surface these interfaces sit on top of, worth building to now rather than twice.
What should not be built yet is anything against a number this article deliberately did not give: no compliance date, no recovery-time target, no matching threshold, because none of those numbers appear in the provisions read for this article as agreed on 16 August 2026. Every article number quoted above is the number the text carried on that date, and every one of them can move before the Official Journal prints it. Cite by document and page until it does. The offset structure is stable. The anchor is not. Build to the offset.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 7
No matches
Try a different keyword, change the topic or clear filters
-
Neither the PSD3 directive nor the PSR regulation has been published in the Official Journal of the European Union, so there is no compliance date to plan against yet. Both instruments set their own entry into force at twenty days after publication, and every other deadline in the package is defined as an offset counted from that unset starting point rather than as a fixed calendar date.
-
The texts define offsets from entry into force rather than dates. The PSR body applies at 21 months, and two named articles are deferred a further six months to 27 months.
Underneath those two headline figures sit EBA delegation offsets of 9, 12 and 18 months for various technical standards and guidelines, plus a discretionary extension of up to 3 months a competent authority may grant when it cannot process a firm's submitted information in time.
-
The 18 and 24 month figures trace to the European Commission's original 2023 legislative proposal, a superseded document. The Council's April 2026 compromise text carries the identical article structure with the figures updated to 21 and 27 months, so a source citing 18 or 24 months reflects the 2023 draft rather than the text currently under negotiation.
-
The regulation treats unavailability as a presumption rather than a judgment call. It is presumed to have arisen once five consecutive access requests either receive a server error response or get no response within 30 seconds.
The presumption shifts the evidential burden onto the account servicing provider rather than declaring an automatic breach, and it gives both sides of an integration the same measurable trigger to build monitoring against.
-
The instinctive response of purging the data immediately is not compliant. Withdrawal carries a 48 hour floor: the receiving provider must not delete the data before that window elapses, because the same 48 hours is also the window in which the user may reverse the withdrawal.
The compliant shape is a quarantine state distinct from both active and deleted, holding the data unused until the window closes.
-
No. The obligation to provide a testing facility for authorised and still-pending applicants alike carries an absolute restriction: no personal data of any kind may pass through it, not sensitive payment data alone. Masked or pseudonymised production data does not satisfy this, because pseudonymised data remains personal data under GDPR, so the facility needs fully synthetic data with referential integrity across accounts, transactions and identities.
-
Under the transaction monitoring duty, the payer's provider must refund a transaction unless it can provide evidence that both its own institution and the payee's institution carried out monitoring. The burden of proof sits with the provider.
The provisions read for this obligation do not define a channel, message field or registry that would carry that evidence from the payee's institution to the payer's institution, so building the monitoring check alone does not close the duty.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
