The Swift Foreign Exchange Confirmation. The two parties to an FX deal (or a money broker) send it to each other to confirm the currencies, amounts, rate, value date and settlement instructions of a spot, forward, swap leg or non-deliverable forward.

How is the common reference in field 22C of an MT300 built?

From the sender’s and receiver’s BICs without the country code (bank code plus location code), placed in alphabetical order, with four digits from the exchange rate between them: the rightmost non-zero digit of field 36 and the three digits before it, zero filled. ZAGTAEAD and BANKGB2L at 1,08712 give BANK2L8712ZAGTAD.

What is the difference between MT300 and MT320?

The MT300 confirms a foreign exchange deal (two currencies exchanged at a rate). The MT320 confirms a fixed-term loan or deposit in one currency, with principal, interest rate and maturity, and its rollover and maturity events.

What is the difference between MT300 and MT304?

The MT300 is the confirmation between the two trading parties. The MT304 is sent by one party, typically a fund manager, to a third party such as its custodian or a CLS settlement member, to advise or instruct the settlement of a deal done with someone else.

How is a non-deliverable forward confirmed with an MT300?

With two confirmations from each side. The opening one has 17F Y and 17O Y with the settlement currency (32E), valuation date (30U) and rate source (14S). The valuation one has 17F Y, 17O N and 21A pointing to the opening confirmation, with the fixing rate in field 36.

Is the MT300 being replaced by ISO 20022?

Not as part of the payments migration. Category 3 treasury messages were outside CBPR+, and the MT300 is still the standard Swift FX confirmation on FIN. Swift lists fxtr.014 as its ISO 20022 equivalent, a trade notification to a central settlement system.

Category 3: Foreign exchange, money markets and derivatives

MT300 Foreign Exchange Confirmation

Written and maintained by ZagTrader. Last reviewed 21 October 2026. How this page is sourced and checked

The MT300 is the Swift message two counterparties to a foreign exchange deal send each other to confirm its terms: who bought and sold which currencies, the rate, the value date and where each amount will be paid. It covers spot, forwards, each leg of an FX swap and non-deliverable forwards, and is sent by both sides (or by a money broker) on trade date so the confirmations can be matched before settlement.

Message type: MT300
Category: 3
Structure: 12 sequences, 95 fields listed
ISO 20022: fxtr.014

When MT300 is used

An MT300 is exchanged between party A and party B, the two legal entities that agreed an FX deal. Each side sends its own MT300 and receives the other’s, and each sees itself as party A in the message it sends. A fund manager confirms with itself in 82a and the fund in 83a; an agent dealing for a client uses 94A AGNT; a money broker can send the confirmation to both principals with 94A BROK and its own details in sequence C. The MT300 confirms the contract only: the money moves through payments such as MT202 or MT205 (quoting the common reference in field 21) and appears on statements such as MT950.

Confirmation matching is the point of the message. The two MT300s are compared field by field (trade date, value date, rate, both amounts and the settlement instructions), either by the counterparties’ own systems or by a matching service. Field 22C gives both confirmations the same key without either side knowing the other’s reference. A break usually means a booking error or stale settlement instructions, and it is far cheaper to fix on trade date than after value date.

Field 22C is built the same way by both sides. Take the sender’s and the receiver’s BICs, drop the two-letter country code, and keep the four-letter bank code with the two-character location code (ZAGTAEAD becomes ZAGTAD, BANKGB2L becomes BANK2L). Put the two codes in alphabetical order, letters before digits. Between them put four digits from the rate in field 36: the rightmost non-zero digit and the three digits to its left, with leading zeros if there are fewer. A rate of 1,08712 gives 8712, so ZagTrader and BANKGB2L both write BANK2L8712ZAGTAD. A rate of 1,0865 gives 0865; 102,18 gives 0218.

Settlement is described from party A’s point of view. Subsequence B1 is the amount party A buys and where it receives it (57a). Subsequence B2 is the amount it sells, where party B receives it (57a) and, for third-party payments, the beneficiary institution (58a). Field 53a says where a payment will come from and 56a names an intermediary. Use option A with a BIC wherever possible: option D was removed from the B1 and B2 party fields in SR 2019 to improve matching, and option J is meant for cases a BIC and account cannot express. Option J also carries the /NOSI/ codes for standing settlement instructions (SSIS), netting (NETS), no payment (NONE), unknown details (UKWN), the non-deliverable leg of an NDF (NDFS) and CCP-cleared trades (CLRD).

CLS and payment versus payment. For trades settled in CLS, the market recommendation is a 57A with a BIC on both legs. The trade reaches CLS separately, through a CLS settlement member: a third-party client of a settlement member typically instructs it with an MT304 or an equivalent file, while the MT300 still goes to the counterparty for confirmation. Field 17I flags payment-versus-payment settlement on another platform (for example USD/MYR through Hong Kong’s interbank clearing) and must not be used for CLS trades.

Field 22A drives the lifecycle. NEWT is a new confirmation, or the corrected one after a cancellation. AMND replaces the earlier confirmation named in field 21 and must repeat all fields, changed or not. CANC cancels both the confirmation in field 21 and the contract, and must repeat at least the mandatory fields of sequences A and B. DUPL repeats a confirmation already sent, and EXOP confirms the FX deal that results from exercising an option confirmed with an MT305 or MT306. An MT392 request for cancellation, answered by an MT396, is an alternative way to cancel. Sequence F confirms post-trade events on an earlier MT300 (early delivery, rollover, unwind) with field 21H naming the event and the earlier field 20.

Non-deliverable forwards (NDFs) and other cash-settled trades have used dedicated fields in sequence A since SR 2017: free-format codes such as /VALD/ in 77D or 72 are rejected. Both parties exchange an opening confirmation (17F Y, 17O Y, with the settlement currency 32E, valuation date 30U and settlement rate source 14S) and a valuation or fixing confirmation (17F Y, 17O N, with 21A pointing to the opening confirmation’s field 20). Both carry the gross notional amounts in 32B and 33B; the non-deliverable leg uses 57J:/NOSI/NDFS and the net settlement amount is the difference between the deliverable amounts of the two messages. The market recommends EMT00 in 14S for currency pairs under EMTA template terms. For a cross, two 14S lines give the reference currency source first and the settlement currency source second.

An FX swap is confirmed as two MT300s, one per leg; field 22W in sequence E can carry one identifier that links them. Sequence D (split settlement, only with 17U Y) splits an amount that is too large for one payment into several parts with the same beneficiary, each with its own direction (17A), amount and agents, closed by the count in 16A. Sequence E carries regulatory reporting data: one or more reporting jurisdictions (22L) with the unique transaction identifier split into a namespace (22M) and an identifier (22N), prior UTIs (22P, 22R), and clearing, venue, timestamp and indicator fields used for EMIR, CFTC and similar regimes.

MT300 format: sequences and fields

Sequence AGeneral InformationMandatory

Who the parties are, what the message does, the common reference and, for non-deliverable trades, the NDF terms.

Tag	Name	Status	Format	Meaning
15A	New Sequence	M	Empty field	Opens sequence A. Only the tag is sent: the line is `:15A:` with nothing after it.
20	Sender's Reference	M	16x	The sender’s own reference for this confirmation. Later amendments, cancellations, valuation confirmations (21A) and post-trade events (21H) point back to it, so it must be unique. No leading or trailing slash and no double slash.
21	Related Reference	C	16x	Field 20 of the confirmation this one amends or cancels. Mandatory when 22A is AMND or CANC, optional otherwise. When 22A is EXOP it should carry field 20 of the MT305 or MT306 that confirmed the option.
22A	Type of Operation	M	4!c	What the message does: NEWT (new confirmation), AMND (replaces an earlier confirmation), CANC (cancels an earlier confirmation and the contract), DUPL (repeats a confirmation already sent by another channel) or EXOP (confirms the exercise of an option).
94A	Scope of Operation	O	4!c	The role of sender and receiver: BILA when they are the two principals (the default when the field is absent), AGNT when one of them acts for a third party that did the deal, BROK when a money broker sends the confirmation.
22C	Common Reference	M	4!a2!c4!n4!a2!c	A reference both sides can build independently, so their confirmations pair up. It joins the sender’s and receiver’s BICs without the country code (bank code plus location code, six characters each, in alphabetical order) around four digits taken from the exchange rate in field 36: the rightmost non-zero digit and the three digits to its left, zero filled. See the rules below.
17T	Block Trade Indicator	O	1!a	Y when the deal is a block trade that will be allocated, N (the default) for a normal trade.
17U	Split Settlement Indicator	O	1!a	Y when the amounts settle in several parts, which makes sequence D mandatory. N or absent: each amount settles as a whole and sequence D is not allowed.
17I	Payment versus Payment Settlement Indicator	O	1!a	Y when the two currencies settle simultaneously on a payment-versus-payment platform agreed in advance by both parties. The standard says not to use it for trades that settle in CLS.
82a	Party AOptions A or J	M	A: [/1!a][/34x] 4!a2!a2!c[3!c] J: 5*40x	One of the two legal counterparties: the sender, the institution or corporate the sender acts for, or (for a broker) one of the parties it is confirming to. A fund manager puts itself here and the fund in 83a. Use option A with a BIC whenever possible; option J takes coded pairs such as /ABIC/, /NAME/, /LEIC/.
87a	Party BOptions A or J	M	A: [/1!a][/34x] 4!a2!a2!c[3!c] J: 5*40x	Party A’s counterparty: the receiver or the institution or corporate it acts for. Option A is preferred for matching.
83a	Fund or Beneficiary CustomerOptions A or J	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] J: 5*40x	The fund or customer for which party A or party B traded, when a fund manager or agent is involved. In option J the code /SVBY/ followed by PTYA or PTYB says which party services it.
77H	Type, Date, Version of the Agreement	O	6a[/8!n][//4!n]	The master agreement covering the deal, for example ISDA, DERV (German master agreement), AFB, FBF, ICOM, IFEMA, FEOMA, ISDACN, ISDACS (cash-settled forwards and options in deliverable currencies) or OTHER, optionally followed by the signing date (YYYYMMDD) and the version year.
77D	Terms and Conditions	O	6*35x	Free text about the legal terms, or bilaterally agreed codes between slashes. It must not start a line with /VALD/, /SETC/, /SRCE/ or /FIX/: those old NDF codes are rejected since structured NDF fields exist.
14C	Year of Definitions	O	4!n	Which version of the FX and Currency Option Definitions applies. Absent means 1998.
17F	Non-Deliverable Indicator	O	1!a	Y for a non-deliverable or other cash-settled trade, N or absent for a deliverable trade. The other NDF fields (17O, 32E, 30U, 14S, 26K, 21A) may only be used when this is Y.
17O	NDF Open Indicator	C	1!a	For a cash-settled trade: Y on the opening confirmation, N on the valuation (fixing) confirmation. Mandatory when 17F is Y, not allowed otherwise.
32E	Settlement Currency	C	3!a	The currency in which the NDF is settled. Mandatory on the opening confirmation (17O is Y), not allowed otherwise. It is usually one of the two traded currencies but may be a third one.
30U	Valuation Date	C	8!n	The fixing date of the NDF (YYYYMMDD), typically two business days before settlement. Mandatory on the opening confirmation, not allowed otherwise.
14S	Settlement Rate SourceRepeatable	C	3!a2n[/4!n/4!c]	The rate source used to value the NDF, with an optional time and location, for example EMT00 (the EMTA template terms for the currency pair) or WMR03/1000/GBLO. Mandatory on the opening confirmation, at most two occurrences: for a cross, the reference currency source first, then the settlement currency source.
26K	Calculation Agent	C	4!c	Who acts as calculation agent for a cash-settled trade: ISDA (as in the master agreement), JOIN (both parties), PTYA or PTYB. Optional on an opening confirmation, not allowed otherwise.
21A	Reference to Opening Confirmation	C	16x	On the valuation confirmation (17O is N): field 20 of the opening confirmation it closes. Mandatory then, not allowed otherwise.
14E	Clearing or Settlement Session	O	35x	The session or service in which a market infrastructure should process the trade. The infrastructure defines the values its members may use.

Sequence BTransaction DetailsMandatory

Trade date, settlement date and rate. The two amounts and their settlement parties follow in subsequences B1 and B2.

Tag	Name	Status	Format	Meaning
15B	New Sequence	M	Empty field	Opens sequence B.
30T	Trade Date	M	8!n	The date the deal was agreed (YYYYMMDD). A unilateral correction keeps the original date; a renegotiated deal carries the renegotiation date. On an NDF valuation confirmation it is the valuation date.
30V	Value Date	M	8!n	The date both amounts settle (YYYYMMDD). For an NDF it is the final settlement date on both the opening and the valuation confirmation. SR 2025 renames the term Value Date to Settlement Date in the documentation, with no change to the content.
36	Exchange Rate	M	12d	The rate at which the deal was struck, with a comma as decimal mark (for example `1,08712`). On an NDF valuation it is the fixing rate from the agreed source. Field 22C takes four digits from this rate.
39M	Payment Clearing Centre	O	2!a	ISO country code of the clearing centre for an offshore currency, for example HK for offshore CNY cleared in Hong Kong. Not used for onshore settlement.
35C	Digital Token Identifier	C	9x[/30x]	The digital token identifier (for example an ISO 24165 DTI) when a non-deliverable trade is against a digital token. Only allowed when 17F is Y and 32B or 33B has the currency code XXX.

Sequence B1Amount BoughtMandatory

From party A’s point of view: what it receives and where.

Tag	Name	Status	Format	Meaning
32B	Currency, Amount	M	3!a15d	The currency and amount party A buys, that is, receives. Comma as decimal mark; no more decimals than the currency allows. Precious metal codes (XAU, XAG, XPD, XPT) are rejected: metals use category 6.
53a	Delivery AgentOptions A or J	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] J: 5*40x	The institution from which party B will pay the amount bought, when the payer wants to say where the funds come from.
56a	IntermediaryOptions A or J	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] J: 5*40x	An intermediary institution between the delivery agent and the receiving agent, when there is one.
57a	Receiving AgentOptions A or J	M	A: [/1!a][/34x] 4!a2!a2!c[3!c] J: 5*40x	Where party A receives the amount bought: its own account if it services itself, or its correspondent, with the account number when needed. Option J with /NOSI/ and a code covers cases with no explicit agent: SSIS (standing settlement instructions), NETS (netted), NONE (no settlement), UKWN (not yet known), NDFS (non-deliverable leg of an NDF) or CLRD (cleared through a CCP).

Sequence B2Amount SoldMandatory

From party A’s point of view: what it pays and where party B receives it.

Tag	Name	Status	Format	Meaning
33B	Currency, Amount	M	3!a15d	The currency and amount party A sells, that is, pays.
53a	Delivery AgentOptions A or J	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] J: 5*40x	The institution from which party A will pay the amount sold, when it wants to tell party B.
56a	IntermediaryOptions A or J	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] J: 5*40x	An intermediary institution for the amount sold, when there is one.
57a	Receiving AgentOptions A or J	M	A: [/1!a][/34x] 4!a2!a2!c[3!c] J: 5*40x	Where party B receives the amount sold: party B itself or its correspondent, with an account number when needed, or /NOSI/ with a code in option J.
58a	Beneficiary InstitutionOptions A or J	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] J: 5*40x	The institution in whose favour the payment is made when it is not party B, for example a third-party payment to an affiliate. Option A with a BIC is recommended where possible.

Sequence COptional General InformationConditional

Not match-critical information. The sequence is optional, but mandatory (with 88a) when 94A is BROK.

Tag	Name	Status	Format	Meaning
15C	New Sequence	M	Empty field	Opens sequence C.
29A	Contact Information	O	4*35x	Who to contact about the deal, with codes such as /NAME/, /DEPT/, /PHON/.
24D	Dealing Method	O	4!c[/35x]	How the deal was agreed: BROK (voice broker), ELEC (electronic system), FAXT, PHON or TELX, optionally followed by more detail.
84a	Dealing Branch Party AOptions A, B, D or J	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] B: [/1!a][/34x] [35x] D: [/1!a][/34x] 435x J: 540x	The branch of party A that dealt, when it is not party A itself.
85a	Dealing Branch Party BOptions A, B, D or J	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] B: [/1!a][/34x] [35x] D: [/1!a][/34x] 435x J: 540x	The branch of party B that dealt, when it is not party B itself.
88a	Broker IdentificationOptions A, D or J	C	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 435x J: 540x	The voice broker that arranged the deal. Mandatory when 94A is BROK. Electronic platforms go in 24D, not here.
71F	Broker's Commission	C	3!a15d	The brokerage fee. Only allowed on a broker confirmation (94A is BROK).
26H	Counterparty's Reference	O	16x	The counterparty’s own reference for the deal, if known. Useful for matching but not a matching field.
21G	Broker's Reference	O	16x	The broker’s reference for the deal.
72	Sender to Receiver Information	O	6*35x	Additional information in the `/8c/` code format, for example /TIME/ or /VENU/. It must not carry UTI codes (use sequence E) or the old NDF codes.

Sequence DSplit Settlement DetailsConditional

Present only when 17U is Y. The block 17A to 58a repeats once per part (some structure listings call it subsequence D1), then 16A closes the sequence. Used when an amount is too large to settle in one payment; the beneficiary is the same for every part.

Tag	Name	Status	Format	Meaning
15D	New Sequence	M	Empty field	Opens sequence D.
17A	Buy (Sell) IndicatorRepeatable	M	1!a	For each part: Y when party A receives this amount, N when party A pays it.
32B	Currency, AmountRepeatable	M	3!a15d	The currency and amount of this part of the settlement.
53a	Delivery AgentOptions A, D or JRepeatable	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 435x J: 540x	Where the funds for this part come from.
56a	IntermediaryOptions A, D or JRepeatable	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 435x J: 540x	An intermediary for this part.
57a	Receiving AgentOptions A, D or JRepeatable	M	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 435x J: 540x	Where this part is received.
58a	Beneficiary InstitutionOptions A, D or JRepeatable	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 435x J: 540x	The beneficiary institution for this part, when it is not the counterparty.
16A	Number of Settlements	M	5n	The total number of parts, after the last one. It must equal the number of repetitions of the block 17A to 58a.

Sequence EReporting InformationOptional

Data for trade repository reporting (EMIR, CFTC and other regimes). Meant for reporting, although the UTI and prior UTI may also travel on ordinary confirmations. The repeating reporting party block E1 comes first, then the fields listed under "Reporting Information, continued".

Tag	Name	Status	Format	Meaning
15E	New Sequence	M	Empty field	Opens sequence E. At least one other field of the sequence must follow.

Sequence E1Reporting PartiesOptional, repeatable

Repeats once per reporting jurisdiction.

Tag	Name	Status	Format	Meaning
22L	Reporting Jurisdiction	M	35x	The regulator or regime to which the trade is reported, for example ESMA, FCA, CFTC, SEC, ASIC, HKMA, JFSA, MAS or FMIA. With OTHR, name the jurisdiction in 77A.
91a	Reporting PartyOptions A, D or J	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 435x J: 540x	The party responsible for reporting the trade.

Sequence E1aUnique Transaction IdentifierOptional, repeatable

Repeats when a trade has more than one UTI for the jurisdiction.

Tag	Name	Status	Format	Meaning
22M	UTI Namespace/Issuer Code	M	30x	The first part of the UTI: the code of the entity that created it, often its LEI.
22N	Transaction Identifier	M	32x	The second part of the UTI. Together with 22M it identifies the trade for the regulator, and both sides must report the same value.

Sequence E1a1Prior Unique Transaction IdentifierOptional, repeatable

Tag	Name	Status	Format	Meaning
22P	PUTI Namespace/Issuer Code	M	30x	Issuer part of a prior UTI, for example the block trade before allocation or the trade before a novation.
22R	Prior Transaction Identifier	M	32x	Identifier part of the prior UTI.

Sequence EReporting Information, continuedOptional

The rest of sequence E, after the last E1 block. All fields are optional; field codes for the one-letter indicators are defined per regime in the standard.

Tag	Name	Status	Format	Meaning
81a	Central Counterparty Clearing House (CCP)Options A, D or J	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 435x J: 540x	The CCP that clears the trade.
89a	Clearing BrokerOptions A, D or J	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 435x J: 540x	The clearing broker, for a cleared trade.
96a	Clearing Exception PartyOptions A, D or J	O	A: [/1!a][/34x] 4!a2!a2!c[3!c] D: [/1!a][/34x] 435x J: 540x	The party claiming an exception from the clearing obligation.
22S	Clearing Broker IdentificationRepeatable	O	1!a/35x	An identifier of the clearing broker, with a one-letter qualifier.
22T	Cleared Product Identification	O	35x	The product identifier used by the clearing house.
17E	Clearing Threshold Indicator	O	1!a	Y or N: whether the contract is above the clearing threshold. Needed for non-financial counterparties under EMIR.
22U	Unique Product Identifier	O	12x	The product identifier. Until SR 2023 this was a 6-letter code such as FXFORW or FXNDFO; SR 2024 widened it to 12 characters for ISO 4914 unique product identifiers and SR 2025 corrected the character set.
35B	Identification of Financial Instrument	O	[ISIN1!e12!c] [4*35x]	An ISIN and/or description of the instrument, when one exists.
17H	Allocation Indicator	O	1!a	A (post-allocation), P (pre-allocation) or U (unallocated).
17P	Collateralisation Indicator	O	1!a	Whether and how the trade is collateralised, as a one-letter code.
22V	Execution Venue	O	35x	Where the trade was executed: a BIC, LEI or MIC.
98D	Execution Timestamp	O	8!n6!n[,3n][/[N]2!n[2!n]]	Execution date and time in UTC, optionally with milliseconds and a UTC offset.
17W	Non Standard Flag	O	1!a	Y when the trade has non-standard terms.
22W	Link Swap Identification	O	42x	One reference shared by the near and far legs of an FX swap, which are confirmed in two separate MT300s.
17Y	Financial Nature of the Counterparty Indicator	O	1!a	Whether the counterparty is a financial or non-financial entity, as a one-letter code.
17Z	Collateral Portfolio Indicator	O	1!a	Y when the trade is collateralised on a portfolio basis, which makes 22Q mandatory.
22Q	Collateral Portfolio Code	C	10x	The code of the collateral portfolio. Mandatory when 17Z is Y.
17L	Portfolio Compression Indicator	O	1!a	Y when the trade results from portfolio compression.
17M	Corporate Sector Indicator	O	1!a	The corporate sector of the counterparty as a one-letter code, for regulatory reporting.
17Q	Trade with Non-EEA Counterparty Indicator	O	1!a	Y when the counterparty is outside the European Economic Area.
17S	Intragroup Trade Indicator	O	1!a	Y for a trade between two entities of the same group.
17X	Commercial or Treasury Financing Indicator	O	1!a	Y when the trade reduces risk linked to commercial activity or treasury financing.
98G	Confirmation Timestamp	O	8!n6!n[,3n][/[N]2!n[2!n]]	When the trade was confirmed.
98H	Clearing Timestamp	O	6!n[,3n][/[N]2!n[2!n]]	The time the trade was cleared.
34C	Commission and FeesRepeatable	O	4!c/[N]3!a15d	A type of commission or fee (for example CHAR, EXEC, TOTL) with its currency and amount, or PCT and a rate. Repeats to give a breakdown. It reports the charge, it does not instruct its payment.
77A	Additional Reporting Information	O	20*35x	Any further information the regulator needs, ideally with a code such as /ESMA/ or /CFTC/. Also names the jurisdiction when 22L is OTHR.

Sequence FPost-Trade EventsOptional

Confirms a lifecycle event on an earlier trade, such as an early delivery, rollover or unwind of a forward.

Tag	Name	Status	Format	Meaning
15F	New Sequence	M	Empty field	Opens sequence F.
21H	Event Type and Reference	M	4!c/16x	The event and field 20 of the MT300 it applies to. Events: EAMT (early delivery), PEAM (partial early delivery), PRUR (partial unwind and rollover), PRUW (partial unwind), ROLL (rollover), UNWD (unwind) and UNWR (unwind and rollover).
21F	Underlying Liability Reference	O	16x	A reference to the underlying exposure, for example the commercial trade being hedged.
30F	Profit and Loss Settlement Date	O	8!n	When the profit or loss from the event settles, if not on the value date of the trade.
32H	Profit and Loss Settlement Amount	O	[N]3!a15d	The profit or loss actually settled. Positive (no sign): party A pays; with the N sign: party A receives.
33E	Outstanding Settlement Amount	O	3!a15d	After a partial early delivery or partial unwind, the amount still to settle, in the bought or sold currency.

Format notation: n digits, a upper-case letters, c upper-case letters and digits, x any character of the Swift character set, d a decimal number with a comma, ! fixed length, [ ] optional, 4*35x up to 4 lines of 35 characters. M mandatory, O optional, C conditional (a rule decides).

Rules worth knowing

Field 21 is mandatory when 22A is AMND or CANC and optional for NEWT, DUPL and EXOP (network rule C1, error D70).
Sequence C is mandatory, with field 88a, when 94A is BROK. Field 71F (broker’s commission) is only allowed with BROK (rule C2, error D74).
Sequence D is mandatory when 17U is Y and not allowed otherwise (rule C3, error D76). Field 16A must equal the number of settlement parts (error D96).
If 17F is Y, 17O is mandatory, otherwise 17O is not allowed. With 17O Y, fields 32E, 30U and at least one 14S are mandatory, 26K is optional and 21A is not allowed. With 17O N, 21A is mandatory and 32E, 30U, 14S and 26K are not allowed (rules C7 and C8, error C87). Field 35C needs 17F Y and the code XXX in 32B or 33B (rule C9).
Field 22C: the BIC codes must be the sender’s and receiver’s (error T95), in alphabetical order with letters before digits (T96), and the four digits must come from field 36 as described above (T22).
Field 14S may occur at most twice (error T10). Lines of 77D and codes in 72 must not use /VALD/, /SETC/, /SRCE/ or /FIX/ (error T70).
In every optional sequence or subsequence, its mandatory fields must be present when it is used (C32). Sequence E must contain at least one field besides 15E (C98), and 17Z Y requires 22Q (C56).
Amounts use a comma as decimal mark, with no more decimals than the currency allows (C03, T40, T43). The metal codes XAU, XAG, XPD and XPT are not allowed (C08): use the category 6 messages.
A cancellation (22A CANC) cancels both the earlier confirmation and the underlying contract. An amendment replaces the earlier message and must contain all its fields, changed and unchanged.

MT300 example

On 20 October 2026 ZagTrader Test Bank, Dubai (ZAGTAEADXXX) buys EUR 5,000,000.00 one month forward from BANKGB2LXXX in London at 1,08712, paying USD 5,435,600.00 on 20 November 2026. ZagTrader receives the euros at its correspondent BANKDEFFXXX and pays the dollars from its New York branch to BANKGB2L’s correspondent BANKUS33XXX. The deal is under an ISDA master agreement and reportable in the UK, so the confirmation carries a UTI. BANKGB2L sends its own MT300 with the roles reversed and the same 22C.

{1:F01ZAGTAEADAXXX0000000000}{2:I300BANKGB2LXXXXN}{4:
:15A:
:20:ZTFX2610200417
:22A:NEWT
:94A:BILA
:22C:BANK2L8712ZAGTAD
:82A:ZAGTAEADXXX
:87A:BANKGB2LXXX
:77H:ISDA/20150612//2002
:15B:
:30T:20261020
:30V:20261120
:36:1,08712
:32B:EUR5000000,
:57A:BANKDEFFXXX
:33B:USD5435600,
:53A:ZAGTUS33XXX
:57A:BANKUS33XXX
:15C:
:24D:PHON
:15E:
:22L:FCA
:22M:549300ZAGTTEST000001
:22N:ZTFX261020000417
-}

Decode this example in the parser

Line by line

Line	What it says
{1:F01ZAGTAEADAXXX0000000000}{2:I300BANKGB2LXXXXN}{4:	Sender ZAGTAEADXXX, input MT300 to BANKGB2LXXX, normal priority.
:15A:	Start of sequence A: an empty field.
:20:ZTFX2610200417	ZagTrader’s reference for this confirmation.
:22A:NEWT	New confirmation, so field 21 is not needed.
:94A:BILA	Sender and receiver are the principals (same meaning as leaving 94A out).
:22C:BANK2L8712ZAGTAD	BANK2L and ZAGTAD in alphabetical order, around 8712: the rightmost non-zero digit of the rate 1,08712 and the three digits before it.
:82A:ZAGTAEADXXX	Party A: ZagTrader, the sender.
:87A:BANKGB2LXXX	Party B: the counterparty.
:77H:ISDA/20150612//2002	Covered by an ISDA master agreement signed 12 June 2015, 2002 version. No 14C, so the 1998 FX Definitions apply.
:15B:	Start of sequence B.
:30T:20261020	Trade date.
:30V:20261120	Value date: one month forward.
:36:1,08712	Exchange rate, USD per EUR.
:32B:EUR5000000,	Subsequence B1: party A buys (receives) EUR 5,000,000.00.
:57A:BANKDEFFXXX	Where ZagTrader receives the euros: its correspondent in Frankfurt.
:33B:USD5435600,	Subsequence B2: party A sells (pays) USD 5,435,600.00, that is 5,000,000 x 1.08712.
:53A:ZAGTUS33XXX	The dollars come from ZagTrader’s New York branch.
:57A:BANKUS33XXX	Where BANKGB2L receives the dollars: its New York correspondent.
:15C:	Sequence C: optional information that is not matched.
:24D:PHON	Deal agreed by phone.
:15E:	Sequence E: reporting information.
:22L:FCA	Subsequence E1: reportable to the UK FCA.
:22M:549300ZAGTTEST000001	Subsequence E1a: UTI namespace, here the (fictitious) LEI of the UTI generator.
:22N:ZTFX261020000417	UTI transaction identifier. BANKGB2L must report the same UTI.
-}	End of block 4.

BICs, references, the LEI and the UTI are made up.

BANKGB2L’s matching confirmation has BANKGB2LXXX as party A, buys USD 5,435,600.00 in B1 (57A BANKUS33XXX) and sells EUR 5,000,000.00 in B2 (57A BANKDEFFXXX), with the same 22C BANK2L8712ZAGTAD.

Settlement instructions shown are illustrative. In practice they come from each party’s standing settlement instructions.

Common errors and rejects

Common reference 22C rejected or different on each side (T22, T95, T96)
The usual causes: the four digits taken from the wrong end of the rate (they come from the rightmost non-zero digit of field 36), the BIC codes not in alphabetical order, or codes built from party A and party B instead of the sender and receiver when an agent or broker sends the message. If the network accepts both but the two sides used different rates (for example one booked 1,0871 and the other 1,08712), the 22C values differ and the confirmations do not pair up. Recheck the booked rate first: a different 22C usually means an economic difference.
Amendment or cancellation without field 21 (D70)
With 22A AMND or CANC the message must say which confirmation it replaces or cancels: put the earlier field 20 in field 21. An amendment must repeat every field of the original, not just the changed ones, because it replaces it.
NDF fields rejected (C87) or old NDF codes in 77D (T70)
The NDF fields only work as a set: 17F Y requires 17O; an opening (17O Y) needs 32E, 30U and 14S and must not have 21A; a valuation (17O N) needs 21A and must not have 32E, 30U, 14S or 26K. Codes such as /VALD/ or /FIX/ in 77D or 72 date from before SR 2017 and are rejected.
Split settlement sequence D rejected (D76, D96)
Sequence D is only allowed, and then required, when 17U is Y. Field 16A must equal the number of parts given in the repeated 17A to 58a blocks.
Confirmations do not match on settlement instructions
Both sides confirm the economics but one quotes a 57A with a BIC and the other a free-text or /NOSI/UKWN instruction, or an outdated correspondent. Agree standing settlement instructions in advance, use option A, and avoid leaving UKWN as a default: industry guidance notes that placeholder values avoid rejection but defeat automated matching.
Metal or invalid currency in 32B or 33B (C08, T52)
Gold, silver, palladium and platinum codes are not allowed in the MT300; precious metal deals use the category 6 messages such as MT600. Any other currency code must be a valid ISO 4217 code with no more decimals than the currency allows.

MT300 in ISO 20022

Swift’s MT and MX equivalence tables (May 2024) give fxtr.014 Foreign Exchange Trade Instruction as the ISO 20022 equivalent of the MT300; it is the only category 3 message with an equivalent listed there. Its defined use is narrower than the MT300’s: a participant sends it to a central settlement system to notify an FX trade agreed by both parties, rather than the two counterparties confirming to each other.

Treasury messages (category 3) were not part of the CBPR+ migration that ended MT/MX coexistence for cross-border payment instructions on 22 November 2025. Bilateral FX confirmations on Swift are still exchanged as MT300s on FIN, and no migration date for them has been announced in the sources we checked.

The payments that settle the deal are a different matter: cross-border MT202 transfers that move the currencies are now exchanged as pacs.009 on Swift.

MT300 questions

What is an MT300?: The Swift Foreign Exchange Confirmation. The two parties to an FX deal (or a money broker) send it to each other to confirm the currencies, amounts, rate, value date and settlement instructions of a spot, forward, swap leg or non-deliverable forward.
How is the common reference in field 22C of an MT300 built?: From the sender’s and receiver’s BICs without the country code (bank code plus location code), placed in alphabetical order, with four digits from the exchange rate between them: the rightmost non-zero digit of field 36 and the three digits before it, zero filled. ZAGTAEAD and BANKGB2L at 1,08712 give BANK2L8712ZAGTAD.
What is the difference between MT300 and MT320?: The MT300 confirms a foreign exchange deal (two currencies exchanged at a rate). The MT320 confirms a fixed-term loan or deposit in one currency, with principal, interest rate and maturity, and its rollover and maturity events.
What is the difference between MT300 and MT304?: The MT300 is the confirmation between the two trading parties. The MT304 is sent by one party, typically a fund manager, to a third party such as its custodian or a CLS settlement member, to advise or instruct the settlement of a deal done with someone else.
How is a non-deliverable forward confirmed with an MT300?: With two confirmations from each side. The opening one has 17F Y and 17O Y with the settlement currency (32E), valuation date (30U) and rate source (14S). The valuation one has 17F Y, 17O N and 21A pointing to the opening confirmation, with the fixing rate in field 36.
Is the MT300 being replaced by ISO 20022?: Not as part of the payments migration. Category 3 treasury messages were outside CBPR+, and the MT300 is still the standard Swift FX confirmation on FIN. Swift lists fxtr.014 as its ISO 20022 equivalent, a trade notification to a central settlement system.

All MT messages · Category 3 messages · ISO 20022 messages · Codes · Troubleshooting