Who authorised it is a question with a regulatory answer and no technical one

Start with the chain, because the argument is not abstract and the abstraction is what usually gets it dismissed.

A complaint arrives about a fee. A triage agent classifies it. A retrieval agent pulls the account history, the product terms in force on the relevant dates, and the fee schedule. A calculation agent recomputes what should have been charged. A remediation agent posts an adjustment to the customer's account and drafts the letter that explains it. Five hops, one of which moves money in a customer's account and one of which produces a communication to that customer. The bank is large enough to be squarely inside every supervisory expectation that attaches to a customer-affecting process.

The telemetry is good. Spans, parents, latency per hop, tool arguments and tool results attached. If the calculation agent had timed out, an engineer would find it in ninety seconds.

Then, in a control-testing walkthrough, someone from the second line asks a question that sounds administrative and is not:

Which individual authorised the adjustment?

The record answers a neighbouring question with total confidence. The adjustment was posted by a service principal — call it svc-agentplatform-prod. That principal holds an entitlement to the adjustments endpoint. The entitlement was provisioned through the joiner-mover-leaver process, has an owner of record in the configuration management database, and was recertified eleven weeks ago by a named person who is a manager in servicing operations. Every link in that sentence is real, evidenced and testable.

None of it is an answer to the question that was asked. It establishes that a service was permitted, at some point, to do a class of things. It does not establish that any person authorised this adjustment, to this customer, for this amount, on this reasoning. Attribution to a service is not attribution to a person, and the distance between the two is not a documentation gap that better record-keeping closes.

What actually closes the gap, in practice, is a paragraph. Somewhere in the control narrative there is a sentence of the form: the service account operates under the delegated authority of the Head of Servicing Operations, who has approved its entitlement set and who retains accountability for actions taken under it. That sentence is written by a person, about a system, in a document the system has never read and cannot contradict. It is an assertion. It may even be a true assertion. It is not evidence, and the difference between an assertion and evidence is the entire discipline the second line exists to enforce everywhere else in the bank.

The five-hop servicing chain above, the service principal name, the control narrative paragraph and the recertification detail are a constructed illustration, assembled from patterns documented in public specifications, published supervisory guidance and vendor documentation. It is not a report of any real incident, institution, customer or deployment, and no part of this piece describes client work.

The objection, stated properly

There are two strong responses to what I have just written, and they come from different people. The first comes from inside the bank, and it is the better one. The second comes from the regulatory reading, and it is the more fashionable one. Both deserve to be put at full strength.

The response from inside the bank goes like this. Banking has spent two decades building one of the most explicit accountability regimes in the private economy, and it did not do so decoratively. There are three lines of defence with documented mandates. Every privileged identity has a named owner and an approval record. Entitlements are recertified on a cycle, and the recertification is itself evidenced and sampled by internal audit. Segregation of duties is enforced in the provisioning tooling rather than in a policy document. Material changes pass a change advisory board with a recorded decision and a recorded approver. General IT controls are tested annually by external auditors who are professionally sceptical for a living. Non-financial risk taxonomies map processes to accountable executives by name. In a sector where a senior manager can be personally sanctioned, nobody forgot to write down who is responsible.

So the natural reading of my complaint is that I have described a bank without an entitlement model, which is not a bank. Add the field. Put the accountable executive's identifier on the span, propagate it, and the record now names a person at every hop.

The second response is the regulatory one, and it is the argument I hear most often in 2026. On 17 April 2026 the agencies revised the interagency model risk management guidance. The revised guidance says, in footnote 3, that generative AI and agentic AI models "are novel and rapidly evolving" and that "as such, they are not within the scope of this guidance." It says, in its introduction, that it "does not set forth enforceable standards or prescriptive requirements; accordingly, non-compliance with this guidance will not result in supervisory criticism against a banking organization." On the most economical reading, agentic systems are outside the framework, the framework was never enforceable, and this is therefore a problem the supervisor has explicitly declined to have. Build the thing, monitor it sensibly, and revisit when someone writes a rule.

I want to concede both of those at full strength before answering either, because each is right about something and the thing each is right about is not the thing at issue.

The entitlement model is real, and it is not what is being asked about. An entitlement is a standing capability attached to a principal. It says what that principal may do, indefinitely, until someone changes it. A grant is an event: a moment at which one party extended a bounded permission to another for a particular purpose. A bank's controls are built almost entirely out of grants — a payment above a threshold requires an approver, a limit breach requires a documented waiver, a model change requires a sign-off — because a grant is what produces an evidenced decision. The agent chain produces no grants. It runs entirely on standing capability, which is exactly the class of control the bank's own frameworks treat as the weakest, and which is why entitlement reviews exist in the first place: they are the compensating control for the absence of a per-use decision.

Putting the executive's name on the span writes down a fact that is not true at that hop. The accountable executive did not authorise the adjustment. They approved an entitlement set for a service, in a change record, some months previously. Stamping their identifier onto the fourth hop of a chain they have never seen asserts a decision that did not occur. That is not improved telemetry; it is a stronger claim resting on the same absent evidence, and it is worse than the paragraph in the control narrative because it now looks like data. If the second line finds an identifier in a field, it will reasonably assume it was recorded because something happened.

The out-of-scope sentence does not end where it is usually quoted. Footnote 3 is four sentences long and the version that circulates is the first two. The third sentence is the one that matters, and it points the opposite way: "Nonetheless, a banking organization's risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document." The carve-out does not remove the requirement to determine appropriate governance and controls. It relocates the determination to the institution and declines to specify it.

Which is the whole argument, compressed. The agencies removed the framework that would have told a bank what controls to build for agentic systems, and expressly left the bank responsible for deciding. That is not a reprieve. It is a deferral with the obligation left in place and the specification withdrawn, and it means the eventual specification will be written against whatever institutions have already built.

What the April 2026 revision actually did

It is worth being precise about the instrument, because it is mis-cited in five specific ways that a banking reader will catch, and being caught on any of them costs more than the argument is worth.

First, the rescission lists are three distinct lists and they are frequently merged. OCC Bulletin 2026-13 rescinds four OCC issuances: the "Model Risk Management" booklet of the Comptroller's Handbook; OCC Bulletin 1997-24, "Credit Scoring Models: Examination Guidance," including its appendix; OCC Bulletin 2011-12, "Sound Practices for Model Risk Management: Supervisory Guidance on Model Risk Management"; and OCC Bulletin 2021-19, on model risk management for bank systems supporting BSA/AML compliance. The Federal Reserve's parallel action is stated separately: SR 26-2 supersedes SR 11-7 and SR 21-8. The FDIC's, in FIL-15-2026, rescinds FIL-22-2017 and FIL-27-2021. SR 11-7 was never an OCC issuance for the OCC to rescind. It is superseded, and it should be cited only as superseded; anyone still quoting it as current guidance in an agentic control narrative in late 2026 is quoting a document that has been replaced.

Second, and more consequentially, the generative-and-agentic carve-out is not the OCC's alone. It appears as footnote 3 of the shared guidance document, "Supervisory Guidance on Model Risk Management," dated 17 April 2026, whose cover names the Board of Governors of the Federal Reserve System, the Federal Deposit Insurance Corporation and the Office of the Comptroller of the Currency. That same document is what the Federal Reserve distributes as the attachment to SR 26-2 and what the FDIC distributes with its financial institution letter. The sentence is the agencies' jointly. It is worth getting right in both directions: the carve-out is broader than a single-agency statement, and the corresponding responsibility-returns sentence in the same footnote is likewise the agencies' jointly.

Third, the non-enforceability sentence has a second clause and a footnote, and both are stronger than the first clause. In full:

This guidance does not set forth enforceable standards or prescriptive requirements; accordingly, non-compliance with this guidance will not result in supervisory criticism against a banking organization.

That is a genuinely permissive sentence and it should not be softened. But the footnote attached to it retains the hook: after citing the agencies' respective rules on the role of supervisory guidance, it adds that "supervisory action may result for any violations of law or unsafe or unsound practices stemming from insufficient management of model risk." The agencies disclaimed the framework in the sentence and kept the enforcement basis in the footnote to it. Nobody had to infer the deferral reading; it is written down.

It is also worth saying once, plainly, that supervisory guidance in United States banking has never carried the force of law. The 2023 interagency third-party guidance states it in terms: "Supervisory guidance does not have the force and effect of law and does not impose any new requirements on banking organizations." So the April 2026 non-enforceability sentence is not a novel concession. It is the standing status of all supervisory guidance, restated. What is novel in April 2026 is the scope carve-out, not the non-enforceability — and a control narrative that leans on the non-enforceability sentence as though something changed has misread which half is new.

Fourth, the promised next step is a consultation, not a rule and not draft guidance. The bulletin's background section says the agencies "will continue to consider additional measures" and that they "plan to issue in the near future a request for information that addresses model risk management generally and considers, in particular, banks' use of AI, including generative AI and agentic AI and AI-based models." A request for information asks what should be in a framework. It is the step before anyone drafts one.

As of 18 August 2026 — four months on — no such request for information has been published. A Federal Register document query restricted to the OCC, the Federal Reserve System and the FDIC, for documents published on or after 17 April 2026, returns two documents matching "artificial intelligence" — an anti-money-laundering proposed rule of 9 July 2026 and a payment-system-risk notice of 26 May 2026 — and none matching a model risk management request for information. That is a dated, reproducible observation rather than a prediction, and its consequence runs against the comfortable reading: the specification is further away than "guidance is coming" implies, which lengthens rather than shortens the period during which each institution is deciding for itself.

Fifth — and this is the part that most control narratives miss entirely — the guidance's definition of "model" independently excludes most of the machinery that an agent chain is actually made of. The definition covers "a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates," and expressly excludes "simple arithmetic calculations, such as those found within spreadsheets, as well as deterministic rule-based processes and software where there are no statistical, economic, or financial theories underpinning their design or use."

Read that against an orchestration stack. The planner is a routing policy. The tool-dispatch layer is a lookup and a call. The policy engine that decides whether an adjustment above a threshold requires a second opinion is a rule evaluation. None of those is a model under this definition, whatever else they are. So the layer at which authority actually passes between agents falls outside the framework twice over: once because it is part of an agentic system, and once because it is not a model at all. The exclusions are independent, which means closing either one would not bring it back in.

One qualification, because the threshold is often overstated. The guidance says it "is expected to be most relevant to banking organizations with over $30 billion in total assets" and that generally excluding smaller organizations "is consistent with a tailored supervisory approach," while noting it may still be relevant to smaller organizations with significant model risk exposure. The OCC bulletin separately carries a note stating the guidance is applicable to all community banks, subject to the limitations discussed in the guidance. That is a relevance expectation with qualifications on both sides, not a bright line, and writing it as "it does not apply below thirty billion" is the kind of shortcut a supervisory reader will notice.

The physical fact: nothing was delegated, because delegation was never an object

Everything above is context. This section is the argument, and it is a claim about what exists in memory rather than a claim about what anyone failed to log.

In the prevailing propagation pattern, authority moves between agents as ambient context. Three mechanisms account for nearly all of it, and the important property they share is that none of them is an event.

1. A shared session. The chain runs inside one session object authenticated once at the boundary. Each agent reads from it. Nothing is passed, because the session is simply in scope. There is no moment at which the retrieval agent gives the remediation agent anything, so there is no moment at which a grant could have been recorded.
2. An inherited credential. A token, a key or a pre-constructed client sits in the process environment or in a shared configuration object, built at startup. The fourth agent does not obtain it. It has been in possession of it since the process began, on identical terms to every other agent in the process.
3. A system prompt carried forward. Instructions, tool definitions and accumulated conversation state cross a handoff. What changes is what the receiving agent knows. What does not change is what it may do, because capability was never the thing modelled as travelling.

Now compare that with how every other control in a bank produces its evidence. A payment approval is an event: a request, an approver, a timestamp, a decision. A limit waiver is an event. A model change sign-off is an event. A privileged access grant is an event, which is precisely why access recertification works — the provisioning system emitted a record at the moment the permission came into being, and the recertification compares the current state against those records. Bank controls are auditable because they are constructed out of request-approve-record triples, and a triple leaves a trace by construction.

The agent handoff produces no request, no approval and therefore nothing to record. It is not that the record is thin. It is that the shape of the thing the control framework knows how to evidence was never instantiated.

This is why it is not a missing field. A missing field implies there was a value and nobody wrote it down. Here there is no value. When the remediation agent posts an adjustment under a credential minted before the chain started, the only principal identifier that would be correct to attach to that span is the one already attached to every other span in the chain — which therefore distinguishes nothing. Writing it down five times does not produce five facts. It produces one fact copied five times, and the copies say nothing about what happened in between.

And it is why better instrumentation does not reach it. Turn sampling off. Retain everything at full fidelity. Pay the bill. The chain is now perfectly recorded and the authority question is exactly as unanswerable as before, because the fidelity is fidelity to a call graph. A call graph is recoverable because each of its edges is an invocation, and an invocation is an event that the code causing it can observe while it is happening. An authority graph is not recoverable because each of its edges would be a grant, and in this pattern no grant is ever created.

There is a general form of this argument, made against the published specifications that sit nearest the problem — token exchange, capability credentials, workload identity, the agent protocols and the telemetry conventions — in a separate piece written for platform engineers. I will not repeat it here. What matters for a bank is narrower and harder to argue with: the object your control framework needs is not merely unrecorded, it does not exist, and a framework built to evidence decisions cannot evidence a decision that was never made.

It would be comfortable to treat this as a gap that a framework release closes. I do not think it is, and the reason is that the object requires a change in three places at once: a credential that can be derived in a weaker form without a round trip to the issuer; a handoff API that takes the derived credential as a parameter rather than only taking context; and a verifier at the resource that will actually evaluate the chain rather than only the bearer. Each of those exists somewhere in the literature. None of them is the default in the agent frameworks and reference architectures whose documentation I have been able to read, and patching one of the three produces nothing usable. I have not surveyed what individual institutions have built privately, and a counterexample would be a fact about one deployment rather than about the field.

What fails, at mechanism level, in a bank

Generic arguments about agent risk are cheap. Here is what specifically breaks, in the terms this sector uses, with the sentence from the guidance that each one runs into.

Roles and responsibilities across the lifecycle. The guidance's governance section states that "sound governance practices delineate the individual(s) responsible for key activities throughout the model lifecycle, from development through validation and ongoing monitoring." The expectation is a named individual per activity. A chain in which every hop runs as the same service principal cannot delineate anything: the mapping from activity to individual is many-to-one and constant, which is the same as having no mapping. This is not a scoping objection — even accepting that the agentic components are out of scope, the components that are in scope are being operated by a chain whose activity-to-individual mapping has collapsed.

Delegation to parties outside the team. The same section addresses delegation directly: "For banking organizations that use external resources to help manage model risk, sound practice involves maintaining proper oversight and integrating that work into broader model risk management activities. Organizations benefit from clearly defining roles and responsibilities when delegating these activities." Clearly defining roles when delegating presupposes that a delegation is a thing you can point at. The agentic case has delegations everywhere and no delegation objects anywhere.

Third-party components you cannot see inside. The guidance anticipates opacity and refuses to let it discharge the obligation: "because certain components may be proprietary, banking organizations may not receive from the vendor the underlying code, data, or methodology that they would have if a model were developed internally. Nevertheless, the principles of model risk management remain applicable." Transfer that to a chain that calls a hosted tool endpoint or a third-party agent. The bank cannot see inside the vendor's hop. Under the plain reading of that sentence, not being able to see inside is not a reason the principles stop applying — it is a reason the bank needs a record of what authority crossed the boundary, which is precisely the record that does not exist.

Responsibility that does not attenuate. The 2023 interagency third-party guidance puts the principle in one sentence: "A banking organization's use of third parties does not diminish its responsibility to meet these requirements to the same extent as if its activities were performed by the banking organization in-house." Read that alongside an architecture in which capability is passed outward at every hop and nothing carries the parent's obligation along with it. The regulatory structure and the technical structure are moving in opposite directions: responsibility is monotone and does not weaken, while authority in the stack is inherited whole and never narrows.

Two operational consequences follow, and they are the ones that actually hurt when something goes wrong.

The first is revocation. An entitlement can be revoked from a service principal in seconds, and every bank can demonstrate that. What cannot be done is revoking authority from a chain, because there is no chain object to revoke from — only a principal, and revoking the principal stops everything the principal does, including all the traffic that was fine. The bank is left choosing between a blunt outage and an unbounded exposure, and both of those are answers the second line will find unsatisfying.

The second is population scoping. When a defect is found in a customer-affecting process, the first question a bank has to answer is how many customers were affected, and the answer has to be defensible enough to survive being wrong in the customer's favour. Scoping the population means enumerating every action taken under the authority that was defective. If authority is ambient, the population is every action the service principal took in the window, which will be dramatically larger than the true population — so the bank either over-remediates at cost, or under-remediates on a judgement it cannot evidence. That is a decision made under uncertainty that the architecture created and did not have to.

/** A service identity. Stable, long-lived, provisioned through joiner-mover-leaver. */
export interface ServicePrincipal {
  readonly kind: "service";
  readonly id: string;                    // e.g. "svc-agentplatform-prod"
  /** Owner of record in the CMDB. An owner is not an authoriser of any given action. */
  readonly ownerOfRecord: string;
  /** When the entitlement set was last recertified. Evidence about the entitlement, not the act. */
  readonly lastRecertifiedIso: string;
}

/** A natural person, as the accountability regime understands the term. */
export interface NaturalPerson {
  readonly kind: "person";
  readonly directoryId: string;
  readonly displayName: string;
}

export type Principal = ServicePrincipal | NaturalPerson;

/** One hop. Everything here is an observation of an invocation that happened. */
export interface Hop {
  readonly spanId: string;
  readonly parentSpanId: string | null;
  readonly operation: "invoke_agent" | "execute_tool";
  readonly component: string;             // "triage" | "retrieval" | "remediation" | ...
  readonly startedIso: string;
  readonly durationMs: number;
  /** Present only on the hop that reached a system of record. */
  readonly effect?: { readonly endpoint: string; readonly method: string };
}

/**
 * The run. The principal sits here rather than on Hop because it is a property of the
 * process, not of any hop: every hop executes under the identical value. Modelling it
 * per-hop would let a caller believe five facts were recorded where one was.
 */
export interface ChainRecord {
  readonly correlationId: string;
  readonly principal: ServicePrincipal;
  readonly hops: readonly Hop[];
  /** The boundary authentication. One event, at the edge, before any agent ran. */
  readonly boundarySession: { readonly sessionId: string; readonly authenticatedIso: string };
}

This sector already built the missing structure, twice, for order flow

The most useful thing about arguing this in banking and capital markets is that the field does not need to be persuaded the structure is possible. It already mandates it — not for agents, but for the one flow where attribution across handoffs was treated as a first-order regulatory problem.

Take the Market Access Rule first, because it is the closer analogue. 17 CFR 240.15c3-5(d) requires that a broker-dealer's risk management controls and supervisory procedures be "under the direct and exclusive control of the broker or dealer." That is the default, and it is a strong one. Then paragraph (d)(1) permits a narrow, structured exception: a broker-dealer "may reasonably allocate, by written contract, after a thorough due diligence review, control over specific regulatory risk management controls and supervisory procedures" described in paragraph (c)(2) to a customer that is itself a registered broker or dealer, and only where it has a reasonable basis for determining that the customer "has better access" such that it can more effectively implement the specified controls. Then paragraph (d)(2) closes it: "Any allocation of control pursuant to paragraph (d)(1) of this section shall not relieve a broker or dealer ... from any obligation under this section."

Read the shape of that rather than the subject matter. Delegation must be explicit. It must be written. It must name the parties. It must be scoped to enumerated controls rather than granted wholesale. It is restricted to a qualifying counterparty class. It requires a documented basis for believing the delegate is better placed. And it does not reduce the parent's obligation by one degree.

That is a carried, attenuated, parent-naming grant with a non-diminishing obligation, adopted as a rule in this sector in November 2010, with compliance phased in from July 2011. The same rule's paragraph (c)(2)(iii) requires controls reasonably designed to "restrict access to trading systems and technology that provide market access to persons and accounts pre-approved and authorized by the broker or dealer" — pre-approval of the specific principals, not a standing capability held by a shared service.

Then take the Consolidated Audit Trail, which solved the record half. Rule 613(c)(1) requires "an accurate, time-sequenced record of orders beginning with the receipt or origination of an order ... and further documenting the life of the order through the process of routing, modification, cancellation, and execution." Rule 613(c)(7) specifies the fields. At origination: the customer identifiers, the order identifier, and the reporter receiving or originating. At each routing event, both ends: the identifier of the party routing and the identifier of the party being routed to. And — the detail that matters most here — where an order is routed internally within a broker-dealer, the record must carry "the identity and nature of the department or desk to which an order is routed." An internal handoff, inside one firm and possibly inside one process, is not exempt from naming both ends.

I am citing these as existence proofs of the structure, not as law applicable to agent orchestration, and the distinction matters. Rule 613 governs the reporting of orders in NMS securities. Rule 15c3-5 governs market access. Neither one reaches a servicing chain adjusting a fee, and anyone who tells a bank otherwise is overselling. What they establish is narrower and quite sufficient: when this sector decided that attribution across handoffs was worth mandating, it did not mandate better logging and hope the chain could be reconstructed afterwards. It mandated a carried identifier and a named counterparty at each end, because reconstruction from logs was understood not to work.

That is the argument in one line. The field already knows that attribution across handoffs has to be carried rather than recovered. It knows it because it tried the other thing, at scale, with regulatory attention on it, and then wrote a rule.

The limits of the argument, and what would falsify it

Four things could be wrong here, and it is worth naming them at their strongest rather than in the weakened forms that are easy to answer.

The claim is about a prevailing pattern, not about every deployment. I am describing how agent stacks propagate authority in the frameworks and reference architectures currently in use. A bank that mints a per-hop credential from its own authorization server, bounded to the operation at hand and naming its parent, already has the object and this entire argument is inapplicable to it. I have not found such a deployment described in any primary source, but I have not surveyed the sector and absence of publication is not absence. One public, checkable counterexample — a production banking agent stack where each hop carries a distinct, more tightly bounded credential naming its parent — would confine this piece to a description of what the rest of the field is doing.

I cannot quantify the degradation, and I am not going to pretend otherwise. The obvious empirical question is how attribution accuracy falls as the number of agent-to-agent handoffs rises. I could not find a regulator, standards body or vendor publication that measures it. So there is no curve in this piece, no threshold, and no claim that attribution collapses after some particular number of hops. It is an open question. Anyone who attaches a number to it should be asked for the primary source, and if the answer is a survey of practitioners' impressions, that is not a measurement.

The regulatory reading could break in the institution's favour. The agencies might publish the request for information, run the consultation, and issue guidance that specifies exactly the controls an authority chain would provide. In that world a bank that built the evidence layer early merely built it early, which is the cheapest of all the ways to be wrong. The asymmetry is the point: the cost of building early is a design constraint absorbed while the stack is small, and the cost of building late is retrofitting attribution into chains already in production, which is the same problem as reconstructing it from logs.

The strongest falsifier is behavioural, and I cannot close it. If examiners in practice accept the control narrative paragraph — if the assertion that a service acts on a named owner's authority is treated as sufficient — then the gap has no supervisory consequence and this argument reduces to an aesthetic preference about evidence. I have no basis for claiming that examiners reject it, and I am not going to invent one. What I can point at is the guidance's own governance language asking for the individual responsible per lifecycle activity, the third-party principle that responsibility does not diminish, and the fact that the same regulators, in the same sector, wrote per-hop naming into rule text the moment attribution across handoffs mattered to them.

There is one more limit worth stating, because it cuts against the way this argument is usually deployed commercially. Nothing above shows that a bank should stop building agent chains, and nothing above suggests that the absence of an authority object has caused a loss anywhere. I am not aware of a published incident in this sector turning on this failure, and if I were, it would be in the sources rather than in a paragraph like this one. The argument is about what an institution can demonstrate when asked, which is a different and narrower claim than an argument about what will go wrong.

What an answer would have to be

This is the teardown. Building the answer here would collapse a pair of pieces into a worse single one, so I will name the properties and stop.

An authority record that survives a supervisory walkthrough has to have at least four properties, and the fourth is the one that usually gets dropped.

1. The grant is an object created at the handoff. Not a condition inherited from the environment, and not a field stamped onto a span after the fact. Something is constructed at the moment authority passes, or there is nothing to evidence.
2. It names its parent and is bounded more tightly than its parent. A grant identical to its parent carries no information — it is the same grant. If the chain does not narrow, the chain is decorative.
3. It is verified where the action lands, not only where it was issued. A check performed at the authorization server tells you a delegation was permitted. A check performed at the resource tells you this call was within the authority it was performed under, which is the question that was asked.
4. It terminates in a natural person, and the terminal link is the load-bearing one. Every other property can be satisfied by a chain of service identities delegating to each other forever. The regime does not want a well-formed chain; it wants the chain to end in someone answerable. That means the root grant has to be issued against a human decision that actually occurred, with the record of the decision bound into the grant rather than sitting in an adjacent ticket.

And it has to survive two conditions that a clean-room design tends to assume away: some hops are third-party and opaque, so the chain must be verifiable across a boundary the bank cannot see inside; and revocation has to be possible at the granularity of the chain rather than the principal, or the operational answer to a defect remains a blunt outage.

None of that is exotic. The credential constructions that support derivation without a round trip have been in the literature for over a decade, and the regulatory precedent for a written, enumerated, parent-naming delegation that does not relieve the parent has been on the books in this sector since 2010 and binding since 2011. What has not been done is the assembly, in a form an institution can operate and an examiner can walk through. That construction is the subject of the companion to this piece, "An authority chain that survives supervisory examination," which is forthcoming.

The reason to do it now rather than after the consultation is the reason the deferral is a stronger argument than the exemption reading. The agencies have not begun writing the specification. They have begun asking what should be in it — and as of the date on this piece, they have not yet asked. Whatever eventually gets written will be written against what institutions have already built, by people reading what the institutions did in the interval. That interval is open, and it is the only period in which what a bank builds influences what it is later measured against.