ZagTrader

Category 1: Customer payments and cheques

MT195 Queries

Written and maintained by ZagTrader. Last reviewed . How this page is sourced and checked

The MT195 is the message a bank uses to ask another bank a question about an earlier customer payment or other category 1 message: the beneficiary says the money has not arrived, the beneficiary cannot be identified, the value date looks wrong. It quotes the original message in field 21, puts the question in field 75, and always expects an answer, preferably an MT196.

Message type
MT195
Category
1
Structure
7 fields listed
ISO 20022
camt.110

When MT195 is used

The MT195 is the category 1 member of the common group MTn95 Queries. The category digit follows the message being queried: a question about an MT103 is an MT195, about an MT202 an MT295, about a statement an MT995. Banks and corporates can both send and receive it.

Typical uses are payment investigations: the beneficiary claims non-receipt, the beneficiary cannot be found at the address given, the account is not held under that name, the value date or interest is wrong, a possible duplicate, a suspected fraud, or a request for more information on a party for regulatory or sanctions screening reasons. A query can also ask for an amendment to an earlier message when the category has no dedicated message or field for that.

Field 21 quotes field 20 of the message queried, so that every query about the same original message points to it. Field 11S or 11R adds the type and date of that message, and the original is identified further by a narrative in field 79 or by a copy of at least its mandatory fields (one or the other, not both).

The answer comes in an MT196 that quotes the MT195’s field 20. To ask for a payment to be cancelled, use the MT192 instead; to say something that fits no structured message, the MT199. The MT195 is also the message the MT101 and MT104 guidelines recommend for rejecting a single transaction.

MT195 format: sequences and fields

Message text (block 4)Mandatory

No sequences. Field 79 or a copy of the original fields may follow, but not both (rule C1).

TagNameStatusFormatMeaning
20Transaction Reference NumberM16xThe Sender’s reference for the query. The answering MT196 quotes it in field 21. No leading or trailing slash and no double slash (T26).
21Related ReferenceM16xField 20 of the message being queried, or an equivalent reference for a non-Swift message. For a single transaction on an MT950 or similar statement, the account servicer’s reference from subfield 8 of field 61 may be used.
75QueriesM6*35xThe question or questions, one per line. A line can start with a query number between slashes followed by the details it needs, for example /1/ (we appear not to have been debited), /2/ (not credited), /3/ (beneficiary says payment not received, please state if and when effected), /4/ (beneficiary cannot identify the transaction), /22/ (possible duplicate), /33/ (fraud suspicion), /52/ (payment blocked by a sanctions screening hit). Free narrative is allowed too.
77ANarrativeO20*35xMore room for the query when six lines in field 75 are not enough.
11aMT and Date of the Original MessageOptions R or SOR: 3!n 6!n [4!n6!n] S: 3!n 6!n [4!n6!n]The type and date (YYMMDD) of the message queried, plus the session number and input sequence number when known. Option S for a message the Sender sent, option R for one it received. The type must be between 100 and 999 (T18) and the date valid (T50).
79Narrative Description of the Message to Which the Query RelatesC35*50xA description of the original message detailed enough for the Receiver to identify it: date, amount, value date, parties. Not allowed together with the copy of fields (rule C1, C31). A first line starting /REJT/ or /RETN/ must follow the payments reject and return guidelines (T80).
(no tag)Copy of at least the Mandatory Fields of the Original MessageCCopy of fieldsThe fields of the message queried, in their original order, or those identifying one transaction of a multiple message. Swift checks their syntax but not that they match the original; 77F and 77T may not be copied (T13). Not allowed together with field 79.

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 (C31): field 79 and the copy of the original fields must not both be present.
  • The MT195 always requires a response, preferably an MT196 Answers.
  • All queries about the same original message refer to it in field 21.
  • Field 75 holds one query per line. Details marked (1) or (2) in the query text come first after the number; a second item is preceded by a slash. Continue on the next line with //, or in field 77A.
  • Query numbers 23 to 29 (copies and details of truncated cheques) are for the MT195 only; numbers 30 to 35 are for the MT295.
  • It is not used to ask about documents sent for collection: the MT420 exists for that.

MT195 example

On 20 October 2026 ZagTrader Test Bank in Dubai (ZAGTAEADXXX) sent BANKGB2LXXX an MT103 with reference ZT2610200001 for GBP 25,000.00, value 22 October, in favour of Acme Components Ltd. A week later the beneficiary says nothing has arrived, so ZagTrader asks BANKGB2LXXX whether and when the payment was effected.

{1:F01ZAGTAEADAXXX0000000000}{2:I195BANKGB2LXXXXN}{4:
:20:ZTQRY2610270001
:21:ZT2610200001
:75:/3/
:11S:103
261020
1234000567
:79:OUR MT103 FOR GBP 25000,00 VALUE 261022
IN FAVOUR OF ACME COMPONENTS LTD
ACCOUNT GB42BANK40051587654321
-}
Decode this example in the parser

Line by line

LineWhat it says
{1:F01ZAGTAEADAXXX0000000000}{2:I195BANKGB2LXXXXN}{4:Same Sender and Receiver as the original MT103. Category 1, because the original is a category 1 message.
:20:ZTQRY2610270001Reference of the query; the MT196 will quote it in field 21.
:21:ZT2610200001Field 20 of the MT103 being queried.
:75:/3/Query 3: the beneficiary says the payment did not arrive; please state if and when it was effected.
:11S:103The original is an MT103 that the Sender sent (option S) ...
261020... on 20 October 2026 ...
1234000567... with session number 1234 and input sequence number 000567.
:79:OUR MT103 FOR GBP 25000,00 VALUE 261022Narrative description of the original, so the Receiver can find it.
IN FAVOUR OF ACME COMPONENTS LTD
ACCOUNT GB42BANK40051587654321
-}End of block 4. No copy of fields, because field 79 is used.

BICs, names, references, session numbers and the IBAN are made up.

Common errors and rejects

  1. Field 79 and copied fields both present (C31)

    Identify the original message either with a narrative in field 79 or with a copy of its fields, not both.

  2. Wrong category digit

    The type follows the message being queried: MT195 for a customer payment, MT295 for a bank-to-bank transfer, MT995 for a statement entry. A query sent with the wrong digit lands in the wrong queue at the Receiver.

  3. Field 21 does not match the original

    If field 21 is not the original field 20 (or the statement reference), the Receiver cannot link the query and will ask back, adding days to the investigation. Copy it exactly.

  4. Query number without its required details

    Some query numbers need details right after them, for example /22/ needs the date and reference of the earlier entry. Leaving them out forces a follow-up exchange.

  5. Invalid MT number or date in 11S (T18, T50)

    The first line of 11a must be a message type from 100 to 999 and the second a valid YYMMDD date.

MT195 in ISO 20022

In ISO 20022, payment investigations use camt.110 Investigation Request and camt.111 Investigation Response. Swift’s CBPR+ roadmap, as reproduced in Citi’s September 2025 client webinar, lists MT195 and MT295 against camt.110 and MT196 and MT296 against camt.111, and marks them for a later end of life.

Exceptions and investigations were not switched on 22 November 2025: BNY’s May 2025 notice says that the migration of MTn92, MTn95, MTn96 and MTn99 depends on the roll-out of Swift’s Case Manager. Until then the MT195 remains in use for payment questions. Cancellation requests have their own pair, camt.056 and camt.029.

MT195 questions

What is an MT195?
A query from one bank to another about an earlier customer payment or other category 1 message, for example to ask whether a payment the beneficiary has not received was executed.
What does /3/ mean in field 75?
Query number 3: we have been told the beneficiary did not receive the payment or cheque; please state if and when the transaction was effected. Other common numbers are /1/ (we appear not to have been debited), /2/ (not credited) and /4/ (the beneficiary cannot identify the transaction).
What is the difference between MT195 and MT199?
The MT195 is a structured query linked to an earlier message, with numbered questions and an expected answer in an MT196. The MT199 is free text for anything that has no message of its own.
How is an MT195 answered?
With an MT196 Answers that quotes the MT195’s field 20 in its field 21 and gives the answer in field 76.
What is the difference between MT195, MT295 and MT995?
They are the same MTn95 Queries layout. The first digit follows the message being queried: 1 for customer payments, 2 for financial institution transfers, 9 for statements and cash management.
What replaces the MT195 in ISO 20022?
camt.110 Investigation Request, answered by camt.111. Their adoption depends on the roll-out of Swift’s Case Manager, and the MT195 stays in use until then.

All MT messages · Category 1 messages · ISO 20022 messages · Codes · Troubleshooting