Category 1: Customer payments and cheques
MT103 STP Single Customer Credit Transfer (STP)
Written and maintained by ZagTrader. Last reviewed . How this page is sourced and checked
The MT103 STP is the MT103 customer credit transfer with a smaller set of fields and letter options, so that the receiving bank can process it without manual repair. The ordering customer’s bank, or a bank acting for it, sends it to the next bank in the chain. The STP variant is switched on by the code STP in field 119 of the user header block, which makes the network apply the stricter validation.
What MT103 STP is used for
The block 3 user header must carry {119:STP} and the UETR in field 121, for example {3:{119:STP}{121:...}}. Without the flag the same text is validated as a core MT103. The MT103 STP is a general use message: no Message User Group registration is needed, and it can only travel over FIN because it relies on that special validation.
The restrictions compared with the core MT103: fields 52, 54, 55, 56 and 57 accept option A (a BIC) only; field 53 accepts options A and B, and 53B must carry the party identifier; field 51A is not used; field 23E may only hold CORT, INTC, SDVA or REPA; the account line of field 59a is always present; in field 72 the code /INS/ must be followed by a valid financial institution BIC, the codes /REJT/ and /RETN/ are not allowed and no ERI (euro-related information) may appear.
Since 22 November 2025, MT103 STP sent between financial institutions over the cross-border network is no longer delivered as an MT: Swift’s contingency processing converts it to a pacs.008 when it passes the stricter checks, and charges for the conversion from 1 January 2026. Banks that receive payments in MT form get them through in-flow translation.
- Sent by
- The ordering customer’s bank, or an intermediary bank further down the chain
- Sent to
- The next bank in the chain, up to the beneficiary’s bank
MT103 STP format: sequences and fields
Message text (block 4)Mandatory
No sequences. Block 3 must contain {119:STP} and field 121 (UETR). Letter options are fewer than in the core MT103.
| Tag | Name | Status | Format | Meaning |
|---|---|---|---|---|
| 20 | Sender’s Reference | M | 16x | The sender’s own reference for the payment, quoted back in any query, cancellation or confirmation. |
| 13C | Time IndicationRepeatable | O | /8c/4!n1!x4!n | A coded time instruction, such as the latest time for the debit or credit, with the UTC offset. |
| 23B | Bank Operation Code | M | 4!c | Type of operation: CRED for a normal transfer, or a service level code SPRI, SSTD or SPAY. CRTS (test) should not be used on FIN. |
| 23E | Instruction CodeRepeatable | C | 4!c[/30x] | Coded instructions, limited to SDVA, INTC, REPA and CORT in this variant. Not allowed with SSTD or SPAY in 23B; only SDVA or INTC with SPRI. |
| 26T | Transaction Type Code | O | 3!c | Nature or purpose of the payment, often a balance of payments code for regulatory reporting. |
| 32A | Value Date/Currency/Interbank Settled Amount | M | 6!n3!a15d | Value date, currency and the amount settled between the banks, with a comma as the decimal mark. Precious metal codes are not allowed. |
| 33B | Currency/Instructed Amount | C | 3!a15d | The amount the customer instructed, before conversion and charges. Mandatory between banks in the listed European countries and whenever charges fields 71F or 71G are present. |
| 36 | Exchange Rate | C | 12d | Rate used to convert the instructed amount. Present only when 33B is in a different currency from 32A. |
| 50a | Ordering CustomerOptions A, F or K | M | A: [/34x] 4!a2!a2!c[3!c] F: 35x 4*(1!n/33x) K: [/34x] 4*35x | The customer who orders the payment: a BIC (A), structured name and address lines (F) or free name and address (K). |
| 52A | Ordering Institution | O | [/1!a][/34x] 4!a2!a2!c[3!c] | The ordering customer’s bank, when it is not the sender. BIC only in this variant. |
| 53a | Sender’s CorrespondentOptions A or B | C | A: [/1!a][/34x] 4!a2!a2!c[3!c] B: [/1!a][/34x] [35x] | The account or institution through which the sender reimburses the receiver. With option B the account (party identifier) must be given. Needed when field 55A is used. |
| 54A | Receiver’s Correspondent | C | [/1!a][/34x] 4!a2!a2!c[3!c] | Where the funds will be made available to the receiver, when that is not the receiver itself. Needed when field 55A is used. |
| 55A | Third Reimbursement Institution | O | [/1!a][/34x] 4!a2!a2!c[3!c] | The receiver’s branch or institution that receives the funds when the correspondents in 53A and 54A are both involved. |
| 56A | Intermediary Institution | C | [/1!a][/34x] 4!a2!a2!c[3!c] | A bank between the receiver and the account with institution. Not allowed with SPRI in 23B, and requires 57A. |
| 57A | Account With Institution | C | [/1!a][/34x] 4!a2!a2!c[3!c] | The beneficiary’s bank, when it is not the receiver. A clearing code such as //FW or //RT may appear in the party identifier line. |
| 59a | Beneficiary CustomerOptions no letter, A or F | M | No letter: [/34x] 4*35x A: [/34x] 4!a2!a2!c[3!c] F: [/34x] 4*(1!n/33x) | The customer to be credited. The account line is always present in this variant, and an IBAN is required between banks in the listed European countries. |
| 70 | Remittance Information | O | 4*35x | Information for the beneficiary, such as the invoice being paid. |
| 71A | Details of Charges | M | 3!a | Who bears the charges: OUR (ordering customer), SHA (shared) or BEN (beneficiary). |
| 71F | Sender’s ChargesRepeatable | C | 3!a15d | Charges already taken by banks in the chain. At least one is required with BEN; not allowed with OUR. |
| 71G | Receiver’s Charges | C | 3!a15d | Charges the sender pays to the receiver under OUR, in the currency of 32A. Not allowed with SHA or BEN. |
| 72 | Sender to Receiver Information | O | 6*35x | Coded information only. /INS/ must be followed by a financial institution BIC; /REJT/, /RETN/ and ERI are not allowed in this variant. |
| 77B | Regulatory Reporting | O | 3*35x | Statutory or central bank reporting codes for the country of the sender or receiver. |
Format notation: n digits, a upper-case letters, c upper-case letters and digits, x any character of the Swift character set, d a decimal number with a comma, ! fixed length, [ ] optional, 4*35x up to 4 lines of 35 characters. M mandatory, O optional, C conditional (a rule decides).
MT103 STP in ISO 20022
The ISO 20022 equivalent is pacs.008, which Swift publishes in a core and an STP usage guideline for CBPR+. Since the end of coexistence on 22 November 2025, MT103 STP is converted to pacs.008 by contingency processing.
MT103 STP questions
- What makes an MT103 an MT103 STP?
- The code STP in field 119 of the user header block ({3:{119:STP}}). It tells the network to validate the message against the STP rules: option A only in 52 and 54 to 57, options A or B in 53, no 51A, a limited 23E code list and a stricter field 72.
- Why was my MT103 STP rejected when the same message passes as a core MT103?
- Usually a letter option the STP variant does not allow (for example 57D or 56C), field 53B without an account, a 23E code outside CORT, INTC, SDVA and REPA, or /REJT/, /RETN/ or ERI in field 72. Remove the flag only if the payment really cannot be sent in STP form.
- Is MT103 STP still used after November 2025?
- Between financial institutions on the cross-border network, payment instructions now travel as pacs.008. An MT103 STP still sent is converted by Swift’s chargeable contingency processing, which applies stricter checks than before.
All MT messages · Category 1 messages · ISO 20022 messages · Codes · Troubleshooting