Structured address data in payment transactions
The ongoing introduction of the ISO 20022 standard is bringing significant changes to international and urgent payments.
A key change concerns the mandatory use of structured or hybrid address data in payment instructions whenever an address is provided. Proactive modifications to your ERP and TMS systems are required to support efficient and compliant payment processing as market practices evolve.
Which payment instruments are affected?
The following cases require the provision of address information comprising, at a minimum, the town name and ISO country code:
- International payments (for the beneficiary, the ultimate payer and the ultimate beneficiary and the agents along with the local clearing code if no BIC is provided)
- SEPA direct debits, where payer address information is mandatory if part of the transaction occurs outside the EU/EEA. For ultimate payer and ultimate beneficiary, address information is not permitted.
Attention: Countries/regions (jurisdictions) may define deviating regulations for domestic transactions, e.g. addresses are not required in United Kingdom for domestic credit transfers and direct debits; addresses are not required for urgent payments within EU/EEA in EU/EEA currency; addresses are not required for SEPA direct debits within EU/EEA nor SEPA credit transfers.
Deutsche Bank applies the orderer’s name and, if required, address from customer master data to provide them in the outbound clearing message.
Rule: Once a postal address is provided, town name and ISO country code must be included in dedicated elements. This rule is valid for international payments across the globe, all SEPA transactions, and those urgent domestic payments where the payment market infrastructure follows the ISO postal address requirements, e.g. T2, CHAPS for UK, SIX for Switzerland.
Most domestic non-urgent payments don’t require structured or hybrid postal address data.
Why are structured addresses important?
ISO pain messages (versions 03 and 09) contain dedicated data elements (XML fields) such as street name, building number, floor, postal code, town name and country. The adoption of structured address data supports improved data quality, enhanced automation, and compliance with applicable regulatory requirements, including those related to the prevention of financial crime.
In addition to the mandatory town name and country, we strongly recommend including the postal code (if available) and additional address details such as street name and building number, each in its designated element. To support accurate identification of all parties involved in a payment, which is relevant for customer due diligence and transaction monitoring processes, address information should be provided in dedicated elements whenever possible. Whilst unstructured beneficiary addresses (i.e., using only address lines) are still accepted until November 2026, clients are therefore encouraged to migrate to structured or hybrid formats well in advance of this deadline.
Which pain versions are subject to these requirements?
- From 14 November 2026, in line with current market timelines, addresses for payments are expected to be provided in a hybrid or structured format rather than solely as unstructured address lines.
- Since November 2025, international and urgent payments involving an ultimate payer or ultimate beneficiary (i.e., 'on behalf of' payments) have required addresses to be submitted in structured or hybrid format.#
What address options are available?
Address Option 1 – Structured address
By providing the address information exclusively in the dedicated XML elements, the fully structured address format offers the highest level of detail. For example, the building number should be put in a separate data element to avoid potential future payment rejections. In this fully structured option, no address line is included.
The use of fully structured address information may reduce the likelihood of payment interventions during transaction or sanctions screening processes, thereby supporting more efficient processing.
Address Option 2 – Hybrid address
If you cannot provide part of the address information in dedicated XML elements (e.g., separating street name and building number), this information may be provided in a maximum of two address lines. This hybrid address option combines unstructured and structured address data in a pragmatic manner. Town and country are mandatory dedicated data elements and should not be repeated in the address lines if already provided.
What actions need to be taken?
We recommend prioritising the following actions to ensure a smooth transition:
- Begin with a comprehensive review and revision of your address master data and the process by which your business partners’ address data is stored in your systems.
- Ensure that, from the outset, the fully structured or hybrid structure is applied when providing an address, including the mandatory data elements town name and country. This applies to the payer, the beneficiary, as well as any ultimate payer or ultimate beneficiary.
How does Deutsche Bank support clients?
Both the fully structured and hybrid address options are supported in pain.001 messages versions 03 and 09, as well as pain.008 messages versions 02 and 08. Where beneficiary address information does not meet applicable clearing requirements, Deutsche Bank may apply adjustments solely to support onward payment processing, subject to market constraints.
With respect to address details of the ultimate payer or ultimate beneficiary, town name and country must already be provided in dedicated data elements. Deutsche Bank will accept address data without rejecting payments on this basis.
In case of agents, if BIC is provided then address data validation (town name and country code) is not performed.
However, the transmission of all address elements to the recipient bank may depend on downstream processing capabilities within the wider payment chain as part of the ISO 20022 migration.
Important details on data processing in the payment process
- Currently, the semantic consistency of address data elements (for example, whether the town name corresponds to the provided country), is not systematically validated as part of payment processing.
- For smooth payment processing, the town name should be in English or the recipient country's language using Latin characters.
- The name and address of the payer are supplemented from Deutsche Bank’s master data. For the beneficiary bank or correspondent bank, it is advisable to use the SWIFT BIC. If this is not available and the local clearing code is applied, then the bank name and bank address (town name and country) must be provided.
Reference to format specifications
The address requirements described above are defined in the relevant format specifications available in SWIFT MyStandards for payment instruments under the CGI-MP standard and in Specification on Data Formats (Annex 3 of the DFÜ Agreement) – EBICS for the DK standard. Format tests conducted via SWIFT MyStandards for CGI-MP standard will verify that town name and country are provided, in preparation for future validations. for the DK standard. Format tests conducted via SWIFT MyStandards for CGI-MP standard will verify that town name and country are provided, in preparation for future validations.
Camt.05X messages are part of the ISO 20022 standard for bank-to-corporates financial messaging. They provide detailed account information, helping businesses and financial institutions reconcile transactions efficiently. This message standard is commonly used in corporate banking for cash and liquidity management.
The account information camt.05X message set includes three different message types, with each serving distinct financial reporting needs. Combined, these messages enable efficient cash flow monitoring, transaction tracking and financial control across treasury operations.
How do the different camt messages differ from each other?
CAMT.053 is an end of day account statement which provides a detailed overview of account transactions for a particular booking day after business day closure. It enables businesses to reconcile transactions that happened throughout the day and helps with effective treasury management. It is a replacement for MT940 (End of day account statement).
Key benefits:
- End of day summary with detailed transaction information
- Supports daily reconciliation in ERP and TMS for better cash management
- Useful for corporates to analyze cash flow and track financial performance
CAMT.052 is an intraday account report which provides intraday updates on account transactions once they are booked. It enables businesses to monitor cash movements throughout the day and helps manage liquidity effectively. It is a replacement for MT942 (interim transaction report).
Key benefits:
- Provides intraday visibility into cash flows
- Supports corporate treasury operations for better cash management
- Useful for corporates with high transaction volumes needing frequent updates
CAMT.054 is a transaction level report which provides overview on Bulk booking transactions (batch payments) and R-transactions (return, rejects, refunds) for a particular booking day after business day closure. It enables businesses to reconcile credit and debit advices, batch bookings and return transactions that happened throughout the day and helps with effective treasury management.
Key benefits:
- End of day summary with detailed information on batches and returns
- Supports daily reconciliation in ERP and TMS for better cash management
- Useful for corporates to analyze cash flow and track financial performance.
The cash management messages listed above are provided via the following Deutsche Bank channels:
| Format | Channels available |
|---|---|
| camt.052 (Intraday account report) | EBICS, Host-to-Host, SWIFT Fileact, Cash Manager, API |
| camt.053 (End of day account statement) | EBICS, Host-to-Host, SWIFT Fileact, Cash Manager, API |
| camt.054 (Debit/credit advice, Bulk and return reports) | EBICS, Host-to-Host, SWIFT Fileact, Cash Manager, API |
What are the general differences between MT940 and ISO cam.053 messages?
| Description | MT940 | camt.053 V08 |
|---|---|---|
| Message structure | Flat text-based format with fixed tagged fields | ISO 20022 XML uses structured XML elements with clear definitions |
| Field length | Restricted character length, often truncated details | Larger field sizes due to the structured nature of the data elements |
| Data richness | Limited multilanguage support and limited reference fields | Supports Unicode, multiple languages, and extended remittance data. Full standardized references such as E2E ID, Transaction ID etc. |
| Bulk booking details | Bulk booking details are not supported | Bulk booking details are supported and can also be reported in a separate camt.054 message |
| Bank Transaction Code | Only GVO and SWIFT codes are supported | ISO Bank Transaction Codes (Domain/Family/SubFamily), SWIFT and GVO codes are supported. Provides more granularity |
What are the changes clients will be faced with during the migration?
With the transition to ISO 20022 and camt-based account statements, you will notice several important enhancements and adjustments designed to improve your daily processes:
- Richer transaction details. camt statements provide extended remittance information and structured data elements, giving you a complete picture of every transaction. This means fewer follow-up queries and faster identification of incoming and outgoing payments.
- Larger file sizes. camt.05x messages contain significantly more data than legacy MT formats, which means file sizes will be larger. This is a natural result of the enhanced detail and structure.
- Separate bulk booking reports. Bulk booking details can be provided in a camt.053 message or in a separate camt.054 message –a feature not possible with MT messages –offering clearer segregation of bulk transactions.
- Enhanced reference and transaction codes. camt.05x messages include additional reference details and bank transaction codes, giving you more flexibility and precision in your reconciliation processes
What are the benefits of an account statement based on ISO message format?
- The financial world is moving toward greater transparency, efficiency, and automation – and ISO 20022 is at the heart of this transformation.
- Improved reconciliation. With standardised and structured fields, camt messages simplify automated matching in your ERP or treasury systems. This reduces manual intervention, minimizes errors, and accelerates your reconciliation process.
- Regulatory readiness and futureproofing. ISO 20022 is the global standard for financial messaging. Migrating now ensures compliance with evolving regulatory requirements and positions your business for future innovations in payments and reporting.
- Multi-language and multi-currency support. Camt messages are designed for global business. They seamlessly handle multiple languages and currencies, making them ideal for multinational corporations and cross-border operations.
- Reduced ambiguity. Every data element in a camt message is clearly defined through XML tags. This eliminates interpretation issues common in legacy formats and ensures consistent processing across systems and geographies.
What do you need do to start your migration to ISO 20022 CAMT messages?
- Migrating from MT940 to camt.053 V08 is more than a format change – it’s an opportunity to enhance reconciliation, data richness, and compliance. Here’s how to get started:
- Review system capabilities. Ensure your ERP or TMS can parse ISO 20022 XML and supports Unicode. This is essential for handling structured data and multi-language content.
- Update technical Integration and review capabilities. Adjust your mapping from MT940 tags to camt.053 XML elements. This step ensures seamless data flow between the technical systems and your bank.
- Test and validate. Run MT940 and camt.053 in parallel during a coexistence phase to confirm accuracy and consistency. Use SWIFT MyStandards guidelines and sample messages for format testing.
Please prepare your transition by testing, in coordination with treasury, IT, your banking partners and TMS Service providers. This will assist and lead to a smooth ISO migration.
The format guidelines for the different message types as well as the sample files are available on Swift MyStandards via dbAutobahn. Please ask your service contact at Deutsche Bank if you need further details. If you need more time for your individual analyses and preparation of your IT system for future processing, please request a coexistence phase of MT and camt message to take your time to decide about individual ISO migration path.
At Deutsche Bank, we recognise that the transition to ISO 20022 is not merely a regulatory requirement — it is a strategic opportunity to optimise your payment processes, unlock richer data insights, and drive operational efficiency. As your trusted partner, we are committed to supporting you throughout this journey with tailored testing solutions that meet your specific needs. This document outlines the available testing paths, helping you identify the most suitable approach for your organisation. The below table shows an overview of which payments and standards are available for each test path:
What testing options are available?
| Your payment format | Test path |
|---|---|
|
Option 1: SEPA DK Standard Schema (+ CCU/AXZ): |
Format checker |
|
Option 2: SEPA DK Standard Schema (+ CCU/AXZ): |
directMC |
|
Option 3: CGI-MP standard for all payment and direct debit types: |
Swift MyStandards Swift MyStandards |
|
Option 4: SCORE+ Standard for International Payments |
Swift Sparrings Partner (via Swift Login) |
Test path 1: German DK payment processing
For clients using German DK (Deutsche Kreditwirtschaft) formats, Deutsche Bank offers a dedicated validation service to ensure smooth integration with ISO 20022 standards. Our Format Checker tool enables quick and easy validation of test files generated from your ERP or TMS systems. It checks compliance with both the XSD schema and Deutsche Bank’s implementation guidelines, providing immediate feedback.
If you are not yet registered for Format Checker (formatpruefer.de) and wish to use this service, please contact your Deutsche Bank service manager.
Test path 2: directMC – SEPA test file validation
If you are a directMC user, you can leverage the built-in validation functionality via your EBICS channel. Simply import your payment file offline and delete it without transmitting it to the Bank. This allows for seamless validation within your existing workflow, with immediate feedback based on XSD schema and functional checks.
Test path 3: Swift MyStandards testing
Clients with access to Deutsche Bank Autobahn can use Swift MyStandards for self-service testing. This platform supports Deutsche Bank’s XML usage guidelines in line with the CGI-MP standard. Upload your test files via the portal to receive instant validation results, including XSD schema checks and most Deutsche Bank-specific business rules. For access to dbAutobahn, please reach out to your customer service manager.
Swift Corporates can also use format testing capability on the Swift MyStandards website for SCORE+ pain.001 v9. Upload your test files via the portal to receive instant validation results, including XSD schema checks and business rules. You can easily request access to the tool on the website.
Test path 4: Swift Test Sparring Partner (TSP) for SCORE+
The Swift Test Sparring Partner (TSP) is an advanced simulation platform that enables corporates to test Swift payment flows, including the new SCORE+ pain.001 messages over FINplus. The platform simulates settlement and creditor agents, allowing you to send test messages to dummy BICs and receive pain.002 responses—independent of any bank’s test or production environment.
Swift TSP supports:
- Format validation for SCORE+ usage guidelines
- Network connectivity checks to FINplus
- Receipt of pain.002
- if applicable, trck.004 messages for GPI tracking
To use this service, you must have a valid swift.com account and access to the TSP portal. For more information, please refer to the Online Portal.
How do you protect your data?
To ensure a secure and successful migration, it is essential to use only test data during validation. Protecting your production data remains our highest priority.
Testing Recommendations:
Use valid test IBANs to avoid validation errors
Anonymise debtor and creditor data, especially when testing address changes
When changing address data, make sure the information is realistic but not personally identifiable
Your partner in your ISO 20022 migration
Deutsche Bank is here to guide you through every step of the ISO 20022 transition. For expert advice and tailored support, please contact your Deutsche Bank representative. Together, we can unlock the full potential of ISO 20022 and shape a more efficient, innovative, and secure future for your payment operations.
Disclaimer
This factsheet is for information purposes only and is designed to serve as a general overview regarding the services of Deutsche Bank AG, any of its branches and affiliates. The general description in this factsheet) relates to services offered by Corporate Bank of Deutsche Bank AG, any of its branches and affiliates to customers as of July 2026, which may be subject to change in the future. This information is provided solely as a neutral description of operational capability and is not a recommendation or marketing of any booking location or structure. Cash management accounts are generally available to locally established or resident entities and, within the EEA, to entities established in other EEA jurisdictions. Non-resident accounts for clients outside the relevant jurisdiction (including outside the EEA) are restricted and will only be provided where independently and exclusively initiated by the client, without any prior or contemporaneous marketing, promotion, or solicitation by the Bank or its affiliates, and subject to applicable legal and regulatory requirements. This factsheet and the general description of the services are in their nature only illustrative, do neither explicitly nor implicitly make an offer and therefore do not contain or cannot result in any contractual or non-contractual obligation or liability of Deutsche Bank AG, any of its branches or affiliates. Deutsche Bank AG is authorised and regulated by the European Central Bank and the German Federal Financial Supervisory Authority (BaFin). With respect to activities undertaken in the UK, Deutsche Bank is authorised by the Prudential Regulation Authority. It is subject to regulation by the Financial Conduct Authority and limited regulation by the Prudential Regulation Authority. Details about the extent of Deutsche Bank AG’s authorisation and regulation by the Prudential Regulation Authority are available from Deutsche Bank AG on request.
Copyright© (July 2026) Deutsche Bank AG. All rights reserved.