ISO 20022

In many organizations, the transition to ISO 20022 in cash reporting was viewed as a purely technical requirement. In practice, however, it has become clear that the shift has changed far more than just the message format.

Cash reporting – meaning the provision and analysis of account information such as account balances and account statements – is undergoing a fundamental transformation as a result of the introduction of the ISO 20022 standard. The previous MT formats under the SWIFT FIN standard were based on text‑based messages with fixed tags and limited field lengths. Many details were transmitted in free‑text fields, which made automated processing difficult and often required additional interpretation logic in treasury systems.

With ISO 20022, a modern XML‑based standard has been introduced that structures data clearly and can transmit significantly more information using standardized elements. In cash reporting, this development is most evident in the camt formats, such as camt.053 for electronic account statements, which provide bank information in a much more detailed and structured manner.

Over the past two years, we have supported dozens of migrations from MT940/MT942 to camt.053/camt.052 across various industries. Although the starting point was comparable, the complexity and impact of these projects differed significantly due to client‑specific requirements, the diversity of system interfaces and the different ways information is processed.

Replacing the MT940 and MT942 formats with camt.053 and camt.052 has structurally transformed cash reporting. What initially appeared to be a simple format change proved, during implementation, to be a comprehensive data and process project affecting treasury systems, downstream workflows and collaboration with banking partners.

The key difference between MT and camt lies not only in the technical format but in the underlying data model. Whereas MT formats were highly text‑based and conveyed many details within a few freely usable fields, camt formats require information to be assigned to clearly defined XML elements. Details that were previously consolidated in the remittance information are now distributed across multiple fields, such as counterparty data, references and booking types. This structure provides a foundation for automation and more granular analytics, yet it also demands more precise processing within the treasury system.

Although camt.053 and camt.052 are based on the same ISO 20022 specification, practical experience has shown that banks implement the standard in different ways. The reason lies in the structure of the standard itself.

ISO 20022 defines a structured, XML‑based data model with significantly higher granularity than the earlier MT formats (see Exhibit 1). 

Exhibit 1: Comparison of free‑text fields in MT940 with structured data fields and predefined population rules in camt.053
Source: KPMG in Germany, 2026

The standard provides numerous clearly defined data fields, for example for structured end‑to‑end references, separate fee information or detailed counterparty data. At the same time, however, the specification contains optional elements and allows flexibility in usage. This means that banks are not required to populate every available field or interpret elements in the exact same way, as long as they remain compliant with the standard.

In practice, this has resulted in varying levels of detail in camt files. Some banks, for example, consistently provide structured end‑to‑end references in the designated XML element, while others continue to include this information in combined text fields. The same applies to fees: depending on the bank, fees may be presented as a separate transaction, as a dedicated fee element within the booking entry or simply as textual information.¹

The cutover approach was not uniform either. While some banks set fixed decommissioning dates for MT940/MT942, others allowed for a longer parallel run of MT and camt formats. For treasury organizations, this meant that account statements had to be processed differently depending on the bank and country. In practice, treasury systems often had to handle both MT and camt formats for a period of time, including adjusted reporting and reconciliation processes.

Moreover, the changes had an immediate impact on downstream processes. Adjustments in cash reporting directly affected reconciliation mechanisms, internal reports and interfaces to ERP systems.

On the client side, approaches to the migration varied as well. Treasury organizations that tested the camt formats in parallel with MT at an early stage were able to identify deviations in data structures in time and prepare their downstream systems (ERP) accordingly. In these cases, camt files were first analyzed in the test environment before being used productively for cash reporting or reconciliation.

Reactive approaches, by contrast, often focused initially on the technical ability to import the files into the treasury system. As long as camt files were processed without error messages and account balances were displayed correctly, the migration was considered “successful.” Only during ongoing operations did it become apparent that existing cash‑reporting logic or specific reconciliation rules no longer worked as expected.

For example, many existing reconciliation rules were based on specific text patterns in the MT940 remittance information. 

Exhibit 2: Comparison of the “Invoice” field population in MT940 and camt.053
Source: KPMG in Germany, 2026

When this information was provided in the camt format in a structured way across separate XML fields – for example as <EndToEndId> or within <RmtInf> – the existing rules no longer worked reliably. In other cases, fees were no longer delivered as separate booking lines but were referenced within a single transaction. This changed the logic used to determine net amounts or to allocate bank fees.

Close coordination between Treasury, IT and Accounting was particularly important in this context. camt data is not used exclusively within the treasury system but is often passed on to ERP systems or used for booking automation. Changes in the data structure – such as references, counterparty information or booking types – therefore had an immediate impact on automated posting proposals, clearing processes or accounts receivable and payable reconciliations.

In several cases, existing interfaces had to be adjusted because field lengths, field contents or reference logic had changed. In some situations, control and reporting processes also had to be modified, as the new data structure affected aggregation, transaction counts or classification logic.

The migration made one thing very clear: camt affects not only the account‑statement import but the entire data‑processing chain, from the bank feed through the treasury system and all the way into the ERP and the accounting function.

During ongoing operations, clear advantages of the migration also became apparent. The structured data foundation enables significantly greater transparency in cash reporting and improves the basis for automated reconciliation. For treasury organizations with international footprints in particular, the introduction of camt led to more consistent data across banks and countries over the long term.

However, the actual added value depended heavily on how consistently the new data was utilized. Organizations that viewed camt merely as a replacement for MT captured only part of its potential. Where camt data was actively integrated into reporting and reconciliation processes, sustainable efficiency gains became evident.

Across the many migrations we supported over the past two years, certain patterns emerged that were consistent regardless of industry or system landscape. Even though the starting situations differed, the central questions and challenges were remarkably similar.

It became clear that the introduction of camt is not an isolated IT initiative. The new data structure affects processing, reporting and reconciliation and requires close coordination between Treasury, IT and Accounting. The actual benefits only materialize once data logic, mapping rules and process interfaces are clearly defined.

Many projects also showed that the added value does not occur at the technical go‑live. It develops gradually during day‑to‑day operations, through adjustments to reconciliation rules, optimization of reporting structures and the consistent use of structured information.

For many treasury organizations, the migration is formally complete. What remains decisive, however, is the extent to which the new data structures are actively used and integrated into existing processes.

Unlike payment messages, there is no globally uniform end date for processing MT940 or MT942 in cash‑reporting formats. In practice, the migration to camt formats is largely driven by the banks. Many institutions currently offer both formats in parallel, while others have already defined concrete end dates for MT formats. For companies, this means that the need for action depends heavily on the respective banking relationship, the technical connectivity and their own system landscape.

In practice, it is advisable to prepare for the migration early and to test the camt formats in parallel with the existing MT format. Close coordination with the banks and with internal IT is essential in order to identify potential end dates for MT formats at an early stage and to implement the migration in a controlled manner. If this has not yet taken place, it is recommended to proactively contact the relevant banks and clarify the current status of their migration plans.