MT940 Format: The Tags, Line by Line

MT940 is the SWIFT Customer Statement Message — the tagged flat-file end-of-day statement — and the whole format is a short chain of tags: a message reference (:20:), the account (:25:), a statement number (:28C:), an opening balance (:60a:), one :61: statement line per booked entry with an optional :86: information block under it, and the closing balances (:62a:, :64:, :65:). If you're choosing between statement formats, that's the MT940 vs camt.053 vs BAI2 comparison; if your file is XML, you want the camt.053 field walkthrough; if it's a US flat file, the BAI2 record walkthrough. This post is for the day an MT940 is in front of you and you need to know what each tag and subfield actually holds — verified against a bank's published implementation (Nordea's MT940 service description), because SWIFT's own specification sits behind the user handbook login.

And no, this isn't archaeology. The CBPR+ interbank coexistence period ended in November 2025, but the corporate-to-bank space runs on its own clock: SWIFT's SCORE participants can continue exchanging MTs like MT940 after the cutover, and migration is not yet mandatory for corporates — the MT retirement timeline post untangles the different clocks. MT940s keep landing in import folders every morning, which is why the tag-level detail still earns its keep.

The shape of the message

An MT940 is a SWIFT FIN message: blocks delimited by curly braces, with the statement data living in block 4 as a sequence of tags, each on its own line, each starting with a colon-wrapped tag number. The character set is deliberately narrow — uppercase A–Z, digits, and a short list of punctuation (/ - ? : ( ) . , ' + plus space and line breaks). No lowercase, no accents, and that constraint alone explains a lot of shouting beneficiary names in statement archives.

The tag sequence:

:20:   transaction reference number   mandatory   16x
:21:   related reference              optional    16x
:25:   account identification         mandatory   35x
:28C:  statement/sequence number      mandatory   5n[/5n]
:60a:  opening balance (F or M)       mandatory   1!a6!n3!a15d
:61:   statement line                 repeating, one per entry
:86:   information to account owner   optional, follows its :61:
:62a:  closing balance (F or M)       mandatory   1!a6!n3!a15d
:64:   closing available balance      optional    1!a6!n3!a15d
:65:   forward available balance      optional    1!a6!n3!a15d

The format notation is SWIFT's own shorthand, and you only need four readings of it here: 6!n is exactly six digits, 16x is up to sixteen characters, 15d is a decimal amount whose decimal comma is mandatory, and 6*65x (coming up in :86:) is up to six lines of 65 characters. Square brackets mean optional.

:20:, :21:, :25:, :28C: — the header tags

:20: Transaction Reference Number (16x, mandatory) is the reference assigned by the sender to unambiguously identify the message — not the statement, the message. One statement split across three messages has three different :20: values. Store it for support calls; don't key on it.

:21: Related Reference (16x, optional) — rarely interesting on a statement; present in the structure.

:25: Account Identification (35x, mandatory) is the account for which the statement is sent. The format is generous on purpose: banks put IBANs, domestic account numbers, sometimes BIC-prefixed constructions in here. Your importer's account-matching logic should treat it as an opaque string mapped per bank, not parse it.

:28C: Statement Number/Sequence Number (5n/5n, mandatory) is the sequential number of the statement, optionally followed by the sequence number of the message within that statement when one statement spans several messages: 28C:235/1, then 28C:235/2. Two operational facts from Nordea's description worth wiring into an importer. First, the statement number resets to 1 on 1 January each year — so a gap check must tolerate the year-end wrap, or it will page someone every New Year's morning. Second, when downloading files, the sequence numbers will not necessarily arrive sorted — reassemble on :28C:, never on arrival order. This is MT940's version of the gap check I recommend on camt.053's ElctrncSeqNb: a missed statement is a silently wrong cash position, and the statement number is the free detector.

:60a: — opening balance

Format 1!a6!n3!a15d, mandatory, and the little a in :60a: means the tag comes in two variants — :60F: (first opening balance) and :60M: (intermediate opening balance, for multi-message statements; more below). The subfields, in order:

The rule that matters: :60a: must always equal field :62a: of the previous customer statement message for this account. That's the integrity check the format hands you for free — previous closing equals current opening, and opening plus the signed sum of :61: lines equals closing. When either fails you have a missing statement or a broken file, and you want the importer to say so before the cash position ships.

:61: — the statement line, subfield by subfield

This is the tag the whole format exists for: one :61: per booked entry, everything packed into a single line with almost no delimiters. The format string, exactly as specified:

6!n[4!n]2a[1!a]15d1!a3!c16x[//16x][34x]

Nine subfields, in fixed order:

Three of these deserve more than a table row.

The debit/credit mark is two characters wide for a reason. Besides D and C there are RC — reversal of credit, which books as a debit entry — and RD, reversal of debit, which books as a credit. A parser that only knows D and C will either reject reversal lines or, worse, book them on the wrong side. Reversals are rare enough to survive testing and common enough to corrupt a live position.

Subfield 7 is the reconciliation handle. For debit entries its purpose is to identify, to the account owner, the instruction that caused the debit — this is where the reference you supplied with your payment comes back to you, MT940's modest ancestor of the EndToEndId round trip in pain.001 and camt.053. Sixteen characters, no structure, and NONREF when the bank has nothing — at which point subfield 9's supplementary details are the consolation prize.

The transaction type identification code (subfield 6) is the entry's classification, and it comes in three families:

• S + three digits: the SWIFT message type behind the entry, 100–999.
• N + three characters: a code from a standard list of several dozen three-letter codes (TRF, CHG, INT, DDT, STO, MSC and their kin) for entries arising from payment and transfer instructions.
• F + three characters: entries originated by the account servicing institution itself.

Nordea's description then adds its own codes on top for cash-pool bookings — CMZ (zero balancing), CMS (sweeping), CMT (topping) — which is worth pausing on: even the classification code, the most machine-readable thing in the file, grows bank-specific extensions. When an electronic bank statement run in SAP picks a posting rule for an MT940 line, this code is the external transaction code it keys on. It's doing the job camt.053's Bank Transaction Code does — with four characters instead of a curated three-level taxonomy, which is a fair summary of the two formats' relationship.

Here's a real line from Nordea's sweeping example, with the packing on display:

:61:0509070908D494031,34NCMZTOP/SWEEPSVERIGE GBPAX DANMARK A/S

Read it with the table: value date 050907, entry date 0908, D for debit, amount 494031,34, transaction type NCMZ (a zero-balancing sweep), customer reference TOP/SWEEPSVERIGE, and the counterparty name riding in supplementary details. No delimiters between any of them — the only way to cut that line correctly is to apply the format definition left to right.

:86: — information to account owner, and why it's bank-specific

Format 6*65x — up to six lines of 65 characters — optional, attached to the :61: line it follows. And here is the sentence this post exists to say plainly: the standard defines the size of :86:, not its structure. What goes into those 390 characters, and in what layout, is decided bank by bank. Everything below is Nordea's implementation, shown as a worked example — not "the MT940 :86: format", because there is no such thing.

Nordea structures the field as /Code/Information pairs, with these codes:

For its sweeping services the first :86: line switches to a fixed layout instead — transaction code (CMZ, CMS or CMT), account number, customer reference, beneficiary or payer name:

:86:CMZ/20496116759120/TOP/SWEEPSVERIGE/GBPAX DANMARK A/S

Two implementations inside one bank's :86:, and neither is portable. Another bank will use different codes, a different sub-structure, or plain prose. This is the concrete mechanism behind the format comparison's verdict that MT940's weakness is structure: the remittance information, counterparty names and FX details that camt.053 carries in typed XML elements live here in a free-text field whose layout is a per-bank convention. Every MT940 auto-matching rate I've seen quoted is really a statement about how well someone reverse-engineered each bank's :86: — so treat that parser as per-bank deliverable work, written from the bank's implementation guide and tested against production statements, never copied from the last project.

:62a:, :64:, :65: — the closing balances

:62a: Closing balance — mandatory, same 1!a6!n3!a15d structure as :60a:, same F/M split: :62F: is the final closing balance, :62M: an intermediate one. The chaining rule from the opening balance, stated from the other end: the content of this field will be repeated in field :60a: of the subsequent customer statement message for this account.

:64: Closing available balance — optional. The definition has more teeth than "available": funds which are available to the account owner if the balance is credit, or the balance which is subject to interest charges if it is debit. Booked versus available is the difference between what the ledger says and what you can actually spend today — same distinction camt.053 makes with its CLBD/CLAV balance codes.

:65: Forward available balance — optional. Funds available to the account owner (credit or debit balance) for a specified forward value date — a small forward-looking window in an end-of-day format.

Both availability tags are optional, and whether a given bank sends them is an implementation fact, not a standard one. If your cash position needs available figures, confirm per bank before you design for them.

Multi-message statements: how F and M chain

A busy account outgrows one message, and the format's answer is mechanical. The statement number stays fixed while the :28C: sequence number increments, and the balance variants mark the pieces:

• First message: opens :60F:, closes :62M:
• Intermediate messages: :60M: … :62M:
• Final message: :60M: … :62F: — the last message of the statement must contain :62F:

The statement and sequence numbers are what let the receiver put the messages back into sequence and form the complete statement — remembering the earlier warning that downloaded files won't necessarily arrive in sequence order. An importer that treats every message as a self-contained statement will double-count balances on the first busy day; key the reassembly on :28C: and only trust :62F: as the day's closing figure.

What usually goes wrong

• Treating :86: as standard. It's bank-specific by construction. One parser per bank, written from that bank's guide, tested on that bank's production files.
• Only handling D and C. RC and RD exist, and each books on the opposite side of its name. Reversals in the debit/credit mark are the classic year-two production incident.
• Skipping the balance chain check. Previous :62a: must equal current :60a:, and :60a: plus the signed :61: lines must equal :62a:. Two comparisons, and they catch missing statements and truncated files before the position is wrong.
• A gap check that forgets 1 January. The statement number resets to 1 at the start of the year (in Nordea's implementation) — build the wrap into the check.
• Parsing amounts with a decimal point. The 15d format's decimal comma is mandatory. 494031,34 is the format; a locale-naive parseFloat reads it as something else entirely.
• Trusting arrival order. Sequence numbers in downloaded files aren't necessarily sorted. Reassemble multi-message statements on :28C:.

The tags themselves have been stable for decades — that stability is exactly why MT940 still flows in the corporate-to-bank space while the interbank world has moved on. The craft, as with camt.053, is never in the standard's skeleton; it's in the bank-specific corners — :86: layouts, code extensions, which optional tags actually arrive — and all of that is written down per bank. Get each bank's MT940 description, diff it against what your importer consumes, and the format holds few surprises after that.

See also bank statement formats: MT940 vs camt.053 vs BAI2, the camt.053 field walkthrough, electronic bank statement processing in SAP, and MT101 vs MT103 vs MT202.