New OCC Rules: Bank AI Supervision Shifts to Proactive Control, Third-Party Dependency Emerges as Key Challenge

New OCC guidance requires banks to implement proactive control over AI, with passive audit trails no longer compliant and third-party dependency the biggest challenge.
The U.S. Office of the Comptroller of the Currency (OCC) has issued new supervisory expectations for bank AI deployment, explicitly requiring banks to demonstrate "proactive control" in six areas: AI model risk management, data governance, explainability, third-party AI dependency, operational resilience, and consumer protection. The wording shift from "monitoring" to "proactive control" marks a substantive paradigm change from detective to preventive controls—controls must take effect at the moment AI acts, not in post-hoc log review. This poses architectural challenges for banks already running AI in production, with a clear gap between legacy batch audit systems and the new standard. Third-party AI dependency is seen as the hardest area to reform, as banks have limited visibility into vendor component behavior and must renegotiate contracts, establish real-time interfaces, and even require control hooks. Community feedback shows most institutions are still in the early stage of assessing gaps.
The U.S. Office of the Comptroller of the Currency (OCC) has issued new supervisory expectations for banks deploying AI, significantly raising the compliance bar. The guidance identifies six areas where banks must demonstrate "proactive control": AI model risk management, data governance, explainability, third-party AI dependency, operational resilience, and consumer protection.
The wording change is critical—the OCC uses "proactive control" rather than "monitoring" or "logging." Passive audit trails no longer meet the standard.

A Paradigm Shift from Post-Hoc Detective Controls to Pre-Emptive Preventive Controls
This regulatory pivot creates concrete operational challenges for banks already running AI in production. These banks previously built compliance systems around post-hoc review, and today there is a clear gap between their architecture and what examiners expect.
The shift from detective controls to preventive controls is fundamentally not a documentation issue. It requires controls to exist at the very moment AI takes action, rather than being discovered hours later during log review. This means banks need to redesign control points in AI workflows, moving compliance checks forward into the decision-making step.
According to Reddit community discussions, practitioners widely agree that this real-time control requirement poses a substantial challenge to existing architectures, especially legacy systems that rely on batch auditing and periodic spot checks.
Detective Controls and Preventive Controls are two foundational categories in internal control and auditing. Detective controls aim to identify errors or violations after they occur, typically through log review, periodic reconciliation, anomaly alerts, and sample audits; their value lies in providing a traceable evidence chain, but they cannot prevent harm. Preventive controls are positioned before or at the moment a business event occurs, blocking non-compliant behavior through permission checks, rules engines, real-time interception, input validation, and similar mechanisms; their core characteristic is that they take effect "before or during action." In traditional IT governance, the two are usually complementary; the OCC's explicit demand for "proactive control" essentially requires banks to shift the center of gravity of AI compliance from detective controls to preventive controls, which poses a fundamental challenge to existing architectures that rely on batch logs.
Third-Party AI Dependency: The Thorniest Compliance Blind Spot
Among the six areas, third-party AI dependency is widely seen as the hardest to reform. Banks may be able to govern their own models, but they have limited visibility into the behavior of vendor or partner AI components running in the same workflow.
This "black box within a black box" problem is especially prominent in composite AI applications—when banks embed external APIs, pre-trained models, or SaaS services into their own processes, the control boundary becomes blurred. Examiners require banks to be accountable for the behavior of these external components, but banks often lack sufficient technical means to intervene in or explain their behavior in real time.
In community discussions, some practitioners noted that bringing third-party dependencies into a proactive control framework requires renegotiating vendor contracts, establishing real-time monitoring interfaces, and even requiring vendors to provide embeddable control hooks—none of which can be completed in the short term.
Third-party AI dependency in a regulatory context typically refers to financial institutions using models, APIs, SaaS services, or pre-trained components provided by external vendors to complete their own business processes. The risk of such dependency lies in the outward shift of the control boundary: banks lack full visibility into vendor model training data, version iteration, internal logic, and failure modes, yet they remain responsible for the final output. Regulators generally require banks to conduct due diligence, contractual constraints, continuous monitoring, and exit plans for third-party risk, but when AI components are embedded as black boxes in real-time workflows, traditional annual reviews and static contract terms struggle to meet the "proactive control" standard. In industry practice, embeddable control hooks, real-time telemetry interfaces, and model behavior contracts are emerging as technical directions to mitigate this problem, but no unified standard exists yet.
Practical Impact on Practitioners
For AI practitioners at regulated institutions, the OCC guidance means the focus of compliance work needs to shift from "proving we recorded what happened" to "proving we implemented controls at the moment it happened." This involves restructuring model risk management processes, refining data governance granularity, deploying explainability tools earlier, and establishing cross-departmental collaboration mechanisms.
It is currently unclear how many banks already have the architectural foundation to meet the new standards, but community feedback suggests most institutions are still in the early stages of assessing gaps and planning reforms. The third-party dependency issue especially requires industry-level collaboration and standard-setting; a single bank cannot solve it independently.

Model Risk Management (MRM) is a mature framework in bank supervision, originating from the SR 11-7 guidance issued by the Federal Reserve and OCC in 2011, which requires institutions to implement full-lifecycle governance over model development, validation, deployment, and continuous monitoring. Traditional MRM emphasizes independent validation, documentation, and periodic review, with a quarterly or annual cadence. The OCC's inclusion of AI in proactive control requirements means the MRM cadence needs to shift from periodic review to real-time or near-real-time intervention, and the validation target expands from static models to AI components that continuously learn or run in composite workflows. For practitioners, this is not just a tool upgrade but a systemic adjustment involving governance processes, role division, and evidence retention methods.
Conclusion
The OCC's new guidance marks a substantive shift in bank AI supervision from "post-hoc accountability" to "in-process control." For AI practitioners, the proactive control requirement tests not only the agility of technical architecture but also organizational maturity in vendor management, cross-departmental governance, and real-time risk intervention. Third-party AI dependency, as the weakest link, is likely to become the focus of the next phase of regulatory scrutiny and industry discussion.
Related articles
Tech FrontiersColdframe: A Honeypot Disguised as a Supermarket Freezer Controller
Coldframe is a honeypot disguised as Danfoss AK-SM 800A and Dixell XWEB freezer controllers, built as a single Python file that detects CVE-2025-41450 attempts and is identified as real devices on Shodan.
Tech FrontiersGRFNet: A Lightweight PyTorch Model Designed for Multichannel Time-Series Classification
GRFNet is a lightweight PyTorch model for multichannel time-series classification, originating from EEG decoding research. With only 3,847 parameters, it is based on the ROCKET architecture, combining random convolution kernels with learnable spatial filters, supports arbitrary input lengths, and will soon be evaluated on the PhysioNet dataset.
Tech FrontiersCUDA-Accelerated Rocket League Simulator: A Player-Made Hardcore Experiment
A Reddit post shows a "100% Accurate" Rocket League simulator accelerated with CUDA. We analyze its technical context, CUDA's value in game physics simulation, and the significance and limitations of such community projects.