Raphael Amponsah, PhD

AI & Data Product Architect

Open framework · Version 1.0

SAFER: governing AI in regulated financial institutions

Five pillars, twenty controls, and one evidence scale, reviewed every quarter inside the governance your institution already runs. Free to read, use, and cite.

Check your institution How to cite

Version: 1.0
Published: 1 October 2026
Editor: Raphael Kofi Amponsah
Licence: CC BY-ND 4.0

What SAFER is

SAFER is a framework for governing the use of AI in banks, savings and loans companies, microfinance institutions, fintechs, and insurers. It sets out five pillars, four controls in each, and one scale for scoring every control on evidence. The result is a single score a board can read, backed by twenty named controls a risk team can act on.

It was developed for governing AI inside a regulated commercial bank in Ghana, where staff were already using AI tools and customer data is protected by the Data Protection Act, 2012 (Act 843). The Bank of Ghana's Cyber and Information Security Directive of March 2026 now sets binding rules for AI in regulated financial institutions, and every SAFER control is mapped to it.

Evidence, not intent.
A control is scored on what the institution can show today, not on what its policy says should happen.
Inside existing governance.
SAFER adds no committee and no parallel process. The score goes to the meeting that already reviews risk.
Outcomes, not products.
Controls describe what must be true and the evidence that shows it. Any tool or procedure that produces the evidence meets the control.

The five pillars

Each pillar answers one question a regulator, auditor, or board will ask about AI, and holds four controls.

Secure
Who can use AI, with what access, from which vendors.
Accountable
Who owns AI risk, and where it is reported.
Filtered
What data reaches AI tools, and how that is enforced.
Ethical
How AI affects customers, and who checks.
Resilient
What happens when AI fails or goes wrong.

Filtered is the pillar most often met with software, because it governs what data reaches an AI service. SAFER does not require any particular product to meet it.

The evidence scale

Every control is placed on the same five levels. The scale measures what is, not what is intended.

Level	Label	What it means
0	Absent	The control does not exist. There is no policy, no process, and no evidence.
1	Aware	The control is acknowledged in writing, but nothing is implemented.
2	Defined	A documented procedure exists. It is not yet routine.
3	Practised	The control runs on a defined cadence and produces evidence.
4	Audited	An independent party reviews the control, and its findings drive change.

Scoring and posture

Score each control on the evidence available today. With no evidence at all, the score is 0.
When you cannot decide between two adjacent levels, choose the lower. An institution that over-scores discovers its real posture when a regulator or an incident does.
A pillar score is the mean of its four control scores, rounded down to one decimal place.
The overall score is the mean of the five pillar scores, rounded down the same way, and maps to a posture.

Overall score	Posture	Recommended action
0.0 to 1.0	Exposed	Stop new AI deployments; remediate before continuing.
1.1 to 2.0	Forming	Consolidate documentation; convert intent into routine.
2.1 to 3.0	Operational	Maintain cadence; move highest-risk controls to level 4.
3.1 to 3.5	Mature	Audit-ready; commission independent review.
3.6 to 4.0	Audited	Sustain and refresh annually.

Cadence

Score every quarter, at the meeting where the institution already reviews its other risk measures, usually the Risk Committee. Do not create a separate AI-risk meeting. The review needs no more than 45 minutes: rescore, discuss what moved, and agree two changes for the next quarter, each with a named owner.

The first full scoring takes about a working day. By the fourth quarter it takes less than an hour.

The twenty controls

Each control states what must be true and what an institution shows to score it. Controls marked Check are also asked in the AI Readiness Check.

S · Secure: Who can use AI, with what access, from which vendors.

ID	Control	Evidence
S1Check	Approved tools onlyStaff use only AI tools on the institution's approved list, signed in through accounts the institution manages.Evidence: An Approved AI Tools Register, and sign-in records showing staff use institution accounts.NIST AI RMF: GV 1.6, GV 6.1 · NIST AI 600-1: GV-6.1-007 · Act 843: s.28(1) · BoG CISD 2026: ¶25(2), ¶64(1)	An Approved AI Tools Register, and sign-in records showing staff use institution accounts.
S2Check	Access limited to needEach AI tool, integration, or agent can reach only the data and systems its role needs, enforced by the systems it touches rather than by instructions to the AI. An agent cannot take an action that is irreversible or affects a customer without a person's approval, it can be stopped, and its actions are logged and reviewed.Evidence: A map of what each AI tool and agent can reach, reviewed against need; permission settings; approval records; and reviewed action logs.NIST AI RMF: MAP 4.2, MS 2.7 · Act 843: s.28(1) · BoG CISD 2026: ¶38(1), ¶100(3); Annexure E (h), (j)	A map of what each AI tool and agent can reach, reviewed against need; permission settings; approval records; and reviewed action logs.
S3Check	AI vendors assessedBefore use, at least every two years, and on material change, each AI vendor is assessed for where data is stored, how long it is kept, who can access it, whether it is used to train models, and what the vendor documents about testing, intended use, and known limits. The contract requires notice of model changes and gives the institution the right to evidence.Evidence: Completed vendor assessments, and written contracts covering these points.NIST AI RMF: GV 6.1, MG 3.1 · NIST AI 600-1: GV-6.1-009 · Act 843: s.30 · BoG CISD 2026: ¶83, ¶97 · BoG Outsourcing Directive 2024: ¶33	Completed vendor assessments, and written contracts covering these points.
S4	Unapproved use detectedUse of unapproved AI tools on institution devices and networks, including through personal accounts, is detected and acted on.Evidence: A regular report of traffic to AI services, and the follow-up recorded for each finding.NIST AI RMF: GV 1.6, MG 2.3 · NIST AI 600-1: MG-2.3-001 · Act 843: s.28(2) · BoG CISD 2026: ¶64(3)	A regular report of traffic to AI services, and the follow-up recorded for each finding.

A · Accountable: Who owns AI risk, and where it is reported.

ID	Control	Evidence
A1Check	AI registerA current register records every AI tool and use case: who uses it, the data it touches, the vendor, the model and version, the risk tier, and how far it acts on its own.Evidence: A dated register, reviewed at least every quarter.NIST AI RMF: GV 1.6 · NIST AI 600-1: GV-1.6-001 · BoG CISD 2026: ¶23(1), ¶100(4); Annexure E (d)	A dated register, reviewed at least every quarter.
A2Check	Named ownersEach AI use case has one named person accountable for its risks.Evidence: A named owner against every entry in the register.NIST AI RMF: GV 2.1 · Act 843: s.17 · BoG CISD 2026: ¶24(1), ¶100(4)	A named owner against every entry in the register.
A3Check	Reported every quarterA named AI Risk Owner, independent of the business lines that use AI, reports AI risk, including the SAFER score, to senior management and the Board, through an existing committee, at least every quarter.Evidence: The appointment in writing, committee and Board papers or minutes, and the AI summary in regulatory returns where required.NIST AI RMF: GV 1.5, GV 2.3 · BoG CISD 2026: ¶100(9), ¶115(1); Annexure E (a)	The appointment in writing, committee and Board papers or minutes, and the AI summary in regulatory returns where required.
A4	Approved before useNo new AI use case starts until an intake record is approved, naming the owner, the tool, the data, the risk tier, and who checks the outputs. A use that affects customers or acts on systems must first pass tests for accuracy, fairness, and misuse such as prompt injection, and a high-risk use needs the approvals the regulator requires, such as the Board's. Approval is revisited at least once a year and whenever the use or the model changes.Evidence: Approved intake records with risk tiers, test results, and Board or regulatory approvals, and an Approved Use Cases log that matches what is in use.NIST AI RMF: MAP 1.1, MG 1.1 · Act 843: s.22, s.25 · BoG CISD 2026: ¶98(1), ¶98(4), ¶100(5), ¶122; Annexure E (a), (e)	Approved intake records with risk tiers, test results, and Board or regulatory approvals, and an Approved Use Cases log that matches what is in use.

F · Filtered: What data reaches AI tools, and how that is enforced.

ID	Control	Evidence
F1Check	Written data ruleA written rule, signed by staff, says what data may and may not enter AI tools. By default, customer personal data does not go to an external AI service without a lawful basis, equivalent protection, and any approval required to send it outside Ghana. Its examples include Ghana Card numbers, account data, and special personal data such as health records.Evidence: The published rule, and signed acknowledgements.NIST AI RMF: GV 1.4 · NIST AI 600-1: GV-1.4-002 · Act 843: s.28(1), s.37 · BoG CISD 2026: ¶25(2); Annexure G 3(h), 3(i)	The published rule, and signed acknowledgements.
F2Check	Enforced before sendingSensitive data is detected and removed or replaced before it reaches an external AI service, both in staff prompts and in customer-facing AI, for everyone with access. Samples of what gets through are tested.Evidence: A detection or redaction control in each path to external AI services, its coverage, its logs, and test results.NIST AI RMF: MG 3.1, MS 2.10 · NIST AI 600-1: MG-3.1-001 · Act 843: s.19, s.28(2) · BoG CISD 2026: ¶98(2); Annexure E (f)	A detection or redaction control in each path to external AI services, its coverage, its logs, and test results.
F3Check	Visibility of data sentThe institution can see what kinds of data reach external AI services, reviews it on a set cadence, and fixes what the control missed.Evidence: Reports by type of data, review records, and the fixes made.NIST AI RMF: MS 1.2, MS 2.10 · Act 843: s.28(2) · BoG CISD 2026: ¶64(3), ¶82(2)	Reports by type of data, review records, and the fixes made.
F4	Purpose and minimum dataPersonal data is used to build, train, or feed an AI system only for a specific purpose that is compatible with why it was collected and covered by the institution's data protection registration, using only as much as that purpose needs, kept accurate and up to date.Evidence: A data protection impact assessment for each AI system that uses personal data, signed off by the data protection officer.NIST AI RMF: GV 1.1, MS 2.10 · Act 843: s.17, s.19, s.22, s.25, s.26 · BoG CISD 2026: ¶99(2); Annexure E (f)	A data protection impact assessment for each AI system that uses personal data, signed off by the data protection officer.

E · Ethical: How AI affects customers, and who checks.

ID	Control	Evidence
E1Check	Review in proportion to riskAI output is reviewed in proportion to what is at stake. A decision about an individual customer, such as declining credit or blocking an account, gets a recorded review by a competent person with authority to override. High-volume alerts, such as fraud flags, are sampled against set thresholds. Other output is checked by the person who relies on it.Evidence: Review records, overrides with their reasons, sampling rates, and the thresholds used, kept as long as regulation requires.NIST AI RMF: GV 3.2, MAP 3.5 · Act 843: s.41 · BoG CISD 2026: ¶97(2); Annexure E (j)	Review records, overrides with their reasons, sampling rates, and the thresholds used, kept as long as regulation requires.
E2Check	Fairness testedAI outputs that affect customers are tested for unfair differences between customer groups, such as region, gender, age, or income, including differences in error rates, before launch and after every model change. Where a material unfair difference is found, the use is suspended until it is fixed in the data, the model, or the decision rule.Evidence: Test results, any suspensions, and the fixes made.NIST AI RMF: MS 2.11 · NIST AI 600-1: MS-2.11-002 · BoG CISD 2026: ¶115(2), ¶122(1); Annexure E (g), (l)	Test results, any suspensions, and the fixes made.
E3Check	Customers toldCustomers are told in plain words when AI is used in a decision or conversation that affects them, what it does with their data, and how to reach a person. A customer is told when a decision about them was made solely by automated means. AI is never presented as a person.Evidence: Customer notices, scripts, or terms, and a check that customers, including vulnerable customers, understand them.NIST AI RMF: MS 2.8 · Act 843: s.23, s.41(2) · BoG CISD 2026: Annexure E (l)	Customer notices, scripts, or terms, and a check that customers, including vulnerable customers, understand them.
E4	Decisions explainedA customer can get the main reasons for an AI-assisted decision about them in plain language, and can challenge it and have a person reconsider it, with a written response within 21 days. Detail that would help someone evade fraud controls may be withheld.Evidence: Sample explanations, and the record of challenges, responses, and outcomes.NIST AI RMF: MS 2.9, MS 3.3 · Act 843: s.35, s.41 · BoG CISD 2026: ¶100(2); Annexure E (j), (l)	Sample explanations, and the record of challenges, responses, and outcomes.

R · Resilient: What happens when AI fails or goes wrong.

ID	Control	Evidence
R1Check	AI incident planThe existing incident plan covers AI scenarios: data exposed through a prompt, a harmful or wrong output, manipulated input such as prompt injection, an agent acting outside its permissions, and a vendor failure. It names who outside the institution must be told and by when. AI incidents are reported internally within 24 hours, and the plan is tested with an AI scenario at least once a year.Evidence: The plan and its notification matrix (in Ghana: the Bank of Ghana immediately for leaked customer data or a material AI incident; the CERT within 24 hours; the Data Protection Commission and affected customers as soon as reasonably practicable), incident reports, and the latest exercise record.NIST AI RMF: GV 4.3, MG 4.3 · NIST AI 600-1: MG-4.3-003 · Act 843: s.31 · BoG CISD 2026: ¶50, ¶100(7), ¶115(2) · Act 1038: s.47(5)	The plan and its notification matrix (in Ghana: the Bank of Ghana immediately for leaked customer data or a material AI incident; the CERT within 24 hours; the Data Protection Commission and affected customers as soon as reasonably practicable), incident reports, and the latest exercise record.
R2Check	Fallbacks testedAny AI tool can be stopped at once with a tested kill switch, and each critical process that uses AI keeps running, through a manual or rule-based fallback, if the AI service fails, changes, or is withdrawn.Evidence: The kill-switch procedure, and a documented fallback for each critical process, each with the date it was last tested.NIST AI RMF: GV 6.2, MG 2.4 · NIST AI 600-1: GV-6.2-006 · BoG CISD 2026: ¶97(2), ¶100(6); Annexure E (k)	The kill-switch procedure, and a documented fallback for each critical process, each with the date it was last tested.
R3Check	Staff trainedEveryone who uses or oversees AI, from staff to the Board, is trained when they start, at least once a year, and when tools change materially, and is tested afterwards. Training covers safe use, the tools' limits, how to check output, and when not to rely on it: an approved tool can still be wrong.Evidence: Training material, and completion and test records by role, including the Board.NIST AI RMF: GV 2.2, MAP 3.4 · BoG CISD 2026: ¶59(1), ¶61	Training material, and completion and test records by role, including the Board.
R4	Errors and changes monitoredAI output is monitored for errors and drift against set thresholds, and breaches are handled as incidents. Changes to an AI service, such as a new model or new terms, are assessed before critical work relies on them.Evidence: An error log, monitoring results against thresholds, and change-review records.NIST AI RMF: MS 2.4, MG 4.1 · NIST AI 600-1: MG-4.3-002 · Act 843: s.26 · BoG CISD 2026: ¶97(2), ¶100(6); Annexure E (g), (j)	An error log, monitoring results against thresholds, and change-review records.

How the catalogue was built

The catalogue brings together what SAFER's working instruments already require: the evidence scale, the AI Use Case Intake and AI Incident Report forms, the acceptable use statement, the quarterly review, and the AI Readiness Check. Every control was then checked against seven studies on trust in AI and AI governance, read in full, and against the regulatory texts below. No study contradicted a control's purpose, but the evidence changed the wording of fourteen: review is proportionate to risk, new uses are tested before launch, agents act only within enforced permissions, and incidents follow the notification deadlines the law sets.

The research supports the Accountable, Ethical, and Resilient controls most strongly. It says little about staff use of generative AI, so S1 and S4 rest on regulation and practice alone. References are listed against a control only where the source text was read and confirmed. They map SAFER to its sources; they are not legal advice.

Regulatory texts

NIST AI RMF: NIST AI 100-1, Artificial Intelligence Risk Management Framework 1.0 (January 2023). GV Govern, MS Measure, MG Manage. Source
NIST AI 600-1: NIST AI 600-1, Generative Artificial Intelligence Profile (July 2024). Source
Act 843: Data Protection Act, 2012 (Act 843), Ghana. Source
BoG CISD 2026: Bank of Ghana, Cyber and Information Security Directive (March 2026), including Annexure E, AI/ML Governance and Control Guidelines. Source
BoG Outsourcing Directive 2024: Bank of Ghana, Outsourcing Directive (November 2024). Source
Act 1038: Cybersecurity Act, 2020 (Act 1038), Ghana. Source

Research

Study	Type	Controls it supports
Afroogh, S., Akbari, A., Malone, E., Kargar, M., & Alambeigi, H. (2024). Trust in AI: progress, challenges, and future directions. Humanities and Social Sciences Communications, 11, 1568. Source	Systematic review	E1, E2, E4, F4, R3, R4In part: S2, S3, A2, A3, A4, F1, F2, F3, E3, R1, R2
Regona, M., Yigitcanlar, T., Hon, C., & Teo, M. (2026). Building trust in artificial intelligence: A systematic review through the lens of trust theory. ACM Computing Surveys, 58(9), Article 220. Source	Systematic review	A2, E1, E2, E4, R2, R3, R4In part: S2, S3, A1, A3, A4, F2, F4, E3, R1
Dang, Q., & Li, G. (2026). Unveiling trust in AI: the interplay of antecedents, consequences, and cultural dynamics. AI & Society, 41, 669–692. Source	Systematic review	E4In part: A2, F4, E1, E2, E3, R3
Falowo, O. I., & Bou Abdo, J. (2026). Empirical study on automation, AI trust, and framework readiness in cybersecurity incident response. Algorithms, 19(1), 62. Source	Survey of practitioners	R1In part: S2, A2, E1, R3, R4
Chen, L. (2026). Beyond external constraints: The missing dimension of AI governance. Working paper, SSRN 6449738. Source	Working paper (not peer reviewed)	E2In part: S2, S3, F3, R4
Ragone, G., Buono, P., Good, J., & Lanzilotti, R. (2026). Do children trust AI, and should they? Designing and validating a child-centred K-AI trust scale for intelligent systems. Proceedings of CHI 2026. Source	Scale validation study	In part: F4, E1, E3, E4
Choung, H., David, P., & Ross, A. (2022). Trust in AI and its role in the acceptance of AI technologies. International Journal of Human–Computer Interaction. Source	Two surveys	In part: E3, E4

Using SAFER

Free · 5 minutes
Check your institution
The AI Readiness Check: fifteen questions, three per pillar, scored on this scale. Indicative, not a full assessment.
Take the check
Run it yourself
The SAFER Governance Toolkit
The scoring workbook, policy templates, and the intake and incident forms that put the framework to work.
See the toolkit
Facilitated
A SAFER assessment
Scored with your team on evidence, mapped to Act 843 and your cyber security obligations, with a baseline your Risk Committee can track.
How the review works

Licence and citation

The text of SAFER on this page is published under the Creative Commons Attribution-NoDerivatives 4.0 licence (CC BY-ND 4.0). You may copy and share it, including in commercial work, as long as you credit it and do not distribute modified versions. Using SAFER inside your institution, scoring against it, and writing your own policies that refer to it need no permission.

SAFER is a name, not just a text. Please do not describe a product or service as SAFER-certified, or as a SAFER assessment, without written permission.

Cite as

Amponsah, R. K. (2026). SAFER: A framework for governing AI in regulated financial institutions (Version 1.0). https://raphaelamponsah.com/safer

Independence

SAFER's editor also sells SAFER X REDACT, software that helps an institution meet the Filtered pillar, and carries out SAFER assessments as a consultant. You should know that before you rely on the framework.

To keep the framework neutral, three rules apply to every version:

Controls state outcomes and evidence. None names or requires a product.
Any tool or procedure that produces the evidence meets the control.
Changes are published here, with a change log, and open for comment before they take effect.

Change log and comments

Version	Date	Change
1.0	1 October 2026	First open publication: the five pillars, the evidence scale, the scoring rules, the posture bands, and the twenty controls, each checked against seven studies and mapped to the NIST AI RMF, Act 843, and the Bank of Ghana Cyber and Information Security Directive (2026).

Comments on version 1.0 are open, from practitioners, auditors, regulators, and researchers. Write to hello@raphaelamponsah.com with “SAFER 1.0” in the subject.