Standing Settlement Instructions Workflow

Intake is the first control point. An SSI may arrive through onboarding documents, authenticated portals, counterparty notices, custodian files, standards-based templates, automated utility updates, SWIFT-style notification files, or internal reference-data requests. The workflow should preserve where the request came from, who submitted it, what changed, when it was received, and which account, market, currency, asset class, custodian, CSD, depository, or settlement method it claims to cover. If the firm relies on an external SSI utility or custodian-maintained source, the internal workflow should monitor synchronization state so a street-side update does not remain invisible to the trade enrichment engine.

Normalization turns the request into structured data. A usable SSI cannot be a paragraph in an email or a loose spreadsheet row. It needs defined fields: legal entity, fund, account, counterparty, custodian, local agent, CSD or depository, place of settlement, currency, security type, delivery-versus-payment, receive-versus-payment, free-of-payment, BIC, DTC participant number, account string, effective time, approval status, and version ID. The workflow should reject broad defaults that apply one instruction across incompatible markets or asset classes.

Validation tests whether the route can be used. The system should check identifiers, account formats, market rules, currency scope, security-type eligibility, duplicate instructions, conflicting active records, missing effective dates, and message-schema fit. For ISO 20022 settlement payloads such as sese.023, the workflow should validate destination strings against the required structured fields before release. A route that looks readable to an analyst can still fail if character formatting, field length, account structure, place of settlement, or local agent data cannot map cleanly into the outbound message. The workflow should also distinguish automated validation from business approval. A valid field format does not mean the firm is authorized to use the instruction for live settlement.

Approval turns a draft into governed reference data. New, changed, suspended, or retired SSIs should require independent review when the change can affect asset or cash movement. Maker-checker evidence should show who created the draft, who approved it, what source was reviewed, what changed from the prior version, and when the new version becomes effective. The workflow should not overwrite history. It should create a new version and preserve the old one for as-of trade reconstruction.

Publishing makes the SSI available to trade enrichment and settlement instruction generation. At that point, the trade workflow can attach the active SSI version to a captured trade and generate the correct settlement instruction. Publication should not be treated as a local database write only. The workflow should show whether the active version has reached the systems that enrich trades, generate instructions, monitor settlement status, and report exceptions. The key control is linkage. A later analyst should be able to see which SSI version enriched the trade, which instruction used it, what external status came back, and whether any rejection or fail was tied to routing data.

The workflow begins before a trade exists. Reference-data and operations teams capture SSI requests during onboarding, account setup, custodian change, market expansion, counterparty update, or exception repair. The request remains a draft until the route, scope, and source evidence are clear.

The second step is validation. The system checks whether the instruction is internally complete and externally usable. A securities SSI may need BIC, place of settlement, custodian account, DTC participant number, CSD route, security type, currency, and settlement method. SWIFT and ISO 20022 settlement messaging increase the value of structured data because missing or ambiguous fields can create message rejection, matching breaks, or manual repair.

The third step is governance approval. Because SSIs affect where assets and cash move, the approval path should be stronger than normal data maintenance. A maker can prepare the instruction, but a separate checker should approve activation. Entitlements should control who can draft, validate, approve, publish, suspend, or retire an SSI. A user with read access to SSI data should not automatically have authority to change settlement routing.

The fourth step is versioning. Each active SSI should have an effective timestamp, status, version ID, source reference, maker, checker, and successor relationship where applicable. If an instruction changes after trade capture but before settlement release, the workflow should decide which version applies and preserve the as-of logic. Historical trades need historical SSI truth, not the latest value in the database. Real-time or frequent synchronization with authoritative SSI sources, where available, reduces data drift between the version approved by the street and the version cached inside the firm's enrichment layer.

The fifth step is trade use. During trade enrichment automation, the workflow selects the active SSI for the account, counterparty, market, currency, security type, and settlement method. That version should remain attached to the trade and to the outbound settlement instruction automation event. If the SSI is missing or stale, the trade should stop in an enrichment exception rather than moving forward with a guessed route.

The sixth step is exception feedback. If a matching utility, custodian, CSD, depository, or counterparty rejects an instruction because the route is wrong, the system should not treat the problem as a generic settlement fail. It should link the rejection back to the SSI version, reference-data owner, trade, instruction, and repair action. Under T+1, that feedback loop matters because late SSI repair can consume the time needed for allocation, confirmation, affirmation, and settlement processing. For U.S. institutional activity, clean SSI enrichment is part of the operating engine that helps firms reach trade-date affirmation before the 9:00 PM ET DTC processing cutoff described in DTCC T+1 guidance.

The final step is retirement. SSIs should not remain active forever without review. Custodian changes, account closures, market migrations, legal-entity changes, fund restructures, and repeated rejection patterns should trigger amendment, suspension, or retirement review. Retired instructions should remain available for audit and historical trade reconstruction, but they should not enrich new trades.