The Adverse Action Letter Should Be Tested Before the AI Vote

A practical weekly article for community-bank and credit-union boards and senior leaders on treating adverse action notices as the governance test before approving AI-enabled le...

The cleanest AI demo happens before the hard question shows up.

The vendor walks through the workflow. The model ranks applications. The dashboard explains throughput, consistency, fraud reduction, or faster decisions. The lending team sees less review. Compliance sees configurable rules. Executives see a way to compete without hiring a small army.

That is the attractive part.

Then someone asks what the denied applicant will receive.

Not eventually. Not after legal rewrites the template. Not after the vendor says the model is proprietary. What will the actual adverse action notice say, and can the institution defend it?

That is where the AI approval packet should slow down.

For a community bank or credit union, an automated underwriting tool, pricing model, account-opening score, fraud screen, or loan-decision assistant is not just a technology upgrade. It is a governance decision about evidence, accountability, and regulatory defensibility.

The board does not need to understand the math behind every model feature. Please do not turn directors into part-time data scientists.

But the board and senior leaders should expect management to prove that an automated decision can be explained in plain language to the person affected by it.

If the institution cannot explain the no, it is not ready to approve the yes.

The adverse action notice is not paperwork

Adverse action notices are easy to underestimate because they look like forms.

Forms feel administrative. Technology feels strategic. So the approval conversation drifts toward implementation timelines, vendor due diligence, integration cost, cybersecurity review, and model performance.

But the form is where strategy becomes a promise to a real person.

If a member is denied credit, receives less favorable terms, or is affected by a covered decision, the institution cannot hide behind a black box. It has to communicate specific reasons in a way the applicant can understand and potentially address.

That makes the notice a governance artifact.

It shows whether the institution understands the decision system well enough to explain it, challenge it, monitor it, and correct it.

The Consumer Financial Protection Bureau made this point directly in 2022. The CFPB said federal anti-discrimination law requires companies to explain the specific reasons for denying an application or taking other adverse action, even when the creditor relies on complex algorithms. The release also quoted Director Rohit Chopra saying companies are not absolved of legal responsibilities when they let a black-box model make lending decisions.

Source: CFPB, “CFPB Acts to Protect the Public from Black-Box Credit Models Using Complex Algorithms,” May 26, 2022: https://www.consumerfinance.gov/about-us/newsroom/cfpb-acts-to-protect-the-public-from-black-box-credit-models-using-complex-algorithms/

That is not a footnote for compliance.

It is a design requirement.

Example one: the reason has to match the real decision

The first board-level test is simple: can management show a sample adverse action notice for the actual decision workflow being approved?

Not a generic template. Not a vendor brochure. Not a compliance policy that says the right thing at 30,000 feet.

A real sample.

Take three declined applications from a test sample. For each one, show:

1. The decision outcome. 2. The key factors that drove the result. 3. The adverse action reasons that would be disclosed. 4. The evidence source for each reason. 5. The owner responsible for reviewing accuracy.

This is where vague AI governance becomes practical.

If the model says the application is too risky but the notice says “insufficient credit history,” leadership should ask why. If the system uses hundreds of variables but the notice produces a canned reason that does not line up with the real decision, the institution may have a fairness and compliance problem hiding inside a tidy workflow.

The risk is not only that the model is wrong.

The risk is that nobody can tell whether the explanation is right.

A community institution can recover from a tool that needs tuning. It is much harder to recover from a system that makes decisions management cannot explain.

Hope is not a control. It is a mood.

Example two: the regulators are watching automated systems as civil-rights systems

In 2023, the CFPB, Department of Justice Civil Rights Division, Equal Employment Opportunity Commission, and Federal Trade Commission issued a joint statement on automated systems. The agencies said automated systems are increasingly used for high-impact decisions, and existing legal authorities still apply.

Source: CFPB, DOJ, EEOC, and FTC, “Joint Statement on Enforcement Efforts Against Discrimination and Bias in Automated Systems,” April 25, 2023: https://www.consumerfinance.gov/about-us/newsroom/joint-statement-on-enforcement-efforts-against-discrimination-and-bias-in-automated-systems/

For boards, the lesson is not “never use automation.” That would be lazy.

The lesson is that automation does not move the institution outside the normal accountability structure. If the bank or credit union uses a vendor model, embedded score, machine-learning feature, or rules engine to influence credit access, pricing, fraud friction, or account eligibility, the institution still owns the impact.

That ownership needs to show up before launch.

A useful approval packet should answer four plain questions:

1. Which decisions will the tool make, recommend, score, or route? 2. Which populations, products, and channels are affected? 3. How will management test for disparate impact, error patterns, override trends, and complaint signals? 4. Who can pause, adjust, or retire the tool if the evidence turns ugly?

Notice the word “who.”

AI governance gets weak when responsibility is spread politely across technology, lending, compliance, vendor management, legal, operations, and risk. Everyone has a piece. Nobody owns the full sentence.

The board should want the full sentence.

Management should be able to say who owns decision logic, compliance review, vendor challenge, monitoring, and stop authority.

That is not bureaucracy. That is adult supervision.

Example three: third-party risk does not stop at procurement

Many community banks and credit unions will not build these models from scratch. They will buy them, enable them, inherit them through a loan platform, or discover them inside a “feature enhancement” from a vendor.

That does not make the governance job smaller.

In 2023, the Federal Reserve, FDIC, and OCC issued final joint guidance on third-party risk management. The agencies described third-party risk management as a life-cycle process that includes planning, due diligence, contract negotiation, ongoing monitoring, and termination. They also emphasized that banking organizations should tailor risk management to the relationship’s risk and complexity.

Source: Federal Reserve, FDIC, and OCC, “Agencies issue final guidance on third-party risk management,” June 6, 2023: https://www.federalreserve.gov/newsevents/pressreleases/bcreg20230606a.htm

For an AI-enabled lending or account-opening tool, due diligence should not stop at SOC reports, uptime, insurance, and data security. Those are table stakes.

The board packet should show how management will challenge the model after signing.

That means asking for evidence about training data, validation, change notices, monitoring reports, override controls, audit rights, complaint support, data retention, subcontractors, and model updates. It also means knowing what to do if the vendor changes the model and the adverse action reasons suddenly shift.

A vendor release note should not quietly rewrite the institution’s fair lending posture.

What should be in the AI approval packet

A practical packet does not need a dissertation. Do not bury the board in model documentation until everyone approves the thing out of self-defense.

Start with five exhibits.

Show where the tool enters the workflow. Does it decide, recommend, rank, route, price, flag, or merely summarize? The difference matters.

Show sample decisions and adverse action reasons. Tie each reason back to the actual evidence used.

3. Human review path

Name when a human must review the output, who can override it, how overrides are documented, and how override trends are monitored.

4. Monitoring plan

Define the post-launch evidence: approval rates, denial reasons, protected-class testing where applicable, exceptions, complaints, overrides, vendor changes, and error trends.

5. Stop authority

Name who can pause the workflow if the model, vendor, data feed, or explanation process fails. A stop button without an owner is just a decoration.

The real vote is about accountability

Automation can absolutely help community institutions. Faster decisions matter. Consistency matters. Staff capacity matters. Member experience matters.

But speed is not the only measure of a good lending system.

A good system can also explain itself well enough for management to govern it, compliance to test it, staff to challenge it, and the applicant to understand the decision.

That is the standard boards should care about.

Before approving the next AI-enabled lending tool, automated underwriting enhancement, or account-opening score, ask to see the adverse action letter. Then trace it backward through the workflow.

If the explanation is clear, specific, evidence-based, and owned, the institution is closer to responsible automation.

If the explanation is vague, generic, vendor-dependent, or disconnected from the real decision, the approval packet is not finished.

The question is not whether the technology is impressive.

The question is whether the institution can defend the decision when the person on the other side asks why.

Board and executive discussion questions

1. For the next AI-enabled lending, account-opening, or pricing tool, can management show a real sample adverse action notice and trace each reason back to the decision evidence? 2. Who owns post-launch monitoring of denial reasons, overrides, complaints, vendor model changes, and fair-lending signals, and who has authority to pause the workflow? 3. Which current vendor system already influences eligibility, pricing, routing, or fraud friction in ways we have not reviewed as an automated decision system?