Devancore Inc.
Devancore Post-Trade Glossary
Glossary
Broker Dealer Clearing Connector
A broker dealer clearing connector ingests clearing-firm activity, normalizes accounts and instruments, monitors settlement state, and preserves the audit trail used for reconciliation, books and records, and reporting inputs.
Document source: https://devancore.com/glossary/broker-dealer-clearing-connector/
Devancore Post-Trade Glossary
Broker Dealer Clearing Connector
A broker dealer clearing connector ingests clearing-firm activity, normalizes accounts and instruments, monitors settlement state, and preserves the audit trail used for reconciliation, books and records, and reporting inputs.
Definition
A broker dealer clearing connector is the post-trade software layer that keeps an introducing broker-dealer's operating record aligned with its clearing or carrying firm. The practical control problem is simple: the clearing firm posts trades, positions, cash, confirms, rejects, and settlement obligations, while the introducing firm still has to run operations, supervision, books and records, and reporting from a record it can explain.
Execution success does not finish the job. Post-trade processing still has to show what was submitted to the clearing firm, what the clearing firm accepted, what it rejected, which account and instrument it posted, whether the settlement instruction moved, and whether internal positions and cash still agree with the clearing view.
Clearing connector records
Clearing connector records
The connector is useful when each clearing event has a source, a mapped record, a workflow state, and evidence.
| Record area | What the connector holds | Control question |
|---|---|---|
| Trade activity | Trade file, execution event, allocation, cancel, correction, as-of, and source identifier | Can the internal blotter be traced to the clearing-firm submission and response? |
| Account map | Introducing account, clearing account, fully disclosed customer account, or omnibus subledger | Does each internal account resolve to the account the clearing firm actually posted? |
| Instrument map | Internal security ID, CUSIP, ISIN, clearing-firm symbol, and settlement eligibility | Does the connector use the same instrument the clearing firm and CNS used? |
| Stock record | Long, short, in-transit, fail, pledged, and location of securities | Do internal longs and shorts agree with the clearing-firm and CNS position? |
| Cash and money | Free cash, pending settlement, dividends, fees, margin, and money-line activity | Does internal cash agree with the clearing-firm money balances used downstream? |
| Evidence | Raw file or message, ingest time, mapping result, reject reason, owner, approval, and close state | Can operations, FINOP, and supervision reconstruct the event without assembling logs by hand? |
The connector works at software level by ingesting activity, normalizing accounts and instruments, monitoring settlement, preserving an audit trail, and supporting compliance workflows with evidence rather than with a second unofficial ledger. An API for introducing broker dealer clearing can submit trades or retrieve status. File drops can do the same at end of day. In both cases the operating question is whether those payloads became controlled state.
Fully disclosed vs omnibus clearing integration changes the mapping problem, not the need for a connector. In a fully disclosed model, the clearing firm maintains customer-level accounts. The introducing firm still needs a governed copy of activity, rejects, settlement status, and exception history so operations and supervision are not dependent on portal extracts. In an omnibus model, the clearing firm sees an aggregate position. The introducing firm maintains the customer subledger and must be able to show that internal customer records still roll up to the clearing firm's aggregate stock record and cash.
Breaks appear where that mapping is weak. A trade may be executed internally and rejected hours later by the clearing firm. An account number may be valid internally and unknown at the clearing firm. A clearing-firm security identifier may not match the internal CUSIP or ISIN. An allocation may sit in suspense while the clearing firm has already posted a street-side quantity. A stock-record location may show shares as free while the clearing view shows them in fail, pledged, or in transit.
A clearing firm trade file reconciliation workflow is the usual detection point. The internal blotter, allocation record, confirm, reject file, stock record, and money balances should be compared against the clearing firm's trade, position, and cash files. Unmatched rows should become owned exceptions, not overnight reconciling items that disappear into a spreadsheet.
Broker dealer clearing connector — source to evidence
Devancore Glossary · devancore.com
Broker dealer clearing connector — source to evidence
Devancore Glossary · devancore.com
How it works
A broker dealer clearing connector works by converting clearing-firm events into instruction, confirmation, clearing, and settlement state that operations can control. The workflow starts when activity is received and ends when the record is accepted, repaired, settled, or aged as an open exception with evidence.
Clearing connector control points
Clearing connector control points
Breaks usually appear where a source event is accepted without becoming owned workflow state.
| Step | Data required | Failure mode |
|---|---|---|
| Ingest | Trade file, API event, drop copy, confirm, reject, stock record, cash file, and CNS or settlement status | Late, duplicate, truncated, or unattributed source activity |
| Normalize | Account map, instrument map, currency, quantity, price, trade date, settlement date, and side | Identifier mismatch that posts the right economics to the wrong record |
| Match | Internal blotter versus clearing-firm trade file, confirm, and allocation state | Unmatched, DK, partial, or as-of activity sitting outside the operating view |
| Instruct and clear | SSI, settlement instruction, trade matching result, CNS obligation, and instruction status | Instruction sent, acknowledged, or netted without a controlled internal state |
| Reconcile | Stock record, cash, fails, suspense, and clearing-firm position or money files | CNS or cash break with no owner, aging, or source lineage |
| Retain | Source payload, normalized record, correction history, approval, and reporting extract | Books and records or net-capital inputs that cannot be tied back to the clearing event |
Ingest is the first control. Activity may arrive as an end-of-day trade file, a real-time API event, a drop copy, a confirmation, a reject, a stock-record file, a money line, or a CNS or other settlement status. Each source should keep its payload, timestamp, source system, and sequence or file identity. Duplicate, late, truncated, or unattributed activity is a control issue before it is an accounting issue.
Normalization maps the clearing firm's identifiers onto the introducing firm's operating records. Accounts, offices, registered representatives, customer or omnibus structure, instruments, currencies, quantities, prices, trade dates, and settlement dates have to resolve consistently. If the map is wrong, later reconciliation can look like a position break when the real error is a reference-data miss.
Trade matching and confirmation establish agreement. The connector should show whether the internal trade, the clearing-firm trade file, and any customer or street-side confirm describe the same economics. Unmatched, DK, partial fill, cancel, and as-of states need distinct workflow treatment. A correction should preserve the original record, the replacement, the reason, and the approver.
Settlement instruction and clearing state come next. Standing settlement instructions, the generated settlement instruction, matching result, and CNS or other clearing obligation are not the same fact. An instruction can be created, approved, sent, acknowledged, compared, netted, or rejected without the security or cash having moved. The connector should keep workflow status separate from settlement finality evidence.
DTCC CNS stock record reconciliation is the position control for many U.S. equity and related obligations. Continuous Net Settlement nets compared trades into a delivery or receive obligation. The stock record should show what the firm is long or short and where those securities sit: at the clearing firm, at DTC, in transit, in fail, or otherwise constrained. A CNS break, an unallocated suspense quantity, or a location mismatch should age with an owner and a source event.
Exception management is the operating core. A reject received after execution, a failed allocation, a missing SSI, an instrument mismatch, a cash difference, or an as-of repair should create a case: reason code, owner, severity, open time, required action, maker-checker path, and close state. The same evidence supports supervisory review and later reporting. FINRA net capital calculation from clearing files depends on this discipline because unsettled trades, fails, and related balances are inputs. The connector should preserve those inputs and their lineage. The firm's FINOP and computation process remain responsible for the capital determination.
Clearing connector — accept or exception path
Devancore Glossary · devancore.com
Clearing connector — accept or exception path
Devancore Glossary · devancore.com
In Devancore™
Devancore — clearing connector evidence chain
Devancore · evidence stack
Source event
Trade files, API events, confirms, rejects, stock-record lines, cash movements, and settlement status enter with source identifier, timestamp, and payload reference.
Normalized record
Accounts, instruments, quantities, dates, cash, and location are mapped to the introducing firm's operating identifiers.
Workflow state
Accepted, unmatched, rejected, instructed, failed, repaired, settled, or closed remains attached to the source event.
Control trail
Owner, reason code, maker-checker review, correction, and aging stay with the exception rather than in a side spreadsheet.
Downstream use
Operations, supervision, books and records, and reporting consume the same evidence chain.
Devancore supports a broker dealer clearing connector as a post-trade operating record around clearing-firm activity. It can help teams ingest source events, normalize accounts and instruments, keep settlement and exception state, retain reconciliation evidence, and feed reporting and books-and-records workflows from the same chain.
Devancore does not act as a broker-dealer, clearing firm, carrying broker, custodian, execution venue, or compliance owner. It does not clear transactions, carry customer accounts, or determine net capital. Its role is to help keep the introducing firm's operating copy of clearing activity coherent after the clearing firm has posted, rejected, netted, or settled the event.
In a Devancore-style workflow, a trade file, API event, confirm, reject, stock-record line, cash movement, settlement instruction, or CNS status update enters as a source event. The record is mapped to account, instrument, quantity, cash, dates, location, and workflow state. Accepted, unmatched, rejected, instructed, failed, repaired, settled, and closed remain visible with owner, timestamp, reason, and source payload.
That structure is what operations, supervision, and finance actually use. The clearing firm may know the master customer or street-side position. The introducing firm still needs to see which rows failed mapping, which rejects arrived after execution, which CNS or cash breaks are aging, and which corrections were approved. The connector value is the controlled handoff and the evidence behind it.
Conversational finance depends on the same record. A user can ask which clearing rejects are still open, which omnibus subledger accounts do not roll up to the clearing-firm aggregate, which stock-record breaks affect CNS, or which repaired as-of trades still lack approval. The answer should resolve to source files or messages, mapped records, status, owners, and evidence.
Related terms
- Broker-Dealer Compliance Technology
https://devancore.com/glossary/broker-dealer-compliance-technology/
The software layer that enables broker-dealers to meet SEC and FINRA regulatory obligations — books and records, net capital, supervisory controls, and audit trail — through automation rather than manual processes.
- Broker-Dealer Net Capital Rule
https://devancore.com/glossary/broker-dealer-net-capital-rule/
The SEC rule requiring broker-dealers to maintain minimum liquid net capital at all times, calculated under either the Basic Method or the Alternative Method, to support orderly operations and customer protection.
- 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.
- Rule 17a-3
https://devancore.com/glossary/rule-17a-3-books-and-records/
The SEC rule requiring registered broker-dealers to create and maintain current books and records for every securities transaction - including the blotter, general ledger, customer account ledgers, order tickets, and net capital computation.
- 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.
- Regulatory Reporting — Securities
https://devancore.com/glossary/regulatory-reporting-securities/
The post-trade obligation to submit structured trade data — transactions, positions, and order lifecycle events — to regulators under MiFID II, EMIR, Dodd-Frank, and CAT to establish the supervisory record of each trade.
- 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.
- FINRA Supervision Technology
https://devancore.com/glossary/finra-supervision-technology/
FINRA supervision technology is the software infrastructure broker-dealers use to implement, enforce, and document the supervisory controls required under FINRA Rules 3110 and 3120.
- NSCC Continuous Net Settlement
https://devancore.com/glossary/nscc-continuous-net-settlement/
DTCC's central counterparty that novates equity trades, nets obligations multilaterally by CUSIP, and carries unsettled positions until DvP finality at DTC.
- Central Counterparty Clearing (CCP)
https://devancore.com/glossary/ccp-central-counterparty-clearing/
Financial market infrastructure that legally interposes itself as the counterparty to every trade through novation, eliminates bilateral credit risk, and reduces settlement volume through multilateral netting.
- 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.
- 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.
- 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.
- 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.
- Trade Blotter Post Trade Workflow
https://devancore.com/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.
- System of Record Securities Operations
https://devancore.com/glossary/system-of-record-securities-operations/
The authoritative single source of truth for a firm's positions, trades, and accounts — the system of record that all other systems, reports, and compliance functions derive from.
- 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.
- Rule 15c3-3 Customer Protection Rule
https://devancore.com/glossary/rule-15c3-3-customer-protection/
SEC rule requiring broker-dealers to hold customer securities in possession or control and fund the Special Reserve Bank Account through the reserve formula.
- 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.
Contact
Request a briefing or platform walkthrough with the Devancore team.
Request access https://devancore.com/access/