MT509 Trade Status Message

When MT509 is used

The MT509 is the status message of the trade initiation and confirmation flow, the counterpart of what the MT548 is for settlement instructions. In the order direction, the executing party (broker, transfer agent) tells the instructing party what happened to its MT502: received and accepted, rejected with a reason, cancellation done or denied, replacement done. In the confirmation direction, the client (or an ETC service provider acting for it) tells the broker that an MT515 was rejected or is not affirmed, and why. Positive affirmation itself is sent with an MT517. The standard also lets an instructing party send an MT509 to its custodian to update the trade status behind a settlement instruction it sent earlier.

23G says what the status is about. INST reports on an instruction (an order or a confirmation), CAST on a cancellation request, REST on a replacement request. Sequence A1 (LINK) carries the reference of the message being reported on, normally 20C::RELA with the SEME of that message and 13A::LINK with its type (for example 502 or 515).

Sequence A2 (STAT) holds the status in field 25D, and the qualifier says which kind of status it is: IPRC (instruction processing: PACK accepted, REJT rejected, REPR in repair), CPRC (cancellation processing: CAND cancelled, CANP pending, DEND denied, PARF partially filled with the rest cancelled), RPRC (replacement processing: REPL done, PEND, DEND, REJT), MTCH (matching: MACH or NMAT) and AFFM (affirmation: AFFI affirmed or NAFI unaffirmed). Several A2 occurrences can report several statuses at once.

Reasons go in sequence A2a (REAS) inside the status, as 24B with a qualifier that follows the status: REJT for a rejection, NMAT for unmatched, NAFI for unaffirmed and REPR for repair. Typical reason codes are DSEC (financial instrument), SAFE (account), BUSE (type of order), DDAT (settlement date), DQUA (quantity), DDEA (deal price), DMON (settlement amount), EXEC (commission), ULNK (unknown linked reference), REFE (duplicate reference), LATE (market deadline missed) and NARR, with the text in 70D::REAS.

Sequence B (TRADE) can repeat the trade so that the receiver can identify it without the original: direction (22H::BUSE), payment type (22H::PAYM), the security (35B), and quantities or amounts such as the quantity ordered (36B::ORDR), executed so far (PREX), remaining or cancelled (CANC, AFCA) and the related amounts in 19A.

Fund platforms use the MT509 to acknowledge or reject fund subscriptions and redemptions and to report on cancellation requests. A fund order router may also use it to report whether an incoming message passed its own validation.

MT509 format: sequences and fields

Rules worth knowing

• Sequence A with at least one A2 is mandatory. A1, A2a, B, B1 and C are optional; if B is present it must contain 22H::BUSE, 22H::PAYM and 35B.
• Use the 24B qualifier that fits the status in the same A2: REJT reasons with a rejection, NMAT with unmatched, NAFI with unaffirmed, REPR with repair.
• The quantities and amounts in sequence B are conditional under network rules: which ones may appear depends on the status reported. Search for the error code your interface reports, since rule numbers differ between releases.
• A rejection is final: the rejected order or confirmation is not processed. Send a corrected message with a new reference rather than a cancellation of the rejected one.

MT509 example

The broker (BRKRAEADXXX) acknowledges the MT502 buy order NW502261020007 of Northwind Asset Management (FUNDGB2LXXX) for 40,000 shares: the order is accepted for execution.

{1:F01BRKRAEADAXXX0000000000}{2:I509FUNDGB2LXXXXN}{4:
:16R:GENL
:20C::SEME//BRK509261020014
:23G:INST
:98C::PREP//20261020083215
:16R:LINK
:13A::LINK//502
:20C::RELA//NW502261020007
:16S:LINK
:16R:STAT
:25D::IPRC//PACK
:16S:STAT
:16S:GENL
:16R:TRADE
:22H::BUSE//BUYI
:22H::PAYM//APMT
:36B::ORDR//UNIT/40000,
:35B:ISIN AEZAGT000016
ZAGTRADER DEMO PJSC
:16S:TRADE
-}

Line by line

A rejection would carry :25D::IPRC//REJT and, inside the STAT block, a REAS block such as :24B::REJT//DSEC (unknown instrument).

When the manager rejects a confirmation, the direction reverses: the manager sends the MT509 to the broker with :13A::LINK//515, the broker’s SEME in 20C::RELA and a reason such as :24B::REJT//EXEC for a commission it does not accept.

All BICs and the ISIN are made up. The ISIN carries a valid check digit.

Common errors and rejects

1. Status cannot be attached to an order (wrong RELA)

   If 20C::RELA does not carry the exact SEME of the order or confirmation, the receiver’s system cannot link the status and it lands in an exception queue. Always quote the reference exactly as received, and add 13A::LINK with the type.

2. Rejection without a usable reason

   A REJT with only NARR and no 70D text, or a reason qualifier that does not fit the status, leaves the other side guessing. Use the most specific 24B code and add 70D only where it adds facts.

3. Cancellation denied (DEND) after execution

   A cancellation request for an order that has already been executed comes back with 25D::CPRC//DEND. The trade will be confirmed with an MT515; if it must be undone, a new opposite order is needed.

4. Confirmation not affirmed for a commission or amount difference

   A client that disagrees with the commission, fees or settlement amount of an MT515 reports NAFI or a rejection with reasons EXEC, CHAR or DMON. The broker must agree the figures and resend the confirmation (cancel and new).

5. MT509 confused with MT548

   The MT509 reports on orders and confirmations; the status of a settlement instruction (MT540 to MT543) comes in an MT548 from the custodian. A settlement problem such as LACK is never reported in an MT509.

   How to fix it

MT509 in ISO 20022

For investment funds, Swift’s MT and MX equivalence table (8 May 2024) maps the MT509 funds template to setr.016 (OrderInstructionStatusReport) and setr.017 (OrderCancellationStatusReport). Clearstream’s Vestima user guide pairs MT509 INST with setr.016, MT509 CAST with setr.017, and also uses setr.057 (order confirmation status report) and semt.001 (securities message rejection) where an MT509 was used before.

For other trade status reporting the table lists no ISO 20022 equivalent of the MT509, and it remains in use on FIN.

Related messages

• MT502Order to Buy or Sell
• MT513Client Advice of Execution
• MT515Client Confirmation of Purchase or Sale
• MT517Trade Confirmation Affirmation
• MT518Market-Side Securities Trade Confirmation
• MT548Settlement Status and Processing Advice

• From instruction to settled position: MT540-548, sese.023/024/025 and the statements that follow.

Codes used in MT509

• PACK
• REJT
• CAND
• DEND
• MACH
• NMAT

MT509 questions

What is an MT509 message?

A Swift trade status message. It reports whether an order, a cancellation or replacement request, or a trade confirmation was accepted, rejected, cancelled, matched or affirmed, with reason codes when something is wrong.

What is the difference between MT509 and MT548?

The MT509 reports on trade-side messages (orders and confirmations: MT502, MT515, MT518). The MT548 reports on settlement instructions (MT540 to MT543) and comes from the custodian.

Who sends an MT509?

Both sides. The broker or transfer agent sends it to the client about orders; the client or its ETC service provider sends it to the broker about confirmations it rejects or has not affirmed.

Does an MT509 affirm a trade?

It can report an affirmation status (25D::AFFM//AFFI), but positive affirmation of a confirmation is normally sent with an MT517. The MT509 is mostly used for rejections and for the status of orders and requests.

What is the ISO 20022 equivalent of MT509?

For fund orders, setr.016 (order instruction status report) and setr.017 (order cancellation status report). For other trade status there is no equivalent in Swift’s equivalence table.