Case study · Client name withheld
The product was live.
The risk function wasn’t.
A growing rewards business was already moving money without a dedicated risk function. I designed what needed to become visible, owned, and repeatable before the company spent more on tooling, automation, or headcount.
The problem
Money is already moving. Problems are already happening. Nobody owns the function that should make sense of them.
- Who knows what happened?
- Who owns the decision?
- Which problems are incidents, and which are normal exceptions?
- What is actually driving loss or load?
- What needs tooling, and what can stay manual?
The insight
Don’t automate ambiguity.
Software, vendors, and automation are tempting when a risk function is immature. But technology cannot resolve a system the company does not understand yet.
Make the risk visible. Establish ownership. Learn the patterns. Make the decisions repeatable. Then decide what deserves to scale.
The model
Not days. Not quarters. Maturity.
See
You can't control what you can't observe.
Map how money and value move, where failures and abuse appear, what information already exists, and who is making the decisions today.
Control
Stop exceptions from becoming chaos.
Give incidents an owner. Track exceptions. Establish a baseline for what is happening and how often.
Sophisticated controls are useful later. Clear ownership is useful immediately.
Repeat
The second time a problem happens, you should know more than you did the first time.
Recurring situations should stop requiring reinvention. Make the judgment repeatable enough that it does not depend on remembering who handled the last one.
Scale
Now decide what deserves machinery.
Use what the work has taught you to decide what to automate, buy, build, govern, or staff.
Requirements before vendors. Evidence before automation.
Why ninety days
The point was not to build a mature risk organization in three months. It was to establish enough visibility and control that the next decisions could come from evidence instead of guesswork.
What the foundation was designed to make possible
The organization should be able to answer:
- What happened?
- Where did it happen?
- Who owns it?
- How do we contain it?
- How do we stop it happening again?
The company approved the plan.
What stays private
The principle is public. The implementation is not.
- Specific abuse patterns and investigation sequences
- Exact controls, decision rights, thresholds, and escalation triggers
- Data and tooling architecture
- Vendor evaluation logic
- Client-specific roadmaps and internal metrics
See the engagement in more detail
Deeper implementation context is available for appropriate conversations.
Request deeper context