| 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
Cross-border data transfers: when a payment message leaves the region
What you will learn
Your objective. By the end of this lesson, you will be able to explain cross-border data transfers: when a payment message leaves the region and apply it to a real banking scenario.
Why it matters. For a business analyst, the transfer work is a mapping exercise.
Chapter objective: Data protection, US anti-money-laundering law, and keeping payments running under stress
Key learning points
- Cross-border payment
- US adequacy and Data Privacy Framework
- Transfer impact assessments
- Field 70 free text risk
- Onward screening by correspondents
- 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.
Sanctions screening: Checking payment parties, countries and references against sanctions lists published by governments and international bodies.
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 Cross-border data transfers: when a payment message leaves the region.
Insights and practice scenarios
Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.
Practise this lesson
Exercise
Read the MT103 to message described in this lesson and identify its key parts.
Use the message structure, fields and example in this lesson.
- What to do. List the main blocks of the message, name the field that carries the amount, and name the field that identifies the payment.
Correct result. The message is made of blocks, each carrying a part of the payment instruction. The amount field and the identification field are the two a receiving bank checks first, because without them it cannot process or reconcile the payment.
Why. A message is only useful if you can read it. The blocks tell the receiving bank what to do, and the amount and identification fields are what it checks first.
Check your understanding
Practice question
Which of the following best describes cross-border data transfers: when a payment message leaves the region?
Takeaway and next step
What to remember
For a business analyst, the transfer work is a mapping exercise.
Open the message type from this lesson and inspect its fields, then find the field that carries the amount.
Open the ISO 20022 Message Explorer →
Builds on "Data subject rights in payments: access, erasure and the AML wall".
Transcript and full text
Show transcript
Every cross-border payment is also a cross-border data transfer. When a European bank sends an MT103 to a correspondent in the United States, it transfers the ordering customer name, the beneficiary name, the account numbers and the remittance information outside the European Economic Area. When a payment goes through SWIFT, the message is stored and processed in data centres in Belgium, the Netherlands and the United States. GDPR Chapter V applies to all of this, and the bank must have a transfer mechanism in place before the payment is sent. The simplest transfer mechanism is an adequacy decision. The European Commission has decided that a small number of countries provide an adequate level of data protection, and transfers to those countries need no additional safeguard. The United States is not covered by a general adequacy decision for all transfers, although the EU-US Data Privacy Framework provides adequacy for certified US organisations. A payment to a correspondent that is not covered by adequacy needs another mechanism, usually the standard contractual clauses. Standard contractual clauses are the workhorse for payment data transfers. They are a set of contract terms published by the European Commission that the sending bank and the receiving correspondent sign. The clauses require the receiver to protect the data, to notify the sender of government access requests, and to allow audits. The bank must also carry out a transfer impact assessment, which asks whether the law of the receiving country undermines the protection the clauses promise. For a payment to a country with broad government surveillance powers, that assessment can be difficult. SWIFT is a special case that every payments BA should understand. SWIFT is a messaging network, not a bank, and it processes personal data as a processor on behalf of its member banks. SWIFT has binding corporate rules approved by the Belgian data protection authority, which provide the transfer mechanism for the data SWIFT processes. But the bank's own transfer to the correspondent, and the correspondent's onward transfer to the beneficiary bank, are separate transfers that need their own mechanisms. The message does not become compliant just because SWIFT is compliant. The payment message itself creates a data minimisation problem. Field 70 of an MT103 can carry any free text the payer writes, and payers write medical details, legal references and personal notes. Field 72 can carry instructions that name individuals. Once that text is in the message it travels to every bank in the chain, and it is stored in every screening system along the way. The practical control is to limit free-text fields at the point of initiation, to warn the customer that the reference will be visible to other banks, and to strip the field before it reaches an analytics system. Sanctions screening makes cross-border transfers more complex, because the screening itself is a transfer. When a European bank screens a payment against a US sanctions list hosted in the United States, the payment data is transferred to the screening provider. When a correspondent bank in Singapore screens a payment it received from Europe, the data has already crossed the border. The screening contract must therefore include the transfer mechanism, and the bank must be able to show which screening providers hold payment data and where they are located. For a business analyst, the transfer work is a mapping exercise. Every payment flow must be mapped to the countries the data passes through, the transfer mechanism for each hop, and the contract that contains it. The requirements must state that a new correspondent cannot be onboarded until the transfer mechanism is signed, and the acceptance criteria must include a test that proves the mechanism exists for each corridor. Last reviewed 7 November 2026. Further reading: Regulation (EU) 2016/679, Chapter V; European Commission standard contractual clauses, Implementing Decision (EU) 2021/914; European Data Protection Board recommendations on supplementary transfer tools; SWIFT binding corporate rules.
Every cross-border payment is also a cross-border data transfer. When a European bank sends an MT103 to a correspondent in the United States, it transfers the ordering customer name, the beneficiary name, the account numbers and the remittance information outside the European Economic Area. When a payment goes through SWIFT, the message is stored and processed in data centres in Belgium, the Netherlands and the United States. GDPR Chapter V applies to all of this, and the bank must have a transfer mechanism in place before the payment is sent.
The simplest transfer mechanism is an adequacy decision. The European Commission has decided that a small number of countries provide an adequate level of data protection, and transfers to those countries need no additional safeguard. The United States is not covered by a general adequacy decision for all transfers, although the EU-US Data Privacy Framework provides adequacy for certified US organisations. A payment to a correspondent that is not covered by adequacy needs another mechanism, usually the standard contractual clauses.
Standard contractual clauses are the workhorse for payment data transfers. They are a set of contract terms published by the European Commission that the sending bank and the receiving correspondent sign. The clauses require the receiver to protect the data, to notify the sender of government access requests, and to allow audits. The bank must also carry out a transfer impact assessment, which asks whether the law of the receiving country undermines the protection the clauses promise. For a payment to a country with broad government surveillance powers, that assessment can be difficult.
SWIFT is a special case that every payments BA should understand. SWIFT is a messaging network, not a bank, and it processes personal data as a processor on behalf of its member banks. SWIFT has binding corporate rules approved by the Belgian data protection authority, which provide the transfer mechanism for the data SWIFT processes. But the bank's own transfer to the correspondent, and the correspondent's onward transfer to the beneficiary bank, are separate transfers that need their own mechanisms. The message does not become compliant just because SWIFT is compliant.
The payment message itself creates a data minimisation problem. Field 70 of an MT103 can carry any free text the payer writes, and payers write medical details, legal references and personal notes. Field 72 can carry instructions that name individuals. Once that text is in the message it travels to every bank in the chain, and it is stored in every screening system along the way. The practical control is to limit free-text fields at the point of initiation, to warn the customer that the reference will be visible to other banks, and to strip the field before it reaches an analytics system.
Sanctions screening makes cross-border transfers more complex, because the screening itself is a transfer. When a European bank screens a payment against a US sanctions list hosted in the United States, the payment data is transferred to the screening provider. When a correspondent bank in Singapore screens a payment it received from Europe, the data has already crossed the border. The screening contract must therefore include the transfer mechanism, and the bank must be able to show which screening providers hold payment data and where they are located.
For a business analyst, the transfer work is a mapping exercise. Every payment flow must be mapped to the countries the data passes through, the transfer mechanism for each hop, and the contract that contains it. The requirements must state that a new correspondent cannot be onboarded until the transfer mechanism is signed, and the acceptance criteria must include a test that proves the mechanism exists for each corridor. Last reviewed 7 November 2026. Further reading: Regulation (EU) 2016/679, Chapter V; European Commission standard contractual clauses, Implementing Decision (EU) 2021/914; European Data Protection Board recommendations on supplementary transfer tools; SWIFT binding corporate rules.
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.