Halden Pay is facing two simultaneous forcing events — a card-scheme liability shift and an acquirer ultimatum — against a six-month window it cannot miss. Fraud losses running at £600k per year have already doubled over 12 months, and the cost of inaction compounds on both fronts simultaneously. The decision is not really about the long-term optimal architecture; it is about which path can deliver a working, production-grade fraud scoring capability before the acquirer's formal review closes the window. Buy is the call — not because it is strategically optimal in isolation, but because it is the only path that fits the constraint. A vendor licence from Ravelin, Sift, or Sardine can be live in three to four months at £900k over three years, leaving a margin before the hard gate.
The proprietary transaction graph — the asset that genuinely does represent Halden Pay's competitive edge — is not surrendered by this decision; it is protected by buying time. The right framing for the vendor period is not 'we rented someone else's model' but 'we bought 12 to 18 months to build the internal case for doing this properly.' The transition to Make, when the hiring freeze lifts and the business case is evidenced by vendor performance data, is the second chapter — not a concession.
Transaction-level ML scoring to detect and block fraudulent card payments before they clear, reducing chargebacks across the SME merchant portfolio
Card-scheme rule change shifting fraud liability, plus Halden Pay's largest acquiring partner formally requiring chargeback reduction within six months or imposing repricing
The acquirer review is a hard gate — not a stretch goal. Missing it triggers repricing that compounds the margin pressure already created by rising fraud losses. The card-scheme liability shift runs in parallel, meaning delay on either front is costly.
The three tests pull in different directions, and the honest classification sits at Context rather than Core. On the differentiation test: the proprietary transaction graph is genuinely distinctive, but the scoring engine that processes it is not — Ravelin, Sift, Sardine, and comparable vendors all produce transaction-level ML scoring that meets the functional requirement today. The moat is the data, not the capability being decided. On the proprietary-advantage test: a vendor scoring engine can be pointed at Halden Pay's own transaction graph through API integration, so the data advantage is not lost by buying the scoring layer. On the off-shelf availability test: viable, production-grade products exist and are in use by comparable firms. The capability is therefore Context — important to operate well, but not the source of competitive differentiation in itself. The data layer beneath it remains Core and should be protected accordingly.
Misclassifying this as Core and building accordingly creates a 12–18 month capability gap during which fraud losses compound, the acquirer reprices, and the card-scheme liability shift runs uncapped. The real risk is not that a vendor owns the scoring engine — it is that Halden Pay delays protection of the data asset that actually is its moat by conflating the two. Sourcing the scoring capability from outside does not surrender the proprietary graph; it puts a working protective layer around it faster.
| Criteria | Weight | Make | Buy | Partner | Wait |
|---|---|---|---|---|---|
| Speed | 35% | 2 | 9 | 6 | 1 |
| TCO | 20% | 5 | 6 | 5 | 7 |
| Capability fit | 25% | 9 | 6 | 7 | 3 |
| Strategic control | 10% | 10 | 3 | 6 | 4 |
| Reversibility | 10% | 3 | 6 | 5 | 9 |
| Weighted Total | 100% | 5.2 | 6.7 | 5.9 | 3.8 |
Total cost of ownership over 3 years
Buy is the lowest three-year cost at approximately £900k all-in, against Partner at roughly £1.05m and Build at £1.2m–£1.5m. The gap between Buy and Partner is around £150k over three years — a relatively small premium for a materially different strategic outcome if IP terms are secured. Build carries the highest cost and the longest time to value, and its two-year figure understates the true TCO because the team and infrastructure costs persist beyond year two. Wait carries no direct cost of the capability itself, but the £600k annual fraud loss running unmitigated means the three-year cost of inaction is approximately £1.8m in fraud losses alone, before acquirer repricing is added.
Mitigation: Negotiate a pilot clause covering at least 60 days of live transaction volume before full contract commitment. Define chargeback reduction thresholds as contractual exit triggers if performance benchmarks are not met within 90 days of go-live.
Mitigation: Confirm API integration complexity with the chosen vendor before signing. Assign integration as the single engineering priority for the period — not a parallel workstream. Build a four-week buffer into the internal plan against the six-month external deadline.
Mitigation: Ensure contract terms include full data portability and model-output logging from day one. Design the integration layer to be vendor-agnostic so a future migration to an internal model does not require a full re-integration. Review vendor dependency annually.
Mitigation: Use the Buy window to build the business case for the ML function. Document model performance, data signal quality, and chargeback outcomes during the vendor period — this becomes the evidence base for a headcount exception request in 12–18 months.
Mitigation: Treat the scheme liability date as a parallel hard gate alongside the acquirer review. Sequence vendor selection and contract signature within the first four weeks to preserve the integration window.
Mitigation: If Partner is revisited as a transition path, engage legal counsel before opening commercial conversations. Require model weight ownership and training-data IP to be retained by Halden Pay as a non-negotiable term — walk away from any arrangement that does not meet this condition.
Buy scores highest in the weighted matrix — driven by Speed, which carries the most weight and where Buy scores 9 against Make's 2 and Partner's 6. The six-month acquirer deadline is a hard gate, not a preference, and Buy is the only path that fits inside it with any margin. Make cannot meet the deadline under any realistic hiring and build scenario, particularly with a hiring freeze in place. Partner is a credible strategic option but is at the exploration stage with IP terms unresolved — committing to it now would mean opening commercial negotiations, agreeing IP terms, and completing integration all within six months, which is a tighter and less certain path than a standard vendor licence. Wait is not a genuine option: deferring means the £600k annual fraud loss continues unmitigated, acquirer repricing follows the formal review, and the card-scheme liability exposure compounds in parallel. The central trade-off is that Buy leaves Halden Pay's proprietary transaction graph underexploited for as long as the vendor model is in place. That is a real cost — but it is the cost of meeting a deadline that, if missed, makes every other option more expensive. The right sequence is to buy now, protect the data asset in the contract terms, and build the internal case for an ML function during the vendor period so the transition to Make is planned rather than forced.
What this is. This Make vs Buy was built through a guided conversation between Demo and Ren.
How it was built. All analysis reflects your own thinking — structured using established frameworks, sharpened, and presented clearly.
This report was produced by Ren, an AI advisor built by Renatus. It is based on information you provided during the conversation and established frameworks. It is intended to support — not replace — your own judgement. All conclusions should be reviewed before acting on them.
Renatus applies the underlying principles of established methods and credits their origin where relevant. Named frameworks, methods, and instruments are the property of their respective owners. Reference to them does not imply endorsement or affiliation.
3 frameworks were used to structure your thinking: