Payment service providers operating under PSD2 inherit a change-governance obligation most delivery stacks weren't built for: the EBA's ICT and security risk management expectations require changes to payment systems to be controlled, tested, and documented through their lifecycle — and supervisors verify with samples. For engineering leaders at PSPs, e-money institutions, and banks running payment rails, the recurring pain is the approval trail: authorizations that exist as meeting outcomes and chat threads, invisible to the auditor tracing a specific change to the payment engine. Automating those approvals — with audit-ready evidence attached — is the practical unlock.
This how-to lays out the sequence: what EBA-aligned change control expects, the approval automation that satisfies it, and the evidence architecture that turns supervisory sampling into a lookup.
The EBA's ICT and security risk management guidelines — the operational backbone under PSD2 — expect financial entities to manage ICT changes so that modifications to payment systems are risk-assessed before implementation, approved by appropriate authority, tested proportionately, deployed in a controlled way, and documented throughout. Translated to sampling terms: for any change to the payment stack, produce the connected record of assessment, authorization, testing, and implementation. The provisions read as governance boilerplate until a supervisor or scheme auditor picks three changes to your payment engine and asks for exactly that chain — at which point the difference between "we have an approval process" and "here is this change's approval record" becomes the whole examination.
Every change to in-scope systems rides a structured change request carrying the system reference (payment engine, SCA components, API gateway) and a risk classification with documented criteria. This is the object every downstream record binds to — and the scoping that makes "all changes to the payments platform, Q2" a filter rather than a project.
Replace approval-by-meeting with approval policies: the workflow routes each change to the roles your governance requires for its risk class — engineering lead for routine, plus risk/security sign-off for payment-path changes — and records identity, role, and timestamp against the specific artifact before deployment can proceed. Two properties make this audit-proof: enforcement (the deploy gate means the record's existence proves the control ran) and non-backfillability (policy-executed approvals can't be reconstructed after the fact, which is exactly why supervisors trust them).
Test executions — functional, regression, security — log against the change at run time; CI/CD integrations attach deployment and post-implementation verification events. Retention is durable, sized to supervisory lookback rather than pipeline defaults, so the March change's test evidence exists at next year's examination.
The Release Compliance Dossier presents each release's chain — changes, assessments, approvals, tests, deployments — as one artifact, and compliance objectives map the evidence stream to your EBA-aligned control set. The multiplier: the same chain answers PSD2 supervision, DORA's ICT change requirements, card scheme audits, and bank partner due diligence — four examiners, one record.
Quarterly, sample yourself: three changes to payment systems, full chains, timed — including one emergency change, because the expedited path's evidence is what examiners probe hardest. Minutes per chain means the automation holds; anything requiring reconstruction is next sprint's fix, found before a supervisor finds it.
PSD2 change approval automation is a records discipline: payment-system changes anchored, approvals executed as policy with identity and authority recorded, evidence bound at execution, chains assembled per release. Build it once and supervisory sampling, DORA obligations, and scheme audits all draw from the same living trail — while approvals themselves get faster, not slower.
Changes to payment systems risk-assessed before implementation, approved by appropriate authority, tested proportionately, deployed controlled, and documented throughout — with the connected record producible per sampled change.
Policy execution: the workflow routes by risk class, records identity, role, and timestamp against the specific artifact, and gates deployment — so the record's existence proves the control ran and can't be backfilled.
The payment stack: payment engine, SCA components, API gateways, and settlement paths — each change carrying its system reference so scoped supervisory queries resolve as filters.
Yes — the chain that answers PSD2 supervision also serves DORA's ICT change requirements, card scheme audits, and bank partner due diligence. One evidence architecture, four examiners.