sese.032 — Securities Trade Status Query
L'interrogation de statut sur une transaction en cours. Quand l'asset manager veut savoir où en est sa transaction (executed, matched, allocated, settled) avant de déclencher des actions downstream, il pose la question via sese.032 — réponse attendue dans la minute via sese.024 ou sese.030.
Objet et place dans le flux
sese.032 est une requête de statut active : le buy-side (account owner) interroge le sell-side (broker, custodian, CSD) sur l'état courant d'une transaction. Trois cas typiques :
- Polling automatisé — l'ETL du buy-side interroge périodiquement (toutes les 5-15 min) les transactions ouvertes pour détecter changements de statut entre les pushed messages.
- Investigation manuelle — middle office voit une transaction bloquée et veut un statut précis avant escalade.
- Audit/Compliance — extraction d'un état figé pour archivage réglementaire (T+5 obligation pour certains régulateurs).
sese.032 est pull par opposition aux pushed messages (sese.024, sese.030). Sur les marchés modernes (CHIPS, T2S), le push est temps réel et le pull devient marginal ; il reste essentiel pour les marchés émergents ou les sub-custodians moins connectés.
Structure XML
- QryRef — Query Reference : identifiant unique de la requête.
- TxIdDtls — identifiants de la transaction interrogée.
- FinInstrmId — ISIN.
- TradDt — date de trade pour disambiguer.
- RqstrDtls — Requestor Details (BIC du demandeur).
- QryDtls — Query Details : type de requête (TRDS = trade status, SETT = settlement status…) et flags pour le scope.
Champs clés
QryRef/Ref— identifiant unique de cette requête (à reporter dans la réponse).TxIdDtls/AcctOwnrTxIdetCtrPtyTxId— la transaction concernée (au moins l'un des deux suffit).QryDtls/QryTp/Cd— type (TRDS, SETT, MTCH, ALOC…).QryDtls/RqstdStsetRqstdMtchSts— flags pour ce qu'on veut voir.
Exemple XML
BNP Paribas interroge Northern Trust le 16 mai 2026 sur le statut de la transaction Apple du 15 mai (réf interne BNPP-ORD-20260515-001). Demande inclut statut général et statut de matching :
<?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— identifiant unique de la requête (à reporter dans la réponse pour matching).TxIdDtls— la transaction interrogée, identifiée par les deux références bilatérales.QryDtls/QryTp/Cd = TRDS— type Trade Status (général).RqstdSts = true+RqstdMtchSts = true— demande complète : statut + match status.
Pièges courants
- Polling excessif — interroger toutes les 30 secondes une même transaction est un anti-pattern. Convenir d'une fréquence raisonnable (1-5 min) ou utiliser le push.
- TxId trop générique — sans identifiant précis, le destinataire ne sait pas répondre. Toujours fournir au moins un AcctOwnrTxId ou CtrPtyTxId.
- Timeout court — certains destinataires (sub-custodians émergents) prennent 2-5 minutes à répondre. Configurer des timeouts ETL larges (10 min) pour ne pas perdre les réponses tardives.
- Pas de QryRef unique — sans QryRef unique, deux requêtes sur la même transaction sont indiscernables dans les réponses retournées.
- Confusion avec sese.024 — sese.024 est PUSHED par le destinataire (statut spontané) ; sese.032 est PULLED par le demandeur. Ne pas envoyer un sese.024 en réponse à un sese.032 mais bien un sese.024 marqué comme « réponse à query ».