What the ECB’s TARGET delay actually changes for T2

It’s been an interesting few weeks for central banks and regulators. Swift’s announcement in late August of a controlled extension of Standards Release 2026 (SR2026) sent a few ripples across the industry. The deferral undoubtedly gives banks more time to ensure their systems are ready for structured addresses, but it’s impacted other releases timed to coincide with Swift’s.  

That includes the ECB’s TARGET releases. The Eurosystem confirmed that the scheduled November 2026 releases (also known as R2026.NOV) for T2, T2S, TIPS and ECMS will proceed, but instead of deploying on 14 November, it will happen on 28 November.  

For banks, the headline isn’t the two-week delay. It’s the T2 measures that allow fully unstructured addresses to continue in RTGS messages and send through application-to-application (A2A) messages. They’re designed to ensure smooth cross-border payments while the wider industry works towards structured and hybrid addresses.  

But what does this mean for T2 participants day-to-day?  

What you need to know

While T2’s structured and hybrid address requirements have been postponed, the remaining CRs (from R2026.NOV) are going ahead. This means user testing for parties connecting through A2A ISO 20022 messages (such as pacs.008) is still expected to begin on 9 October 2026.  

For banks that accept structured, hybrid and unstructured addresses, not much will change. Existing downstream controls will stay as they are. However, this won’t restore the business-validation controls that were removed in a previous T2 change. T2 will still allow messages through that don’t follow the recommended format, they just won’t be flagged as an error anymore. The banks that have already configured their systems to reject unstructured addresses will need to act. They need to check that the old format will still make it through during this transition.  

Structured and hybrid addresses is still the end point. But currently, T2 participants are expected to continue to work on implementing them, while temporarily still being able to receive unstructured addresses.  

The T2 changes in detail

The Eurosystem is reintroducing a ‘grace-period’ guidance within MyStandards. This means that Town Name and Country become optional fields and the number of free-text Address Line fields increases from two to three. These changes apply to six messaging types: pacs.004, pacs.008, pacs.009, pacs.010, camt.029 and camt.056.  

There are no changes for hybrid addresses. They still need Town Name and Country, and the address should have no more than two Address Lines. 

These updated requirements are now guidance rather than enforced validation. As a result, T2 may accept and process certain address combinations that would previously have been rejected or reported as validation errors. 

In practice, this means T2 won’t be checking address quality as messages arrive. Banks still using SR2025-era handling should have no issues. What you’ll need to verify is whether sanctions screening, fraud monitoring, investigation workflows, repair processes and regulatory reporting still behave as expected on fully unstructured data, and whether anything has been decommissioned on the assumption that T2 would reject it.  

That check needs to start further upstream than T2. The relaxed address requirements cover A2A processing at the T2 gateway itself. What they don’t cover is the channels a bank uses to originate a payment before it ever reaches T2. Many institutions, preparing for the original mandate, built creditor-address validation into those channels directly. Those validations reject outgoing pacs.008 and pacs.009 instructions with incomplete addresses ahead of T2 ever enforcing it.  

That control is now stricter than the rail it feeds and will keep blocking payments T2 would happily process and forward. You can relax it, hold it as a standing data-quality rule, or timebox it to the grace period — but it should be a decision you take, not an oversight. The same question applies to debtor and agent addresses, not creditor alone. 

Testing data downstream

Just because a message is technically valid, it doesn’t mean it follows the address rules correctly.  

Here’s why: once Town Name and Country are no longer required fields in the schema, and the grace period rules are not being automatically checked, messages with blank or incorrect fields can still pass validation. Nothing in the system is enforcing the postal address standards anymore. 

This doesn’t mean banks need to build new systems, it just changes where the quality check happens. The A2A access channel would normally catch bad address data, but, with these temporary changes, it can’t do that job anymore. Banks that didn’t already reject unstructured addresses should be fine – your downstream checks will likely still catch it. But it’s worth testing.  

You should be checking incomplete or inconsistent data behaves once it hits sanctions screening, name-and-address matching, transaction monitoring, repair queues and audit reporting. It’s not enough to just ask “did this message go through?” You also need to know whether the payment can be processed safely, investigated consistently, and handled correctly.  

The A2A and U2A split

The T2 change is deliberately limited to A2A. That’s so it can be delivered to the user testing environment (UTEST) from 9 October. There’s no corresponding U2A or GUI change included.  

From November, the RTGS GUI (U2A, where payments are entered or repaired manually) will only accept structured or hybrid postal addresses, in line with the T2 User Detailed Functional Specifications (the document that sets out how the GUI handles addresses). 

This creates a mismatch between what the automated channel can accept and the manual channel can fix.  

A payment received through A2A may contain an address format that cannot be repaired or re-entered through the GUI in the same form. So banks whose exception processes depend on U2A need to test that path explicitly, including hand-offs, repair decisions and fallback arrangements. 

The ECB’s confirmed TARGET changes

What banks should do now

• Keep 9 October protected. Confirm test entry criteria and dependencies on the October UTEST delivery.
• Use the final technical documents. Check and recheck your systems and plans line up against the SDD (system design document), Swift’s MyStandards collections and the binding technical schema files (XSDs) for the November release.  
• Trace every XSD dependency. Confirm the version and activation date expected by internal applications, network providers and vendor platforms. 
• Test messy data. Include incomplete structured data, three address lines and hybrid combinations that may pass the schema but still break address formatting rules.  
• Test across the full chain. Take scenarios beyond parsing into screening, monitoring, repair, investigation and reporting. 
• Validate the A2A/U2A hand-off. Confirm what happens when an A2A payment cannot be represented in the RTGS GUI for repair or re-entry. 
• Prepare for day one. The ECB has flagged risks in T2’s Data Warehouse processing on day one. Make sure you have a backup plan for any reports relying on that data.  
• Don’t lose momentum. Keep cleaning customer data and rolling out structured or hybrid formats. These changes are a temporary fix to keep payments moving, not the end game.

Questions for system owners and vendors

You should be asking whether they know how to handle the new message format for the November release, and will each be activated in time for 28 November? Just as important, can your screening, fraud-monitoring and repair systems still process fully unstructured addresses without any data loss?

There are practical edge cases to work through as well. What is the process for handling a payment containing an address that the GUI can’t re-enter or fix manually in the system? And which address formatting rules recommended by MyStandards will be enforced, monitored or reported by the bank rather than T2?

Finally, you should be across preparation and governance. What testing is planned to catch the known glitches in payment processing and reporting? And how are T2 RTGS, TIPS and SEPA scheme decisions separated in your implementation plan?

Extra vigilance is needed

Swift’s SR2026 delay has given the industry extra time, but a more complicated control environment. The November TARGET release is slightly delayed but still going ahead. So, you need to be ready to start testing in October. The temporary T2 measures mean a message can now get through T2 even if it doesn’t meet the recommended address-formatting standards. 

Payments leaders need to actively manage the gap between a message that works and one with address data that meets the requirements. Someone specific needs to own the process and be able to prove how you’re handling non-compliant addresses (end-to-end). It’s also key that you track each scheme – T2, TIPS/SEPA and EBA –  separately rather than in a single bucket.  

The institutions best prepared for 28 November will be the ones who can safely handle messy, transitional data right now, while still moving their customers and systems towards fully structured addresses. 

Where RedCompass Labs can help

This grace period exists because fixing address data is hard. Banks don’t have enough time or people to test every case before it matters. 

If your team is stretched thin, our Payments Expert Agent can help. It brings over two decades of payments experience to your project, so you can test and fix issues faster and more cheaply. 

See what’s possible with Payments Expert Agent.

Note: The use of A2A in this article is SWIFT/T2 terminology for application-to-application messaging, not account-to-account (the term’s more common meaning in retail and open-banking payments).