Fraud Prevention Under PSD3 and Customer Education

Fraud in open banking takes many forms, but the most harmful is authorised push payment fraud, where a criminal tricks a customer into sending money to a criminal account. The customer authenticates the payment, so the bank sees a valid instruction, and the money leaves at once. The criminal may pretend to be the bank, a supplier, or a family member, and may use a fake invoice or a spoofed phone number. As agreed, PSD3 would respond by requiring better verification before payment, faster sharing of fraud information between banks, and clearer refund rules when a customer is tricked. The goal is to stop the payment before it settles, because recovery after settlement is slow and often fails. Banks prevent fraud with layered controls that run before, during and after the payment. Before the payment, the bank checks the device, the location, the payee history and the customer behaviour, and it verifies the payee name against the account. During the payment, the bank applies SCA and shows the customer a clear confirmation screen with the amount and the payee. After the payment, the bank monitors for unusual patterns and can warn the customer if the money went to a new payee at an unusual hour. No single control stops all fraud, and a bank that relies only on SCA will miss fraud where the customer was tricked into authenticating, which is why the layers must work together. Testing should try a new payee with a mismatched name, a large amount at 3 a.m., and a payment from a new device. As agreed, PSD3 would strengthen the customer refund position when fraud happens. If a payment was unauthorised, meaning the customer did not approve it, the bank must refund it promptly unless it can prove the customer acted fraudulently or with gross negligence. If the customer was tricked into authorising the payment, the position is more complex, but PSD3 as agreed, and national rules, would increasingly require the bank to assess whether its own controls were good enough, and to refund in cases where the bank failed to warn or to verify. A business analyst should know the refund rules for the country in question, because they shape the complaint journey, the evidence the bank must keep, and the wording of the customer messages. Customer education is now part of the fraud control, because the best technology cannot stop a customer who is convinced the caller is genuine. Banks must warn customers in plain language at the moment of payment, for example by showing a message that the bank will never ask for a full password by phone, or that a new payee should be checked before the first payment. Education must also happen outside the payment journey, through messages, letters and online guidance that explain common scams. A product owner should treat these warnings as design, not as legal text, because a warning that nobody reads is the same as no warning at all, and the regulator will ask for evidence that customers saw and understood it. A worked example shows fraud prevention under PSD2. A customer receives a text message claiming to be from their bank, saying their account has been compromised and asking them to click a link to verify. The customer clicks the link, enters their password and a one time code, and the fraudster uses them to log into the customer's account and send EUR 5,000 to an account it controls. The bank's fraud engine detects the payment because the beneficiary is new, the amount is ten times the customer's normal payment, and the login came from a device the customer has never used. The bank blocks the payment and calls the customer, who confirms they did not send it. The payment is rejected, the account is frozen, and the customer is asked to change their credentials. The bank also reports the fraud to the regulator and to the police. For a business analyst, the requirement is to define the fraud detection rules, the action for each risk score, and the customer education that helps customers recognise phishing. A failure scenario tests the education. A customer who has been educated about phishing still clicks a link in a text message, because the message is convincing and the customer is in a hurry. Education alone does not prevent fraud; the bank must also have technical controls, such as transaction risk analysis, device fingerprinting, and confirmation of payee, that catch the fraud even when the customer is tricked. Confirmation of payee, which checks that the name the customer entered matches the name on the account, would have caught this fraud, because the fraudster's account is in a different name from the one the customer intended. The bank must implement confirmation of payee for all payments where it is available, and must warn the customer when the name does not match. Last reviewed 7 November 2026. Further reading: PSD2 Directive (EU) 2015/2366; UK Payment Systems Regulator APP fraud reimbursement rules, in force 7 October 2024. Worked example with numbers: a criminal tricks a customer into sending GBP 5,000 to a criminal account, and the customer authenticates the payment, so the bank sees a valid instruction. The bank checks the device, the location, the payee history and the customer behaviour, and sees that the customer has never paid this payee before, that the device is new, and that the payment is large, so it holds the payment and shows the customer a warning that the payee may be a fraudster. If the customer confirms, the bank releases the payment, but if the customer stops, the bank saves GBP 5,000. The warning must appear at the moment of payment, in plain language, because a warning that arrives after the payment has settled is a warning that arrives too late. Failure and recovery: fraud prevention fails when the controls are too weak or too strong, and both failures cost money. If the controls are too weak, a fraudster gets through, and the bank must refund the customer if the payment was unauthorised, unless it can prove the customer acted fraudulently or with gross negligence. If the controls are too strong, genuine customers are blocked, and the merchant loses sales. The recovery for a fraud is a prompt refund for an unauthorised payment, a clear explanation of what happened, and a review of the controls that missed it, because a control that misses a fraud once will miss it again. Customer education is part of the control, because the best technology cannot stop a customer who is convinced the caller is genuine. For a business analyst, product owner or subject matter expert, the fraud requirement must state the layered controls, device, location, payee history, customer behaviour and verification of payee, and must state that they run before, during and after the payment. The requirement must also state the refund position, an unauthorised payment must be refunded promptly unless the bank can prove fraud or gross negligence, and must state that PSD3 as agreed would strengthen that position, while PSD2 is the law in force. The test pack must include an authorised push payment fraud, an unauthorised payment, and a genuine payment that the controls wrongly block. Source: PSD2; UK Payment Systems Regulator; last reviewed 7 November 2026.