Make vs Buy | Renatus
PLANNING MAKE VS BUY
Prepared for Demo · 26 Jun 2026

Make vs Buy: Real-Time Transaction Fraud & Risk Scoring

Fraud losses have more than doubled in 12 months, a card-scheme liability shift and an acquirer ultimatum are landing together, and Halden Pay has six months to act before the cost compounds

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.

The decision

Capability
Real-time fraud & risk scoring

Transaction-level ML scoring to detect and block fraudulent card payments before they clear, reducing chargebacks across the SME merchant portfolio

Trigger
Dual forcing event

Card-scheme rule change shifting fraud liability, plus Halden Pay's largest acquiring partner formally requiring chargeback reduction within six months or imposing repricing

Decision window
Six months (by Q4 2026)

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.

Strategic role

Context

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.

Core
Data yes, engine no
The transaction graph is proprietary and distinctive — the scoring engine that processes it is not. Vendors can sit on top of Halden Pay's data without owning it.
Context
Correct classification
Transaction fraud scoring is a well-served category with mature vendors. The capability must work well, but it is not the source of Halden Pay's differentiation.
Commodity
Not quite
Commodity implies fully interchangeable with no configuration needed — fraud scoring still requires tuning to Halden Pay's merchant mix and risk profile, so it sits above pure commodity.

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.

Build

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
52 / 100
What it means
Stand up a dedicated fraud and ML function from scratch: hire three to four ML and data engineers, build training pipelines on the proprietary transaction graph, develop and validate a real-time scoring model, and integrate it into the payments flow. This is a greenfield capability build — no existing fraud expertise, tooling, or infrastructure to extend from.
Time
12–18 months to production-grade capability
Cost
£1.2m–£1.5m over two years (headcount, infrastructure, tooling)
Capability gap
No fraud-ML expertise in-house today. One data engineer already at capacity. Active hiring freeze limits new headcount to backfills only — standing up a three to four person specialist team requires an exception that is not currently approved.
Honest view
Build cannot meet the six-month acquirer deadline under any realistic scenario. Even with immediate hiring approval, onboarding, data pipeline work, model training, and validation would take well beyond six months before anything production-grade is in the fraud path. The hiring freeze makes this a near-impossibility without a specific board-level exception. Build remains the right long-term answer if the proprietary data asset is ever to be fully exploited — but it cannot solve the immediate problem.
Speed
2 / 10
TCO
5 / 10
Capability fit
9 / 10
Strategic control
10 / 10
Reversibility
3 / 10

Buy

68 / 100
What it means
License a production-grade fraud scoring platform from an established vendor — Ravelin, Sift, or Sardine are the named candidates. Integration is via API into the existing payments flow. The vendor model is pre-trained on broad transaction data and requires configuration to Halden Pay's merchant mix. Halden Pay's proprietary transaction graph can inform rules and risk parameters but cannot be natively encoded into the vendor model itself.
Time
3–4 months to live
Cost
£280k per year plus £60k one-off implementation cost
Fit gap
Vendor models are trained on broad merchant populations — performance on Halden Pay's specific SME acquiring mix is unproven and likely to require ongoing manual tuning. Proprietary signals from the transaction graph cannot be easily embedded into the vendor scoring model.
Lock-in
Moderate — transaction data is exportable, but the trained model and any configuration IP stays with the vendor. Exit means restarting model tuning with a new vendor or switching to Build, with transition costs and a capability gap during handover.
Honest view
Buy is the only path that can meet the six-month acquirer deadline with reasonable confidence. Three to four months to live leaves a margin before the hard gate — enough for integration, testing, and early chargeback data to show improvement. The fit gap is real but manageable: vendor models are not perfect out of the box, but they are production-grade and battle-tested at comparable scale. The strategic cost is that Halden Pay's proprietary graph stays underexploited for as long as the vendor model is in place.
Speed
9 / 10
TCO
6 / 10
Capability fit
6 / 10
Strategic control
3 / 10
Reversibility
6 / 10

Partner

60 / 100
What it means
A hybrid arrangement — either a managed or co-development tier with a vendor such as Ravelin or Sardine that trains on Halden Pay's transaction data, or an engagement with a specialist fraud-ops consultancy. The goal is to combine vendor model infrastructure with Halden Pay's proprietary signals, producing a scoring layer that is more tailored than a standard licence but faster to stand up than a full internal build.
Value split
Halden Pay contributes the transaction graph and merchant context; the partner contributes model infrastructure, fraud expertise, and operational tooling. Cost is approximately £350k per year — roughly £70k more annually than a standard Buy licence.
Governance risk
IP ownership is the critical fault line. If the partner retains the model weights and any IP derived from training on Halden Pay's data, walking away means losing the model that was built on Halden Pay's own proprietary graph — a significant and non-obvious lock-in risk. This question is currently unresolved across the arrangements explored.
Candidates
Ravelin managed tier · Sardine co-development programme · Specialist fraud-ops consultancy
Honest view
Partner is a credible middle path only if IP ownership is secured for Halden Pay from day one. Without that, it carries the cost premium of a strategic arrangement with the lock-in risk of a pure vendor licence — the worst of both. If IP terms can be negotiated cleanly, Partner becomes the most strategically coherent option: it protects the data asset, accelerates time to capability, and builds a foundation for eventual internalisation.
Speed
6 / 10
TCO
5 / 10
Capability fit
7 / 10
Strategic control
6 / 10
Reversibility
5 / 10

Wait

38 / 100
What it means
Defer the decision, tighten existing rules-based fraud controls in the interim, and revisit at the acquirer's formal review in two quarters. No new capability is commissioned — the current tooling stack, however limited, absorbs the fraud volume while the business monitors chargeback trends.
Trigger to act
The acquirer's formal six-month review — if chargebacks have not improved materially by then, repricing is imposed. This trigger is not a decision point; it is the consequence of the decision not being made.
Cost of waiting
Fraud losses running at approximately £600k per year continue unmitigated. Acquirer repricing adds further margin compression on top of those losses. The card-scheme liability shift runs in parallel, meaning scheme-level exposure also compounds. Reputational risk with the acquiring partner increases, and options narrow as the window closes — if Build was ever viable, waiting makes it less so.
Honest view
This is avoidance, not a genuine strategic option. The acquirer review is a hard gate, not a trigger for reconsideration — by the time the review lands, the cost has already been incurred. Rules-based tightening alone is unlikely to move chargebacks enough to satisfy the acquirer's threshold, and Halden Pay has acknowledged as much. Wait is included here for completeness and honest scoring — not because it is a live option.
Speed
1 / 10
TCO
7 / 10
Capability fit
3 / 10
Strategic control
4 / 10
Reversibility
9 / 10

Total cost of ownership

Total cost of ownership over 3 years

Make
£1.35m
Buy
£900k
Partner
£1.05m
Wait
£1.8m
0.0 0.5 1.0 1.5 2.0 2.5
£m

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.

Risks

Vendor model underperforms on Halden Pay's SME merchant mix
high

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.

Integration takes longer than three to four months, missing the acquirer's hard gate
high

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.

Vendor lock-in prevents migration to a Build path once internal capability matures
medium

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.

Hiring freeze prevents the eventual transition to an internal Build capability
medium

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.

Card-scheme liability shift compounds losses if go-live is delayed
high

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.

Partner IP terms, if pursued later, may vest model ownership with the vendor
medium

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.

The killer assumption

Assumption:
A licensed vendor model will produce a genuine, measurable reduction in chargebacks on Halden Pay's specific SME acquiring traffic within six months of go-live
Why it matters:
Buy is the only path that fits the acquirer's deadline. If the vendor model does not perform on Halden Pay's merchant mix — whether due to model fit, integration issues, or tuning lag — the six-month window closes without the chargeback improvement the acquirer requires. At that point, repricing is imposed, Build remains 12–18 months away, and the window for a clean Partner negotiation has narrowed. There is no fallback option that solves the immediate problem.

Leading signal:
Chargeback rate trend in the first 60 days post-go-live. If the rate is not moving down by week eight, the model is not performing and the tuning or vendor strategy needs to change before the acquirer review lands.

Review cadence:
Weekly in the first 60 days post-go-live, then monthly through to the acquirer review. After the review, quarterly.

What this Reveals

Buy

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.

Vendor selection and contract signature completed within four weeks of this decision to preserve the integration window
Pilot or performance clause negotiated into the contract — defined chargeback reduction thresholds with exit rights if not met within 90 days of go-live
Full data portability and model-output logging secured in contract terms from day one
Integration assigned as the single engineering priority — not run in parallel with other platform work
Chargeback rate monitored weekly from go-live; escalation protocol defined if rate is not improving by week eight
Business case for an internal ML function to be developed during the vendor period, targeting a headcount exception request within 12–18 months
About About this report

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.

Frameworks Guided Strategy Used

3 frameworks were used to structure your thinking:

Capability Sourcing Decision Tree Tests whether the capability is core, context, or commodity — and whether the company has, can build, or must source it. Adapted from Geoffrey Moore's core/context model.
Total Cost of Ownership Compares full lifetime cost of build vs buy — including implementation, integration, opportunity cost, and exit cost. Standard sourcing economics.
Strategic Optionality Tests how each path preserves or forecloses future strategic options. From real-options thinking applied to sourcing.
Meet Ren
Your AI strategist
We use essential cookies to keep you logged in and protect your session. Our only optional cookies remember your language preference — we don't track you or collect unnecessary data. Cookie Policy · Privacy Policy

Cookie Settings

Choose which cookies you'd like to allow. Essential cookies cannot be disabled as they are required for the platform to function.

Essential Cookies Always Active
Login sessions, security tokens, and consent preferences. Required for the platform to work.
Functional Cookies
Language preferences, display settings, and last accessed report. Disabling may affect personalisation.
Analytics Cookies
Aggregated, anonymised usage data to help improve the platform. Never used to identify you personally.