No pain.001, no gain: What to do before MT 101 ends

For decades the MT 101 “Request for Transfer” has carried out payment initiations. It helps to move money from corporates to banks and from banks to other banks via relay arrangements. 

That era is coming to an end. At least for the interbank leg. It’s giving way to the ISO 20022 equivalent, pain.001, as part of SR 2026 (Standards Release) in November. The switch was originally planned for November 2025, but it was postponed following community consultation. It means we’re in a period of coexistence ending in November 2026. 

That doesn’t apply to every MT 101 though. The changes vary depending on the scenario. If you’re a corporate sending instructions to a bank, that will be different to when a Forwarding agent relays them, or when a Debtor executes one.  

The question is: what does this mean for you?  

Let’s walk through who’s using MT 101, what’s changing in November 2026, and what you need to do now. 

Who sends MT 101 today?

Before talking through the changes, it is worth explaining the two different MT 101 use cases.

1. Corporate-to-bank

Corporates are the most prevalent MT 101 senders. In-house banks (treasury acting as banker to the group), shared service centers (centralized finance back offices) and payment factories (one engine for all group payments) all use MT 101 to instruct their banks to execute payments or move funds between accounts. These are typically from a treasury management system connected to Swift.

Corporates access Swift primarily through: 

• SCORE (Standardized Corporate Environment): This is the dominant model. A corporate holding a BIC (Business Identifier Code), can exchange messages with its baking partners in a standardized framework, rather than setting up separate negotiations and one-to-one connections.
• MA-CUG (Member-Administered Closed User Groups): the older, bank-administered model. It’s still in use with some institutions. 
• Treasury counterparty / other arrangements: a smaller group with specific bilateral setups. 

In these flows, the corporate is the Initiating Party. It sends the MT 101 directly to its Account Servicing Institution (the Debtor Agent), which debits the corporate’s account and executes the payment.

2. FI-to-FI (Financial Institution)

The second use case is the interbank relay. 

Here, a corporate has a primary relationship with Bank A and maintains accounts with Bank B. The corporate instructs Bank A, and Bank A, acting as Forwarding Agent, relays the instruction over FIN as an interbank MT 101 to Bank B, the Debtor Agent. 

This institution holds the account, debits it and executes the payment (onward settlement then typically flowing as pacs.008). 

The participants in the relay chain are therefore:

• Debtor / Initiating Party: the corporate customer requesting the payment 
• Forwarding Agent: the bank receiving the customer’s request and relaying it to the account-holding bank
• Debtor Agent: the account servicing institution that executes the debit 
• Creditor Agent: the beneficiary’s bank, reached via the subsequent payment leg 

Click to enlarge

The interbank MT 101 comes in two formats: 

• MT 101 single instruction (FI-to-FI): one payment instruction per message 
• MT 101 multiple instruction (FI-to-FI): several instructions batched in one message 

As part of SR 2026, the ISO 20022 pain.001 becomes the standard for FI-to-FI payment initiation relay, ending the coexistence period that began in November 2025. 

What changes (or stays the same) in November 2026?

1. The interbank migration to pain.001

As part of SR 2026, the ISO 20022 pain.001 becomes the standard for FI-to-FI payment initiation relay, ending the coexistence period that began in November 2025.

Here’s how it will work:

Rejected Outright – MT 101 multiple instruction (FI-to-FI)

From November 2026 this variant reaches end of life. Messages will be NAKed, and there is no conversion safety net. Institutions still relaying multi-instruction MT 101s interbank must migrate these flows to pain.001. There are no exceptions.

Tolerated – MT 101 single instruction (FI-to-FI)

From November 2026, this variant stops being a natively supported message and becomes a converted one. Swift’s contingency service will translate a single-instruction MT 101 from a Forwarding Agent into pain.001 for delivery – but subject to additional FIN validation rules and conversion fees.

These fall on the sending bank rather than the corporate that initiated the payment. The validation rules are already published and cover single instructions specifically. Note too that passing validation is not a guarantee of delivery: a message that clears FIN validation can still be aborted if it cannot be translated.

A bridge – pain.001 with embedded MT 101 (in-flow translation)

Since 22 November 2025, Swift has delivered interbank pain.001 messages with an MT 101 translation attached. Banks that are not yet ISO-ready can still process them. The pain.001 is the legal message of record; the embedded MT 101 is a backup, not an equivalent.

It has been chargeable since 1 January 2026, and Swift has been explicit that contingency measures of this kind are temporary, carrying deliberate operational, transparency, and financial disincentives to discourage long-term reliance. It is also conditional: if the RMA authorization is removed, the translation disappears along with the direct pain.001 channel.

2. Who can keep sending MT 101 unchanged?

This is the question we hear most often from clients, so let’s break it down. 

Your corporate customers can carry on sending MT 101 to you. That channel – including SCORE – sits outside the scope of the interbank migration, and the withdrawal of the multi-instruction variant applies to the bank-to-bank leg only. 

What changes is your leg. Where you act as Forwarding Agent, you will be relaying onward as pain.001 rather than MT 101, which makes your corporate customers’ data your problem. Their addresses and party details have to survive the conversion, and the failure shows up on your interbank message, not theirs. Start those conversations now. 

3. Who will be impacted by the advanced FIN validation rules?

These rules and fees land on one specific flow: single-instruction interbank MT 101s that you send as Forwarding Agent and leave Swift to convert. Every one of them will face stricter validation and carry a charge. That is deliberate, the pricing is set to make staying on MT more expensive than migrating off it. 

What it does not touch is the MT 101s your corporate customers send you under SCORE or MA-CUG. Those sit outside the scope entirely. 

You should also be aware: if a Debtor Agent removes the pain.001 authorization with a particular counterparty (if there’s no existing business agreement, for instance) after 14 November 2026, the other bank loses both the direct pain.001 channel and the MT 101 fallback conversion. The messages won’t be translated, and the sender gets an abort notification.  

No RMA authorization on FINplus, no ISO 20022 messages. Rather than make every bank set up its pain.001 permissions from scratch on the new network, Swift copies across what you already have on FIN.

What has already happened?

Swift ran a first bootstrap on 6 December 2025 – a one-off exercise in which it created RMA authorizations on your behalf, in bulk, rather than leaving each bank to set them up itself. 

It was conditional. Swift only created a pain.001 authorization where two things were already true: you and your counterparty had an MT 101 RMA in place, and both of you had acceded to the Rulebook for Payment Initiation Relay – the agreement that governs how banks exchange pain.001 in relay arrangements – by 1 October 2025. 

If either condition was missing, nothing was created for you. Those banks have been building their pain.001 authorizations one at a time in the RMA portal ever since. 

What happens on 3 October 2026?

The mandatory FINplus bootstrap runs on 3 October 2026 (backup: 10 October) during the weekend maintenance window (Sat 16:00 – Sun 05:00 GMT; RMA Portal and distribution file services unavailable). There are two components: 

• admi.024: for all BICs holding MT 199/299 authorisations (Administration profile). 
• pain.001 and pain.002: for SUPE and NOSU institutions only (corporates/SCORE are out of scope, no RMA change on corporate-to-bank relationships), based on FIN MT 101 traffic over the past 12 months: pain.001 authorised in the same direction as the MT 101 (FI Initiated (Interbank) Request), pain.002 in the opposite direction (FI Initiated (Interbank) Response).

To prepare for the October bootstrap, here’s five things every RMA manager should know.

1. There’s no rulebook accession condition. Unlike December 2025, this bootstrap is unconditional (MT 101 has uses beyond the relay scenario). The safeguard shifts to you: check counterparties in the Rulebook Directory and remove RMAs where no business agreement exists.

2. Existing relationships will be untouched. Only missing message types are added; existing FIN and pain.001/pain.002 relationships remain as is.

3. Not everything goes live on 3 October. Additions to existing FINplus relationships are active from 3 October and brand-new authorisations start 14 November, 00:00 GMT (SR 2026 activation).

4. Activation status will be preserved. But in-flight activation proposals over the bootstrap weekend must be cancelled and recreated (or the authorisation reactivated) to pick up the new message types.

5. Bootstrap changes aren’t audited. History and audit records aren’t updated; validate the results via the portal’s reporting options.

Click to enlarge

Looking further ahead

The contingency conversion for single-instruction MT 101 is not the final destination. The aim is for ISO 20022 to be across the payment initiation chain, and the corporate channel is the next logical step. Richer structured data in pain.001 flowing end-to-end into pacs.008 without translation loss. Institutions and corporates that treat November 2026 as the finish line will find it was actually the starting gun. There is no gain without pain.

Want to know more?

If you’re a corporate or a bank who needs help with the MT 101 migration, then reach out. . Discover how our Payments Expert Agent can support your transition in a fraction of the time and cost.