Data Department worked with a payment services company that extends payment limits to its network of dealers and merchants. The work centred on predicting dealer default and building a dealer risk score, so that limit-increase requests could be decided automatically.
What was the decision?
The company gives each dealer a payment limit. Dealers regularly ask for that limit to be raised. Every request is a small credit decision: approve it in full, approve part of it, or reject it.
Deciding these requests by hand is slow and can be inconsistent. Approving too freely raises the risk that a dealer cannot pay. Rejecting too often holds back good dealers and the business they bring. The question we set out to answer was: can we tell, for each request, how likely this dealer is to default, so that safe requests can be approved automatically?
What did we build?
| Component | What it answers | Role in the decision |
|---|---|---|
| Default prediction model | How likely is this dealer to fail to pay? | Core input to every limit decision |
| Dealer risk score | Where does this dealer sit on a simple risk scale? | Lets rules approve, cap or refer a request |
| Limit-history reconstruction | What limits did each dealer ask for and receive over time? | Training data for both of the above |
What the model learned from. The risk score drew on three kinds of data:
- Limit-request history: requested versus approved limits, and full or partial rejections.
- Transaction history: how each dealer actually uses its payment limit.
- Chargeback and dispute data: chargebacks (payments reversed after a customer dispute) and other disputes linked to the dealer.
Why was data preparation such a large part of the work?
The company's systems recorded limit changes as a log of edits, not as a clean history of requests and decisions. To train a model, we first had to reconstruct each dealer's limit history from those change logs: what was requested, what was approved, and when.
This is common in credit work. In general, the decision history a model needs often exists only as a side effect of operational systems, and rebuilding it carefully is what makes the later modelling trustworthy.
Results
- A dealer default model and dealer risk score built from limit-request, transaction and chargeback data.
- A reconstructed limit history that did not exist before in a usable form.
We do not publish performance figures for this project.
What did we learn?
Start from the decision. The aim was never "a credit model" in the abstract. It was faster, consistent answers to limit-increase requests.
The data work is the project. Reconstructing limit history took a large share of the effort, and it is reusable for later modelling work.
Design the score around the rules. A risk score is useful when it maps cleanly onto actions: approve, cap or refer. Building it with those rules in mind keeps the output usable by the people who decide limits.
For related work, see our financial services and insurance page, our collections forecasting case, and our AI strategy and fractional Chief AI Officer service.
Frequently asked questions
What is a dealer risk score?
A dealer risk score is a number that summarises how likely a dealer or merchant is to default on what it owes. It lets a payment company apply consistent rules to limit requests.
Can limit-increase decisions be fully automated?
In general, the safest pattern is to automate the clear cases and refer borderline ones to a person. A risk score makes that split explicit: low-risk requests are approved, higher-risk ones are capped or referred.
What data does merchant credit risk scoring need?
In this project: limit-request history, transaction history, and chargeback and dispute data. In general, the history of past credit decisions is the hardest part to assemble.