ISO 20022 for Indian Exporters: What Changes in Your Inward Payments

ISO 20022 is the international standard that sets how banks structure the messages they send each other when money moves. It carries details such as names, addresses and invoice references in separate labelled fields, whereas the older Swift MT format packed them into blocks of free text.

If you receive foreign currency into India, you do not need to sign up for or file anything new. Your client's bank and your Indian bank handle the format. What you may notice is cleaner sender details on the credit advice your bank sends you.

As of November 2026, banks have exchanged cross-border payment instructions in the new format since 22 November 2025. A later change to how addresses are written has been postponed, and Swift has not set a new date.

Think of the ISO 20022 standard (also written ISO20022) as a common language for payment data. As for the ISO 20022 full form, ISO stands for the International Organization for Standardization, and 20022 is this standard's number in its catalogue.

Here is one payment written both ways:

• The old MT style: your client's name and address sit in one block of text, and the reference is free text such as "Payment for Invoice 123456".
• The new structured style: name, street, town and country each get their own field, and the invoice number can sit in a field labelled as an invoice reference.

The main benefits for banks come from these labelled fields:

• Fewer manual checks: more payments go through straight-through processing, checked and credited without someone reading them by hand.
• Cleaner compliance checks: rich data in named fields can make sanctions screening and anti-money laundering checks easier to run accurately than guessing where a name sits in free text.
• Easier matching: an invoice number in its own field is simpler to match to the right invoice.

Swift is the network banks use; the standard sets what each message contains. Swift's ISO 20022 migration, often called the MT to MX migration, ran under its Cross-Border Payments and Reporting Plus programme (CBPR+). It moved bank-to-bank payments from the older MT format to MX messages, which is Swift's name for ISO 20022 messages.

How the old payment message fields map to the new format

The customer payment that pays your invoice used to travel as a SWIFT MT103. Its replacement is pacs.008. The fields map across closely, though not one for one, because the new message splits several of them into smaller parts.

A bank that has not fully upgraded may rely on Swift to translate messages between MT and the new format. That translation back into MT is where long details can get cut.

Common message types you may see named

These are the ISO 20022 message types you are most likely to see named on a payment or statement.

The standard covers messages for securities, trade, cards and foreign exchange as well as payments. In payments, several major systems already use it:

India was early: RBI built its current RTGS on the standard in 2013 and has said it intends to move all its payment messaging systems to it. For ISO 20022 payments reaching you, the system that matters most is Swift, because that is how a payment from abroad usually reaches your Indian bank.

As of November 2026, only the first of the two steps is finished.

The postponed step is about addresses. An unstructured address is free lines of text. A structured address puts street, town, postcode and country in their own fields. A hybrid address sits between the two: at minimum the town and country go in their own fields.

For now, structured and hybrid addresses are both valid, and unstructured addresses are still accepted. The delay does not change how you get paid.

The new format sets how your payment details are written, and nothing else. Your fees, your exchange rate, your Foreign Inward Remittance Advice (FIRA) and the reporting done by your authorised dealer (AD) bank (the bank licensed to handle foreign exchange) all work as before. What can change is the detail you see on each credit.

What the new structured data fields carry on each payment you receive

The new format gives each detail its own slot:

• Names: your client's full name, and yours as the receiver.
• Addresses: structured postal addresses, split into street, town and country.
• References: tax IDs and invoice numbers in labelled fields.

Which slots get filled depends on the sender's bank. Structured remittance, with the invoice number in its own labelled field, needs agreement between the banks, so many cross-border payments still carry the reference as short free text.

How your FIRA, purpose code and AD bank steps are affected

The format does not affect your FIRA, purpose code or AD bank reporting. Your FIRA and any e-FIRA work as before.

Under the Foreign Exchange Management Act (FEMA) export regulations in force from 1 October 2026, your AD bank records each foreign inward remittance against your exports in EDPMS. These are your AD bank's reporting duties under rules from the Reserve Bank of India (RBI), and they do not depend on the message format, so your purpose code steps stay the same.

The main risk for you is a mismatch: a name, reference or address on the payment that does not line up with your invoice or your bank record, or a reference cut short along the way.

1. Your exact legal name and address: give clients your name and address exactly as they appear on your bank record, so the receiver details match what your bank expects.
2. The invoice number in the reference: ask every client to put the invoice number at the start of the payment reference, where it is least likely to be cut.
3. Short, plain reference text: free-text references are typically limited to 140 characters on the cross-border leg, and a conversion back to MT can cut a long one (a bank may add a "+" to show the cut), so keep it well under that.
4. The same purpose code as before: choose the RBI purpose code for inward remittance that fits your service, exactly as you did before the switch.
5. Credit advice matched to the invoice: match each credit advice to its invoice when it lands, and keep both with your FIRA records.
6. A full copy when something looks wrong: if a credit shows a changed name or a cut reference, ask your bank for the full payment message and its Swift gpi tracking reference (the UETR, which follows the payment through every bank in the chain) before you chase the client.

If many credits land each month, put the reference rule from step 2 in every invoice template.

Xflow receiving accounts give you one set of account details to share with every overseas client, so the name and reference they enter stay consistent. Each withdrawal to your Indian bank account comes with a free FIRA issued by an RBI-authorised bank, which shows who paid you and why, and withdrawals reach you within 1 business day.

ISO 20022 changes how payment details are written, not what you pay or report. The main switch for cross-border payments happened on 22 November 2025, and the address change planned for November 2026 is postponed. Your fees, FIRA, purpose code and AD bank reporting stay the same. Give clients your exact legal name and ask for the invoice number in every payment reference.