MT101 to pain.001: Payment Initiation Relay Over SWIFT, Field by Field

Interbank MT101 is being replaced by the CBPR+ pain.001 (version pain.001.001.09) under SWIFT’s ISO 20022 Payment Initiation Relay rulebook. The November 2026 end of coexistence is not being enforced after SWIFT’s August 2026 deferral, and a new date is expected in December 2026. That buys time for the real work: a one-to-many field mapping, single-instruction messages instead of batches, structured addresses, and a test pack that proves nothing gets lost in the relay.

The MT101 is the message treasurers love and banks tolerate. A corporate with accounts at ten banks sends requests for transfer to one bank, which relays them to the bank holding each account. It runs on bilateral agreements, a terse format, and field 23E codes that every bank interprets slightly differently. Moving it to ISO 20022 is overdue and, compared with pacs.008, under-documented.

This article is in the migration section of The ISO 20022 Reference. PAIN vs pacs explains why customer-to-bank and bank-to-bank messages differ. Here the focus is the specific move from MT101 to pain.001 over SWIFT.

What does MT101 do, and what replaces it?

An MT101 is a request for transfer: an instruction to debit an ordering customer’s account and pay a beneficiary. It travels in two settings:

1. Corporate to bank, over Swift for Corporates (SCORE). The corporate sends the MT101 straight to the bank holding the account.
2. Bank to bank (the relay). The corporate sends its requests to one bank, the forwarding agent, which relays each one to the debtor agent, the bank where the account is held.

The ISO 20022 replacement is the pain.001 Customer Credit Transfer Initiation in both settings, with the pain.002 status report coming back. But the rules differ:

Setting	Today	ISO 20022	Covered by the CBPR+ end of coexistence?
Corporate to bank (SCORE)	MT101 over FIN	pain.001 over FINplus under SCORE+ usage guidelines	No. MT101 in SCORE continues
Bank to bank (relay)	MT101 over FIN under bilateral agreements	CBPR+ pain.001.001.09 under the Payment Initiation Relay rulebook	Yes, date being reset

The relay is the part with a deadline, so it is the focus below.

What is the Payment Initiation Relay rulebook?

SWIFT’s ISO 20022 Payment Initiation Relay rulebook is the business framework for relaying pain.001 between banks. It succeeds the framework that governed MT101 relay: SWIFT publishes interpretation notes explaining how the rulebook applies alongside the older service level master agreement and request for transfer schedule during coexistence.

What it means operationally:

• Accession. A bank accedes through an eForm and declares its BICs, readiness dates, and the roles each BIC supports: forwarding agent, debtor agent, or both.
• The directory. SWIFT’s online directory lists acceded banks with their accession, change, and termination status. Before you send a pain.001 relay to a debtor agent, you check it has acceded in the debtor agent role. That check belongs in your routing, not in a spreadsheet.
• The default path. SWIFT says that for most banks, acceding to the rulebook is the default way to have a business framework in place, rather than bilateral contracts per counterparty.

What are the dates now?

Current as of October 2026.

Date	What was planned	What happened
November 2025	In-flow translation of interbank pain.001 to MT101 for receivers not ready	Live since November 2025
3 October 2026	RMA bootstrap to enforce the end of coexistence	Will not take place (ING, 1 September 2026)
November 2026	End of coexistence: MT101 with multiple transactions rejected (NAK), MT101 single converted to pain.001 by contingency processing, with extra FIN validation and fees	Not enforced. MT101 single and multiple remain supported between banks
December 2026	(not in the original plan)	New compliance date expected, per SWIFT’s CBPR+ guidance as reported by ING
Early 2027	(not in the original plan)	SWIFT may consider a new bootstrap based on adherence to the rulebook, as an incentive to adopt pain.001
November 2027	Ancillary messages (pain.002, camt.055, camt.029) adopted bilaterally by this date	Unchanged in public sources

The deferral comes from SWIFT’s 27 August 2026 decision to defer all payments changes in Standards Release 2026 and phase the other planned payments changes separately. Banks are still asked to keep moving: ING is migrating its counterparties to pain.001.001.09, and J.P. Morgan reports receiving CBPR+ pain.001 since November 2025.

What changes for the corporate and for the bank?

For the corporate, on the relay path, very little at first: it still sends requests to its forwarding agent. What changes is the data it must supply. A pain.001 has room for a structured debtor and creditor, structured remittance, purpose codes, an end-to-end identification that survives to the beneficiary’s statement, and a UETR. The pain.002 that comes back tells it precisely what happened. Corporates that keep sending MT101 to their forwarding agent need that agent to map it, which is where data gets lost.

For the forwarding agent, the job becomes a transformation: receive the corporate’s request (MT101, pain.001, a host-to-host file, or an API call), validate it against the CBPR+ usage guideline, and relay one pain.001 per transaction to the debtor agent.

That last part is the structural change. The CBPR+ pain.001 relay is a single-instruction message. An MT101 could carry several transactions, and ING’s mapping table lists MT101 multiple with “no MX equivalent”. A forwarding agent that receives a ten-transaction request sends ten pain.001 messages. Your reference scheme, duplicate checks, status aggregation, and the batch versus single booking logic downstream all have to cope.

For the debtor agent, the incoming request is richer and stricter. It executes the transfer, usually as a pacs.008, and reports status back with a pain.002. The ancillary messages (pain.002 for status, camt.055 to cancel, camt.029 to answer) are bilateral today and due by November 2027.

How does MT101 map to pain.001?

Field by field, for the fields that matter. The XML paths are relative to the pain.001 Customer Credit Transfer Initiation.

MT101 field	Content	pain.001 element	Watch out for
:20	Sender’s reference	GrpHdr/MsgId and PmtInf/PmtInfId	One MT101 becomes several messages: derive unique ids traceable to the original
:21R	Customer specified reference	PmtInf/PmtInfId or a reference agreed bilaterally	Often used for the corporate’s batch reference
:28D	Message index / total	No equivalent	Chaining of MT101 messages disappears
:50C / :50L	Instructing party	GrpHdr/InitgPty
:50G / :50H / :50F	Ordering customer and account	PmtInf/Dbtr and PmtInf/DbtrAcct	Structured debtor name and address
:52a	Account servicing institution	PmtInf/DbtrAgt	The debtor agent that must have acceded
:51A	Sending institution	GrpHdr/FwdgAgt	The forwarding agent role
:30	Requested execution date	PmtInf/ReqdExctnDt/Dt
:25	Authorisation	No direct equivalent	Signature handling moves outside the message
:21	Transaction reference	CdtTrfTxInf/PmtId/InstrId	Point to point
(none)		CdtTrfTxInf/PmtId/EndToEndId and UETR	New: carried unchanged to the beneficiary
:21F	FX deal reference	CdtTrfTxInf/XchgRateInf/CtrctId
:23E	Instruction code (URGP, CHQB, INTC, PHON, OTHR…)	PmtTpInf (service level, category purpose) or InstrForDbtrAgt / InstrForCdtrAgt	Agree a mapping table per code; free-text 23E narratives are the classic loss
:32B	Currency and amount	CdtTrfTxInf/Amt/InstdAmt with Ccy
:33B and :36	Original ordered amount and exchange rate	Amt/EqvtAmt and XchgRateInf	Which currency is fixed must survive
:56a	Intermediary	CdtTrfTxInf/IntrmyAgt1
:57a	Account with institution	CdtTrfTxInf/CdtrAgt
:59 / :59A / :59F	Beneficiary	CdtTrfTxInf/Cdtr and CdtrAcct	Structured or hybrid address
:70	Remittance information (4x35)	CdtTrfTxInf/RmtInf	Room for structured references after migration
:77B	Regulatory reporting	CdtTrfTxInf/RgltryRptg	Country-specific codes
:71A	Details of charges (OUR, SHA, BEN)	ChrgBr (DEBT, SHAR, CRED)	See charges
:25A	Charges account	PmtInf/ChrgsAcct

Three mapping rules deserve their own requirement.

1. 23E is a decision table, not a field. Write it as a decision table: each code, its ISO 20022 destination, and what happens to codes with narrative text. URGP and the service level, INTC and category purpose, PHON and OTHR into instructions for the agent: each needs an explicit row.
2. Charges translate, they do not copy. OUR becomes DEBT, SHA becomes SHAR, BEN becomes CRED. A mapper that passes the three-letter MT code fails schema validation at best.
3. FX must keep which side is fixed. In an MT101 with :33B and :36, the ordered amount and the rate tell the debtor agent which currency the customer fixed. In pain.001, InstdAmt and EqvtAmt express the same choice differently. Get it wrong and the beneficiary receives the right amount in the wrong currency, which is a payment defect, not a format defect. Amounts and FX covers the two amounts.

How do structured addresses affect MT101 and pain.001?

SWIFT’s guidance for corporates is the same on every channel, MT101 over SCORE, pain.001 over SCORE+, or a bank’s proprietary channel: when the requirement applies, the beneficiary address must have at least town name and country as structured elements. In MT101 that means field 59 option F, which carries the address in numbered lines with the town and country identified. In pain.001 it means the structured postal address, or the hybrid form with town and country structured and up to two address lines.

Two caveats as of October 2026. The November 2026 date was deferred, and ING reports that unstructured addresses in interbank MT101 remain supported for now. And if the beneficiary bank is identified by BIC, no bank address is needed. The full picture, and why corporates should still collect structured beneficiary addresses in their ERP now, is in structured addresses.

For the forwarding agent, this creates an awkward requirement: a corporate may send a 59F address that is hybrid, and the onward pain.001 must keep the structure it was given, not flatten it back into address lines. Test it.

If you are writing the forwarding agent’s requirements from a one-line brief like “support pain.001 relay”, From Vague BR to Functional Requirements shows the method, and Break Into Banking covers the corporate banking flows behind it.

What should you test?

#	Scenario	Expected result
1	Single-transaction MT101 from a corporate, relayed as pain.001	All mapped fields present, CBPR+ validation passes
2	MT101 with five transactions	Five pain.001 messages, each with a unique MsgId traceable to the original :20 and :21
3	Each 23E code in use	Lands in the agreed element per the decision table
4	23E with narrative text	Narrative preserved in the agreed instruction element, not dropped
5	:71A OUR, SHA, BEN	ChrgBr DEBT, SHAR, CRED
6	:33B and :36 present	Fixed-currency side preserved, beneficiary receives the intended amount
7	Beneficiary with 59F hybrid address	Town and country structured in the pain.001, no flattening
8	Remittance at the 4x35 limit	Complete in RmtInf, no truncation
9	Debtor agent not acceded to the rulebook	Relay blocked before sending, clear error to operations
10	Debtor agent rejects	pain.002 RJCT with reason code mapped back to the corporate
11	Same request submitted twice	Duplicate detected, second relay not sent
12	Debtor agent executes	Resulting pacs.008 carries the same EndToEndId and UETR, so the corporate can reconcile
13	Receiver not ready, in-flow translation to MT101	Translated MT101 accepted by the receiver, and the truncation is documented

Case 12 is the one that justifies the migration. With MT101, a corporate rarely saw its own reference again once the debtor agent turned the request into a payment. With pain.001 and a UETR, the request, the pacs.008, the status reports, and the beneficiary’s statement all share identifiers. If your test does not prove that, the migration has changed the format and kept the old blind spot. The same field-by-field assertion discipline as the pacs.008 test cases applies.

The Analyze a Payment API lab practises the same skill on a payment initiation contract: finding the fields that disappear between what the client sends and what the system executes.

The takeaway

Interbank MT101 is moving to the CBPR+ pain.001 under SWIFT’s Payment Initiation Relay rulebook. The November 2026 end of coexistence is not being enforced after the August 2026 deferral, and a new date is expected in December 2026, so use the time. Accede to the rulebook, check counterparties in the directory, and build the mapping as a set of explicit decisions: single-instruction messages instead of batches, a 23E decision table, translated charge codes, FX that keeps its fixed side, and addresses that keep their structure. Then prove with tests that the corporate’s identifiers survive from request to statement, because that traceability is what MT101 never gave anyone.

For the wider migration, read the MT to ISO 20022 mapping. The full map is on The ISO 20022 Reference.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: ISO 20022, CBPR+, MT101, Payment Initiation, Corporate Banking