Trade Settlement Instruction
The standing settlement instruction (SSI) database containing counterparty settlement details — including custodian accounts, BIC codes, account numbers, and the effective dates and validation rules that determine how each trade type with each counterparty should settle.
Why This Object Matters for AI
AI cannot predict settlement failures or auto-affirm trades without a validated SSI database; without it, every trade requires manual lookup of 'where does this counterparty want us to deliver securities or cash.'
Transaction Processing & Operations Capacity Profile
Typical CMC levels for transaction processing & operations in Financial Services organizations.
CMC Dimension Scenarios
What each CMC level looks like specifically for Trade Settlement Instruction. Baseline level is highlighted.
Settlement instructions live in the heads of operations staff and in email chains. When a new trade needs to settle, someone asks 'where does Goldman want us to deliver?' and the answer depends on who you ask. Different desks have different versions of counterparty SSIs saved in personal folders. A trade fails because the securities desk used an old BIC code that was changed six months ago — nobody communicated the update.
None — AI cannot validate settlement instructions, predict failures, or auto-affirm trades because no machine-readable SSI database exists. Every trade settlement requires a human to look up or recall the correct delivery details.
Create a central SSI register — even a shared spreadsheet listing counterparty name, trade type, custodian, account number, BIC code, and effective date for each set of standing settlement instructions.
A shared spreadsheet lists SSIs for the major counterparties — counterparty name, security type, custodian, account number, and BIC. But the spreadsheet has 200 rows with no version control, and three people maintain different tabs. Some entries are current, some are six months stale. FX SSIs are in one tab, equities in another, and fixed income instructions are 'in the email from last March.' When a trade fails, operations checks the spreadsheet, then checks email, then calls the counterparty to confirm.
AI could read the spreadsheet to look up SSIs, but cannot trust the data because there is no version control, no effective dates, and no validation that the instructions are still current. Using stale SSIs for automated settlement would cause more failures than it prevents.
Standardize the SSI database with mandatory fields — counterparty legal entity, trade type, asset class, custodian BIC, account number, sub-account, effective date, expiry date, and validation status — and establish a single authoritative source.
Settlement instructions are maintained in a dedicated SSI database with standard fields: counterparty LEI, trade type, asset class, custodian, BIC code, account number, effective date, and last validation date. The database is the designated source for settlement details. However, the SSI database is disconnected from the trade processing system — operations staff look up the SSI, then manually enter settlement details on the trade. Transcription errors account for a measurable percentage of settlement failures.
AI can look up the correct SSI for a given counterparty and trade type, and flag instructions that have not been validated recently. Cannot auto-populate trade settlement fields because the SSI database is not integrated with the trade processing workflow.
Integrate the SSI database with the trade capture and settlement systems so that validated settlement instructions auto-populate on trades based on counterparty and trade type — eliminating manual lookup and transcription.
The SSI database is integrated with trade processing. When a trade is captured, the system automatically looks up the correct settlement instruction based on counterparty, asset class, and settlement market. SSIs include custodian chains, intermediary agents, and split settlement rules for complex counterparties. Operations can query 'show me all SSIs for Goldman Sachs across all asset classes with their last validation date and any pending updates' and get a complete, reliable answer.
AI can auto-affirm trades by matching incoming confirmations against the SSI database, predict settlement failures by identifying mismatches between trade instructions and standing SSIs, and flag counterparties with high SSI change frequency. Straight-through processing rates increase significantly.
Formalize the SSI database as an entity in a structured ontology with explicit relationships to counterparty master data, custodian network maps, settlement market rules, and historical failure patterns — enabling AI to reason about SSI validity beyond just field matching.
Settlement instructions are formal entities in a structured ontology with validated relationships to counterparty legal entity hierarchies, custodian network topologies, settlement market calendars, historical failure patterns, and regulatory requirements. An AI agent can ask 'for this emerging market counterparty, which custodian chain has the lowest historical fail rate for local-currency government bonds settling on T+1?' and get a precise, data-driven answer traversing the SSI knowledge graph.
AI can autonomously manage the SSI lifecycle — validating instructions against counterparty changes, recommending optimal custodian chains based on historical performance, and auto-routing settlement instructions for new trade types based on ontology-driven rules. Full autonomous settlement enrichment for standard flows.
Implement real-time SSI context streaming — counterparty SSI changes, custodian network updates, and settlement market rule changes flow into the SSI entity the moment they occur, enabling the system to react to changes before the next trade settles.
Settlement instructions are living entities in a dynamic knowledge graph that self-maintain based on operational events. When a counterparty changes custodians, the SSI entity updates and all affected in-flight trades are re-evaluated automatically. When a settlement market changes its cut-off rules, every SSI for that market adjusts. The SSI is not a static lookup table — it is a continuously optimizing model of how each trade with each counterparty should settle, informed by real-time market conditions.
Fully autonomous settlement instruction management. AI maintains, validates, and optimizes SSIs in real-time. The system predicts SSI changes before counterparties formally notify, based on patterns in custodian network shifts and market structure evolution.
Ceiling of the CMC framework for this dimension.
Capabilities That Depend on Trade Settlement Instruction
Other Objects in Transaction Processing & Operations
Related business objects in the same function area.
Transaction Record
EntityThe atomic record of each financial transaction — containing transaction type, amount, currency, originator, beneficiary, value date, settlement status, and the complete audit trail from initiation through final settlement across all payment and securities systems.
Nostro Account Position
EntityThe real-time and expected balance position for each correspondent banking account — containing current balance, pending debits and credits, expected settlement flows, and the reconciliation status against internal ledgers and counterparty statements.
Exception Case
EntityThe structured record of each processing exception requiring investigation — containing the triggering transaction, exception type, priority, assigned investigator, resolution steps taken, root cause code, and the time-to-resolution metrics that drive operational performance.
Payment Network Configuration
EntityThe managed definition of available payment rails and their characteristics — including network identifiers (ACH, Fedwire, SWIFT, RTP), cutoff times, fee schedules, speed tiers, and the routing logic that determines which network to use for each payment type and urgency level.
Cash Position Forecast
EntityThe multi-horizon projection of cash flows by currency and account — containing expected inflows, outflows, settlement obligations, and the confidence intervals that treasury uses for liquidity planning and intraday funding decisions.
Transaction Routing Rule
RuleThe codified logic that determines how transactions flow through processing systems — including routing criteria (amount, currency, urgency, counterparty), system capacity thresholds, failover paths, and the priority rules when multiple valid routes exist.
Operational Capacity Plan
EntityThe staffing and system resource plan based on forecasted transaction volumes — containing volume projections by transaction type, staffing requirements, system scaling triggers, and the contingency plans for volume spikes like month-end or market volatility events.
What Can Your Organization Deploy?
Enter your context profile or request an assessment to see which capabilities your infrastructure supports.