Bite Apps › SafeCAMT › MT940 format
MT940 format explained — every field, :61: and :86: in detail
How a SWIFT MT940 bank statement is built: all fields from :20: to :65: with their formats, a subfield-by-subfield breakdown of the :61: statement line, the transaction type codes, and the two common :86: conventions — German ?-subfields with SEPA keywords and slash codes.
Need the transactions in Excel, a reconciliation check or a camt.053 version? SafeCAMT does it in your browser — the statement is never uploaded.
Open SafeCAMT — free, in your browser- A complete MT940 statement
- MT940 fields
- Reading the format notation
- The :61: statement line
- Transaction type codes
- The :86: field
- MT940 vs camt.053
- FAQ
A complete MT940 statement
:20:STMT261102 :25:DE44500105175407324931 :28C:00217/001 :60F:C261101EUR48210,55 :61:2611021102CR9800,00NTRFNONREF//2026110200124 :86:166?00SEPA GUTSCHRIFT?20EREF+INV-2026-0412 ?21SVWZ+RF18539007547034?30ABNANL2A?31NL91ABNA0417164300 ?32Nordwind Logistics BV :61:2611021102D1250,40NDDTNONREF//2026110200131 :86:105?00SEPA LASTSCHRIFT?20MREF+M-88213?21SVWZ+Office lease Nov :62F:C261102EUR56760,15 :64:C261102EUR56760,15 -
The statement opens with a credit balance of 48,210.55 EUR, books a credit of 9,800.00 and a debit of 1,250.40, and closes at 56,760.15 — 48,210.55 + 9,800.00 − 1,250.40. That arithmetic is exactly what SafeCAMT’s reconciliation checks for every statement in a file. In a SWIFT-delivered file the text block is wrapped in {1:…}{2:…}{4: … -} headers; files downloaded from online banking often omit them.
MT940 fields
| Tag | Name | Format | Status | Contents |
|---|---|---|---|---|
| :20: | Transaction Reference Number | 16x | Mandatory | Reference of this statement message, assigned by the bank. |
| :21: | Related Reference | 16x | Optional | Reference of a related message (for example the MT920 request). |
| :25: | Account Identification | 35x | Mandatory | The account the statement is for — often the IBAN, sometimes BIC/account or bank code/account. |
| :28C: | Statement Number / Sequence Number | 5n[/5n] | Mandatory | Statement number and page (sequence) number, e.g. 00123/001. Gaps mean a missing statement or page. |
| :60F: | Opening Balance (first) | 1!a6!n3!a15d | Mandatory* | D/C mark, date YYMMDD, currency, amount. Equals the previous statement’s closing balance. |
| :60M: | Opening Balance (intermediate) | 1!a6!n3!a15d | Mandatory* | Used instead of :60F: on the second and later pages of a multi-page statement. |
| :61: | Statement Line | 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x][34x] | Optional, repeating | One booked transaction — see the breakdown below. |
| :86: | Information to Account Owner | 6*65x | Optional | After a :61: — details of that transaction (counterparty, IBAN, remittance). After the last :62a: — information about the whole statement. |
| :62F: | Closing Balance (booked) | 1!a6!n3!a15d | Mandatory* | Booked balance at the end of the statement. |
| :62M: | Closing Balance (intermediate) | 1!a6!n3!a15d | Mandatory* | Closing balance of a page when the statement continues on the next page. |
| :64: | Closing Available Balance | 1!a6!n3!a15d | Optional | Funds available to the account owner. |
| :65: | Forward Available Balance | 1!a6!n3!a15d | Optional, repeating | Available balance on future value dates. |
* One opening balance (:60F: or :60M:) and one closing balance (:62F: or :62M:) are mandatory in each message. The interim report MT942 uses the same :61: and :86: lines but replaces the booked balances with :34F: floor limits and :90D:/:90C: totals.
Reading the format notation
SWIFT formats use length + type codes: n digits, a letters, c letters and digits, x any SWIFT character, d a decimal amount with a comma. 16x means up to 16 characters, 6!n exactly six digits, […] an optional part and 6*65x up to six lines of 65 characters. A balance 1!a6!n3!a15d therefore reads: D/C mark, date YYMMDD, currency, amount — C261101EUR48210,55.
The :61: statement line, subfield by subfield
Example: :61:2611021102CR9800,00NTRFNONREF//2026110200124
| # | Subfield | Format | Rules | In the example |
|---|---|---|---|---|
| 1 | Value date | 6!n | YYMMDD | 261102 |
| 2 | Entry (booking) date | [4!n] | MMDD, optional | 1102 |
| 3 | Debit/credit mark | 2a | C credit, D debit, RC reversal of credit, RD reversal of debit | CR → C |
| 4 | Funds code | [1!a] | Optional third letter of the currency code | — |
| 5 | Amount | 15d | Decimal comma, no thousands separator | 9800,00 |
| 6 | Transaction type identification code | 1!a3!c | N + code for non-SWIFT bookings, S + MT number for SWIFT transfers (e.g. S103), F + code for first advice | NTRF |
| 7 | Reference for the account owner | 16x | Customer reference; NONREF if there is none | NONREF |
| 8 | Reference of the account servicing institution | [//16x] | Bank’s own reference, after a double slash | //2026110200124 |
| 9 | Supplementary details | [34x] | On a new line, optional | — |
Note the trap in the example: after the D/C mark C comes the optional funds code R (the third letter of EUR) — a parser that reads CR as “reversal of credit” gets the sign wrong. The mark is RC for a reversal, never CR. Reversals must be booked with the opposite sign of what the letters suggest; dropping or mis-signing them is a classic reason why imported statements stop reconciling.
Transaction type identification codes
The four characters after the amount classify the booking. With N the next three letters are a code such as:
| Code | Meaning |
|---|---|
| NTRF | Transfer |
| NCHG | Charges and other expenses |
| NCHK | Cheques |
| NCOL | Collections |
| NCOM | Commission |
| NDDT | Direct debit item |
| NDIV | Dividends |
| NFEX | Foreign exchange |
| NINT | Interest |
| NMSC | Miscellaneous |
| NRTI | Returned item |
| NSTO | Standing order |
| NTRN | Transaction fee |
| NTCK | Travellers cheques |
These codes are coarse — banks put the precise transaction type in :86:, for example the German GVC (166 = SEPA credit transfer received, 105 = SEPA core direct debit) or a proprietary code. camt.053 replaces them with the three-level ISO bank transaction code: GVC 166 becomes PMNT/RCDT/ESCT, GVC 105 becomes PMNT/RDDT/ESDD.
The :86: field
:86: is free text of up to 6 × 65 characters, and its structure is bank- and country-specific. Two conventions cover most files.
German structured :86: (DFÜ-Abkommen)
Starts with the three-digit GVC, followed by subfields introduced by ? and a two-digit number:
| Subfield | Contents |
|---|---|
| ?00 | Booking text (Buchungstext), e.g. SEPA GUTSCHRIFT |
| ?10 | Primanota / journal number |
| ?20 – ?29 | Purpose lines (Verwendungszweck), carrying the SEPA keywords below |
| ?30 | Bank code (BLZ) or BIC of the counterparty |
| ?31 | Account number or IBAN of the counterparty |
| ?32 – ?33 | Counterparty name |
| ?34 | Text key extension / return reason |
| ?60 – ?63 | Further purpose lines |
Inside the purpose lines, SEPA data is tagged with keywords:
| Keyword | Meaning |
|---|---|
| EREF+ | End-to-end reference |
| KREF+ | Customer reference |
| MREF+ | Mandate reference (direct debits) |
| CRED+ | Creditor identifier (direct debits) |
| DEBT+ | Originator identifier |
| SVWZ+ | Remittance information (purpose) |
| ABWA+ | Ultimate debtor (abweichender Auftraggeber) |
| ABWE+ | Ultimate creditor (abweichender Empfänger) |
| IBAN+ | Counterparty IBAN |
| BIC+ | Counterparty BIC |
Slash-coded :86: (Dutch and many international banks)
Fields are introduced by codes between slashes: /TRTP/SEPA OVERBOEKING/IBAN/NL91ABNA0417164300/BIC/ABNANL2A/NAME/Nordwind Logistics BV/REMI/USTD//Invoice 412/EREF/INV-2026-0412. Common codes are /NAME/, /IBAN/, /BIC/, /REMI/ (remittance, with /USTD// unstructured or /STRD/ structured), /EREF/, /MARF/ (mandate reference), /CSID/ (creditor ID), /RTRN/ (return reason) and /CNTP/ (counterparty block).
SafeCAMT understands both conventions and maps them to the camt.053 elements when it converts MT940 to camt.053.
MT940 vs camt.053
camt.053 is the ISO 20022 successor of MT940. It carries the same balances and entries, but every piece of the :86: text gets its own element — EndToEndId, RltdPties/Dbtr, RmtInf/Strd — and one entry can hold many transaction details. Swift’s CBPR+ roadmap makes receiving camt.052/053/054 mandatory from November 2027 and plans to retire MT9xx statements in November 2028. The tag-by-tag correspondence is in the MT940 to camt.053 mapping table.
FAQ
What is an MT940 file?
MT940 is the SWIFT customer statement message: an end-of-day bank account statement in tagged text format, with an opening balance (:60F:), one :61: line per transaction plus :86: details, and a closing balance (:62F:). Banks also offer it as a download for ERP and accounting imports.
What is the difference between MT940 and MT942?
MT940 is the booked end-of-day statement with opening and closing balances. MT942 is an intraday (interim) report listing transactions booked so far, without booked opening/closing balances.
How do I read the :61: line?
Value date (YYMMDD), optional booking date (MMDD), debit/credit mark (C, D, RC, RD), optional funds code, amount with a decimal comma, transaction type code (e.g. NTRF), customer reference (or NONREF), optional //bank reference, and optional supplementary details on the next line.
How do I convert MT940 to Excel or camt.053?
Open the file in SafeCAMT. It parses :61: and :86:, reconciles the balances, exports CSV or Excel, and converts the statement to camt.053.001.08 — all in your browser, without uploading the file.
Last updated 2026-11-10. Something wrong or missing? Email support@biteapps.cc.