Here's a fun trivia question for your next tech meetup: what piece of legislation, older than the light bulb, is going to shape how national banks deploy AI for the foreseeable future? The answer isn't some freshly minted executive order or a shiny new congressional framework—it's the National Bank Act of 1864. Yes, Abraham Lincoln was still signing wartime legislation when this thing was drafted, and yet here we are, trying to stretch it over large language models and automated underwriting systems.

Welcome to AI regulation in the financial sector, where the cutting edge meets the genuinely ancient.

Why a Civil War-Era Law Still Has Teeth

The National Bank Act established the Office of the Comptroller of the Currency (OCC), the federal agency that charters and supervises national banks. And here's the thing—the OCC hasn't been sitting on its hands. Its authority under this 160-year-old statute turns out to be surprisingly elastic. The law grants the OCC broad power to define what constitutes safe and sound banking practices, which means it doesn't need Congress to pass new AI-specific legislation to start setting expectations. It can simply declare that deploying a poorly governed AI model is an unsafe banking practice and regulate accordingly.

That's either reassuring or terrifying, depending on where you sit.

The "Safety and Soundness" Framework Is Doing a Lot of Heavy Lifting

If you work in fintech or bank technology, you're going to want to tattoo the phrase "safety and soundness" somewhere visible. This is the OCC's foundational standard, and it's the lens through which every AI deployment at a national bank will eventually be scrutinized. Think of it as the regulatory equivalent of "does this thing work, and could it blow up the bank?"

Under this framework, examiners aren't just asking whether your AI model produces accurate outputs in a demo environment. They're asking questions like:

• Can your team actually explain how the model makes decisions? (Explainability isn't optional.)
• Have you stress-tested the model against data distributions it wasn't trained on?
• Do you have human oversight mechanisms that aren't just theater?
• Are there audit trails that would survive a congressional hearing?

If your answer to any of those is "we trust the model," congratulations—you've just described an unsafe banking practice.

Model Risk Management: The Regulation That Already Exists

Here's what a lot of breathless AI-in-banking coverage conveniently skips: robust AI governance guidance for banks isn't new. The OCC's SR 11-7 guidance on Model Risk Management has been on the books since 2011. It was written with quantitative financial models in mind, but its core requirements—validation, documentation, ongoing monitoring, clear ownership—map almost perfectly onto modern AI systems.

The uncomfortable truth is that many banks deploying AI today are doing so in ways that would already fail a rigorous SR 11-7 audit. The models are more complex now, the data pipelines are messier, and the outputs are harder to interpret. But the governance expectations haven't fundamentally changed. They've just become harder to meet.

The regulatory bar isn't being raised so much as it's being applied to systems that were built assuming no one would check.

Fair Lending Is Where This Gets Really Complicated

Overlay the National Bank Act's safety and soundness framework with fair lending laws—the Equal Credit Opportunity Act, the Fair Housing Act, the Community Reinvestment Act—and you get a compliance matrix that should keep bank risk officers awake at night. AI models trained on historical data have a well-documented tendency to encode and amplify historical biases. A model that denies credit at higher rates to protected classes isn't just an ethical problem; it's a legal liability under laws that have been on the books for decades.

The OCC, along with the CFPB and the Fed, has been increasingly explicit that "the algorithm did it" is not a valid compliance defense. If your AI model produces disparate outcomes, you own those outcomes. Full stop. The burden of proof runs toward the bank, not away from it.

This matters enormously for anyone building AI-powered underwriting, pricing, or customer service tools. Disparate impact analysis isn't a nice-to-have feature you bolt on at the end—it needs to be baked into model development from day one.

What This Means for Banks Actually Building Things

If you're an engineer or product lead at a national bank, here's the practical translation of all this regulatory archaeology:

• Document everything. Not just model performance metrics, but training data provenance, validation methodology, and the business rationale for every significant design choice. Assume an OCC examiner will read it.
• Build interpretability in, not on. Black-box models that perform well in backtests but can't be explained to a regulator are a liability. SHAP values and LIME aren't perfect, but they're better than a shrug.
• Third-party AI is still your problem. Buying an AI tool from a vendor doesn't transfer the compliance obligation. The OCC has been clear: if you deploy it, you're responsible for governing it.
• Continuous monitoring isn't optional. Models drift. Data distributions shift. A model that was fair and accurate at launch can become neither over time without ongoing surveillance.

The Bigger Picture: Regulatory Clarity Is Coming, Slowly

Congressional AI legislation specifically tailored to banking is somewhere on the horizon, but "somewhere on the horizon" in Washington terms could mean five to ten years. In the meantime, the OCC will continue to exercise authority under a law signed before electricity was commercially available, using a model risk framework designed before modern deep learning existed.

Is that ideal? Obviously not. But it's the environment you're operating in, and pretending otherwise is how banks end up with enforcement actions that could have been avoided with better governance upfront. The 160-year-old law isn't going anywhere soon. Better to understand it than to be surprised by it.

The good news, if you squint at it right: the OCC's principles-based approach gives banks more flexibility than prescriptive rules would. You're not told exactly how to govern your AI—you're told it needs to be safe, sound, fair, and explainable. How you get there is largely up to you. That's a wide lane for engineers and product teams who take governance seriously from the start.

The bad news: that flexibility disappears fast when an examiner decides your governance framework is mostly slide decks.