FINTech Infrastructure
Decline rate monitoring
CONTEXT
The service issues virtual cards for advertising platforms. Clients use them at scale to run large volumes of ad campaigns. As transaction volume grows, operational risk increases as well, especially the Decline Rate (DR) — the percentage of failed transactions. When DR exceeds acceptable limits, banks apply restrictions and penalties.
Business Model
The service earns from client transaction volume. The higher the turnover, the higher the revenue. However, a high DR directly threatens the model — penalties increase and relationships with providers can be damaged.
What is DR
Decline Rate is the share of failed transactions out of the total number of transactions. In essence, it is a financial risk metric. It reflects not only technical issues but also risky client behavior.
The Problem
The team could see the overall DR number but did not understand where exactly the problem originated — which provider, which BIN, or which client. Reactions were slow, decisions were manual, and penalties often arrived faster than analysis.
RISK CONTROL ARCHITECTURE
The goal was not just to collect data, but to build a clear and structured risk control system. We organized monitoring into levels — from the overall picture down to specific sources of the problem.
Overview
The first screen displays all legal entity and provider pairs. It immediately shows which combinations are outside the acceptable DR range and require attention. From here, the team can enter any problematic pair and explore the details.
Legal Entity / Provider Level
Inside a selected pair, we show DR dynamics and the list of clients within that pair. It becomes clear who contributes most to DR. This helps the team understand whether the issue is isolated or systemic.
Risk BINs
From the pair level, users can move to BINs and see which issued card ranges generate high DR. This helps identify provider-level risk and understand whether the issue is tied to a specific card batch, allowing traffic redistribution if needed.
Risk Clients
The next layer focuses on clients. Here we show each client’s contribution to overall DR, their transaction weight, current status, and volume. The team can quickly take action, including freezing a client to prevent penalties.
Risk Threshold Settings
To make the system manageable, we introduced configurable risk thresholds. The team defines where medium and high risk begin. Color indicators and filters are built around these values, making the system adaptable to the current provider requirements.
SOLUTION
We built a dedicated Decline Risk Monitoring section — a system that connects overall risk to specific sources.
Horizontal Architecture
The system is designed without deep navigation layers. Users move between sections through tabs and quick transitions on the same level, without losing context or “diving” into complex hierarchies.
Layered Analytics
Risk is analyzed from top to bottom — from the overall view to specific providers, BINs, and clients. This significantly reduces the time needed to locate the root cause.
Flexible Filters and Thresholds
The team can define minimum client weight, risk thresholds, and apply filters by status or segment. The system adapts to the current risk sensitivity of providers.
Visual Signals
Color-coded levels make risk immediately visible without deep numerical analysis. Problems stand out at a glance.
RESULT
DR became an intuitive tool for managing penalty risk and provider-related restrictions.
Overall Impact
The team started identifying issues before they escalated into penalties. The response shifted from reactive to proactive.
Reduced Penalties
Early detection of problematic clients and BINs helped decrease penalties and stabilize relationships with providers.
Controlled Growth
The service continued scaling, but with a transparent risk control system in place. Growth in providers and clients no longer meant uncontrolled growth in penalties — it became a manageable process.