What is in the :86: field of an MT940?

Whatever your bank puts there. :86: is free text with no standard structure, and it is where the counterparty, the remittance information and the end-to-end reference live. Three common conventions are SWIFT sub-tags (/ORDP/, /REMI/, /EREF/), German ?-codes, and a plain sentence. We hold the convention per bank as a versioned rule set, so a file read last year is re-read when the rule set improves.

What do the subfields of :61: mean?

In order: the value date as YYMMDD, the entry date as MMDD, a debit or credit mark, the amount with a comma decimal, a four-character transaction type identification code, the reference for the account owner, and after a double slash the bank’s own reference. The account owner’s reference is often the literal NONREF on a credit, because the owner did not originate the movement.

Why does an MT940 say NONREF?

Because the account owner has no reference for that movement. Somebody else sent the money, so the reference that identifies it is the payer’s and it sits down in :86:. It is not an error and it is not a missing field — it is the format saying that this particular reference does not exist on this side of the payment.

What is the difference between :62F: and :64:?

:62F: is the final closing balance of the statement period: opening plus credits minus debits, and it is the figure the next statement opens on. :64: is the closing available balance, which is the same money minus whatever the bank has not released yet. A statement can state both, and they disagree exactly as often as value dates fall after booking dates.

Is MT940 being replaced by CAMT.053?

It is being offered alongside it. Banks that publish CAMT.053 rarely stop publishing MT940, because their customers’ systems read it, and plenty of accounts are still reported only this way. We read both and reconcile against either, so the choice stays a conversation with your bank rather than a project on your side.

SWIFT · end of day

What is inside an MT940, field by field

An MT940 is the statement your bank sends once the day is closed. The amounts and the dates sit in fixed positions anybody can read. Everything that says who paid you and what for is pushed into one field that has no standard behind it, and that field is where the work is.

The account every page here reads

EUR

Published by: SWIFT
What it carries: One account, one day: opening balance, every movement, closing balance.
Account: ES21 0049 0001 5323 4567 8901

Closing balance · Aug 14, 2026EUR 2,990,901.67

The definition

What an MT940 actually is

A telex-era message most European banks still send every morning, and the reason a treasury team’s day starts by opening a text file.

An MT940 is the SWIFT message a bank sends to report one account’s closed statement period. Tag :20: identifies the message, :25: names the account, :28C: gives its place in a numbered series, :60F: states the opening balance, a :61: and :86: pair follows for every movement, and :62F: states the closing balance. Amounts use a comma for the decimal and no thousands separator; direction is a single C or D rather than a sign.

Who sends it: Your bank, over whatever channel you already have with it — a host-to-host drop, EBICS, an SFTP folder. The message is the same whichever way it arrives, which is why the channel and the format are two separate decisions.
When it arrives: Once the statement period closes: for most banks that is one message per account per banking day, and more where a busy account is split across several statements. :28C: is what tells you which one you are holding and whether one is missing.
What it looks like: Plain text, one tag to a line, tags in a fixed order. Nothing is nested and nothing is named — the tag and the position are the whole schema, which is why a line that wraps stops being readable.

What its parts are called

MT940 :86:
MT940 :61: subfields
MT940 vs CAMT.053
MT940 NONREF
MT940 :62F:

The file

One account’s day, as the bank wrote it

The same account and the same three movements every page in this library uses, so the closing balance you carry from here to the CAMT.053 page has to agree with itself.

MT940One credit, two debits, closing on the balance in the card above

:20:STMT26081400161
:25:ES2100490001532345678901
:28C:00161/00001
:60F:C260813EUR2864112,47
:61:2608150814C182046,55NTRFNONREF//BK26081401
:86:/ORDP/NORTE TESORERIA SL/REMI/FRA 4471/EREF/4471QX
:61:2608140814D42318,90NDDTMD-88214//BK26081402
:86:/BENM/NORTE SUMINISTROS SL/REMI/SUMINISTRO JULIO
:61:2608140814D12938,45NCHGNONREF//BK26081403
:86:/REMI/COMISION MANTENIMIENTO 3T
:62F:C260814EUR2990901,67

Where each fact lives in this file

Which account it is: :25:
The balance it opened on: :60F:
One movement, and which way it went: :61: · 3 · 5
The day it was booked, and the day the money is yours: :61: · 1 · 2
What the bank wrote about it: :86:
The reference that ties it to a payment: :61: · 8 · :86:/EREF/
The balance it closed on: :62F:

What comes out

The amount is the easy half. :86: is the work.

A :61: line is positional, so every reader agrees about it. The field underneath is free text, and no two banks fill it the same way.

Out of :61: we take the amount, the value date, the booking date, the transaction type and the bank’s own reference — five facts in fixed places, and nothing about them is open to interpretation. The value date is the one most tools quietly collapse into the booking date; it is a separate subfield here and it stays separate all the way through, because a credit that is yours tomorrow is not a credit you can spend today.

Then :86: arrives, and it is free text. One bank writes SWIFT sub-tags, one writes German ?-codes, one writes a sentence. The counterparty, the invoice reference and the end-to-end reference are all in there, and where they are is that bank’s own convention. We hold each bank’s convention as a versioned rule set rather than as code, so improving one re-reads the history it already parsed instead of leaving it wrong.

Format profiles · MT940

Which account it is:25:: ES21 0049 0001 5323 4567 8901
The balance it opened on:60F:: EUR 2,864,112.47
One movement, and which way it went:61: · 3 · 5: EUR +182,046.55
The day it was booked, and the day the money is yours:61: · 1 · 2: Aug 15, 2026
What the bank wrote about it:86:: NORTE TESORERIA SL · FRA 4471
The reference that ties it to a payment:61: · 8 · :86:/EREF/: 4471QX
The balance it closed on:62F:: EUR 2,990,901.67

Every value beside the tag it was read from, so the reading can be checked against the record above.

That is the whole trade with this format. What it states, it states exactly; what it leaves undefined, somebody has to know. Send us a file and the reading is ours.

The same day, spelled differently

CAMT.053 gives every one of those references an element of its own. MT942 is this message before the day is closed. Norma 43 is the Spanish account’s version of it, eighty characters to a record.

Formats to read beside it

What reads it here

The same day written in four formats, side by side, is on Format library

Asked about MT940

The questions a practitioner actually types

01What is in the :86: field of an MT940?: Whatever your bank puts there. :86: is free text with no standard structure, and it is where the counterparty, the remittance information and the end-to-end reference live. Three common conventions are SWIFT sub-tags (/ORDP/, /REMI/, /EREF/), German ?-codes, and a plain sentence. We hold the convention per bank as a versioned rule set, so a file read last year is re-read when the rule set improves.
02What do the subfields of :61: mean?: In order: the value date as YYMMDD, the entry date as MMDD, a debit or credit mark, the amount with a comma decimal, a four-character transaction type identification code, the reference for the account owner, and after a double slash the bank’s own reference. The account owner’s reference is often the literal NONREF on a credit, because the owner did not originate the movement.
03Why does an MT940 say NONREF?: Because the account owner has no reference for that movement. Somebody else sent the money, so the reference that identifies it is the payer’s and it sits down in :86:. It is not an error and it is not a missing field — it is the format saying that this particular reference does not exist on this side of the payment.
04What is the difference between :62F: and :64:?: :62F: is the final closing balance of the statement period: opening plus credits minus debits, and it is the figure the next statement opens on. :64: is the closing available balance, which is the same money minus whatever the bank has not released yet. A statement can state both, and they disagree exactly as often as value dates fall after booking dates.
05Is MT940 being replaced by CAMT.053?: It is being offered alongside it. Banks that publish CAMT.053 rarely stop publishing MT940, because their customers’ systems read it, and plenty of accounts are still reported only this way. We read both and reconcile against either, so the choice stays a conversation with your bank rather than a project on your side.

Send one MT940 and see it read.

One account, one month. You get back every line with its value date, its counterparty and its reference, and the balances footed.

Request a demo Back to the format library

No connection to set up for this — one file is enough to start.