Seven Controls for AI-Assisted Loan Pricing at Credit Unions

A credit union using AI or advanced analytics in loan pricing should separate four things: the board-approved pricing policy, the model’s recommendation, the employee or system authorized to act, and the evidence retained after the offer. Then it should test exceptions and borrower outcomes with the same discipline used for the model itself.

Pricing is not the same as underwriting. Underwriting asks whether and how much to lend. Pricing determines the rate, fees, term, discounts or other conditions offered after—or alongside—that decision. A tool may recommend a price from expected loss, funding cost, collateral, relationship data, market conditions or predicted take-up. It may also optimize within a rate sheet or route a case to an employee.

That can improve consistency and speed. It can also turn a broad policy range into thousands of individualized outcomes that are difficult to reconstruct. The control objective is therefore not merely to validate a model. It is to ensure that every offer remains inside approved authority, uses permitted information, produces a traceable record and can be monitored and corrected.

The current Regulation B resource, most recently amended July 21, 2026, says the rule protects applicants from discrimination in any aspect of a credit transaction. Its current text permits a creditor to consider information subject to specific limits, but prohibits using information to discriminate on a prohibited basis. The NCUA’s AI resource, updated April 28, 2026, says existing technology-neutral rules apply to AI and that examiners look at internal controls, ongoing monitoring and third-party due diligence.

Those sources do not prescribe a loan-pricing architecture. The seven controls below translate them into an operating design. Credit unions should map the framework to the product, applicable federal and state law, charter, risk appetite and counsel’s advice.

1. Put policy outside the model

Start with a board- or committee-approved pricing policy that the model cannot rewrite. Define eligible products and populations, minimum and maximum rates, fee limits, term options, risk tiers, relationship discounts, promotional authorities, floors tied to funding cost or return requirements, and any combination that is never allowed.

Convert those rules into a versioned policy table or rules service. The model may choose or recommend only inside that envelope. If a recommended price falls outside it, the system should reject the recommendation or route the case to a named exception process—it should not silently clip the value and hide the failure.

Evidence: approved policy version, effective dates, machine-readable boundaries, product mapping, test cases at every boundary and a record of who can change each element.

2. Trace every input and version

For each offer, retain the inputs actually used, their source and time, the derived variables, the model and rules versions, the rate sheet, and the output before any override. Distinguish applicant-provided data, bureau data, account history, collateral data and external market data. A field that appears harmless in a vendor interface may be a transformed variable assembled from several sources.

Define freshness rules and missing-data behavior. A pricing engine should not substitute a stale bureau value, default geography or inferred income without an approved rule and a visible flag. Reproduce a sample of offers from the retained record before launch and after every material change.

Evidence: data dictionary, permitted-use decision, source lineage, missing-value logic, model and rule hashes, and a replay test that returns the recorded recommendation.

3. Separate recommendation from authority

Document whether the tool suggests a rate, selects among approved offers, automatically sends an offer, or changes a price after member interaction. Those are different authorities. Assign each stage to a role and require an explicit approval for automation that can make or communicate a consequential offer without review.

Employees need to see the policy range, the recommended price, the allowed alternatives and the reason an exception is or is not permitted. They should not be able to enter any number, and they should not be forced to accept the recommendation merely because rejecting it is cumbersome.

Evidence: authority matrix, system permissions, approved automation level, human-review triggers, separation-of-duties test and logs showing who or what issued the final offer.

4. Turn exceptions into a controlled workflow

Pricing discretion often moves through exceptions: matching a competitor, recognizing a relationship, correcting data, retaining a member or addressing a documented product constraint. Create a finite list of exception reasons, define which roles may approve each one, cap the size and duration, and require supporting evidence.

Do not allow free-text notes to become an alternative pricing policy. Monitor exception requests, approvals, denials, size, approver, branch or channel, product, employee and subsequent performance. Review unusual concentrations and repeated “temporary” exceptions.

Evidence: reason code, requested and approved variance, approver, evidence reference, expiration, final terms and post-booking confirmation.

5. Preserve reasons that match the action

The member record should distinguish underwriting, pricing and counteroffer events. If the credit union takes adverse action, the notice workflow must reflect the action actually taken. The current Regulation B notification provision requires specific reasons or notice of the right to receive them in covered circumstances; generic model labels are not a substitute for the institution’s legal analysis.

Build reason mapping from the actual policy and decision path. Test whether the record can explain why one approved price was selected, why an alternative was unavailable and whether an employee changed the recommendation. Compliance should approve the notice and counteroffer logic before the model reaches production.

Evidence: event type, material factors and policy rules, counteroffer record, final communication, notice mapping, delivery time and retention schedule.

6. Monitor the full offer funnel

A portfolio average can hide a weak pricing process. Monitor the sequence from application to recommendation, exception, offer, acceptance, booking, performance, complaint, modification and payoff. Compare like-for-like segments defined by the approved policy, while ensuring any analysis of protected information is lawfully designed and access-controlled.

At minimum, review rate and fee distribution, exception and override rates, approval and counteroffer mix, take-up, time to decision, early delinquency, prepayment, complaints, corrections and member retention. Do not treat lower losses or higher yield as permission to ignore member outcomes or operating errors.

Set thresholds for investigation, not automatic conclusions. A shift may reflect applicant mix, product changes, funding conditions, employee behavior, data quality or the model. The investigation should identify the cause and the corrective owner.

Evidence: approved metric definitions, comparison groups, control limits, alert log, root-cause analysis, complaints linked to the decision record and remediation status.

7. Control change, rollback and correction

Pricing systems change even when the model does not. Rate sheets, funding costs, vendor features, data sources, employee permissions and product campaigns can alter outcomes. Classify each change, require regression tests proportional to its impact, and define who can approve release.

Maintain a tested rollback to the previous pricing package or to a manual rate sheet. The trigger should cover more than uptime: unexpected offer distribution, missing evidence, broken notice mapping, unauthorized exceptions, material data drift or a breach of an approved control threshold may all require containment.

Correction must reach members when appropriate. The runbook should identify affected offers, calculate the difference, stop additional use, preserve evidence, notify owners, determine member remediation with counsel and confirm closure.

Evidence: change ticket, impact assessment, test results, approval, deployment record, rollback result, affected-offer query and correction ledger.

A minimum decision record

For each offer, the credit union should be able to retrieve one compact record containing:

• application, member and product identifiers appropriate to the institution’s privacy design;
• policy, model, data and rate-sheet versions;
• inputs used and material derived variables;
• recommended price and approved range;
• exception or override request, reason, evidence and approver;
• final rate, fees, term, discounts and offer channel;
• decision and communication timestamps;
• notice or counteroffer record when applicable; and
• later correction, complaint or remediation link.

If the institution cannot reconstruct the offer from that record, it does not yet have an auditable pricing process.

Run five pre-launch tests

1. Boundary test: cases at, just below and just above every approved floor, ceiling, tier and fee limit.
2. Exception test: valid, invalid, oversized, expired and repeated exceptions across each role and channel.
3. Replay test: a production-like sample rebuilt from retained inputs and versions.
4. Outcome test: offer, acceptance, booking and early-performance results compared with the approved baseline and investigated for unexpected differences.
5. Rollback test: containment, prior-version recovery, affected-offer identification and member-correction workflow completed against a clock.

The NIST AI Risk Management Framework treats governance, mapping, measurement and management as connected activities. That is a useful design principle for pricing: policy establishes authority, the decision record maps what happened, monitoring measures results, and the rollback and correction process manages what happens next.

Credit unions do not need a separate control universe for every new model. They do need a pricing process that makes automated influence visible. The safest design keeps policy outside the model, discretion inside a governed workflow, and every member offer connected to evidence that can be tested, explained and corrected.