MT940 ataskaita, or MT940 report, is the SWIFT message format banks use to deliver end-of-day account statements, and it still underpins daily reconciliation for most finance teams. Its ongoing role is operational, not symbolic: it moves balances and transaction data into your accounting and treasury systems. The ISO 20022 shift toward camt.053 brings richer structured data, but whether your bank has switched, and when, depends on that bank’s own migration schedule.

TL;DR:

The main issues in reconciliation stem from variability in the free-text :86 field, which requires bank-specific parsing rules and remittance standardization.

Demivoltdemivolt.comBring Payments Into Clearer ViewDemivolt provides business accounts, SEPA and SWIFT payments, and multi-account structures for clearer financial control across operations.Visit Demivolt

MT940 file structure and the tags that matter for reconciliation
How finance teams use MT940 for reconciliation, and where it breaks
MT940 vs camt.053: what ISO 20022 actually changes
A checklist to audit your statement feeds before anything changes
Lessons from live migration projects
Our view on supporting statement feeds through this transition
How Demivolt supports your statement connectivity
FAQ
Sources

MT940 file structure and the tags that matter for reconciliation

An MT940 file is plain text, organized into labeled fields called tags, and reading one is mostly a matter of knowing which tags carry the information you need. Some tags are mandatory on every statement; others appear only when relevant to a specific transaction or account setup.

The tags that matter most for day-to-day work:

:20 is the transaction reference number, a unique identifier for the message itself.
:25 identifies the account, usually the IBAN, so you know which ledger the statement belongs to.
:28C is the statement number and sequence, useful for detecting gaps or duplicates.
:60F and :62F carry the opening and closing balances for the period.
:61 is the transaction line itself: value date, amount, and a reference code for each booking.
:86 holds the narrative or remittance information, the free-text field where payment descriptions live.

This structure is defined in SWIFT’s Message Reference Guide, which documents each tag and marks which ones are mandatory versus optional. In practice, banks interpret the optional parts differently. Watch for missing subfields in :86, inconsistent delimiters between banks, or truncated reference codes. These are not file errors; they are bank-specific formatting choices, and your parsing logic needs to account for them rather than assume one universal layout.

How finance teams use MT940 for reconciliation, and where it breaks

MT940 supports a fairly standard reconciliation workflow: pull the daily statement, match each :61 line against open invoices or expected payments, update your cash position, and flag anything unmatched for manual review.

Import the statement and validate the opening balance against yesterday’s closing balance.
Match each transaction line to an invoice, payment run, or expected receipt using amount, date, and reference.
Route unmatched items to manual review, usually because the :86 narrative lacks a clean invoice number.
Update your cash position and close out the day once exceptions are resolved.

The weak point is almost always :86. It is free text, so one bank might place the payer name first, another might lead with a payment reference, and a third might truncate the field entirely. Practical treasury commentary notes that these bank “dialects” are a real source of reconciliation breaks, independent of anything your own systems do wrong.

You do not need a new bank relationship to fix this. Standardize your parsing rules per bank, build remittance formatting templates with your counterparties where possible, and add a pre-processing script that normalizes date formats and amount notation before matching runs.

Pro Tip: Canonicalize dates and decimal formats across all incoming statements before your matching engine runs; most false mismatches come from formatting differences, not missing data.

MT940 vs camt.053: what ISO 20022 actually changes

The core difference is structural. MT940 is plain text with a limited, fixed set of tags. Camt.053 is XML, with a far larger schema that can carry structured remittance detail, related-party information, and booking-type flags that :86 free text simply cannot hold.

Here is the part worth getting right: the November 2025 ISO 20022 milestone applied to cross-border payment instructions, not to bank statement formats directly. Swift confirmed that coexistence between MT and ISO 20022 messages for payment instructions ended on November 22, 2025, and encouraged banks to focus on using the structured data that instructions now carry. Statement delivery is a separate decision each bank makes on its own timeline.

MT940 uses a compact set of tags; camt.053 schemas (through version .001.08) hold far more structured fields.
Camt.053 can embed related-party and booking-type data that MT940’s free-text :86 cannot represent reliably.
Higher auto-match rates depend on both the sender and the receiving system using those structured fields, not just the format switch itself.

Camt.053’s structured remittance fields can improve auto-match rates, but industry commentary is clear that the gain only shows up once both sides of the payment and the treasury system itself are configured to use that structure, not simply once the file format changes.

A checklist to audit your statement feeds before anything changes

Start by confirming, account by account, what format your bank currently sends: MT940, camt.053, or camt.052. Request a sample file for each, as formats and content may vary.

Ask each bank whether its camt.053 is generated natively or converted from an underlying MT940 feed, and request a migration timeline if one exists.
Load sample files into a staging environment and map every field to your ERP or treasury system before touching production.
Run MT940 and camt.053 in parallel where both are available, and measure auto-match rates before cutting over fully.
Assign clear owners: an account manager for the bank relationship, a treasury lead for mapping decisions, and an IT or vendor contact for system configuration.

Set a parallel-run window of at least one full statement cycle, and define acceptance criteria in advance, such as a target auto-match rate, before retiring the old feed.

Pro Tip: Treat “camt.053 available” as a question, not an answer: some banks wrap MT content in XML rather than generating it natively, so the structured fields you expect may not actually be populated.

Lessons from live migration projects

Migration experience across banks is uneven. KPMG’s work with clients on these transitions shows that timelines and complexity vary significantly by bank and by the age of the client’s own ERP or treasury system, with schema version handling and Unicode support common points of friction.

Migration projects from MT940/MT942 to camt.053/camt.052 differ in complexity depending on each bank’s technical path and the client’s existing system configuration.

Running MT and camt feeds in parallel before cutover remains the most reliable way to catch mapping errors early, rather than discovering them after your old feed is switched off.

Our view on supporting statement feeds through this transition

Some regulated EU fintech platforms issue dedicated IBAN accounts and support SWIFT and SEPA payment flows, which can involve generating statements and helping clients make sense of them, as described in Enterprise Payment Operations — Cray. Multi-account structures and role-based access matter during migration, since treasury leads, account managers, and IT contacts often need different views of the same statement feed at once. We see format testing as a practical, ongoing task rather than a one-time project, particularly for businesses managing accounts across multiple banking relationships during a changeover.

— dd

How Demivolt supports your statement connectivity

If your finance team is auditing statement formats across several banking relationships, a business account with Demivolt gives you a dedicated IBAN, SWIFT and SEPA payment support, and multi-account visibility in one place, with transparent fees and no surprise charges.

Request a connectivity test or sample statement file to see how your reconciliation workflow would handle our feeds before you commit to any changes.

FAQ

Is MT940 being phased out entirely?

Not on a fixed industry-wide date. SWIFT’s November 2025 milestone ended MT and ISO 20022 coexistence for cross-border payment instructions specifically, while bank statement formats like MT940 continue on each bank’s own schedule.

What’s the real difference between MT940 and camt.053?

MT940 is a plain-text format with a compact, fixed set of tags, while camt.053 is XML with a much larger schema that can carry structured remittance and related-party detail. The practical benefit of camt.053 depends on your treasury system actually using that structure, not just receiving the file.

How do I ask my bank about camt.053 availability?

Ask directly whether camt.053 is generated natively or converted from an MT940 feed internally, and request a sample file alongside any available migration timeline. Practical commentary from treasury vendors notes that some “camt.053” statements are MT content wrapped in XML rather than a genuine native format.

Why do my :86 fields look different across banks?

The :86 narrative field is free text, so each bank formats it differently, placing references, payer names, or descriptions in varying order or truncating them. This variability is a known source of reconciliation breaks and is best handled with per-bank parsing rules rather than a single universal template.

Does Demivolt provide MT940 or camt.053 statements?

Certain regulated fintech platforms issue dedicated IBAN accounts with SWIFT and SEPA support and may provide sample statement files for testing as part of onboarding. Specific format availability and timelines are best confirmed directly with our team for your account setup.

4 MT940 Report Checks Finance Teams Must Run Before ISO 20022

Table of Contents