◆ 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
- ◆ 132 pre-built KRIs across 6 risk domains
- ◆ Green/amber/red threshold calibration
- ◆ Data source and owner mapping
- ◆ Escalation trigger definitions
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.89%, 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. | Tech industry average voluntary turnover is ~13–17%; fintech skews higher at 18–22%, so green is set at top-quartile |
| 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%–79% · 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. |
| Compliance Training Completion Rate | Employees who completed mandatory training by deadline / total required × 100. Green ≥95% · Amber 85%–94% · Red <85%. Regulators expect near-100% completion of BSA/AML and ethics training. |
| Terminated Employee Access Deprovisioning SLA | Terminations with access revoked within 24 hours / total terminations × 100. Green 100% · Amber 95%–99% · 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.89% · Red <99.5%. Bank partners typically require a 99.9% SLA. |
| 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% — thresholds anchored to the DORA elite-performer benchmark. |
| 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 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 a small tier, not the full library
Owner · Risk or compliance lead
Output · A starter set of roughly 20 KRIs — one or two per major risk category — manageable by a solo compliance hire, expanding toward 75 and then the full 132 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 pre-agreed notification paths and response actions for amber and red breaches
Recalibrate annually and after material events
Owner · Risk lead with KRI owners
Output · 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 (132 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 roughly 20 — one or two per major risk category — which a solo compliance hire can actually maintain. Growing teams with dedicated risk staff typically run around 75; mature programs with a full risk team can operate a library of 132. The failure mode is starting with everything: a 130-metric dashboard nobody updates is worse than a 20-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, collect 12 months of data, then recalibrate. 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: monitor closely and investigate, but no formal escalation yet.
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. Review all thresholds annually at minimum, and recalibrate after any material adverse event.