| Field | Meaning | Required |
|---|---|---|
:20: | A unique reference assigned by the sending bank to identify this payment through its whole life. It must not repeat for the same sender within the same business | M |
:23B: | A four character code that tells the receiving bank how to handle the transfer. CRED means a normal credit transfer, SPAY means a SWIFT payment, SSTD means a st | M |
:32A: | The value date on which funds become available to the beneficiary, the three letter ISO currency code and the amount to be paid. For USD 25,000 on 5 November 20 | M |
:33B: | The currency and amount in which the ordering customer instructed the payment, when that differs from the settlement currency in field 32A. It preserves the ori | O |
:50a: | The customer who ordered the payment, identified by account number and name and address. Option K gives account, name and address in free text. Option F gives s | M |
:52a: | The financial institution that ordered the transfer when it is not the sender of the message. It is normally the bank holding the ordering customer account in a | O |
:53a: | The account held by the sender with the receiver, or the correspondent bank through which settlement will occur. It tells the receiving bank where to debit the | O |
:54a: | The account held by the receiver with another bank, used when the receiver does not hold the sender account directly. It identifies the next bank in the settlem | O |
:57a: | The bank where the beneficiary holds an account, when it is not the receiver of the MT103. It directs the receiving bank to forward the payment to the correct a | O |
:59a: | The final recipient of the funds, identified by account number and name and address. Option A gives the account and BIC, option F gives structured name and addr | M |
:70: | Free text information for the beneficiary explaining what the payment is for, such as an invoice number, contract reference or salary month. It is limited to fo | O |
:71A: | A three letter code stating who pays the transfer charges. OUR means the ordering customer pays all charges, BEN means the beneficiary pays all charges, and SHA | M |
Meridian Bank London sends an MT103, reference MER1035521, for USD 25,000 value 5 November 2024 to Harbour Bank Singapore to pay Bright Logistics for invoice INV-1187. This is a pre-migration example, from before coexistence ended on 22 November 2025. Field :71A: is SHA, the beneficiary account is given in :59a:, and the payment settles on the value date.
Valid example from the message catalogue. Scheme rules: MT103 is a SWIFT MT (FIN) message, not a base ISO 20022 message: there is no single global scheme rulebook, and each bank and market practice sets its own format limits and cut-off times on top of the
GDPR and payment data: what counts as personal data in a payment
What you will learn
Your objective. By the end of this lesson, you will be able to explain gdpr and payment data: what counts as personal data in a payment and apply it to a real banking scenario.
Why it matters. For a business analyst, GDPR is a requirements discipline, not a legal footnote.
Chapter objective: Data protection, US anti-money-laundering law, and keeping payments running under stress
Key learning points
- Personal data in payments
- GDPR definition of personal data
- Lawful basis per data field
- Retention versus AML law
- Article 34 breach notification
- Further reading and sources
Key terms
Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.
SWIFT: The Society for Worldwide Interbank Financial Telecommunication, a member owned cooperative that provides secure messaging services for financial institutions.
MT103: A SWIFT message that carries a single customer credit transfer instruction from one bank to another. It names the ordering customer, the beneficiary, the amount, the currency and the value date.
SWIFT MT message viewer showing GDPR and payment data: what counts as personal data in a payment.
Practise this lesson
Exercise
Find the field IBAN in the message described in this lesson and explain what it controls.
Use the field description and the example in this lesson.
- What to do. Write down what IBAN carries, what happens if it is wrong, and which system reads it.
Correct result. IBAN carries the value the lesson describes. If it is wrong, the payment is rejected, returned, or misrouted, and the exception must be investigated before the payment can proceed.
Why. Fields are the contract between systems. A wrong field is not a typo, it is a failed payment.
Check your understanding
Practice question
Which of the following best describes gdpr and payment data: what counts as personal data in a payment?
Takeaway and next step
What to remember
Consent is almost never the right basis for a payment, because the customer cannot meaningfully refuse consent and still have the payment made.
Follow a payment through every stage, from instruction to beneficiary credit, and note where it can stop.
Open the Payment Lifecycle Simulator →
Builds on "Webhooks and event delivery: signatures, retries, ordering and replay".
Transcript and full text
Show transcript
Every payment carries personal data. A SEPA credit transfer carries the payer name, the payer IBAN, the payee name, the payee IBAN and a remittance reference that often names a person or a contract. A card payment carries the cardholder name, the card number, the merchant name and the location. A SWIFT MT103 carries field 50a for the ordering customer, field 59a for the beneficiary customer, field 70 for the remittance information and field 72 for sender to receiver information. None of this is anonymous, and none of it can be processed without a lawful basis. The General Data Protection Regulation, Regulation (EU) 2016/679, applies to every payment a European bank or payment institution processes, and to any payment that touches a person in the European Economic Area. GDPR defines personal data as any information relating to an identified or identifiable person, and an IBAN is personal data because it identifies the account holder. Payment data is not a special category under Article 9, so the ordinary lawful bases apply, but the volume and the sensitivity of the data make the obligations serious. The lawful basis for processing payment data is usually performance of a contract, because the bank must move the money the customer instructed, and legal obligation, because anti-money-laundering law requires the bank to screen, record and report. Consent is almost never the right basis for a payment, because the customer cannot meaningfully refuse consent and still have the payment made. A business analyst must be able to name the lawful basis for every data field a new payment feature collects, and must challenge any field that has no basis. Data minimisation is the rule that bites hardest in payments. Article 5 requires personal data to be adequate, relevant and limited to what is necessary. A payment screen that shows the full beneficiary address to every operations user fails this test. A remittance reference that carries a free-text note about a medical bill fails it. The practical design rule is to show each user only the fields their task needs, to mask account numbers outside the payment engine, and to strip free-text fields before they reach a data warehouse. Retention is where GDPR and anti-money-laundering law collide. GDPR says data must not be kept longer than necessary, while the Fifth Anti-Money-Laundering Directive requires transaction records to be kept for five years after the end of the business relationship, extendable by a further five years. The resolution is a retention schedule that keeps the payment record for the AML period and deletes or anonymises the marketing and analytics copies sooner. The schedule must be written, approved and enforced by the system, not left to individual judgement. A data breach in payments is a reportable event. Under Article 33 the controller must notify the supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people. Under Article 34 the affected people must be told without undue delay when the risk is high. A payment file sent to the wrong correspondent bank, a statement printed with the wrong address, or an API that returns another customer's payment history are all breaches, and the 72 hour clock starts when the bank knows, not when it finishes investigating. For a business analyst, GDPR is a requirements discipline, not a legal footnote. Every requirement that touches payment data must state the lawful basis, the retention period, who can see each field, and what happens on a subject access request. The acceptance criteria must include a test that proves a user without the right role cannot see the full IBAN, and a test that proves a deleted customer record stays deleted in the analytics copy. Last reviewed 7 November 2026. Further reading: Regulation (EU) 2016/679, Articles 5, 6, 33 and 34; European Data Protection Board guidelines on data protection by design; the Fifth Anti-Money-Laundering Directive, Article 40.
Every payment carries personal data. A SEPA credit transfer carries the payer name, the payer IBAN, the payee name, the payee IBAN and a remittance reference that often names a person or a contract. A card payment carries the cardholder name, the card number, the merchant name and the location. A SWIFT MT103 carries field 50a for the ordering customer, field 59a for the beneficiary customer, field 70 for the remittance information and field 72 for sender to receiver information. None of this is anonymous, and none of it can be processed without a lawful basis.
The General Data Protection Regulation, Regulation (EU) 2016/679, applies to every payment a European bank or payment institution processes, and to any payment that touches a person in the European Economic Area. GDPR defines personal data as any information relating to an identified or identifiable person, and an IBAN is personal data because it identifies the account holder. Payment data is not a special category under Article 9, so the ordinary lawful bases apply, but the volume and the sensitivity of the data make the obligations serious.
The lawful basis for processing payment data is usually performance of a contract, because the bank must move the money the customer instructed, and legal obligation, because anti-money-laundering law requires the bank to screen, record and report. Consent is almost never the right basis for a payment, because the customer cannot meaningfully refuse consent and still have the payment made. A business analyst must be able to name the lawful basis for every data field a new payment feature collects, and must challenge any field that has no basis.
Data minimisation is the rule that bites hardest in payments. Article 5 requires personal data to be adequate, relevant and limited to what is necessary. A payment screen that shows the full beneficiary address to every operations user fails this test. A remittance reference that carries a free-text note about a medical bill fails it. The practical design rule is to show each user only the fields their task needs, to mask account numbers outside the payment engine, and to strip free-text fields before they reach a data warehouse.
Retention is where GDPR and anti-money-laundering law collide. GDPR says data must not be kept longer than necessary, while the Fifth Anti-Money-Laundering Directive requires transaction records to be kept for five years after the end of the business relationship, extendable by a further five years. The resolution is a retention schedule that keeps the payment record for the AML period and deletes or anonymises the marketing and analytics copies sooner. The schedule must be written, approved and enforced by the system, not left to individual judgement.
A data breach in payments is a reportable event. Under Article 33 the controller must notify the supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people. Under Article 34 the affected people must be told without undue delay when the risk is high. A payment file sent to the wrong correspondent bank, a statement printed with the wrong address, or an API that returns another customer's payment history are all breaches, and the 72 hour clock starts when the bank knows, not when it finishes investigating.
For a business analyst, GDPR is a requirements discipline, not a legal footnote. Every requirement that touches payment data must state the lawful basis, the retention period, who can see each field, and what happens on a subject access request. The acceptance criteria must include a test that proves a user without the right role cannot see the full IBAN, and a test that proves a deleted customer record stays deleted in the analytics copy. Last reviewed 7 November 2026. Further reading: Regulation (EU) 2016/679, Articles 5, 6, 33 and 34; European Data Protection Board guidelines on data protection by design; the Fifth Anti-Money-Laundering Directive, Article 40.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.