Devancore Inc.
Devancore Post-Trade Glossary
Glossary
Trade Blotter Post Trade Workflow
A trade blotter post-trade workflow turns blotter rows into governed operating records for allocation, enrichment, confirmation, settlement instruction, exception management, reconciliation, supervision, and audit evidence.
Document source: https://devancore.com/glossary/trade-blotter-post-trade-workflow/
Devancore Post-Trade Glossary
Trade Blotter Post Trade Workflow
A trade blotter post-trade workflow turns blotter rows into governed operating records for allocation, enrichment, confirmation, settlement instruction, exception management, reconciliation, supervision, and audit evidence.
Definition
A trade blotter post-trade workflow turns a blotter row into a governed operating record. The blotter is where many users understand the workflow because it shows the trade, its current status, and the next action. In institutional operations, that row should do more than display price and quantity. It should show whether the trade is captured, allocated, enriched, matched, affirmed, instructed, failed, repaired, reconciled, approved, and retained with evidence.
The control problem is that a blotter can look complete while the underlying record is not ready. A trade may appear on the screen after execution, but still lack account-level allocation, current SSI, custodian route, fee treatment, confirmation agreement, settlement status, or reconciliation evidence. A blotter without controlled state is only a view. A blotter with state, owner, and evidence becomes an operating workbench.
Blotter workflow states
Blotter workflow states
A trade blotter becomes useful when every row carries state, owner, and evidence.
| State | What it means | Control question |
|---|---|---|
| Captured | Trade received from OMS, EMS, broker API, FIX message, file, or manual source | Can the row be traced to the source event? |
| Allocated | Block trade split by fund, account, strategy, sleeve, custody path, and fee treatment | Is each account-level record complete and approved? |
| Enriched | Instrument, counterparty, SSI, custodian, cash account, fee, settlement method, and market data added | Can the trade be instructed without manual repair? |
| Matched | Broker, counterparty, or matching utility agrees with economics and allocation detail | Which fields are agreed, disputed, or missing? |
| Instructed | Settlement instruction sent or queued to custodian, CSD, bank, broker, or network | Does the instruction reflect the approved blotter record? |
| Exceptioned | Break, missing data, dispute, stale status, failed instruction, or manual correction requires ownership | Who owns the issue, and what evidence supports the action? |
| Closed | Trade settled, reconciled, consumed by book of record, and retained with evidence | Can the lifecycle be reconstructed from the row? |
The first responsibility of the workflow is source lineage. Each row should point back to the order, fill, broker response, execution message, manual entry, correction, or imported file that created it. Lineage matters because post-trade questions usually begin with a simple problem: which source record produced this row?
Allocation gives the row operational meaning. A block trade may need to become several account-level trades across funds, strategies, sleeves, custodians, settlement locations, and fee treatments. If allocation is corrected after capture, the workflow should preserve the original value, amended value, user, reason, approval, and downstream impact.
Enrichment determines whether the row can move toward settlement. The blotter should show which trades lack instrument data, counterparty data, current standing settlement instructions, cash account, custody path, CSD route, commission, tax lot context, or other settlement-critical fields. Missing enrichment should create an owned exception, not an informal reminder.
Matching and affirmation move the row from internal record to external agreement. The blotter should show whether the broker or counterparty agrees with economics, allocation, fees, settlement date, and settlement instructions. Unmatched and unaffirmed trades should be visible by cutoff, materiality, counterparty, owner, and reason.
Settlement status should be part of the same workflow. A trade that is instructed, pending, partially settled, failed, repaired, settled, or final has different operational meaning. If status sits in a separate custodian report, users have to reconcile the workflow by hand.
Books-and-records evidence depends on history. A strong blotter preserves the original record, amendments, approvals, comments, status changes, source messages, and downstream references. Without that history, a reviewer sees the final row but not the path that produced it.
Trade blotter — row to controlled state
Devancore Glossary · devancore.com
Trade blotter — row to controlled state
Devancore Glossary · devancore.com
How it works
A trade blotter post-trade workflow works by using the blotter as an action surface. Users should be able to identify what requires work, understand why it requires work, act within permissioned controls, and leave a record of the action.
Blotter control checklist
Blotter control checklist
A post-trade blotter should expose the checks that determine whether a trade can move forward.
| Control area | Data required | Evidence output |
|---|---|---|
| Source lineage | Order ID, execution ID, fill, broker, venue, timestamp, raw message | Trace from blotter row to source trade |
| Allocation control | Block, fund, account, strategy, custodian, allocation method, approver | Account-level trade with change history |
| Enrichment control | Instrument master, counterparty, SSI, custodian account, cash account, fees | Settlement-ready record or missing-data exception |
| Agreement control | Confirmation, match status, affirmation, broker response, DK reason | Matched, disputed, corrected, or unaffirmed state |
| Settlement control | Instruction, route, status, fail reason, repair action, intended settlement date | Pending, failed, repaired, settled, or final state |
| Supervision control | Owner, comment, reason code, maker-checker approval, timestamp | Reviewable audit trail |
Capture brings the trade into the blotter. The source may be an OMS, EMS, broker API, FIX message, file, matching utility, manual input, or correction feed. The row should carry source system, source identifier, timestamp, user or process, and raw message reference.
Validation tests whether the row can be worked. The system should check required fields, duplicate risk, instrument status, account eligibility, counterparty mapping, settlement calendar, currency, and trade-date versus settlement-date logic. A row that fails validation should not silently proceed.
Allocation turns the row into the right account-level records. The workflow should show whether the allocation is pending, applied, corrected, rejected, approved, or transmitted. If a user changes an allocation after confirmation, the blotter should make the correction visible because downstream settlement and accounting records may need repair.
Enrichment prepares the row for agreement and instruction. Standing settlement instructions, custodian accounts, cash accounts, broker codes, CSD routes, fees, and reference data should be attached before the trade moves to confirmation or settlement instruction.
Matching and affirmation establish whether the external party agrees. The blotter should distinguish matched, unmatched, alleged, affirmed, disputed, DK, corrected, cancelled, and resubmitted states where those states apply. The goal is not simply to show a red row. The goal is to tell the operator what action is required.
Exception management converts breaks into owned work. A price difference, quantity mismatch, missing SSI, stale status, failed instruction, unmatched allocation, or rejected settlement should have cause, owner, priority, aging, comment, evidence, and resolution path. Breaks near settlement cutoff or with material cash impact should be visible before lower-risk items.
Supervision and audit run across the workflow. Maker-checker controls, approval thresholds, entitlement limits, reason codes, timestamps, comments, attachments, and status history should travel with the row. A correction without a reason weakens the row. An exception with clear cause, owner, and evidence strengthens it.
In Devancore™
Trade blotter — control risks
Devancore · risk register
Stale row
mediumCause Status does not update after broker, custodian, or matching utility response.
Control Event-driven status history with owner and timestamp.
Uncontrolled correction
highCause Price, account, allocation, SSI, or fee is changed without approval trail.
Control Maker-checker workflow, reason code, and amended-record history.
Missing settlement data
highCause Trade is captured but lacks current SSI, custodian account, or cash leg.
Control Pre-instruction validation and missing-data exception queue.
Weak evidence
mediumCause Comments, confirmations, repair actions, and downstream impacts live outside the row.
Control Evidence package attached to the workflow record.
Devancore supports trade blotter post-trade workflows by treating the blotter row as a controlled operating record. The platform should be framed as workflow and evidence infrastructure for post-trade teams, not as an execution venue, broker, custodian, clearing broker, adviser, accountant, or compliance owner.
In a Devancore-style workflow, each trade row carries source lineage, normalized data, workflow state, exception status, owner, approval history, downstream references, and evidence. The record can connect trade capture, allocation, enrichment, confirmation, settlement instruction, reconciliation, accounting handoff, supervision, and reporting inputs.
This gives operations teams a practical way to manage the day. They can see trades captured but not allocated, allocations changed after execution, trades missing SSIs, confirmations that remain unmatched, settlement instructions pending release, failed trades requiring repair, reconciliations blocked by missing external data, and rows that need supervisory review.
Conversational finance works well on top of a governed blotter because users ask operational questions in plain language. A user may ask which high-value trades are unaffirmed, which rows need SSI repair, which allocation corrections are waiting for approval, which settlement fails affect cash, or which trades are ready for accounting handoff. The answer should resolve to rows, status, owners, and evidence.
The practical value is not the screen itself. It is the controlled state behind the screen. A blotter should help the firm prove what happened to each trade from capture through close.
Related terms
- Trade Capture System
https://devancore.com/glossary/trade-capture-system/
The system that books an executed trade into the firm's official records and initiates the post-trade processing workflow from enrichment and matching through to settlement instruction.
- Trade Break Management
https://devancore.com/glossary/trade-break-management/
The exception workflow for identifying, classifying, and resolving post-trade discrepancies before they breach the T+1 affirmation cutoff or trigger CSDR cash penalties.
- Straight-Through Processing (STP)
https://devancore.com/glossary/straight-through-processing/
End-to-end automation of the post-trade lifecycle from execution to DvP settlement, with STP rate as the primary compliance KPI under T+1.
- Broker-Dealer Audit Trail
https://devancore.com/glossary/broker-dealer-audit-trail/
The immutable, chronologically linked record of every trade lifecycle event — from order receipt through settlement — maintained to satisfy SEC Rules 17a-3 and 17a-4, FINRA clock synchronization requirements, and CAT reporting obligations.
- Trade Enrichment Automation
https://devancore.com/glossary/trade-enrichment-automation/
The automated augmentation of a raw trade capture with settlement instructions, counterparty identifiers, and regulatory fields required for clearing and settlement.
- Trade Confirmation Matching
https://devancore.com/glossary/trade-confirmation-matching/
The automated comparison of trade details between counterparties to verify both sides recorded the same economics before settlement instructions are generated.
- Trade Reconciliation
https://devancore.com/glossary/trade-reconciliation/
The systematic comparison of internal trade and position records against external sources to identify breaks and resolve them before they become settlement failures.
- Trade Allocation
https://devancore.com/glossary/trade-allocation/
Post-execution process that splits a block trade into account-level positions, each generating a separate confirmation and settlement obligation.
- Settlement Instruction Automation
https://devancore.com/glossary/settlement-instruction-automation/
Automatically generating and transmitting settlement instructions to custodians and CSDs using pre-loaded SSI data — replacing manual entry, enabling STP, and making T+1 compliance operationally viable.
- Standing Settlement Instructions
https://devancore.com/glossary/standing-settlement-instructions/
Pre-agreed instructions specifying how a counterparty's securities and cash should be delivered or received, applied automatically to every qualifying trade.
- Trade Matching
https://devancore.com/glossary/trade-matching/
Bilateral comparison of independently submitted trade records that either confirms settlement-readiness or surfaces the field-level mismatch producing a trade break.
- Same-Day Affirmation (SDA)
https://devancore.com/glossary/same-day-affirmation/
The completion of allocation, confirmation, and affirmation in DTCC CTM by the 9:00 PM ET industry benchmark on trade date — the operational requirement under SEC Rule 15c6-2 that enables automatic DTC settlement instruction generation for T+1.
- Failed Trade Settlement
https://devancore.com/glossary/failed-trade-settlement/
A trade that does not settle on its contractual settlement date because one party cannot deliver the required securities or cash, triggering penalties and buy-in procedures.
- Trade Break Resolution
https://devancore.com/glossary/trade-break-resolution/
The process of resolving data mismatches between trade counterparties before settlement cutoffs to prevent settlement fails.
- Middle Office Software
https://devancore.com/glossary/middle-office-software-securities/
The control layer between execution and settlement that automates trade validation, compliance monitoring, allocation, IBOR maintenance, and exception management in real time under T+1 and hybrid digital asset workflows.
- Post-Trade Operations Software
https://devancore.com/glossary/post-trade-operations-software/
Technology automating post-execution back-office workflows — trade capture, confirmation, settlement, reconciliation, position management, and regulatory compliance.
- OMS To Post Trade Integration
https://devancore.com/glossary/oms-to-post-trade-integration/
OMS to post-trade integration is the controlled handoff from order and execution records into allocation, confirmation, enrichment, settlement instruction, reconciliation, supervision, and reporting workflows.
- Front To Back Investment Lifecycle
https://devancore.com/glossary/front-to-back-investment-lifecycle/
The front to back investment lifecycle is the controlled workflow from investment intent, order, execution, allocation, confirmation, settlement, position, accounting, reconciliation, and reporting evidence.
Contact
Request a briefing or platform walkthrough with the Devancore team.
Request access https://devancore.com/access/