From Periodic Checks to Risk-Driven Decisions: Designing a Data-Driven Process

An Inefficient, Time-Based Process

In the domain of Credit Risk Monitoring, some processes are based on fixed-interval checks. In the data era, we wanted to transition to a risk-driven decision engine based on data insights. This allows us to act at the right moments rather than periodically. Decisions are taken when the risk changes – not when the calendar tells to do so.

• The time-based approach leads to unnecessary checks at scheduled moments, or checks happening too late if a risk has increased. This approach yields many other benefits.
• The number of checks decreases: most customer perform financially well and require fewer checks than what periodic schedules enforce.
• Customers enjoy lower costs: checks require customer input and therefore take up their time.
• Customers and employees have a better understanding of when a check is needed.
• Employees dedicate their time where it matters most.

Unlocking a Risk-Based Process with Architecture

We replaced a fixed‑interval check with a data‑driven, event‑based architecture. Three independent applications turn raw data into business events, apply rules (including manually submitted signals) and guide a human‑in‑the‑loop workflow. We intentionally separated responsibilities over three applications, so that three squads can move quickly and independently.

Architecture at a Glance

The three‑application flow turns raw data into decisions — with human expertise where it matters.

The core idea is straightforward:

App 1: Event Producer translates raw changes from the Enterprise Data Lake into business events.

• Gather the latest data
• Emit business events for relevant business changes

App 2: Event Evaluator & Rules determines about the actions for those events, combining automation with human‑submitted signals.

• Consume business events
• Accept manually entered events from other systems (submitted by employees)
• Apply business rules → decide need for check based on single events or a mix of events

App 3: Process Orchestrator runs a human‑in‑the‑loop process to complete revaluations with full traceability.

• Create/route revaluation requests
• Support employee review and controlled workflow
• Record outcomes for audits

Key Design Question: Why Not Merge App 1 and App 2?

In practice, combining event creation and rule evaluation links two different concerns: “what changed?” and “what does it mean?”. Keeping them separate gives us three advantages:

1. Squad autonomy
   Two squads can work independently, each owning its application end‑to‑end. This avoids bottlenecks and allows faster, safer iteration.
2. Cleaner architecture
   It makes testing, versioning and future refactoring easier.
3. Easier evolution
   We can add new event types, tune rules or swap rule engines without risking side effects in the producer. The business dynamics involved in identifying, interpreting and acting on events differ. Identification tends to be more stable than interpretation and action.

Where People Stay in the Loop

Automation detects when revaluation might be needed; people decide how to proceed. App 3 receives validated signals from App 2 and then:

• Assigns requests to the right employees;
• Supports their review process, and
• Ensures that processes can be completed in a controlled, auditable manner.

This balance keeps the system fast and trustworthy. We automate the plumbing while respecting human judgment.

The Cancelation Challenge (and the Data Quality Principle)

We can’t exclude the possibility of an event being created from incomplete or incorrect data. That’s why event‑driven systems need to be able to handle corrections.

We considered “patch logic” and bespoke cancelation flows, but ended up deciding on a clear principle:

If an event is wrong because the data is wrong, fix the data at the source.

Once corrected:

• The pipeline reprocesses automatically;
• New events are emitted;
• Previous events are cancelled by sending the same event with an activated cancelation flag.

This keeps the stream clean, enables the use of a single schema (cancelation flag) and reduces complexity. Over time, it’s far cheaper to invest in source-data quality than to maintain layers of exception code.

What’s Next?

• Broader event catalog: expand event types as our understanding deepens.
• Richer rules: iterative improvements to thresholds and combinations of signals.
• Self‑service capabilities: guard‑railed ways for business experts to propose or simulate rule changes.
• Further automation: assessing cases where human expertise matters the most and automating the rest.
• More domains: applying the same pattern to other data‑driven decision flows where latency and traceability matter. For instance, asset revaluation or credit review domains could make use of that data-driven chain.

Closing Thoughts

Moving from periodic checks to risk-driven decisions is about speed. But it’s also about aligning the system with reality: acting when the world changes, not when the timer fires. By drawing clean boundaries between event production, rule evaluation and human in the loop execution—and by insisting on data-quality-first cancelations—we’ve built a foundation that adapts to both current and future needs.

If you’re tackling similar challenges, think future-proof, collaborate with the business experts, and give your teams the autonomy to evolve their part of the system. Everything else will fall into place.