Accessibility, Inclusive Payments and PSD3

Strong customer authentication can exclude people, and that exclusion is a real risk, not an edge case. A customer with poor eyesight may not read a one time code, a customer with arthritis may struggle with a fingerprint sensor, an older customer may not own a smartphone, and a customer in a rural area may have no mobile signal when the code arrives. PSD2 already said authentication must be accessible, but As agreed, PSD3 would make the expectation clearer, because banks must offer methods that work for customers with different needs. A bank that offers only an app based approval is effectively telling some customers they cannot pay online, and that is not acceptable to regulators. As agreed, PSD3 would expect banks to provide more than one authentication method, and to let the customer choose the method that works for them. Options can include a hardware token with large buttons, a phone call with a spoken code, a code sent by post for some journeys, or authentication inside a branch. The method must still meet the two factor rule, so a single code by post is not enough on its own, but combined with a password it can work. The bank must also make its screens readable, with clear language, good contrast, and compatibility with screen readers. A business analyst should ask which methods exist, who can use each one, and what happens when the preferred method fails. Inclusive payments go further than authentication, because they cover the whole journey from opening an account to making a payment and checking a balance. An inclusive design uses plain language instead of jargon, shows the amount and the payee clearly before the customer confirms, and gives the customer time to check without a countdown that causes panic. It also means that a customer who cannot use digital channels can still pay by phone or in a branch, and that a customer who makes a mistake can correct it before the money moves. Testing should try the journey with a screen reader, with large text, and with no smartphone, and record where customers get stuck. The cost of getting this wrong is not just a complaint, it is a customer who stops using the bank and loses independence. Banks must also consider customers who act through someone else, such as a person with power of attorney or a carer who helps an elderly relative. The third party must be able to authenticate and authorise within the limits of their authority, and the bank must record who acted and on whose behalf. This is where open banking consent and authentication meet, because a delegated user needs their own factors, not the account holder password. A product owner should treat delegated access as a full journey, with its own consent screen, its own limits, and its own audit trail, because a regulator will ask how the bank knows the payment was truly authorised. A worked example shows inclusive payments in practice. A customer who is blind uses a screen reader to pay a bill through their bank's mobile app. The app must be accessible: every button must have a label the screen reader can read, every field must be navigable by keyboard, and the strong customer authentication flow must work with the screen reader. If the authentication requires the customer to read a code from a push notification that the screen reader cannot access, the customer cannot pay, and the bank has failed to provide an accessible service. The bank must test its app with assistive technology, and must provide an alternative authentication method, such as a voice call, for customers who cannot use the standard flow. Accessibility is not a nice to have; it is a regulatory requirement, and a bank that does not provide it can be fined. For a business analyst, the requirement is to define the accessibility requirements for each customer journey, the assistive technologies to test with, and the alternative authentication methods. A failure scenario tests the alternative. A customer who cannot use a push notification because their phone does not support it is offered a voice call as an alternative for strong customer authentication. The bank calls the customer, reads a one time code, and the customer enters it. The payment is authorised. If the bank had no alternative, the customer could not pay, and the bank would have to explain why to the regulator. The alternative must be as secure as the standard method: a voice call that reads a code is secure if the code is single use and time limited, but it is not secure if the code can be reused or if the call is not authenticated. Last reviewed 7 November 2026. Further reading: PSD2 Directive (EU) 2015/2366; European Accessibility Act; bank accessibility standards. Worked example with numbers: a customer with poor eyesight wants to pay EUR 240 online, and the bank offers a hardware token with large buttons that reads the code aloud, instead of a one time code on a small phone screen. The customer presses the token, hears the code, enters it, and the payment is approved, because the bank provided a method the customer can use. If the bank had offered only a fingerprint sensor, the customer could not have authenticated, and the payment would have failed, even though the customer had the money and wanted to pay. The cost of the token is a few euros, while the cost of excluding the customer is the loss of a customer and a complaint to the regulator. Failure and recovery: inclusive payments fail when a design assumes every customer can see, hear, type and own a smartphone, and the failure is a customer who cannot pay. A customer with a power of attorney may need to authorise a payment for an elderly relative, and the bank must let the authorised person authenticate within the limits of their authority, not block them because they are not the account holder. If the bank blocks a carer who is properly authorised, the elderly relative cannot pay, and the carer must call the bank, which takes days. The recovery is a design that supports delegated authority from the start, with a clear route for a carer or attorney to authenticate. For a business analyst, product owner or subject matter expert, the accessibility requirement must state that the bank provides more than one authentication method, lets the customer choose, and supports customers who act through someone else, such as a person with power of attorney or a carer. The requirement must also state that inclusive design covers the whole journey, from opening an account to making a payment and checking a balance, using plain language instead of jargon, and showing the amount and the payee clearly before approval. The test pack must include a customer with poor eyesight, one with arthritis, and one acting through a power of attorney. Source: PSD2; European Accessibility Act; last reviewed 7 November 2026.