Hero background

SR 2026 deadlines have split. Here’s what PMPG advises

Why a payment that clears one system can fail at the next – and what to do about it

6 min read

There’s a split in the payments industry. Ever since Swift revised its SR 2026 timeline, different parts of the payments ecosystem are working towards different deadlines. Some now have more time. Other Payment Market Infrastructures (PMIs) are expected to stick to the original deadline.  

Most of the conversation so far has centered on postal addresses. But SR 2026 changes more than how an address is formatted. It also affects the supporting data that accompanies a payment, such as proxy types, creditor references, scheme names, and branch identification.

These fields can look like small details. But when systems operate on different timelines and rules, they can decide whether a payment arrives or gets rejected along the way.

The target state and responsibility to deliver it haven’t changed. When everyone gets there has.  

Here’s what’s happened

The Payments Market Practice Group (PMPG), the independent global body supporting ISO 20022 adoption, recently published guidance on handling these diverging timelines. Its message is that the extra time only creates value if banks use it to improve readiness. The longer runway shouldn’t slow your momentum. The PMPG’s advice is to recalibrate your priorities.  

With multiple implementation timelines and requirements in play, institutions need to identify and address any points along a payment’s journey where one system’s rules don’t align with another’s. In practice, this could result in a payment leaving the sender looking perfectly valid, only to be rejected before it arrives. The only thing that changed was the destination’s rulebook. 

This article looks at what happens when the correct payment data is missing and who’s responsible for fixing it.  

One payment, two outcomes

Picture a credit transfer to a beneficiary in Germany. The debtor paid using the beneficiary’s mobile number as a proxy and attached a structured creditor reference to the remittance. The destination requires two things: a Proxy Type (CR 003012) wherever a proxy is used, and a Reference (CR 000068) wherever Creditor Reference Information is used. The PMPG flags both as supporting data elements that some PMIs may require.

How to understand these examples

The snippets below are fragments of an ISO 20022 message. Here’s what each label signifies.

LabelWhat it stands forWhat it does in this scenario
<Prxy> Proxy A stand-in used to identify an account, such as a mobile number 
<Tp>TypeProvides identification of the proxy type 
<Cd>Code A value from an official ISO list, such as TELE or SCOR 
<Prtry>ProprietaryName of Identification scheme given by the customer. This is where NOTPROVIDED would go if missing 
<Id>IdentificationThe identifier itself, such as a phone number 
<CdtrRefInf>Creditor Reference InformationThe block carrying the reference used by a beneficiary to match a payment to the invoice
<CdOrPrtry> Code or Proprietary A wrapper holding either an official code or a custom value
<Ref>ReferenceThe reference itself

Outcome 1: The Debtor Agent gets it right

The proxy carries its type. The creditor reference carries the actual reference. The payment passes through untouched. No placeholder, no repair, no delay.

The proxy is a telephone number, and it says so within the message. The reference block contains both its type and the reference itself.  

Outcome 2: The data arrives incomplete

The proxy has no type, and the creditor reference block has a type but no reference:

The number is there in the proxy, but the identifier doesn’t say what it is, and the reference block is empty. 

A payment missing a tag can clear CBPR+ (Cross-Border Payments and Reporting Plus) validation but still be rejected once it reaches a PMI that’s applying HVPS+ (High-Value Payments System) rules. After it arrives, the intermediary agent now has three options: send it on and risk rejection, raise a Request for Information and delay the payment, or apply a fallback. The PMPG recommends fallbacks for exactly this case, and only when the destination agent cannot supplement the data. 

What each fix really costs

A proxy fix will ensure the payment gets through, but describes nothing. A proxy fix lets the payment proceed if the destination PMI accepts it, but describes nothing. In this scenario, the PMPG default is NOTPROVIDED in Proxy Type/Proprietary: 

Downstream systems still cannot determine whether the identifier is a phone number, an email address, or something else; the value should be replaced through source remediation. 

In the case of the creditor reference fix, the structure remains, but not the meaning. Here, the intermediary retains the structured block and populates Reference with NOTPROVIDED: 

The block now validates, but the beneficiary cannot use it to reconcile the payment. The PMPG’s guidance is explicit in this: the fallback does not create a genuine creditor reference, and NOTPROVIDED must not be read as one. 

Sometimes the fallback can’t be used at all. The PMPG recognizes that some institutions can’t modify remittance information because of internal audit, compliance, operational, or system constraints. Where that applies, the intermediary agent follows its established repair, Request for Information, or exception-handling process. The fallback is a recommendation, not an obligation. 

Four considerations for managing interoperability

  1. Placeholders aren’t a long-term fix: They don’t improve underlying data quality and shouldn’t be treated as a permanent solution. Use the extra time to fix your data at source and collect meaningful structured information.  
  2. The original deadline is still relevant: Some PMIs are expected to continue with their planned implementations, so different parts of the ecosystem will be working to different timelines, and potentially different requirements.  
  3. Look beyond postal addresses: Good ISO 20022 data depends on many other supporting fields. You should consider the implications for related migration activities, including exceptions and investigations (E&I), payment initiation migration, and associated FINplus adoption milestones.  
  4. Check your testing and client communications against each system you support: The CBPR+ timeline has been revised, but some PMIs are still moving ahead with HVPS+ UG2026-aligned activity, so a payment that meets one system’s requirements may fail another’s. 

The full set of PMPG fallbacks

ElementWhat the PMPG says Fallback
Proxy Type (CR 003012) May be required where a Proxy Identifier is used Use NOTPROVIDED in Proprietary  
Creditor Reference (CR 000068) The associated Reference may become mandatory Keep the structured block and populate Reference with NOTPROVIDED 
Scheme Name (CR 003031) May be required where Other Identification is used, limited to ISO External Code List values Default to CUST (CustomerNumber) 
Branch Identification (CR 000042) Removed by SR 2026 in favor of more consistent identification Remove it and, where supported, carry the value as received in InstructionForCreditorAgent 
Instructed Amount (CR 003013) Some PMIs may mandate it across the payment and return chain (pacs.008, pacs.009COV, pacs.004) Use the received Interbank Settlement Amount and currency 
Unstructured postal address The transition from fully unstructured to hybrid and structured addresses Structured Town Name and Country only where they can be reliably identified, and keep the rest in AddressLine 

Who needs to do what

Debtor agents

This is your job. Populate what the destination needs at source. Every fallback an intermediary applies is a gap between what you sent and what the destination requires.

Intermediary agents

You may apply these fallbacks, but they are optional, subject to destination acceptance and your own risk appetite. If you cannot modify the data, use your established repair or exception process.

Everyone

Track fallback volumes by sending institution, send the pattern back as a remediation request, and retire each fallback as data quality improves.

Where we can help

If you need help finding where your payments may fall short of different systems’ rules, Payments Expert Agent can help. Our AI solution puts over two decades of expertise inside your project. It can help you identify data gaps, fix them at the source, and test against each system you support in a fraction of the time and cost.

Meet the Agent here.

 

You may also like

Let's work together