Position Reconciliation Software
Software that automates daily comparison of internal position records against custodian statements, prime broker reports, and on-chain ledger state, surfacing breaks before they affect Rule 15c3-3 determinations, NAV, or securities count obligations.
Definition
Position reconciliation is the discipline of verifying state rather than events. Where trade reconciliation confirms that every transaction was correctly captured, position reconciliation confirms that the cumulative result of all those transactions — what the firm actually holds, by security and account — is accurately reflected in the books and records and matches what custodians, prime brokers, and regulators can independently confirm.
Position vs. trade reconciliation
The distinction matters operationally. A firm can reconcile every trade record cleanly — every execution report matched, every booking confirmed — and still carry a position break caused by a corporate action applied at a different ratio by the custodian, a failed settlement that aged past the expected settlement date without a correcting entry in the internal record, or a prime broker netting arrangement that produced a different quantity than the firm's gross position record shows. Position breaks represent the net error state of the ledger. They are often invisible to trade reconciliation systems because they do not correspond to any single unmatched transaction event. The two systems are complementary, not substitutes. Securities reconciliation software addresses both — but the position reconciliation layer is where ledger integrity is ultimately verified.
The regulatory foundation
For broker-dealers, position reconciliation is not operational housekeeping — it is a regulatory prerequisite. SEC Rule 15c3-3 (the Customer Protection Rule) requires broker-dealers to maintain possession or control of all fully paid and excess margin customer securities. At each daily computation, the firm must determine whether it holds a surplus or a deficit: the number of customer shares it cannot account for in permissible locations. An unreconciled position discrepancy can cause a firm to compute a deficit as a surplus — treating shares it does not actually control as satisfying the possession-or-control requirement. Undetected deficits are among the most serious findings an examination can produce. Position reconciliation software transforms the daily possession-or-control determination from a calculation performed on potentially stale books into one performed on a verified, current position record.
SEC Rule 17a-13 creates a parallel obligation: broker-dealers must conduct a count, comparison, and record verification of all securities held, comparing against their own books and records and against accounts at every clearing agency and custodian where securities are maintained, at least once per calendar quarter. Daily automated reconciliation makes the quarterly count a confirmation rather than a discovery exercise — and the daily reconciliation log provides the documentary record that the quarterly count draws from. Rule 17a-3 requires creation and maintenance of accurate securities transaction, position, and customer account records; the reconciliation log is the operational evidence that those records are current and verified.
The shadow accounting problem
In the absence of effective position reconciliation software, operations teams frequently maintain parallel spreadsheet-based position records — shadow books — to compensate for latency, gaps, or granularity limitations in the official system of record. Shadow accounting is operationally rational in the short term and structurally dangerous over time. Shadow books diverge from the official record, operate without approval workflows or audit trails, and produce a documented gap between what the firm uses internally and what it reports externally. Effective securities reconciliation software significantly reduces the operational need for shadow accounting by making the official record accurate and timely enough that no parallel book provides additional value — and introduces only the risk of an unexplained discrepancy with the record regulators rely on.
Multi-source position data
Position data sources — formats and break risk
| Position Source | Data Format | Update Frequency | Primary Break Risk |
|---|---|---|---|
| OMS / internal record | Internal trade events | Real-time | Booking errors, unmatched allocations |
| Custodian (MT535/MT536) | SWIFT statement | End-of-day | Corporate action gaps, settlement timing |
| Prime broker report | CSV / proprietary | End-of-day | Short position mismatches, financing |
| DTC / NSCC (CSD) | Proprietary files | End-of-day | Failed settlement reflection |
| On-chain ledger | Custody API / indexer | Continuous | Finality lag, chain reorg |
A securities operation typically maintains positions across multiple external sources simultaneously: one or more custodians, a prime broker, a CSD, and — for firms with digital asset exposure — on-chain vaults or custodied wallets. Each source has its own format, latency, and settlement reference time. Normalizing across them before comparison is a prerequisite for reliable results: a mismatch in CUSIP-to-ISIN mapping or a misaligned account hierarchy generates phantom breaks indistinguishable from genuine discrepancies until manually investigated.
Corporate action complexity
Corporate actions are among the most common sources of persistent position breaks that trade reconciliation does not detect — alongside settlement fails and securities lending recalls. Every corporate action must be processed simultaneously by the firm's internal system and by each custodian, applying the same entitlement at the same reference date. Discrepancies in ratio, record date, or election outcome for voluntary events produce position differences that do not match any pending settlement instruction and will not self-resolve. Left uninvestigated, these breaks distort the firm's net position records and, for broker-dealers, can produce a systematic misstatement of net capital that accumulates until the entitlement error is corrected. Automated corporate action scrubbers — comparing internal entitlement calculations against custodian-confirmed event terms — are a prerequisite for preventing this break category from becoming a permanent feature of the reconciliation queue.
Hybrid inventory
For firms with both traditional securities and digital asset holdings, position reconciliation must span two fundamentally different settlement infrastructures. Traditional positions are confirmed through custodian MT535/MT536 statements on a daily batch cycle. Digital asset positions are confirmable continuously through custody platform ledgers, node indexers, and blockchain analytics APIs. Reconciliation against on-chain state must be anchored to a confirmed block height rather than the most recent block, to prevent phantom breaks caused by chain reorganizations on probabilistic finality networks. The two rails must be modeled separately within the reconciliation engine so that finality-lag breaks are not misclassified as booking errors.
Position reconciliation — daily data flow
Devancore Glossary · devancore.com
Position reconciliation — daily data flow
Devancore Glossary · devancore.com
How it works
1. Data ingestion
The reconciliation run begins with data collection from all configured position sources: custodian SWIFT MT535/MT536 statements for each custodian relationship, prime broker position reports, DTC Participant Position Reports and NSCC CNS position files, and on-chain balance queries against custody platform ledgers or node indexers for digital asset holdings. Ingestion is coordinated around each source's publication schedule. A custodian statement arrives after the market close; prime broker reports arrive on a separate cycle; on-chain state is queryable at any time. The system logs the timestamp and source reference for every external record ingested, providing the data provenance required for audit documentation.
2. Identifier normalization
Before comparison, all position records must be mapped to a common identifier scheme. Custodian MT535/MT536 statements use ISIN; internal OMS records may use CUSIP or proprietary instrument IDs; prime broker reports may use SEDOL or ticker; on-chain positions require token contract address and chain identifier. A maintained security master — mapping every identifier variant to a canonical internal representation — is a prerequisite for reliable reconciliation. Normalization failures produce phantom breaks classified as identifier mapping errors, which are distinguishable from genuine position discrepancies once the security master is corrected but consume investigation time until they are.
3. Reference time alignment
All sources must be aligned to a consistent position reference time before comparison. An internal record snapshot taken at 4:00 PM compared against a custodian statement reflecting the 3:00 PM settlement cutoff will produce breaks from activity in the intervening window. The reconciliation engine applies the agreed cutoff time as a filter on each source and records the applied reference times in the run log.
4. Position matching
The comparison engine matches internal and external position records at the security-and-account level, producing a net difference for every line where quantities or values do not match. Configurable tolerance thresholds suppress differences below defined limits — set by position value, share quantity, or percentage difference depending on the firm's configuration — reducing break volume from rounding artifacts and minor timing differences without concealing genuine discrepancies.
5. Break classification
Each break is classified by root cause. Expected settlement differences — internal positions reflecting trades within the settlement window not yet settled at the custodian — are categorized as timing differences and cross-referenced against the outstanding settlement instruction queue. Breaks matching a pending instruction are tracked separately from unexplained breaks. Breaks without a corresponding pending instruction are flagged for investigation as booking errors or processing gaps. Corporate action breaks are identified where the quantity difference corresponds to a known entitlement event applied at a different ratio. Identifier mapping errors are flagged separately for security master correction. Segregation discrepancies — breaks in customer-attributed positions — are immediately flagged for Rule 15c3-3 possession-or-control review, independent of the standard escalation workflow.
6. Tri-party validation
Where prime broker data is available, the reconciliation extends to a three-way comparison: internal record, custodian MT535/MT536 statement, and prime broker report. Tri-party validation identifies which of the three sources holds the outlier value, directing investigation to the correct source from the start. Firms with significant prime brokerage relationships run tri-party reconciliation as the standard workflow for all affected accounts.
7. Resolution and sign-off
Breaks are routed to responsible teams by classification: timing differences to settlement operations, corporate action breaks to asset servicing, identifier mapping errors to the data management team, booking errors to trade support, and segregation gaps to compliance. Each break record contains the internal position, the external position from each source, the net difference, the classification, and days since first appearance. Resolution is documented against the break record with the corrective action taken. Unresolved material breaks are escalated before the Rule 15c3-3 possession-or-control computation cutoff and before the NAV calculation window closes. The daily reconciliation log — recording every run, every break, and every resolution — also serves as the primary documentary basis for the Rule 17a-13 quarterly securities count and verification, allowing the quarterly count to confirm rather than rediscover the firm's position accuracy.
Break classification — resolution routing
Devancore Glossary · devancore.com
Break classification — resolution routing
Devancore Glossary · devancore.com
In Devancore™
Account primitive — unified position container
Devancore Glossary · devancore.com
Devancore's position reconciliation is built on the Account primitive — the unified container for all position data across every source type and settlement rail. Every holding the firm carries, whether it is a CUSIP at a custodian, a token in an on-chain vault, or a position financed through a prime broker, is represented within an Account. This means the internal position record and the external sources reconciled against it share the same data model from the point of ingestion: normalization is applied at ingest rather than at comparison time, eliminating the class of phantom breaks produced by identifier mapping failures.
Multi-source ingestion
Devancore ingests custodian SWIFT MT535/MT536 statements, DTC Participant Position Reports, prime broker reports, and on-chain ledger queries through the same connectivity layer used for settlement instruction processing. Each ingested position record carries its source identifier, the as-of timestamp from the external source, and the pre-normalization raw values — providing a complete provenance chain for every reconciliation input. Reconciliation runs are logged with the sources ingested, reference times applied, and comparison result counts: matched positions, breaks identified by classification, and breaks carried forward from prior runs.
Finality-aware digital asset reconciliation
For digital asset positions, Devancore queries on-chain balance state through custody platform ledgers and node indexers on a continuous basis. Reconciliation is anchored to a confirmed block height for each network rather than the most recent block, preventing phantom breaks caused by chain reorganizations on probabilistic finality networks. Breaks in digital asset positions are classified separately from traditional position breaks: a break that exists because a transaction has not yet reached the required confirmation depth is held as an expected finality-lag break until the threshold is reached, then automatically promoted to a genuine discrepancy if it persists. Partial transfer events — where multiple on-chain transfers together constitute a settlement — are tracked as open until the full expected quantity is confirmed, preventing premature ABOR updates.
Rule 15c3-3 position feed
Customer-attributed positions are flagged at the account level in Devancore, allowing the Rule 15c3-3 possession-or-control determination to draw directly from reconciled, verified position data. Segregation gaps — differences between what the internal record shows as customer-attributed and what the custodian confirms — are surfaced immediately as a priority break classification, independent of the standard end-of-day reconciliation cycle. A deficit in customer securities is visible to compliance before the daily computation runs, not after.
Ops Copilot
Ops Copilot surfaces the position break queue at the start of each operations session, ordered by break age, materiality, and settlement date proximity. Corporate action breaks are pre-labeled with the relevant entitlement event. Segregation gaps are elevated above all other break classifications. Each break record includes the internal position, the external position from each source, the net difference, the cause classification, and the full resolution history — providing investigation context without a separate manual triage step. The reconciliation log and all break resolution records are retained in WORM-compliant storage, satisfying Rule 17a-4 retention requirements and serving as the documentary record for the Rule 17a-13 quarterly securities count.