Devancore Inc.
Devancore Post-Trade Glossary
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.
Document source: https://devancore.com/glossary/oms-to-post-trade-integration/
Devancore Post-Trade 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.
Definition
OMS to post-trade integration is the controlled handoff from order and execution systems into post-trade operations. The practical question is simple: can the firm prove that the trade being allocated, confirmed, settled, reconciled, and reported is the same trade that was ordered and executed?
An order management system can hold portfolio intent, order state, routing instructions, block trades, fills, broker responses, and execution status. Post-trade teams need more than that. They need account-level allocations, instrument and counterparty mapping, settlement instructions, custodian routing, confirmation status, affirmation status, reconciliation evidence, exception ownership, and reporting lineage.
OMS handoff control points
OMS handoff control points
The handoff is strongest when each field has a source, owner, state, and evidence trail.
| Record area | What moves downstream | Control question |
|---|---|---|
| Order and fill | Order ID, execution ID, broker, venue, side, price, quantity, timestamp, commission, and source message | Can the post-trade record be traced back to the executed order? |
| Block and allocation | Block trade, fund, account, strategy, sleeve, allocation method, allocation timestamp, and approval state | Did each account receive the correct economics and settlement path? |
| Instrument and counterparty | ISIN, CUSIP, FIGI, internal identifier, legal entity, broker code, counterparty, and market | Do front-office identifiers resolve to settlement and accounting records? |
| Settlement data | SSI, custodian account, CSD, depository participant, cash account, settlement method, and intended settlement date | Can the trade be instructed without manual repair? |
| Agreement state | Confirmation, match status, affirmation, DK reason, allocation dispute, fee dispute, and correction history | Do the firm and counterparty agree before the settlement window closes? |
| Evidence | Raw message, normalized record, validation result, exception owner, approval, status update, and downstream consumption | Can a reviewer reconstruct the full handoff without asking each team? |
The first control point is lineage. A downstream trade record should point back to the OMS order, execution, fill, and source message. If the accounting record cannot be traced to the execution record, every later review becomes a reconstruction exercise.
Allocation is where execution becomes operationally specific. A block trade may be valid at execution while still incomplete for post-trade. Each fund, account, strategy, sleeve, custodian, fee treatment, and settlement location needs its own controlled record. Changes after execution should preserve who changed the allocation, when, why, and what downstream records were affected.
Enrichment turns a captured trade into a settlement-ready record. The system adds standing settlement instructions, custodian account, CSD or depository path, cash account, settlement method, counterparty codes, fees, tax lot context, and instrument reference data. A trade that is correct in the OMS can still fail if enrichment is stale or missing.
Confirmation and affirmation test external agreement. The firm, broker, custodian, matching utility, and administrator may each hold a view of the trade. The integration should show whether economics match, whether allocation details agree, whether fees are disputed, whether SSI data is valid, and whether the trade can move toward settlement.
Reconciliation gives the handoff evidence. Internal trade, cash, position, and accounting records should be compared against broker, custodian, bank, CSD, administrator, and ledger records. Breaks should be classified by cause, owner, materiality, timing, and downstream impact.
The point of OMS to post-trade integration is not only moving data. It is preserving state. A professional operating model shows which trades are captured, allocated, enriched, matched, affirmed, instructed, pending, failed, repaired, settled, reconciled, adjusted, approved, closed, and reported.
OMS to post-trade — controlled handoff
Devancore Glossary · devancore.com
OMS to post-trade — controlled handoff
Devancore Glossary · devancore.com
How it works
OMS to post-trade integration works by converting order and execution events into a controlled operating record. The workflow begins with an order or fill and ends when the trade has either reached a clean downstream state or entered a supervised exception path.
System boundary map
System boundary map
OMS integration should preserve boundaries while giving post-trade teams enough state to control the record.
| Layer | Primary role | Post-trade dependency |
|---|---|---|
| OMS | Order creation, model context, route instruction, block lifecycle, and execution state | Order and fill lineage |
| EMS or broker API | Execution routing, fill capture, venue and broker response, partial fill status | Executable source event |
| Post-trade workflow | Trade capture, enrichment, allocation validation, confirmation, affirmation, settlement instruction, and fail monitoring | Controlled operating record |
| Custody and settlement | Custodian, CSD, bank, SWIFT, ISO 20022, DTC, or other settlement path | External settlement status |
| Books and reporting | IBOR, ABOR, PBOR, regulatory input, management reporting, and audit package | Traceable downstream output |
The OMS creates or receives the order record. It may hold model context, account restrictions, portfolio target, route instruction, broker selection, pre-trade rule result, and execution state. Those details matter after execution because a reviewer may need to understand why the trade exists and which instruction authorized it.
The execution layer produces fills. A fill may arrive through a FIX execution report, broker API, EMS event, drop copy, allocation message, or file feed. Partial fills and multi-day fills require careful state handling because they may produce several downstream allocation and settlement records from one order.
Trade capture records the execution in the post-trade environment. The capture process should identify duplicates, reject malformed events, validate instrument and counterparty data, preserve raw source messages, and assign a workflow state. Capture without lineage creates risk even when the trade economics look correct.
Allocation converts block-level activity into account-level records. A strong integration does not treat allocation as a clerical step. It verifies account eligibility, fund split, custody path, settlement location, fee handling, and approval state. If allocation changes after broker confirmation, the change should be visible as a controlled correction.
Enrichment adds settlement and reference data. Standing settlement instructions, custodian accounts, cash accounts, CSD routes, settlement method, market calendars, instrument identifiers, LEIs, broker codes, and fee schedules determine whether the trade can move through post-trade without manual repair.
Matching, confirmation, and affirmation establish agreement. The integration should track whether the trade is matched, unmatched, affirmed, disputed, corrected, or cancelled. Breaks should be visible before they become settlement fails.
Settlement instruction is the output of the handoff. The instruction can use SWIFT, ISO 20022, DTC, custodian API, broker API, or other network-specific formats. The operational issue is not the message format alone. The instruction must be supported by the right trade, allocation, SSI, cash leg, security leg, approval, and evidence.
Reconciliation closes the loop. Post-trade teams compare the internal record against broker, custodian, bank, administrator, and accounting records. The best integration keeps each break tied to the source order, source message, correction history, and affected downstream output.
OMS integration — message and control map
Devancore · message matrix
| Rail | Message | Purpose | Record |
|---|---|---|---|
| Order | OMS order and route | execution lineage | approved intent, order ID, broker, route, account scope, and rule context |
| Execution | fill or trade capture report | source event | price, quantity, side, timestamp, venue, broker, commission, and source message |
| Allocation | block split | account-level trade | fund, account, strategy, sleeve, custodian, allocation method, and approval status |
| Settlement | instruction payload | delivery readiness | SSI, CSD, custodian account, cash account, settlement method, and intended settlement date |
| Control | exception state | supervision and evidence | break owner, reason code, approval, correction, timestamp, and downstream impact |
In Devancore™
Devancore — OMS handoff evidence chain
Devancore · evidence stack
Source event
The order, fill, block, allocation, correction, or broker response enters with source identifier, timestamp, and raw message reference.
Normalization
The event is mapped to instrument, account, portfolio, entity, counterparty, broker, currency, date, and settlement path.
Control state
The record carries validation result, enrichment status, match status, settlement readiness, exception owner, and approval state.
Downstream record
IBOR, ABOR, reconciliation, supervision, and reporting workflows consume the controlled post-trade state rather than a loose export.
Review package
Audit trail, comments, corrections, source records, and status history remain attached to the handoff.
Devancore supports OMS to post-trade integration by maintaining the controlled operating record after execution. The platform should be framed as a post-trade record and workflow layer that can connect order, execution, allocation, settlement, reconciliation, supervision, and reporting states.
Devancore does not act as an execution venue, broker, custodian, clearing broker, fund administrator, legal adviser, tax adviser, accountant, or compliance owner. Its role is to help teams keep the operational record coherent after front-office activity becomes post-trade work.
In a Devancore-style workflow, an OMS order, fill, block trade, allocation, broker response, custodian status, settlement update, cash event, correction, or cancellation enters as a source event. The record is mapped to instrument, account, portfolio, entity, counterparty, custody path, settlement method, date, currency, and workflow state.
The system can then track whether the event is captured, allocated, enriched, matched, affirmed, instructed, failed, repaired, settled, reconciled, adjusted, approved, or closed. Each transition should retain source evidence, owner, timestamp, reason code, and downstream impact.
This matters for teams that operate across multiple systems. The OMS may know the order. The broker may know the fill. The custodian may know the settlement status. The administrator may know the accounting output. Compliance and supervision may need evidence across all of them. Devancore's value is in the post-trade bridge: one controlled view of the handoff and the evidence behind it.
Conversational finance depends on this structure. A user can ask which trades left the OMS but failed allocation, which fills lack SSIs, which confirmations are unmatched, which settlement instructions are pending, which breaks affect cash, or which reporting outputs depend on corrected trades. The answer should resolve to records, status, and evidence.
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 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.
- 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 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 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 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.
- 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.
- 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.
- FIX Protocol Trade Capture
https://devancore.com/glossary/fix-protocol-trade-capture/
Open financial messaging standard where MsgType 8 Execution Reports trigger real-time trade capture and settlement pipeline processing for broker-dealers.
- FIX Engine Connectivity for Broker-Dealers
https://devancore.com/glossary/fix-engine-connectivity/
The software layer managing FIX session state, message sequencing, heartbeats, and failover for broker-dealers connecting to brokers, venues, and ECNs.
- 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.
- 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.
- 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.
- 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.
- Investment Book of Record
https://devancore.com/glossary/investment-book-of-record/
The IBOR — a real-time position record used by investment managers, capturing unsettled trades, accruals, and corporate actions ahead of custodian confirmation and ABOR settlement.
- Accounting Book of Record
https://devancore.com/glossary/accounting-book-of-record/
The ABOR: custodian-confirmed settled positions used as the authoritative basis for NAV calculation, financial statements, and regulatory reporting.
- 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/