DTC wants to turn a multi-step, batch-file process for moving shares between a broker and an issuer's own books into something closer to an API call. It filed the proposal with the SEC on September 29, 2026, and says the goal is "reducing transaction processing times from days to minutes." It is a proposal, not an approved rule, and one human approval step stays exactly where it is.
That last part is the story. Faster plumbing is real progress. It is not the same thing as no gatekeepers.
What DTC filed
The filing is SR-DTC-2026-012, published in the Federal Register on October 5, 2026, with a comment deadline of October 26. It targets the Direct Registration System (DRS), which moves shares without paper certificates between DTC-held ownership and direct ownership recorded by an issuer's transfer agent.
Per the filing, DTC proposes to:
- ▸Open DRS to machines. DRS would be reachable through DTC's Securities Processing Application (SPA) via the DTCC Portal for human-to-machine work, and through API and message-queue messaging for machine-to-machine processing.
- ▸Retire legacy routes. Certain PTS and PBS functions and CCF batch-file processing would stop being operational methods for certain DRS transactions.
- ▸Automate one handoff. Today, after a transfer agent approves a participant's profile deposit request, the order is created separately. Under the proposal, SPA would create the Deliver Order automatically.
- ▸Track status. SPA would assign transaction status values and keep an audit trail of status changes.
- ▸Document fees. The Fee Guide gets new entries for pass-through fees. A DRS Agent decides whether to impose one; DTC would charge a five-percent collection charge, which DTC says already applies to existing DRS Centralized Billing.
What does not change
The DRS Agent, usually the issuer's transfer agent, still has to review and approve or reject each Profile Deposit Request and each Withdrawal by Transfer instruction. Only DTC participants can start a withdrawal by transfer, and the agent still has to approve changing the registered owner from DTC's nominee, Cede & Co., to the investor's name.
DTC's own filing acknowledges this: the changes cut DTC-side latency, but they do not remove agent actions. Reporting on the filing makes the same point. DTC is not promising that every transfer finishes in minutes. "Days to minutes" is the target for the automated path, not a service-level guarantee, and the filing does not publish measured results.
Why a crypto builder should read a DTC rule filing
The filing itself does not mention tokenization, blockchain, or distributed ledger technology. Anyone linking it to onchain securities is bringing their own framing.
One person did. According to Digital Today's report, Securitize CEO Carlos Domingo said on October 8 that the proposal could make the path from brokerage accounts to tokenized shares faster. That is a view from a company that works in this space, not a finding in the filing. It is plausible, and it is worth holding as a claim until the implementation exists.
The builder-relevant detail is structural. If you build agents that touch ownership records, whether for reconciliation, transfer tracking, or tokenized-equity workflows, the interface you integrate against is shifting from batch files and manual steps toward APIs and status codes. That is the same direction every other payment and settlement rail has been moving. An agent can poll a status field. It cannot do much with a batch file that lands tomorrow.
It also reinforces a distinction we keep coming back to: an API is a faster door, not a different building. The approvals, the fees, and the legal record-keeper are still there. If your agent design assumes the human step vanishes, the design is wrong, not the rail.
What to watch
- ▸SEC action. The filing is pending. The Commission has 45 days from publication, extendable to 90. Nothing here is live until it acts.
- ▸The date. DTC targets November 13, 2026, pending approval, and says implementation would be no later than January 2027 if that slips, with the date announced by Important Notice.
- ▸Transfer-agent uptake. The speed claim depends on DRS Agents approving quickly. Watch whether agents adopt the API and message-queue routes, and whether anyone publishes real turnaround times once it runs.
- ▸Fee friction. Pass-through fees are the agent's call. Whether they become a drag on small transfers is an open question the filing does not answer.
- ▸Comments. The comment period closes October 26. Objections and clarifications there will show where the contested parts are.
Building an agent that has to work against real rails, with real approval steps? Map the stack first: satohub.ai/build.