ISO 20022 sese.023

A sese.023 message sits after capture, enrichment, allocation, and settlement routing decisions. Upstream systems provide the trade economics. Reference-data systems provide the instrument, account, counterparty, custodian, CSD, market, currency, and calendar data. The standing settlement instructions workflow provides the approved route and party chain. The instruction engine maps those records into a structured settlement payload.

The message quality depends on the source data. A stale SSI, invalid safekeeping account, wrong place of settlement, mismatched security identifier, missing account-servicer data, or malformed party identifier can turn a clean-looking trade into a rejected instruction or manual repair item. ISO 20022 gives the payload structure. It does not rescue bad reference data.

The status boundary matters. SWIFT training material groups settlement instruction, status advice, and confirmation around sese.023, sese.024, and sese.025. The business meaning is different in each step. sese.023 instructs. sese.024 reports processing status. sese.025 confirms settlement. Internal ledgers should not move a trade to final settled state only because the instruction was emitted.

Co-existence with legacy MT54x flows creates a separate control problem. Many operating models still sit between ISO 20022-capable internal systems and older sub-custodian, local-market, or intermediary connections that require ISO 15022-style MT messages. Translation can lose information when rich XML elements are compressed into flatter MT field structures. Party details, account strings, matching references, and settlement indicators that are explicit in a sese.023 payload may be truncated, remapped, or pushed into qualifier-style fields during conversion. The workflow should therefore retain the original sese.023 data, the translated outbound form, and the validation result for both sides of the conversion.

The value of sese.023 is not only XML structure. It creates an auditable instruction record. A strong workflow should show which trade created the message, which SSI version populated the route, which validation checks passed, who released or approved the instruction where required, what external status came back, and what confirmation or exception closed the lifecycle.

The first step is trade linkage. The system needs a stable source obligation: trade ID, account, instrument, side, quantity, intended settlement date, allocation state, and confirmation or affirmation dependency. Where market practice or regulation requires a Unique Transaction Identifier, the UTI should be generated, preserved, or consumed as part of the matching reference set rather than treated as optional text. If the source trade is still ambiguous, the instruction should not be generated.

The second step is enrichment. The instruction needs instrument master data, account data, counterparty data, settlement method, market calendar, custodian or depository route, and the active SSI version. This is where settlement instruction automation either creates a clean payload or exposes the data gap before it reaches the market. In a T+1 cycle, the instruction engine should be able to generate and validate the payload within minutes of trade-date allocation, confirmation, and affirmation, so settlement processing is not pushed into late repair.

The third step is validation. The generated XML should be checked for required fields, structure, party and account formatting, dates, duplicate references, UTI or matching reference where required, settlement method, cash amount and currency where applicable, and market-practice expectations. A schema-valid message may still fail a business rule. A business-readable route may still fail XML validation. Both checks are needed.

The fourth step is release control. Low-risk instructions may flow automatically when all gates pass. High-value, late, amended, free-of-payment, manually repaired, or policy-sensitive instructions may require maker-checker review. A resend or retry should be governed by deterministic references so a timeout does not create duplicate live instructions.

The fifth step is response monitoring. The instruction may be acknowledged, accepted, matched, unmatched, pending, rejected, cancelled, failed, recycled, or confirmed, depending on the account servicer and market. The internal workflow should map those states back to the original trade, not bury them in messaging logs.

The sixth step is books handoff. A firm should update expected cash and position projections when the instruction is sent, but final books should wait for appropriate external proof. In an ISO 20022 securities settlement flow, that proof is commonly represented by settlement confirmation, not the original sese.023 instruction. This separation protects straight-through processing workflow metrics, failed trade settlement controls, and trade reconciliation evidence.