Trade Enrichment Automation

Trade enrichment is the post-execution step in the trade lifecycle in which a raw trade record — which typically contains only the economics captured at execution: instrument, quantity, price, and counterparty — is augmented with the operational and regulatory data required for downstream processing. Enrichment adds standing settlement instructions, custodian account details, Legal Entity Identifier (LEI) and Bank Identifier Code (BIC) codes, ISIN or CUSIP instrument identifiers for the relevant settlement market, settlement date calculated from market conventions and holiday calendars, settlement method, and any regulatory reporting fields required by the applicable regime.

Rule-based enrichment — the process by which configured logic retrieves each data field from the reference data layer based on counterparty, instrument type, and market — is the mechanism that makes straight through processing (STP) possible. A trade that can be fully enriched by rule-based logic flows from execution through confirmation matching and settlement instruction generation without human intervention. A trade that cannot be fully enriched falls out of STP and into manual exception handling. Financial institutions track STP rate — the percentage of trades completing enrichment without manual intervention — as the primary operational metric for evaluating whether their enrichment coverage is adequate. DTCC's T+1 Automation Package positions STP improvement as central to T+1 readiness, and market participants with low STP rates face disproportionate operational risk under compressed settlement cycles.

In a T+1 environment, enrichment must happen rapidly after execution — there is no buffer for manual lookup workflows. A trade that is not enriched before the confirmation matching window closes cannot be affirmed by the 9:00 PM ET SDA deadline, and a trade that misses affirmation carries significantly elevated settlement failure risk. Incomplete or incorrect enrichment is a significant operational driver of settlement fails and regulatory reporting failures — not because trade economics were wrong, but because the operational data required to move the trade through settlement infrastructure was missing or incorrect. For enrichment to work reliably, the reference data it draws from must be accurate and up to date at the moment of enrichment — stale reference data produces enrichment that passes without error but contains incorrect instructions.

At execution, a trade contains the minimum information needed to agree on economics: instrument, quantity, price, and counterparty. Settlement infrastructure requires considerably more. The settlement system needs to know which custodian account to debit, which to credit, through which CSD or settlement network, in which currency, on which date, using which settlement method, and with which regulatory identifiers appended. Enrichment adds all of this automatically by looking up data from the reference data layer rather than requiring operators to enter it manually for each trade.

The enrichment process resolves data from multiple reference data domains simultaneously:

• Standing settlement instructions (SSIs): the counterparty's custodian BIC, account number, and place of settlement for the instrument type — retrieved by counterparty and asset class
• Account and custody details: which internal account holds the position being sold, or should receive the position being bought — retrieved from the account master
• Instrument identifiers: ISIN, CUSIP, SEDOL, or FIGI as required by the destination settlement market — retrieved from the instrument master
• Counterparty identifiers: LEI for regulatory reporting, BIC for settlement routing — retrieved from the counterparty master
• Settlement date: calculated from market settlement convention (T+1, T+2, or same-day) adjusted for market holidays in the relevant calendar — retrieved from the market settlement rules and holiday calendar

Enrichment failure modes are where operational risk concentrates. Each enrichment domain has a distinct failure pattern:

A missing SSI produces an unresolved settlement instruction — the trade cannot proceed to instruction generation until the SSI is established or manually overridden. In T+1, there is often insufficient time to establish a new SSI and verify it through the required out-of-band confirmation process before the affirmation cutoff.

A missing or unresolved LEI may prevent compliant regulatory reporting under applicable regimes — including SEC and FINRA transaction reporting requirements in the US, and MiFID II and EMIR for European-facing operations — even when the trade settles correctly operationally. A counterparty with an expired or invalid LEI creates the same compliance exposure across both jurisdictions.

An incorrect holiday calendar produces a wrong settlement date — the trade is enriched with a settlement date that is a non-business day in the settlement market, likely to be rejected when the instruction reaches the CSD. This failure mode is particularly acute for cross-border trades where the instrument's home market holiday calendar differs from the settlement location's calendar.

For institutional block trades, enrichment must occur at the sub-account allocation level: each allocation must be enriched with its specific custodian details before the industry allocation deadline in institutional equity workflows — commonly referenced as 7:00 PM ET — allowing the broker to generate confirmations ahead of the 9:00 PM ET affirmation deadline. A block trade where sub-account enrichment is incomplete at the allocation stage cannot generate the confirmations required for SDA.

Digital asset enrichment requires wallet addresses and network identifiers rather than BIC and account number pairs. The enrichment failure mode for digital asset settlement on public blockchain networks is materially more severe than for traditional settlement: an incorrect BIC or account number produces a failed settlement that can be investigated and corrected; an incorrect wallet address on most public networks produces a transfer that is extremely difficult or impossible to reverse. Digital asset SSI equivalents — the wallet address and network identifier for each counterparty — must therefore be treated as higher-risk reference data requiring stricter verification controls than traditional SSIs, given the limited or absent recall mechanisms after on-chain settlement completes.