Risk and Compliance study materials
Risk and Compliance study resources

Risk Appetite Versus a Profitable Exception

Risk and Compliance · Put your knowledge to work in context.

All case studies

Risk Appetite Versus a Profitable Exception

Helios Payments has a board-approved risk appetite stating it will accept no more than a 'low' residual risk for customer authentication controls. The product team proposes launching a new peer-to-peer transfer feature in six weeks. Its authentication design uses SMS one-time passcodes only, which the security team rates as 'medium' residual risk because of SIM-swap fraud. The product lead argues that SMS is standard in the market, that adding app-based authentication would delay launch by ten weeks, and that the projected first-year revenue is $4.2M. The risk committee meets monthly; the next meeting is in three weeks, after the proposed launch date. The CRO is asked to approve a time-limited exception so the launch can proceed.

1. Can the CRO approve this exception? Analyze the authority and governance issues.

Read the worked answer

Not unilaterally, on these facts. The appetite statement is board-approved, which means the tolerance for authentication risk is set at board level. A CRO can typically approve exceptions within stated tolerance, but cannot authorize a breach of a board-set limit. Approving a 'medium' residual against a 'low' appetite is a breach, so it requires escalation to the body that owns the appetite - the board or a delegated risk committee acting under explicit authority.

The timing compounds this: the risk committee meets after the launch date. The CRO cannot let a calendar gap convert into implicit approval. The correct path is either (a) an extraordinary risk committee session before launch, or (b) a documented deferral of launch until the committee can decide. Approving the exception and ratifying later would set a precedent that appetite limits are advisory, which undermines the entire framework.

2. The product lead offers to accept the risk personally in writing. Does that resolve the governance problem?

Read the worked answer

No. Individual risk acceptance does not substitute for organizational risk acceptance when the limit is set at board level. A product lead can own the delivery risk and be accountable for the feature, but cannot absorb a risk the board has reserved. Accepting it personally creates a false impression of coverage: if SIM-swap fraud causes customer losses, the firm - not the individual - bears the regulatory, financial, and reputational consequences. A personal letter also does nothing for customers who are harmed.

What the offer is useful for: documenting that the business understands the residual risk and is accountable for remediation timelines. Treat it as an input to the committee decision, not a substitute for it. The committee should record who accepted what, at what level, and with what expiry.

3. Recommend a decision path that respects both the appetite framework and the commercial pressure, and state the conditions you would attach.

Read the worked answer

Recommended path: conditional, scoped exception approved by the risk committee at an emergency session before launch, with the CRO presenting rather than deciding alone.

Conditions to attach:

  • Scope limit: cap transaction value or volume per customer during the exception period to bound loss exposure.
  • Compensating controls: velocity limits, device fingerprinting, and step-up verification for high-value transfers.
  • Hard expiry: exception lapses on a fixed date (e.g., 90 days), not on 'completion of roadmap'.
  • Funding commitment: app-based authentication funded and scheduled now, with milestone reporting to the committee.
  • Monitoring trigger: defined fraud-loss threshold that automatically suspends the feature.
  • Appetite review: if SMS-only proves durable, propose amending the appetite statement through the board rather than issuing serial exceptions.

This respects the framework (the right body decides), preserves the commercial opportunity, and ensures the exception is time-bound and monitored rather than permanent.