PSD2 and Open Banking

The European Union's second Payment Services Directive, known as PSD2, changed the relationship between banks and their customers by giving customers the right to share their account data with third parties. Under PSD2, a bank must allow licensed third party providers to access a customer's account, with the customer's explicit consent, through secure APIs. There are two main types of provider. An Account Information Service Provider aggregates account data from several banks so the customer can see all their finances in one place. A Payment Initiation Service Provider lets a customer pay directly from their bank account from inside another app, such as an online shop, without entering card details. The bank remains responsible for the account and for strong customer authentication, but it no longer controls the whole customer experience. Strong customer authentication, or SCA, is the security rule that sits at the centre of PSD2. It requires two out of three factors for electronic payments. Something the customer knows, such as a password, something they have, such as a phone, and something they are, such as a fingerprint. This is why paying online in Europe now usually involves a push notification to a banking app or a biometric check. There are exemptions for low value and low risk payments, and the rules are complex, but the principle is clear. A single password is no longer enough. A BA working on payment journeys must design the SCA flow into the experience, including what happens when authentication fails, when a customer has no smartphone, and when a payment is exempt. Open banking has spread beyond Europe, with similar regimes in the United Kingdom, Australia, Brazil, India and elsewhere, each with its own rules and timelines. The business impact is significant, because banks lose their monopoly on the customer interface, and fintech companies can build services on top of bank accounts. For banks, the response has been to build good APIs, to offer their own aggregation and initiation services, and to monetise premium API access. For a BA, open banking work means understanding the regulatory requirements, the consent model, the API specifications, and the liability rules, because when a third party initiates a payment that goes wrong, the question of who is responsible must have a clear answer. A worked example shows PSD2 in practice. A customer of Bank A wants to pay a merchant using a payment initiation service provider, a PISP, rather than logging into Bank A's own app. The customer selects the PISP at checkout, is redirected to Bank A to authenticate with strong customer authentication, and consents to the payment. The PISP calls Bank A's payment initiation API with the customer's consent, and Bank A executes the payment. The customer never gives their Bank A password to the PISP, and the PISP never sees the customer's account balance. The payment settles as a normal credit transfer, and the merchant is credited. The PISP is regulated, it must be licensed, and it must carry professional indemnity insurance. For a business analyst, the requirement is to define the consent flow, the authentication steps, the API calls, and the liability if the payment goes wrong: the PISP is liable if it initiates a payment the customer did not consent to, and the bank is liable if it executes a payment without a valid consent. A failure scenario tests the consent. A customer consents to a payment of EUR 100 to a merchant, but the PISP initiates a payment of EUR 1,000. Bank A's API must reject the payment, because the amount does not match the consent, and must return a 422 error with a code indicating the consent mismatch. The bank must also log the attempt and notify the customer. If the bank executes the payment without checking the consent, it has breached its PSD2 obligations and is liable for the loss. The consent check is not optional: it is the control that prevents a PISP from initiating payments the customer did not agree to. PSD3, which is agreed but not yet law as of 7 November 2026, strengthens these controls further, but PSD2 remains the law in force. Last reviewed 7 November 2026. Further reading: PSD2 Directive (EU) 2015/2366; Berlin Group NextGenPSD2 API framework; European Banking Authority regulatory technical standards on strong customer authentication. Take a customer who uses a budgeting app that shows accounts from three banks. The customer consents in the app, is redirected to each bank to authenticate, and the app receives an access token for each bank. The app then calls each bank's account information API every morning and shows the customer a single view of their money. When the customer wants to pay a bill from the app, the app calls the payment initiation API, the customer authenticates with the bank, and the payment is made. The bank never sees the budgeting app's interface, and the app never sees the customer's bank password. That separation is the point of PSD2, and it is what makes the whole model work. Consent failures are the most sensitive part of open banking. Suppose a third party initiates a payment that the customer did not authorise, because the third party's system was compromised. The customer complains to the bank, the bank says the payment came through a licensed third party, and the third party says it acted on the customer's instruction. The liability rules must answer who pays, and the answer depends on the country, the type of provider, and whether strong customer authentication was performed. A BA must capture the liability matrix in requirements, the consent record that proves what the customer agreed to, and the dispute process that resolves it, because a payment that goes wrong through a third party is still the bank's problem to explain. Open banking requirements are regulatory requirements first and product requirements second. The BA must know the consent model: what the customer consents to, how long the consent lasts, how it is revoked, and what happens to data already shared. The BA must know the SCA exemptions: low value, recurring, trusted beneficiary, and when each one applies. And the BA must know the performance rules, because regulators set response times for bank APIs and fine banks that are too slow. A BA who treats open banking as a product feature without the regulatory layer will build something that fails its first compliance review.