SWIFT MT940 Customer Statement – Detailed analysis
The SWIFT MT940 is called Customer Statement Message. It is basically an account statement and therefore provide detailed information about all entries booked to an account. It can be sent:
either directly to the account owner – In the SWIFT world account owners are banks or corporations.
or to financial institution authorised by account owner to receive it – The authorised financial institution can also play the role of a concentrating financial institution for an account owner. It then receives SWIFT MT940 from various banks and delivers them to the account owner.
You can read the SWIFT MT940 message specifications here. In this article, we will consider an example of SWIFT MT940 and analyze the content. It is a SWIFT MT940 sent to an account owner which is a bank, in our case Citibank New York that has a correspondent account with BNP Paribas Paris as we see on the picture below.
On the table below, you see the fields that are transported in the SWIFT MT940 message sent by BNPP to Citi. Additional comments are provided to ease the understanding of each field and what it is used for. We have three entries in the statement: two debit entries and one credit entry.
The Sender BIC appears in header block (Block 1) in the MT940 Input and in the application block (Block 2) in the MT940 Output.
This introduces the Text block (block 4). All the fields below are in the text block of the MT940 message.
Transaction Reference Number
This is the Sender's Reference specific to this MT940. It is generated by BNPAFRPP.
Mandatory and of format 35x (No letter option). It is the account number of CITIUS33. BNPAFRPP is the account holder.
Statement Number/Sequence Number
Mandatory and of format 5n[/5n] for statement number/sequence number. Only one message is sent for this statement. The sequence number 1 might have been omitted.
Mandatory and of format 1!a6!n3!a15d (D/C Mark)(Date)(Currency)(Amount). In D/C Mark, C for Credit Balance and D for Debit balance.
Optional and provided in format 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x] [34x] - The last element supplementary details must be on a new line. Here we have the following elements 180908: Value date D: Debit entry 73929,05: Amount of the entry S103: S for SWIFT Transfer, 103 for the Message Type received. ORIGREF242: For a debit entry, the Reference for the Account Owner is the field 20 Sender's Transaction Reference Number (or its equivalent) of the original instruction. The original MT103 was initiated by another institution, not by BNPAFRPP. BNPPOWNREF984: Own reference assigned to the transaction by BNPAFRPP. In case BNPAFRPP initiated the transaction, this would be populated in the preceding field and this one could remain empty. Supplementary Details is not populated. The information to Account owner is not provided for the 1st transaction.
Optional and provided in format 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x] [34x] - The last element supplementary details must be on a new line. Here we have the following elements 180908: Value date C: Credit entry 64765: Amount of the entry S202: S for SWIFT Transfer, 202 for the Message Type sent. BNPPOWNREF789: For a debit entry, the Reference for the Account Owner is the field 20 Sender's Transaction Reference Number (or its equivalent) of the original instruction. The original MT202 was initiated by BNPAFRPP. That is why it is populated here. Reference of the Account Servicing Institution and Supplementary Details are not populated.
Information to Account Owner
:86:/BENM/BANK OF SHANGAI /REMI//INV/8299389
Optional field populated in format 6*65x. It is related to the 2nd Transaction. The beneficiary party is identified with the preceding code /BENM/. /REMI/ indicates that /INV/8299389 comes from the remittance information (F70).
Optional and provided in format 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x] [34x] - The last element supplementary details must be on a new line. Here we have the following elements 180908: Value date C: Credit entry 363592,78: Amount of the entry NBOE: N for Non-SWIFT Transfer, BOE Bill Of Exchange NONREF: No reference was provided by the sender. BNPPOWNREF896: Own reference assigned to the transaction by BNPAFRPP. Supplementary Details is not populated. The information to Account owner is not provided for the 1st transaction.
Information to Account Owner
:86: /ORDP/PARIS CORP NGO TRANSACTION
Optional field populated in format 6*65x. It is related to the 3rd Transaction. The ordering party is identified with the preceding code /ORDP/. Non Governmental Organization Transaction
Mandatory and of format 1!a6!n3!a15d (D/C Mark)(Date)(Currency)(Amount). The C at the beginning means it is a Credit balance. Otherwise it would be a D for Debit Balance. Closing Balance = 26382,85-73929,05-64765+363592,78 = 251281,58
End of Message Text/Trailer
Read this page on the SWIFT formatting rules and Character sets of MT Messages to get additional information and understand what 16x, 35x and the format of the field options mean.
Narratives and notes on this SWIFT MT940 message
Below we provide some narratives and notes about the SWIFT MT940 statement message to better understand its meaning and content. Read them and review the table above to grasp the details. You can also check the SWIFT MT940 format specifications.
Narrative and note 1 (Main purpose of this SWIFT MT940)
With this message, BNP Paribas (BNPAFRPP) is providing an account statement to Citibank (CITIUS33) with all the debit and credit entries booked on the account. Note that the currency of the account is EUR and so the currency of the transactions (entries).
Narrative and note 2 (Information to Account Owner in the SWIFT MT940 )
The SWIFT MT94x contains an optional field called Information to Account Owner (F86) that is not available in the SWIFT MT950. It can be repeated along with each statement line and provides additional information about the related entry and must be passed on to the account owner.
Narrative and note 3 (The SWIFT MT940 can theoretically be used as a cover)
Citibank (CITIUS33) is informed with the statement that its account has been credited. If the credit is related to a MT202 COV, the related reference will be provided in the subfield 7 of the related statement line. See previous article on the SWIFT MT950 message.
With the analysis of SWIFT MT950 in the previous article and SWIFT MT940 in this one, we start to understand how account statements are formatted and structured in the SWIFT world. But we haven’t spoken at all about the available balances in the SWIFT MT940: closing available balance and forward available balance. It is important to understand what they are. Therefore it will be the topic of the next article.
Even mt 940 can be used to send statement to account owner than what is the difference betweem 940 and 950.
The MT940 is usually sent by a bank to another bank (concentrating institution) which is authorized by the account owner (a company or a bank) to receive it while the MT950 is usually sent by a bank directly to the account owner. The MT940 can also be sent to the account owner directly of course. In the MT940, additional information about the line statements can be provided. You can also find the Forward Available Balance in the MT940. But both are account statements and the one or the other may be used in many cases.
Thanks for sharing valuable info about MT940/MT950 message. I have one query, regarding Additional Information (F86). Is there any standards specified for sharing information in F86. E.g. If multiple information is provided in this field, then what should be delimiter/separator to differentiate between two or more values(like in F61 statement line // is used to differentiate between Owner Ref and Sender Ref).
In the SWIFT standards, we read that the format of the field 86 is 6*65x. Up to 6 lines with maximum 65 characters.
Except what you read in the usage rules, I am not aware of other specificities.
But an agreement is possible between two or more parties to structure this field according to their own needs.
They will then decide how to structure it.
Hi Jean Paul, great material you have here. One question re: Field 86. Do the invalid SWIFT characters under EBCIDC apply to Field 86? There are several invalid SWIFT characters, but i’m wondering if they apply to free form fields like Field 86 or only certain validated fields?
1. Tag 61 is mandatory in case of MT940 and non mandatory in case of MT950. Hence I would say, MT940 is a detailed statement, whereas MT950 not necessarily detailed statement, it could just be a summary by providing only the opening balance and closing balance.
2. Presence of tag 86 in 940 and absence in 950. Implies, additional information to the account owner can be provided in 940 and not in 950
Hi Srikanth, Thanks for your contribution. I fully agree with the point 2. As for the point 1, I checked the SWIFT specifications again and the Tag 61 is optional.
Thanks a lot Paul. Is it also true that mt940 only includes entries which are results of swift messages but mt950 includes all types of entries.
Hi Pramod, Both MT940 and MT950 are account statements with all entries booked on the account, no matter if entries result from SWIFT messages or not. An account statement with entries resulting only from SWIFT messages would not make sense at all. The customer would never know exactly how much money he has on the account and could therefore not be able to make any decision. Account statements always include all entries independent of the origin. Thanks for allowing me to clarify this. If you have further question, do not hesitate.
Thank a lot Paul. Your site is really valuable. I really appreciate your work.
Each MT940 message come to bank in relation to respective MT103 message next day.
If a Bank has Nostro account with another Bank. Then I want to know which Banks creates and send MT940 message for a MT103 payment. is the Nostro Bank creates MT940 or Transaction initiated Bank.
The MT940 is an account statement. The sender of the MT940 is the account holder and the receiver is the account owner.
It does not matter if the account is a Nostro or a Vostro. The sender is always the account holder and the receiver is always the account owner. Let me know if you need more explanation.
do some MT940 swift messages differentiate or are they all the same (with the exception of Optional fields)
The MT940 must stick to the same rules and specifications (See https://www.paiementor.com//swift-mt940-format-specifications/). In that sense, they are all the same. 🙂
Hi Jean Paul,
I would like to ask you one question:
– is there a way to send MT940s through a correspondent bank?
Just to describe the issue I am facing (as the client): I want to activate MT940 (receiving bank will be BNP) and sender will be BYLADEM1001. I have contacted the sender bank and they said that they should send the MT940 statement through a correspondent bank (in my case BYLADEMM) – looks like the same bank (maybe its the central office).
Is that possible? Which whom of the parties should I sign the agreements in case this is possible?
Thank you for your time!
The answer to first question is clearly Yes. It is possible and you do not have the choice in this case. BYLADEM1001 (1 at position 8) is a not connected BIC and therefore cannot send messages. For cost reduction and efficiency, they have centralised the sending of MT940 in the main office. For the receiver, it does not matter that much. You get the account statement anyway. It is just that the sender BIC will be different. Everything else will be the same.
For the second question, I do not know. There are so many cases and regulation is different per country. If anyone can help, feel free to do so.
Yes, you can sign the agreement with the BYLADEMM for the account statement. As Jean rightly pointed out that any Swift BIC with the eight digit ending with 1 is an “Invalid Swift bic” – meaning not connected and hence cannot send or receive. However, in those cases all the details availability and the agreement can be signed with the Head office Swift bic.
Hope this clarifies., sorry i was just going through the reply, noticed this one.
Hi Jean Paul,
I would like to know if the MT940 carries a field for the deposit date of cash/cheques. and If not, are there any unused fields in the MT940 format where the bank could specify the date as a text field so that the same would reflect in customer EBRS
Thanks in advance
there is no specific field in the MT940 for the deposit date of cash/cheques. In the statement line, there is a 34 long field where you can potentially put that information. If not, you have Information to Account Owner (Field 86) that is pretty long and could bear that information too.
The receiving party must be informed about position, format and length of that information if it should process it STP. If not you can write explicitly “Deposit date of cash YYYYMMDD”.
Hi Jean Paul, what is the purpose of Option P in tag 25, and how is it used? Regards
Option P allows you to provide the BIC of the account owner in addition to the account number. This option is generally used when the receiver is not the account owner. It is receiving it on behalf of the account owner. The BIC allows to easily identify the account owner and forwards him the statement if required.
I am a little confused regarding the account holder and account owner.
I am stuck on this as my bank is not providing the correct header details and I am unclear as to what exactly I should be asking for.
I am trying to configure an bound integration for my bank statement with a new format of MT940 but I am having issues as my file is missing the BIC and Bank code.
I assume, my company – Company X is the account holder and therefore the receiver of this information. Is this correct?
I don’t expect to have a account owner BIC that varies from the account holder.
I would expect my statement to be named
‘MT940HSSBCCE x x x x x x x’
Hi Susan, my understanding is that your company (company X) is the receiver and your bank is the sender. Since you are receiving the account statement from SWIFT, it should contain an application Header Block for Output Message. You can find the specifications here with examples. Please check and let me know if you have further questions.
We generate MT940 statement for a date range (eg : 01-03- 2019 to 30-04-2019). It is split into multiple messages.
In all the messages, the Intermediate Account opening balance tag (Tag 60M ) is always populating date as 01-03- 2019 and Intermediate Account closing balance(Tag 62M) is always populating as 30-04-2019, whereas the balances are populating as per the corresponding opening date and closing date of transaction in a message.
Is this the correct functionality?”
Sorry for not answering before. I am very busy at the moment.
To be strict, the date of the Intermediate Account opening balance tag (Tag 60M) should ideally take the date of the last (debit or credit) entry and the date of the Intermediate Account closing balance(Tag 62M) should also ideally take the date of the last (debit or credit) entry.
That totally makes sense. In reality, people do not care that much about those dates as long as the balances are correct. What truly matters in a statement are the dates of the opening and closing balances.
Dates of Closing Available Balance and Forward Available Balance are really important too. They must be correct. If you can easily fix the dates of intermediate balances, do it. Receivers won’t waste time asking themselves the same question.
Hello Jean Paul
This is a great site and I am very appreciative of the resources shown and the clear explanations. Question – is it acceptable per MT940 standard to have “blank space” between one statement the next? See below example:
I am receiving this from a bank currently and the bank is pushing back on removing space. Our integration however is rejecting because of this space. Thanks!
Thanks for the appreciation! Characters in the SWIFT MT world are not always an easy topic.
If I understand correctly, you have two CrLf characters between one statement and the other and your integration does not expect that.
Unfortunately that specific point is not clear in the SWIFT standards. The standard specifies the use of CrLf for fields, but does not say anything about the end of the message. At least I am not aware of. However, I have already seen applications like your integration that reject messages if two CrLf come at the end. They expect only one CrLf.
So You cannot oblige the bank to remove the space based on the standards. 🙁 I hope you find a solution.
Hello Jean Paul
This is a great site and i refer it lots of time to find out answers. Related to MT940/950 i have a question. When the MT statements gets broken into multiple pages i.e. what is the length of page so that the generated MT messages gets reported in multiple pages ?
Thanks for your appreciation 🙂
The maximum length of a SWIFT MT940 or MT950 message is 2000 characters. When a statement is broken into multiple pages, the sequence number in the field 28C must be populated accordingly.
Hi Jean. Can you please tell us what is the MT940 file size? (in kb/mb?) And what would be the Swift Message file size as well?
Can we use the SWIFT MT940 format in processing lockbox file of Oracle EBS financials?
I would say it is probably YES, but I am sure. Please check the documentation of Oracle EBS Financials or check with Oracle directly.
Hi Jean Paul,
One question I have received regarding the sending of MT940, is there a rules from SWIFT that mention that in order to send an MT940 to company a SWIFT contrat is mandatory.
I thought that MT940 can be send without having a SWIFT contract has long company sent the instruction to the bank to send MT940?
Not sure what you mean with a SWIFT contract. I am not aware of any contract required in that context. But your bank may have specific rules.
In the SWIFT standard, it is said that the MT940 can be sent to a party authorised by the account owner to receive the information. Obviously, the receiving party must be reachable through the SWIFT network.
Hi Jean Paul,
I am from a Software Product Company delivering MT 940 statement through our system. I understand if the message size is more than 2000 characters, the message needs to be split into multiple pages with incremental message sequence number. In case if we are generating more than one page, what should the value of tag 60 and 62 in each of pages? Same value for 60 and 62 across pages?
Thanks is advance
Below are the SWIFT rules.
The first customer statement message for a specified period must contain field 60F (first opening balance); additional statement messages for the same statement period must contain field 60M (intermediate opening balance).
If there is only one customer statement message transmitted for the period, this field must use tag option F, that is, 62F (final closing balance). When several messages are transmitted for the same statement period, all messages except the last message must contain field 62M (intermediate closing balance); the last message of the statement must contain field 62F.
Thank you so much
Hi Jean Paul,
my task is to process received MT 940 messages, especially doing stuff when a split message has fully received. The sequence number is just a counter. How can I recognize that all sequences of the MT 940 are received?
The last message of the statement must contain field 62F.
Hi Jean, hope you are good?
We (bank) currently deliver the MT-940 to our end clients (corporates) via SFTP. A client requests that the MT-940 should be delivered to their corporate BIC.
Is this a possibility? Could you share some thought on this?
we (bank) are looking to offer to our clients the possibility to deliver the MT-940 via SFTP, but I couldn’t find technical specification about how to implement this in our Swift Alliance. How did you implement your service MT-940 via SFTP?.
Thanks in advance for your help.
In MT940/ MT942 can tag 86 Information to Account Owner (which is coming after field 61) can it come without tag 61? as 61 is optional tag
The answer is Yes. As you said, it is an optional Tag. You don’t have to provide it.
How do you populate the date and balance for interim balance(60M) for file splitting in MT940.
I am doing freelancer service for UK comapny from india.
Uk Comapny transfered the money to my local bank thru wire transfer .My bankers(ICICI) received the payment.
They said that ,we received the money , but without MT940 we couldnt able to transfer the money to your account.
so you have to request your company to ask the sender bank(HSBC) to send the MT940 in the swift Header.
whereas my contract comapny said that you have to ask your bank to contact hsbc to resend the MT940
Really I dont know what i have to do next. whom should sort out my issue?.
Im really struggling trying to find specifications (or at least consistent information) regarding format and/or delimiters when MT940 Statements are paged into multiple pages and sent in a single file. We have seen many variations and would like to know if any are considered more correct. Here is an example of what I have seen:
statement page 1
statement page 2
statement page 1
statement page 2
Any help on this would be greatly appreciated
Someone asked me to look at Tag 25 in these statements. What is Tag 25 and where can I find it in a MT942
We are experiencing an issue with one of our bank account MT940 files in that it doesn’t provide a tag 86 for certain transactions. We queried this with the bank as we could see the additional details for these transactions on the online statement.
Is was their response: the product code for Direct Debits is 1855 – Automated Data Capture Entry, and because the direct debits are not managed within our system that send out the MT940 messages, there is no rule in place to populate these fields.
Have you seen this issue before and do you know of a workaround or fix?
details of Tag 20 – Transaction Reference Number is required…
can any body explain???
Can any one explain what is “Tag 20 – Transaction Reference Number ”
as inquired by Mr. Hamza
Can you plz explain the MT940/942 structure blocks syntax and technical specifications