◆ Quick answer
A KRI library template should include, for every indicator: KRI name and description, the linked risk it monitors, a calculation formula, unit of measure, reporting frequency, green/amber/red thresholds with a documented rationale, data source and collection method, KRI owner, and an escalation trigger for red breaches. Green means on target, amber means monitor closely, red means escalate immediately.
Guide vs. template
This guide explains what belongs in the template. The paid template gives you the editable working files so you're not rebuilding from a blank page.
Paid template includes
- ◆ 152 pre-built KRIs across 23 risk categories, each with 24 fields of metadata
- ◆ 20 emerging-risk KRIs (AI-enabled fraud, scams, instant payments, AI governance, AI agents), each with its source
- ◆ Board / Management / Operational tier on every KRI, plus Emerging Risk filter
- ◆ KRI Dashboard that calculates Green/Amber/Red status, trend and breach streaks from your values
What is this template for?
A Key Risk Indicator (KRI) library is the working file risk teams use to define each metric, its calculation formula, its green/amber/red thresholds, the data source it comes from, the owner accountable for it, and the escalation that fires when it breaches. The useful version is not a list of metric names — it makes each KRI operational: a formula anyone can reproduce, thresholds with a documented rationale, a named system to pull the data from (HR information system, incident management platform, cloud monitoring), and a specific action when the indicator turns red. Without thresholds, a KRI is just a number.
◆ Audience
Who needs this.
- ◆ You have a risk register but no way to monitor whether risk levels are actually changing month to month.
- ◆ Your bank partner or board is asking for risk metrics and you're manually assembling numbers before every meeting.
- ◆ A bank partner oversight review asked for Bank Secrecy Act / anti-money laundering (BSA/AML) metrics and you don't have defined indicators with thresholds.
- ◆ You're building a KRI program from scratch and would rather start from calibrated thresholds than guess.
- ◆ Your current dashboard is metric theater — lots of numbers, no thresholds, no escalation, no owners.
◆ Required fields
What every row needs.
The fields that make this template defensible to an auditor, bank partner, or examiner — and what goes in each.
| Field | Why it matters | Example |
|---|---|---|
| KRI name and description | A metric nobody can explain gets ignored. Each KRI needs a plain-English statement of what it measures. | Key Person Coverage Ratio — percentage of critical roles with at least one documented backup or successor |
| Linked risk ID | A KRI that doesn't map to a risk in your register is just a statistic. The link is what makes the dashboard answer "is this risk getting worse?" | KRI-PR-001-1 links to risk PR-001 (People Risk) in the risk register |
| Calculation formula and unit of measure | Two people should get the same number. Ambiguous math is how dashboards drift. | Voluntary terminations in trailing 12 months / average headcount × 100, reported as a percentage |
| Green/amber/red thresholds | Thresholds convert raw data into actionable intelligence. Green = on target, amber = monitor closely, red = escalate immediately. | System uptime: Green ≥99.9%, Amber 99.5%–<99.9%, Red <99.5% |
| Threshold rationale | When the board asks "why is 15% the line?", you need a documented basis — industry benchmark, regulatory bright line, statistical baseline, or contractual obligation. | Commonly cited ranges put voluntary turnover in the low-to-mid teens for tech companies — validate against your own history; above 25% signals systemic retention problems |
| Data source and collection method | A KRI without a named source system never gets reported twice. Name the platform and the export path. | HR system termination records; PagerDuty incident analytics; AWS CloudWatch availability metrics |
| KRI owner | The owner is accountable for reporting the number on cadence and acting when it breaches — distinct from the team that produces the data. | Chief People Officer owns turnover; VP Engineering owns uptime and change failure rate; CISO owns patch time |
| Escalation trigger | Red without a pre-agreed action is just a color. Define who gets notified, how fast, and what happens next. | Key person departure: notify CEO and board chair within 24 hours; begin succession activation immediately |
| Implementation difficulty and automation path | Teams stall trying to automate everything on day one. Grade each KRI easy/medium/hard and plan manual-first, automate-later. | Start: manual quarterly spreadsheet review. Phase 2: HR-system custom field and dashboard. Phase 3: automated reporting |
◆ Worked example
Sample KRIs with real green/amber/red thresholds
| Key Person Coverage Ratio | Critical roles with a documented backup / total critical roles × 100. Green ≥80% · Amber 60%–<80% · Red <60%. Quarterly, owned by the Chief People Officer. |
|---|---|
| Voluntary Turnover Rate | Voluntary terminations in trailing 12 months / average headcount × 100. Green <15% · Amber 15%–<25% · Red ≥25%. Red triggers root cause analysis within 30 days. |
| HR Policy Training Completion Rate | Employees who completed mandatory training / total required × 100. Green ≥95% · Amber 85%–<95% · Red <85%. Covers mandatory training including BSA/AML, which anti-money laundering programs must provide to appropriate personnel. |
| Terminated Employee Access Deprovisioning SLA | Terminations with access revoked within 24 hours / total terminations × 100. Green 100% · Amber 95%–<100% · Red <95%. Monthly, cross-checked between the HR system and identity provider. |
| System Uptime / Availability | (Total minutes − unplanned downtime) / total minutes × 100 for core payment and account systems. Green ≥99.9% · Amber 99.5%–<99.9% · Red <99.5%. 99.9% is a common SLA level — match it to your bank partner contract. |
| Mean Time to Recovery (MTTR) | Average time from detection to full restoration for P1/P2 incidents. Green <2 hours · Amber 2–4 hours · Red >4 hours. Red triggers post-mortem and runbook review. |
| Change Failure Rate | Deployments causing an incident or rolled back / total production deployments × 100. Green <5% · Amber 5%–15% · Red >15%. Change failure rate is one of the four DevOps Research and Assessment (DORA) metrics; treat the cut-offs as commonly cited ranges and validate them against your own deployments. |
| Data Reconciliation Break Rate | Reconciliation runs with unresolved breaks / total runs × 100. Green <1% · Amber 1%–3% · Red >3%. Daily; unexplained breaks over $1K freeze affected accounts and notify the CFO within 2 hours. |
| Critical Vulnerability Patch Time | Average days from critical CVE disclosure to production patch. Green <7 days · Amber 7–30 days · Red >30 days. Rationale cites Cybersecurity and Infrastructure Security Agency (CISA) guidance on patching critical vulnerabilities. |
| Phishing Click-Through Rate | Employees who clicked a simulated phishing link / employees tested × 100. Green <5% · Amber 5%–15% · Red >15%. Quarterly; clickers get mandatory retraining within 5 business days. |
◆ Implementation roadmap
How to roll this out.
Start with 10–15 KRIs, not the full library
Owner · Risk or compliance lead
Output · A starter set of 10–15 KRIs tied to your top risks — manageable by a solo compliance hire — expanding toward the full library of 152 as the program matures
Link every KRI to a risk in your register
Owner · Risk lead with business owner input
Output · Each indicator carries a linked risk ID so the dashboard reads as "risk movement," not disconnected metrics
Calibrate thresholds using a documented basis
Owner · KRI owner with second-line challenge
Output · Thresholds set from one of four approaches — industry benchmarks, regulatory bright lines, statistical baselines (mean ± standard deviation), or contractual obligations to bank partners and vendors — each with a written rationale
Name the data source and owner for each KRI
Owner · KRI owner + data owner team
Output · A named system, export path, and collection method per indicator, plus an owner accountable for reporting it on cadence
Set the reporting cadence and escalation protocol
Owner · Risk lead + risk committee
Output · Weekly/monthly/quarterly reporting by KRI criticality, with one written escalation protocol — amber: KRI owner and Chief Risk Officer notified within 1 business day; red: Chief Risk Officer within 24 hours and CEO and board risk committee within 24–48 hours
Recalibrate annually and after material events
Owner · Risk lead with KRI owners
Output · A first recalibration after 3 months of data for new KRIs, then an annual threshold review at minimum plus recalibration after any material adverse event — thresholds that never move are thresholds nobody trusts
◆ Ready to use it?
Download the KRI Library (152 Key Risk Indicators).
Use the guide to understand the structure, or buy the editable template to move faster.
◆ FAQ
Frequently asked questions.
How many KRIs should a fintech track? ⌄
Start with 10–15 tied to your top risks, which a solo compliance hire can actually maintain, and add more once the monthly cycle runs smoothly. Board packs usually carry 5–8 KRIs. The failure mode is starting with everything: a 130-metric dashboard nobody updates is worse than a 15-metric dashboard that gets reported every month.
How do I set green/amber/red thresholds without historical data? ⌄
Use one of four documented approaches: industry benchmarks where external data exists (uptime, fraud rates, turnover), regulatory bright lines where regulators have defined them, statistical methods (mean ± standard deviation) once you have an internal baseline, or contractual thresholds tied to bank partner and vendor obligations. If you have no history, start from a benchmark or contractual value, recalibrate after your first 3 months of data, and move to statistical methods once you have 12 months. Document the basis for every threshold — that documentation is what makes the number defensible.
What is the difference between a KRI and a KPI? ⌄
A Key Performance Indicator measures progress toward a business objective; a Key Risk Indicator measures whether risk exposure is rising toward your appetite. The same metric can serve both roles — uptime is a KPI to a product team and a KRI to a risk team — but the KRI version needs thresholds tied to risk appetite and an escalation path, not just a target.
What should happen when a KRI turns red? ⌄
Red means performance has breached risk appetite and requires immediate action — which is why every KRI needs a pre-defined escalation trigger with a named owner, a notification timeline, and a response action. For example: a key person departure means notifying the CEO and board chair within 24 hours and activating succession plans; a sustained API error rate above 1% means declaring a P1 incident. Amber is the early warning tier: the KRI owner and Chief Risk Officer are notified within one business day, root cause analysis starts within five business days, and a KRI that stays amber for three periods without improving is escalated like a red.
Who should own a KRI — risk or the business? ⌄
The business executive closest to the metric owns it: the Chief People Officer owns turnover, the VP Engineering owns uptime and change failure rate, the CISO owns patch time and phishing click-through. The risk team owns the methodology, the calibration process, and the challenge function. Separately, name the data owner team — the group that actually produces the number — so reporting doesn't stall when the KRI owner and the data source sit in different departments.
How often should KRIs be reported? ⌄
Match frequency to how fast the risk moves: daily for transaction-level indicators like reconciliation breaks and API error rates, monthly for operational metrics like uptime, MTTR, and deprovisioning SLAs, and quarterly for slower-moving indicators like turnover, training completion, and key person coverage. Recalibrate new KRIs after their first 3 months of data, review all thresholds annually at minimum, and recalibrate after any material adverse event.