Risk-scoring merchants at onboarding

Score a merchant at onboarding on two questions at once: how likely the business is to fail on you, and how likely it is to be something other than what the application claims. The first is credit and chargeback exposure. The second is fraud and laundering. Both have to be settled before the first transaction clears, because after that the money moves and the acquirer carries the residual.

That is the awkward part of merchant underwriting. You are making a decision that determines months of settlement exposure using an application form, a website, and a handful of registry lookups. The merchant has every incentive to look ordinary. A transaction launderer files paperwork for a homeware shop and then runs card volume for something that no acquiring bank would knowingly board. The onboarding score is the one point where you can catch that before the exposure exists, and most of the signal you need is sitting in data you already pull for KYB.

What the score is actually predicting

Split the target, because a single “risk” label hides two different economics. Excessive chargebacks cost you refunds, scheme fines, and eventually a monitoring program. Laundering and fraud cost you a lot more and put your acquiring license in the conversation. A merchant can be low on one and high on the other, and the actions differ, so we train and calibrate them separately even when they share features.

The label definitions matter more than the algorithm. We fix an observation window and a performance window up front:

• Chargeback risk: probability the merchant crosses a dispute-ratio threshold within, say, the first six months of processing.
• Laundering risk: probability the merchant’s traffic shows signs of transaction laundering or misrepresented MCC, judged against confirmed cases and closed investigations.
• Credit and settlement risk: probability of a negative balance the merchant cannot cover, which matters most where you offer delayed settlement or reserves.

Each label comes from an outcome that was not knowable at application time. Get sloppy about that and you build a model that backtests beautifully and dies in production, because it learned from the future. Point-in-time correctness is the whole game here. A feature that quietly peeks at a merchant’s later chargebacks turns your eval into a fiction.

The data, and where it goes wrong

Most onboarding features fall into four groups, and each has a failure mode worth naming.

• Registry and KYB: incorporation date, directors, ownership chain, filing history, sanctions and PEP hits. The trap is entity resolution. The same director sits behind three previously terminated merchants under slightly different name spellings, and if your matching is naive you never connect them. Resolving the entity to a stable identity is where this data earns its keep.
• Application attributes: MCC, expected monthly volume, average ticket, refund policy, delivery timeline. Self-reported and therefore adversarial. The useful signal usually lives in the mismatch rather than the value itself. A stated MCC that does not fit the website, a ticket size that is wrong for the segment, a volume a two-month-old company should not be able to forecast.
• Web and content: what the site actually sells, whether checkout works, whether the terms and contact details are real, whether the domain was registered last week. This is often the strongest early signal for laundering, and it is the one traditional underwriting handles worst because it does not scale to manual review.
• Prior processing and network links: MATCH/TMF listings, shared devices, shared bank accounts, shared beneficial owners across your existing book. A clean-looking merchant that shares a settlement account with a terminated one is not clean.

Pull these through a feature pipeline with lineage you can trace. When an underwriter or a regulator asks why an application scored where it did, you want to point at the exact source record and the value as of the application timestamp, not a number that has since been overwritten. Registry data drifts, websites change, ownership gets restructured. A feature store that pins each value to the decision time is what makes the audit trail hold up months later when the dispute arrives.

Scoring, thresholds, and the review lane

The model output is a probability, and a probability is not a decision. The decision comes from where you place the thresholds, and that placement is a business choice about your false-positive budget. Decline too aggressively and you turn away good merchants and your sales team routes around the model. Approve too loosely and the chargebacks and fines show up two quarters later, long after anyone connects them to the onboarding call.

So we run three lanes off the calibrated score:

• Straight-through approval for the clean band, where the expected cost of a wrong approval is below the friction of a manual review.
• Automatic decline for the clearly bad band, with reason codes retained.
• Manual review for the middle, routed to an underwriter with the top contributing features surfaced, the entity links laid out, and the website evidence attached.

Calibration is what makes those bands mean something. A raw model score of 0.8 has to correspond to roughly an 80% observed rate, or the underwriter cannot trust the lane, and the finance team cannot price the reserve. We check calibration on a held-out eval set drawn from the right time period, and we watch it in production, because merchant mix drifts. A model calibrated on last year’s applicant pool quietly decalibrates when a new PSP partner brings a different segment through the door. Watch the input distributions and the score-to-outcome relationship. That drift monitoring is what tells you the score has stopped meaning what the thresholds assume, before a quarter of bad approvals tells you the same thing at more expense.

None of this removes the underwriter. It changes what they spend time on. The straight-through lane clears the volume that never needed a human, the decline lane stops the obvious cases, and the review lane arrives pre-assembled so the person is deciding rather than gathering. The reason codes and the pinned evidence are what let you defend a decision later, whether the challenge comes from a declined merchant, a scheme, or an examiner reading the file at quarter-end.