sese.023 Securities Settlement Transaction Instruction

When sese.023 is used

After a trade is executed and confirmed, each side tells its own custodian or CSD participant how to settle it: the seller instructs a delivery, the buyer a receipt. The account owner sends a sese.023 to its account servicer naming the security, the quantity, the trade and settlement dates, the safekeeping account, the settlement chain on both sides and, for a delivery or receipt against payment, the cash amount.

Two elements decide what kind of instruction it is. SttlmTpAndAddtlParams/SctiesMvmntTp says whether securities come in (RECE) or go out (DELI), and SttlmTpAndAddtlParams/Pmt says whether cash moves the other way (APMT, against payment) or not (FREE). RECE + FREE is the MT540, RECE + APMT the MT541, DELI + FREE the MT542 and DELI + APMT the MT543.

The account servicer validates the instruction, forwards it into the market and has it matched against the counterparty’s instruction at the CSD. Every step comes back as a sese.024 status advice (accepted, matched or unmatched, pending or failing settlement, with reason codes) and the final result as a sese.025 confirmation. The full sequence is in the securities settlement lifecycle guide.

In T2S, a CSD or a directly connected participant sends the sese.023 to T2S, and T2S answers with a sese.024 as validation, matching and settlement happen and with a sese.025 once the instruction settles (as described in the T2S UDFS text quoted in change request T2S-0859-SYS).

A sese.023 is not changed or cancelled by sending another sese.023. Cancellation uses the separate cancellation request sese.020, whose status comes back in sese.027; a settled transaction that the account servicer later reverses is reported with sese.026.

Versions in common use

sese.023 key elements

Paths are relative to Document/SctiesSttlmTxInstr. Occurrence is from the base message (sese.023.001.11); market practice such as CBPR+ or a CSD’s rules can make an optional element mandatory or forbid it.

Rules worth knowing

• Four MTs, one MX: the MT message type carries the direction and payment type; in sese.023 both are explicit elements. When translating, check that RECE/DELI and FREE/APMT agree with the MT type, and that an APMT instruction carries SttlmAmt.
• Party sides follow the securities, not you. On a DELI your own chain sits in DlvrgSttlmPties and the counterparty’s chain (with the place of settlement in RcvgSttlmPties/Dpstry) in RcvgSttlmPties. On a RECE it is the other way round. Swapping the sides is a frequent cause of unmatched instructions.
• Settlement parties are numbered outwards from the depository: Pty1 is the participant of the CSD (the agent), Pty2 its client, and so on. The Clearstream instruction specifications for receipts into CEU show exactly this layout: Depository, then Party 1 (delivering agent), then Party 2 (seller).
• In T2S, the mandatory matching fields for a DVP instruction are payment type, securities movement type, ISIN, trade date, settlement quantity, intended settlement date, the delivering and receiving party BICs, the CSDs of both parties, and currency, settlement amount and credit/debit indicator. For FOP the last three do not apply. Additional and optional matching fields (such as the common reference in CmonId) only need to agree once one side fills them in (ECB T2S matching fields presentation).
• Amounts and quantities are XML decimals with a dot. Dates are ISO dates (2026-10-22), date-times carry a UTC offset. The currency is an attribute: <Amt Ccy="AED">.
• ISO 20022 securities messages get new versions through the yearly ISO maintenance releases, and each market infrastructure decides when to adopt one. Market practice is layered: the ISO base message, the SMPG global market practice, the market infrastructure’s usage guidelines and finally each participant’s own rules. Always build to the version and usage guideline your account servicer or CSD publishes.

sese.023 XML example

ZagTrader Test Bank in Dubai (ZAGTAEADXXX, the account owner) sold 10,000 shares of AEZAGT000016 at AED 25.45 on 20 October 2026. It instructs its custodian CUSTAEADXXX, a participant of the local CSD CSDXAEADXXX, to deliver the shares against AED 254,500.00 on 22 October 2026 to the buyer BRKRAEADXXX, whose receiving agent at the same CSD is BANKAEADXXX. Written as an ISO 15022 message, the same instruction would be an MT543; the mapping table below shows each field. Only the Document is shown; the business application header would carry the sender, receiver and message ID.

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:sese.023.001.11">
  <SctiesSttlmTxInstr>
    <TxId>ZTDEL2610200001</TxId>
    <SttlmTpAndAddtlParams>
      <SctiesMvmntTp>DELI</SctiesMvmntTp>
      <Pmt>APMT</Pmt>
    </SttlmTpAndAddtlParams>
    <TradDtls>
      <TradId>ZT-TRD-88412</TradId>
      <TradDt>
        <Dt>
          <Dt>2026-10-20</Dt>
        </Dt>
      </TradDt>
      <SttlmDt>
        <Dt>
          <Dt>2026-10-22</Dt>
        </Dt>
      </SttlmDt>
    </TradDtls>
    <FinInstrmId>
      <ISIN>AEZAGT000016</ISIN>
      <Desc>ZAGTRADER TEST CO ORD SHS</Desc>
    </FinInstrmId>
    <QtyAndAcctDtls>
      <SttlmQty>
        <Qty>
          <Unit>10000</Unit>
        </Qty>
      </SttlmQty>
      <SfkpgAcct>
        <Id>ZAG-SAFE-0001</Id>
      </SfkpgAcct>
    </QtyAndAcctDtls>
    <SttlmParams>
      <SctiesTxTp>
        <Cd>TRAD</Cd>
      </SctiesTxTp>
      <PrtlSttlmInd>PART</PrtlSttlmInd>
    </SttlmParams>
    <DlvrgSttlmPties>
      <Dpstry>
        <Id>
          <AnyBIC>CSDXAEADXXX</AnyBIC>
        </Id>
      </Dpstry>
      <Pty1>
        <Id>
          <AnyBIC>CUSTAEADXXX</AnyBIC>
        </Id>
      </Pty1>
    </DlvrgSttlmPties>
    <RcvgSttlmPties>
      <Dpstry>
        <Id>
          <AnyBIC>CSDXAEADXXX</AnyBIC>
        </Id>
      </Dpstry>
      <Pty1>
        <Id>
          <AnyBIC>BANKAEADXXX</AnyBIC>
        </Id>
      </Pty1>
      <Pty2>
        <Id>
          <AnyBIC>BRKRAEADXXX</AnyBIC>
        </Id>
        <SfkpgAcct>
          <Id>12345678</Id>
        </SfkpgAcct>
      </Pty2>
    </RcvgSttlmPties>
    <SttlmAmt>
      <Amt Ccy="AED">254500.00</Amt>
      <CdtDbtInd>CRDT</CdtDbtInd>
    </SttlmAmt>
  </SctiesSttlmTxInstr>
</Document>

DELI + APMT makes this the MX form of an MT543 (deliver against payment).

Own side: DlvrgSttlmPties holds the CSD and the custodian that delivers (MT :95P::DEAG). Counterparty side: RcvgSttlmPties holds the place of settlement (:95P::PSET), the receiving agent (:95P::REAG) and the buyer with its account (:95P::BUYR with :97A::SAFE).

PrtlSttlmInd PART allows partial settlement. The sese.024 and sese.025 pages follow this same instruction through a lack of securities and a partial settlement of 6,000 shares.

CdtDbtInd is CRDT because the seller receives the cash. The buyer’s matching receipt instruction carries RECE and DBIT.

All BICs, the ISIN (check digit valid) and the accounts are made up.

sese.023 and its MT equivalent

sese.023 is the ISO 20022 counterpart of four ISO 15022 messages. The MT message type carries what the MX states in two elements: MT540 = RECE + FREE, MT541 = RECE + APMT, MT542 = DELI + FREE, MT543 = DELI + APMT. The status replies map the same way: MT548 becomes sese.024, and the confirmations MT544 to MT547 become sese.025.

There is no general MT-to-MX deadline for securities settlement. Category 5 messages were not part of Swift’s November 2025 move of cross-border payment instructions to ISO 20022 and remain in use on FIN alongside their ISO 20022 equivalents. T2S and the CSDs and participants that connect to it directly work in ISO 20022 (sese and semt), so MT54x users reach T2S through a CSD or custodian that translates. See ISO 20022 migration: securities versus payments.

A translation is rarely one to one in both directions. The MX can carry data the MT cannot (an LEI on each party, more party levels, newer elements such as the unique transaction identifier in later versions), and MT narrative fields have no exact MX home. Check translated instructions for lost data before they reach matching.

Common errors and rejects

1. Unmatched: counterparty data differs (NMAT)

   Your instruction is accepted but stays NMAT. The reason code names the field: DDAT settlement date, DQUA quantity, DSEC security, DMON amount, DEPT place of settlement, ICAG agent. Compare your trade confirmation with the counterparty, correct whoever is wrong and cancel and re-instruct if needed. CMIS means no counterparty instruction was found at all.

   How to fix it

2. Rejected at validation (REJT)

   The account servicer cannot process the instruction: unknown or invalid ISIN (DSEC), safekeeping account not recognised (SAFE), settlement transaction type not allowed (SETR), settlement date invalid (DDAT) or place of settlement unknown (DEPT). Fix the data and send a new sese.023 with a new TxId.

   How to fix it

3. Settlement parties on the wrong side

   For a DELI the counterparty belongs in RcvgSttlmPties; for a RECE in DlvrgSttlmPties. Converting from MT by copying REAG into the delivering block, or forgetting the depository on the counterparty side, produces agent or place of settlement mismatches.

   How to fix it

4. Amount, currency or direction does not match

   SttlmAmt must agree with the counterparty’s amount within the market’s tolerance, in the same currency, and with the opposite CdtDbtInd. A missing amount on an APMT instruction or a DBIT on a delivery against payment ends in DMON or NCRR.

   How to fix it

5. Matched but not settling (LACK, MONY)

   Once matched, the instruction can still pend: LACK when your account lacks the securities, MONY when cash or credit is short, CLAC or CMON when the counterparty is short. Partial settlement only helps if PrtlSttlmInd allows it on both sides.

   How to fix it

6. Sent after the cut-off (LATE, ADEA)

   An instruction received after the market deadline (LATE) or the account servicer’s deadline (ADEA) may be rejected or settle a day late, which can trigger settlement fail penalties where they apply. Send instructions as soon as the trade is confirmed.

   How to fix it

Related messages

• sese.024Securities Settlement Transaction Status Advice
• sese.025Securities Settlement Transaction Confirmation
• MT540Receive Free
• MT541Receive Against Payment
• MT542Deliver Free
• MT543Deliver Against Payment
• MT548Settlement Status and Processing Advice
• MT537Statement of Pending Transactions
• semt.017Securities Transaction Posting Report

• Unmatched instruction (NMAT)
• From instruction to settled position: MT540-548, sese.023/024/025 and the statements that follow.
• Securities messages stay on ISO 15022 alongside ISO 20022 after the November 2025 payments switch; the MT to MX map.

Codes used in sese.023

• TRAD
• REPU
• SECL
• NMAT
• ICAG
• LACK

sese.023 questions

What is the difference between sese.023 and MT540, MT541, MT542 and MT543?

They carry the same instruction. The four MTs differ only in direction (receive or deliver) and payment (free or against payment). sese.023 is one message with SctiesMvmntTp (RECE or DELI) and Pmt (FREE or APMT). For example an MT543 is a sese.023 with DELI and APMT.

Which sese.023 version does T2S use?

T2S has used sese.023.001.11 since release R2026.JUN (business day 15 June 2026); before that it used sese.023.001.09. Release R2026.NOV moves it to sese.023.001.13; Clearstream reports that deployment as postponed to business day 30 November 2026. Check your CSD’s release notes for the exact cut-over.

Where does the place of settlement (PSET) go in sese.023?

In the depository of the counterparty’s side: RcvgSttlmPties/Dpstry on a delivery, DlvrgSttlmPties/Dpstry on a receipt. The agents (:95P::REAG and :95P::DEAG in the MT) are Pty1 on the matching side.

How do I cancel a sese.023?

Send a cancellation request (sese.020) quoting the instruction’s reference. Its status comes back in sese.027. Once both sides’ instructions are matched, many markets need both parties to cancel; until then the instruction may show the cancellation as pending (CANP).

Is sese.023 replacing MT54x settlement instructions?

Not on a fixed date. Securities messages were outside Swift’s November 2025 payments deadline and MT540 to MT543 remain in use on FIN. sese.023 is required where the infrastructure works only in ISO 20022, such as T2S for directly connected parties, and is offered by many CSDs and custodians alongside the MTs.

What does PrtlSttlmInd do in a settlement instruction?

It says whether the instruction may settle in parts when not enough securities or cash are available: PART yes, NPAR no, PARQ or PARC only above a minimum quantity or cash value. Each partial settlement is confirmed in a sese.025 that shows the quantity still to settle.