MT940 Format Explained: SWIFT customer statement

MT940 at a glance
Message	`MT940`
Name	SWIFT customer statement
Read by	MT940 Viewer

Who sends it, and when

The account-holding bank sends it to the account owner after the end of the business day: over SWIFT (as a FIN message) for companies connected to it, or as a file (often .sta or .940) over host-to-host, EBICS or online banking. Between banks the same statement is an MT950.

The structure of an MT940

MT940 · structure

{1:F01…}{2:O940…}          SWIFT headers (absent in files from online banking)
{4:
:20:   Transaction reference
:21:   Related reference (optional)
:25:   Account identification
:28C:  Statement number / page
:60F:  Opening balance (:60M: on a continuation page)
:61:   Statement line   ┐ repeated, one per entry
:86:   Details          ┘
:62F:  Closing balance (:62M: if the statement continues)
:64:   Closing available balance (optional)
:65:   Forward available balance (optional, repeatable)
:86:   Information about the whole statement (optional)
-}

Versions in use

MT940 is a SWIFT FIN message type, maintained in SWIFT’s yearly standards releases rather than in versions. What differs between banks is how they fill it: the :86: structure, the account format, the transaction type codes. The viewer reads SWIFT messages with or without their headers, and several statements in one file.

An annotated MT940

An excerpt of the sample the viewer opens (fictitious companies, published test account numbers):

mt940-multi-statement.sta

{1:F01NWTHDEF1AXXX0000000000}{2:O9400615261028COBADEFFAXXX00000000002610290615N}{4:
:20:STMT301P1
:25:DE89370400440532013000
:28C:00301/001
:60F:C261027EUR23456,78
:61:2610281028C1190,00NTRFAW-2026-0815//COBA261028001
:86:166?00SEPA-GUTSCHRIFT?100931?20EREF+AW-2026-0815?21SVWZ+RE 2026-0
815 Kd 4711?30SSKMDEMMXXX?31DE75512108001245126199?32Adventure Wo
rks GmbH
…
:62M:C261028EUR24556,88
-}{5:{CHK:4F3A9C2B71D0}}

“…” marks lines left out.

MT940 sample, explained
In the file	What it says
`{2:O940…COBADEFFAXXX…}`	Application header: an output MT940, sent by the bank with BIC COBADEFF.
`:25:DE89370400440532013000`	The account, here an IBAN.
`:60F:C261027EUR23456,78`	Opening balance: credit, 27 October 2026, EUR 23,456.78.
`:61:2610281028C1190,00NTRF…`	A credit of 1,190.00 on 28 October, a transfer (NTRF).
`:86:166?00SEPA-GUTSCHRIFT…`	Its details in German ?nn subfields: booking text, end-to-end id, remittance, payer.
`:62M:`	Intermediate closing balance: the statement continues on a second page.

Open this sample in the MT940 Viewer

Common validation errors

What most often goes wrong in an MT940, and the rule that reports it in the viewer and the API:

mt.balance.roll-forward (Balances do not roll forward): :60F: plus the :61: lines does not give :62F:.
mt.balance.continuity (Statements do not chain): A page or statement that does not open with the previous closing balance.
mt.field.required (Mandatory field missing): A missing :20:, :25:, :28C:, :60F: or :62F:, or a :61: without its reference.
mt.date (Invalid date): An impossible date (YYMMDD or MMDD).
mt.field.length (Field too long): A reference over 16 characters, or a :86: over 6 lines of 65.
mt.sequence (Statement numbering): A missing or repeated page in :28C:.

Check an MT940 from a script or an AI agent

Scripts and AI agents can do the same without a browser: POST /api/v1/validate or the MCP tool validate_payment_file returns every issue with its rule id, severity, line and path, and whether the file is valid. No key is needed, and the file is processed in memory and never stored (API and MCP docs).

REST · curl

curl -s --data-binary @mt940-multi-statement.sta https://iso20022-navigator.com/api/v1/validate

MCP · tools/call

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "validate_payment_file",
    "arguments": {
      "content": "<the file text>"
    }
  }
}