Skip to content

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

RequirementWhat we testEvidence produced
Article 4(1): an authentication code is accepted onceResubmission of a used one-time code or signed challenge on login and payment endpointsReplay test log with the server response to each resubmission
Article 4(3)(a): a failure does not show which element was wrongWrong knowledge element with a correct code, a correct knowledge element with a wrong code, and both wrongResponse body and error code comparison for each failure combination
Article 4(3)(b): at most five consecutive failed attempts before a blockThe failed attempt counter across web, app, and API channels and after a new session startsLockout test log with the attempt count per channel
Article 4(3)(d): online account access ends after 5 minutes without activityAn authenticated session left idle for 5 minutes, then a request to the accountSession timeout log with request timestamps
Article 5(1): the code is linked to the amount and the payeeThe amount and payee on the authentication screen against the executed payment, and a change of amount or payee after authenticationAmount and payee comparison log from display to execution
Article 9(3): multi-purpose device protectionLogin and payment on a rooted or jailbroken device and with a modified app binaryDevice integrity test report per operating system
Article 10a: SCA through an account information provider every 180 daysAccess requests through a test provider on day 179, day 181, and after a new SCAAccess decision table with request dates
Article 11: contactless limits of EUR 50 per payment, EUR 150 cumulative, or five consecutive paymentsPayments at and above each limit and the counter reset after SCACounter boundary test cases with the issuer decision
Article 14: recurring series with the same amount and the same payeeSCA on creation, amendment, and first payment, and a subsequent payment with a changed amountExemption decision table for each series change
Articles 18 and 19: TRA only within the reference fraud rateExemption decisions on synthetic transactions around the EUR 100, EUR 250, and EUR 500 thresholds, and a fraud rate recalculationRecalculated 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.

Questions

What is PSD2?

PSD2 is Directive (EU) 2015/2366, the second EU Payment Services Directive, which Member States applied from 13 January 2018. PSD2 sets authorisation and conduct rules for payment service providers, gives account information and payment initiation providers access to online payment accounts, and requires strong customer authentication under Article 97.

What is strong customer authentication?

Strong customer authentication (SCA) is authentication based on two or more independent elements from the categories knowledge, possession, and inherence, as PSD2 Article 4(30) defines it. Under Delegated Regulation (EU) 2018/389, SCA generates an authentication code that is accepted once, and the code for a remote payment is linked to the amount and the payee.

When is strong customer authentication required?

PSD2 Article 97(1) requires strong customer authentication when a 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. Articles 10 to 18 of Delegated Regulation (EU) 2018/389 list the exemptions and the conditions under which a payment service provider does not apply SCA.

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