Skip to main content

For regional banks and credit unions

AI your risk function can sign off.

  • Decision models
  • Codified rules
  • Human in the loop
  • Decision records
  • Model risk
  • Evaluation
  • SR 26-2
  • BSA/AML
  • Fair lending

At a bank, the hard part isn’t building AI. It’s getting it approved. Bring us the idea or prototype your risk, compliance and model-risk teams haven’t signed off yet. In two weeks we codify the rules, measure error on your own past cases, and hand you the evidence your approvers ask for, before the bank funds the whole project.

What blocks adoption

Four reasons pilots stall in regulated firms.

One large bank took about five years to ship a new client portal. Building took time, but the approval cycles took longer.

  1. 01

    Unpredictable output

    Risk would sign off on more if the technology were reliable. A system that is usually right, and cannot say when it is wrong, does not pass review.

  2. 02

    No evidence the AI follows policy

    The rules are written down for people. Risk has no way to check that the AI applies them as written.

  3. 03

    No record of who decided what

    When an examiner asks, nobody can show the basis for a given decision.

  4. 04

    A good idea with no team to prove it

    Product and business leaders can see where AI would help, but have no engineers to build the evidence. The idea waits for a budget it can’t win without proof.

Who it is for

One pilot for both sides of the approval.

  • Product and business leaders

    Digital, commercial banking, onboarding, lending

    You have the idea. We give it the weight of evidence: rules risk can read, error measured on your own cases, and a record of every decision. You walk into approval with answers, not a proposal.

  • Risk, compliance and model-risk leaders

    Including BSA officers

    You set the rules and the threshold, and you get the measurements and records a review asks for.

  • COOs and CIOs

    One process proven under your controls, at a fixed price, makes the case for the next.

Where it starts

Four processes to start with.

We start where a person still makes the final decision.

  • Business-account onboarding and KYC exceptions

    Checking that each application’s documents are complete and consistent, and routing ownership and screening questions to the right reviewer. Identity verification and compliance approval stay as they are.

    Show compliance a measured error rate on last year’s business-account files, and the faster-onboarding project gets approved on evidence. The measures: abandoned applications and time to open.

  • Alert triage for anti-money-laundering checks

    A first read of each alert against your written criteria. The alerts your rules cannot settle go to an analyst.

    Prove the queue can be sorted at or below today’s analyst error rate before asking for headcount or a platform.

  • Credit memos and borrower documents

    Checking that a memo’s figures agree with the borrower’s statements, and that each policy rule was applied.

    Catch figure mismatches before credit committee, so fewer files come back.

  • Complaints handling

    Each complaint classified against your policy categories, with the basis recorded.

    Every complaint classified on the day it arrives, with the basis recorded for examiners.

The controls pilot

Four steps. One process. Measured.

  1. 01

    Choose one risk-prone decision process

    Narrow enough to finish, important enough to matter.

  2. 02

    Codify the rules

    Each business rule becomes a plain question with fixed answers, and each answer comes with how sure the system is. The model that answers is a decision model, built to return one answer from a fixed set with a probability. Your risk team can read and change every rule.

  3. 03

    Measure against your baseline

    How often the system gets a decision wrong on past cases with known outcomes, compared with how the process performs today.

  4. 04

    People decide the rest

    In the pilot, the system only sorts, checks and routes; it never approves, files or denies. Every case the rules can’t settle, or the system isn’t sure of, goes to a person at the threshold your risk team sets, and those cases show where the rules need to grow.

Deliverables

What you can take to a review.

  • Codified rules

    Your business rules, written so your risk team can read them and the system can apply them.

  • Measured error rates

    On past cases with known outcomes, against your baseline.

  • A decision record

    What was decided, on what evidence, by which model version, and who authorized it.

  • A working pilot

    Running on real cases alongside your current process, without acting on them.

  • The means to check it yourself

    The cases, the outputs and the scoring code, so your own team can rerun the measurement.

What stays under your control.

Scattered coral bars above a solid line, ordered rows below it
  • Known risks are written as rules your risk team can read, test and change.
  • Anything the rules do not cover, or the system is unsure of, goes to a person.
  • Consequential actions need a named person’s authorization.
  • Every decision is recorded with its basis.
  • Any model change is re-measured before it is used.
  • Sensitive data is masked before it reaches a model.

Built for the reviews you already face.

Each pilot is designed around the questions your examiners and second line already ask.

Model risk (SR 26-2, April 2026)

What the reviewer asks
Is the use tiered by risk? How was it validated, and how is it monitored?
What the pilot gives them
Rules they can read, error measured on past cases, the model version on every decision, and re-measurement before any model change

BSA/AML (FFIEC manual, CIP and CDD)

What the reviewer asks
Is due diligence still risk-based, with a person accountable?
What the pilot gives them
Onboarding and alert triage that only sorts and routes; analysts make every disposition

Fair lending (ECOA and Regulation B)

What the reviewer asks
Could this affect a credit decision or an adverse-action reason?
What the pilot gives them
Credit work limited to pre-review checks of memos and documents; no automated credit decisions

UDAAP and complaints

What the reviewer asks
Are complaints classified consistently and on time?
What the pilot gives them
Each complaint classified against your categories, with the basis recorded

Third-party risk (interagency guidance, 2023)

What the reviewer asks
Where does the data go, and can we check the vendor’s claims?
What the pilot gives them
A data boundary agreed first, sensitive data masked, and the cases and scoring code handed over so your team can rerun them

SR 26-2 is guidance from the Federal Reserve, OCC and FDIC. Credit unions are examined by the NCUA; for them, the pilot produces the same evidence for their examiners.

Proof

From our published work.

Who leads it

Rishi Diwan, Principal, Enterprise AI

Rishi Diwan

Principal, Enterprise AI

Leads the executive alignment, the business case and the first production pilot.

Rishi has spent more than 25 years getting new technology approved and adopted inside large institutions, at SAP, Salesforce, Exasol and JPMorgan Chase. At SAP he built the playbook for shipping a product in 90 days within a large enterprise’s existing constraints, and wrote the business plan that took SAP HANA to a $1 billion run rate in two years. He has worked in applied AI since 2016, consulted for Databricks and Domino Data Lab, and founded Light Craft Labs, an AI consulting firm.

How it begins

An approval pre-review, a controls pilot, then production.

  1. 2 weeks

    Approval pre-review

    Fixed price. We choose one process with you, draft its rules, set the baseline, list the questions your approvers will ask, and end with a go or no-go.

  2. 4 to 6 weeks

    Controls pilot

    Fixed scope and fixed price. Runs beside your current process on real cases, without acting on them.

  3. By agreement

    Production

    Integration, monitoring and handover to your teams.

Questions

Fair questions,straight answers.

What is a decision model?

A model built to answer one defined question with one answer from a fixed set, and a probability. A language model returns free text. A fixed answer with a probability is easier to measure, to set a threshold on and to keep a record of.

How does this fit our model risk framework?

The pilot produces what a review under SR 26-2 asks for: codified rules, error measured against your baseline, a record of each decision with its model version, and named authorization for consequential actions. It does not replace your own validation; it gives your validators evidence to work from.

Which models do you use?

A decision model applies the rules. Our default is TypeSafe’s Jev, which we have run in production since before its public launch, because it returns a defined answer with a probability and costs little enough to run on every case. Where your data rules call for a different setup, we choose the model with you and measure it the same way. Language models are used where text has to be read or written, and only where the rules allow.

Where does it run?

We agree the data boundary before any work begins. Where your policy requires your own environment or a particular region, we choose a model that can run there.

Who should bring you in?

Usually the product or business leader who owns the idea, with risk or compliance at the table from the first week.

We’re a smaller bank or credit union. Is this for us?

Yes. It is built for one process at a fixed price, with no platform to buy.

What do you need from us?

A sponsor, the people who own the process, a set of past cases with known outcomes, and access to a test environment.

What if the pilot shows it is not ready?

Then you have learned that for the price of a pilot, with the measurements to show why.

Next step

Prove it on one process.

A 20-minute pre-review of one AI idea: what your approvers will ask, and the evidence that answers it.

Request an approval pre-review