SWIFT MT Messages in Trade Finance: MT700, MT760 and Message Flow

Every documentary credit, bank guarantee and cross-border payment that moves through a bank's international division rides on a message standard candidates must know cold. SWIFT MT messages in trade finance are the numbered instructions — MT700, MT760, MT202 and their relatives — that issuing banks, advising banks and reimbursing banks exchange to open, amend, pay or refuse a credit or guarantee. For the ITF paper, examiners test whether you can match a message type to its function and place it correctly in the transaction flow. This article builds that map end to end.

🌐 What SWIFT Is and How a BIC Is Structured

SWIFT (Society for Worldwide Interbank Financial Telecommunication) is a member-owned cooperative messaging network headquartered in Belgium. It does not hold or move funds itself — it carries authenticated, structured instructions between banks, and the receiving bank acts on the instruction through its own nostro or vostro accounts. Nearly every correspondent banking relationship an Indian bank maintains for trade finance depends on this network.

Each institution on the network is identified by a Bank Identifier Code (BIC), commonly called a SWIFT code. A BIC is 8 or 11 characters: a 4-letter bank code, a 2-letter country code, a 2-character location code, and an optional 3-character branch code (XXX denotes the head office). Every MT message carries a sender BIC and receiver BIC in its header, which is what makes the message traceable and what an RMA authorisation actually controls.

Messages are grouped into categories by their first digit — category 1 for customer payments, category 2 for institution transfers, category 7 for documentary credits and guarantees, and so on. An "MT" prefix plus a three-digit number identifies the exact message type, so MT700 and MT760 sit in the same family as cousins with very different jobs. Candidates preparing from the bank's Trade Finance chapter should treat this numbering logic as the starting point before memorising individual message types.

📄 The MT7xx Family: Documentary Credit Messages

Category 7 is the workhorse of documentary trade. MT700 is the message an issuing bank sends to open a documentary credit — it carries the credit amount, tenor, latest shipment date, required documents and the UCP 600 terms the credit is subject to. Once issued, any change to those terms travels as an MT707, the amendment message, which the advising bank must pass on to the beneficiary before it can be acted upon.

Where a credit reaches the beneficiary's bank through an intermediary rather than directly from the issuing bank, the intermediary uses MT710 — advice of a third bank's documentary credit — to relay the terms without altering them. A transferable credit moves to a second beneficiary through MT720, the transfer message, which substitutes the first beneficiary's name, price and shipment dates within the limits the original credit allows.

The back end of the documentary cycle has its own messages. If the presenting bank's documents are discrepant, the issuing or confirming bank sends MT750 to flag the discrepancy, and if it decides not to honour the presentation at all, it sends MT734, the advice of refusal, which must state every discrepancy relied upon or the refusal is not valid under UCP 600. Where the issuing bank instead accepts the documents on a waiver, it authorises payment through MT752. Reimbursement between banks is separately authorised by MT740, which the issuing bank sends to a reimbursing bank instructing it to honour claims from the nominated bank. This chapter-level detail is exactly what the Regulatory Framework chapter expects you to sequence correctly.

💡 Exam Tip: Pair each MT7xx code with a verb — MT700 issues, MT707 amends, MT750 flags, MT734 refuses, MT740 authorises reimbursement. Verb recall beats rote number memorising in the exam hall.

🔐 MT760, MT767 and the Payment Legs — MT202 and MT103

Demand guarantees and standby letters of credit do not use MT700 at all. They are issued with MT760, which carries the guarantee text, the amount, expiry and the underlying obligation it secures, and any change to that guarantee is carried by MT767, the guarantee amendment message. Banks handling performance guarantees, bid bonds and financial guarantees for exporters and contractors rely on this pair, which is a natural companion topic to the bank's standby letter of credit coverage.

None of the category 7 messages actually move money — they instruct, amend, advise or authorise. The money itself travels on a separate leg. MT202, the general financial institution transfer, is the bank-to-bank instruction typically used to execute a reimbursement authorised under MT740, or to cover a related customer payment between correspondent banks. MT103, the single customer credit transfer, is the message that finally credits the beneficiary's own account — an exporter, for instance, once the negotiating bank has been reimbursed.

A typical documentary credit therefore generates at least two distinct message streams: the category 7 messages that document the trade obligation (MT700 through MT767) and the payment messages (MT202 and MT103) that settle it. Confusing the two is a common paper error — a guarantee amendment does not authorise a payment, and a reimbursement authorisation does not by itself move funds until MT202 is sent.

⚠️ Common Mistake: Students often assume MT740 itself pays the negotiating bank. It only authorises the reimbursing bank to honour claims — the actual funds move separately via MT202.

🔄 ISO 20022 Migration, RMA and Fraud Control Points

SWIFT has been migrating cross-border payment traffic to the ISO 20022 (MX) standard under its CBPR+ programme. The MT103 and MT202 payment legs moved onto richer MX equivalents, with the MT/MX coexistence period for cross-border payments closing in November 2025 — banks now exchange these payment messages predominantly in MX format. Category 7 trade messages (MT700 through MT767) sit on a separate, later migration track and continue to run largely on the MT standard for now, so candidates should not assume documentary credits and guarantees have already moved to MX.

Two control points matter most for trade fraud prevention, and both come up in the Risk Management chapter. First, the Relationship Management Application (RMA) — a bank must explicitly authorise which counterparty BICs may send it FIN messages before those messages can even reach its system. A purported MT700 or MT760 from a bank with no active RMA relationship should never be actioned, and several documented guarantee frauds have involved paper claiming "SWIFT authentication" that was never actually transmitted through the network at all. Second, message authentication itself relies on bilateral keys, so an authenticated MT message from a valid BIC under an active RMA carries far more evidentiary weight than a scanned PDF or courier copy.

Operationally, banks should always verify a received documentary credit or guarantee against the live SWIFT message rather than any accompanying paper, confirm the RMA status of the sending BIC, and route high-value MT700/MT760 traffic through maker-checker before acting on it. RBI's guidelines for import and export transactions expect authenticated SWIFT (or equivalent secure) messages as the basis for advising credits and guarantees — see the Reserve Bank's Master Directions for the current framework governing cross-border trade documentation.

📌 Remember: No active RMA relationship means no authenticated MT message can flow between two BICs — this single control blocks a large share of attempted trade-guarantee fraud.

🧠 Practice MCQs: SWIFT MT Messages in Trade Finance

Want chapter-wise mock tests with 100+ MCQs? Start practising free →

✅ Take This Further

Message-type recall is only half the battle — you also need to place each MT code inside the transaction sequence, connect it to the underlying UCP 600 or demand-guarantee rules, and recognise the control points examiners test around fraud prevention. Revise the Facilitation Bodies chapter alongside this topic to see how SWIFT sits within the wider institutional architecture of trade finance, and cross-check discrepancy handling against our note on UCP 600 and document discrepancies. If you are also revising cost-side banking topics, see how correspondent balances tie into cost of deposits and deposit pricing for the CAIIB BFM paper. For every ITF topic mapped chapter-by-chapter, browse the International Trade Finance tag hub, and once you've worked through the message flow, take a full practice test to lock it in before exam day.