Four Free AI Governance Tools for Banks and Fintechs: What Each Does and When to Use It

A compliance manager at a captive finance lender spent three weeks trying to answer one board question: “What AI systems are we running, and are any of them high-risk under the EU AI Act?” She had no inventory, no tiering method, and no policy that defined what “approved AI use” even meant at her organization. Her options were to hire a consultant immediately, wait for an internal working group to produce a terms-of-reference document, or find something she could use today on internal systems without exposing data to a third-party service. That third option did not exist in any form she could trust until she asked her security team why they could not just build it in the browser.

That scenario, with minor variations, is the conversation that produced the DSE AI governance tools suite: four free, in-browser utilities built for compliance leads, model risk officers, and AI governance managers at US banks, captive finance lenders, and fintechs. Each tool runs entirely in the browser. Nothing is sent to a server. That single design constraint is not a marketing point. It is what makes it reasonable to use them on real internal AI inventory data, internal policy drafts, or internal governance tracking before any vendor due diligence has been done on the tool itself.

This article explains what each tool does, when to use it, what it cannot do, and how to sequence the four so you get the most out of them before engaging DSE for the deeper work.

Why a free tool cannot replace an engagement

Be clear about the boundary before reading further. These tools are starter artifacts, not finished governance programs. They will help you organize your thinking, produce initial documentation, and understand where your program has gaps. They will not certify you under any standard, produce audit-ready evidence on their own, or substitute for the legal and regulatory analysis that classification work actually requires.

A browser-based AI system inventory generator produces a register you defined. An EU AI Act risk classifier produces a tier based on the answers you gave. An acceptable-use policy generator produces a template you edited. A NIST AI RMF checklist produces a completion percentage against the tasks you said were done. Each output is exactly as accurate as the input and judgment behind it, which is the same thing that is true of any internal draft.

The tools are useful at two specific moments: before an engagement, when you need to understand your AI footprint and build shared vocabulary with your board and risk committee; and during an engagement, when you want a structured starting point that a DSE senior team can review and extend rather than building from nothing. They are not a substitute for the engagement itself, which is where legal analysis, examiner-facing artifact construction, and the independent review of your program live. That work sits at the AI governance readiness engagement, not in a browser tab.

Start here: the AI system inventory

The AI System Inventory Generator is the right first tool, and not because it is listed first. It is foundational because every other governance activity depends on it. You cannot tier AI systems by risk if you do not know which systems exist. You cannot assign owners if you have no register to assign them against. You cannot satisfy the MAP function of NIST AI RMF 1.0 (NIST AI 100-1, January 2023) without a current, contextualized picture of your AI use.

The tool generates a tiered AI use-case register with fields drawn from NIST AI RMF MAP function suggested practices and EU AI Act documentation considerations for high-risk systems. For each system you enter, you record the system name, its owner, the business function it serves, the data it touches, whether it was internally built or vendor-supplied, and whether it has been through any formal review. For vendor-supplied systems, SR 11-7 makes clear that the using institution — not the vendor — is responsible for model risk management. The inventory should flag vendor-supplied systems for third-party model risk review under the June 2023 Interagency Guidance on Third-Party Relationships. The tool then lets you assign a risk tier across risk categories the EU AI Act uses: prohibited, high-risk, limited transparency, and minimal risk. You export the result as CSV or Markdown, which makes it easy to import into a governance platform or share with a risk committee.

Two things make this tool worth using even if you only build a partial inventory. First, the act of filling it in surfaces systems your team had not thought of as AI, because the field definitions force you to consider AI bundled inside vendor SaaS products that nobody reviewed when the contract renewed. Second, the exported register is a structured artifact a DSE team can extend immediately rather than starting from a spreadsheet you built in three different fonts over two years.

For a fuller treatment of the discovery problem that precedes inventory-building, including the eight channels that surface shadow AI across your environment, see the related article on banking AI governance and the shadow AI discovery guide in the same cluster.

EU AI Act risk tier: what it resolves and what it does not

The EU AI Act Risk Classifier walks you through a structured questionnaire to determine where a given AI system falls across the four risk categories: prohibited, high-risk, limited transparency, and minimal risk. The classifier asks about the system’s purpose, the population it affects, whether it makes or contributes to consequential decisions, and where it is placed or used in geographic terms.

The output is a preliminary tier assignment with an explanation of which factors drove the result and what the named tier’s obligations are at a summary level. If the system lands in the high-risk tier, the classifier identifies the relevant Annex III category and summarizes the obligations class, including risk management, data governance, logging, technical documentation, transparency, human oversight, and accuracy and robustness requirements.

What it resolves is the framing question. Many US banks and fintechs spend weeks debating whether the EU AI Act even applies to them before anyone has looked at a specific system. The classifier is a structured way to move from “does this apply to us” to “under what conditions and for which systems,” which is the more useful question. It also surfaces the extraterritorial scope issue: under Article 2(1)(e) of the EU AI Act, providers and deployers established outside the EU may be in scope where the output of an AI system is used in the EU — but ‘output used in the EU’ is a specific legal concept that requires analysis of the deployment facts, not simply a question of whether outputs affect EU individuals. A US captive finance lender with EU-based operations processing EU-resident applications is a clearer in-scope case than one scoring US-resident EU nationals. Use the classifier to surface which of your systems may present an extraterritoriality question, then engage counsel to confirm scope.

What it does not resolve is the precise legal classification of a specific system. That is the output of a real assessment, not a questionnaire. The EU AI Act has significant definitional nuances that require legal analysis: fraud detection systems and credit scoring systems are classified under different Annex III categories, and a system’s tier depends on the specific deployment facts and the Annex category it falls under, not on a simple rule. Use the classifier to organize your thinking and identify which systems warrant closer attention, not to produce a compliance determination. The precise applicability to any given system is assessment work, and that assessment is governed by the timeline described in the related EU AI Act article — note that the EU AI Act’s application dates are staggered: prohibited practices applied from February 2, 2025; GPAI model provisions from August 2, 2025; Annex III high-risk system obligations from August 2, 2026. US institutions should assess their current versus upcoming obligations on that schedule.

AI acceptable-use policy: when a template is enough and when it is not

The AI Acceptable-Use Policy Generator produces a complete policy document from a structured set of inputs. You specify your organization type (the generator offers healthcare, financial services, and government contracting clause variants), the scope of AI systems the policy covers, your approval and exceptions process, your data classification rules, and your expectations for human oversight of AI outputs. The generator assembles those inputs into a structured policy with a purpose statement, scope, definitions, acceptable use provisions, prohibited use provisions, oversight requirements, reporting obligations, and violation consequences. It exports to Markdown.

A template policy is enough in one specific case: your organization has no AI policy at all, the board needs to see that you have one, and the policy is going to be reviewed and edited by your legal team before it is adopted. In that case, the generator gives you a structured first draft in thirty minutes instead of three weeks, and legal starts from a document rather than a blank page. That is real value, and it is the honest use case.

A template policy is not enough in several cases that matter. It is not enough if it is the final artifact submitted without legal review, because the acceptable use provisions need to reflect your actual risk appetite and your actual regulatory obligations, neither of which are things a generator can know. It is not enough if your organization has AI embedded in credit decisioning, loan servicing, or fraud detection, because those systems carry SR 11-7 model risk supervisory expectations (SR Letter 11-7 applies to state member banks supervised by the Federal Reserve; OCC Bulletin 2011-12 is the OCC’s companion issuance for nationally chartered banks) and fair-lending obligations under ECOA and Regulation B that a generic finserv clause variant cannot fully capture. For fintechs subject to CFPB examination, also note CFPB Circular 2022-03 on adverse action and algorithmic models and the CFPB’s subsequent supervisory highlights addressing AI in credit underwriting, which are not covered by a generic finserv policy template. And it is not enough if it is treated as a governance program rather than one artifact within one. An acceptable-use policy without the inventory, the tiering standard, the committee structure, and the audit trail is a document in a binder, not a governance program. The distinction between the two is the subject of the related article on AI governance vs AI compliance.

NIST AI RMF checklist: using it to track readiness rather than claim compliance

The NIST AI RMF Checklist Generator organizes the NIST AI RMF 1.0 subcategories across the four functions, govern, map, measure, and manage, into a completion tracking interface. NIST subsequently published the AI RMF Generative AI Profile (NIST AI 600-1, July 2024), which addresses generative AI-specific risks across the four functions; institutions deploying generative AI should review it alongside the core framework. For each subcategory, you mark whether evidence exists, whether the work is in progress, or whether the gap is open. The tool tracks completion percentages by function and overall, and it exports the full checklist to CSV so you can share it with a risk committee or use it as a workplan for closing gaps.

The most useful thing about this tool is not the completion percentage. It is the structure it imposes on the question of where a program is thin. A bank running a credible SR 11-7 program will typically find, on first pass, that the measure and manage functions score relatively high, because independent validation, ongoing monitoring, and issue response are already SR 11-7 disciplines. The govern and map functions tend to score lower, because traditional model risk management was not built for AI-specific policy, AI use inventories with data-provenance fields, or third-party foundation-model due diligence. Those gaps are exactly the places where AI-specific risk lives, and seeing them spelled out by function is the first step toward a sequenced remediation plan rather than a general “we need to do more on AI.”

Use the checklist tool to understand the shape of your readiness gap and to structure the conversation with your board and risk committee. Do not use it to produce a compliance assertion. NIST AI RMF 1.0 is a voluntary framework with no certification program, and a completion percentage in a spreadsheet is not evidence of alignment. Evidence of alignment is the underlying artifacts: the policy, the inventory, the validation reports, the monitoring dashboards, and the committee minutes that show each function producing real decisions and real documents. The checklist helps you know which artifacts you have and which are missing. The NIST AI RMF for financial services article covers the full sequence for building that evidence base against an SR 11-7 program.

How to sequence the four tools

The sequence matters because the tools are not independent. The inventory feeds everything else, so it comes first. The risk classifier takes individual systems as inputs, so it depends on having a list of systems from the inventory. The acceptable-use policy needs to reflect the risk tiers the classifier produced, so it follows the classifier. The NIST AI RMF checklist is most useful once you have completed the other three, because several map and govern subcategories are specifically about the inventory and the policy, and you can only mark them complete if those artifacts exist.

Practically: spend an initial session with the inventory generator producing a first-pass register of the AI systems your organization runs, starting with systems that touch decisions or data rather than productivity tools. Run each system of concern through the risk classifier, focusing on any system involved in credit, underwriting, fraud, or customer-facing decisioning. Use the classifier output to inform which clause variants and restrictions you activate in the acceptable-use policy generator, then have legal review and adopt the result. Open the NIST AI RMF checklist, mark the inventory and policy artifacts as complete where they exist, and use the remaining gap as your remediation backlog.

That sequence, done in a single working session with each tool, produces: a structured first-pass AI inventory in CSV, a preliminary EU AI Act tier for each system of concern, a policy draft in Markdown that your legal team can review and adapt, and a documented readiness gap by NIST AI RMF function. Four starter artifacts, produced in a single working session, with nothing sent outside your browser.

What this guide is / What it is not

What it is: A practitioner guide to four free, in-browser AI governance tools built for compliance leads and model risk officers at US banks, captive finance lenders, and fintechs. It explains what each tool produces, when that output is sufficient, when it is not, and how to sequence the four. It is meant to give a compliance or governance team a structured starting point before or alongside a formal engagement.

What it is not: Legal or regulatory advice, a certification, a conformity assessment, or evidence of compliance with any standard. The tools produce starting artifacts, not finished governance programs. NIST AI RMF is voluntary and has no certification program. EU AI Act classification for a specific system requires legal analysis. ISO/IEC 42001:2023 certification requires a third-party audit. DSE prepares organizations for audit and examination; we do not certify, and we do not guarantee any exam or audit outcome. Any vendor promising guaranteed regulatory approval is selling certainty that does not exist.

FAQ

Are the DSE AI governance tools really free and do they send data to a server?

Yes, all four tools are free. They run entirely in the browser with no server-side component, which means no data you enter is transmitted to DSE or any third party. That design choice is deliberate: it removes the third-party data-sharing question before you use the tools on real internal AI inventory data or internal policy drafts, which is when they are most useful.

What is an AI system inventory and why does a bank or fintech need one?

An AI system inventory is a structured register of every AI system an organization runs or procures, including owner, business function, data handled, risk tier, and review status. For a bank or fintech, it is the prerequisite artifact for every downstream governance and compliance activity. You cannot tier systems by risk, assign owners, satisfy the MAP function of NIST AI RMF 1.0, or produce the documentation required for EU AI Act high-risk systems without a current inventory. Most organizations underestimate their AI footprint because AI now arrives bundled inside vendor SaaS products with no separate procurement event.

Does filling out a NIST AI RMF checklist make a bank compliant or certified?

No. NIST AI RMF 1.0, published as NIST AI 100-1 in January 2023, is a voluntary framework with no certification program. A completion percentage in a checklist is not evidence of alignment to the framework. Evidence of alignment is the underlying artifacts: the policy, the inventory, the validation reports, the monitoring dashboards, and the committee minutes that show each function producing real decisions and real documents. The checklist is a gap-identification tool, not a compliance claim.

Can a browser-based EU AI Act risk classifier tell us if our credit scoring model is high-risk?

A browser-based classifier can give you a preliminary tier assignment based on your answers to a structured questionnaire, which helps frame the question and identify which systems warrant closer attention. It cannot produce a legally authoritative classification for a specific system, because that requires legal analysis of how the system is deployed, what role it plays in a decision, and whether any definitional nuances of the EU AI Act apply to the specific deployment facts. For example, fraud detection AI and credit scoring AI sit under different Annex III categories, which affects the tier analysis in ways a questionnaire cannot fully resolve. Use the classifier to organize your thinking, then confirm the classification with counsel against your actual deployment footprint.

When should a bank or fintech use these tools versus engaging DSE directly?

The tools are most useful before an engagement, to understand your AI footprint and build shared vocabulary with your board and risk committee, and at the start of an engagement, to give a DSE senior team a structured starting point rather than a blank page. They do not replace an engagement for banks or fintechs that need examiner-facing artifacts, legal analysis of EU AI Act scope, SR 11-7-aligned validation evidence, or ISO/IEC 42001:2023 management system implementation. If your program needs to produce artifacts a US prudential examiner, internal auditor, or board committee can pick up and follow, that is engagement work.

Start with the tools, then call us

The AI governance tools suite exists because the compliance lead described at the top of this article is real, her problem is common, and the first step of a governance program should not require a signed engagement letter. Use the inventory to find your AI footprint. Use the risk classifier to understand which systems carry the most obligation. Use the policy generator to produce a first draft your legal team can review. Use the NIST AI RMF checklist to know where your gap is.

When those four artifacts are in hand and the gap is visible, the conversation about what to do next is a better one. That conversation is what the AI governance readiness engagement is designed for: a senior DSE team that can take your starting artifacts, review them against your actual SR 11-7 program and examiner posture, and build the readiness evidence a real audit or examination requires. When you are ready to move from starter artifacts to a defensible program, engage us.