Data subject rights in payments: access, erasure and the AML wall

A customer has the right to ask a bank what personal data it holds about them, and the bank must answer within one month under Article 15. For a payments customer that answer is a list of every payment they sent and received, every screening decision made about them, every fraud score assigned, and every third party the data was shared with, including correspondent banks and scheme operators. Building that answer by hand takes weeks, so the bank needs a subject access request process that pulls the payment history, the screening log and the sharing register together in one place. The right to erasure under Article 17 is the one that causes the most confusion in payments. A customer can ask for their data to be deleted, but Article 17(3)(b) says erasure does not apply where processing is necessary for compliance with a legal obligation. Anti-money-laundering law is exactly such an obligation. The bank must keep the transaction record for the statutory period, and must tell the customer why it is keeping it. The customer can still have their marketing profile deleted, their contact preferences removed, and their data erased from systems that have no legal reason to hold it. The right to rectification matters more in payments than most people expect. A wrong beneficiary name on a payment, a misspelt payer name in a screening hit, or an incorrect address in a KYC record all create real harm, because they cause payments to be delayed, blocked or returned. Article 16 gives the customer the right to have inaccurate data corrected without undue delay, and the correction must flow to every system that holds the wrong value, including the screening engine and the correspondent bank that received the payment. Data portability under Article 20 lets a customer take their payment history in a structured, commonly used and machine-readable format. For a current account that means a statement file, and for a payment initiation service it means the consent record and the payment history the service created. The practical consequence for a product owner is that the export format must be specified in the requirements, and the export must not leak another customer's data, which happens when a joint account or a bulk payment file is exported without filtering. The right to object and the right to restrict processing both have payment consequences. A customer can object to profiling, which includes the fraud scoring that decides whether a payment is held for review. The bank can continue the profiling if it has compelling legitimate grounds, and fraud prevention is such a ground, but it must be able to explain that to the customer. A restriction request can freeze a payment investigation, so the operations team needs a procedure that honours the restriction without destroying the evidence the investigation needs. Automated decision making under Article 22 is directly relevant to instant payments. When a payment is blocked by an automated screening rule, or a fraud score decides that a payment needs manual review, that is a decision based solely on automated processing with a legal or similarly significant effect. The customer has the right to human intervention, to express their point of view, and to contest the decision. The payment hub must therefore log the rule that fired, the score, and the human reviewer who confirmed or overturned it. For a business analyst, the subject rights work is a set of user stories with hard deadlines. A subject access request story must state the one month deadline, the systems to be searched, and the format of the answer. An erasure story must state which systems keep the record under the AML obligation and which delete it. The acceptance criteria must include a test where a request is made and the answer arrives complete and on time. Last reviewed 7 November 2026. Further reading: Regulation (EU) 2016/679, Articles 15 to 22; European Data Protection Board guidelines on data subject rights; UK Information Commissioner guidance on subject access requests.