Free reference 40 KRIs

What are good key risk indicator (KRI) examples for fintechs and banks?

Name: Key risk indicator (KRI) examples
Creator: RiskTemplates
License: https://creativecommons.org/licenses/by/4.0/

Short answer

Here are 40 key risk indicators (KRIs) for US fintechs and banks, across 10 risk areas (operational; technology and business continuity; cybersecurity; third-party; BSA/AML; compliance; consumer complaints; liquidity and funding; model and AI; fraud and payments). Each has a definition, a formula, a data source, a reporting frequency and an example Green/Amber/Red threshold. The thresholds are illustrative starting points to calibrate against your own data, not regulatory requirements.

20 of the 40 carry a regulatory hook: the US rule or guidance that asks for that metric or area, such as the SAR deadline in 31 CFR 1020.320(b)(3) or the FTC Safeguards Rule's access-control and testing requirements. No US rule prescribes a list of KRIs; the OCC's Heightened Standards come closest by requiring quantitative risk appetite limits at large banks.

Last verified: October 14, 2026

Download CSV JSON

How to use this Sources

40 KRIs by risk area

Jump to any KRI in the table. Area names group the examples for this page; each row also shows the category it carries in the full library.

Operational (3)

Transaction Error Rate
Regulatory Report Filing Timeliness
Regulatory & Bank Partner Findings Past Due

Technology and business continuity (4)

System Uptime / Availability
Mean Time to Recovery (MTTR)
BCP Test Completion Rate
DR Test Completion Rate

Cybersecurity (5)

Phishing Click-Through Rate
PII Records Exposed
Privileged Access Review Completion
Terminated Employee Access Deprovisioning SLA
Critical Vulnerability Patch Time

Third-party (4)

Critical Vendor Due Diligence Currency Rate
Vendor SLA Breach Rate
Vendor SOC 2 Report Currency Rate
Critical Vendor Exit Plan Coverage

BSA/AML (6)

CDD/EDD Completion Rate
OFAC Screening Coverage Rate
SAR Filing Timeliness Rate
Alert Aging Rate
KYC Refresh Completion Rate
Alert-to-SAR Conversion Rate

Compliance (3)

MTL License Coverage Rate
Privacy Rights Request Response Rate
Reg E Error Resolution Timeliness

Consumer complaints (3)

Customer Complaint Rate
Complaint Resolution Time (Average)
UDAAP-Related Complaint Share

Liquidity and funding (3)

Settlement Funding Buffer
Runway (Months of Cash)
Days of Operating Expenses (DOE)

Model and AI (5)

Model Inventory Validation Coverage
Models Past Revalidation Date
AI Use Case Assessment Currency
Human Override Rate on AI Decisions
Shadow AI Discoveries

Fraud and payments (4)

Account Takeover (ATO) Rate
ACH Return Rate — Unauthorized
Card Dispute and Fraud Ratio (Visa VAMP basis)
Instant Payment Fraud Loss Rate

All 40 KRIs with formulas and example thresholds

Example thresholds are illustrative. Green, Amber and Red values show a reasonable starting point; calibrate each one to your own data, contracts and risk appetite. They are not regulatory requirements, even where a regulatory hook is listed. Rows marked "Starter threshold" have no reliable benchmark yet.

Key risk indicator examples, 40 KRIs, with illustrative thresholds, last verified October 14, 2026
KRI	Definition and formula	Example thresholds (illustrative)	Frequency	Data source	Why these thresholds	US rule or guidance	Last verified
Transaction Error Rate KRI-OR-001-1 Operational · library category: Operational Risk Tier: Operational	Percentage of transactions that fail, are reversed, or are manually corrected due to processing errors Formula: Error/reversal transactions / Total transactions × 100 Unit: % · Lower is better	Green: <0.1% Amber: 0.1%–0.5% Red: >0.5%	Daily	Where the data comes from Payment processor logs: Stripe Dashboard > Payments > filter status=failed. Internal transaction database. Reconciliation system break log. Operations ticketing system for manual corrections.	Threshold rationale Error-free processing is the baseline expectation. <0.1% is a commonly cited target for straight-through processing — validate against your own data; >0.5% signals systematic processing issues requiring root cause analysis.	No specific US rule; internal or sponsor-bank metric	2026-10-14
Regulatory Report Filing Timeliness KRI-OR-008-1 Operational · library category: Operational Risk Tier: Management	Percentage of mandatory regulatory reports filed by required deadline Formula: Reports filed on time / Total reports due in period × 100 Unit: % · Higher is better	Green: 100% Amber: 95%–<100% Red: <95%	Monthly	Where the data comes from Regulatory reporting calendar (internal or from GRC tool). Include: OFAC/BSA/SAR deadlines, state license renewals, FinCEN reports, bank partner reporting deadlines, NMLS filings.	Threshold rationale Late regulatory filings are a commonly cited exam finding, and repeat tardiness can lead to civil money penalties; 100% on time is the only acceptable target.	No specific US rule; internal or sponsor-bank metric	2026-10-14
Regulatory & Bank Partner Findings Past Due KRI-OR-010-2 Operational · library category: Operational Risk Tier: Board	Open findings from regulators, sponsor banks, card networks or auditors that are past the remediation date you committed to. Formula: Count of open external findings past committed remediation date Unit: count · Zero tolerance	Green: 0 Amber: 1 Red: ≥2	Monthly	Where the data comes from Issues tracker (e.g., the exam and regulatory findings log in the Issues Management Tracker)	Threshold rationale A missed commitment to a regulator or sponsor bank is treated as a governance failure, not just a late task. It is one of the fastest ways for a finding to escalate.	No specific US rule; internal or sponsor-bank metric	2026-10-14
System Uptime / Availability KRI-TR-001-1 Technology and business continuity · library category: Technology Risk Tier: Board	Percentage of time core payment and account systems are available to customers (excluding planned maintenance) Formula: (Total minutes in period - Unplanned downtime minutes) / Total minutes in period × 100 Unit: % · Higher is better	Green: ≥99.9% Amber: 99.5%–<99.9% Red: <99.5%	Monthly	Where the data comes from AWS CloudWatch or Datadog or PagerDuty — uptime monitoring. For customer-facing: StatusPage.io historical data. For payment processing: processor SLA reports (Stripe Dashboard > Developers > Webhooks).	Threshold rationale 99.9% ≈ 44 minutes of downtime a month; below 99.5% (≈3.6 hours a month) draws bank-partner scrutiny and customer churn. 99.9% is a common SLA level in bank-partner and SaaS agreements — use the level in your own contracts.	No specific US rule; internal or sponsor-bank metric	2026-10-14
Mean Time to Recovery (MTTR) KRI-TR-001-2 Technology and business continuity · library category: Technology Risk Tier: Management	Average time from incident detection to full service restoration for P1/P2 incidents Formula: Sum of recovery times for P1/P2 incidents / Count of P1/P2 incidents Unit: hours · Lower is better	Green: <2 hours Amber: 2–4 hours Red: >4 hours	Monthly	Where the data comes from PagerDuty, OpsGenie, or Jira Service Management — incident start time vs. all-clear time. Tag severity (P1/P2) consistently.	Threshold rationale 2 hours for P1/P2 recovery is a commonly cited target — validate against your own incident history and contract commitments. Longer recovery times signal gaps in runbooks, on-call processes, or architecture resilience.	No specific US rule; internal or sponsor-bank metric	2026-10-14
BCP Test Completion Rate KRI-OR-004-1 Technology and business continuity · library category: Operational Risk Tier: Management	Percentage of business continuity plan tests completed as scheduled in the year Formula: BCP tests completed / BCP tests planned × 100 Unit: % · Higher is better	Green: 100% Amber: 80%–<100% Red: <80%	Quarterly	Where the data comes from BCP documentation + test calendar. GRC tool (Vanta, Drata, Tugboat Logic) if implemented. Internal compliance project management (Jira, Asana).	Threshold rationale The FFIEC Business Continuity Management booklet says an entity's risk profile should drive how often it exercises and tests its plans; it does not set a fixed minimum. Many bank partner agreements require at least annual testing, and an untested plan gives no evidence that recovery will work.	Examiners assess whether the exercise and testing program lets management confirm it can restore critical business functions; the entity's risk profile should drive how often it tests. FFIEC IT Handbook, Business Continuity Management booklet, section VII.A	2026-10-14
DR Test Completion Rate KRI-TR-012-1 Technology and business continuity · library category: Technology Risk Tier: Management	Percentage of disaster recovery and business continuity tests completed on schedule Formula: DR tests completed on schedule / DR tests planned in period × 100 Unit: % · Higher is better	Green: 100% Amber: 80%–<100% Red: <80%	Quarterly	Where the data comes from DR test schedule + test results documentation. BCP plan document. If using AWS: Elastic Disaster Recovery test failover results. Manual tracking in GRC tool (Vanta, Drata, Tugboat).	Threshold rationale The FFIEC Business Continuity Management booklet expects documented, tested recovery plans; bank partners often require annual testing contractually. An untested plan cannot be relied on.	Examiners assess whether the exercise and testing program lets management confirm it can restore critical business functions; the entity's risk profile should drive how often it tests. FFIEC IT Handbook, Business Continuity Management booklet, section VII.A	2026-10-14
Phishing Click-Through Rate KRI-CY-003-1 Cybersecurity · library category: Cyber Risk Tier: Management	Percentage of employees who click phishing links in simulated phishing tests Formula: Employees who clicked simulated phishing link / Employees who received test × 100 Unit: % · Lower is better	Green: <5% Amber: 5%–15% Red: >15%	Quarterly	Where the data comes from Phishing simulation platform: KnowBe4, Proofpoint Security Awareness, Cofense. All three provide click rate reporting by department and campaign.	Threshold rationale Simulation vendors publish average click rates for their customer base — compare against your own vendor's data; <5% represents strong awareness; >15% indicates training program failure. Examiners and auditors review phishing results as evidence of awareness-training effectiveness.	Non-bank financial institutions under the FTC must give personnel security awareness training updated for the risks in their risk assessment. 16 CFR 314.4(e)(1) (FTC Safeguards Rule)	2026-10-14
PII Records Exposed KRI-CY-001-2 Cybersecurity · library category: Cyber Risk Tier: Management	Total number of customer PII records exposed in confirmed breach incidents in trailing 12 months Formula: Sum of PII records exposed across all confirmed breach incidents in the trailing 12 months Unit: count · Zero tolerance	Green: 0 Amber: 1–999 Red: >999	Monthly	Where the data comes from Incident investigation findings — forensic analysis of scope. Legal and compliance incident documentation. SIEM and DLP tool logs.	Threshold rationale State breach laws differ on when regulators or consumer reporting agencies must also be notified (commonly at 500 or 1,000 affected residents). Larger incidents widen notification duties and scrutiny from regulators and bank partners.	A notification event involving the information of at least 500 consumers must be reported to the FTC no later than 30 days after discovery. 16 CFR 314.4(j)(1) (FTC Safeguards Rule)	2026-10-14
Privileged Access Review Completion KRI-PR-007-1 Cybersecurity · library category: People Risk Tier: Management	Percentage of privileged access accounts (admin, root, service accounts) reviewed in quarterly access review Formula: Privileged accounts reviewed and certified / Total privileged accounts × 100 Unit: % · Higher is better	Green: 100% Amber: 95%–<100% Red: <95%	Quarterly	Where the data comes from Identity management system (Okta, AWS IAM, Azure AD) — pull list of privileged accounts. Access review tools: Vanta, Drata, SecureApp. Or manual spreadsheet certification.	Threshold rationale SOC 2 criteria and bank-partner security standards expect periodic access reviews; 100% coverage is expected for privileged accounts, and any uncertified access is a finding.	Requires implementing and periodically reviewing access controls so only authorized users reach customer information. 16 CFR 314.4(c)(1) (FTC Safeguards Rule)	2026-10-14
Terminated Employee Access Deprovisioning SLA KRI-PR-007-2 Cybersecurity · library category: People Risk Tier: Management	Percentage of terminated employees with access revoked within 24 hours of termination Formula: Terminated employees with access revoked within 24h / Total terminations × 100 Unit: % · Higher is better	Green: 100% Amber: 95%–<100% Red: <95%	Monthly	Where the data comes from Okta (or Azure AD/Google Workspace) — suspension timestamp vs. HR termination date. Cross-reference HR system termination date with IdP account status change.	Threshold rationale Same-day deprovisioning is a security baseline; any delay creates an insider-threat window. The FTC Safeguards Rule requires access controls that permit access only to authorized users (16 CFR 314.4(c)(1)), and auditors and bank partners test deprovisioning against your documented SLA.	Requires access controls that authenticate and permit access only to authorized users. 16 CFR 314.4(c)(1) (FTC Safeguards Rule)	2026-10-14
Critical Vulnerability Patch Time KRI-TR-010-1 Cybersecurity · library category: Technology Risk Tier: Management	Average days from disclosure of a critical-severity CVE to patch deployment in production Formula: Sum of days from CVE disclosure to patch deploy for critical CVEs / Count of critical CVEs patched in period Unit: days · Lower is better	Green: <7 days Amber: 7–30 days Red: >30 days	Monthly	Where the data comes from Vulnerability scanner: Wiz, Snyk, Qualys, Tenable. GitHub Dependabot security alerts. CVE dates from NVD (nvd.nist.gov). Cross-reference with deployment logs.	Threshold rationale CISA's Binding Operational Directive 26-04 (June 10, 2026), which binds federal civilian agencies and replaced BOD 19-02's flat 15-day deadline for critical vulnerabilities, sets risk-based remediation timelines as short as 3 days for exposed, known-exploited vulnerabilities — a useful benchmark. The FTC Safeguards Rule requires continuous monitoring or vulnerability assessments at least every six months (16 CFR 314.4(d)(2)); >30 days creates an unacceptable exposure window.	Requires continuous monitoring, or annual penetration testing plus vulnerability assessments at least every six months. 16 CFR 314.4(d)(2) (FTC Safeguards Rule)	2026-10-14
Critical Vendor Due Diligence Currency Rate KRI-TP-006-5 Third-party · library category: Vendor/Third-Party Risk Tier: Management	Percentage of critical/tier-1 vendors with due diligence assessments completed within the past 12 months Formula: Count of critical vendors with current (≤12M) due diligence / Total critical vendors × 100 Unit: % · Higher is better	Green: ≥90% Amber: 75%–<90% Red: <75%	Quarterly	Where the data comes from Vendor management system (Venminder, OneTrust, Prevalent, or GRC platform) — due diligence tracking module	Threshold rationale The 2023 interagency third-party guidance describes due diligence before selection and ongoing monitoring scaled to the risk and criticality of each relationship. A 12-month refresh for critical vendors is a common internal standard, not a regulatory deadline. ≥90% reflects good practice.	Describes due diligence before selecting a third party and ongoing monitoring scaled to the risk and criticality of the relationship. Interagency Guidance on Third-Party Relationships, 88 FR 37920 (June 9, 2023), sections C.2 and C.4	2026-10-14
Vendor SLA Breach Rate KRI-TP-005-2 Third-party · library category: Vendor/Third-Party Risk Tier: Management	Percentage of defined SLA metrics that vendors failed to meet in the reporting period Formula: Count of SLA metrics breached / Total SLA metrics tracked × 100 Unit: % · Lower is better	Green: <5% Amber: 5%–10% Red: >10%	Monthly	Where the data comes from Vendor contracts (SLA schedules); vendor-provided performance reports; internal monitoring dashboards (uptime, error rate, processing time)	Threshold rationale SLA breaches signal operational degradation; >10% breach rate across critical vendor SLAs creates material operational risk and potential regulatory exposure for service disruptions.	Describes service-level agreements and performance measures used to monitor a third party and address poor performance. Interagency Guidance on Third-Party Relationships, 88 FR 37920 (June 9, 2023), section C.3.b	2026-10-14
Vendor SOC 2 Report Currency Rate KRI-TP-006-1 Third-party · library category: Vendor/Third-Party Risk Tier: Management	Percentage of critical/high-risk vendors with current SOC 2 Type II (or equivalent) reports on file (issued within past 12 months) Formula: Count of critical vendors with SOC 2 Type II report ≤12M old / Total critical vendors × 100 Unit: % · Higher is better	Green: ≥85% Amber: 70%–<85% Red: <70%	Quarterly	Where the data comes from Vendor management system — SOC 2 report repository; direct vendor requests; AICPA SOC 2 reports from vendors	Threshold rationale SOC 2 Type II provides independent assurance over vendor controls. The 2023 interagency third-party guidance says a banking organization may consider reviewing SOC reports in due diligence, and bank partners commonly ask fintechs for current ones; gaps indicate unverified control environments for critical service providers.	Says a banking organization may consider reviewing System and Organization Control (SOC) reports as part of due diligence. Interagency Guidance on Third-Party Relationships, 88 FR 37920 (June 9, 2023), section C.2	2026-10-14
Critical Vendor Exit Plan Coverage KRI-TP-012-1 Third-party · library category: Vendor/Third-Party Risk Tier: Management	Percentage of critical/tier-1 vendors for which a documented exit plan (vendor transition plan) exists and has been tested or reviewed in the past 12 months Formula: Count of critical vendors with current documented exit plans / Total critical vendors × 100 Unit: % · Higher is better	Green: ≥80% Amber: 60%–<80% Red: <60%	Annual	Where the data comes from Vendor management system — exit plan repository; business continuity documentation; legal team (contract termination provisions)	Threshold rationale The 2023 interagency third-party guidance describes contingency plans for transitioning an activity to another third party or bringing it in-house, and treats termination as a stage of every relationship. Without a plan, a critical vendor failure leaves no tested way out.	Describes contingency plans for moving an activity to another third party or in-house, and termination as a stage of the relationship. Interagency Guidance on Third-Party Relationships, 88 FR 37920 (June 9, 2023), sections C.1 and C.5	2026-10-14
CDD/EDD Completion Rate KRI-AML-002-1 BSA/AML · library category: BSA/AML Risk Tier: Management	Percentage of Customer Due Diligence (CDD) and Enhanced Due Diligence (EDD) reviews required in the period that were completed on time Formula: CDD/EDD reviews completed on schedule / Total CDD/EDD reviews due × 100 Unit: % · Higher is better	Green: ≥95% Amber: 85%–<95% Red: <85%	Monthly	Where the data comes from CRM or AML platform (Actimize, NICE, Verafin, Fiserv) — CDD/EDD workflow module; manual tracking spreadsheet if no platform	Threshold rationale CDD/EDD completion is a core BSA/AML expectation. FinCEN's CDD Rule requires risk-based procedures for ongoing customer due diligence, including maintaining and updating customer information on a risk basis. (FinCEN's 2018 CDD FAQs add that a routine periodic review is not by itself a trigger to update beneficial ownership information.) Reviews you schedule under your own policy are exam evidence, so missed reviews are a common finding.	Banks must have risk-based procedures for ongoing customer due diligence, including maintaining and updating customer information on a risk basis. 31 CFR 1020.210(a)(2)(v)	2026-10-14
OFAC Screening Coverage Rate KRI-AML-003-1 BSA/AML · library category: BSA/AML Risk Tier: Board	Percentage of transactions and customer onboarding events screened against OFAC SDN and consolidated sanctions lists Formula: Screened transactions and onboarding events / Total transactions and onboarding events × 100 Unit: % · Higher is better	Green: 100% Amber: 99%–<100% Red: <99%	Monthly	Where the data comes from OFAC screening system (Refinitiv World-Check, LexisNexis, Accuity, ComplyAdvantage); transaction processing logs; onboarding platform screening logs	Threshold rationale OFAC's 2019 Framework for OFAC Compliance Commitments lists sanctions screening software or filter faults (for example, not updating to the latest SDN List) among the root causes of apparent violations. A screening gap is not itself a violation, but a prohibited transaction that passes through one can be, so treat this KRI as zero tolerance.	Lists sanctions screening software or filter faults among the root causes of apparent sanctions violations. OFAC, A Framework for OFAC Compliance Commitments (2019), section VI	2026-10-14
SAR Filing Timeliness Rate KRI-AML-004-1 BSA/AML · library category: BSA/AML Risk Tier: Board	Percentage of Suspicious Activity Reports (SARs) filed with FinCEN within the 30-calendar-day regulatory deadline (60 days if no suspect identified) Formula: SARs filed within deadline / Total SARs filed in period × 100 Unit: % · Higher is better	Green: ≥98% Amber: 95%–<98% Red: <95%	Monthly	Where the data comes from FinCEN BSA E-Filing system; SAR case management system (Actimize, Verafin, internal tracker); SAR records (a copy of each SAR and its supporting documentation must be kept for 5 years under 31 CFR 1020.320(d))	Threshold rationale FinCEN requires SARs within 30 calendar days of initial detection of facts that may constitute a basis for filing (60 days if no suspect is identified). Late filings are a direct violation and a leading indicator in BSA enforcement actions.	A bank must file a SAR no later than 30 calendar days after initial detection of facts that may be a basis for filing (up to 60 days if no suspect is identified). 31 CFR 1020.320(b)(3)	2026-10-14
Alert Aging Rate KRI-AML-007-1 BSA/AML · library category: BSA/AML Risk Tier: Management	Percentage of open transaction monitoring alerts that are more than 30 days old without disposition Formula: Open alerts aged >30 days / Total open alerts × 100 Unit: % · Lower is better	Green: <5% Amber: 5%–15% Red: >15%	Monthly	Where the data comes from Transaction monitoring/case management system; AML platform alert queue with creation date timestamps	Threshold rationale Alert backlogs directly impact SAR filing timeliness and signal resource constraints. SARs are due 30 calendar days after initial detection, so an aged alert queue is a common sign of an under-resourced BSA program.	Alert backlogs feed the SAR clock: a bank must file no later than 30 calendar days after initial detection. 31 CFR 1020.320(b)(3)	2026-10-14
KYC Refresh Completion Rate KRI-AML-009-1 BSA/AML · library category: BSA/AML Risk Tier: Management	Percentage of customers requiring periodic KYC review (per risk-tiered schedule) who had their review completed on time in the period Formula: KYC reviews completed on time / KYC reviews due in period × 100 Unit: % · Higher is better	Green: ≥95% Amber: 85%–<95% Red: <85%	Monthly	Where the data comes from CRM or KYC platform; AML case management system; customer onboarding platform with KYC review scheduling (risk tier determines refresh frequency: High = annual, Medium = 2-year, Low = 3-year)	Threshold rationale Stale KYC creates undisclosed risk in the customer portfolio. FinCEN's CDD Rule expects customer information to be maintained and updated on a risk basis; FinCEN's 2018 CDD FAQs clarify only that a routine periodic review is not by itself a trigger to update beneficial ownership information. Once your policy sets refresh cycles by risk tier, examiners and bank partners test you against them. ≥95% on-time completion is a common internal target; backlog is a material BSA finding.	Banks must have risk-based procedures for ongoing customer due diligence, including maintaining and updating customer information on a risk basis. 31 CFR 1020.210(a)(2)(v)	2026-10-14
Alert-to-SAR Conversion Rate KRI-AML-006-1 BSA/AML · library category: BSA/AML Risk Tier: Management	Percentage of transaction monitoring alerts that ultimately result in a SAR filing, indicating alert quality and investigative effectiveness Formula: SARs filed in period / Total alerts closed (investigation complete) in period × 100 Unit: % · Target range	Green: 2%–8% Amber: 1%–<2% or >8%–15% Red: <1% or >15%	Monthly	Where the data comes from Transaction monitoring system (Actimize, Verafin, NICE, Fiserv); case management system; SAR filing records in FinCEN E-Filing	Threshold rationale Alert-to-SAR conversion is a common tuning signal: <1% suggests over-alerting or weak investigations; >15% suggests under-alerting. 2%–8% is a commonly cited range — validate against your own scenarios.	No specific US rule; internal or sponsor-bank metric	2026-10-14
MTL License Coverage Rate KRI-PM-001-1 Compliance · library category: Payments Risk Tier: Board	Percentage of states where the company has money transmission activity that are covered by an active money transmitter license Formula: States with active MTL where transmission occurs / States where money transmission activity occurs × 100 Unit: % · Higher is better	Green: 100% Amber: 90%–<100% Red: <90%	Quarterly	Where the data comes from License management system (NMLS, Thomson Reuters GEMS, Wolters Kluwer ComplianceCentral) + transaction data showing active states. State licensing counsel review.	Threshold rationale Unlicensed money transmission can violate state law and federal law (18 U.S.C. § 1960). 100% coverage is required; any gap creates enforcement risk, and state penalties can accrue daily.	Makes it a federal crime to knowingly operate an unlicensed money transmitting business, including one run without a state license where the state makes that a misdemeanor or felony. 18 U.S.C. 1960	2026-10-14
Privacy Rights Request Response Rate KRI-CO-005-1 Compliance · library category: Compliance Risk Tier: Management	Percentage of consumer data requests responded to within regulatory deadline Formula: Requests completed on time / Total requests × 100 Unit: % · Higher is better	Green: ≥98% Amber: 90%–<98% Red: <90%	Monthly	Where the data comes from Privacy request management system (OneTrust, TrustArc) or manual tracker	Threshold rationale CCPA requires responses to consumer rights requests within 45 days (extendable once by 45 days with notice). Late responses trigger enforcement risk and consumer complaints.	No specific US rule; internal or sponsor-bank metric	2026-10-14
Reg E Error Resolution Timeliness KRI-NB-002-1 Compliance · library category: Neobank/BaaS Risk Tier: Management	Percentage of Reg E electronic fund transfer error resolutions completed within required timeframes Formula: Reg E disputes resolved within statutory timeframe / Total Reg E disputes in period × 100 Unit: % · Higher is better	Green: 100% Amber: 95%–<100% Red: <95%	Monthly	Where the data comes from Customer dispute management system (Zendesk, Salesforce Service Cloud, dedicated Reg E tracking tool) — dispute receipt date, provisional credit date, final resolution date. Bank partner dispute tracking.	Threshold rationale Reg E requires provisional credit (or a determination) within 10 business days and final resolution within 45 calendar days (90 in some cases). EFTA allows actual damages plus statutory damages of $100–$1,000 per individual action, with class-action exposure; Reg E error resolution is a frequent exam focus.	Sets the 10-business-day investigation period, provisional credit to extend it to 45 days, and the 20-business-day and 90-day extensions. 12 CFR 1005.11(c) (Regulation E)	2026-10-14
Customer Complaint Rate KRI-OR-003-1 Consumer complaints · library category: Operational Risk Tier: Board	Number of formal customer complaints per 1,000 active customers in the period Formula: Formal complaints received / Active customers × 1,000 Unit: per 1K · Lower is better	Green: <2 Amber: 2–5 Red: >5	Monthly	Where the data comes from Support ticketing system (Zendesk, Intercom, Freshdesk) — formal complaints tagged separately from general support. CFPB complaint portal (if you have a consumer-facing product). Better Business Bureau complaints.	Threshold rationale Complaint trends are reviewed by regulators and sponsor banks, and the CFPB's public complaint database makes spikes visible; >5 per 1K active customers is a red flag; complaint spikes often precede regulatory inquiries; monitoring enables proactive issue resolution	No specific US rule; internal or sponsor-bank metric	2026-10-14
Complaint Resolution Time (Average) KRI-OR-003-2 Consumer complaints · library category: Operational Risk Tier: Management	Average number of days from complaint receipt to final resolution Formula: Sum of days from complaint receipt to resolution / Total complaints resolved in period Unit: days · Lower is better	Green: <10 days Amber: 10–30 days Red: >30 days	Monthly	Where the data comes from Support ticketing system (Zendesk) — complaint open date vs. resolution date. Reg E error resolution tracking if EFT product. CFPB complaint portal response tracking.	Threshold rationale Reg E requires provisional credit or a determination within 10 business days and final resolution within 45 calendar days (90 in some cases). Faster resolution reduces regulatory risk and improves customer experience; >30 days risks missing Reg E deadlines.	No specific US rule; internal or sponsor-bank metric	2026-10-14
UDAAP-Related Complaint Share KRI-CO-003-1 Consumer complaints · library category: Compliance Risk Tier: Management	Percentage of complaints alleging misleading, unfair or undisclosed terms, fees or practices. Formula: Complaints tagged as alleging misleading/unfair/undisclosed terms or fees / Total complaints × 100 Unit: % · Lower is better	Green: <5% Amber: 5%–10% Red: >10% Starter threshold	Monthly	Where the data comes from Customer support platform (Zendesk, Intercom) + CFPB complaint database	Threshold rationale Complaint themes, not just volume, are what point to UDAAP risk; the CFPB's public complaint database makes patterns visible to regulators and sponsor banks. Starter threshold — no reliable industry benchmark exists yet; recalibrate after 3 months of your own data.	No specific US rule; internal or sponsor-bank metric	2026-10-14
Settlement Funding Buffer KRI-BP-003-1 Liquidity and funding · library category: Bank Partner Risk Tier: Operational	Available liquidity as a multiple of peak daily settlement obligations Formula: Available cash / Peak daily settlement obligation in trailing 30 days Unit: ratio · Higher is better	Green: ≥3x Amber: 2x–<3x Red: <2x	Daily	Where the data comes from Treasury/banking system: available cash balance from bank account(s). Settlement obligation: daily ACH/wire settlement amounts from payment processor or bank partner. Can pull from both.	Threshold rationale Settlement funding failure is existential — a missed settlement can trigger a bank partner's suspension or termination rights; 3x buffer provides adequate cushion for unexpected volume spikes; <2x is dangerously thin	No specific US rule; internal or sponsor-bank metric	2026-10-14
Runway (Months of Cash) KRI-SR-004-1 Liquidity and funding · library category: Strategic Risk Tier: Board	Number of months of operating expenses covered by current cash reserves Formula: Current cash balance / Monthly operating burn rate Unit: months · Higher is better	Green: ≥18 months Amber: 9–<18 months Red: <9 months	Monthly	Where the data comes from Bank account balances (bank statements or Plaid connection) + accounting system for burn rate. Monthly burn = Total operating expenses per P&L.	Threshold rationale 18 months is a commonly cited planning horizon for venture-backed fintechs; <12 months makes fundraising urgent; <9 months draws bank-partner concern (bank partners monitor the financial health of program managers).	No specific US rule; internal or sponsor-bank metric	2026-10-14
Days of Operating Expenses (DOE) KRI-FA-001-2 Liquidity and funding · library category: Financial/Accounting Risk Tier: Management	Number of days of current operating expenses covered by cash and cash equivalents Formula: Cash and cash equivalents / (Annual operating expenses / 365) Unit: days · Higher is better	Green: ≥180 days Amber: 90–<180 days Red: <90 days	Monthly	Where the data comes from Bank account balance(s) from bank statements or accounting system + monthly burn rate from P&L. Same data as runway calculation.	Threshold rationale 180 days (about 6 months) is a commonly used planning floor; <90 days creates operational risk and bank-partner concern. Startup-phase companies may operate lower but should disclose it to their board and bank partner.	No specific US rule; internal or sponsor-bank metric	2026-10-14
Model Inventory Validation Coverage KRI-MR-004-1 Model and AI · library category: Model Risk Tier: Management	Percentage of models in production that have been independently validated within required cycle Formula: Models with current independent validation / Total models in production × 100 Unit: % · Higher is better	Green: 100% Amber: 80%–<100% Red: <80%	Quarterly	Where the data comes from Model inventory register (spreadsheet or GRC tool) with: model name, deployment date, last validation date, next due date, validator, status. Typically maintained by Model Risk Management or Compliance.	Threshold rationale OCC Bulletin 2026-13 / SR 26-2 (which replaced SR 11-7) says validation generally occurs before a model's first use, with timing and frequency that vary with the model's purpose, methodology, changes and materiality. It is aimed at banking organizations with more than $30 billion in assets, and sponsor banks often apply it to fintech partners' models. <80% means material models lack validation.	Revised interagency model risk guidance: validation generally occurs before first use, with timing and frequency that vary with the model. Aimed at banking organizations over $30 billion in assets; generative and agentic AI are out of scope. OCC Bulletin 2026-13 / Federal Reserve SR 26-2 (April 17, 2026)	2026-10-14
Models Past Revalidation Date KRI-MR-004-4 Model and AI · library category: Model Risk Tier: Management	Count of models in the model inventory that are overdue for their scheduled revalidation Formula: Count of models where Current Date > Scheduled Revalidation Date and revalidation not yet completed Unit: count · Zero tolerance	Green: 0 Amber: 1–2 Red: >2	Monthly	Where the data comes from Model inventory register with scheduled revalidation dates. Compare current date to revalidation due date for each model. Source: Model Risk Management tracking log.	Threshold rationale Any model past its revalidation date represents unreviewed model risk. Even 1-2 overdue models can signal resource or governance gaps. OCC Bulletin 2026-13 / SR 26-2 says validation generally occurs before first use; where a model must be used before validation is complete, it describes closer attention to the model's limitations and controls such as limits on its use. Document the interim controls for every overdue model.	Where a model is used before validation is complete, the guidance describes closer attention to its limitations and controls such as limits on use. OCC Bulletin 2026-13 / Federal Reserve SR 26-2 (April 17, 2026)	2026-10-14
AI Use Case Assessment Currency KRI-MR-004-2 Model and AI · library category: AI & Automation Risk Tier: Board	Percentage of AI use cases in the inventory (in-house, vendor and GenAI) with a current, approved risk assessment. Formula: AI use cases with a current risk assessment / Total AI use cases in inventory × 100 Unit: % · Higher is better	Green: ≥95% Amber: 85%–<95% Red: <85%	Quarterly	Where the data comes from AI use case inventory (e.g., AI Risk Assessment Template)	Threshold rationale Bank partners and examiners start AI reviews with the inventory and ask whether each use case was assessed. OCC Bulletin 2026-13 / SR 26-2 covers predictive models but leaves generative and agentic AI out of scope, so the NIST AI RMF 1.0 and AI 600-1 fill the gap. California's CCPA automated-decision rules add risk-assessment duties for certain uses from 2026–27.	No specific US rule; internal or sponsor-bank metric	2026-10-14
Human Override Rate on AI Decisions KRI-MR-004-3 Model and AI · library category: AI & Automation Risk Tier: Management	Percentage of AI recommendations (credit, fraud, KYC, collections) that human reviewers change. Formula: AI recommendations changed by a human reviewer / Total AI recommendations reviewed × 100 Unit: % · Target range	Green: 2%–15% Amber: 1%–<2% or >15%–25% Red: <1% or >25% Starter threshold	Monthly	Where the data comes from Decision engine logs with reviewer outcome	Threshold rationale Two-sided on purpose. Very low override rates suggest reviewers are rubber-stamping the model (automation bias); very high rates suggest the model is not fit for purpose. Human oversight is central to the NIST AI RMF and to model risk guidance. Starter threshold — no reliable industry benchmark exists yet; recalibrate after 3 months of your own data.	No specific US rule; internal or sponsor-bank metric	2026-10-14
Shadow AI Discoveries KRI-TP-006-2 Model and AI · library category: AI & Automation Risk Tier: Management	New unapproved AI tools or AI uses discovered in the quarter through network/CASB monitoring, expense reviews, surveys or amnesty programs. Formula: Count of new unapproved AI tools or uses discovered in the period Unit: count · Lower is better	Green: ≤2 Amber: 3–5 Red: >5 Starter threshold	Quarterly	Where the data comes from CASB / secure web gateway logs; expense reports; employee attestation	Threshold rationale Unapproved AI use is where customer data and confidential information leak. Discoveries should fall after an amnesty and a clear approved-tool list; a count of zero with no active discovery method is not evidence of control. Starter threshold — no reliable industry benchmark exists yet; recalibrate after 3 months of your own data.	No specific US rule; internal or sponsor-bank metric	2026-10-14
Account Takeover (ATO) Rate KRI-FR-001-1 Fraud and payments · library category: Fraud Risk Tier: Management	Number of confirmed account takeover incidents per 10,000 active accounts Formula: Confirmed ATO incidents / Active accounts × 10,000 Unit: per 10K · Lower is better	Green: <1 Amber: 1–5 Red: >5	Monthly	Where the data comes from Fraud detection platform (Sardine, Sift, Unit21) — confirmed ATO case count. Support ticket system (Zendesk, Intercom) — tickets tagged 'account-takeover' or 'unauthorized-access'. Active account count from database.	Threshold rationale No authoritative public benchmark exists for confirmed ATO cases per 10,000 accounts, so these are starter thresholds — validate against your own data. Red at >5 per 10K signals inadequate authentication controls or an active ATO campaign.	No specific US rule; internal or sponsor-bank metric	2026-10-14
ACH Return Rate — Unauthorized KRI-FR-008-1 Fraud and payments · library category: Fraud Risk Tier: Management	ACH return rate for unauthorized return codes (R05, R07, R10, R11, R29, R51) as a percentage of total ACH debits Formula: ACH debit returns with unauthorized codes (R05/R07/R10/R11/R29/R51) / Total ACH debit originations × 100 Unit: % · Lower is better	Green: <0.3% Amber: 0.3%–<0.5% Red: ≥0.5%	Monthly	Where the data comes from ACH processor / bank partner returns file. ODFI (bank partner) provides return files. Nacha unauthorized return codes: R05 (unauthorized debit to consumer account using corporate SEC code), R07 (authorization revoked by customer), R10 (customer advises not authorized), R11 (customer advises entry not in accordance with the terms of the authorization), R29 (corporate customer advises not authorized), R51 (item related to RCK entry is ineligible or RCK entry is improper).	Threshold rationale Nacha sets a 0.5% unauthorized debit return rate threshold (return codes R05, R07, R10, R11, R29 and R51); an Originator above it can face a Nacha inquiry and enforcement, and your ODFI will require a plan to bring it down. Red starts at that line; Amber (0.3%–<0.5%) is the warning buffer. Nacha also sets 3% administrative and 15% overall return rate levels.	No specific US rule; internal or sponsor-bank metric	2026-10-14
Card Dispute and Fraud Ratio (Visa VAMP basis) KRI-PM-004-1 Fraud and payments · library category: Payments Risk Tier: Management	Card fraud reports plus disputes as a percentage of settled card-not-present transactions — the ratio Visa's Acquirer Monitoring Program (VAMP) uses Formula: (Fraud reports (TC40) + Disputes (TC15)) / Settled card-not-present transactions × 100, monthly Unit: % · Lower is better	Green: <0.75% Amber: 0.75%–<1.5% Red: ≥1.5%	Monthly	Where the data comes from Payment processor chargeback reports: Stripe Dashboard > Radar > Disputes. Marqeta: Disputes report. Galileo: Chargeback summary. Bank partner dispute/chargeback summary. Nacha return rate for ACH.	Threshold rationale Per Visa's VAMP program, which replaced VDMP and VFMP in 2025, the US merchant "Excessive" threshold is 1.5% from April 1, 2026 (with at least 1,500 fraud reports plus disputes in the month). Red is set at that line; Amber gives a buffer. Mastercard runs a separate excessive-chargeback program — confirm its current thresholds with your acquirer.	No specific US rule; internal or sponsor-bank metric	2026-10-14
Instant Payment Fraud Loss Rate KRI-FR-003-6 Fraud and payments · library category: Fraud Risk Tier: Board	Fraud losses on real-time payments (RTP, FedNow, instant payouts) as basis points of instant-payment volume. Formula: Fraud losses on instant payments / Instant payment volume × 10,000 Unit: bps · Lower is better	Green: <2 bps Amber: 2–5 bps Red: >5 bps Starter threshold	Monthly	Where the data comes from Payments ledger by rail; fraud loss log	Threshold rationale Instant payments settle irrevocably, so losses cannot be recalled the way ACH or card payments sometimes can. Tracking them separately stops card and ACH performance from masking instant-payment exposure. Starter threshold — no reliable industry benchmark exists yet; recalibrate after 3 months of your own data.	No specific US rule; internal or sponsor-bank metric	2026-10-14

These 40 come from the KRI Library (152 Key Risk Indicators), which has all 152 KRIs across 23 categories plus owners, escalation triggers, implementation notes and a dashboard that calculates Green/Amber/Red status and breach streaks from your values.

More on using KRIs: KRI examples for operational and financial risk teams, leading vs lagging KRIs and tying KRIs to board-approved risk appetite.

◆ How to use this

Pick the metric, then calibrate the threshold.

Pick the risk areas that matter for your business model and start with 10 to 15 KRIs you can measure from data you already have.
Copy the formula exactly and write down how you count the numerator and denominator, so the number means the same thing every period.
Treat each threshold as a draft: replace it with your contract terms, your own history or a rule's bright line, and have it approved.
Use the regulatory hook to find the rule or guidance an examiner or sponsor bank will measure you against, and read the source itself.
Review thresholds at least annually and after a material event, a product launch or an exam finding.

Methodology

Rows are copied cell for cell from KRI Library workbook v2026.10.1 (October 14, 2026); 40 of its 152 KRIs are published here. Before publishing, each was audited: formula against definition, Red worse than Amber worse than Green, threshold labels against the workbook's threshold logic, US relevance, and stale or overstated regulatory references. 17 of the 40 needed corrections, which were made in the workbook itself. Each regulatory hook was checked against the linked primary source on October 14, 2026; rows without one are left blank rather than stretched to fit a rule.

Not legal advice

These are illustrative examples for risk and compliance teams, not legal advice or regulatory requirements. Calibrate every threshold to your own data, contracts and risk appetite. Rules change; confirm any regulatory point against the cited source and with counsel.

◆ FAQ

Common questions.

What is the difference between a KRI and a KPI?

A key performance indicator (KPI) measures progress toward a goal, such as onboarding volume or revenue. A key risk indicator (KRI) measures how close you are to a risk you have decided not to take, and it carries thresholds that trigger escalation before a loss or violation happens. The same number can be both: SAR filing timeliness is a performance metric for the BSA team and a risk indicator for the board. The FFIEC Business Continuity Management booklet lists the two side by side among the board reporting examiners review: "Metrics, including key risk indicators and key performance indicators for BCM and resilience."

How many KRIs should we have?

No US rule sets a number. A workable structure is 5 to 8 KRIs in the board pack, tied to your top risks; 10 to 15 for the executive or risk committee; and operational KRIs as the teams that own them need. The 40 examples here carry the library's suggested tier: 9 Board, 29 Management and 2 Operational. Start with KRIs you can measure from data you already have; a KRI without a reliable data source is a guess.

How do you set KRI thresholds?

Use the strongest anchor you have: a bright line set by a rule or card network (Nacha's 0.5% unauthorized ACH debit return rate, which sets the Red line for "ACH Return Rate — Unauthorized"; Visa's 1.5% VAMP ratio for "Card Dispute and Fraud Ratio (Visa VAMP basis)"), a contract term such as your bank partner's uptime service level, or your own history (with 12 months of data, for example, Amber beyond one standard deviation from the mean and Red beyond two). Set Red where the metric breaches your risk appetite and Amber early enough to act before that. Document why each threshold sits where it does, get it approved, and recalibrate at least annually. 4 of the 40 examples use starter thresholds because no reliable benchmark exists yet; recalibrate those after three months of your own data.

Do regulators require KRIs?

Not by that name for most firms, and no US rule lists which KRIs to use. The closest requirement is the OCC's Heightened Standards (12 CFR Part 30, Appendix D), which apply to OCC-supervised banks with $50 billion or more in average total consolidated assets: the risk appetite statement "should include both qualitative components and quantitative limits" that address earnings, capital and liquidity; independent risk management reports the risk profile against the risk appetite to the board or its risk committee at least quarterly; and the bank needs processes to identify limit breaches and escalate them by severity. Those monitored limits are KRIs in all but name. Examiners also look for metrics in specific areas: the FFIEC Business Continuity Management booklet lists key risk indicators among the board reporting it expects. Appendix D does not reach fintechs, but a sponsor bank can require KRI reporting in the program agreement, so check yours.

Are these thresholds benchmarks or regulatory limits?

Neither. Every Green/Amber/Red value here is an illustrative example from the KRI Library to calibrate against your own data, contracts and risk appetite. Where a threshold sits on a rule or network line, such as Nacha's or Visa's, the rationale says so. The regulatory hook column names the US rule or guidance that asks for the metric or the area (20 of 40 rows have one); it describes the source, not a threshold.

◆ Sources

Primary sources.

The rules and guidance behind the regulatory hooks and the answers above. Threshold rationales that cite Nacha or Visa rules point to those networks' published programs.

Data: CSV · JSON. Free to reuse under CC BY 4.0 with attribution to RiskTemplates and a link to this page. Last verified October 14, 2026.