PSD2 strong customer authentication (SCA) testing requirements
PSD2 strong customer authentication (SCA) is the EU rule, set by Directive (EU) 2015/2366 Article 97 and Delegated Regulation (EU) 2018/389, that payment service providers authenticate payers with two independent elements for online account access and electronic payments. SCA testing verifies single-use codes, lockout limits, dynamic linking, and exemption conditions. FintechAssuranceLabs delivers a requirement-to-test traceability matrix with execution logs.
- Jurisdiction
- EU and EEA (Directive (EU) 2015/2366 and Delegated Regulation (EU) 2018/389); UK under the FCA SCA-RTS
- Primary source
- eur-lex.europa.eu
Engineering interpretation of testing requirements, not compliance advice.
What PSD2 and the RTS on strong customer authentication require
Directive (EU) 2015/2366 (PSD2) Article 97(1) requires a payment service provider to apply strong customer authentication when the payer accesses a payment account online, initiates an electronic payment transaction, or carries out a remote action that may imply a risk of payment fraud. Article 97(2) adds dynamic linking for remote electronic payments: the authentication links the transaction to a specific amount and a specific payee.
The detailed rules sit in Commission Delegated Regulation (EU) 2018/389, the regulatory technical standards (RTS) on strong customer authentication (EUR-Lex, checked on 2026-09-16). The RTS applies from 14 September 2019 (Article 38(2)). The requirements that change test scope:
- Authentication code (Article 4). The code is accepted only once. A failed authentication does not reveal which element was wrong. No more than five consecutive failed attempts are allowed before a block. Online account access ends after at most 5 minutes without payer activity.
- Dynamic linking (Article 5). The payer sees the amount and the payee. The code is specific to that amount and payee, and any change to either invalidates the code.
- Elements and devices (Articles 6 to 9). A breach of one element does not compromise the others. When an element or the code runs on a multi-purpose device such as a phone, the provider uses separated secure execution environments and detects alteration of the software or device (Article 9(3)).
- Exemptions (Articles 10 to 18). The exemptions cover account information access, contactless and low-value payments, trusted beneficiaries, recurring payments, and transaction risk analysis (TRA), among others. Delegated Regulation (EU) 2022/2360 extended the SCA renewal period for account information access from 90 days to 180 days and added a mandatory exemption for access through an account information provider (Article 10a), applicable from 25 July 2023 (EBA final report EBA/RTS/2022/03, checked on 2026-09-16).
- Fraud rates and monitoring (Articles 18 to 21). TRA is allowed only while the provider's fraud rate stays at or below the Annex reference rate for the exemption threshold value: for remote card payments, 0.13% up to EUR 100, 0.06% up to EUR 250, and 0.01% up to EUR 500. Article 19 calculates the rate by value over a rolling 90-day quarter, including both SCA-authenticated and exempted payments.
- Review of security measures (Article 3). SCA measures are documented, periodically tested, evaluated, and audited. A provider that uses TRA has its methodology, model, and reported fraud rates audited at least yearly.
The financial consequence sits in PSD2 Article 74(2): when the payer's provider does not require strong customer authentication, the payer bears no financial loss unless the payer acted fraudulently. Card payments in the EEA usually apply SCA through EMV 3-D Secure; the EMV 3DS testing requirements page covers the message flow. In the UK, the FCA applies its own SCA-RTS, which added an Article 10A exemption through PS21/19 (checked on 2026-09-16). The successor EU package is tracked on the PSD3 and PSR page.
What SCA testing verifies
| Requirement | What we test | Evidence produced |
|---|---|---|
| Article 4(1): an authentication code is accepted once | Resubmission of a used one-time code or signed challenge on login and payment endpoints | Replay test log with the server response to each resubmission |
| Article 4(3)(a): a failure does not show which element was wrong | Wrong knowledge element with a correct code, a correct knowledge element with a wrong code, and both wrong | Response body and error code comparison for each failure combination |
| Article 4(3)(b): at most five consecutive failed attempts before a block | The failed attempt counter across web, app, and API channels and after a new session starts | Lockout test log with the attempt count per channel |
| Article 4(3)(d): online account access ends after 5 minutes without activity | An authenticated session left idle for 5 minutes, then a request to the account | Session timeout log with request timestamps |
| Article 5(1): the code is linked to the amount and the payee | The amount and payee on the authentication screen against the executed payment, and a change of amount or payee after authentication | Amount and payee comparison log from display to execution |
| Article 9(3): multi-purpose device protection | Login and payment on a rooted or jailbroken device and with a modified app binary | Device integrity test report per operating system |
| Article 10a: SCA through an account information provider every 180 days | Access requests through a test provider on day 179, day 181, and after a new SCA | Access decision table with request dates |
| Article 11: contactless limits of EUR 50 per payment, EUR 150 cumulative, or five consecutive payments | Payments at and above each limit and the counter reset after SCA | Counter boundary test cases with the issuer decision |
| Article 14: recurring series with the same amount and the same payee | SCA on creation, amendment, and first payment, and a subsequent payment with a changed amount | Exemption decision table for each series change |
| Articles 18 and 19: TRA only within the reference fraud rate | Exemption decisions on synthetic transactions around the EUR 100, EUR 250, and EUR 500 thresholds, and a fraud rate recalculation | Recalculated fraud rate per band with the TRA decision for each transaction |
The SCA exemptions testing guide lists exemption request fields and test data for card payments.
Artifacts auditors and competent authorities request
- The Article 3 audit report on SCA security measures, which the provider makes available to the competent authority on request.
- The elements used per channel, with the category of each element and the independence rationale under Article 9.
- Test evidence that the security measures were periodically tested, as Article 3(1) requires.
- For TRA users, the fraud rate methodology, the model, and the fraud rate figures per transaction type (Article 19(3)), with the yearly audit, done by an independent external auditor in the first year and at least every 3 years (Article 3(2)).
- Quarterly monitoring data per exemption: fraud value, total value, average transaction value, and the number and share of exempted payments (Article 21).
- The report to the competent authority when a monitored fraud rate exceeds the reference rate, with the planned measures (Article 20(1)).
- For account servicing providers: interface technical documentation and a testing facility for third-party providers (Article 30(3) and 30(5)), and quarterly availability and performance statistics for the dedicated interface (Article 32(4)).
Common SCA findings
- Reusable one-time code. The code stays valid for its full lifetime and a second submission of the same code authorises a second login. The defect breaks Article 4(1).
- Error message reveals the failed element. The app shows "incorrect PIN" for one failure and "code expired" for another. The defect breaks Article 4(3)(a).
- Attempt counter per channel. Five failures on web and five more in the app never trigger a block, or the counter resets on a new session. The defect breaks Article 4(3)(b).
- Payee editable after authentication. A credit transfer confirmation screen lets the user change the IBAN after the one-time code is entered, and the transfer executes with the original code. The executed payment has no authentication code linked to its payee, which breaks Article 5(1)(d).
- Recurring exemption on a variable amount. A subscription with usage-based charges uses the recurring exemption for each charge. The defect breaks Article 14, which covers only a series with the same amount and the same payee.
- Trusted beneficiary added without SCA. The web interface requires SCA to add a trusted payee, but the mobile API endpoint does not. The defect breaks Article 13(1).
- 90-day prompt on account information access. A legacy configuration still asks customers of an account information provider to authenticate every 90 days, which breaks Article 10a(1).
- Fraud rate calculated by count. The TRA engine divides fraudulent transactions by total transactions, or leaves out fraud on SCA-authenticated payments. The defect breaks the value-based calculation in Article 19(1).
How we cover PSD2 SCA
Mobile app testing delivers the biometric login and step-up authentication test report and mobile app security checks against OWASP MASVS, which cover Articles 4 and 9 on phones. Payment flow testing maps every authentication branch in the payment flow map and states the financial impact of each SCA defect in the defect log. Open banking API testing runs the consent and reauthorisation flow test suite against Articles 10a and 30 to 33. Card issuing testing checks the Article 11 contactless counters in the spend control and authorisation rule test matrix.
We test SCA flows for neobanks, business banking, spend management cards, Banking-as-a-Service programmes, open banking providers, remittance, and buy now pay later checkouts. For an audit under Article 3, audit evidence testing maps each RTS article to test cases in a requirement-to-test traceability matrix and hands over a test evidence pack per audit scope, with retest evidence after remediation.
Related
Services
Segments
- Neobanks and digital banking
- Payment acquiring
- Open banking and data aggregation
- Banking-as-a-Service and card issuing
- Spend management and corporate cards
- Business banking
- International transfers
- Buy now pay later
- Family and youth banking
- Subscription billing and revenue management
- Accounting and invoicing
- AP/AR automation and treasury
- POS and merchant services
- Revenue-based financing and factoring
Adjacent standards
Questions
What is PSD2?
What is strong customer authentication?
When is strong customer authentication required?
Scope your testing
Send FintechAssuranceLabs your product, segment, money flows, and the standards that need evidence, and get a proposed test scope with its deliverables.
Scope your testing