MT517 Trade Confirmation Affirmation

When MT517 is used

Affirmation closes the trade confirmation loop. The client orders with an MT502, allocates a block with an MT514, receives one MT515 per allocation, checks each against its own records (security, quantity, price, commission, fees, settlement amount, settlement date and chain) and then affirms it with an MT517. If something is wrong, the client does not affirm: it rejects or reports the confirmation as unaffirmed with an MT509 and a reason code. After affirmation, each side instructs its custodian: MT541 or MT543 for against payment trades, MT540 or MT542 for free of payment.

The message is deliberately short. It carries no trade details: it identifies the affirming party (95a::AFFM, mandatory) and points to the confirmation being affirmed through sequence A1, which is mandatory, normally with 13A::LINK//515 and the broker’s SEME in 20C::RELA. By affirming, the client accepts the confirmation exactly as sent; there is no partial or conditional affirmation.

The sender is the instructing party or its authorised representative; the receiver is the institution that sent the confirmation, usually a broker-dealer. An ETC service provider can sit between them. Such a provider can also send an MT517 with 25D::AFFM//FORC, a forced affirmation, to notify that settlement will take place under the rules of its service even though the client did not affirm explicitly.

Why it matters for settlement. With short settlement cycles, unaffirmed trades are a leading cause of late or unmatched settlement instructions. Many markets measure same-day affirmation rates, and an affirmation sent late on trade date leaves little time for the custodians to match before the CSD deadlines.

23G NEWM affirms; 23G CANC withdraws an affirmation sent earlier, with the SEME of that MT517 in 20C::PREV.

MT517 format: sequences and fields

Rules worth knowing

• The MT517 has only sequence A with its linkage sequence A1. Both are mandatory: an affirmation without a link to a confirmation is meaningless.
• 95a::AFFM is mandatory. BUYR, SELL, DEAG, REAG and the alternate identifier (95L::ALTE) are optional.
• When 23G is CANC, an A1 must carry 20C::PREV with the reference of the affirmation being cancelled.
• The structure differs between sources on whether 13a is optional or conditional; the SR 2025 structure used here shows it as optional.

MT517 example

Northwind Asset Management (FUNDGB2LXXX) affirms the MT515 BRK515261020001 that its broker (BRKRAEADXXX) sent for the Gulf Equity Fund allocation of 25,000 shares.

{1:F01FUNDGB2LAXXX0000000000}{2:I517BRKRAEADXXXXN}{4:
:16R:GENL
:20C::SEME//NW517261020001
:23G:NEWM
:98C::PREP//20261020173000
:95P::AFFM//FUNDGB2LXXX
:16R:LINK
:13A::LINK//515
:20C::RELA//BRK515261020001
:16S:LINK
:16S:GENL
-}

Line by line

The manager then instructs the fund’s custodian with an MT541, and the broker instructs its own custodian with an MT543.

All BICs are made up.

Common errors and rejects

1. Affirmation cannot be matched to a confirmation

   A typo in 20C::RELA, or the client’s own reference instead of the broker’s SEME, leaves the affirmation unlinked. The broker may reject it with an MT509 and reason ULNK. Quote the confirmation reference exactly.

2. Affirming a confirmation that was cancelled

   If the broker cancelled and replaced its MT515, an affirmation of the old reference affirms nothing. Affirm the replacement confirmation.

3. Affirmed by mistake

   Affirmation binds both parties. If you affirmed in error, cancel the affirmation (23G CANC with 20C::PREV) at once and agree the correction with the broker before the settlement instructions go out.

4. No affirmation sent on trade date

   An unaffirmed trade often means the settlement instructions are sent late and the custodians’ instructions stay unmatched (CMIS) near the deadline. Monitor unaffirmed confirmations during trade date.

   How to fix it

ISO 20022

Swift’s MT and MX equivalence table (8 May 2024) lists no ISO 20022 equivalent for the MT517.

Category 5 messages were not part of the November 2025 end of coexistence for payments, and the MT517 remains available on FIN. Much affirmation now happens inside ETC service providers, which the standard allows as a route for this message.

Related messages

• MT515Client Confirmation of Purchase or Sale
• MT509Trade Status Message
• MT518Market-Side Securities Trade Confirmation
• MT514Trade Allocation Instruction
• MT502Order to Buy or Sell
• MT541Receive Against Payment
• MT543Deliver Against Payment

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

Codes used in MT517

• CMIS

MT517 questions

What is an MT517 message?

A trade confirmation affirmation: the client tells the broker that it agrees with a trade confirmation, usually an MT515. It binds both parties to the confirmed trade details.

What is the difference between MT517 and MT509?

The MT517 positively affirms a confirmation. The MT509 reports a status, and on the confirmation side it is used to reject a confirmation or report it as not affirmed, with reason codes.

What is a forced affirmation?

An MT517 with 25D::AFFM//FORC, sent by an ETC service provider to notify that settlement will take place under the service’s rules although the client did not affirm itself.

Can I affirm only part of a confirmation?

No. The MT517 carries no trade details and affirms the linked confirmation as sent. If any detail is wrong, reject it with an MT509 and wait for a corrected confirmation.

Is there an ISO 20022 equivalent for MT517?

Swift’s equivalence table lists none. The MT517 remains an MT message on FIN.