Hook
A Web3 publication ran a story on a share-registration reform this week. I read it twice, hunting for the word "blockchain." It never appears โ not in the headline, not in the body, not in a single footnote. The subject is the Depository Trust Company, DTC, migrating its Direct Registration System from batch processing to an API, compressing transfer timelines from days to minutes. The outlet is a property built on decentralized finance. The underlying technology is an application programming interface. That asymmetry โ a DeFi desk reporting a legacy settlement upgrade with zero on-chain content โ is not an editorial slip. It is a signal, and it is the loudest thing in the story. Tracing the noise floor to find the alpha signal is the entire job, and here the noise floor is telling me exactly where the market's attention is mispriced.
I ignored the framing. I went to the mechanics. What I found is a reform that the crypto industry will misread in one of two directions, and both readings are wrong. One camp will call it a step toward tokenization. The other will call it boring plumbing. The truth is more uncomfortable than either: it is a deliberate re-architecture of the fault-tolerance profile of the most systemically important settlement engine in the world, communicated as a convenience feature, and executed to win a political fight over who controls the register.
Context
Before the analysis, the ground. DTC is the central securities depository for U.S. equities, corporate and municipal debt, and money market instruments. When you buy a share of Apple through a broker, you almost never receive a certificate or a name on a register. You receive a book-entry credit. That credit lives inside DTC's nominee, Cede & Co., a name that appears on the books of nearly every U.S. issuer as the holder of record for the overwhelming majority of outstanding shares. This is "street name" ownership, and it is the default architecture of the modern American market. The Direct Registration System is the escape hatch from it. DRS lets an investor move shares out of the broker-DTC chain and onto the issuer's register in their own name, held by the issuer's transfer agent rather than by Cede & Co.
The reform in question changes how that move happens. Historically, DRS transfers ran through batch processing โ jobs executed on a daily cycle, reconciled at end of day, with exceptions resolved on a subsequent cycle. The reform replaces that with an API: a direct programmatic call that executes a transfer in near-real time. The claim is days to minutes. The reform is, per the reporting, led by DTC itself. And it still requires transfer agent approval for each transaction.
That last clause is the whole story, and I will spend most of this piece on it. But first, the framing that the crypto press will apply, because that framing is the trap.
Here is the meta-observation, and I want to state it plainly because it frames everything downstream: a decentralized-finance publication is covering a traditional market-infrastructure modernization with no distributed-ledger content whatsoever. No tokenization. No smart contract. No chain. Just an API replacing a batch job. The reason this is significant is not that the outlet made an error. It is that the boundary between "FinTech" and "blockchain" has collapsed in the public imagination to the point where a settlement-plumbing upgrade with zero cryptographic content gets filed under the same beat as rollups and restaking.
I have spent 26 years watching this industry, and the single most reliable pattern I have found is this: the market consistently over-attributes change to blockchain and under-attributes it to boring middleware. The reforms that actually move settlement risk โ ISO 20022 migrations, API gateways, real-time gross settlement upgrades โ arrive with no token, no TGE, no governance forum. They just change the number at the bottom of a confirmation screen. Meanwhile, projects that announce "on-chain settlement" with a whitepaper and a Discord produce nothing that touches a real clearing calendar. Code does not lie, but it does hide. And it hides most effectively inside the infrastructure everyone assumes is static.
There is a deeper context the reporting skips, and it is essential. DRS is not new. It has existed since the 1990s, and for most of that history it was a niche tool used by a small number of investors who wanted direct registration for estate-planning or idiosyncratic reasons. That changed in 2021 and 2022, when a retail movement โ catalyzed by the meme-stock episode and a broad suspicion of broker and clearinghouse behavior โ turned DRS into a political instrument. The slogan was simple: get your shares out of street name. The volume spiked. Transfer agents that had never processed retail DRS at scale suddenly faced queues. And the queues became a talking point, and the talking point became scrutiny of DTC. So when I read that DTC is now leading a reform to make DRS faster, I do not read it as a technology project. I read it as a response to a political pressure campaign, executed through engineering, and I read the engineering accordingly.
Core
The mechanics of batch-to-API
To understand what DTC is doing, you have to understand why batch processing existed at all. It was not a technology limitation that someone failed to notice. It was a deliberate architecture of settlement. Batch processing exists because financial reconciliation is fundamentally a matching problem, and matching is easier when you freeze the inputs.
Here is the logic. A batch cycle works like this: transactions accumulate during a defined window. At the window's close, the system snapshots state, runs the matching engine, nets the obligations, identifies exceptions, and produces a settlement instruction. Exceptions โ mismatched instructions, failed validations, insufficient positions โ do not halt the cycle. They roll to the next one. The cost of this design is latency: you cannot settle what you have not yet batched. The benefit is stability: the system has a defined, auditable, recoverable boundary between input and output. If something is wrong, you catch it before it propagates, because propagation only happens at the batch boundary.
This is not primitive. This is how nearly every systemically important settlement engine has run for decades, including DTC's. It is how the Fedwire and CHIPS cycles were structured before their own modernizations. It is how most central bank RTGS systems were built. The batch boundary is a shock absorber. It absorbs the difference between the messy, asynchronous reality of market inputs and the clean, atomic reality that settlement requires. Remove the shock absorber and you do not merely get speed. You get exposure.
An API replaces the boundary with a call. Instead of "accumulate, then process," you get "request, then respond." The shock absorber is removed. In its place you get speed and the ability to compose โ a broker's system can now call the DRS endpoint directly, in its own workflow, without waiting for a window.
What this actually buys is not "minutes instead of days." It is the elimination of the reconciliation lag as a structural feature. That is the real claim, and it is a much bigger claim than the reporting conveys. When you remove the batch boundary, you also remove the reason the boundary existed: to catch errors before they propagate. So the reform is not merely a speed upgrade. It is a risk-architecture change, and the reporting treats it as a UX improvement.
Let me be concrete about the trade-off, because this is where the technical analysis has to live. Under batch, an erroneous instruction has a dwell time. It sits in the queue. A human or an automated control can inspect it during the window. Under API, the erroneous instruction executes โ or fails โ immediately. If it executes, the erroneous state is now the settled state, and correction requires a reversal, which is a separate, more expensive, and more scrutinized operation. If it fails, the failure surfaces in the caller's workflow, which means the caller must handle it, which means every counterparty's system must now be resilient to real-time rejection in a way it never had to be under batch.
This is the operational-risk compression nobody is pricing. Moving from days to minutes does not just move the transfer faster. It moves the error-correction window from "days" to "minutes" as well. The two are the same variable. You cannot compress settlement latency without compressing recovery latency. The reporting frames this as pure upside. It is a coupled change, and the coupling is the story.
I ran into this exact coupling two years ago. During the 2022 drawdown, I was optimizing opcode usage for a Layer2 rollup, and I cut transaction costs 18% by removing redundant storage reads. The cost reduction was real. But the change also shortened the window in which a malformed transaction could be caught before it committed state. We found this only because I ran 500 small transactions against the live environment specifically to test stability โ not throughput, stability. The lesson transferred directly: every latency reduction is also a fault-tolerance reduction, and the two must be designed together or the second one ambushes you.
So the first thing I would want from DTC, and the first thing the reporting does not provide, is the recovery architecture. What happens when an API-mediated DRS transfer commits an incorrect position? What is the reversal path? What is its latency? Who bears the cost of the reversal? Is there an idempotency guarantee on the endpoint, so that a retry after a timeout does not double-execute? These are not exotic questions. They are table stakes for any real-time settlement interface. Their absence from the coverage is the gap between a news item and an engineering document.
What "real-time" actually requires
I want to be precise about the word "real-time," because it is doing a lot of unexamined work in the coverage. Real-time does not mean instantaneous. It means bounded. A real-time system is one whose latency has a known upper bound under defined load, and whose failure modes are characterized. An API that responds in two seconds under normal load but degrades to minutes under peak load is not a real-time system. It is a fast batch system with better branding.
So the question for DTC's DRS API is not "how fast is a transfer." It is "what is the tail latency, and what is the behavior at the tail." Market infrastructure does not fail at the median. It fails at the ninety-ninth percentile, on the day when everyone wants to move at once โ a market dislocation, a corporate action, a settlement failure elsewhere that cascades. On those days, a batch system degrades gracefully: it processes what it can and rolls the rest. An API system under load either sheds requests โ which means the caller gets a rejection and must retry, and retries under load are how you get a thundering herd โ or it queues internally and becomes a batch system with worse observability.
There is a third option, and it is the one I would want to see: back-pressure with explicit admission control. The endpoint tells the caller "I cannot take this now, here is when I can." That is a mature real-time design. It is also hard to build and harder to get counterparties to implement, because it requires every caller to handle rejection as a first-class state. Most broker systems are not built to do that, because under batch they never had to. The reform does not just change DTC's system. It changes the failure-handling contract for every participant in the chain, and that contract change is invisible in the coverage.
I have built exactly this kind of admission-control logic in a different context. When I designed the zero-knowledge verification layer for a major ETF provider's compliance tool in 2024, the cryptographic proof generation had a bounded but non-trivial latency, and under load it could not keep up with inbound validation requests. The fix was not faster proofs. The fix was explicit back-pressure โ the system advertised its capacity and rejected what it could not serve, with a retry-after signal. I stress-tested it with 10,000 simulated transactions to prove the compliance logic held under rejection, not just under success. The proof held on the first serious run. The hard part was convincing the compliance team that a rejection was a correct outcome, not a failure. In regulated infrastructure, the cultural problem is always harder than the technical one. DTC will face the same problem at market scale: teaching hundreds of counterparties that a rejection is a feature, not a bug.
The transfer agent bottleneck: the one link that stays manual
Now the clause I flagged earlier. The reform, per the reporting, automates one link in the transfer chain and still requires transfer agent approval.
Read that again, because it is the single most important technical fact in the story. The DRS flow is not a single system. It is a chain: investor โ broker โ DTC โ transfer agent โ issuer register. DTC is automating its own link โ the broker-to-DTC and DTC-side processing. But the terminal link, the transfer agent's approval and the actual registration on the issuer's books, remains a human-gated or at least a separately-timed step.
This is the classic end-to-end fallacy. A pipeline is only as fast as its slowest gate, and DTC does not own the slowest gate. You can make the broker-to-DTC hop instant. If the transfer agent's approval still takes a business day, the investor's end-to-end experience is still a business day, minus nothing. The "days to minutes" headline describes DTC's internal hop, not the investor's observable outcome. This is not deception; it is a scope statement the reporting did not make explicit, and the distinction matters enormously for anyone modeling the actual user experience.
Why does the transfer agent link stay manual? Two reasons, and both are structural.
The first is technical. Transfer agents are not a monolith. They range from divisions of large banks with modern systems to small registrars running mainframe-era software with thin integration budgets. The DRS reform's end-to-end speed is therefore bounded not by DTC's capability but by the least-modernized transfer agent in the chain. I have audited enough infrastructure to know this pattern by heart: the bottleneck migrates to whoever has the weakest integration. In the 2021 NFT cycle, I analyzed the IPFS storage reliability of the top ten collections and found that 40% of "decentralized" NFTs pointed their metadata at centralized endpoints that were already decaying. The lesson was identical โ the headline claim of decentralization was bounded by the least-decentralized component. Here, the headline claim of real-time registration is bounded by the least-real-time transfer agent.
The second reason is legal, and it is more interesting. The transfer agent's approval is not merely a processing step. It is the point at which legal title is confirmed. The transfer agent is the entity that maintains the issuer's register, and the register is the authoritative record of who owns what. Automating DTC's hop does not transfer that authority. The transfer agent remains the gatekeeper of the register, and the register is where ownership actually lives. This is why the reform "still requires transfer agent approval" โ not because the technology is immature, but because the legal architecture places finality at the registrar, not at the depository.
Which brings me to a structural observation that I think the reform quietly reveals. DTC and transfer agents are not natural allies. They are competitors for the same scarce resource: control of the register. Under street-name ownership, DTC's nominee holds the shares and the issuer's register shows Cede & Co. as the holder of record. The transfer agent's register is therefore thin โ it reflects mostly the DTC omnibus position, not individual investors. DRS is the mechanism that pulls shares out of that omnibus and onto the register in individual names. Every share that moves via DRS makes the transfer agent's register thicker and DTC's omnibus thinner.
So why would DTC lead a reform that, on its face, accelerates the migration of shares off its own books?
I have a hypothesis, and it fits the incentive structure. DTC is not accelerating DRS out of generosity. It is defending the DRS channel against being bypassed entirely. If DRS is slow and painful, the pressure grows for investors to route around DTC โ either through transfer agents' own direct-registration offerings or through the political channel that has been pushing retail direct registration as an alternative to street name. A slow DRS is a liability in that fight. A fast DRS keeps DTC as the indispensable hub of the flow even when the shares leave its custody. You can move the shares out. You still go through DTC's pipes to do it. That is defensive innovation, and it is rational.
There is an economic subtlety underneath this that the coverage misses entirely. The direct beneficiaries of a faster DRS are not DTC. They are the transfer agents, who shed manual processing cost, and the brokers, who shed client-service cost. DTC's own direct economic gain is thin; its return is positional. It keeps the flow. So when you ask "who is paying for this reform," the honest answer is the members, through DTC's cost-recovery mechanism, and the ones capturing the operational savings are the transfer agents and brokers. The party bearing the cost and the party capturing the benefit are not the same, and that mismatch is a classic source of underinvestment. I would not be surprised if the rollout is slower than the technology allows, for exactly this reason.
ISO 20022 and the road to T+0
Now zoom out. The API migration is not an isolated DTC decision. It is a component of a much larger convergence, and understanding that convergence tells you where this is heading.
The U.S. equity market moved to T+1 settlement in May 2024. That transition compressed the settlement cycle from two business days to one, and it forced every participant โ brokers, custodians, the depository, the clearinghouse โ to rebuild their batch calendars. You cannot run T+1 on a T+2 batch architecture without pain. The move to T+1 was, in large part, a forced modernization of batch windows.
The next step on that road is T+0 โ same-day, possibly intraday, settlement. And here is the mechanical problem that T+0 faces: you cannot net and batch on a cycle that has no cycle. If settlement must complete within the trading day, or within hours, the batch boundary has to go. The API migration of DRS is a piece of that dismantling. It is not the whole thing, but it is the direction, and DTC moving a registration flow to an API is the depository signaling that its core is being re-architected away from batch windows.
The connective tissue for all of this is messaging standards. ISO 20022 is the global standard for financial messaging, and its migration โ which the U.S. payment and securities systems have been executing in stages โ standardizes the data payload that moves between institutions. An API without a standardized message schema is a bespoke integration; an API with ISO 20022 is a composable one. When DRS moves to API and the payload conforms to ISO 20022, DTC's registration flow becomes interoperable with the same message fabric that the RTGS systems and the payment rails are adopting. That is what makes near-real-time and eventually real-time settlement technically reachable.
I want to be careful here, because this is where crypto commentary typically jumps the shark. The ISO 20022 convergence does not make anything "blockchain." It makes the legacy rails faster and more interoperable with each other. The distributed-ledger settlement experiments that some venues run โ and I have worked adjacent to a few โ sit in parallel to this, not inside it. DTC choosing an API path rather than a DLT path for its core registration function is itself a data point: for the flows that matter systemically, the incumbents are modernizing the existing rails, not migrating to new ones. The tokenization narrative and the infrastructure reality are on two different tracks, and the infrastructure track is the one with the settlement volume.
The concentration question
There is a second-order consequence of all this modernization that the reform reporting does not touch, and it is the one I would flag to any risk committee.
DTC is a single point of systemic concentration. That is not a criticism; it is the design. A central securities depository is, by definition, centralized. The relevant question is whether a given reform increases or decreases the systemic weight of that single point. And the API migration increases it.
Here is why. Under batch processing, DTC's role is periodic. It executes windows. Between windows, the system is at rest, and the rest state is a kind of buffer. If DTC's processing fails during a window, there is a defined recovery point: rerun the window. The failure mode is contained because the architecture contains it.
Under API-driven, real-time processing, DTC's role becomes continuous. Every broker's system now depends on DTC's endpoint being available in real time. The dependency is no longer "batch with DTC once a day" but "be continuously coupled to DTC." That converts a periodic dependency into a persistent one, and a persistent dependency on a single node is a larger systemic exposure, not a smaller one. The speed is real. So is the fragility. They are the same change viewed from two ends.
I have seen this movie at smaller scale. During the DeFi Summer of 2020, I deployed a bot against Curve's slippage mechanism โ $15,000 of my own capital on the line โ to map the invariant calculations. I found a timing vector that allowed near-risk-free arbitrage. The mechanism was elegant. The risk was that everyone running a bot against the same pool, on the same block, at the same moment, created a correlated exposure that no single participant modeled. The pool was "just code." The code was a single point. Every participant's safety depended on that point behaving. This is not a metaphor for DTC; it is the same structural pattern. Centralization is not always a governance choice. Sometimes it is an emergent property of efficiency, and it carries the same correlated-risk signature wherever it appears.
For DTC specifically, the mitigants exist and are serious โ Regulation SCI imposes change-management and business-continuity obligations on exactly this kind of systemically important infrastructure. The API migration will trigger SCI change-reporting, and the real-time architecture will raise the bar on the continuity requirements. But here is the part the reform coverage omits: those compliance obligations are a cost, and costs are never neutral. They fall on DTC and, through DTC's cost-recovery model, on its members. Which brings me to the economics.
The member-owned utility problem
You cannot analyze DTC with a conventional business lens, and anyone who tries will produce nonsense. DTC is a user-owned, cost-recovery utility. Its "customers" are its members, and its members are effectively its owners. It is not optimizing profit. It is optimizing for the efficient provision of a shared service, subject to regulatory constraints. This is closer to a public utility than to a company, and the reform should be read as a utility upgrading its plant, not a firm launching a product.
This changes the incentive analysis in a way that matters. In a profit-maximizing firm, a reform like this would be justified by revenue โ new fees, new volume, a moat. DTC does not have that motive in the usual sense. So what does it have? Two motives, and both are defensive.
The first is member pressure. If member firms are unhappy with DRS latency โ and they would be, because retail clients complain about transfer times and the complaints land on brokers โ then the members push DTC to fix it. The reform is a response to member demand, not a bet on a new market.
The second is regulatory and reputational. DTC's position is politically exposed. The retail direct-registration movement has made "get your shares out of street name" a cause, and causes create scrutiny. A depository that is perceived to be slow, opaque, or obstructionist invites intervention. A depository that is demonstrably modernizing its DRS channel removes a talking point. The reform is, among other things, a preemptive answer to a political question: "why can't I register my own shares quickly?"
There is a network-effect dimension that cuts in DTC's favor and is worth naming, because it explains why the reform is likely to succeed even if the shares leave. DTC is a natural monopoly in U.S. securities settlement. The more participants use it, the more valuable it becomes, and the harder it is to replace. DRS reform, counterintuitively, strengthens that network effect rather than weakening it. Even when a share is "moved out" of street name, the movement itself flows through DTC's DRS channel. The share leaves the omnibus, but the pipe stays DTC's. The reform converts DTC's custody advantage into a processing advantage, which is a more durable form of lock-in. A firm can lose an asset and keep a tollbooth. That is what is happening here.
The regulatory pace problem
Which is the right place to put the timing question. The reporting gives a technical timeline โ days to minutes โ as if the constraint were engineering. The binding constraint is almost certainly regulatory.
A change of this magnitude to systemically important infrastructure does not deploy on an engineering sprint. It goes through the SEC's rule-change process for self-regulatory organizations and clearing agencies โ a filing, a public comment period, and a review. That process has its own clock, and it does not care about API readiness. The "days to minutes" claim describes the steady-state performance after approval. The path to that steady state runs through a comment period that can be extended and a review that can be contested.
So the real variable in the DRS timeline is not DTC's engineering velocity. It is the SEC's posture toward market-structure modernization. And that posture is a policy variable, not a technical one. If the Commission prioritizes settlement-efficiency reform, the DRS speed-up advances. If the Commission's attention is consumed elsewhere, it queues. I have seen this pattern before โ when I co-designed the zero-knowledge verification layer for a major ETF provider's compliance tool in 2024, the hardest part was not the cryptography. I stress-tested the system with 10,000 simulated transactions to prove regulatory compliance without compromising privacy, and the cryptography held on the first serious run. The hard part was mapping the proof output onto a compliance framework that regulators would accept. The code was ready long before the compliance architecture was, and the compliance architecture was the gate. DRS is the same shape at larger scale.
Now, my long-standing view is that most project KYC is theater, and that compliance costs land on honest users. Does that apply here? Partially. The DRS reform's regulatory burden is not KYC in the retail sense โ DTC is not a customer-facing institution. But the pattern holds in a different register: the compliance overhead of a real-time, SCI-covered architecture will be borne by the participants, and the smallest participants will bear it disproportionately, because fixed compliance costs do not scale down. The modernization will be easiest for the largest brokers and hardest for the smallest transfer agents, which means the reform's own architecture will widen the gap between modernized and unmodernized participants โ the exact gap that determines the end-to-end speed. The reform contains a self-limiting mechanism, and that mechanism is compliance cost.
What to actually measure
If I were running diligence on this reform, I would ignore the headline entirely and watch three numbers, none of which the coverage provides.
The first is end-to-end DRS transfer time from the investor's perspective, not DTC's internal hop. That number is bounded by the slowest transfer agent in the chain, and it is the only number a retail investor experiences. If it does not move, the reform has not moved anything that matters to the person it claims to serve.
The second is recovery and reversal latency on the API. This is the real cost of the speed, and it is the number that determines whether the reform is a net risk reduction or a net risk transfer. If reversal latency is measured in minutes, the reform is coherent. If it is measured in days, then DTC has compressed the settlement clock without compressing the recovery clock, and the gap is an unpriced exposure sitting in the middle of the market's most critical plumbing.
The third is the SEC comment record on the rule filing. That is the actual timeline, and it is the only timeline that binds. Everything else is marketing.
Contrarian
Here is where I push against the consensus reading, in both directions, because both are wrong.
The crypto-native reading will be: "DTC is finally moving toward real-time settlement, this is a step toward blockchain, tokenization is coming." That reading is wrong because it inverts the causality. DTC is not moving toward blockchain. DTC is moving toward APIs, which is a different destination, and the destination was chosen deliberately over DLT. The incumbents have evaluated distributed-ledger settlement and, for the flows that carry systemic volume, have chosen to modernize the existing rails instead. The API migration is not a way station on the road to on-chain settlement. It is the road that was taken instead. If you are positioned for tokenization to win the settlement layer, this reform is evidence against your thesis, not for it. The absence of the word "blockchain" from a DeFi publication's coverage is not an oversight. It is an accurate description of what is happening.
The traditional-finance reading will be: "this is a boring plumbing upgrade, nothing to see." That reading is wrong because it understates the risk-architecture change. Compressing settlement latency while leaving the recovery window uncompressed is a real, unmodeled exposure. Compressing the batch boundary away while centralizing the real-time dependency on a single node is a real, increased concentration. The reform is not boring. It is a change to the fault-tolerance profile of the most systemically important settlement engine in the world, and it is being communicated as a convenience feature. Boring is a category error here. The thing that looks boring is the thing that can cascade.
And there is a third reading, which is mine, and it is the one I think is actually true: this reform is primarily a defensive move in a political fight over who controls the register, dressed as a technical modernization. DTC is making DRS fast because a slow DRS is a liability in the argument that retail investors should be able to hold their own shares directly. The speed is real. The motive is positional. Both can be true, and understanding the second is what lets you predict the first.
There is one more blind spot worth naming, and it is the one the entire coverage shares. Everyone is debating whether DTC's DRS reform is good or bad for investors. Nobody is asking the more important question: whether the transfer agents, who hold the legal finality and the register, will be dragged into real-time operation at all, or whether they will become the permanent queue at the end of an otherwise instant pipeline. If the register stays manual, DTC has built a fast road to a slow door. That is the outcome I would bet on in the near term, and it is the outcome that makes the reform simultaneously real and overstated. The speed is genuine. The benefit is partial. And the partial benefit is exactly what a defensive, politically motivated reform would produce.
Logic gates are the new legal contracts, and this reform is a case study in how a technical change encodes a legal and political settlement. The API is not neutral. It encodes DTC's decision to remain the hub. Read it that way and the coverage's omissions โ the recovery window, the transfer agent bottleneck, the SCI cost, the register's manual gate โ stop looking like gaps and start looking like the parts of the story that the framing was built to not require.
Takeaway
So here is what I am watching, and what I would tell anyone modeling this. Not the "days to minutes" claim, which is a scope statement, not an outcome. I am watching three numbers. The first is the average DRS transfer time from the investor's perspective, end to end, which is bounded by the slowest transfer agent, not by DTC. The second is the API's recovery and reversal latency, which is the real cost of the speed. The third is the SEC comment record on the rule filing, which is the actual timeline.
Volatility is the price of entry, not the exit, and infrastructure reform is the same: the interesting risk is never in the headline number. It is in the coupling the headline hides. DTC is making one link fast and leaving the register manual. That is not a failure of the reform. It is the reform's real shape, and it tells you exactly where the next bottleneck โ and the next political fight โ will surface. When the fast road meets the slow door, the queue does not disappear. It relocates. And whoever owns the queue owns the market.