The FFIEC's final authentication guidance urges financial institutions to adopt risk-based authentication, but many teams struggle with implementation. The challenge isn't understanding the concept; it's integrating "risk-based" into authentication workflows without causing friction or security gaps.
Why These Mistakes Keep Happening
Risk-based authentication seems simple: assess the transaction, assign a risk score, and adjust authentication requirements. However, the guidance doesn't specify thresholds, define "low risk" for your customers, or explain how to handle conflicting risk signals and authentication results.
Many compliance teams treat the guidance as a checklist, adding risk scoring to existing flows without rethinking them. This results in systems that either constantly challenge customers (due to low thresholds) or miss fraud (due to high thresholds and weak authentication).
Mistake 1: Treating Risk Scores as Pass/Fail Gates
If you're using a single threshold to decide whether to challenge a user, you're missing the nuances of risk. A score of 49 and a score of 10 get the same treatment, even though one is riskier. Similarly, a score of 51 and a score of 95 both trigger the same MFA method, though they may require different responses.
The solution: use risk bands with graduated responses. Define at least three zones, low risk (passive monitoring), medium risk (step-up authentication like SMS), and high risk (out-of-band verification). Map each band to specific controls and document your choices based on fraud data and customer tolerance. Review these bands quarterly as attack patterns change.
Mistake 2: Ignoring Authentication Strength in the Risk Calculation
If your risk engine doesn't consider the authentication method used, you're missing a critical variable. A customer using a hardware security key should have a different risk score than one using a reused password.
The solution: include authentication method and assurance level in your risk calculation. If a user authenticated with FIDO2 or a hardware token recently, apply a risk discount. If they used a password or answered knowledge-based questions, apply a risk penalty. Use NIST SP 800-63B to map authentication methods to assurance levels and use them as risk modifiers.
Mistake 3: Failing to Reauthenticate for Privilege Escalation
Allowing high-value transactions without additional checks because of a low initial login risk score can lead to security breaches. An attacker could exploit a low-value session to perform high-risk actions.
The solution: implement step-up authentication for privilege escalation. Define high-risk actions (like wire transfers) and require reauthentication regardless of session age. Verify identity with a method appropriate to the new risk level. For example, a $50,000 wire should trigger out-of-band verification even if the user authenticated with MFA recently.
Mistake 4: Using Behavioral Analytics Without Baseline Validation
Behavioral analytics can detect anomalies, but relying on them alone can lead to false positives and missed fraud. Attackers can mimic normal patterns to evade detection.
The solution: use behavioral analytics to adjust risk scores, not replace cryptographic authentication. Validate your model against your SAR database to ensure it's detecting actual fraud. Combine behavioral signals with device fingerprinting, network reputation, and transaction pattern analysis.
Mistake 5: Skipping the Fallback Authentication Path
If your primary authentication flow fails, having no documented fallback procedure can create security gaps or lock out legitimate customers.
The solution: design and document fallback authentication paths with the same rigor as primary paths. If a customer can't complete MFA, provide alternatives like an out-of-band phone call or in-person verification. Train your contact center on these procedures and audit their use quarterly to ensure they're secure.
Prevention Checklist
Before finalizing your risk-based authentication implementation:
- Define at least three risk bands with specific authentication requirements
- Map authentication methods to NIST SP 800-63B assurance levels and use them as risk modifiers
- Identify high-risk actions that require step-up authentication
- Validate your behavioral analytics model against your SAR database
- Document fallback authentication procedures for every failure mode
- Review risk band thresholds quarterly based on fraud data
- Test your risk engine's response to conflicting signals
- Ensure your contact center can execute fallback authentication securely
The FFIEC guidance provides a framework. Your task is to translate it into specific decisions: which risk score triggers which authentication method, how to handle session escalation, and what to do when the primary path fails. Get these decisions wrong, and you'll frustrate customers or miss fraud. Get them right, and you'll have a system that adapts to actual risk instead of applying the same control to every transaction.
