Risk engine — Decision view

The Risk engine plays a central role in the bank’s decision-making. Used by the back office, it evaluates more than 100 parameters to inform credit decisions.

RoleLead Product Designer
2026

CompanyInbank

DomainD2C, B2B2C, Customer care, Risk management

Context

Sometimes, a person still needs to step in—for example, when automated checks fail, a register is unavailable, or a customer challenges a decision.

In the old system, the decision view was a long table of parameters. It was a practical, low-cost choice: the team saved on design and development, and adding a new parameter was as simple as adding another row. Over time, users—especially back-office staff—became accustomed to the format.

Challenge

Depending on location and banking product, the system may request data from more than 20 registries.

Unpredictable content

Good news: responses are always returned as JSON, so they're structured. Bad news: the structure differs from registry to registry; the response size varies from 1 field to a few dozen.

Limited budget and time

This is an internal tool, and companies prefer to spend as little time on it as possible. From a design lead perspective, tailoring the view for every possible combination is a curse.

The view should be compact yet concise

User interviews showed that the view should be easy and quick to scan, but still include all the information from the registries.

Solution

The solution needed to be inexpensive to build, easy to maintain, and clear enough to cover 80% of cases. Because the tool was used only on desktop, we focused on a 1920px-wide screen.

Rather than designing a flow with only a few steps, we created guidelines based on the system’s initial state. This gave engineers a consistent way to add responses for new registries without needing design support each time.

Parameter rules: formats and booleans — Readability improvementsTo keep it readable, I wrote rules to standardise parameters.For example, we started using True/False for boolean values, while registries may return true/false or yes/no. Showing them as tags helps to distinguish them quicker, without reading.

Parameter rules: grouping — Readability improvementsTo keep it readable, I wrote rules to standardise parameters.For example, we started using True/False for boolean values, while registries may return true/false or yes/no. Showing them as tags helps to distinguish them quicker, without reading.

Decision view with registry groups that can be collapsed and empty fields hidden — Compact yet conciseOne of the main concerns users had was that some data might be hidden after the redesign, even though every detail can be important for a full review.To keep things compact and tidy, users can hide empty fields and collapse register groups. The system remembers these choices, but users can show empty values again whenever they need to.

Guidelines mapped to the initial system state — Migration guidelinesA quick map illustrating the logic behind the changes and guiding engineers.

Conclusion

Rather than designing a separate layout for every registry, I defined consistent formatting rules and controls to simplify complex responses while keeping important details accessible. The next step is to test whether specialists can find information faster without overlooking critical data.

Inbank · 2025 – 2026Turning a one-off credit tool into a partner's daily routine

Read it →

Netcracker · 2020 – 2022From paper notes after the shift to a panel that logs the call for you

Read it →

Inbank · 2025 – 2026Moving design from a service department to a product function

Read it →