MT940 — Customer Statement Message
Carries account statement information for one account over one period: an opening balance, individual booked entries, and a closing balance. Banks send it for the nostro accounts they service; corporates receive it — often relayed or over non-Swift channels — for cash management and reconciliation.
DIRECTION: Sent by the account-servicing institution to the account owner, or to another institution authorised to receive the statement on the owner's behalf.
WHO IS INVOLVED
- Account-servicing institutionProduces the statement from its books, typically at end of day.
- Account ownerMatches statement entries against its own ledger — the core of nostro reconciliation — and investigates whatever does not match.
- Relay institutionWhere used, forwards statements to a corporate or a group treasury that concentrates account information.
KEY FIELDS
Curated subset of the fields practitioners meet first — the official SWIFT Standards MT documentation is the complete specification.
| FIELD | NAME | PRESENCE | WHAT IT MEANS |
|---|---|---|---|
:20: | Transaction Reference Number | MANDATORYSWIFT Standards MT | The sender's unique reference for this statement message.Identifies the message, not the account or period — those live in fields 25a and 28C. |
:21: | Related Reference | OPTIONALSWIFT Standards MT | Links the statement to a request, when it was produced in answer to one.Used when the statement responds to an MT920 request; routine scheduled statements omit it. |
:25a: | Account Identification | MANDATORYSWIFT Standards MT | Which account the statement describes.The identifier is the servicer's account number, which may differ from how the owner labels the same account internally — mapping tables matter. |
:28C: | Statement Number / Sequence Number | MANDATORYSWIFT Standards MT | Numbers the statement, and the page when one statement spans several messages.Continuity checking on statement and sequence numbers is how reconciliation systems detect missing statements or pages.⚠ Processing pages out of order, or missing one, corrupts the running balance chain. |
:60a: | Opening Balance | MANDATORYSWIFT Standards MT | The balance the statement starts from — debit or credit, date, currency, and amount.Option F opens a statement; option M continues from a previous page. The opening balance should equal the previous statement's closing balance.⚠ Booking a statement without checking it chains onto the prior closing balance lets gaps slip through unnoticed. |
:61: | Statement Line | OPTIONALSWIFT Standards MT | One booked entry: value date, debit or credit, amount, transaction type, and references.Repeats for each entry. The subfields — especially the customer and bank references — are where auto-matching succeeds or fails, and banks differ in what they put there.⚠ Parsers that assume one bank's 61 conventions break on the next bank's statements; references truncated upstream arrive here unmatchable. |
:86: | Information to Account Owner | CONDITIONALSWIFT Standards MT | Free-form detail about the entry above it — counterparty, remittance text, charge details.The structure inside 86 is not standardised across banks: many use national or proprietary code conventions. Treat each account servicer's format as its own parsing profile.⚠ Assuming a single 86 layout across correspondents is one of the most common causes of broken automated reconciliation. |
:62a: | Closing Balance (Booked Funds) | MANDATORYSWIFT Standards MT | The balance after all entries in the statement.Option F closes the statement, option M carries an intermediate balance to the next page. Opening balance plus entries must equal this figure.⚠ A closing balance that does not compute from opening balance plus lines means entries are missing or duplicated somewhere. |
:64: | Closing Available Balance | OPTIONALSWIFT Standards MT | How much of the closing balance is actually available, once uncleared items are excluded.Liquidity teams care about the difference between booked and available; not every servicer supplies it. |
COMMON ERRORS
- Parsing field 86 with one fixed structure across all correspondents.Consequence: Auto-matching silently degrades for the banks whose conventions differ; investigation queues grow without an obvious cause.Avoid it: Maintain a parsing profile per account servicer and monitor match rates per correspondent, not just in aggregate.
- Ignoring statement and page continuity in 28C.Consequence: A missing statement or page means missing entries — balances stop reconciling and the gap is discovered late.Avoid it: Check sequence continuity and opening-versus-prior-closing balance on every statement before booking entries.
- Relying on references in 61 that were truncated or replaced earlier in the payment chain.Consequence: Entries that belong to known payments arrive unmatchable and land in manual queues.Avoid it: Match on multiple criteria — amount, value date, counterparty — not on a single reference, and push correspondents for reference transparency.
- Treating booked balance as available liquidity.Consequence: Positions look funded when part of the balance is not yet usable, leading to overdrafts or failed settlements.Avoid it: Use field 64 where supplied, and agree with the servicer how availability is reported where it is not.
USAGE CONTEXTS
- Nostro reconciliationThe end-of-day MT940 for each nostro account is matched line by line against the bank's own mirror ledger. Unmatched entries — an expected credit that never arrived, a charge nobody booked — become investigation cases.
- Corporate statement deliveryThe format long ago escaped the interbank network: banks deliver MT940-format statements over host-to-host connections, EBICS, and e-banking portals, and treasury systems everywhere import it. This breadth of use keeps the format alive well beyond Swift itself.
- ISO 20022 equivalentsThe camt.053 statement is the strategic successor, with richer structure and no 86-style free-text ambiguity. Category 9 messages remained usable on the FIN network after the November 2025 retirement of cross-border MT payment instructions, and banks are migrating statement delivery on their own timelines — expect years of coexistence in practice.
Sources for this reference2
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · Category 9 — MT 940
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: Field list curated for learning; national and bilateral usage rules omitted.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.