sese.032 — Securities Trade Status Query

The status query on a pending transaction. When the asset manager wants to know where its trade stands (executed, matched, allocated, settled) before triggering downstream actions, it asks via sese.032 — answer expected within the minute via sese.024 or sese.030.

Purpose and place in the flow

sese.032 is an active status request: the buy-side (account owner) queries the sell-side (broker, custodian, CSD) about the current state of a transaction. Three typical cases:

• Automated polling — the buy-side ETL periodically queries (every 5-15 min) open transactions to detect status changes between pushed messages.
• Manual investigation — middle office sees a stuck transaction and wants precise status before escalation.
• Audit/Compliance — extraction of a frozen state for regulatory archiving (T+5 obligation for some regulators).

sese.032 is pull as opposed to pushed messages (sese.024, sese.030). On modern markets (CHIPS, T2S), push is real-time and pull becomes marginal; it remains essential for emerging markets or less-connected sub-custodians.

XML structure

• QryRef — Query Reference: unique request identifier.
• TxIdDtls — identifiers of the queried transaction.
• FinInstrmId — ISIN.
• TradDt — trade date for disambiguation.
• RqstrDtls — Requestor Details (BIC of requester).
• QryDtls — Query Details: query type (TRDS = trade status, SETT = settlement status…) and scope flags.

Key fields

• QryRef/Ref — unique identifier of this query (to carry over to the answer).
• TxIdDtls/AcctOwnrTxId and CtrPtyTxId — the transaction concerned (at least one of the two is enough).
• QryDtls/QryTp/Cd — type (TRDS, SETT, MTCH, ALOC…).
• QryDtls/RqstdSts and RqstdMtchSts — flags for what to see.

XML example

BNP Paribas queries Northern Trust on 16 May 2026 about the status of the 15 May Apple transaction (internal ref BNPP-ORD-20260515-001). Request includes general status and matching status:

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:sese.032.001.04">
  <SctiesTradStsQry>
    <QryRef>
      <Ref>BNPP-QRY-20260516-AAPL-001</Ref>
    </QryRef>
    <TxIdDtls>
      <AcctOwnrTxId>BNPP-ORD-20260515-001</AcctOwnrTxId>
      <CtrPtyTxId>NTRS-CONF-20260515-AAPL-001</CtrPtyTxId>
    </TxIdDtls>
    <FinInstrmId>
      <ISIN>US0378331005</ISIN>
    </FinInstrmId>
    <TradDt>
      <Dt>
        <Dt>2026-05-15</Dt>
      </Dt>
    </TradDt>
    <RqstrDtls>
      <Id>
        <AnyBIC>
          <AnyBIC>BNPAFRPP</AnyBIC>
        </AnyBIC>
      </Id>
    </RqstrDtls>
    <QryDtls>
      <QryTp>
        <Cd>TRDS</Cd>
      </QryTp>
      <RqstdSts>true</RqstdSts>
      <RqstdMtchSts>true</RqstdMtchSts>
    </QryDtls>
  </SctiesTradStsQry>
</Document>

• QryRef/Ref — unique request identifier (to be carried in the answer for matching).
• TxIdDtls — the queried transaction, identified by both bilateral references.
• QryDtls/QryTp/Cd = TRDS — Trade Status (general).
• RqstdSts = true + RqstdMtchSts = true — full request: status + match status.

Common pitfalls

• Excessive polling — querying the same transaction every 30 seconds is an anti-pattern. Agree on a reasonable frequency (1-5 min) or use push.
• Too-generic TxId — without a precise identifier, the recipient cannot answer. Always provide at least an AcctOwnrTxId or CtrPtyTxId.
• Short timeout — some recipients (emerging sub-custodians) take 2-5 minutes to answer. Configure broad ETL timeouts (10 min) to not lose late responses.
• No unique QryRef — without a unique QryRef, two queries on the same transaction are indistinguishable in the returned answers.
• sese.024 confusion — sese.024 is PUSHED by the recipient (spontaneous status); sese.032 is PULLED by the requester. Do not send a sese.024 in response to a sese.032 but a sese.024 marked "query response".

Related messages

• sese.023 — Settlement Instruction.
• sese.024 — Settlement Status Advice (possible answer).
• sese.030 — Trade Confirmation (possible answer).
• SWIFT MT: MT599 (free format) or proprietary bilateral query.