Category 1: Customer payments and cheques
MT104 Direct Debit and Request for Debit Transfer
Written and maintained by ZagTrader. Last reviewed . How this page is sourced and checked
The MT104 carries customer direct debits across borders: it asks a bank to debit one or more debtors’ accounts and pay the proceeds to a creditor. It is sent by the creditor’s bank to the debtors’ bank, or by a creditor or forwarding bank to the bank that holds the creditor’s account. In ISO 20022 the bank-to-bank direct debit is pacs.003.
- Message type
- MT104
- Category
- 1
- Structure
- 3 sequences, 37 fields listed
When MT104 is used
The MT104 is used in two business scenarios, each with its own Message User Group. In the Direct Debit scenario the creditor’s bank sends the MT104 to the debtors’ bank: the Receiver debits the debtors and pays the total back to the Sender, which credits the creditor. In the Request for Direct Debit (RFDD) scenario the Sender asks the Receiver to collect the debits and credit the creditor’s account that the Receiver itself holds; no settlement flows back to the Sender.
The scenario changes the message. A Request for Direct Debit has 23E RFDD in sequence A and the validation flag {119:RFDD} in the user header, and it has no sequence C. A Direct Debit has no flag, and sequence C (settlement details) is mandatory: it holds the total the Receiver must pay to the Sender and, when charges are taken, the totals of the charges.
Sequence A holds what applies to every debit: the type of direct debit in 23E (pre-authorised, not pre-authorised, or a return), the requested execution date and, when there is one creditor, the creditor. Sequence B repeats once per debtor, with the amount, the debtor’s account and, where a mandate exists, the mandate reference. Several fields can sit either in sequence A or in each sequence B, never in both.
Whole-message rejects and returns travel as a new MT104 with 23E RTND and a reason in field 72 (/REJT/ or /RETN/). For a single transaction inside the message, the guide recommends an MT195 instead. Everything else (accepted currencies, amount limits, revocation deadlines, charges) is settled in bilateral or multilateral agreements, and the guide recommends that the law of the debtor’s country govern the whole transaction.
Do not confuse it with the MT107 General Direct Debit Message, a similar bank-to-bank format used under other agreements, or with the MT204, the financial markets direct debit used between banks for their own accounts.
MT104 format: sequences and fields
Sequence AGeneral InformationMandatory
Once per message. 21E, 26T, 52a, 71A, 77B and the instructing party 50a (C or L) may be here or in sequence B, never in both (rule C3).
| Tag | Name | Status | Format | Meaning |
|---|---|---|---|---|
| 20 | Sender's Reference | M | 16x | The Sender’s unique reference for the message. No leading or trailing slash and no double slash (T26). With field 21 of a transaction it identifies that debit in queries and cancellations. |
| 21R | Customer Specified Reference | C | 16x | A reference for the whole message from the instructing party or creditor. Allowed only in a Request for Direct Debit (23E RFDD); not allowed otherwise (rule C12). |
| 23E | Instruction Code | O | 4!c[/30x] | The type of direct debits in the message: AUTH (pre-authorised under a mandate or contract), NAUT (not pre-authorised), RFDD (request for direct debit), RTND (a previous MT104 returned: rejected, reversed or revoked) or OTHR (bilaterally agreed, with text after a slash; text is only allowed with OTHR, D81). Its value decides whether 23E appears in sequence B (rule C1). |
| 21E | Registration Reference | C | 35x | The registration reference that authorises the creditor to take part in a direct debit scheme. If present here, the creditor 50a must also be in sequence A (rule C4). |
| 30 | Requested Execution Date | M | 6!n | The date (YYMMDD) on which the Receiver is asked to execute every debit in sequence B. |
| 51A | Sending Institution | O | [/1!a][/34x] 4!a2!a2!c[3!c] | Identifies the Sender when the MT104 travels in a FileAct file. Not allowed in FIN (D63). |
| 50a | Instructing PartyOptions C or L | C | C: 4!a2!a2!c[3!c] L: 35x | A party authorised by the creditor or its bank to order all the debits, when it is not the creditor itself. BIC in option C, agreed party identifier in option L. |
| 50a | CreditorOptions A or K | C | A: [/34x] 4!a2!a2!c[3!c] K: [/34x] 4*35x | Who collects the money and which account is credited, for all debits in the message. Must be here or in every sequence B, never both and never neither (rule C2, C76). In a Request for Direct Debit the account is held at the Receiver and is mandatory. |
| 52a | Creditor's BankOptions A, C or D | C | A: [/1!a][/34x] 4!a2!a2!c[3!c] C: /34x D: [/1!a][/34x] 4*35x | The creditor’s bank that orders the debits, even when the creditor account is an IBAN. If absent, that role falls to the Sender in the Direct Debit scenario and to the Receiver in the RFDD scenario. |
| 26T | Transaction Type Code | C | 3!c | The nature or purpose of all debits, for example invoices, subscriptions or instalments. The codes are agreed bilaterally. |
| 77B | Regulatory Reporting | C | 3*35x | Statutory or regulatory codes for the Sender’s or Receiver’s country. /ORDERRES/ gives the creditor’s country of residence and /BENEFRES/ the debtor’s. |
| 71A | Details of Charges | C | 3!a | Who bears the charges of every debit: OUR (the creditor), BEN (the debtor) or SHA (shared; in the Direct Debit scenario the creditor pays the Sender’s side and the debtor the Receiver’s side). |
| 72 | Sender to Receiver Information | C | 6*35x | Only in a returned MT104 (23E RTND), where it is mandatory (rule C5, C82): line 1 starts with /REJT/ or /RETN/ and gives the reason, following the payments reject and return guidelines. |
Sequence BTransaction DetailsMandatory, repeatable
Once per debit.
| Tag | Name | Status | Format | Meaning |
|---|---|---|---|---|
| 21 | Transaction Reference | M | 16x | The unique reference of this debit within the message. With field 20 it identifies the transaction. |
| 23E | Instruction Code | C | 4!c[/30x] | The type of this debit: AUTH, NAUT or OTHR. Mandatory in every sequence B when sequence A has RFDD or no 23E; not allowed when sequence A has another code (rule C1, C75). |
| 21C | Mandate Reference | O | 35x | The reference of the direct debit mandate agreed between the creditor and the debtor. |
| 21D | Direct Debit Reference | O | 35x | A further reference that identifies this direct debit. |
| 21E | Registration Reference | C | 35x | The creditor’s scheme registration reference for this debit, when not given in sequence A. Needs the creditor 50a in the same sequence B (rule C4). Not allowed in an RFDD (rule C12). |
| 32B | Currency and Transaction Amount | M | 3!a15d | The amount to debit from the debtor’s account, before any charges added under BEN or SHA. All 32B fields in the message must use the same currency (rule C11, C02). |
| 50a | Instructing PartyOptions C or L | C | C: 4!a2!a2!c[3!c] L: 35x | As in sequence A, for this debit only. Not allowed when it is in sequence A (rule C3). |
| 50a | CreditorOptions A or K | C | A: [/34x] 4!a2!a2!c[3!c] K: [/34x] 4*35x | The creditor for this debit, mandatory in every sequence B when not in sequence A (rule C2). Not allowed in an RFDD (rule C12). |
| 52a | Creditor's BankOptions A, C or D | C | A: [/1!a][/34x] 4!a2!a2!c[3!c] C: /34x D: [/1!a][/34x] 4*35x | The creditor’s bank for this debit, when not given in sequence A. Not allowed in an RFDD. |
| 57a | Debtor's BankOptions A, C or D | O | A: [/1!a][/34x] 4!a2!a2!c[3!c] C: /34x D: [/1!a][/34x] 4*35x | The bank that holds the debtor’s account and will execute this debit. Absent means the Receiver is the debtor’s bank. |
| 59a | DebtorOptions no letter or A | M | No letter: [/34x] 4*35x A: [/34x] 4!a2!a2!c[3!c] | Whose account is debited. Although the format shows the account as optional, in the MT104 the debtor’s account must be present (E10). |
| 70 | Remittance Information | O | 4*35x | Details for the debtor, such as the invoice being collected: /INV/, /RFB/ (reference for the debtor), /ROC/, /IPI/. |
| 26T | Transaction Type Code | C | 3!c | Purpose of this debit, when not given in sequence A. Codes agreed bilaterally. |
| 77B | Regulatory Reporting | C | 3*35x | Regulatory codes for this debit, when not given in sequence A. |
| 33B | Currency/Original Ordered Amount | O | 3!a15d | The amount as originally ordered by the creditor, when it differs from 32B. Currency or amount (or both) must differ from 32B (rule C7, D21). |
| 71A | Details of Charges | C | 3!a | Who bears the charges of this debit, when not given in sequence A. |
| 71F | Sender's Charges | C | 3!a15d | Charges due to the Sender for this debit. If used in any sequence B, the total must appear in sequence C (rule C6). Not allowed in an RFDD. |
| 71G | Receiver's Charges | C | 3!a15d | Charges due to the Receiver for this debit, in the 32B currency. If used, the total must appear in sequence C. Not allowed in an RFDD. |
| 36 | Exchange Rate | C | 12d | The rate used to convert 33B into the 32B currency. Mandatory when 33B and 32B currencies differ, otherwise not allowed (rule C8, D75). |
Sequence CSettlement DetailsConditional
Mandatory in a Direct Debit (23E absent or not RFDD); not allowed in a Request for Direct Debit (rule C12, C96).
| Tag | Name | Status | Format | Meaning |
|---|---|---|---|---|
| 32B | Currency and Settlement Amount | M | 3!a15d | The total the Receiver pays to the Sender. It may include the total charges when charges are settled at once. Keep bulk sizes within the 15-digit limit. |
| 19 | Sum of Amounts | C | 17d | The sum of all 32B amounts in sequence B. Present only when the settlement amount differs from that sum, for example because charges are included (rules C9 and C10, D80 and C01). |
| 71F | Sum of Sender's Charges | C | 3!a15d | The total of the Sender’s charges given in sequence B. Present if and only if 71F appears in sequence B (rule C6, D79). |
| 71G | Sum of Receiver's Charges | C | 3!a15d | The total of the Receiver’s charges given in sequence B. Present if and only if 71G appears there; the amount must not be zero (D57). |
| 53a | Sender's CorrespondentOptions A or B | O | A: [/1!a][/34x] 4!a2!a2!c[3!c] B: [/1!a][/34x] [35x] | Where the Sender wants to be paid. Leave it out when there is a single account relationship in the currency; use option B with the account number when there are several; name a correspondent when there is no direct account, in which case the Receiver sends a cover payment. |
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).
Rules worth knowing
- C1 (C75): with 23E RFDD in sequence A, 23E is mandatory in every sequence B; with any other code in sequence A it is not allowed in sequence B; with no 23E in sequence A it is mandatory in every sequence B.
- C2 (C76): the creditor (50a option A or K) is in sequence A or in every sequence B, never both, never neither. C3 (D73): 21E, 26T, 52a, 71A, 77B and the instructing party are each either in sequence A or in sequence B, never both.
- C4 (D77): wherever 21E appears, the creditor 50a must be in the same sequence. C5 (C82): field 72 is mandatory with 23E RTND and not allowed otherwise.
- C6 (D79): 71F and 71G in sequence B and in sequence C go together. C7 (D21) and C8 (D75): 33B must differ from 32B, and field 36 is needed exactly when their currencies differ.
- C9 (D80) and C10 (C01): field 19 is present only when the sequence C amount differs from the sum of the sequence B amounts, and then it must equal that sum. C11 (C02): one currency for all 32B and 71G fields, and one for all 71F fields.
- C12 (C96): with 23E RFDD, 21R is optional, sequence B must not contain 21E, 50a (A or K), 52a, 71F or 71G, and sequence C is not allowed. Without RFDD, 21R is not allowed and sequence C is mandatory.
- C13 (C94): 23E RFDD in sequence A requires {119:RFDD} in the user header; without RFDD, field 119 must not be present.
MT104 example
Northwind Trading LLC collects monthly service fees from two UK customers under signed mandates. Its bank, ZagTrader Test Bank in Dubai (ZAGTAEADXXX), sends a Direct Debit MT104 to BANKGB2LXXX, which holds one debtor’s account and reaches the other debtor at ZAGTGB2LXXX. BANKGB2LXXX pays the GBP 2,100.00 total back to the Sender on the agreed account, so sequence C is present and there is no RFDD flag.
{1:F01ZAGTAEADAXXX0000000000}{2:I104BANKGB2LXXXXN}{4:
:20:ZT104261020001
:23E:AUTH
:30:261022
:50K:/AE070331234567890123456
NORTHWIND TRADING LLC
DUBAI AE
:71A:SHA
:21:NWDD-2610-0001
:21C:MANDATE-0042
:32B:GBP1250,00
:59:/GB42BANK40051587654321
HARBOUR LOGISTICS LTD
LONDON
:70:/RFB/OCT26-SERVICE-FEE
:21:NWDD-2610-0002
:21C:MANDATE-0057
:32B:GBP850,00
:57A:ZAGTGB2LXXX
:59:/GB38ZAGT40051512345678
KESTREL DESIGN STUDIO LTD
MANCHESTER
:70:/RFB/OCT26-SERVICE-FEE
:32B:GBP2100,00
-}Decode this example in the parserLine by line
| Line | What it says |
|---|---|
| {1:F01ZAGTAEADAXXX0000000000}{2:I104BANKGB2LXXXXN}{4: | Direct Debit scenario: no {119:RFDD} flag in the user header. |
| :20:ZT104261020001 | Sequence A starts. Sender’s reference. |
| :23E:AUTH | Pre-authorised direct debits. With a code other than RFDD here, 23E is not allowed in sequence B. |
| :30:261022 | Requested execution date: 22 October 2026. |
| :50K:/AE070331234567890123456 | One creditor for the whole message, so it sits in sequence A: account at the Sender ... |
| NORTHWIND TRADING LLC | ... and name and address. |
| DUBAI AE | |
| :71A:SHA | Charges shared for every debit. |
| :21:NWDD-2610-0001 | Sequence B, first debit. |
| :21C:MANDATE-0042 | The mandate the debtor signed. |
| :32B:GBP1250,00 | Amount to debit. |
| :59:/GB42BANK40051587654321 | Debtor: the account is mandatory in an MT104. No 57a, so the Receiver holds it. |
| HARBOUR LOGISTICS LTD | |
| LONDON | |
| :70:/RFB/OCT26-SERVICE-FEE | Reference for the debtor. |
| :21:NWDD-2610-0002 | Sequence B, second debit. |
| :21C:MANDATE-0057 | |
| :32B:GBP850,00 | |
| :57A:ZAGTGB2LXXX | This debtor banks elsewhere: the debtor’s bank is named. |
| :59:/GB38ZAGT40051512345678 | |
| KESTREL DESIGN STUDIO LTD | |
| MANCHESTER | |
| :70:/RFB/OCT26-SERVICE-FEE | |
| :32B:GBP2100,00 | Sequence C: settlement amount. It equals the sum of the two debits, so field 19 is not allowed. |
| -} | End of block 4. |
BICs, names, references and IBANs are made up; the IBANs carry valid check digits.
There are no sequence markers in an MT104: the 32B after the last debit belongs to sequence C because it follows the last transaction and has no field 21 before it.
Common errors and rejects
Sequence C missing, or present in an RFDD (C96)
A Direct Debit needs sequence C with the settlement amount; a Request for Direct Debit must not have it. The trigger is 23E in sequence A: RFDD means no sequence C, any other code or no code means sequence C is mandatory.
RFDD flag and 23E do not match (C94)
An RFDD message needs {119:RFDD} in the user header, and a Direct Debit must not carry field 119. Generators that set 23E RFDD but forget the header flag, or reuse a template with the flag, are rejected.
23E in the wrong sequence (C75)
With AUTH, NAUT or OTHR in sequence A, no 23E may appear in sequence B. With RFDD, or with no code in sequence A, every sequence B needs its own 23E.
Settlement total does not add up (D80, C01)
If the sequence C amount equals the sum of the debits, field 19 must be absent; if it differs (for example because charges are included), field 19 must be present and equal the sum of the 32B amounts exactly.
Creditor or charges fields in both sequences (C76, D73)
The creditor, 71A, 26T, 77B, 52a and 21E each live either in sequence A or in sequence B. A template that fills them at both levels is rejected.
Debtor without an account (E10)
Field 59a must start with the debtor’s account, even though the general format of field 59 makes it optional.
How to fix it
MT104 in ISO 20022
Swift’s CBPR+ roadmap, as reproduced in Citi’s September 2025 client webinar, lists pain.008 (Customer Direct Debit Initiation) and pacs.003 (FI to FI Customer Direct Debit) as the ISO 20022 equivalents of the MT104; Citi’s ISO 20022 guide also maps the MT104 to pacs.003. In ISO 20022, pain.008 is the direct debit initiation sent by or for the creditor, and pacs.003 the direct debit exchanged between banks.
Direct debit messages were not part of the 22 November 2025 migration of cross-border payment instructions: BNY’s May 2025 notice says MT104, MT107 and MT204 continue to be supported until Swift defines a date. The same roadmap marks them for a later end of life.
MT104 questions
- What is the difference between a Direct Debit and a Request for Direct Debit in the MT104?
- In a Direct Debit the Receiver debits the debtors and pays the total back to the Sender, which is why sequence C (settlement) is mandatory. In a Request for Direct Debit (23E RFDD and {119:RFDD}) the Receiver credits the creditor’s account it holds itself, so there is no settlement back and no sequence C.
- What do AUTH and NAUT mean in field 23E?
- AUTH marks pre-authorised direct debits, collected under a mandate or contract the debtor signed. NAUT marks debits without such an authorisation. RFDD marks a request for direct debit and RTND a returned MT104.
- How is a rejected MT104 returned?
- A whole message is returned as a new MT104 with 23E RTND and field 72 starting /REJT/ or /RETN/ with the reason. A single debit inside the message is better rejected with an MT195.
- What is the ISO 20022 equivalent of the MT104?
- Swift’s CBPR+ roadmap lists
pain.008andpacs.003: pain.008 is the direct debit initiation sent by or for the creditor, pacs.003 the direct debit between banks. The MT104 is still supported on Swift until a migration date is set. - What is the difference between MT104 and MT107?
- Both carry customer direct debits between banks. The MT107 General Direct Debit Message is used under different bilateral agreements and has no request for direct debit variant; check which format your counterparty and scheme expect.
All MT messages · Category 1 messages · ISO 20022 messages · Codes · Troubleshooting