The Complete Guide to Mt940 Validating: Everything You Need to Know

MT940 is the SWIFT standard for electronic bank statement delivery. Banks around the world use it to transmit account history to corporate treasury systems, accounting platforms, and ERP integrations. Despite its age — the format dates to the 1980s — MT940 remains one of the most common machine-readable bank statement formats in international finance. If you work with bank data, payment reconciliation, or financial system integrations, you will encounter MT940 files.

The problem is that MT940 is a fixed-format text standard with strict structural requirements and very little tolerance for deviation. A missing mandatory tag, a malformed balance line, or a transaction amount with the wrong sign indicator can silently break a downstream parser or cause a reconciliation mismatch that takes hours to trace. MT940 validation catches these problems at the file level before any processing begins.

This guide covers the structure of MT940 files, what each validation check means, how to interpret results, and best practices for designers and developers working with bank statement data.

Connect on LinkedIn →

What Is MT940?

MT940 stands for Message Type 940, part of the SWIFT MT (Message Type) messaging standard. It is the Customer Statement Message — a structured text format that conveys account statement information: the account identifier, statement period, opening balance, individual transactions, and closing balance.

MT940 files are delivered in one of two ways: directly from the bank via SWIFT connectivity or SFTP, or exported from an online banking portal. In either case, the file is a plain-text document with a specific line-by-line structure. Each piece of information is identified by a tag — a colon-delimited code such as :60F: (opening balance) or :61: (statement line).

MT940 is distinct from newer formats like CAMT.053 (ISO 20022 XML), which has been replacing it in some European markets. However, MT940 remains dominant in many regions and is supported by virtually every treasury management system, ERP, and accounting platform that handles bank feeds.

MT940 File Structure

An MT940 file consists of one or more statement blocks. Each block corresponds to a single account statement and follows a fixed sequence of tagged fields. A minimal valid MT940 statement looks like this:

:20:STMTREF01
:25:GB29NWBK60161331926819
:28C:00001/001
:60F:C260101GBP1000,00
:61:2601020102CR500,00NTRF//REF001
:86:Payment received
:62F:C260102GBP1500,00

Each line begins with a tag (the colon-delimited code) followed by the field value. Some fields span multiple lines — these continuation lines do not begin with a tag. The structure is sequential: tags must appear in a defined order, and mandatory tags cannot be omitted.

A single MT940 file may contain statements for multiple accounts or multiple date ranges. Each statement block is separated by a transaction reference tag (:20:) that begins a new block. A validator must handle multi-statement files and apply all checks to each block independently.

Mandatory Tags

The SWIFT MT940 standard defines a set of mandatory tags that must appear in every statement block. Missing any of these is a structural error that will cause most parsers to fail:

• :20: Transaction Reference Number. A unique reference assigned by the sender. Maximum 16 alphanumeric characters. This tag opens every statement block.
• :25: Account Identification. The account identifier, typically an IBAN or account number, optionally followed by a currency code. Maximum 35 characters.
• :28C: Statement Number / Sequence Number. A five-digit statement number and a five-digit sequence number separated by a forward slash (e.g., 00001/001).
• :60F: Opening Balance (Final) or :60M: Opening Balance (Intermediate). The balance at the start of the statement period. Contains a debit/credit indicator, date, currency code, and amount.
• :62F: Closing Balance (Final) or :62M: Closing Balance (Intermediate). The balance at the end of the statement period. Same format as the opening balance tag.

Optional but frequently present tags include :61: (statement line — the individual transaction), :86: (information to account owner — a narrative line following a :61:), and :64: / :65: (closing available balance and forward available balance).

Balance Fields and Reconciliation

Balance validation is one of the most important checks a MT940 validator performs. The opening balance, transaction amounts, and closing balance must be mathematically consistent: opening balance plus the net of all transactions must equal the closing balance.

Balance fields use a specific format: a single character debit/credit indicator (C for credit, D for debit), a six-digit date in YYMMDD format, a three-character ISO 4217 currency code, and an amount with a comma as the decimal separator. For example:

:60F:C260101GBP1000,00

This means: credit balance of GBP 1,000.00 on January 1, 2026. Common balance field errors include:

• Wrong decimal separator. Using a period instead of a comma (e.g., 1000.00 instead of 1000,00). This is not valid MT940 and will cause many parsers to misread the amount.
• Invalid currency code. A currency code that is not a valid ISO 4217 three-letter code.
• Invalid date. A date in the wrong format or a calendar date that does not exist (e.g., month 13).
• Balance mismatch. The closing balance does not match the opening balance adjusted by all transaction amounts. This is the most significant business-level error a validator can catch — it indicates either a missing transaction, a sign error, or a corrupted file.
• Currency mismatch. Opening and closing balances use different currency codes, which is invalid unless specifically supported by the receiving system.

Transaction Lines (Tag 61)

Tag :61: is the statement line — each occurrence represents one transaction. A :61: field has a defined internal structure:

:61:ValueDateBookDateCrDrAmountSwiftCodeReference

Breaking this down: a six-digit value date (YYMMDD), an optional four-digit booking date (MMDD), a debit/credit indicator (C, D, RD, or RC for reversal), the transaction amount with comma decimal separator, a four-character SWIFT transaction code (e.g., NTRF for non-SWIFT transfer), and a reference field. Each component must be present and correctly formatted.

Common transaction line errors include:

• Missing SWIFT transaction code. The four-character code after the amount is mandatory and must be a recognized code.
• Invalid debit/credit indicator. Only C, D, RD, and RC are valid. A lowercase indicator or any other character is an error.
• Malformed amount. An amount containing characters other than digits and a single comma, or an amount with no digits before the comma.
• Date out of range. A value date that falls outside the statement period defined by the opening and closing balance dates.

Field Format Validation

Beyond mandatory tag presence and balance reconciliation, a thorough MT940 validator checks the internal format of each field value. SWIFT defines the content of each tag using a notation system: n for numeric characters, a for alphabetic, c for alphanumeric, x for any SWIFT character set character. For example, the transaction reference (:20:) is defined as 16x — up to 16 characters from the SWIFT character set.

Key format checks include:

• :20: reference length. Must not exceed 16 characters. Must not contain characters outside the SWIFT character set (which excludes certain special characters including curly braces used as SWIFT message delimiters).
• :25: account length. Must not exceed 35 characters. Some implementations require the IBAN to be valid per the ISO 13616 checksum algorithm.
• :28C: sequence format. Must follow the nnnnn/nnnnn pattern exactly — no spaces, no other separators.
• Character encoding. MT940 files should be ASCII or ISO-8859-1. UTF-8 with multi-byte characters in field values is not valid SWIFT and will cause parsing failures in many systems.
• Line length. Individual field value lines must not exceed 65 characters per the SWIFT standard. Lines that are too long may be truncated or rejected by SWIFT network gateways.

Common Validation Errors

In practice, MT940 files from different banks and software systems contain a predictable set of recurring errors. Understanding these helps you act on validation results quickly:

Missing :62F: tag. The closing balance is the most commonly omitted mandatory tag. Some bank export tools generate MT940 files that include all transaction data but omit the closing balance, producing a structurally incomplete statement that will fail validation.

Wrong decimal separator in amounts. Many non-European systems default to a period as the decimal separator. MT940 requires a comma. A file with period-separated amounts will either fail parsing entirely or produce wildly incorrect values depending on the receiving system's tolerance.

Balance reconciliation failure. This typically results from one of three causes: a transaction line with the wrong debit/credit indicator (a credit recorded as a debit shifts the running total), a missing transaction that was excluded from the export, or a rounding error in the amount representation. The validator can identify the discrepancy amount, which usually makes the root cause obvious.

Encoding issues. MT940 files generated on Windows systems may include a UTF-8 BOM, Windows-1252 special characters (smart quotes, em dashes), or CRLF line endings. Most parsers handle CRLF gracefully, but BOM characters and non-ASCII characters in field values are genuine errors.

Truncated file. A file transfer that was interrupted produces an MT940 file that ends abruptly, missing the closing balance and the end-of-message delimiter. This is immediately detectable as a missing mandatory tag.

Best Practices for Designers

If you are designing a system that generates, processes, or displays MT940 files, these practices reduce the risk of format-related failures:

• Validate at the point of generation. If your system generates MT940 files from a database or internal data model, run validation on every generated file before delivering it to the recipient. Catching a generation bug on the first file is far better than discovering it when a bank rejects a batch of statements.
• Use comma as the decimal separator unconditionally. This is the single most common MT940 error. If your internal representation uses period as a decimal separator, the conversion to comma must happen before writing the MT940 output — never assume the recipient will handle both.
• Verify balance reconciliation in your generator. Before writing the :62F: tag, compute the expected closing balance from the opening balance and all transactions. Compare it to the balance you intend to write. A mismatch at generation time indicates a bug in your transaction enumeration or sign handling.
• Include all mandatory tags even when data is absent. If there are no transactions for the statement period, the file must still include :20:, :25:, :28C:, :60F:, and :62F:. The opening and closing balances will be equal, but the tags cannot be omitted.
• Keep field values within SWIFT character set limits. When generating narrative text for :86: fields, strip or replace characters outside the SWIFT character set. Characters such as curly braces, pipes used as separators, and non-ASCII characters are common sources of downstream parsing failures.
• Test with multiple receiving systems. Different ERP and treasury systems have different levels of MT940 tolerance. A file that parses correctly in one system may fail in another due to strict line-length enforcement or different handling of optional fields. Use a validator to confirm structural correctness before testing with live system integrations.
• Archive original files before processing. MT940 files are legal financial records in many jurisdictions. Always preserve the original received file alongside any transformed or processed versions.

Common Use Cases

MT940 validation provides the most value at the boundaries between systems — whenever a file is received from an external source or before it is delivered to a downstream system.

Bank feed integration. When building a bank feed connector that receives MT940 files from a banking API or SFTP feed, validate every incoming file immediately on receipt. A validation failure should trigger an alert and halt processing rather than propagating malformed data into your accounting system.

Treasury management system imports. TMS platforms that import MT940 for cash positioning and reconciliation are sensitive to format errors. Running validation before import confirms that the file will be accepted and that balance figures are reliable.

ERP reconciliation workflows. SAP, Oracle, and Microsoft Dynamics all support MT940 import for bank reconciliation. Each has its own tolerance for format variations. Validating against the MT940 standard confirms structural correctness before the ERP-specific import step.

Audit and compliance review. Compliance teams reviewing bank statement data for audit purposes can use MT940 validation to confirm the integrity of received files — specifically that balance figures are internally consistent and that no transactions appear to be missing.

Fintech product development. Developers building payment applications, accounting tools, or open banking integrations that consume MT940 use validation to confirm their parser handles all edge cases correctly. Running validation against a library of real-world MT940 files from different banks reveals parser gaps before they affect production users.