Devancore Inc.
Devancore Post-Trade Glossary
Glossary
DTC RAD
A context-dependent DTC term covering reorganization announcement data in corporate actions and Receiver Authorized Delivery controls in settlement.
Document source: https://devancore.com/glossary/dtc-rad/
Devancore Post-Trade Glossary
DTC RAD
A context-dependent DTC term covering reorganization announcement data in corporate actions and Receiver Authorized Delivery controls in settlement.
Definition
DTC RAD is a small acronym with real operational weight. In DTC-facing workflows, the same three letters can point to two different records. In corporate action and reorganization operations, RAD is commonly used to describe reorganization announcement data: the event information that tells participants what has changed, which security is affected, what dates matter, what elections may be available, and what entitlement should eventually be expected. In settlement operations, RAD refers to Receiver Authorized Delivery: a DTC delivery-control mechanism that lets the receiving participant review and accept or reject incoming deliveries before they post.
The distinction matters because each meaning belongs to a different operating workflow. Reorganization announcement data sits upstream of corporate action processing. It feeds the instrument master, corporate action engine, entitlement calculation, custody record, client notification process, and accounting record. Receiver Authorized Delivery sits inside the DTC settlement workflow. It controls whether an incoming delivery can move from pending status into the receiver's account, or whether the delivery is rejected, held, or marked DK.
DTC RAD — two meanings, two control points
| RAD context | Meaning | Primary workflow | Record impact |
|---|---|---|---|
| Corporate actions | Reorganization announcement data | event announcement, amendment, election, entitlement | feeds instrument master, corporate action engine, custody record, and accounting entries |
| Settlement | Receiver Authorized Delivery | delivery review, value threshold, acceptance, rejection, DK | controls whether an incoming DTC delivery can post to the receiver account |
| Common risk | ambiguous acronym | workflow routing | wrong interpretation can create missed event updates, incorrect entitlements, hard-deadline failures, or unresolved delivery holds |
| Control standard | source-specific mapping | data lineage and approval evidence | each RAD signal should be mapped to the correct record, owner, timestamp, and exception path |
RAD as reorganization announcement data
Corporate action RAD should be understood as an announcement record, not merely a data feed. A reorganization event can change the economic state of a security without looking like a normal trade. Mergers, exchange offers, tender offers, conversions, redemptions, puts, reverse splits, rights events, warrant exercises, bankruptcies, and similar events all require operations teams to interpret event terms, track dates, manage elections, and compare expected entitlements with actual allocations.
Modern corporate action operations may consume this data through DTC CA Web, ISO 20022 corporate action messages, API interfaces, files, or internal vendor feeds that normalize DTC announcement data before it reaches the firm's books. The ingestion method can change, but the control question stays the same: which announcement version did the firm rely on, and which downstream records changed because of it?
The announcement record is the starting point. It should identify the security, event type, event identifier, issuer or agent source, key dates, option terms, deadlines, rates, ratios, payable mechanics, amendment status, and any conditions that affect eligibility or election. If those fields are incomplete, stale, or overwritten without history, the downstream record becomes unstable. The firm may calculate the wrong entitlement, miss a hard election deadline on a voluntary event, update the wrong security record, or book an accounting entry without clear evidence of the event terms used.
Reorganization data also has a timing problem. Corporate actions change. Deadlines extend. Terms are amended. Elections are reopened or withdrawn. A controlled system cannot treat an announcement as a static document. It needs a versioned event record that shows what was known, when it was known, which downstream records consumed it, and whether any manual override changed the result.
RAD as Receiver Authorized Delivery
Receiver Authorized Delivery belongs to settlement. It is the receiver-side control that allows a DTC participant to review incoming deliveries before they are accepted into the participant's account. RAD profiles can be configured around delivery categories, counterparties, and dollar-value thresholds, so low-value or expected deliveries may post automatically while higher-value or exception-prone deliveries are held for review. A delivery that passes risk controls can still wait on receiver action if the RAD profile requires review. The receiver can accept the delivery, reject it, or issue a DK response when the delivery is not recognized.
Under a compressed settlement cycle, RAD status is operationally important. A delivery held for manual review can create the same practical problem as a bad instruction: the securities do not post, the cash leg does not complete, and the item can move toward a fail. A missed corporate action RAD update can create entitlement liability. A missed settlement RAD hold can create a fail, buy-in pressure, funding cost, or client service break. Settlement teams therefore need to monitor RAD status with the same discipline they apply to matching, SSI enrichment, DTC risk controls, and fail management.
The operating-control issue
The common control problem is not the acronym. The problem is routing. Corporate action RAD should flow into event-data governance. Settlement RAD should flow into delivery-status governance. Each needs a separate owner, source record, timestamp model, exception reason, and audit trail.
A post-trade platform should preserve both meanings without mixing them. If an incoming file, message, report, or status uses RAD, the system should classify the context first: corporate action announcement or settlement authorization. From there it can route the record to the correct workflow. Reorganization announcement data moves toward event setup, entitlement, election, and accounting. Receiver Authorized Delivery moves toward delivery review, counterparty coordination, DK handling, and settlement-fail prevention.
DTC RAD — context and record impact
Devancore · message matrix
| Rail | Message | Purpose | Record |
|---|---|---|---|
| CA RAD | reorganization data | announce event terms | corporate action, entitlement, instrument, and custody records |
| Settlement RAD | receiver authorization | threshold review | DTC delivery status, receiver action, DK reason, settlement outcome |
| Shared control | source + timestamp | prove which signal drove the record | audit trail for downstream changes and exceptions |
| Operating risk | acronym collision | prevent misrouting | separate workflows for event data and delivery approval |
How it works
1. Classify the RAD context
The first step is classification. A RAD signal tied to a reorganization, redemption, distribution, tender, exchange offer, conversion, or other corporate action belongs to the announcement-data workflow. A RAD signal tied to an incoming delivery, receiver approval, delivery hold, or DK response belongs to the settlement workflow. Classification prevents the most basic failure: treating event data as a delivery instruction, or treating delivery authorization as corporate action evidence.
2. Capture the source record
For reorganization announcement data, the source record should preserve the event identifier, security identifier, event type, source, ingestion channel, publication timestamp, effective dates, option terms, deadlines, rates, ratios, and amendment status. The ingestion channel matters because the same announcement may reach the firm through CA Web, an ISO 20022 message, a file, an API, or a normalized vendor feed. For Receiver Authorized Delivery, the source record should preserve the DTC delivery instruction, delivering participant, receiving participant, RAD profile or threshold condition, RAD status, receiver action, timestamp, and rejection or DK reason where applicable.
3. Map fields into downstream records
Corporate action RAD maps into the instrument master, corporate action engine, entitlement record, custody position, accounting record, and client communication workflow. Settlement RAD maps into delivery monitoring, settlement instruction status, fail-risk review, counterparty escalation, and exception management. The field mapping should be explicit. A deadline should not become a generic note. An entitlement ratio should not become unstructured text. A DK reason should not live only in an email thread.
4. Govern amendments and overrides
Reorganization events are rarely clean one-time records. Terms can change, deadlines can extend, and agent information can be corrected. The system should keep the prior state and the new state, then show which downstream records were affected by the change. Manual overrides need maker-checker review because an override can change entitlements, elections, client notices, and accounting treatment. Settlement RAD overrides need the same control discipline: who accepted, rejected, released, or escalated the delivery, and why.
5. Tie the record to evidence
Every RAD-driven action should leave evidence. For corporate action RAD, evidence includes the announcement source, amendment history, event terms, calculation basis, election instruction, entitlement expectation, allocation result, and reconciliation outcome. For settlement RAD, evidence includes the delivery instruction, receiver decision, DK notice where applicable, counterparty communication, and final settlement status.
6. Close the loop through reconciliation
RAD data should not end at intake. After the event or delivery completes, the firm should compare expected outcomes with actual outcomes. A reorganization announcement should reconcile against custodian allocations, cash movements, position changes, and accounting entries. A settlement RAD item should reconcile against DTC delivery status, securities position movement, cash settlement, and fail resolution. The value of RAD is not only receiving the signal. The value is proving that the signal became the right operating record.
DTC RAD workflow — event data to operating record
Devancore Glossary · devancore.com
DTC RAD workflow — event data to operating record
Devancore Glossary · devancore.com
In Devancore™
DTC RAD controls — operating ownership
Devancore · responsibility matrix
| Work | Ops | Data | Supervisor | System |
|---|---|---|---|---|
| Classify RAD context | R | A | C | R |
| Map event fields | C | A | I | R |
| Approve overrides | R | C | A | I |
| Track deadlines | A | C | I | R |
| Preserve evidence | R | C | A | R |
Devancore treats DTC RAD as a classified operating signal. The platform separates corporate action RAD from settlement RAD at intake, maps each signal to the correct workflow, and preserves the source record, timestamps, owners, decisions, and downstream effects.
For reorganization announcement data, Devancore connects event terms to the instrument master, corporate action workflow, entitlement record, custody reconciliation, and accounting output. When an announcement changes, the system preserves the prior version, identifies affected records, and routes the update through review before downstream books are changed.
For Receiver Authorized Delivery, Devancore tracks the settlement instruction, RAD status, receiver decision, DK reason, escalation owner, and final settlement outcome. A delivery held at RAD review becomes visible as an operational exception before it turns into a settlement fail.
The result is a single evidence chain across event data and settlement control. Operations can answer which RAD signal arrived, what it meant, which workflow consumed it, who approved the change, what records were updated, and how the final position, cash, entitlement, or exception was resolved.
Related terms
- DTC Settlement Operations
https://devancore.com/glossary/dtc-settlement-operations/
e settlement system operated by the Depository Trust Company (DTC) that executes final book-entry delivery-versus-payment transfers of US securities after NSCC clearing, with end-of-day cash finality through the Federal Reserve.
- DTCC Digital Asset Tokenization
https://devancore.com/glossary/dtcc-digital-asset-tokenization/
A DTC service enabling the conversion of book-entry securities into on-chain tokenized entitlements for T+0 settlement and automated collateral management under a 2025 SEC No-Action Letter.
- 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.
- Corporate Action Processing
https://devancore.com/glossary/corporate-action-processing/
Corporate action processing is the operational workflow that captures issuer events, calculates per-account entitlements, and reconciles cash and position changes against custodian records.
- Instrument Master Data
https://devancore.com/glossary/instrument-master-securities/
The authoritative golden record of reference data — identifiers, static attributes, and lifecycle parameters — for every instrument a firm can trade, settle, or report.
- 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.
- Custody Reconciliation
https://devancore.com/glossary/custody-reconciliation/
Custody reconciliation is the daily match of internal positions and cash to the custodian statement: timing versus genuine breaks, owners, aging, and the evidence that holdings are actually safekept.
- 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.
- 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.
- 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.
Contact
Request a briefing or platform walkthrough with the Devancore team.
Request access https://devancore.com/access/