📨 Swift MT and the MT940 statement

The MT family: payment and cash reporting messages

MT (Message Type) messages are the legacy format of Swift's FIN network. They are structured text messages built from tags (:20:, :61:, and so on) and grouped into categories: 1 = customer payments, 2 = financial institution transfers, 9 = cash management. Category 9 is the one that matters for reconciliation, because it carries account statements.

An “MT940” that a company receives has not necessarily traveled over Swift. The format became the lingua franca of electronic statements, and most banks deliver it as a file over EBICS, SFTP, or FileAct. The file then lacks the FIN network header blocks, but the tags read exactly the same way.

The MT940, tag by tag

An MT940 is an ordered sequence of tags. The balances (:60F:, :62F:, :64:, :65:) all use the same compact format: debit/credit mark (C/D) + YYMMDD date + ISO currency code + amount with a decimal comma. Each entry is carried by a :61: (structured data) and :86: (narrative and additional information) pair. The first is standardized; the second is left to each bank.

Field :61: broken down

Field :61: packs all the structured information about an entry into one dense line. Its Swift syntax is 6!n[4!n]2a[1!a]15d1!a3!c16x[//16x][34x], a compact notation that only becomes readable once a real line is broken down.

:61:2607100710C12500,00NTRFPAYOUT-ADYEN-42//BNK7593012

260710            1. Value date (6!n, YYMMDD)          -> July 10, 2026
0710              2. Entry date (4!n, MMDD, optional)  -> 07/10; the year is implicit
C                 3. Debit/credit mark (2a): C credit, D debit,
                     RC/RD reversal of credit/debit
(absent)          4. Funds code (1!a): 3rd letter of the
                     currency code, rarely used
12500,00          5. Amount (15d): decimal comma
                     required, NO thousands separator
NTRF              6. Transaction type (1!a3!c):
                     N + Swift-defined code (TRF here)
PAYOUT-ADYEN-42   7. Reference for the account owner (16x):
                     "NONREF" if the bank has none
//BNK7593012      8. Bank reference ([//16x])
(next line)       9. Supplementary details ([34x]), optional

A complete annotated MT940

An e-commerce merchant's statement for July 10, 2026: two PSP payouts credited, plus a supplier direct debit and bank charges debited. Lines starting with # are teaching annotations, added here for readability; they do not appear in the actual file.

# FIN network header (simplified): present if the message goes over Swift,
# absent when the MT940 is delivered as a file via EBICS / SFTP.
{1:F01BNPAFRPPAXXX0000000000}{2:O940AGRIFRPPXXXN}{4:
:20:AC940260710-0132
# :20: unique message reference, assigned by the sending bank
:25:FR7630004008120002345678928
# :25: account concerned (here, the IBAN)
:28C:132/1
# :28C: statement no. 132 of the year, page 1 -> sequence check
:60F:C260709EUR98425,12
# :60F: opening balance: Credit, July 9, 2026, EUR, 98,425.12
:61:2607100710C12500,00NTRFPAYOUT-ADYEN-42//BNK7593012
:86:/ORDP/ADYEN N.V./REMI/SETTLEMENT BATCH 42 ACME FR
# Entry 1: Adyen payout of 12,500.00, credited. The :86: identifies the
# ordering party (/ORDP/) and the remittance info (/REMI/) - bank-specific coding.
:61:2607100710C8420,00NTRFSTRIPE-PO-1PAB77//BNK7593013
:86:/ORDP/STRIPE TECHNOLOGY EUROPE/REMI/STRIPE PAYOUT
# Entry 2: Stripe payout of 8,420.00. The customer reference (16x max)
# was truncated: the full identifier is po_1PabQ2KiAcme7731.
:61:2607100710D1840,50NDDTRENT-2026-07//BNK7593044
:86:/MARF/UMR-FONCDOCKS-0042/CRED/FR12ZZZ556677/REMI/RENT JULY
# Entry 3: SEPA direct debit, debited. /MARF/ = mandate reference (UMR),
# /CRED/ = SEPA creditor identifier (SCI).
:61:2607100710D25,00NCHGNONREF//BNK7593101
:86:ACCOUNT MAINTENANCE FEE JULY 2026
# Entry 4: bank charges, NCHG, no customer reference -> NONREF.
:62F:C260710EUR117479,62
# :62F: closing balance: 98,425.12 + 12,500.00 + 8,420.00 - 1,840.50 - 25.00
:64:C260710EUR117479,62
# :64: available balance by value date (identical here: everything is value-dated today)
:65:C260711EUR117479,62
# :65: forward balance for July 11
-}

• Check 1 (arithmetic): 98,425.12 + 12,500.00 + 8,420.00 − 1,840.50 − 25.00 = 117,479.62 = :62F:. ✔
• Check 2 (sequence): statement 132/1 follows the previous day's 131/x, and its :60F: equals the previous day's :62F:.
• Check 3 (matching): PAYOUT-ADYEN-42 matches batch 42 in the Adyen settlement report. The truncated Stripe reference forces a fallback match on amount + date.

The BIC: identifying banks

The BIC (Business Identifier Code, ISO 9362) identifies each institution on the Swift network and in SEPA messages. It comes in an 8-character version (BIC8, the institution) and an 11-character version (BIC11, with a branch code).

In back-office systems, the BIC shows up in FIN headers, in counterparty details (RltdAgts in camt messages), and in bank channel configuration. Since SEPA Regulation 260/2012, the IBAN alone is enough for credit transfers and direct debits within the EU (“IBAN only”), but the BIC is still essential for multi-bank setups and international payments.

ISO 20022 migration: CBPR+ and the future of MT940

The CBPR+ program (Cross-Border Payments and Reporting Plus) is moving Swift cross-border payments from MT messages to MX (ISO 20022) messages. Coexistence began in March 2023. Category 1 and 2 MTs were retired from interbank FIN traffic in November 2025, ending coexistence for those two categories.

Cascading truncation is the information a payment loses when it changes format along the way. A transfer received as a data-rich pacs.008 may be reported in a pared-down MT940 that has no room for long references or structured party data. Banks maintain MX-to-MT mapping tables that document this data loss (the CBPR+ data truncation concept), which weighs in favor of receiving statements in ISO 20022.