AI Efficiency Program for Marketplace Groups: 2026

If you sit in Group Strategy, the CFO office, or the Office of the CEO at a multi-vertical marketplace group — the Swiss Marketplace Group, Adevinta, Schibsted, Naspers, Axel Springer Classifieds, REA, Scout24, Immobiliare.it shape — the standard enterprise AI playbook does not fit you cleanly. You don't run one business. You run five to fifteen brands across real estate, automotive, classifieds, finance, and jobs, sitting on top of shared central functions (Group Tech, Group Security & Trust, Group Marketing, finance shared services in Belgrade or Kraków or Bucharest). One subsidiary is already AI-native. Two are barely starting. Three were acquired in the last 24 months and are still mid-integration. And the board has asked for an "AI plan for the group" by Q4. This guide explains why an AI efficiency program marketplace groups actually need is structurally different from the generic enterprise version — and how to scope one that respects the multi-vertical reality instead of pretending it away.

Why Marketplace Groups Need a Different AI Efficiency Approach

The generic enterprise AI efficiency program assumes one business with one customer base, one P&L, and roughly uniform AI maturity across functions. Multi-vertical marketplace groups violate all three assumptions on day one. A program built for a single-vertical insurer or a single-vertical bank produces the wrong map of opportunities when applied to a group that runs Ricardo (classifieds), Homegate and ImmoScout (real estate), AutoScout24 (automotive), FinanceScout24 and moneyland.ch (finance), and a handful of just-acquired bolt-ons all at once.

Three structural facts make multi-vertical marketplace groups their own category:

• Shared central functions, asymmetric BU maturity. Finance, security, trust & safety, customer care platforms, payments, and data engineering are usually centralised. But the brands consuming those functions are at wildly different AI maturity levels — one BU has live AI-generated listings and AI-based fraud detection in production; another is still on a multi-year ERP migration. A single group-wide AI rollout calendar collides with this asymmetry within the first 30 days.
• Data assets locked in one subsidiary. Almost every marketplace group has at least one BU sitting on a proprietary dataset that the rest of the group barely touches — a valuation engine, a credit bureau feed, a vehicle history database, a verified-identity graph. The asset was built for one product. It is rarely connected to the consumer-facing brands that would benefit most. This is where the highest-ROI AI opportunities almost always live, and the generic AI program never finds them.
• M&A integration debt as a permanent state. Rolling-up marketplace groups buy one to three companies a year. There is always at least one acquisition mid-integration, with two tech stacks, two customer databases, two contract templates, and two HRIS instances waiting to be harmonised. An AI program that ignores M&A integration as a workflow is missing 15–25% of the addressable surface.

A serious AI efficiency program marketplace groups can actually fund is built around these three facts, not in spite of them. The rest of this guide unpacks what that looks like in practice.

The Cross-Vertical Pattern Library: One BU Builds, All BUs Benefit

The single highest-leverage move in a multi-vertical group is also the one most enterprise AI consultants miss: identify the BU that has already become an "AI factory" — usually accidentally, almost never named that yet — and reframe its AI investments as a group-level patterns library that gets lifted-and-shifted into the rest of the portfolio.

The pattern is consistent across marketplace groups we have looked at:

• One BU (often the largest C2C classifieds property) is years ahead on AI because it had no choice — high listing volume, fraud pressure, multilingual customer base, and a product team that shipped AI features against business KPIs rather than against an AI strategy deck.
• That BU now has working production systems for AI-assisted listing creation, image moderation, multilingual translation, visual search, AI-based fraud detection, and seller-side assistants. These are not pilots. They are running at millions of transactions per month.
• The other BUs in the same group have all of these capabilities on their 2026 or 2027 roadmaps as if they were greenfield builds. They are not. The technical patterns have already been solved next door.

The asymmetry is not a problem. It is a strategic asset waiting for an explicit mandate. A well-designed AI efficiency program marketplace groups should commission begins by naming this asset and turning lift-and-shift into a governance commitment.

What the cross-vertical pattern library looks like as an operating decision:

Pattern (built in BU A)	Lift-and-shift target	Re-implementation cost saved	Time-to-value vs greenfield
AI-assisted listing creation	Automotive C2C, Real Estate FSBO flows	€400K–€1.2M per BU	8–12 weeks vs 9–18 months
Multilingual translation pipeline	Any BU with cross-border surface	€200K–€600K per BU	4–8 weeks vs 6–12 months
Visual search / AI-native discovery	Real Estate, Automotive listings	€500K–€1.5M per BU	12–16 weeks vs 12–24 months
AI-based fraud detection	Payments, identity, all C2C flows	€600K–€1.8M per BU	10–14 weeks vs 12–18 months
Seller-side AI assistants	B2B agent tooling across verticals	€300K–€900K per BU	6–10 weeks vs 9–15 months

The numbers vary by group, but the structural point does not: a single AI efficiency program marketplace group can typically surface five to seven mature patterns in the lead BU that are each worth low-seven-figures of avoided re-implementation across the rest of the portfolio. The job of the program is not to build new AI. It is to make sure the AI you already built gets used four more times.

Unlocking Data Moats That Live in One Subsidiary

The second pattern: somewhere inside a multi-vertical marketplace group, there is almost always a proprietary dataset that would qualify as a defensible moat in its own right — and it is sitting in one subsidiary, disconnected from the consumer-facing brands that would benefit most.

The canonical examples we have seen:

• A real-estate valuation subsidiary that values hundreds of thousands of properties annually for banking clients, owns proprietary hedonic and energy-efficiency models, and represents a meaningful share of the country's mortgage volume — but whose data does not flow natively into the group's consumer real estate listings or mortgage matching products.
• A vehicle-history dataset built for B2B dealer auctions that never gets exposed to the C2C automotive listings page, where it would convert browse-to-contact at materially higher rates.
• A verified-identity graph built for one regulated finance product, sitting outside the trust & safety surface of the C2C classifieds brand on the same group network.
• A credit-bureau or insurance-quotes pipeline owned by a comparison subsidiary, never wired into the loan-origination flow of an adjacent finance brand.

The asset is real. The moat is real. The connectivity is missing. This is a category of opportunity that pure top-down strategy work systematically misses because the moat does not appear on any group-level capability map — it appears as a line item in one subsidiary's P&L. Bottom-up workflow discovery surfaces it within the first three weeks because the people running the consumer-facing brand will mention, repeatedly, that they wish they had access to it.

A serious AI efficiency program marketplace groups run should explicitly catalogue these data moats as a workstream:

1. Identify every proprietary dataset that lives in one subsidiary and would have cross-vertical value (valuation, identity, vehicle history, transaction history, dealer-side telemetry, mortgage data, insurance quotes).
2. Score each one for cross-BU monetisation potential: which other brand in the group would convert better, price better, retain better if grounded in this dataset?
3. Design the data-product surface (API, embedding, native integration) and the governance (data-use agreement between BUs, privacy/regulatory boundary, attribution and internal transfer pricing).
4. Sequence the wiring as a multi-quarter programme of four to six AI applications, each grounded in the dataset, each delivered to a different consumer-facing brand.

The data moat does not become an AI moat by accident. It becomes an AI moat because someone wrote it into the operating model.

Payment Consolidation → AI Intelligence Layer

If your marketplace group spent 2023–2025 consolidating payment providers — collapsing Stripe, Datatrans, Worldline, Adyen, regional acquirers down to one or two strategic platforms — you did not just save bps on interchange. You unlocked an AI layer that was technically impossible the year before. Most groups have not noticed.

The mechanism is straightforward: cross-marketplace payment behaviour modelling, cross-BU fraud signal sharing, AI-driven dispute pre-classification, and automated reconciliation all depend on payment data living in a single tenancy. When the same buyer pays for a car on Marketplace A, lists a property on Marketplace B, and gets a mortgage quote on Marketplace C, the only system that can see all three transactions is the unified payment provider. Until the consolidation was done, the data lived in three providers and the cross-marketplace view did not exist. After the consolidation, it does.

This is the same architectural-unlock argument that justified payment consolidation in the first place, applied one layer up. A well-scoped AI efficiency program marketplace group should run will catalogue, specifically:

• Cross-marketplace fraud signal sharing. A seller flagged on Marketplace A should be a higher-friction onboard on Marketplace B. A buyer with chargeback patterns in one vertical should change risk scores in another. None of this is exotic. It just requires the unified payment data layer that did not exist until 2025.
• Cross-marketplace behaviour modelling for monetisation. A user who lists a car they bought five years ago is a much higher-value lead for a real-estate brand than a generic ad impression suggests. The signal is in the payment graph.
• AI dispute pre-classification. The unified provider can train a single dispute-triage model across all marketplaces, instead of three separate models with three separate accuracies.
• Automated reconciliation. Month-end close on consolidated payments is the single highest-ROI AI workflow in most marketplace group finance functions — and one of the easiest to ship in the first 90 days post-consolidation.

If the program does not surface this architectural unlock, it is leaving the most defensible AI moat in the group on the table. Payment consolidation was not three separate facts. It was one decision that just enabled a new layer. The job of the AI program is to actually build that layer.

M&A Integration as a Reusable AI Asset

Rolling-up marketplace groups buy one to three companies per year. The mid-term guidance almost always commits to continued M&A. The CCO often comes from M&A in a previous classifieds group. There are usually two or three INSEAD MBAs and at least one ex-strategy-consultant on the ELT. M&A is not an event. It is a permanent workflow.

And yet, in almost every multi-vertical group we have looked at, M&A integration is handled semi-artisanally each time. A bespoke project plan. Manual data dictionary mapping. Contract review by external counsel charging hourly. HRIS migration done by hand. Knowledge transfer through sit-down meetings and shared drives. Every acquisition starts from scratch. Top operators spend disproportionate calendar time on integration mechanics that AI could absorb — and that calendar time is exactly the ELT bandwidth that should be free for the next strategic M&A selection.

A serious AI efficiency program marketplace group runs should treat M&A integration as one of the highest-priority workstreams, because it is one of the few workflows where:

• The pattern recurs predictably. Every 6–12 months a new acquisition triggers the same set of tasks.
• The work is highly structured. Data mapping, contract clause extraction, system reconciliation, knowledge transfer — all are exactly the categories that current LLMs handle well.
• Re-use compounds. An integration playbook built once gets cheaper, faster, and more reliable on every subsequent acquisition.
• The ROI is measured in ELT calendar. Hours that the CFO, COO, and CCO do not spend on integration mechanics are hours they spend on the next deal.

The shape of an AI-augmented integration playbook as a reusable asset:

Integration workflow	AI capability	Time-to-full-integration impact
Data dictionary mapping	LLM-based schema diffing, field-level mapping suggestions, lineage extraction	From 6–10 weeks to 1–2 weeks
Contract clause extraction	Automated review of acquired company's commercial contracts vs group template; flag deviations	From 4–8 weeks of external counsel to 3–5 days
System reconciliation	AI assistants that map acquired financial systems to group chart of accounts, surface anomalies	From 8–12 weeks to 2–4 weeks
Knowledge transfer	RAG over acquired company's docs, code, runbooks, Slack history; queryable institutional memory from day 1	Reduces 3–6 month ramp to weeks
Employee transition	HRIS field-mapping assistants, policy harmonisation, onboarding content auto-generation	From 4–6 weeks to 1–2 weeks per cohort

The playbook becomes a reusable group asset. By the third acquisition, integration time-to-completion drops materially. By the fifth, the integration team is half the size and the ELT is back on strategic M&A selection rather than mechanical integration management.

LLM-Native Discovery for Marketplace Search

The marketplace-specific monetisation issue nobody puts in the strategy deck: traditional ad revenue from in-app advertising units is in structural decline. Google has sunset in-app Adsense in multiple regions. Advertising revenue at multi-vertical marketplace groups has fallen mid-single digits to low-double-digits year-over-year because of it. Meanwhile, LLM-driven search and discovery is emerging as a new traffic source — today still small (often less than 1% of total traffic), but the trajectory is unambiguous.

The revenue lost to Adsense decline does not come back through more traditional Google ads. It comes back through AI-native owned audience monetisation. The strategic move is to substitute lost revenue, not to recover it. The platforms that capture LLM-discovery traffic in 2026 will own marketshare disproportionately by 2027. This is exactly the architectural shift a properly scoped AI efficiency program marketplace groups should commission needs to push to the top of the backlog.

Concretely, the LLM-native monetisation stack looks like:

• LLM-optimised content surfaces across all brands. Listing descriptions, category pages, and structured data designed to be cited by ChatGPT, Perplexity, Gemini, and the next generation of agentic shopping models — not just by Google's classic crawler.
• Conversational shopping experiences embedded in the product. A vertical-specific agent on the automotive brand. A ChatGPT app inside the real-estate brand. A property-search copilot that answers full intent queries instead of returning ten links.
• Native attribution model for LLM-originated traffic. If you cannot measure conversions from LLM referrals, you will under-invest in the surface that wins the next five years.
• API and MCP surfaces for AI agents. Marketplaces that expose structured, agent-friendly endpoints become the default backend for shopping agents. The ones that don't get scraped instead of cited.

This is one of the few areas where a multi-vertical group has a structural advantage over a single-vertical pure-play: you can run the LLM-native monetisation experiment in one brand, measure it cleanly, then port the winning patterns across the portfolio. The cross-vertical pattern library logic from the first section applies directly.

Operating Model for Multi-Vertical AI Adoption

The wrong move for a multi-vertical marketplace group is to spin up a new Chief AI Officer with a new committee and a new parallel structure. The right move is almost always to elevate and connect the AI function that already exists — and to design a hub-and-spoke operating model that respects BU autonomy while capturing group-level leverage.

What this looks like in practice:

Layer	Role	What it owns
Group Hub	Elevated Head of Data Engineering & Science → Group AI Office	Cross-vertical pattern library, data-moat governance, model gateway, vendor consolidation, EU AI Act compliance
Steering	Existing Sustainability/Risk Steering Committee (CCO + CFO co-chair)	AI policy, risk thresholds, prioritisation across BUs, board reporting
Risk & Safety	Existing Group Director Security, Trust & Safety	Model risk oversight, prompt injection defence, trust & safety integration
BU Spokes	BU MDs + BU product/data leads	BU-specific AI roadmap, P&L accountability, adoption of group patterns
Shared Services	Offshore engineering centres (Belgrade, Kraków, Bucharest, Goa)	AI standardisation layer built before headcount expansion completes

Two principles make this operating model work. First, the Group AI Office does not own implementation in any BU — it owns the patterns library, the gateway, the governance, and the cross-BU dependencies that no BU could solve alone. Second, the offshore standardisation point is non-negotiable: if your near and offshore ratio is climbing 4–5 percentage points a year (the typical multi-vertical group is around 35–45% offshore and growing), you need to sequence the next 18 months as standardise-then-offshore, not the other way around. Migrating workflows offshore at scale without AI standardisation means linear cost growth. With AI standardisation first, the cost curve becomes sub-linear.

How to Scope the Program at Your Marketplace Group

Before issuing the RFP, run this five-step internal exercise. It is the same diagnostic any serious partner will run on you in the first meeting — doing it yourself shortens procurement by weeks and avoids paying a partner to surface what you already know.

Step 1 — Inventory the BU + central function surface

List every BU, every brand inside each BU, every recent acquisition still in integration, and every shared central function (Group Tech, Group Security & Trust, Group Marketing, Group Finance, offshore shared services). For each, note headcount, primary tech stack, current AI footprint, and whether AI is sponsored at BU level or only at group. That list is the denominator the program will cover.

Step 2 — Identify the AI-factory BU

Which BU is the furthest ahead on production AI? Which patterns has it already shipped (listing creation, fraud detection, translation, visual search, seller assistants)? This BU is your patterns library. Naming it explicitly is the precondition for lift-and-shift.

Step 3 — Catalogue the data moats

For each subsidiary, ask: does it own a proprietary dataset that would have cross-vertical value if connected to other group brands? Valuation engines, vehicle history, identity graphs, credit data, dealer-side telemetry. The answer is rarely zero. The first three you find are your highest-ROI cross-BU opportunities.

Step 4 — Audit architectural unlocks

What did you consolidate in the last 24 months that you have not yet built an AI layer on? Payment provider consolidation is the obvious one. Also: CRM consolidation, identity-provider consolidation, customer-care platform consolidation, data-warehouse unification. Each of these enables AI capabilities that were technically impossible before. Most groups have not noticed.

Step 5 — Pick the Phase-I deep-dive cluster

You cannot deep-dive everywhere in 30 days. Choose one cluster where (a) workflow density is highest, (b) leadership wants the win, (c) results will be visible group-wide. For most marketplace groups, the right Phase-I cluster is either the AI-factory BU plus one lift-and-shift target, or the central shared-services function (often offshore) plus one data-moat unlock. Define day-30 success criteria in writing before signing.

SUPALABS First-Party Data

FAQ

How is an AI efficiency program for a marketplace group different from a generic enterprise AI program?

A generic enterprise AI program assumes one business, one customer base, and roughly uniform AI maturity. A multi-vertical marketplace group violates all three: five to fifteen brands across real estate, automotive, classifieds, finance, and jobs, sitting on shared central functions with wildly asymmetric BU maturity and continuous M&A integration. A properly scoped AI efficiency program marketplace groups commission catalogues the cross-vertical pattern library, the data moats locked in single subsidiaries, the architectural unlocks from prior consolidations (payments, CRM, identity), and the M&A integration playbook as reusable assets — categories that a single-vertical program never names. The deliverable is structurally different because the underlying organisational shape is structurally different.

Which BU should we deep-dive on first in a marketplace AI efficiency program?

One of two patterns works. Pattern A: the AI-factory BU (usually the largest C2C classifieds property) plus one lift-and-shift target — the goal is to prove the cross-vertical pattern library hypothesis on a small scope before scaling. Pattern B: a shared central function (often offshore engineering or finance shared services) plus one data-moat unlock — the goal is to prove the architectural-unlock hypothesis with a fast, visible win. Avoid starting with the BU furthest behind on AI; the discovery work surfaces too many low-quality opportunities and the day-30 proof gate becomes hard to defend.

Should the Group AI Office be a new function or an elevation of an existing one?

Almost always an elevation. Most multi-vertical marketplace groups already have a Head of Data Engineering & Science, a Group Director Security/Trust & Safety, and a Sustainability or Risk Steering Committee that already receives AI updates — the AI governance architecture is distributed but real. Spinning up a new Chief AI Officer plus a new committee adds friction without adding capability. The leverage is in elevating Data Engineering & Science into a named Group AI Office, anchoring AI risk under existing Trust & Safety, and using the existing steering committee structure for prioritisation. New roles only if Phase II evidence demands them.

How do we handle the asymmetry between AI-mature and AI-late BUs?

Treat the asymmetry as the strategic asset it is, not a problem to flatten. The AI-mature BU becomes the patterns library. The AI-late BUs become the lift-and-shift recipients. The program governance should explicitly include a cross-BU pattern adoption KPI: each AI-late BU adopts at least two patterns from the mature BU per year, with the integration cost charged to a group budget rather than the receiving BU's P&L. This removes the local incentive to "build it ourselves" and converts asymmetry into leverage. The cost saved on avoided greenfield re-implementation typically pays for the Group AI Office entirely within 18 months.

How does payment consolidation actually unlock AI for a marketplace group?

Pre-consolidation, payment data lives in three or four providers (Stripe in one region, Datatrans in another, Worldline elsewhere). Cross-marketplace fraud signal sharing, cross-BU behaviour modelling, unified dispute pre-classification, and automated reconciliation all require a single tenancy — they were technically impossible because the data was fragmented. Post-consolidation (typically Adyen, Stripe, or a single regional acquirer), the unified payment data layer makes all four AI workflows buildable for the first time. A serious marketplace AI program treats the year after payment consolidation as the moment the AI intelligence layer becomes buildable, not a moment to celebrate the bps saving and move on.

Should M&A integration really be an AI workstream?

Yes — in a rolling-up marketplace group it is one of the highest-ROI workstreams because the pattern recurs predictably and the calendar ROI accrues to the ELT. Every acquisition triggers the same structured tasks (data dictionary mapping, contract clause extraction, system reconciliation, knowledge transfer, HRIS migration), and current LLMs handle all of them well. An AI-augmented integration playbook built once compounds: by the third acquisition, time-to-full-integration drops materially; by the fifth, the integration team is half the size and the CFO/COO/CCO are back on strategic M&A selection instead of mechanical integration management. If your mid-term guidance commits to continued M&A, the playbook is a strategic asset, not a project.

Sources & References