MT940 SWIFT Message: The Complete Guide to Formats, Fields, and Reconciliation

For Indian exporters, freelancers, and SaaS companies, receiving international payments involves more than just tracking bank balances. You need structured electronic statements that integrate with your accounting systems, enable automated reconciliation, and satisfy compliance requirements. The MT940 SWIFT message serves as the global standard for electronic bank statements, transmitting detailed transaction data that corporate treasury teams rely on for end-of-day cash positioning.

The MT940 message provides a structured electronic record of all entries booked to an account, enabling automated reconciliation that eliminates manual data entry errors. Multinational corporations and treasury teams managing cash visibility across different banks and regions depend on this standardised format for consistent reporting. However, the financial industry is actively transitioning from MT940 to the XML-based ISO 20022 standard (camt.053), with critical changes coming in November 2025.

What is an MT940 File?

The MT940 (Message Type 940) is a Customer Statement message sent by a reporting financial institution to an account owner or authorised concentrating institution. This final end-of-day statement differs from interim updates in that it provides a complete record of the day’s activity. It contains all financial transactions (debits and credits) and balance information for a specific account, delivered in a standardised format that systems can process automatically.

Corporate Treasury departments, accounting teams, and automated ERP systems represent the primary users of MT940 files. These stakeholders rely on the MT940 SWIFT message meaning as a universal language for bank-to-corporate communication. The format ensures that whether you’re receiving statements from banks in Singapore, London, or New York, the data structure remains consistent for systematic processing.

Structure of the MT940 SWIFT Message

Having established what an MT940 file represents, understanding its internal structure becomes essential for effective parsing and reconciliation. The message consists of a sequence of mandatory and optional fields (tags) that define the statement data within the Text Block. Each tag serves a specific purpose in conveying transaction details, balances, and reference information.

The block structure encompasses Header, Text Block, and Trailer sections, but the critical data resides within the Text Block’s tags. These tags follow a strict sequence from Tag 20 through Tag 86, each contributing essential information for complete transaction visibility.

Tag 20: Transaction Reference Number

• Identifies this as a mandatory field used by the sender to identify the message uniquely[1]
• Format: 16x (up to 16 alphanumeric characters)
• Serves a critical role in duplicate detection and message tracking across banking systems

Tag 25: Account Identification

• Represents a mandatory field that specifies the account number for the statement.
• Format: 35x (up to 35 characters)
• Typically contains the IBAN or local account number for precise identification.

Tag 28C: Statement Number

• Functions as a mandatory field indicating the sequential number of the statement.
• Format: 5n/5n (Statement Number/Sequence Number)
• Handles multiple messages for a single day’s statement through sequence numbering.

Tag 60F and 60M: Opening Balance

• Defines Tag 60 as the Opening Balance indicator for the statement period.
• Distinguishes between 60F (Final Opening Balance) and 60M (Intermediate Opening Balance).
• Format breakdown: D/C (Debit/Credit) | Date (YYMMDD) | Currency (ISO) | Amount
• 60F usually matches the previous day’s closing balance (62F) for continuity.

Tag 61: Statement Line

• Represents the core field containing individual transaction details[2]
• Sub-elements include: Value Date (6!n), Entry Date (4!n), Debit/Credit Mark (2a), Funds Code (1!a), Amount (15d), Transaction Type (4!c), Reference for Account Owner (16x), Bank Reference (16x)
• Plays a critical role in identifying the ‘what’ and ‘when’ of each transaction.

Explore Razorpay’s Global Payment Solutions

Tag 86: Information to Account Owner

• Functions as an optional but highly valuable field for reconciliation purposes.
• Contains narrative information, remittance details, or payment references.
• Structure varies by bank (unstructured text vs. structured codes like /OCMT/).
• Format: 6x65x (Up to 6 lines of 65 characters).

Tag 62F and 62M: Closing Balance

• Defines Tag 62 as the Closing Balance (Booked Funds) for the statement.
• Distinguishes between 62F (Final Closing Balance) and 62M (Intermediate Closing Balance).
• Format breakdown matches the opening balance: D/C | Date | Currency | Amount
• 62F represents the definitive end-of-day position for account reconciliation.

Comparing MT940 with Other Formats

The structured tags in MT940 messages deliver detailed transaction data, but MT940 is just one format within the broader SWIFT message family. Selecting the right format depends on timing (intraday vs. end-of-day) and the recipient (bank vs. corporate). Clear understanding of these differences enables treasury teams to choose the most suitable messaging for their needs.

MT940 vs. MT942 (Intraday)

• Timing differs fundamentally: MT940 provides a final End-of-Day statement; MT942 delivers an Interim Transaction Report sent during the day.
• Completeness varies: MT940 covers all bookings; MT942 only covers transactions since the last report.
• Usage splits by function: MT940 serves reconciliation; MT942 enables real-time liquidity management.

MT940 vs. MT950 (Statement Message)

• Primary user distinction clarifies purpose: MT940 is a ‘Customer Statement’ (for corporates); MT950 is a ‘Statement Message’ (often for bank-to-bank Nostro/Vostro reconciliation).
• Detail level differs: MT940 supports richer transaction details (Tag 86) tailored for ERP auto-reconciliation.
• Structure varies: MT950 is often more streamlined, focusing on balance confirmation between financial institutions.
• The MT950 vs MT940 SWIFT messages distinction matters most for treasury teams managing multi-bank relationships.

MT940 vs. ISO 20022 (camt.053)

• camt.053 represents the ISO 20022 XML equivalent of MT940, offering the advantages of structured data.
• Key benefits include: Structured data, unlimited field lengths, consistent character sets, and enhanced remittance information
• Migration timeline indicates eventual sunsetting of MT formats, with coexistence ending November 2025.

Common Challenges with MT940 Files

Despite the standardised format comparison showing MT940’s capabilities, practical implementation reveals several processing difficulties. Treasury teams frequently encounter parsing issues that complicate automated reconciliation efforts.

• Parsing difficulties arise from unstructured data in Tag 86, where banks use proprietary formats.
• Bank-specific interpretations of the SWIFT standard create inconsistent implementations with proprietary codes.
• Character encoding problems emerge when non-Latin characters cause system errors and failed imports.
• High costs and technical overhead burden smaller firms in maintaining SWIFT connectivity for statement retrieval.

Solutions for Efficient International Reconciliation

These MT940 processing challenges drive businesses to seek modern solutions for statement handling. The spectrum of available tools ranges from traditional ERPs to contemporary fintech platforms, each addressing different organisational needs.

Treasury Management Systems (TMS)

• TMS platforms aggregate MT940s from multiple banks into unified dashboards.
• Features include automated cash positioning and liquidity forecasting capabilities.
• Best suited for: Large enterprises managing complex multi-bank relationships globally.

ERP System Integration

• Direct import enables MT940 files to flow into ERPs (SAP, Oracle, NetSuite) automatically.
• Requires ‘parsers’ or middleware to map bank-specific MT940 variants to ERP ledgers.
• Best suited for: Mid-to-large corporates integrating finance and operations workflows.

Specialized Parsing Software

• Standalone tools or libraries designed solely to read and convert MT940 files into CSV/Excel formats.
• Provides readable data output for smaller finance teams without full TMS infrastructure.
• Best suited for: SMEs or developers building custom integrations with limited budgets.

Razorpay MoneySaver Export Account

• Introduces a modern alternative for Indian exporters to bypass raw SWIFT file complexity entirely.
• Uses local rails (ACH, SEPA) for collections, avoiding SWIFT fees while providing auto-reconciled digital statements.
• Features include: Single-click FIRC generation and a unified dashboard for real-time payment tracking.
• Positions as a solution that simplifies the reconciliation problem, MT940s were originally designed to solve.

How Razorpay MoneySaver Simplifies Export Reconciliation

Traditional MT940-based reconciliation requires significant technical infrastructure, but modern solutions offer streamlined alternatives. The Razorpay MoneySaver Export Account modernises reconciliation for Indian exporters by providing a unified dashboard that tracks international payments in real time, eliminating the need to parse complex raw MT940 files.

It automatically generates electronic Foreign Inward Remittance Certificates (FIRC) for every transaction, solving a major compliance hurdle that traditionally requires manual bank coordination. Using local account rails (such as ACH and SEPA) for collections offers a structured, digital alternative to traditional SWIFT wires, ensuring faster settlements and seamless integration with your financial records.

Conclusion

The MT940 SWIFT message remains the backbone of corporate bank reconciliation, providing structured transaction data essential for treasury operations. Understanding its tag structure, from transaction lines in Tag 61 to narrative details in Tag 86, empowers businesses to resolve reconciliation errors and maintain accurate cash visibility.

As the industry transitions toward ISO 20022 formats by November 2025, exporters must evaluate whether parsing traditional MT940 files or adopting automated digital solutions better serves their needs. Modern platforms like Razorpay eliminate SWIFT complexity while providing real-time visibility and automated compliance documentation for growing Indian businesses.

FAQs

Q1: What is the primary difference between MT940 and MT942 messages?

The MT940 is a definitive end-of-day statement that records all booked transactions and closing balances, whereas the MT942 is an interim intraday report used for real-time liquidity monitoring without a finalised closing balance.

Q2: How does the MT940 format differ from MT950?

MT940 is a detailed Customer Statement designed for corporate reconciliation with rich narrative fields (Tag 86), while MT950 is a streamlined Statement Message often used between financial institutions for nostro/vostro balance confirmations.

Q3: Is the MT940 format being replaced by ISO 20022?

Yes, the global financial system is migrating to the ISO 20022 standard, where the XML-based camt.053 message will eventually replace the MT940 to provide richer, more structured data.

Q4: What critical information is contained in Tag 61?

Tag 61 is the Statement Line field that contains essential transaction details, including the value date, entry date, debit/credit indicator, funds code, amount, and transaction type identification.

Q5: Why is Tag 86 often a challenge for reconciliation software?

Tag 86 contains the Information to Account Owner, which often holds unstructured text or proprietary bank codes that vary between institutions, making it difficult for standard software to parse automatically.

Q6: Can I read an MT940 file without specialised software?

While MT940 files are technically plain text, they use a dense, code-heavy structure that is difficult for humans to interpret efficiently without a parser or financial application to visualise the data.