Correct population of data in Swift MX messages

Go to list of all SWIFT Payments topics

Previous: In-Flow Translation vs SWIFT Translator: Key Differences

Incorrect usages of MX messages identified so far

The coexistence of MT and MX messages is nearing its end and during this tenure many incorrect uses of MX messages has been observed. In this blog, let us go through a few of those and see what the correct usage recommendations are (Source: PMPG).

Want to learn more about SWIFT?

SWIFT MT AND ISO 20022 MX MESSAGES | 3-IN-1 COURSE PACKAGE

View Details

Observation	Recommendation
Wrong usage of Elements
For identifying a corporate which has its own BIC, BICFI element is used	BICFI element is only meant to identify financial institutions. For non-FI, ANYBIC element must be used
'Creditor Agent' elements are being received without a BIC (just name and address) thereby hindering STP	It is recommended to use the BIC as the primary identifier for an Agent
'SettlementMethod' is sometimes being mis-used. i.e. INDA/INGA is used instead of COVE	'SettlementMethod' should be used correctly
Wrong population of Regulatory Reporting codes in Purpose codes which is making such data useless	Regulatory Reporting and Purpose tags have two different uses. Incorrect population of these elements can lead to rejection of the payment
Some banks while converting MT to MX, and encountering names with more than 35 characters, are wrongly placing the extra characters at the beginning of the address line. This is causing issues for receiving banks as they are unable to identify whether these belong to the address or continuation of the name	The name tag is 140 characters long in MX and thus names should be placed only in this dedicated tag
Some banks are including the MT ‘/’ in account number which is causing issues and preventing STP for the MX messages	In MX messages account numbers should NOT begin with ‘/’
Duplication of creditor/debtor data in ultimate party fields	Ultimate party fields are not mandatory and should be populated only when such a party actually exists
Putting junk like 'NOT PROVIDED' and 'XXX' to fill up address fields	Meaningful data in country and town name is essential for successful address processing, otherwise such messages may get rejected
Wrong usage of Message Types
Positive pacs.002 message sent without any bilateral agreement	It should only be sent when a bilateral agreement is in place
Some banks are sending pacs.008 or pacs.009 with /RETN/ populated in element 'Instruction for Next Agent'.	Banks should send the pacs.004 to return funds when settlement is completed.
Some banks are using pacs.002 to return funds	Banks should send the pacs.004 to return funds when settlement is completed. Pacs.002 should only be used to reject funds.

As testing is going on in full force, it is important to keep in mind that just converting MT to MX is not enough - meaningful data population is equally important. Otherwise, banks are going to pay a heavy price for wrong data population in the coming future.

WANT TO READ MORE?