What Is an MT940 File?

The short answer

An MT940 file is a bank statement in SWIFT message type 940, the Customer Statement Message. It is plain text built from tagged fields: :20: for the reference, :61: for each transaction, :62F: for the closing balance. It is what most European banks hand you where an American bank would hand you an OFX file.

It is the format's own name rather than an extension, which is part of why it is confusing to search for. The same file arrives called .mt940, .940, .sta or plain .txt depending on the bank, and none of those is more correct than the others.

What an MT940 looks like inside

One statement, cut down to a single transaction. Every line opens with a tag, and a field's value continues onto any line that does not:

:20:STMT260105
:25:NL91ABNA0417164300
:28C:00123/00001
:60F:C260104EUR1000,00
:61:2601050105DR24,50NTRFNONREF//8327000000123
:86:?20COFFEE SHOP?21MORNING COFFEE
:62F:C260104EUR975,50

Files are often wrapped in a SWIFT envelope: a {1: header block, a {4: body and a closing -}. That belongs to the message transport rather than the statement. Whether it is present depends entirely on how the file was exported.

The comma is the decimal point

This is the single most damaging thing to get wrong about the format, because it does not fail. It produces a number. SWIFT amounts use a comma for the decimal separator and carry no thousands separator at all.

So 1234,5 is one thousand two hundred and thirty-four and a half. Read by anything that treats a comma as a thousands separator, it becomes 12,345: ten times too large, in a file where nothing else looks wrong. A single misread amount of that kind rarely breaks a reconciliation obviously. It just makes it fail by an amount nobody can account for.

The same rule applies to the balances. :60F:C260104EUR1000,00 is a credit balance of one thousand euro on 4 January 2026: the letter, then the date, then the currency, then the amount, with no separators between any of them.

Reading a :61: line

Every transaction is one :61: line, and it packs nine subfields together with nothing separating them. Working through 2601050105DR24,50NTRFNONREF:

The entry date is the awkward one. It is optional and it is four digits, so whether the characters after the value date are a date or the start of the debit/credit mark comes down to whether they are digits at all.

Reversals invert the letter they carry

The debit/credit mark has four values, not two: C, D, RC and RD. The first two are what they look like. The second two are reversals, and they take the opposite sign to the letter they are built from.

RC is a reversal of a credit. It undoes money coming in, so it takes money out. RD reverses a debit and therefore puts money back. Reading RC as a credit because of the C is an easy mistake and a quiet one, since the entry is a plausible transaction either way and only the total gives it away.

One file, several statements

An MT940 download frequently holds more than one statement: consecutive months, or several accounts, concatenated one after another. Each has its own :20: reference, its own opening balance and its own closing balance.

That matters when reconciling. The opening figure for the whole file is the first :60F: in it, and the closing figure is the last :62F:. Anything that reads only the first statement will report a period much shorter than the file actually covers.

MT940, MT942 and CAMT.053

Three related things, and knowing which you have saves a lot of confusion.

CAMT.053 carries the same information in XML and is where European banking is heading, but MT940 is still in wide daily use and shows no sign of disappearing from download menus.

What an MT940 cannot tell you

It is unusually good on balances. Both figures are stated outright, so unlike an OFX ledger balance neither has to be inferred. A statement can be checked against itself without typing anything in.

What it is poor on is description. The :86: field is free text, and what goes in it varies by bank and by country. Some write a readable payee. Some pack it with ? field codes. Some fill it with routing detail nobody needs. There is no payee field as such, which is why converted MT940 descriptions read less cleanly than converted OFX ones.

And there is no unique transaction identifier of the kind an OFX FITID provides. Reading the same statement twice gives a program no way to recognise entries it has seen before, so duplicate detection has to be done on the content rather than on an id.

Frequently asked questions

What file extension does an MT940 use? There is no single one. .mt940, .940, .sta and plain .txt are all in circulation, and none is more correct than the others. MT940 is the name of a SWIFT message type rather than a file format with a registered extension. What identifies one is the contents: tagged lines beginning :20: and :61:.

Why is my MT940 amount ten times too big? Because something read the comma as a thousands separator. In SWIFT the comma is always the decimal point and there is no thousands separator at all, so 1234,5 is 1234.50 and not 12345. It is the most common way MT940 figures go wrong, and it produces a valid-looking number rather than an error.

Is MT940 the same as CAMT.053? They carry much the same information, but not in the same way. MT940 is the older tagged text format; CAMT.053 is the ISO 20022 replacement and is XML. Banks moving to CAMT.053 generally offer both for a while, and MT940 remains widely available.

Can I open an MT940 in Excel? You can open it as text, but it is not a table. Each transaction spans a :61: line and usually a :86: line beneath it, and the subfields inside :61: have no separators between them at all. A spreadsheet has no way to split that into columns.

What does NONREF mean in my statement? That the transaction has no reference from the account owner. It is a placeholder the format defines for exactly that case, so it is normal rather than a sign of anything missing. The description usually comes from the :86: line beneath instead.