MT940 vs CAMT.053: Bank Statement Format Guide

MT940 and CAMT.053 are the two bank statement formats that define how financial institutions deliver end-of-day account data to corporate clients. If you work in European banking, treasury, or finance operations, you either parse these files today or will need to soon.

MT940 is SWIFT's legacy bank statement format, built on fixed-length tagged fields. Each transaction and balance record is identified by a tag number — Tag 20 for the transaction reference, Tag 60F for the opening balance, Tag 61 for individual statement lines, Tag 86 for transaction details. Banks have delivered end-of-day account statements in this format for decades, and it became the de facto standard for automated bank reconciliation across Europe and beyond.

CAMT.053 is its ISO 20022 XML replacement. Where MT940 encodes data in positional, fixed-width fields, CAMT.053 uses hierarchical XML with named, nested elements. Every transaction carries self-describing context: structured remittance information, debtor and creditor details, purpose codes, and charge breakdowns that MT940 simply cannot represent. The result is significantly more granular detail per transaction.

The structural difference between these formats is fundamental. In an MT940 file, meaning depends on where data sits within a fixed-length field — the characters at positions 1-6 of a Tag 61 line encode the value date, the next four encode the entry date, and so on. In CAMT.053, each data point lives inside a clearly labeled XML element like ValDt or NtryDtls. This makes CAMT.053 files larger but far less ambiguous to parse and validate.

The November 2025 ISO 20022 milestone did not retire MT940 everywhere. Swift says SCORE users can continue to send and receive MT 101, MT940, and MT942 after November 2025, even though key cross-border payment traffic has moved to ISO 20022. Domestic bank-to-corporate statement delivery still depends on the bank, country, and service used.

That uneven rollout is why finance and treasury teams still need dual-format handling. Your bank may have switched already; a client's bank may still send MT940. Either way, you need to understand both formats to keep bank statement data flowing accurately into downstream systems.

How MT940 Structures Bank Statement Data

MT940 is a SWIFT FIN message type — formally, Message Type 940: Customer Statement Message. It was designed for automated delivery of end-of-day account statements from a bank to its customers and follows a rigid, sequential tag structure. Each tag is a numbered field that carries a specific piece of statement data, and the tags always appear in the same order.

Understanding these tags is the key to reading, parsing, or validating any MT940 file.

The Essential MT940 Tags

Tag 20: Transaction Reference Number A unique identifier the bank assigns to this particular statement message. Used to detect duplicates and track specific statements in your reconciliation workflow.

Tag 25: Account Identification The account number the statement relates to. The format varies by country and bank — German banks typically use BLZ + account number or IBAN, while other institutions may use BIC/account combinations.

Tag 28C: Statement Number / Sequence Number Two values separated by a slash: the statement number and the page sequence number. These let you verify ordering and confirm no statements are missing. For example, 00042/001 means statement 42, page 1.

Tag 60F: Opening Balance The account balance at the start of the statement period. The "F" denotes the first opening balance. This field contains four components: a debit/credit mark (D or C), the date in YYMMDD format, the three-letter currency code, and the amount.

Tag 61: Statement Line Each individual transaction gets its own Tag 61 entry. This is a dense, position-dependent field that packs several data points into a single line:

Value date (YYMMDD) and entry date (MMDD)
Debit/credit mark (D, C, RD, or RC for reversals)
Amount
Transaction type identification code (a three-character SWIFT code like N for cash, F for charges)
Customer and bank reference numbers

Tag 86: Information to Account Owner The descriptive detail behind each transaction — counterparty names, payment references, remittance text, and bank-specific codes. Tag 86 always appears immediately after its corresponding Tag 61 entry, forming a paired record of each transaction.

This tag carries the bulk of the human-readable transaction detail and is the most complex tag to parse. Its content can be either unstructured free text or bank-specific structured subfields (such as the German ?20 through ?63 subfield convention). Which format you receive depends entirely on your bank's implementation.

A critical constraint: Tag 86 is limited to 6 lines of 65 characters each, a maximum of 390 characters total. This hard ceiling restricts how much remittance and counterparty information a bank can include per transaction, and it is one of the format's most significant practical limitations.

Tag 62F: Closing Balance The account balance at the end of the statement period. Follows the same format as Tag 60F — debit/credit mark, date, currency, amount.

Annotated MT940 Structure

A typical MT940 message flows in this order:

:20:STARTUMS                        → Transaction reference
:25:10020030/1234567890              → Account identification
:28C:00042/001                       → Statement 42, page 1

:60F:C250410EUR12500,00              → Opening balance: Credit, 10 Apr 2025, EUR 12,500.00

:61:2504100410D1500,00NTRF1234567890 → Transaction: 10 Apr, debit, EUR 1,500.00, transfer
:86:Rent payment April 2025          → Remittance detail for above transaction
ACME GmbH Konto DE89370400440       → (continued)

:61:2504100410C3200,50NTRF0987654321 → Transaction: 10 Apr, credit, EUR 3,200.50, transfer
:86:?20Invoice 2025-0891             → Structured subfields (German format)
?21Payment for consulting            → (continued)
?32Mueller und Partner GmbH          → Counterparty name

:62F:C250410EUR14200,50              → Closing balance: Credit, 10 Apr 2025, EUR 14,200.50

Notice the Tag 61 and Tag 86 pairing: every statement line is followed by its information block. The opening balance plus all debits and credits should reconcile to the closing balance, giving you a built-in integrity check.

The sequential, fixed-tag structure makes MT940 predictable to parse once you understand the field positions. The challenge lies almost entirely in Tag 86, where each bank's formatting conventions introduce the variability you need to account for in any extraction or integration workflow.

How CAMT.053 Structures Bank Statements in XML

CAMT.053 (Bank-to-Customer Statement, or BkToCstmrStmt) is the ISO 20022 XML message format designed for end-of-day bank account statements. Unlike MT940's flat, tag-based layout, CAMT.053 organizes data in a deeply nested XML hierarchy where every piece of information occupies a dedicated, named element. This structure matters because it means you can query, extract, and validate individual fields without parsing free-text blocks.

The XML Hierarchy

A CAMT.053 file follows a strict top-down structure. Each level contains the next.

Document Root and Group Header

The outermost element is Document, which wraps BkToCstmrStmt. Inside that, GrpHdr (Group Header) carries the message identification string and creation datetime. These tell you when the statement was generated and provide a unique reference for the entire file.

Statement (Stmt)

Each Stmt element represents one account's statement for one period. It contains:

Account identification via Acct/Id/IBAN (or Acct/Id/Othr for non-IBAN identifiers)
Electronic sequence number (ElctrncSeqNb), which tracks statement ordering
Creation datetime and the reporting period covered
Balance elements and transaction entries

A single CAMT.053 file can contain multiple Stmt blocks, covering several accounts in one message.

Balance (Bal)

Balance elements carry explicit type codes rather than relying on position:

OPBD (Opening Booked): the confirmed balance at statement start
CLBD (Closing Booked): the confirmed balance at statement end
CLAV (Closing Available): the available balance factoring in pending items

Each balance includes Amt with a currency attribute, a CdtDbtInd (credit or debit indicator), and Dt (date). No ambiguity, no positional guessing.

Entry (Ntry)

Individual transactions appear as Ntry elements, each containing:

Amt with currency and CdtDbtInd for amount and direction
BookgDt (booking date) and ValDt (value date) as separate elements
Sts for transaction status (booked, pending, or information)
AcctSvcrRef for the bank's own reference number
BkTxCd (Bank Transaction Code) with a three-level classification: Domn (domain, e.g., payments), Fmly (family, e.g., credit transfer), and SubFmly (subfamily, e.g., standing order). This structured coding replaces MT940's GVC codes and makes transaction categorization programmatically reliable across banks.

Entry Details (NtryDtls/TxDtls)

This is where CAMT.053 delivers its most significant advantage. TxDtls contains:

Remittance information (RmtInf): both structured (Strd) and unstructured (Ustrd) payment references
Related parties: debtor name (DbtrNm), debtor IBAN (DbtrAcct/Id/IBAN), creditor name (CdtrNm), creditor IBAN (CdtrAcct/Id/IBAN), each in its own element
End-to-end identification (EndToEndId): the reference assigned by the originating party
Purpose codes (Purp/Cd): standardized codes indicating the transaction's business purpose

Annotated CAMT.053 Structure

The following XML shows the same two transactions from the MT940 example above, represented in CAMT.053 format. Notice how each data point occupies its own named element rather than a fixed position within a text line:

<BkToCstmrStmt>
  <GrpHdr>
    <MsgId>STARTUMS</MsgId>
    <CreDtTm>2025-04-10T23:59:00</CreDtTm>
  </GrpHdr>
  <Stmt>
    <Id>STARTUMS</Id>
    <ElctrncSeqNb>42</ElctrncSeqNb>
    <Acct>
      <Id><IBAN>DE10020030001234567890</IBAN></Id>
      <Ccy>EUR</Ccy>
    </Acct>

    <!-- Opening Balance (MT940 Tag 60F) -->
    <Bal>
      <Tp><CdOrPrtry><Cd>OPBD</Cd></CdOrPrtry></Tp>
      <Amt Ccy="EUR">12500.00</Amt>
      <CdtDbtInd>CRDT</CdtDbtInd>
      <Dt><Dt>2025-04-10</Dt></Dt>
    </Bal>

    <!-- Transaction 1: Rent payment (MT940 Tags 61 + 86) -->
    <Ntry>
      <Amt Ccy="EUR">1500.00</Amt>
      <CdtDbtInd>DBIT</CdtDbtInd>
      <BookgDt><Dt>2025-04-10</Dt></BookgDt>
      <ValDt><Dt>2025-04-10</Dt></ValDt>
      <NtryDtls>
        <TxDtls>
          <RltdPties>
            <Cdtr><Nm>ACME GmbH</Nm></Cdtr>
            <CdtrAcct><Id><IBAN>DE89370400440532013000</IBAN></Id></CdtrAcct>
          </RltdPties>
          <RmtInf><Ustrd>Rent payment April 2025</Ustrd></RmtInf>
        </TxDtls>
      </NtryDtls>
    </Ntry>

    <!-- Transaction 2: Consulting payment (MT940 Tags 61 + 86) -->
    <Ntry>
      <Amt Ccy="EUR">3200.50</Amt>
      <CdtDbtInd>CRDT</CdtDbtInd>
      <BookgDt><Dt>2025-04-10</Dt></BookgDt>
      <ValDt><Dt>2025-04-10</Dt></ValDt>
      <NtryDtls>
        <TxDtls>
          <Refs><EndToEndId>INV-2025-0891</EndToEndId></Refs>
          <RltdPties>
            <Dbtr><Nm>Mueller und Partner GmbH</Nm></Dbtr>
          </RltdPties>
          <RmtInf><Ustrd>Payment for consulting</Ustrd></RmtInf>
        </TxDtls>
      </NtryDtls>
    </Ntry>

    <!-- Closing Balance (MT940 Tag 62F) -->
    <Bal>
      <Tp><CdOrPrtry><Cd>CLBD</Cd></CdOrPrtry></Tp>
      <Amt Ccy="EUR">14200.50</Amt>
      <CdtDbtInd>CRDT</CdtDbtInd>
      <Dt><Dt>2025-04-10</Dt></Dt>
    </Bal>
  </Stmt>
</BkToCstmrStmt>

Compare this with the MT940 example: the rent payment to ACME GmbH that was encoded as a Tag 61/86 pair now occupies a fully structured Ntry block with the creditor name and IBAN in dedicated elements. No free-text parsing required.

The Data Density Advantage

Where MT940 compresses counterparty and remittance data into Tag 86's 390-character free-text limit, CAMT.053 provides discrete elements for each piece of information. A parser reads CdtrAcct/Id/IBAN directly rather than pattern-matching within unstructured text that different banks format differently.

The scale of this difference is substantial. Where MT940 offers roughly two dozen tags, the CAMT.053 format defines around 1,300 data tags in version v02 alone, with newer versions (v06 and v08) defining over 5,000 tags, according to Deutsche Bank Corporate Bank.

That extra structure improves automated matching because invoice references, counterparties, account identifiers, and ISO bank transaction codes can be read from dedicated fields instead of inferred from free text.

Versioning Considerations

CAMT.053 is not a single fixed schema. It has evolved through multiple versions, from camt.053.001.02 through .011 and beyond. Each version adds elements and refines existing ones. In practice, version support varies by bank: some still issue v02 files, others have moved to v06 or v08.

Your parser needs to handle this. The core elements described above are stable across versions, but newer versions introduce additional fields for regulatory reporting, richer remittance structures, and expanded party identification. Check the XML namespace declaration at the top of each file to determine which schema version you are working with, and build your extraction logic to degrade gracefully when optional elements from newer versions are absent.

MT940 Tag to CAMT.053 XML Element Mapping

This MT940 tag mapping table is the core reference for anyone migrating parsers, building dual-format integrations, or reconciling statement data across both standards. Each row maps an MT940 tag to its functional equivalent in the CAMT.053 XML schema, with notes on where CAMT.053 extends beyond what MT940 can express.

MT940 Tag	Purpose	CAMT.053 XML Path	Notes
Tag 20	Transaction Reference Number	Stmt/Id	Direct one-to-one mapping. Identifies the statement itself.
Tag 25	Account Identification	Stmt/Acct/Id/IBAN	For non-IBAN accounts, use Stmt/Acct/Id/Othr/Id. CAMT.053 also carries the BIC under Stmt/Acct/Svcr/FinInstnId/BICFI, which MT940 does not separate cleanly.
Tag 28C	Statement Number / Sequence	Stmt/ElctrncSeqNb	CAMT.053 splits this into ElctrncSeqNb (statement number) and LglSeqNb (legal sequence), giving more precise sequencing than Tag 28C's single compound field.
Tag 60F	Opening Balance	Bal where Tp/CdOrPrtry/Cd = OPBD	Balance amount in Bal/Amt with currency attribute. Debit/credit direction in Bal/CdtDbtInd. Date in Bal/Dt/Dt. The XML structure is identical for all balance types, distinguished only by the type code.
Tag 61	Statement Line (Transaction)	Ntry	Amount maps to Ntry/Amt. Direction to Ntry/CdtDbtInd. Value date to Ntry/ValDt/Dt. Booking date to Ntry/BookgDt/Dt. Bank reference to Ntry/AcctSvcrRef. Status in Ntry/Sts.
Tag 86	Remittance / Transaction Details	Ntry/NtryDtls/TxDtls	See detailed breakdown below. This is the largest structural expansion from MT940 to CAMT.053.
Tag 62F	Closing Balance	Bal where Tp/CdOrPrtry/Cd = CLBD	Same structure as opening balance.
Tag 64	Closing Available Balance	Bal where Tp/CdOrPrtry/Cd = CLAV	Optional in both formats. Represents funds actually available, which may differ from the booked closing balance.

The Tag 86 to NtryDtls Expansion

The mapping from Tag 86 to NtryDtls/TxDtls deserves particular attention because it represents the single biggest structural gain in moving to CAMT.053. In MT940, Tag 86 is either fully unstructured free text or, in German banking practice, semi-structured text using subfield codes like ?20 through ?63. Parsers must know each bank's specific subfield conventions to extract counterparty names, account numbers, and payment references reliably.

CAMT.053 replaces this with discrete, typed XML elements:

RmtInf/Ustrd and RmtInf/Strd separate unstructured remittance text from structured remittance data, including creditor references and invoicing details
RltdPties/Dbtr and RltdPties/Cdtr provide counterparty names, postal addresses, and account identifiers (IBAN, BIC) in dedicated fields rather than buried in free text
Refs/EndToEndId carries the end-to-end reference assigned by the originator, while Refs/InstrId holds the instruction identification, both of which would be concatenated somewhere inside Tag 86 text in MT940
Refs/PmtInfId and Refs/MndtId capture payment information IDs and mandate references for direct debits, fields that have no formal place in MT940

Transaction Type Code Mapping

MT940's Tag 61 includes a two-character transaction type code (such as "TRF" for transfer or "CHK" for cheques) drawn from a limited legacy codeset. CAMT.053 replaces this with the BkTxCd element, which uses ISO 20022's three-level classification: domain (e.g., "PMNT" for payments), family (e.g., "RCDT" for received credit transfers), and subfamily (e.g., "ESCT" for SEPA credit transfer). This standardized hierarchy eliminates the ambiguity that comes with interpreting two or three letter abbreviations that different banks may use inconsistently.

CAMT.053 Fields With No MT940 Equivalent

Several CAMT.053 elements have no counterpart in MT940 at all. These represent net-new data available only in the XML format:

Ntry/AddtlNtryInf provides supplementary entry-level information the bank wants to communicate
TxDtls/Purp/Cd carries a standardized ISO purpose code for the transaction (e.g., "SALA" for salary, "SUPP" for supplier payment)
Ntry/Btch contains batch booking indicators, including the number of transactions and total amount when multiple payments are grouped into a single entry
TxDtls/AmtDtls can break down the instructed amount, currency exchange details, and charges separately, which MT940 has no structured way to express

How Banks Implement MT940 and CAMT.053 Differently

Neither MT940 nor CAMT.053 produces identical files across banks. Both are standards built on optional fields and implementation choices, which means a file from Deutsche Bank, a file from Commerzbank, and a file from a French or Dutch bank can all be valid according to the specification yet structurally different in ways that break parsers expecting a single consistent layout.

Understanding where these variations occur is essential for anyone building or maintaining systems that consume German bank statement formats from multiple banking partners.

Tag 86 Variations in MT940

The single largest source of inconsistency in MT940 files is Tag 86, the transaction details field. The SWIFT standard defines Tag 86 as a free-format field with up to 6 lines of 65 characters. What banks put in those lines varies dramatically.

For German domestic use, the Deutsche Bundesbank and the German Banking Industry Committee (Deutsche Kreditwirtschaft, DK) defined a structured subfield format using identifiers prefixed with question marks:

?20–?29 — Booking text and payment reference
?30 — BLZ (Bankleitzahl) of the counterparty's bank
?31 — Account number of the counterparty
?32/?33 — Counterparty name
?60 — IBAN of the counterparty (for SEPA transactions)

Most German banks follow this structure, but even within Germany the specific content varies. One bank might populate ?20 with a condensed reference code while another includes the full remittance text across ?20–?29. Some banks include the SEPA end-to-end reference in ?20, others place it in a different subfield.

International banks frequently skip structured subfields entirely, writing unstructured free text into Tag 86. A parser that reliably extracts counterparty names and IBANs from Sparkasse files using ?32 and ?60 will find nothing useful when applied to a Barclays or BNP Paribas MT940 export. Belgian institutions like BNP Paribas Fortis add further complexity with bilingual statement formats and CODA file delivery, which is why converting BNP Paribas Fortis statements to Excel often requires bank-specific handling beyond standard MT940 parsing. Teams working from Belgian bank exports may also need a separate workflow for converting CODA files to Excel when the source file is not MT940 or CAMT.053 at all. This means Tag 86 parsing logic must be bank-specific or at minimum detect whether structured subfields are present before attempting extraction.

Version and Extension Differences in CAMT.053

CAMT.053 eliminates the free-text ambiguity of Tag 86 by using structured XML elements with defined paths. But it introduces a different class of variation: schema version differences.

Banks currently produce files ranging from camt.053.001.02 through camt.053.001.08 and newer versions. Each successive version adds optional elements and refines existing ones. A parser built against version 02 will encounter unrecognized elements in a version 08 file. Conversely, a parser expecting version 08 fields for structured creditor references or detailed charge breakdowns will find them absent in files produced to the earlier specification.

Beyond version differences, country-level implementation guidelines and bank-specific extensions add further layers of variation. The Deutsche Bundesbank and DK publish detailed implementation guidelines specifying which optional CAMT.053 elements German banks should populate and how. These guidelines significantly reduce variation within the German banking ecosystem, making files from German banks more predictable than those from banks in countries without comparable guidance.

Still, organizations banking across borders will encounter files that follow different national guidelines or no supplementary guidelines at all.

The Practical Consequence

Any system consuming bank statement files from multiple banks must account for structural variation as a first-class concern, not an edge case. For MT940, this means building Tag 86 parsing logic that handles both structured German subfields and unstructured international text. For CAMT.053, it means supporting multiple schema versions and tolerating both the presence and absence of optional elements.

This variability is why most organizations normalize bank statement data into a common format regardless of the source bank. German companies working with DATEV face this directly, as bank transaction data from different institutions needs to map into DATEV's expected booking format. The process of importing financial data into Germany's DATEV accounting system requires handling exactly these kinds of structural differences between banks.

Converting MT940 and CAMT.053 Files to Excel and CSV

Getting transaction data out of MT940 and CAMT.053 files and into Excel or CSV is a core requirement for reconciliation, spend analysis, and feeding data into accounting systems. Three main approaches cover the range of workflows, from enterprise automation to ad-hoc analysis.

ERP and Banking Software Import

Most enterprise ERPs, treasury systems, and banking modules can import MT940 and CAMT.053 directly once bank-specific fields are mapped to the system's internal data model. Platform-specific workflows still vary: Austrian teams using BMD may need format-specific import setup, while Swiss and DACH teams often depend on Banana Accounting camt.053 workflows or PostFinance exports. For organizations already running these systems, direct import avoids intermediate spreadsheets and keeps the audit trail inside the system of record.

Dedicated Converter Tools

Standalone applications and online services parse MT940 or CAMT.053 files and produce Excel or CSV output. These are practical for ad-hoc analysis, one-off conversions, or situations where the target system lacks direct import support. A finance team running a quarterly vendor spend review, for example, may need transaction data in a spreadsheet rather than locked inside an ERP module.

Key considerations when evaluating converter tools:

Tag 86 handling varies significantly. Some tools treat the entire remittance information block as a single text field; others parse structured subfields (EREF, KREF, SVWZ) into separate columns. If you need clean reference data for matching, verify how the tool handles your bank's Tag 86 format before committing.
CAMT.053 version differences matter. Tools built for camt.053.001.02 may not correctly parse camt.053.001.08 schemas, or may ignore elements introduced in later versions. Confirm version compatibility with your bank's output.
MT940 to Excel and MT940 to CSV conversions are straightforward in structure, but bank-specific field variations can produce unexpected results if the tool assumes a generic format.

Custom Parsing

MT940 is a text-based format that can be parsed line by line following the tag structure covered earlier in this article. CAMT.053 is standard XML, parseable with any XML library in Python, Java, Node.js, or similar languages. Custom parsing is the right choice for automated pipelines, API-driven workflows, or when handling bank-specific variations that off-the-shelf tools do not support.

For CAMT.053 to Excel conversion, XML parsing libraries let you walk the document tree and extract exactly the elements you need. Namespace handling is the main technical consideration, since CAMT.053 files declare ISO 20022 namespaces that must be addressed in XPath queries or element lookups.

For MT940, the tag-based structure means parsing logic needs to handle multiline fields (Tag 86 regularly spans multiple lines) and conditional tags that may or may not appear depending on the bank. Teams building integrations across multiple banking partners typically maintain a configuration layer that maps each bank's specific field conventions.

Organizations scaling this work across many banking relationships or building production-grade integrations can benefit from extracting bank statement data via API, which offloads the parsing complexity entirely.

When Banks Deliver PDF Statements Instead

Not every bank statement arrives as a structured MT940 or CAMT.053 file. Many banks provide PDF bank statements alongside electronic formats, and some smaller banks, international branches, or non-European banking partners deliver only PDF statements. In these cases, the transaction data you need for analyzing bank statement transactions for accounting is locked inside an unstructured document rather than available in a parseable format.

AI-powered document extraction handles this gap. Rather than manually keying transactions from a PDF into a spreadsheet, tools like Invoice Data Extraction pull the same core data from PDF bank statements, whether native PDFs or scanned images, into structured Excel, CSV, or JSON output.

Whether your banks deliver MT940, CAMT.053, or PDF statements, you can extract bank statement data into Excel automatically and feed consistent, structured data into your reconciliation and analysis workflows.

Managing the Transition from MT940 to CAMT.053

The shift from MT940 to CAMT.053 varies by country, bank, and message type. Swift's November 2025 cross-border milestone did not create a single bank-to-corporate statement deadline, so multi-bank organizations may receive MT940 from some banks and CAMT.053 from others for an extended period.

Why the Timeline Varies

The timeline varies because bank-to-corporate reporting is shaped by Swift infrastructure, SEPA messaging rules, domestic banking standards, and each bank's own customer migration plan. German banks have moved earlier than many markets, but format retirement still needs to be tracked bank by bank.

A Practical Dual-Format Handling Approach

Managing the coexistence period well comes down to four steps:

Inventory each bank's migration status. Record whether the bank has moved to CAMT.053, still offers both formats, or has announced an MT940 cutoff date.
Verify format support in receiving systems. Confirm that each ERP, TMS, middleware layer, or bank-feed component can ingest CAMT.053 alongside MT940.
Normalize both formats into one model. Map MT940 tags and CAMT.053 XML elements into a shared structure for reconciliation, reporting, and downstream consumption. The mapping table above provides the field-level correspondence.
Prioritize CAMT.053 parsing for custom integrations. If you maintain bank-statement parsing code, build new functionality against CAMT.053 first and keep MT940 support as a coexistence layer.

During coexistence, the safest approach is to normalize MT940 and CAMT.053 into one internal bank-statement model, then let downstream reconciliation and reporting use that model.