Payments
Why was my MT103 rejected with a NAK error code?
Written and maintained by ZagTrader. Last reviewed . How this page is sourced and checked
A NAK means the Swift network refused your MT103 at input because a field breaks the format or a network validated rule; the message was never delivered. The three-character error code tells you which check failed: T codes are field syntax errors, and C, D and E codes are rules that link fields to each other. Fix the field in your payment system, not only in the outgoing message, and send it again.
What it means
Every FIN message is checked by the network when you send it. Two kinds of checks run. Text validation looks at each field on its own: is the tag allowed here, is the date a real date, is the currency a valid ISO 4217 code, does the amount have its decimal comma. Network validated rules look at fields together: if 33B has another currency than 32A, field 36 must be present; if 71A is OUR, no 71F is allowed. The Swift message reference guide lists these rules for each message as C1, C2 and so on, each with the error code it returns.
If a check fails, the sender gets a negative acknowledgement (NAK) instead of a positive one (ACK). Both arrive as a service message from the network (block 1 starting F21). In block 4, field 451 is 0 for an ACK and 1 for a NAK, and field 405 carries the error code, for example {405:T27}. A NAK means the message stopped at the network: the receiver never saw it, so there is nothing to cancel.
The first letter of the code is the class of the error. T is text validation: the content or layout of one field is wrong. C, D and E refer to message validation rules by number: C covers rules 000 to 099, D rules 100 to 199 and E rules 200 to 299. In practice C, D and E codes mean a combination of fields is not allowed, even though each field on its own looks fine. Header problems have their own codes (H for the basic and application headers, U for the user header block), and K codes flag an invalid code word in a generic field. The same code can mean different rules in different message types, so always read it together with the MT.
An ACK is not proof of payment. It only says the network accepted the message. A receiver can still refuse the payment for business reasons (wrong account, compliance, closed beneficiary). Before November 2025 that came back as a reject or return MT103 with /REJT/ or /RETN/ in field 72 (codes checked under T80). For cross-border payments on Swift it now comes back as pacs.002 (reject) or pacs.004 (return); see pacs.002 reason codes.
Since 22 November 2025, cross-border payment instructions on Swift are exchanged in ISO 20022. An MT103 that a bank still sends goes through Swift’s contingency processing: stricter network validation is applied first, a message that fails it is NAKed, and a message that passes is converted to pacs.008 and delivered. So an MT103 layout that was accepted for years can now be refused. Swift publishes the additional rules in the Standards MT Release Guide 2025, and charges for contingency processing from 1 January 2026.
Common causes
- An amount with a dot, a thousands separator or too many decimals for the currency in 32A, 33B, 71F or 71G (T40, T43, C03).
- A date in 32A that does not exist, or written as YYYYMMDD instead of YYMMDD (T50).
- A BIC with a typo, an unknown branch code, or a BIC that is not connected to the network (T27, T28, T29, T45), or a non-financial BIC where a bank is required (C05).
- Field combinations that break a rule: 33B in another currency without 36 (D75), charges fields that do not match 71A (E13, D50, E15), 71F or 71G without 33B (D51), 56a without 57a (C81), 55a without 53a and 54a (E06).
- 33B missing when both the Sender’s and the Receiver’s BIC are in the listed EU/EEA countries, even if it equals 32A (D49).
- Option F lines in 50F or 59F that are out of order, use an unknown number, or miss the country code after
3/(T56, T73). - A reference in field 20 that starts or ends with a slash or contains
//(T26). - A mandatory field missing, a field in the wrong place or a tag that does not exist in the MT103 (T13).
How to fix it
- Read the NAK service message: field 451 should be
1and field 405 gives the error code. Note the code exactly; the letter and the two digits both matter. - Look the code up for the MT103 in the table below. For C, D and E codes, find the network validated rule that returns that code: it names the fields involved.
- Open the original MT103 and check the fields the code points to. Most T errors are one character: a dot instead of a comma, a missing digit before the comma, a slash at the start of field 20.
- Find where the wrong value came from. A BIC from static data, an amount formatting routine or a charges default in the payment template will produce the same NAK on the next payment unless it is fixed there.
- Correct the message and validate it against the MT103 rules before sending again. The NAK names one problem; another check can fail on the next attempt.
- Send the corrected message. The NAKed one was never delivered, so the receiver will not see a duplicate; follow your own procedures on whether the corrected message keeps the field 20 reference.
- If the NAK started after 22 November 2025 on a message that used to pass, compare the message with the stricter contingency rules in the Standards MT Release Guide 2025, and plan to send pacs.008 directly.
Common MT103 NAK error codes. Codes and the rules they belong to are from the Swift MT103 message reference guide (Standards MT November 2021 and November 2024 editions, public bank copies); meanings of T codes are from a public copy of the FIN text validation code list. The fixes are our own.
| Code | Class | What failed in an MT103 | Typical fix |
|---|---|---|---|
| T13 | Text | A field is not expected where it appears: a mandatory field is missing, fields are out of order, or the tag is not part of the MT103. | Check the field order against the MT103 layout and that 20, 23B, 32A, 50a, 59a and 71A are all present. |
| T26 | Text | Field 20 starts or ends with / or contains //. | Change the reference generator so it never produces a leading or trailing slash or a double slash. |
| T27, T28, T29, T45 | Text | BIC in 52a to 57a (or 50A/59A) is badly formed or invalid (T27), is not a valid destination (T28), has an invalid branch code (T29), or is an invalid non-connected BIC (T45). | Check the BIC against the BIC directory, including the branch code. See IBAN and BIC errors. |
| C05 | Rule | The BIC in a bank field (52a to 57a) is not a financial institution BIC. | Name the bank, not the corporate customer, in bank fields. |
| T50 | Text | Date in 32A is not a valid YYMMDD date. | Use six digits and a real calendar date: 261022, not 20261022 or 261032. |
| T52 | Text | Currency is not a valid ISO 4217 code. | Use the three-letter ISO code (for example AED, not DHS). |
| T40, T43 | Text | Amount missing, first character wrong, decimal comma missing or a wrong or second separator. | Write the amount with digits and exactly one comma: 25000,00 or 25000,. No dots, spaces or signs. |
| C03 | Rule | More decimals than the currency allows. | JPY takes no decimals, KWD and BHD three. See how to read 32A. |
| C08 | Rule | Field 32A uses XAU, XAG, XPD or XPT. | Precious metals use category 6 messages, not an MT103. |
| T08 | Text | Field 71A is not OUR, SHA or BEN. | Map your internal charge option to one of the three codes. |
| T56, T73 | Text | Option F lines in 50F or 59F are wrong (number order, missing 3/ line) or the country code is invalid. | Start with 1/ name, use numbers in order, and include 3/ followed by a valid ISO country code. |
| D75 | Rule | 33B currency differs from 32A but 36 is missing, or 36 is present with the same currency. | Add the exchange rate in 36, or remove it for same-currency payments. |
| D49 | Rule | 33B missing although both Sender and Receiver BICs are in the listed EU/EEA countries. | Always send 33B between those countries, even when it equals 32A. |
| D51 | Rule | 71F or 71G present without 33B. | Add 33B with the instructed amount. |
| E13, D50, E15 | Rule | Charges fields do not fit 71A: OUR with 71F (E13), SHA with 71G (D50), BEN without 71F or with 71G (E15). | Fix 71A first, then remove or add 71F and 71G to match it. |
| C02, D57 | Rule | 71G currency differs from 32A (C02) or 71G is zero (D57). | Put 71G in the 32A currency, or leave it out if there are no receiver’s charges. |
| C81 | Rule | 56a (intermediary) present without 57a (account with institution). | Add the beneficiary’s bank in 57a or remove the intermediary. |
| E06 | Rule | 55a present without both 53a and 54a. | Use 55a only when 53a and 54a name two different correspondents. |
| E18 | Rule | 23E contains CHQB and 59a still has an account. | Remove the account line when the payment is made by cheque. |
Example
ZagTrader Test Bank in Dubai sends an MT103 to BANKGB2LXXX: the customer instructed EUR 29,000.00 and the bank converted it to GBP 25,230.00 at 0.87, but the payment system did not add the exchange rate. The network refuses it with D75 because 33B and 32A have different currencies and field 36 is missing. Open it in the parser to see the fields; the fix is one added line, :36:0,87, after 33B.
{1:F01ZAGTAEADAXXX0000000000}{2:I103BANKGB2LXXXXN}{3:{121:64517c30-d8bb-4b91-b074-b3bd403e6eaf}}{4:
:20:ZT2610200014
:23B:CRED
:32A:261022GBP25000,00
:33B:EUR29000,00
:50F:/AE070331234567890123456
1/GULF TRADING LLC
2/OFFICE 1204 BUSINESS BAY TOWER
3/AE/DUBAI
:59F:/GB42BANK40051587654321
1/ACME COMPONENTS LTD
2/1 HIGH STREET
3/GB/LONDON
:70:/INV/2026-0461
:71A:SHA
-}Open this example in the parserThe message is deliberately wrong: 33B is in EUR, 32A in GBP and there is no field 36, which breaks network validated rule C1 of the MT103 (error code D75).
The NAK for it is a service message with {451:1} and the error code in field 405.
The Sender is in AE, so rule C2 (D49) does not force 33B here; it is present because a currency conversion took place.
BICs, names, IBANs and the UETR are made up; the IBANs carry valid check digits.
Questions
- What is a NAK on Swift?
- A negative acknowledgement: the network’s answer that it refused your message at input. It comes as a service message with
{451:1}and an error code in field 405. The message was not delivered. An ACK ({451:0}) means the network accepted it, nothing more. - What does error code T27 mean?
- The BIC in the message is badly formed or invalid. Related codes are T28 (the BIC is not a valid destination), T29 (invalid branch code) and T45 (invalid non-connected BIC). Check the BIC and its branch code in the BIC directory.
- What does D75 mean in an MT103?
- Field 36 (exchange rate) does not fit 33B: either 33B is in a different currency from 32A and 36 is missing, or 36 is present although both currencies are the same.
- Why are MT103s that used to pass now NAKed?
- Since 22 November 2025, cross-border MT103s on Swift go through contingency processing. They are checked against stricter rules so they can be converted to pacs.008, and messages that fail are NAKed. Compare your layout with the rules in the Standards MT Release Guide 2025, or send pacs.008 directly.
- What do the letters T, C, D and E in Swift error codes mean?
Tcodes are text validation errors in a single field.C,DandEcodes refer to message validation rules (C for rules 000 to 099, D for 100 to 199, E for 200 to 299), which usually check how fields relate to each other.