Strong Customer Authentication and PSD3 Enhancements

Strong customer authentication requires two out of three factors, something the customer knows, such as a password or PIN, something the customer has, such as a phone or a card, and something the customer is, such as a fingerprint or face. The two factors must be independent, so losing one must not compromise the other. When a customer pays online, the bank asks for two factors, for example a fingerprint on the phone plus a one time code, before it allows the payment. The bank must also link the authentication to the amount and the payee, a rule called dynamic linking, so the approval cannot be reused for a different payment. If the amount changes after approval, the authentication is no longer valid. PSD2 introduced SCA, but its first years were painful, because banks, merchants and customers each built their own journeys and many payments failed. Customers did not understand why a routine purchase suddenly needed a code, merchants saw abandoned baskets rise, and banks struggled with customers who had no smartphone. Regulators allowed exemptions, such as low value payments below EUR 30, recurring payments after the first one, and trusted beneficiaries the customer had whitelisted. Even with exemptions, the friction stayed high, and the industry learned that security without usable design simply pushes customers to another channel. As agreed, PSD3 would keep the two factor rule but improve how it is applied. It clarifies the exemptions so banks and merchants apply them the same way, it improves the treatment of recurring payments and merchant initiated transactions, and it requires clearer information when authentication fails. It also strengthens the rules on liability, so when a payment is made without proper authentication and the customer did not act fraudulently, the refund path is faster and clearer. The Payment Services Regulation adds detail on how authentication must work for different channels, including phone and branch, so a customer who cannot use an app is not locked out of paying. A key agreed PSD3 improvement is the handling of transaction risk analysis, which lets a bank skip SCA when its fraud systems rate a payment as low risk. The bank looks at the device, the location, the amount, the payee history and the customer behaviour, and if the risk is low it can allow the payment without a challenge. This is not a loophole, because the bank carries the fraud risk when it skips SCA, and the regulator sets limits on how often and how much can be exempted. For a product owner, this means the authentication journey is a risk decision, not a fixed screen, and the rules for when to challenge and when to trust must be written, tested and monitored. Testing must cover a wrong code, an expired code, a changed amount after approval, and a cancelled journey. A worked example shows strong customer authentication in action. A customer pays EUR 500 online using a card. The merchant's payment service provider redirects the customer to their bank, where they authenticate with two factors: something they know, their password, and something they have, a one time code sent to their phone. The bank verifies both factors, confirms the payment, and the customer returns to the merchant. The whole flow takes 30 seconds. If the customer fails one factor, the payment is not authorised, and the merchant is told the authentication failed. Strong customer authentication is required by PSD2 for most electronic payments, with exemptions for low value payments, recurring payments, and trusted beneficiaries. The exemptions are not loopholes: they are defined in the regulation, and the bank must apply them correctly. A payment of EUR 500 is above the low value exemption, so it requires strong customer authentication. A payment of EUR 20 to a trusted beneficiary may be exempt. A failure scenario tests the exemption. A fraudster who has stolen a customer's card details tries to pay EUR 25 online, hoping the low value exemption means no strong customer authentication is required. The bank's risk engine scores the transaction as high risk, because the device is new, the IP address is in a different country, and the merchant is one the customer has never used. The bank therefore requires strong customer authentication despite the low value, because the exemption is conditional on the risk being low. This is transaction risk analysis: the bank can exempt a payment from strong customer authentication only if it has analysed the risk and found it to be low. A bank that exempts every low value payment without risk analysis is in breach of the regulation. Last reviewed 7 November 2026. Further reading: PSD2 Directive (EU) 2015/2366; European Banking Authority regulatory technical standards on strong customer authentication. Worked example with numbers: a customer pays EUR 240 online with a card, and strong customer authentication asks for two factors, a fingerprint on the phone and a one time code sent by text, which are two independent factors, something the customer is and something the customer has. The bank links the authentication to the amount EUR 240 and to the payee, so the approval cannot be reused for a different payment. If the customer pays EUR 25 for a coffee, the bank may skip authentication under the low value exemption, because the risk is low, but if the customer pays EUR 240 five times in an hour, the bank must ask for authentication again, because the velocity rule has been breached. Failure and recovery: SCA fails when the customer cannot complete it, and the failure is a payment that is declined or abandoned. A customer with poor eyesight may not read a one time code, a customer with arthritis may struggle with a fingerprint sensor, and an older customer may not own a smartphone, so the bank must offer more than one authentication method, and must let the customer choose the method that works for them. If the customer fails authentication three times, the bank must lock the method and offer another one, not keep asking for the same method, because a customer who fails three times will abandon the purchase. The recovery is an alternative method, such as a hardware token or a phone call with a spoken code. For a business analyst, product owner or subject matter expert, the SCA requirement must state the two factor rule, the exemptions, and the agreed PSD3 improvements, which clarify the exemptions, improve the treatment of recurring payments, and require clear communication when authentication is needed. The requirement must state that PSD3 is agreed but not yet law, so the improvements are described as agreed, not as in force. The requirement must also state the transaction risk analysis rule, which lets a bank skip SCA when its fraud systems rate a payment as low risk. The test pack must include a successful authentication, a failed authentication, a low value exemption, and a velocity breach. Source: PSD2; European Banking Authority; last reviewed 7 November 2026.