TL;DR
A shop’s card non-payments had climbed past 5% and were heading toward 8%, each loss surfacing weeks too late to recover. I built an in-house fraud-detection system by phases, reinforced it week after week, and the losses fell to fewer than a dozen a year. The system then fell quiet, which is the promise behind systems that scale.
The situation as found
Contrat-Expert, the shop on Net-iris’s in-house stack, sells customizable digital contract templates: one-shot document downloads alongside annual subscription signups. As transactions grew, card non-payments climbed, driven by the banks’ over-protection of consumers on internet transactions before 3D Secure existed. The rate passed 5% and was heading toward 8%, a level where the bank could sanction the business or refuse online card payments. Non-payments always arrived with a latency of several weeks, which usually made recovery impossible: easy for the annual subscriptions, not viable for a one-shot download already delivered. I was an entrepreneur then, building it in-house.
The diagnosis
The presenting symptom was a rising rate of unpaid card transactions. The real cause sat deeper: the charge-reversal risk sat entirely on the shop. Under the banks’ consumer protection in the years before 3D Secure, a buyer could dispute the charge, and at payment time I could not tell a risky transaction from a genuine one; the non-payment surfaced only weeks later, long after a digital download had been given away. The problem was not fraud volume alone but the absence of a screen on the acceptance decision, plus detection too late to act.
What was decided, and why
Two options were live, and both were rejected. Absorbing the losses as a cost of doing business held only while the bank tolerated it, and the rate was climbing. Staying manual was no answer either: a staff-based review cannot screen every transaction. I chose to build a layered, in-house fraud-prevention system, because the shop was already custom and developed in-house, and to deploy it in phases, reinforcing it week after week. One component was bought rather than built, a third-party IP-geolocation web service subscribed via API, while the identity-risk scoring logic stayed in my hands.
That layering is the same R&D, phase-based design method I used later for the editorial-priority algorithm, in a different domain. That work is the earlier of the two; they share the method and nothing else. I did this alone, and the source records no team involved.
What was actually built or changed
- The account layer. I hardened account creation against scripts and robots and cut down badly filled data, leaving fewer fake accounts to screen.
- The algorithm. I built a fraud-prevention algorithm and deployed it by phases, reinforcing it week after week to fill the holes and correct false positives.
- The risk score. I fused three signals into one score: IP geolocation from the subscribed web service, risk checks on email-address and name formatting, and postal-address consistency.
- The automation. I automated as much of the flow as I could, so the system could act without a person behind every transaction.
- The back office. I built an interface that gathered fraud-suspicion alerts, and improved transaction and customer tracking so it carried the score and let customer service unblock a legitimate buyer in a few routine checks.
- The correction loop. Every false positive was analyzed for the pattern behind it, and that pattern went back into the algorithm as an improvement.
What broke, and what was got wrong
The false positives were a real cost. Legitimate customers were blocked and needed manual unblocking, through customer service, or by paying by check or calling in, and some false positives could not be corrected to a clean pass. The latency meant early detection stayed reactive, and many non-payments were never recovered. The phased roll-out meant the algorithm ran with holes between reinforcements before each weekly patch, and the risk features had to be learned by testing which signals of geolocation and identity format actually separate fraud from a genuine buyer.
The outcome, with its status
Over the months, the card non-payment rate progressively became an epiphenomenon, and the maintenance load of the algorithm lightened once a stable, high-performing version was found. Remaining non-payments fell to fewer than a dozen a year, measured, against several hundred at the height of the crisis. The cost of the fraud and of managing it was drastically reduced, making the shop and its online transactions more reliable and sustainable; that last point is the source’s own qualitative claim, stated as one and never upgraded to a number. The fraud shield is one of the systems behind the who I am page, alongside the growth machine the editorial-priority algorithm built.
If this is the shape of your problem, an operation quietly leaking through a decision it makes by hand, let’s talk.