MT940 Customer Statement Message

When MT940 is used

An account servicing institution sends an MT940 to report all entries booked to an account over a statement period, normally one business day. The receiver can be the account owner itself, a bank the account owner has authorised to receive the statement (a concentrating institution that collects statements from several banks for one client), or a non-bank account owner such as a corporate, fund or broker. Because a bank only reports an account to a third party with the owner’s authority, the use of the MT940 is governed by bilateral agreement.

The format travels well beyond the FIN network. Banks deliver the same MT940 layout to companies through FileAct, EBICS, host-to-host links and online banking downloads, which is why treasury systems, ERP packages and broker back offices all read it. In that role it is often simply called the electronic bank statement.

Reconciliation is the main use. Each field 61 is one booked entry with its value date, amount, transaction type and references, and the field 86 that follows can carry the counterparty, remittance details and charges. The opening balance must equal the closing balance of the previous statement for the same account, and opening balance plus credits minus debits must equal the closing balance. When those checks fail, see why an MT940 does not balance.

A statement that is too long for one message is split into several messages with the same statement number and a running sequence number in field 28C. The first carries 60F, the following ones 60M (intermediate opening balance), every message except the last ends with 62M, and only the last ends with 62F.

The MT940 is the customer statement. Banks report their own nostro accounts to each other with the leaner MT950, intraday movements go in the MT942, and single debits or credits can be advised as they happen with MT900 and MT910. An MT940 can also be requested with an MT920 Request Message; field 21 then carries the reference of that request.

MT940 format: sequences and fields

Rules worth knowing

• Network rule C1 (error C24): a field 86 inside the loop must be preceded by a field 61, and it must sit in the same message as that field 61. A page break between a 61 and its 86 is rejected.
• Network rule C2 (error C27): the first two letters of the currency code must be the same in fields 60a, 62a, 64 and 65. The third letter can differ because of the funds code (see subfield 4 below).
• Balances: opening balance plus all credit entries (C and RD) minus all debit entries (D and RC) equals the closing booked balance in 62a. The checker of this site does not do this sum for you; your reconciliation system should.
• Field 61, subfield 1, Value Date (6!n, YYMMDD): the date the debit or credit takes effect for interest and availability.
• Field 61, subfield 2, Entry Date ([4!n], MMDD): the booking date, normally given only when it differs from the value date. It has no year: the network checks it against the current system year, and a parser must take the year from the value date or the statement date, taking care around 1 January.
• Field 61, subfield 3, Debit/Credit Mark (2a): C credit, D debit, RC reversal of credit (shown as a debit entry), RD reversal of debit (shown as a credit entry). RC and RD move the balance in the opposite direction to their first letter, which is the most common cause of a statement that does not add up in home-grown parsers.
• Field 61, subfield 4, Funds Code ([1!a]): the third character of the currency code, used only if needed. Many banks do not use it (Handelsbanken’s guide marks it as not in use), but it is the reason a parser cannot assume that the letter after C, D, RC or RD is always the start of the amount.
• Field 61, subfield 5, Amount (15d): no sign, a comma as decimal mark, at least one digit before the comma. The direction comes only from subfield 3.
• Field 61, subfield 6, Transaction Type Identification Code (1!a3!c): S plus a three-digit message type for entries caused by, or advised with, a Swift message (S103, S202, S910); N plus a code for non-Swift transfers or where a text code is preferred (NTRF, NCHK, NMSC); F plus a code for entries first advised by this statement, such as bank charges (FCHG). The first charge advice for an item must use FCHG.
• Common N and F codes from the standard list: TRF transfer, CHK cheques, MSC miscellaneous, CHG charges and other expenses, COM commission, INT interest related amount, DIV dividends, FEX foreign exchange, DDT direct debit item, STO standing order, RTI returned item, SEC securities, CMS/CMT/CMZ cash management sweeping, topping and zero balancing, VDA value date adjustment, and a set of securities items such as CPN coupon payments, RED redemption, SAL sale, PCH purchase and TAX withholding tax payment.
• Field 61, subfield 7, Reference for the Account Owner (16x): the reference the account owner knows. For a debit it is field 20 of the instruction that caused it; for a credit it is the reference for the beneficiary of the incoming transfer; for charges it is the reference of the item charged; for a cheque the cheque number. If there is none, the bank writes NONREF and should give the best alternative in subfield 9.
• Field 61, subfield 8, Reference of the Account Servicing Institution ([//16x]): the bank’s own booking reference, introduced by two slashes. It may be left out when the bank initiated the entry and its reference is the same as subfield 7.
• Field 61, subfield 9, Supplementary Details ([34x], on a new line): extra text for reconciliation, required in practice when subfield 7 is NONREF. It may carry an exchange rate as /EXCH/ followed by the rate and a closing slash.
• Field 86 in the Swift standard: /ORDP/ introduces the ordering party (from 50a of a customer transfer or 52a of a bank transfer), /BENM/ the beneficiary on a debit, /REMI/ remittance information copied from field 70, /CHGS/ charges (may repeat, the last one being the account servicer’s), /OCMT/ the original amount, /EXCH/ an exchange rate. Field 72 content meant for the account owner is copied as it is.
• Field 86 conventions that are bank-specific, not Swift rules: ING’s structured MT940 uses code words such as /EREF/ (end-to-end reference), /CNTP/ (counterparty account, BIC, name, city), /REMI/USTD// or /REMI/STRD/ (unstructured or structured remittance), /PREF/, /MARF/, /CSID/ and /RTRN/ (return reason). German banks often use the layout with a three-digit business transaction code followed by subfields ?00 (booking text), ?20 to ?29 (purpose, with keys such as EREF+, KREF+ and SVWZ+), ?30 (counterparty BIC), ?31 (counterparty account), ?32 and ?33 (counterparty name) and ?34 (return reason). Always parse field 86 with the guide of the bank that sent it.
• The MT940 is not a payment instruction and nothing is settled by it. An entry on the statement is the bank’s record of what it booked; disputes about an entry go through investigations, not through the statement.

MT940 example

ZagTrader Test Bank in Dubai (ZAGTAEADXXX) services a USD account for a broker (BRKRAEADXXX). On the broker’s instruction it sends the daily MT940 for Tuesday 20 October 2026 to the broker’s main bank, BANKAEADXXX, which collects the broker’s statements from all its banks (a concentrating institution). The day holds six entries: an outgoing bank transfer, a client deposit received by MT103, a dividend, an internal transfer with next-day value, the reversal of a duplicate debit, and a charge. Opening balance USD 1,250,000.00, credits USD 314,500.00 (250,000.00 + 37,500.00 + 15,000.00 + 12,000.00), debits USD 480,125.00 (480,000.00 + 125.00), closing booked balance USD 1,084,375.00.

{1:F01ZAGTAEADAXXX0000000000}{2:I940BANKAEADXXXXN}{4:
:20:STMT261020USD01
:25P:AE070331234567890123456
BRKRAEADXXX
:28C:207/1
:60F:C261019USD1250000,00
:61:261020D480000,00S202BRK2610200017//ZAG26293000101
:86:/BENM/BRKRGB2LXXX
/REMI/MARGIN CALL SETTLEMENT 20OCT26
:61:261020C250000,00S103PAY2610200388//ZAG26293000102
:86:/ORDP/AL NOOR INVESTMENTS LLC
/REMI/CLIENT DEPOSIT ACCOUNT 88213
:61:261020C37500,00NDIVNONREF//ZAG26293000103
CASH DIVIDEND Q3 2026
:86:CASH DIVIDEND ISIN AEZAGT000016
EX DATE 15OCT26 GROSS USD 37500,00
:61:2610211020C15000,00NTRFTRF2610200045//ZAG26293000104
:86:/ORDP/GULF TRADING LLC
/REMI/INTERNAL TRANSFER VALUE 21OCT26
:61:261020RD12000,00NTRFBRK2610190031//ZAG26293000105
:86:REVERSAL OF DUPLICATE DEBIT BOOKED 19OCT26
:61:261020D125,00FCHGBRK2610200017//ZAG26293000106
:86:CHARGES OUTGOING TRANSFER BRK2610200017
:62F:C261020USD1084375,00
:64:C261020USD1069375,00
:65:C261021USD1084375,00
:86:CREDIT INTEREST RATE 3,25 PCT FROM 01NOV26
-}

Line by line

BICs, names, references and the IBAN are made up; the IBAN and ISIN carry valid check digits.

The same day reported in ISO 20022 is shown on the camt.053 page, entry for entry.

Common errors and rejects

1. Opening balance does not match the previous closing balance

   Field 60a must repeat the mark, currency and amount of field 62a of the previous message for the account. A mismatch means a statement or a page is missing (check the statement and page numbers in 28C), a statement was loaded twice, or the bank re-sent a corrected statement. Do not force the balance; find the missing message.

   How to fix it

2. RC and RD entries booked in the wrong direction

   RC (reversal of credit) is a debit and RD (reversal of debit) is a credit. Parsers that look only at the first letter post them the wrong way round, and the statement then misses by twice the amount of each reversal.

   How to fix it

3. Field 61 split in the wrong place

   The entry date and the funds code are optional and the mark has one or two letters, so fixed positions do not work. Parse in order: six digits, optional four digits, C/D/RC/RD, optional one letter, the amount up to the first letter after it, then four characters of transaction type, then the reference up to // or the end of the line.

   How to fix it

4. Split statement processed out of order or incomplete

   Long statements arrive as several messages, for example 207/1 with 60F and 62M, then 207/2 with 60M and 62F. Loading a page alone, or treating 62M as the day’s closing balance, gives wrong figures. Wait for the page with 62F before closing the day.

   How to fix it

5. Reconciliation fails because field 86 is cut short

   Field 86 holds at most 6 lines of 65 characters. Long remittance details, structured addresses and end-to-end references from ISO 20022 payments may be truncated, so matching on 86 text alone breaks. Match on subfield 7 and subfield 8 of field 61 first; the full data is in camt.053.

   How to fix it

6. Network rejects C24 or C27

   C24: a field 86 in the loop without a field 61 before it, or separated from its field 61 by a page break. C27: the balance fields use currencies whose first two letters differ. Both are sender-side errors that the bank must fix and resend.

MT940 in ISO 20022

The ISO 20022 equivalent is camt.053 (Bank to Customer Statement). In the cross-border payments and reporting market practice (CBPR+) the version is camt.053.001.08, and the CBPR+ guideline covers both the bank-to-bank leg, where the MT950 is used today, and the bank-to-customer leg of the MT940.

Statements were not part of the 22 November 2025 deadline. Swift ended MT/MX coexistence for cross-border payment instructions on that date, but reporting messages, including the MT940 and the other MT9xx statements, continue to be supported beyond it. Whether you receive MT940 or camt.053 is agreed with each account servicing bank.

The reason to move is data. A camt.053 entry has room for the end-to-end reference, the UETR, structured party names and addresses, and long remittance information from the pacs.008 that caused it, all of which field 86 cannot hold in full. See camt.053 vs MT940 for a field-by-field comparison.

Related messages

• MT950Statement Message
• MT942Interim Transaction Report
• MT900Confirmation of Debit
• MT910Confirmation of Credit
• MT103Single Customer Credit Transfer
• MT202General Financial Institution Transfer
• camt.053Bank to Customer Statement
• camt.052Bank to Customer Account Report
• camt.054Bank to Customer Debit Credit Notification
• pacs.008FI to FI Customer Credit Transfer

MT940 questions

What is an MT940 bank statement?

It is the Swift MT format for an end-of-day account statement: the opening booked balance, one field 61 per booked entry with field 86 details, and the closing booked balance, optionally with available and forward available balances. Banks send it over Swift or as a file to their clients’ treasury and accounting systems.

What is the difference between MT940 and MT950?

The MT940 is the customer statement: it can go to the account owner or to a bank the owner has authorised, and it carries field 86 with details for the account owner. The MT950 is sent by the account servicing institution to the account owner only, typically between banks for nostro reconciliation, and has no field 21, no option P in field 25, no field 65 and no field 86.

What is the difference between MT940 and MT942?

The MT940 is the statement for a closed period with opening and closing balances. The MT942 is an interim report during the day: it lists entries since the last statement or report, above a floor limit set in field 34F, with a timestamp in 13D and totals in 90D and 90C, but no opening or closing balance.

How do I read field 61 in an MT940?

Take it from left to right: value date YYMMDD, optional entry date MMDD, mark C, D, RC or RD, optional funds code, amount with a decimal comma, transaction type (for example S103, NTRF, FCHG), your reference or NONREF, then // and the bank’s reference, and supplementary details on the next line. See field 61 explained.

What do 60F, 60M, 62F and 62M mean?

F is final and M is intermediate. A statement that fits in one message uses 60F and 62F. A statement split over several messages starts with 60F, carries 62M at the end of each page except the last, starts each later page with 60M, and ends with 62F.

Is the MT940 being replaced by camt.053?

camt.053 is the ISO 20022 equivalent and many banks already offer it. Statements were not part of the November 2025 cut-over for payment instructions and remain supported on Swift beyond that date, so the switch is agreed bank by bank. See camt.053 vs MT940.