PSD2 SCA

Per PSD2 RTS Articles 4-9 + EBA Opinions: authentication methods. Requirements include (a) implement biometric authentication using device + cloud biometric meeting EBA guidance + (b) implement device binding for possession factor + (c) implement secure mobile payment + e-commerce flows + (d) implement out-of-band authentication where appropriate + (e) maintain authentication credential lifecycle + revocation + (f) align with FIDO2 + WebAuthn + similar standards.

• PSD2 RTS evidence for PSDTWO-5

• SCA exemptions + fraud reporting partial

Account servicing PSPs must offer at least one interface allowing secure communication with account information service providers, payment initiation service providers, and card based payment instrument issuers using identification, certificates, and audit trails.

• API documentation
• eIDAS certificate validation logs
• Performance and availability KPIs
• Fallback mechanism design
• Test sandbox availability

• No fallback or contingency mechanism
• Certificate validation incomplete
• Availability below ASPSP equivalent

Account servicing PSPs must comply with the data exchange requirements for AISPs and PISPs, including the same information available to the payment service user through their own online interface.

• API field mapping versus user interface
• Comparable view evidence
• Limits documentation
• Consent based access enforcement

• TPP API returns less data than user interface
• Consent scope not enforced server side
• Different latency for TPP versus direct channel

PSPs must ensure the confidentiality and integrity of personalised security credentials of the payment service user, including secure issuance, renewal, and storage.

• Credential lifecycle policy
• Secure storage (HSM or equivalent) records
• Renewal cadence
• Issuance verification logs

• Credentials stored in plain text or weak hashing
• Renewal exclusively user driven
• No segregation of duties on credential issuance

PSPs must ensure that the delivery of personalised security credentials, authentication devices, and software is secure and verifies the legitimate user identity at issuance.

• Identity proofing procedure
• Out of band delivery records
• Activation step evidence
• Anti tampering controls on devices

• Activation by knowledge factor alone
• No anti tampering on device packaging
• Identity proofing weakened in digital onboarding

PSPs must define and apply procedures for the renewal or reactivation of personalised security credentials, ensuring those procedures preserve at least the same level of security as initial issuance.

• Renewal SOP
• Reactivation flow design
• Logs of renewal events
• Comparison of renewal versus issuance controls

• Renewal via email link only
• Reactivation skips identity proofing
• No security review when renewing remotely

SCA may be exempted when the payment service user accesses only balance information or transaction history of the last 90 days, subject to applying SCA at least every 180 days or on first access.

• Exemption application matrix
• 180 day re authentication timer logs
• Limited data view configuration
• Audit log of exemptions invoked

• Re authentication interval exceeds 180 days
• Sensitive data shown under balance exemption
• No SCA on first access of session

SCA may be exempted for contactless electronic payment transactions where the individual amount does not exceed 50 EUR, the cumulative amount since the last SCA does not exceed 150 EUR, or the consecutive count does not exceed five.

• Issuer side counter configuration
• Cumulative tracking logs per card
• Forced SCA trigger evidence at threshold breach
• Limits review minutes

• Counters reset incorrectly across devices
• Forced SCA at threshold not triggered
• Wallet tokens treated separately from card limits

SCA may be exempted for electronic payment transactions initiated at unattended payment terminals for the purpose of paying a transport fare or parking fee, subject to documented controls.

• MCC scope documentation
• Terminal inventory under exemption
• Fraud monitoring on exempt flows
• Annual review of exemption scope

• Exemption used outside transport or parking MCCs
• No separate fraud monitoring on exempt flows
• Stale terminal inventory

SCA may be exempted when the payer initiates a payment to a beneficiary included in a list of trusted beneficiaries created by the payer, with the creation and amendment of the list itself requiring SCA.

• Trusted beneficiary list management procedure
• SCA logs on list additions
• User communication on adding trusted payee
• Removal workflow

• List edited without SCA
• Beneficiaries pre populated by PSP
• No notice to payer of trust status implications

SCA may be exempted for a series of electronic payment transactions with the same amount and to the same payee, with SCA applied to the first transaction of the series.

• First transaction SCA evidence
• Series binding records
• Variation detection logic
• Reauthentication on change

• Amount variations processed without new SCA
• Subscription change of payee not re authenticated
• No documented first transaction

SCA may be exempted for credit transfers between two payment accounts held by the same natural or legal person at the same payment service provider.

• Ownership verification records
• Beneficial owner mapping
• Self transfer routing logic
• Audit log of exempt transfers

• Joint accounts treated as same person without analysis
• Cross PSP transfers exempted incorrectly
• Ownership refresh not periodic

SCA may be exempted for remote electronic payment transactions where the amount does not exceed 30 EUR, with cumulative amount up to 100 EUR or up to five consecutive transactions since the last SCA.

• Issuer counter logic
• Cumulative tracking per PAN
• Forced SCA at breach
• Counter reconciliation tests

• Counters not enforced per PAN
• Currency conversion errors at threshold
• Forced SCA missed at exactly the limit

PSPs may apply an exemption based on transaction risk analysis subject to maintained fraud rates per exemption threshold band (500, 250, 100 EUR) and use of specified real time risk scoring elements.

• Fraud rate calculation per quarter
• TRA engine design
• Real time scoring factor list
• Threshold reductions when fraud rate breached
• Audit logs

• Fraud rates calculated incorrectly
• No reduction in TRA ceiling on breach
• TRA engine lacks behaviour or device analysis

Where the fraud rates exceed the reference fraud rate for two consecutive quarters in a given exemption band, the PSP must cease applying the TRA exemption for that band and notify the competent authority.

• Cessation procedures
• Notification templates
• Quarterly board review
• Reinstatement criteria evidence

• No cessation despite breach
• Reinstatement without sufficient quarters of low fraud
• Competent authority not notified

PSPs must monitor and report the fraud rates for each exemption band to competent authorities, calculated as the value of unauthorised or fraudulent transactions divided by the value of all transactions of the same type.

• Quarterly fraud rate reports
• Methodology documentation
• Audit reports verifying methodology
• Competent authority submissions

• Inconsistent methodology
• No independent audit of figures
• Cross border transactions excluded incorrectly

Per PSD2 Articles 95-96 + RTS: fraud reporting + incident management. Requirements include (a) implement Major Incident Reporting to competent authority within timelines per EBA guidelines + (b) maintain fraud monitoring + reporting to EBA + national supervisor twice yearly + (c) implement operational + security risk management framework + (d) maintain incident response capability + (e) implement business continuity + disaster recovery + (f) integrate with broader operational resilience (DORA alignment).

• PSD2 RTS evidence for PSDTWO-4

• SCA exemptions + fraud reporting partial

Payment service providers must apply Strong Customer Authentication when a payer accesses a payment account online, initiates an electronic payment transaction, or carries out an action through a remote channel that may imply a risk of payment fraud.

• SCA application matrix by channel
• Authentication policy
• Risk based mapping of remote actions
• Annual SCA review minutes

• SCA not applied to non payment account actions with fraud risk
• Outdated mapping missing new digital channels
• Reliance on legacy single factor for sensitive actions

The authentication code must be generated from two or more elements categorised as knowledge, possession and inherence, with breach of one element not compromising the reliability of the others, and the code itself being non reusable.

• Authenticator design document
• Single use code generation logs
• Independence assessment of factors
• Failed reverse engineering test results

• SMS OTP delivered to same device as authentication app
• Static codes accepted across multiple sessions
• Knowledge factor recoverable from possession element

For remote electronic payment transactions the authentication code must be dynamically linked to a specific amount and a specific payee, with the payer informed of both at the time of authentication.

• Dynamic linking design notes
• Sample challenge screens showing amount and payee
• Test results for tampered amounts triggering reject
• Audit logs binding code to transaction parameters

• Authentication code valid even when amount changes
• Payee not displayed at challenge
• Mobile app challenge shows transaction reference only

The knowledge element must include measures to mitigate against being disclosed to, or discovered by, unauthorised parties, including limits on attempts and protection against logging or screen capture.

• Password policy and complexity rules
• PIN handling design
• Attempt lockout configuration
• Mobile app screen recording prevention

• No lockout on PIN entry
• Knowledge factor cached client side
• PIN echoed in clear during entry

The possession element must include measures designed to prevent replication of the element, including device binding, hardware backed key storage, or app integrity checks.

• Device binding registration logs
• Secure enclave or TEE usage
• Root or jailbreak detection results
• App attestation reports

• No root detection on Android wallets
• Possession credentials portable across devices
• Lack of rebinding after device reset

The inherence element must include measures to mitigate against unauthorised use of the element through access by unauthorised parties, including liveness detection and template protection.

• Biometric algorithm performance metrics (FAR FRR)
• Liveness detection test reports
• Template encryption and storage design
• Fallback policy when biometric fails

• Photo or video defeats face recognition
• Templates stored centrally without protection
• No fallback that maintains SCA strength

Use of multiple authentication elements on a single multi purpose device requires segregation in the execution environment between the elements so a breach of one does not compromise the others.

• Sandboxing design
• Secure element usage
• App architecture diagrams
• Out of band channel evidence

• Both factors held in same app without segregation
• Lack of OS sandboxing usage
• No documented breach containment analysis

Per PSD2 + EBA Guidelines: governance + risk + compliance. Requirements include (a) implement comprehensive Information Security Program Management + Board and Management Oversight + Risk Appetite and Tolerance for IT Risk + (b) implement Security Policy Framework + Roles and Responsibilities + (c) implement Network Security and Segmentation + Endpoint Protection + Application Security + (d) cooperate with EBA + national supervisor + (e) maintain compliance monitoring + reporting + (f) integrate with DORA + GDPR.

• PSD2 RTS evidence for PSDTWO-6

• SCA exemptions + fraud reporting partial

Per PSD2 RTS Articles 19-36: common and secure communication. Requirements include (a) implement dedicated Account Information Services (AIS) + Payment Initiation Services (PIS) interface (API) for Third Party Providers (TPPs) + (b) maintain TPP authentication using eIDAS qualified certificates (QWAC + QSealC) + (c) ensure API availability + performance + (d) maintain fallback mechanism in case of API unavailability + (e) implement consent management for AIS + PIS + (f) maintain audit trail for TPP access + (g) cooperate with TPPs + competent authorities.

• PSD2 RTS evidence for PSDTWO-3

• SCA exemptions + fraud reporting partial

Per PSD2 Regulatory Technical Standards (RTS) on SCA + Common and Secure Communication: implement SCA. Requirements include (a) implement Strong Customer Authentication using two or more independent elements from knowledge (password + PIN) + possession (mobile + token + card) + inherence (biometric) for (i) account access + (ii) electronic payment initiation + (iii) any action involving risk of fraud or other abuse + (b) maintain element independence - compromise of one does not compromise others + (c) implement dynamic linking for electronic payment transactions binding amount + payee to authentication code + (d) maintain SCA mechanism resilience against replay + interception + (e) document SCA implementation + risk assessment.

• PSD2 RTS evidence for PSDTWO-1

• SCA exemptions + fraud reporting partial

Per PSD2 RTS Articles 10-18: SCA exemptions. Requirements include (a) implement Low-Value Exemption for amounts up to EUR 30 cumulative EUR 100 + (b) implement Trusted Beneficiary Exemption for whitelisted payees + (c) implement Recurring Transaction Exemption for subsequent transactions in series + (d) implement Corporate Payment Exemption for B2B payments using secure dedicated processes + (e) implement Transaction Risk Analysis (TRA) Exemption based on real-time risk assessment + fraud rate thresholds + (f) maintain audit trail + fraud rate monitoring per Article 18.

• PSD2 RTS evidence for PSDTWO-2

• SCA exemptions + fraud reporting partial