DEV Community: Digital Colliers

When Your Marketplace Consolidates, First-Party Margin Data Stops Being Optional

Digital Colliers — Sat, 25 Jul 2026 10:00:59 +0000

Written by: Michał Sobieraj, Operations Manager, Digital Colliers

Uber buying Delivery Hero at around $14.8B is the kind of deal that quietly rewrites your P&L six months later. If you sell through aggregators, marketplaces, or any platform that sits between you and the customer, consolidation moves pricing power away from you. The acquirer now owns the demand, the customer data, and the take-rate lever. You own the inventory and the risk.

This isn't a food delivery story. It's the same shape you've seen with Amazon 1P vs 3P terms, with Instacart on CPG, with Deliveroo on restaurants. Every few years a platform consolidates, and the merchants who don't already have their own margin model find out what their business actually earns when the commission goes up 200 basis points.

Why consolidation always renegotiates your unit economics

When two aggregators become one, three things happen in sequence. The merged entity re-tiers commissions. Promotional co-funding gets "rationalised." And the data you used to get about your own customers gets thinner, because the platform now has less competitive pressure to share it.

You can't negotiate against any of that if you don't know your true contribution margin per SKU per channel. And most brands don't. They know blended gross margin. They know channel revenue. The gap between those two numbers is where the platform makes its move.

It matters more now because the cushion is gone. UK eCommerce grew about 3% in 2024 versus 2023, so single-digit growth is the baseline you're planning against. DTC customer acquisition cost is up roughly 40% since 2023. Meta CPMs kept climbing through 2024 and 2025. There's no ad-funded growth to hide a bad take-rate renegotiation inside.

What a real merchant-side margin model looks like

The shape of the thing isn't exotic. It's just work that most brands haven't done because it wasn't urgent yet. Here's the minimum you want:

Order-level ingestion from every channel. Not daily rollups. Individual orders, with SKUs, quantities, gross price, discounts, and the channel identifier. Shopify, Amazon Seller Central, each marketplace, each aggregator, your own DTC site.
Commission and fee normalisation. Every platform reports fees differently. Fulfilment fees, referral fees, ad fees, storage, chargebacks. You need one schema so a £1 of Amazon fee and a £1 of TikTok Shop fee land in the same column.
Returns and refunds joined back to the original order. This is where most models break. Online return rates run around 19-20% of gross sales, and apparel in the UK runs 25-40% depending on category. If you can't reconcile the refund to the order line, your margin numbers are fiction.
Per-SKU contribution margin after fees, refunds, and variable fulfilment. Not gross margin. Contribution. The number that tells you whether this SKU on this channel actually pays for itself.

When brands build this properly, the pattern is uncomfortable. Roughly 30% of SKUs at a typical multi-channel brand lose money per order once you account for returns and ad spend. You're subsidising them with the winners, and you don't know which is which until the model exists.

The ops question nobody wants to answer

Building the model once is a project. Keeping it accurate is an operating discipline. So the real question is who owns it.

In the brands that get this right, it's usually a named person on the finance or ops side with SQL access and a standing weekly slot. Not a BI team ticket. Not a quarterly deck. A person whose job includes noticing that Channel X's effective take-rate ticked up 80 bps last week and flagging it before the quarter closes.

A few questions worth asking your own team this month:

If a marketplace raised commissions 150 bps tomorrow, could you tell me by Friday which SKUs go underwater?
How often does the margin model refresh, and who signs off that the refund data is joined correctly?
When was the last time we compared platform-reported fees against what actually hit the bank?

If those questions get vague answers, that's the gap. Consolidation deals like Uber and Delivery Hero don't create the problem. They just set the deadline for fixing it. The brands that already have the model treat these announcements as a Tuesday. The ones that don't spend the next two quarters building it under pressure, which is the worst possible time.

Sources

This article was originally published on the Digital Colliers Blog. Digital Colliers helps DACH and UK companies implement AI — see our AI consulting services or contact us.

NLP Services: How Natural Language Processing Powers Business

Digital Colliers — Thu, 23 Jul 2026 16:00:59 +0000

ARTICLE STARTS BELOW

NLP Services: How Natural Language Processing Powers Business Applications

Every day, your company generates thousands of words. Customer emails, support tickets, survey responses, social media mentions, contract language, regulatory updates. That's data. But without the right tools, it's noise.

NLP services—Natural Language Processing—turns unstructured text into actionable insights and automated workflows. A manufacturer can track quality issues from customer feedback. A bank can summarize regulatory documents. A SaaS company can categorize support tickets instantly.

This guide shows you what NLP services actually are, the main capabilities, real use cases for European B2B companies, and how to choose an NLP solution.

AI implementation

What Is NLP and Why It Matters

Natural Language Processing is AI trained to understand human language—not just match keywords, but grasp meaning.

Traditional keyword matching:
Search for "angry" in customer feedback. Find it 47 times.

NLP sentiment analysis:
Analyze 10,000 pieces of feedback and identify 847 with negative sentiment (anger, frustration, disappointment)—even if they don't use the word "angry." Understand why: top reasons cited are late delivery (60%), poor documentation (25%), support response time (15%).

That difference—keywords vs. understanding—is what NLP delivers.

Here's what makes NLP powerful:

Context awareness: Understands that "This product is cheap" can be positive (good price) or negative (low quality) depending on context
Multilingual: One model handles English, German, French, Polish—critical for European companies
Scalability: Processes 10,000 documents per day where humans could do 50
Consistency: No fatigue, no bias between analysts
Auditability: Every decision logged and explainable

The Six Core NLP Capabilities

Here's the architecture of what NLP services can do:

1. Sentiment Analysis

What it does: Reads text and classifies emotional tone.

Example:

Input: "Product is great, but shipping took forever and the manual is confusing."
Output: Negative (because frustration > praise)
Detailed breakdown: Product satisfaction: positive; delivery: very negative; documentation: negative; net: negative

Business use cases:

Customer feedback analysis: Find which products/features generate the most complaints
Social media monitoring: Track brand sentiment in real time; alert if spike in negative mentions
Support ticket analysis: Prioritize upset customers for quick resolution
Employee engagement: Analyze survey free-text for morale trends

2. Named Entity Recognition (NER)

What it does: Identifies and labels entities in text—people, companies, locations, products, dates, amounts.

Example:

Input: "Acme Corp's VP of Sales, John Smith, negotiated a €500K contract with us in Q3 2024."
Output:

Organization: Acme Corp

Person: John Smith
Job title: VP of Sales
Amount: €500K
Date: Q3 2024

Business use cases:

Contract intelligence: Extract counterparty name, amount, dates, renewal terms—automatically catalog the contract and set reminders
Invoice processing: Extract vendor name, invoice number, due date, line items—feed directly to accounting system
Research: Pull all mentions of a competitor from news, reports, and emails in seconds
Compliance: Flag mentions of regulated products, jurisdictions, or counterparties in regulatory documents

3. Text Classification

What it does: Sorts text into predefined categories or detects intent.

Example:

Emails → Spam / Legitimate / VIP / Inquiry / Complaint
Support tickets → Product issue / Billing / Account / Feature request (+ urgency: Low / Medium / High)
Contract clauses → IP rights / Payment terms / Confidentiality / Liability / Termination

Business use cases:

Auto-routing: Classify support tickets and send to the right team (billing → finance, technical issue → engineering)
Lead qualification: Categorize incoming inquiry as Sales / Support / Partnership / Complaint
Document triage: Automatically sort invoices, contracts, and forms
Intent detection: Understand what customers want (refund, information, complaint, praise) from short messages

4. Summarization

What it does: Extracts key points from long text and condenses to essential information.

Example:

Input: 3,000-word earnings call transcript
Output: "Company grew revenue 15% YoY. Operating margin declined 2 points due to rising labor costs. Expects margin recovery in H2 as efficiency projects ramp. Guidance: €500M revenue in FY25, +12% vs. FY24."

Business use cases:

Regulatory compliance: Summarize long policy documents or regulatory changes for legal team
Meeting notes: Auto-summarize customer calls or internal meetings—highlight action items and decisions
Document review: Skim 50 supplier proposals in hours, not weeks
Research: Extract key findings from competitor intelligence, market reports, or internal case studies

5. Machine Translation

What it does: Translates text from one language to another while preserving meaning.

Example:

Input (German): "Die Lieferung war verspätet und die Qualität der Verpackung war schlecht."
Output (English): "The delivery was late and the quality of the packaging was poor."

Business use cases:

Multilingual support: Automatically translate customer emails to your team's language
Content localization: Translate website copy, documentation, or marketing materials
Global communication: Break language barriers in distributed teams (Poland, Germany, France)
Compliance: Translate regulatory documents and customer contracts

6. Question Answering

What it does: Treats a set of documents as a searchable knowledge base. You ask a question; the system finds the answer.

Example:

Knowledge base: 500 internal policy documents, 10,000 customer Q&As, 100 product FAQs
Question: "What's our policy on invoice payment terms for startups?"
Output: System retrieves 3 relevant policies, highlights the answer, links to the source document

Business use cases:

Virtual assistant: Support agents ask questions instead of manually searching the knowledge base
Customer self-service: Customers ask questions and get instant answers instead of emailing support
Compliance: Audit teams quickly find relevant policies, procedures, and precedents
Onboarding: New employees ask company process questions and get instant answers

Real-World NLP Applications for European B2B

Manufacturing

Problem: 500 customer support emails/week. Current process: analyst reads each one, manually categorizes (product complaint, technical question, billing, praise), and routes. Slow and error-prone.

NLP solution:

Text classifier trained on 1,000 historical emails
Categorizes new emails with 94% accuracy
Auto-routes 85% directly to the right team
15% flagged as uncertain for human review
Saves 10 hours/week; faster response times

Additional benefit: Sentiment analysis reveals that delayed shipments generate 40% of negative feedback. Operations team uses this insight to prioritize delivery improvement.

Financial Services

Problem: Regulatory team manually reads 50+ regulatory updates/week across 20 EU jurisdictions. Currently takes 8 hours. If they miss something material, it's a compliance violation.

NLP solution:

NLP system monitors regulatory databases in 20 languages
Summarizes and translates all updates
Flags updates relevant to the bank's business (your licenses, your products, your jurisdiction)
Routes to relevant internal teams (AML, lending, investment, HR)
Saves 4 hours/week; reduces compliance risk

SaaS & Software

Problem: Support team logs 2,000 tickets/month. They're drowning. Hard to prioritize. Hard to spot product bugs vs. user confusion.

NLP solution:

Classify each ticket: Bug report vs. Feature request vs. How-to question vs. Billing issue
Extract intent: Is customer asking for a refund, guidance, or complaint?
Identify urgency: Angry customer? VIP customer? Both get priority
Summarize ticket: System extracts 3-4 key sentences instead of reading 5 paragraphs
Result: Support team handles 30% more tickets/week; bugs get fixed faster because they're separated from noise

Logistics & Supply Chain

Problem: 500 shipment exception events/week (delayed delivery, customs issue, wrong address). Manually triaging takes hours. Customers upset because they hear nothing.

NLP solution:

Extract key info from exception events: what happened, where, when, impact
Classify severity: Minor delay vs. lost shipment vs. regulatory hold
Auto-generate customer notification email: "Your shipment is delayed due to X. Expected delivery is Y."
Route critical issues to exception managers immediately
Result: Exception response time drops from 4 hours to 30 minutes; customer satisfaction up because they're informed fast

Human Resources

Problem: Recruiting team gets 300 applications/month. Current process: read CVs, shortlist manually. Huge time drain. Bias risk: unconscious screening preferences.

NLP solution:

Classifier: Does resume match job requirements? Extract education, experience, skills
Score candidates: How well do they match the JD? Ranking reduces human bias
Summarize: Pull key sections (recent roles, key achievements, notable skills)
Result: Recruiting team focuses on top 20% of candidates instead of all 300; fairer screening; faster hiring

LLMs vs. Traditional NLP: What's the Difference?

You might hear about Large Language Models (LLMs) like ChatGPT, GPT-4, or open-source models like Llama. Are they the same as NLP services?

Aspect
Traditional NLP
LLMs

Training
Trained on specific task (sentiment, classification)
Trained on huge text corpus; generalizable

Cost
€5K–50K to train and deploy
Cheap inference (€0.01–0.10 per call)

Speed
Fast (milliseconds)
Slower (1–5 seconds per response)

Accuracy on niche tasks
High (>90%) if good training data
Good (80–90%) but less specialized

Hallucination risk
Low
Higher (LLMs can confidently state false facts)

Explainability
High (you see what features matter)
Lower (black-box)

Customization
Easy to fine-tune on your data
Hard (model size, cost of retraining)

When to use traditional NLP:

High-accuracy requirement (>95%): sentiment, classification, entity extraction
Regulatory/audit trail: need to explain decisions
Cost-sensitive: need to process millions of texts affordably

When to use LLMs:

Generalist task: you don't have specialized training data
Summarization, Q&A, translation: LLMs shine here
One-off analysis: chat interface is convenient
Fine-tuning not required: LLM's base knowledge is sufficient

Best practice: Hybrid. Use traditional NLP for high-volume, repetitive tasks (classify 10,000 tickets/week). Use LLMs for complex reasoning, summarization, or one-off analysis.

NLP solutions

Choosing an NLP Provider: Key Questions

When evaluating NLP services, ask:

What languages do you support? You need at least English, German, French, and Polish for European operations. Can they handle mixed-language documents?

How accurate is your model on MY task? Don't trust generic benchmarks. Provide 100 examples of your documents and ask for a proof-of-concept accuracy score.

Can we train on our data? Off-the-shelf models work 70–80% of the time. To hit 90%+, you need to fine-tune on your specific documents, vocabulary, and use case. Does the vendor support this?

How do we integrate this? API? Webhook? ETL pipeline? Cloud only or on-premises? Does it plug into your existing tools?

What about our data? NLP vendors see your text (customer emails, contracts, etc.). Where does it live? Can you do on-premises or private cloud? GDPR compliance?

Costs? Per-document? Per-month? If you process 100,000 documents/month, is it €1K or €10K? Get a transparent pricing model.

Support & customization? If accuracy isn't good enough, can their team help retrain? Or are you on your own?

Scalability? If you go from 10,000 to 1M documents/month, can the system handle it without degrading?

Implementation Roadmap: NLP from Pilot to Production

Phase 1: Define the Use Case (Week 1–2)

Pick one specific problem (support ticket classification, sentiment analysis, contract extraction)
Gather 200–500 examples of your documents
Define success: "Reduce manual work by 30%" or "Improve response time from 4 hours to 1 hour"

Phase 2: Proof of Concept (Week 3–6)

NLP vendor or consultant trains model on your data
Test on 50 held-out examples
Measure accuracy
If <85%, revisit. If >85%, move to pilot

Phase 3: Pilot Deployment (Week 7–12)

Run NLP system alongside human process in parallel
Track: How many decisions does AI make? How many require human review? Where does it fail?
Train team to monitor and retrain model

Phase 4: Full Rollout (Week 13+)

Integrate into production workflow
Automate downstream actions (routing, alerts)
Build dashboards for business owners
Monthly retraining on new hard cases

Phase 5: Continuous Improvement

Monitor accuracy monthly
Retrain quarterly with new data
Add new use cases as confidence builds

Common Pitfalls & How to Avoid Them

Expecting perfection from day one: 90% accuracy is excellent. 95%+ is rare. Plan for a review layer (human checks uncertain decisions).

Training on bad data: Garbage in, garbage out. Clean your training data first: remove duplicates, fix labels, handle ambiguous examples.

Ignoring language diversity: If your customers are in 5 countries, your NLP model needs to handle code-switching (mixing languages) and dialect.

Deploying without a monitoring plan: Models drift. If you don't monitor accuracy weekly, it silently degrades to 75% in two months.

Over-automating too fast: Start with augmentation (AI suggests, human approves). Once confident, move to full automation.

Choosing a vendor with no support: When accuracy drops or you need to retrain, you'll need help. Don't pick a vendor with no support team.

FAQ

Q: How much data do we need to train an NLP model?
A: 200–500 labeled examples for basic tasks. For complex tasks, 1,000–5,000. More is better, but diminishing returns after 10,000.

Q: Can NLP work on our language (Polish, Czech, etc.)?
A: Yes. Most modern NLP models support 100+ languages. Accuracy is slightly lower for less-spoken languages, but very usable.

Q: How long does NLP training take?
A: A POC: 2–4 weeks. Production model: 4–8 weeks. Ongoing retraining: hours to days.

Q: Can NLP understand humor, sarcasm, and context?
A: Yes, if trained on examples. Modern models (especially LLMs) handle nuance well. But edge cases still trip them up. Plan for a review layer.

Q: What if we want to switch vendors later?
A: Retraining on a new vendor's platform takes 2–4 weeks. Not trivial, but doable. Avoid vendors with proprietary training data or format lock-in.

Q: Is our customer data safe with a vendor?
A: Depends on the vendor and contract. Ask for data processing agreements (DPA), encryption, and GDPR compliance commitments. Some vendors offer on-premises or private cloud options for sensitive data.

Start Small, Scale Fast

The companies winning with NLP didn't start with a grand five-year vision. They started with one painful problem—support tickets, compliance monitoring, contract processing—ran a pilot, measured ROI, and then scaled.

Digital Colliers helps European B2B companies deploy NLP solutions that work in production. We've implemented NLP for manufacturing, finance, SaaS, and logistics companies across the EU. We handle the full journey: defining the right use case, building the model, integrating with your systems, and ensuring it stays accurate.

Let's identify your highest-impact NLP opportunity. Schedule a 30-minute consultation with our NLP team. We'll assess your processes, estimate ROI, and recommend a pilot approach tailored to your business.

This article was originally published on the Digital Colliers Blog. Digital Colliers helps DACH and UK companies implement AI — see our AI consulting services or contact us.

AI for Business Leaders: A Non-Technical Enterprise Guide

Digital Colliers — Mon, 20 Jul 2026 16:00:35 +0000

ARTICLE STARTS BELOW

AI for Business Leaders: A Non-Technical Guide to Enterprise AI

You've heard it a thousand times: "AI will transform your business." But when the technical team starts talking about neural networks, transformers, and training datasets, your eyes glaze over. And the consultants pitching AI solutions? They're selling solutions, not clarity.

This guide cuts through the jargon. You'll learn what AI for business leaders actually means—no machine learning PhD required. We'll cover what AI can and can't do, how to identify real AI opportunities in your company, budgeting, building versus buying, team structure, and governance. By the end, you'll have a framework to make confident AI investment decisions.

AI consulting

What AI Actually Is (No Math Required)

Let's start with a clear definition: AI is software trained to recognize patterns in data and make decisions based on those patterns.

That's it. No magic. Here's what that means in practice:

Traditional Software
You write rules: "If Revenue > €1M AND Industry = Manufacturing, flag for account manager review."

AI Software
You feed it 10,000 examples of accounts that should be flagged and 10,000 that shouldn't. The AI learns the patterns—maybe it discovers that certain industries + company age + growth rate matter more than raw revenue. It finds patterns humans didn't write down.

Why this matters:

Traditional software is great for clear, well-defined rules
AI excels when the rules are fuzzy, complex, or constantly changing (customer behavior, market dynamics, fraud patterns)

That's really the divide: use traditional software for deterministic tasks, AI for pattern-based decisions in messy, changing environments.

The AI Decision Framework for Executives

Not every business problem is an AI problem. Use this framework to decide:

Apply this to your company right now. Think of a business process that consumes time and money:

Is it repetitive? Sales qualification, invoice processing, customer churn prediction, fraud detection, hiring screening—all repetitive. Writing quarterly strategy? Not repetitive. Not an AI candidate.

Is it data-rich? You need historical examples. If you've processed 5,000 loan applications and kept outcome data, AI can learn loan approval patterns. If you've only done 50 loans, there's not enough signal.

Is the pattern complex? A bank's loan approval rules are probably written down (income > 3x loan, debt-to-income < 40%). That's not an AI case—it's rule-based automation. But if you want to detect subtle fraud signals hidden in 100 transaction attributes, that's complex pattern-matching: pure AI.

If you answer "yes" to repetitive + data-rich + complex, AI is worth exploring.

AI strategy

Common AI Opportunities in European B2B Companies

Sales & Revenue

Lead scoring: Predict which prospects will close and buy from whom. Accuracy: 70–85%. Impact: Sales team focuses on high-intent leads; close rates improve 20–30%.
Churn prediction: Identify at-risk customers 3–6 months before they leave. Proactive retention saves 5–15% of revenue.
Contract intelligence: Extract terms, obligations, and renewal dates from thousands of PDFs. Removes manual data entry; ensures compliance tracking.

Operations

Predictive maintenance: Sensors on equipment feed AI models. Predict failures days or weeks ahead. Prevent costly downtime; reduce spare parts inventory.
Demand forecasting: Better sales forecasts drive inventory, staffing, and capacity planning. 15–25% reduction in overstock and stockouts.
Supply chain optimization: Route optimization, supplier risk assessment, logistics cost reduction.

Finance & Compliance

Invoice & receipt processing: Optical character recognition (OCR) + AI extracts line items, amounts, vendors from thousands of documents. Accounting automation = faster close, fewer errors.
Expense categorization: Classify expenses to GL codes automatically. Compliance teams verify, but 70–80% need no human touch.
Regulatory intelligence: Monitor regulatory changes and flag relevant rules to legal/compliance teams. Reduces regulatory risk.

Customer Experience

Chatbots & virtual assistants: Handle 40–60% of customer questions without human agents. Reduces support costs; improves CSAT for simple queries.
Sentiment analysis: Analyze customer feedback (surveys, reviews, support tickets) to surface trends and at-risk customers.
Personalization: Recommend products, pricing, or content based on customer behavior and attributes.

HR & Talent

Resume screening: AI rank-orders candidates for manual review. Saves recruiting teams 20–30 hours per hire.
Skills gap analysis: Identify which teams lack critical skills; suggest training or hiring.
Attrition prediction: Flag flight risks among key talent; triggers retention conversations.

Most opportunities live in sales, finance, operations, and customer support. These are data-rich, repetitive, and have clear ROI.

Build vs. Buy: The Decision Matrix

You've identified an AI opportunity. Now: should you build the model in-house or buy a solution?

Factor
Build
Buy

Time to value
6–12 months
1–3 months

Customization
Unlimited
Limited to vendor options

Ongoing cost
€50K–200K/year (team)
€30K–150K/year (licensing + support)

Expertise needed
Data scientist, ML engineer, domain expert
Product manager + data analyst

Risk
High (model may not work; team churn)
Medium (vendor lock-in; feature limits)

Competitive advantage
Potentially high (proprietary model)
Low (competitors use same vendor)

Build if:

You have a truly unique competitive edge (e.g., proprietary data or process)
You already have a data science team
The problem is highly specific to your industry/business
Timeline is 6+ months (you can afford R&D)

Buy if:

You need a solution fast (under 3 months)
The problem is common (many vendors offer it)
You don't want to hire/retain data science staff
You want predictable costs (licensing vs. sunk R&D)

Hybrid (Recommended):
Start by buying a solution (faster validation, lower risk). As use cases mature and data accumulates, build internal models for differentiation.

Building an AI-Ready Organization

If you commit to AI, you need the right people and structure:

Core AI Team (for larger orgs or Build strategy)

AI/ML Engineer: Builds models, deploys to production, maintains pipelines. 1–2 people per 5 use cases.
Data Engineer: Collects, cleans, and structures data. Builds pipelines so AI has fresh, reliable input.
Analytics/Data Scientist: Defines metrics, validates model performance, explains results to business.
Data Governance Lead: Ensures data quality, privacy (GDPR), and bias monitoring.
Product Manager: Translates business problems into AI requirements; manages stakeholder expectations.

Organizational Structure

Centralized (Hub-and-Spoke)
One central AI team serves business units. Pros: economies of scale, consistent standards. Cons: slower, may miss local context.

Decentralized
Each business unit has its own AI team. Pros: fast, tailored solutions. Cons: duplicated effort, inconsistent quality.

Best practice for European B2B: Start centralized with a small "center of excellence" that builds capability and infrastructure. As the team matures, embed data scientists in business units for ownership and speed.

Budget Reality Check

Assume €150K–300K annually for a 3-person junior AI team (data engineer, junior ML engineer, analyst). Add infrastructure (cloud, tooling): €50K–100K/year. Add external consulting during build phase: €50K–200K upfront.

Total first-year AI investment: €250K–600K for one team supporting 3–5 initiatives.

Compare to potential ROI: A revenue-focused AI initiative (churn prediction, lead scoring) often pays back 2–5x in year one.

Services

Governance, Ethics, and Risk

AI in enterprise brings new risks that CFOs and compliance teams need to understand:

Data Privacy & Compliance

GDPR: Personal data used to train AI must comply with GDPR. Right to explanation: if AI denies credit, the person can ask why. You need audit trails.

EU AI Act: Coming in 2025. High-risk AI (used in hiring, credit, law enforcement) faces stricter rules: bias testing, human oversight, documentation.

Action: Audit your AI training data (is it all EU residents? is it representative?). Document model decisions. Have a compliance review before deployment.

Bias & Fairness

If your training data is biased, your AI inherits the bias. Classic example: recruiting AI trained on 10 years of male hires will discriminate against women.

Action:

Audit training data for demographic representation
Test model performance across demographic groups (ensure it's fair to all)
Document and monitor for bias post-deployment

Transparency & Explainability

Black-box AI is increasingly unacceptable in regulated industries and high-stakes decisions (hiring, credit, insurance). Regulators want to know: why did the AI decide X?

Action: Use explainable AI (XAI) techniques. For every important decision, be able to show which data points mattered most.

Cybersecurity & Model Robustness

AI models can be hacked. Adversarial attacks—tiny, crafted tweaks to input data—can fool models. A spam filter might be fooled by a single-character typo if not robust.

Action:

Validate models against adversarial examples
Monitor production models for performance drift
Maintain model version control and audit trails

Piloting AI: The Right Way

Here's how to run a successful AI pilot that answers the question: "Is this worth scaling?"

Define Success Upfront

Before starting, agree on metrics:

Business metric: Revenue increase, cost savings, customer satisfaction improvement (not accuracy)
Technical metric: Model accuracy, inference speed, false positive rate
Operational metric: User adoption, time saved per transaction, support tickets from users

Example: "Lead scoring AI will increase sales team productivity by 20% (more qualified conversations per day) and improve close rate by 10% within 6 months."

Run in Parallel, Not Sequential

Don't replace your current process immediately. Run the AI alongside manual decisions for 4–8 weeks. Compare: AI decided X, humans decided Y, what's the outcome?

This tells you:

Is the AI accurate in real production data?
Does it catch edge cases?
Do stakeholders trust it enough to use it?

Start with Your Best Data

Don't pilot on messy data. Take your highest-quality historical data (e.g., the 500 most complete CRM records). Pilot on this. Prove it works before scaling to messier, larger datasets.

Measure Continuously

Weekly dashboards of model accuracy, user feedback, and business impact. Catch problems early. If accuracy drops week 3, you debug week 3, not after 6 months in production.

Celebrate Wins, Then Plan Scaling

If the pilot shows positive ROI and user adoption, plan scaling: more use cases, more data, more users. But remember: each new use case is a new data challenge. Be methodical.

Red Flags: When NOT to Invest in AI

Not everything needs AI. Be skeptical if:

"AI will solve this, but we don't know why yet": You should always have a clear hypothesis about what AI will improve and by how much.
"We'll build it and iterate": If you don't have a skilled team, this often means burning cash with no ROI.
"Vendors promise 95% accuracy": Accuracy out-of-the-box is fiction. Real-world data is messy. Expect 70–85% for complex problems.
"We'll train AI on all our historical data": Old data can be biased or outdated. Quality > quantity.
"This AI will replace 50 people": Be realistic. AI augments and automates parts of jobs, not whole jobs. Manage change carefully.

FAQ

Q: How long until we see ROI from AI?
A: 12–18 months from start to meaningful ROI, if execution is good. Some quick wins (chatbots, simple automation) can show impact in 3–6 months. Budget conservatively.

Q: Do we need PhDs to build AI?
A: No. Most business AI doesn't require PhD-level research. You need solid engineers, domain knowledge, and good data. Hiring a junior data scientist + experienced engineer is often better than a PhD with no business context.

Q: Can AI be audited?
A: Yes. Model cards (documentation), validation reports, and decision logs are standard. For regulated industries, expect external audits.

Q: What if AI makes a bad decision and costs us money?
A: That's why you pilot and validate. And why humans remain in the loop for high-stakes decisions (hiring, lending, safety). AI is a decision support tool, not a replacement for accountability.

Q: How do we handle staff concerns about job loss?
A: Transparency and redeployment. Show that AI handles repetitive parts (form filling, initial screening). Humans focus on judgment, creativity, and relationships. Retrain staff for higher-value roles.

Q: Can we use our competitor's AI model instead of building our own?
A: You can buy commercial AI (SaaS), but it's the same model for everyone. The competitive advantage comes from your data, your process, and how you use it. Plan to build proprietary AI if this is core to your business.

Making Your First AI Move

You don't need a grand five-year AI strategy. Start small:

Pick one pain point where you lose time, money, or customers
Ask: Is it repetitive, data-rich, and complex? (Use the framework above)
If yes: Run a 2-month pilot with a vendor or consultant
Measure impact: Did it save time? Cost? Revenue?
Scale or iterate: Based on results, either expand or try a different problem

The companies winning with AI now aren't the ones with the biggest budgets or fanciest algorithms. They're the ones who started small, learned from pilots, and scaled what worked.

Digital Colliers helps European B2B leaders identify, pilot, and scale AI initiatives. We speak business language, not jargon. We've run 50+ AI projects across manufacturing, finance, logistics, and SaaS—and we know which patterns work and which fail.

Let's discuss your business. Schedule a 30-minute AI discovery call with one of our consultants. We'll identify your highest-ROI AI opportunity and walk you through what's realistic in your timeline and budget.

This article was originally published on the Digital Colliers Blog. Digital Colliers helps DACH and UK companies implement AI — see our AI consulting services or contact us.

1,300 AI-Fabrication Cases in Eleven Months. Your Filing Workflow Has a Gap

Digital Colliers — Mon, 20 Jul 2026 10:00:33 +0000

Written by: Wiktor Stefański, Head of People & Operations, Digital Colliers

The number that should be pinned above every legal drafting workstation right now: cases involving AI-fabricated citations rose from 87 to over 1,300 in the eleven months tracked in 2024. That is Stanford's Damien Charlotin count, and it is almost certainly an undercount, because it only captures the fabrications that got caught and made it into a written decision.

Read that curve as a leading indicator. Every one of those 1,300 was a filing that passed through some review process and still went out the door with a citation that pointed to nothing. The question for your firm is not whether your associates use AI. Most of them already do. The question is where in your workflow the fabrication check actually sits, and whether it sits there by design or by accident.

The check cannot live in the associate's head

The default state at most firms right now is that verification is implicit. The associate drafts with an AI assistant, glances at the citations, maybe pulls one or two, and passes it up. The partner assumes the associate checked. The associate assumes the tool got it right. Nobody owns the verification step, so nobody does it properly.

This breaks for three reasons:

Fabricated citations often look correct. Right court, plausible party names, a reporter volume that exists. You cannot spot them by reading.
Associates under billing pressure will not manually verify twenty citations. The ABA's Formal Opinion 512 already told us lawyers cannot bill hours that AI saved, which means the economic incentive is to move faster, not slower.
Partners reviewing drafts are pattern-matching on argument quality, not running Shepard's on every cite.

If the check depends on a human remembering to run it every time, the check will fail. The 1,300 cases are the evidence.

Where the check has to sit

The verification step needs to be a gate, not a habit. It should run automatically between drafting and any partner review, and it should refuse to let a document proceed until every citation resolves against a real database record.

Concretely, that means three things wired together:

The drafting tool (whatever your associates use, whether it is a legal-specific product or general-purpose) has to emit citations in a structured, machine-readable form, not just prose.
A validation layer sits between the draft and the review queue. It hits Westlaw, Lexis, Bailii, CanLII, or whatever your primary citation database is, and confirms each cite resolves and says what the draft claims it says.
The result gets logged into your case management system against the matter, so there is a durable record of what was verified, when, and by which version of which tool.

That third piece matters more than people expect. When a regulator or a court asks how the filing was produced, you want a timestamped record, not a reconstruction from memory. The UK Solicitors Regulation Authority put out its AI guidance in November 2023 and has been signalling for two years that firms are expected to have documented process control around AI use. That is not going to get looser.

The cost of leaving the gap open

The monetary cost of a sanction is the small part. The bigger costs stack behind it.

One reported fabrication in your firm's name becomes the first search result for that partner for years.
Insurance carriers are already pricing AI-related malpractice risk. Firms without documented verification workflows will pay more, or get non-renewed.
Clients, particularly institutional ones, are starting to ask about AI use in engagement questionnaires. "We rely on associate diligence" is not going to survive that question much longer.
Under EU AI Act Article 50 transparency obligations, which apply from 2 August 2026, certain AI-generated outputs need to be identifiable as such. Legal filings produced by firms operating in the EU will get pulled into that conversation whether the drafters want to be or not.

The firms that will look good in 2027 are the ones that treated citation verification as a plumbing problem in 2025. They bought or built the middleware. They wired the drafting tool to the citation database to the case management system. They made the check impossible to skip.

What to actually do this quarter

If you are reading this and you know your firm has the gap, the useful first move is small and diagnostic. Pick ten recent filings that involved AI-assisted drafting. Have someone verify every citation from scratch. Count the fabrications, the misquotes, and the cites that exist but do not support the proposition.

Whatever number you get is your baseline. If it is zero, your process is already working and you should document why. If it is not zero, you now know the size of the gap, and you can decide what to spend to close it before a court decides for you.

Sources

This article was originally published on the Digital Colliers Blog. Digital Colliers helps DACH and UK companies implement AI — see our AI consulting services or contact us.

The CISA GitHub Leak Is a Credential Inventory Problem

Digital Colliers — Mon, 20 Jul 2026 04:00:34 +0000

Written by: Karol Sobieraj, Founder & CEO, Digital Colliers

CISA's advisory this month landed with a thud, but the shape of it isn't new. A federal contractor's private GitHub repo leaked cloud access keys. The industry response was predictable: turn on secret scanning, rotate the exposed keys, move on. That misses the real problem. Most mid-market banks I talk to can't answer a simpler question. Where do our credentials live, who owns them, and how fast can we kill one.

That's not a scanning problem. That's an inventory problem. And in financial services, the cost of not solving it now is going up fast.

How the leaks actually happen

The GitHub story is one channel. The pattern underneath is boring and universal. A developer needs to test something against a staging bucket. They paste a key into a config file. The config file ends up in a repo, or a Slack thread, or a Jira ticket, or a laptop that gets reimaged six months later. The key is valid for a year. Nobody remembers it exists.

Multiply that across every engineer, every contractor, every CI job, every third-party SaaS integration your bank has stood up since 2019. You don't have a credential problem. You have a credential archaeology problem.

A few of the channels operators keep finding leaks in:

Public and private Git repos, including forks and old branches
CI/CD variable stores that outlived the pipeline
Postman collections and internal wikis
Vendor onboarding docs shared over email
Serverless environment variables from projects nobody owns anymore
Container images with baked-in tokens

Scanning helps with the first two. It does almost nothing for the rest.

Why scanning alone fails

Secret scanners are pattern matchers. They find things that look like keys inside places you told them to look. They can't tell you if the key is still active. They can't tell you who owns it. They can't tell you which production system will break when you rotate it. And they definitely can't tell you whether the key found in a public repo is the same key sitting inside your production Lambda.

That last part is where remediation stalls. A scanner tells you a key leaked. Nobody knows what depends on it. The security team files a ticket. The ticket sits for weeks while engineering figures out the blast radius. Meanwhile the clock on your regulatory exposure is running.

This is the same dynamic Verizon has documented on the CVE side. Only about 3 to 5% of publicly disclosed vulnerabilities get patched within 30 days. The gating factor isn't detection. It's the org's ability to act on what it already knows.

The cost of not fixing this in 2026

DORA has been in force since 17 January 2025. It's not a future problem. It requires financial entities in the EU to identify, classify and document all ICT assets, including the third-party ones. A credential is an ICT asset. If you can't produce the inventory on demand, you're already out of compliance, whether or not you've been asked yet.

GDPR sits on top of that. Fines reach up to €20M or 4% of global turnover. A leaked cloud key that gives an attacker read access to a customer data store isn't a security incident anymore. It's a notifiable breach, and the regulator's first question is going to be how long the key was live and why nobody rotated it. "We didn't know we had it" is not an answer that reduces the fine.

The cost of inaction here isn't hypothetical. It's the delta between rotating in hours and rotating in weeks, priced in regulatory exposure and customer trust.

The minimum data model to rotate in hours

You don't need a platform. You need a table. The banks that are getting this right are building something close to this, and querying it from a single place:

Credential ID and type (API key, OAuth token, service account, cert)
Issuing system and issue date
Expiry, if any
Owning team and named human backup
Systems that consume it, with confidence level
Last-used timestamp, pulled from the issuing system
Rotation runbook link

That's it. Seven fields. The hard part isn't the schema. It's the discipline to populate it, keep it current, and treat any credential that isn't in the table as an incident.

Operators who can query that table in one shot rotate in hours. Everyone else negotiates with their own git history while the regulator waits.

Sources

European Commission

This article was originally published on the Digital Colliers Blog. Digital Colliers helps DACH and UK companies implement AI — see our AI consulting services or contact us.

The EU Just Told Meta to Change the Feed. Your Ad Plan Should Assume It Happens

Digital Colliers — Sun, 19 Jul 2026 22:00:33 +0000

Written by: Nicole Ogonowska, IT Growth Manager, Digital Colliers

In July 2026 the European Commission issued a preliminary finding that Facebook and Instagram breach the Digital Services Act on addictive design. Autoplay and infinite scroll are named. If the finding holds, Meta either changes the surface where your ads live or pays DSA fines that scale with global turnover. Either outcome moves the price of attention. Your paid social forecast for the back half of 2026 probably assumes neither happens.

What actually changes if the feed changes

Start with the mechanic. Autoplay and infinite scroll are the reason a user sees ten ads in a session instead of two. Kill either one and impressions per session drop. Meta will not accept lower revenue per user quietly, so CPMs rise to defend inventory. CPMs for DTC advertisers were already climbing through 2024 and 2025, and customer acquisition cost across DTC brands is up roughly 40% since 2023. A forced UX change on top of that is not a small edit to the model. It is a reprice.

The knock-on for eCommerce operators is uncomfortable but predictable:

Prospecting campaigns get more expensive first, because cold audiences depend on volume of impressions.
Retargeting holds up longer, because it depends on intent not scroll depth.
Creative fatigue accelerates, because each impression has to work harder.
Attribution windows look worse, because the funnel gets shorter and choppier.

None of that is speculative. It is just what happens when you shrink the number of ads a user sees per session and keep advertiser demand constant.

The forecast most teams are running is already wrong

If your 2026 plan pencils in flat or improving blended CAC on Meta, ask what it assumes about the feed. Most media plans I see assume the surface is a constant. It is not. The DSA case is one input. The EU AI Act's Article 50 transparency obligations kick in on 2 August 2026 and touch generative ad creative. GDPR fines still reach up to €20M or 4% of global turnover, which shapes what data Meta will and won't let you use for lookalikes. Every one of these is a small squeeze on the machine you rent from Meta to find customers.

Meanwhile the demand side is soft. UK eCommerce grew around 3% in 2024 versus 2023, and single-digit growth is the new baseline. You cannot outgrow a CAC problem in a 3% market. You have to fix the unit economics, and roughly 30% of SKUs at a typical multi-channel brand already lose money per order once returns and ad spend are counted.

Own the model, don't rent it

The operators who look calm in this cycle are the ones who stopped treating Meta as the customer database. They treat it as a distribution channel with a shrinking half-life. Practically, that means a few things:

First-party data as the source of truth. Every order, every session, every return, joined to a customer ID you own. Not a Meta pixel event, not a GA session, a row in your warehouse.
Predicted LTV that runs on your data, not the platform's. If Meta is optimising bids on a 7-day purchase signal and you have a 12-month LTV curve, you bid smarter than the auction.
Retention economics that don't need paid social to work. Email, SMS, post-purchase, product bundling, returns reduction. Boring, and the reason some brands survive a CPM spike.
Channel diversification that is real, not a slide. Search, retail media, affiliate, organic. Each with its own creative pipeline.

The throughline is that your model of the customer lives on infrastructure you control. When Meta changes the feed, or the DSA forces the change, or the AI Act narrows what generative creative can claim, your acquisition math still works because the inputs are yours.

What to do this quarter

Run the forecast twice. Once with today's Meta CPMs and once with a 20 to 30% CPM increase and a shorter attribution window. If the second version breaks the P&L, you have a data problem, not a media problem. The teams that ship through 2026 are the ones treating the DSA finding as a scheduled event, not a surprise. The rest will find out in the quarterly review.

Sources

This article was originally published on the Digital Colliers Blog. Digital Colliers helps DACH and UK companies implement AI — see our AI consulting services or contact us.

The Interpol $293M Sweep Is a Data Model Wake-Up Call

Digital Colliers — Sun, 19 Jul 2026 16:00:33 +0000

Written by: Jakub Pietroszek, Partnership Manager, Digital Colliers

Interpol's HAECHI VI operation wrapped in July 2026 with 5,811 arrests and $293M seized across 97 countries. The rings they broke up did not care whether your victim opened a current account, a card, a loan, or a wallet. They exploited the seams between those products. Most mid-market banks still triage fraud one product at a time, on data that lands overnight. That gap is the whole story.

The product-by-product trap

If you sit in a fraud ops seat at a mid-market bank, you already know the shape of this. Card fraud sits in one tool. ACH and wire sit in another. Onboarding and KYC sit in a third. Each has its own analyst queue, its own case format, its own rules author. When a mule ring hits three of your products in the same week using overlapping devices, the alerts land in three different queues and nobody stitches them until someone files a SAR.

The cost of that fragmentation shows up in the false positive rate. Industry benchmarks put AML transaction-monitoring false positives at 85 to 95 percent at typical mid-market banks. That is not a modelling problem alone. It is a data problem. Rules fire on thin, single-product context because that is all the analyst sees at the moment of decision.

Why the nightly warehouse cannot save you

The standard answer is "we already have a data warehouse, everything lands in it." That is fine for reporting. It is not fine for fraud ops, for three reasons.

Latency. A card auth decision has roughly 200 to 500 milliseconds. An ACH hold decision has minutes. A nightly ETL job cannot see either.
Grain. Warehouses are shaped for accounting periods and product hierarchies. Fraud needs the entity as the grain, not the account.
Joinability. If your card table and your wire table do not share a stable customer or device key at write time, no amount of downstream SQL will invent one.

DORA has been in force across the EU since 17 January 2025 and it puts operational resilience on the board's plate. "We batch overnight" is a hard answer to defend when the regulator asks how you would spot a coordinated attack across payment rails in real time.

The minimum viable entity layer

Cross-product entity resolution sounds heavy. In practice, the operators shipping this in 2026 tend to start with a narrow, boring foundation. Not a rebuild. A layer.

The minimum join keys most teams need:

A stable internal party ID that survives product boundaries
A device fingerprint hash written on every session, not just logins
A normalised counterparty key for outbound payments, including IBAN, sort code plus account, and wallet address forms
A shared event timestamp in UTC with sub-second precision
A hashed identity bundle for KYC linkage without moving PII around

That is it for the first pass. Five keys, written at source, streamed into an entity store with sub-minute freshness. Rules and models query the entity, not the product table.

A worked example

Picture a mule network. Monday, they open six accounts through your mobile onboarding flow, all passing KYC individually. Tuesday, four of those accounts receive small card refunds from a merchant you also acquire. Wednesday, the funds consolidate through internal transfers into two of the six. Thursday morning, both push out via SEPA Instant to a payment institution abroad.

With product-siloed data and a nightly warehouse, each step looks clean in isolation. Onboarding sees six approvals. Acquiring sees six low-value refunds. Payments sees two outbound transfers under threshold. The pattern only appears on Friday, when someone runs a weekly report.

With an entity layer, the device fingerprint from onboarding links all six parties on Monday. The refund pattern on Tuesday raises the entity's risk score. The Wednesday consolidation trips a velocity rule at the entity grain. Thursday's outbound is held for review before it settles. Same rules engine. Different data shape.

What tends to go wrong

Around 95 percent of enterprise AI projects fail to reach production or ROI, and fraud modernisation projects fit the pattern. The failure mode is almost always the same: teams buy a model or a platform before fixing the data shape underneath it.

A few things worth watching if you are scoping this work:

Automated credit and risk decisioning already carries GDPR exposure under the SCHUFA ruling from December 2023. Entity-level scoring inherits that exposure. Get your DPO in the room early.
EU AI Act high-risk obligations apply from 2 December 2027. Fraud and creditworthiness systems sit inside that scope. The data lineage you build now becomes the audit trail you show later.
Do not start with the model. Start with the five join keys and the streaming path. The model is the last mile, not the first.

The Interpol sweep is a useful mirror. The people attacking your bank are already operating cross-product and in real time. The question is how long your data model stays in yesterday.

Sources

This article was originally published on the Digital Colliers Blog. Digital Colliers helps DACH and UK companies implement AI — see our AI consulting services or contact us.

The Ransomware Negotiator Case Should Change How You Log Vendor Access

Digital Colliers — Sun, 19 Jul 2026 10:00:34 +0000

Written by: Kamil Ponicki, Director of Talent Acquisition, Digital Colliers

The negotiator case is unusual in the headline but ordinary in the underlying control gap. A trusted third party held privileged access during an incident, and the bank's log trail treated that access as one undifferentiated blob of activity under a retainer contract. If your vendor-risk data model still looks like that, the conviction should worry you more than the ransom did.

This is a financial services problem specifically because DORA has been in force since 17 January 2025, and it puts ICT third-party risk squarely on the board. The regulator is going to ask who did what, on whose behalf, under which contractual purpose. If the answer requires a human to reconstruct it from Slack messages and a PDF SOW, you don't have a control. You have a story.

The negotiator case is a vendor-access logging failure

Strip out the drama and you have a straightforward pattern. A firm engaged a specialist under an incident response retainer. That specialist was granted elevated access to systems, wallets, or communications during a live event. The access was logged in the sense that the SIEM saw the sessions. It wasn't logged in the sense that anyone could later answer three questions:

Which contract authorised this session?
Which named human at the vendor performed the action?
What business purpose was this action tied to?

Most banks I talk to can answer question one at the retainer level, not the session level. Question two collapses to a shared service account. Question three lives in someone's inbox.

That's the left-behind risk. It sits in the gap between your vendor management system, your IAM, and your SIEM. Nobody owns the join.

SIEM alone doesn't tell you what happened

SIEM tools are good at what they do. They collect events, correlate them, and flag anomalies. What they don't do, out of the box, is tell you that the session at 02:14 UTC was performed by an incident response contractor under retainer number 4471, for the purpose of ransomware negotiation, with a scope that did not include wallet key access.

Without owner-and-purpose tags on every privileged session, your SIEM is producing evidence you can't cross-examine. When the regulator or a court asks whether the vendor exceeded scope, you need to show scope as data, not scope as prose in a signed PDF.

The patching numbers already tell you how fragile the vendor perimeter is. Only around 3 to 5 percent of publicly disclosed vulnerabilities get patched within 30 days. Your third parties are running that same lag against you. If a compromised vendor session is the entry point, you want the forensic answer to be a query, not a war room.

The joins you actually need

At minimum, a defensible vendor access trail joins four things:

The contract or SOW record, with a scope-of-work field that is machine readable, not a blob of legal text.
The named individual at the vendor, tied to a per-human credential, not a shared account.
The session log from the target system, with the credential ID as a foreign key.
A purpose tag, set at session start, that pins the activity to a specific engagement or ticket.

Build those four joins and a lot of downstream problems get cheaper. Your DORA register queries stop being a quarterly fire drill. Your GDPR exposure gets easier to bound, which matters when fines run up to 20 million euros or 4 percent of global turnover. The SCHUFA ruling has already shown how aggressively courts will read data processing scope in financial contexts, and vendor access is processing.

What operators shipping this in 2026 tend to do

The pattern I keep seeing at firms that get this right is boring, and that's the point. They treat vendor identity as a first-class data model, not an afterthought bolted onto procurement. Every privileged session carries an owner, a purpose, and a contract reference before the session starts, enforced at the access broker.

The engineering effort is real but bounded. It's mostly schema, plumbing, and a few well-placed guardrails on the IAM side. The hard part isn't the code. It's getting procurement, security, and the ICT third-party function to agree that a retainer is not a single line in a spreadsheet.

Sources

This article was originally published on the Digital Colliers Blog. Digital Colliers helps DACH and UK companies implement AI — see our AI consulting services or contact us.

What a DSA-Forced Meta Feed Change Would Do to Your Q4 Forecast

Digital Colliers — Sun, 19 Jul 2026 04:00:33 +0000

Written by: Michał Sobieraj, Operations Manager, Digital Colliers

The Commission's preliminary finding that Facebook and Instagram breach the DSA on addictive design is the sort of ruling that sits quietly in a legal update email for a week, then rewrites your media plan. If Meta is forced to change how the feed ranks and serves content, the mechanics your paid social forecast is built on stop being reliable. Not in a catastrophic way. In a slow, margin-eroding way that shows up in Q4 when you can least afford it.

Here is how I'd think about modelling it, and what the operators who move first are actually doing.

What actually changes if the feed gets re-shaped

The DSA remedies on the table are not about ad inventory directly. They target session length, autoplay, infinite scroll, recommender opacity. But every one of those knobs feeds impression supply. Less time in feed means fewer ad slots served. Fewer ad slots at flat demand means CPM pressure. Meta ad CPMs for DTC advertisers already rose year over year through 2024 and 2025, and customer acquisition cost across DTC has climbed roughly 40% since 2023. You're not modelling from a comfortable baseline. You're modelling from a base that's already stretched.

Three scenarios worth putting numbers against:

Mild: reduced session time, 5-10% drop in impression supply, CPMs up mid-single-digits, retargeting windows shorter because return visits per user fall.
Moderate: algorithmic reranking to reduce engagement optimisation, retargeting reach down 15-25%, prospecting audiences less predictive, ROAS on cold traffic drops before you notice it in weekly reports.
Severe: structural changes to recommender defaults, opt-in required for engagement-optimised feed, lookalike quality degrades, and your existing creative testing cadence stops producing winners at the rate it used to.

None of these are certain. But your FY paid social forecast almost certainly assumes none of them happen. That's the exposure.

Why single-channel forecasts break in this environment

UK eCommerce grew about 3% in 2024 versus 2023. Single-digit growth is the baseline now, which means you cannot absorb a 10-15% efficiency hit on your largest paid channel by growing your way out. And roughly 30% of SKUs at a typical multi-channel brand already lose money per order once returns and ad spend are counted. A CPM shock pushes more SKUs into that bucket without anyone at the weekly trading meeting noticing until the quarter closes.

The brands I see handling this well are not the ones with the biggest budgets. They're the ones who can move spend between channels in days, not months, and still trust their attribution. That capability is not a media agency deliverable. It's a data problem.

The left-behind pattern

The operators who'll struggle share a shape. Paid social is run out of one system, email and SMS out of another, Google out of a third, and the customer database is a Shopify export that someone reconciles on a Monday. When Meta efficiency drops, they can't credibly shift 20% of Meta budget into email and SMS because they don't know which customers are already saturated on those channels. They can't push into Google non-brand because their audience exclusions live in Meta and nowhere else. So they keep spending on Meta at worse economics, because it's the only channel they can actually operate at pace.

The fast movers look different:

One customer table that every channel writes to and reads from.
Suppression, frequency and value segments computed centrally, not per platform.
Attribution that survives a channel mix change, usually incrementality-tested rather than last-click.
Creative and offer testing decoupled from any single ad platform's UI.

None of that is glamorous. It's plumbing. But it's the plumbing that lets you respond to a regulatory shift in weeks instead of quarters.

What to do in the next 60 days

You don't need to rebuild your stack before Q4. You need to know where you'd move money if you had to, and whether your data can support that move. A few concrete checks worth running:

Model the moderate scenario against your current Q4 plan. What's the profit hit if Meta CPMs move up 15% and retargeting reach drops 20%?
Audit whether your email and SMS platforms have a live view of paid social exposure per customer. If not, that's the first gap to close.
Pressure-test your Google non-brand headroom. Most brands have more than they think, but only if audience data is portable.
Decide now which SKUs you'd pull from paid social first if unit economics slip. Don't decide that in November.

The DSA ruling might get watered down. Meta might appeal for years. But your forecast shouldn't need the ruling to disappear in order to hold. The teams treating this as a data readiness question, not a media question, are the ones who'll still hit their number.

Sources

This article was originally published on the Digital Colliers Blog. Digital Colliers helps DACH and UK companies implement AI — see our AI consulting services or contact us.

When a Cyber-Resilience Vendor Spends $500M In Your Market, Read the Signal

Digital Colliers — Sat, 18 Jul 2026 22:00:33 +0000

Written by: Luke Sobieraj, Founder & COO, Digital Colliers

When a vendor puts half a billion dollars into your market and builds its European HQ in your capital, that's a bet on a gap. Rubrik isn't betting UK banks and asset managers are ready. They're betting the opposite. They're betting the middle of the market has a data-resilience story that falls apart the first time a regulator or an attacker actually pulls on it.

If you run engineering or operations at a mid-market financial firm, the question isn't whether that bet is smart. It's whether you're the trade.

What data-layer resilience actually means

Most boards hear "cyber resilience" and picture firewalls, EDR, maybe a SOC contract. That's perimeter. Data-layer resilience is different. It's the answer to a much colder question: when your production data is encrypted, corrupted, or quietly poisoned, how fast can you bring the business back, and to what point in time?

Four things matter here, and you should be able to state each one in a sentence:

RTO (Recovery Time Objective). How long from incident to operational. Hours? Days? Be specific per system.
RPO (Recovery Point Objective). How much data you're willing to lose. Fifteen minutes of trades is not the same as fifteen minutes of HR records.
Immutable copies. Backups an attacker with domain admin cannot delete or encrypt. If your backups sit on the same AD trust as production, they're not immutable.
Tested restores. Not "we have backups." Not "we ran a tabletop." A restore drill, on real data, on the clock, with the runbook the on-call actually has.

DORA has been in force since 17 January 2025, and the ICT resilience testing expectations under it are not satisfied by a policy document. They're satisfied by evidence that you've done the restore.

The resilience gap is a data-integration gap

Here's the part vendors don't lead with. The reason mid-market firms fail restore drills isn't backup software. It's that nobody knows where the data lives, who owns it, or which system is the source of truth.

You can see the same pathology in the finance function. Most mid-market finance teams still run month-end close in spreadsheets, pulling numbers across systems by hand. Month-end at the median firm runs 8 to 10 days, while the strongest teams close in under 5. The gap between those two isn't effort. It's data integration. The winners have a single, governed layer where the numbers reconcile automatically. The rest are copy-pasting.

Cyber resilience runs on the same physics. If your customer master lives in three CRMs, your positions live in two OMS instances, and your KYC evidence lives partly in SharePoint and partly in someone's inbox, you don't have a recovery plan. You have a scavenger hunt with a stopwatch on it. Immutable snapshots of a mess restore a mess.

What mid-market firms should be measuring this quarter

If you want to know whether you're the trade Rubrik is pricing, run these checks before end of quarter. None of them require a vendor.

Named RTO and RPO for your top 10 systems. Written down, agreed by the business owner, not aspirational.
Last successful full restore date, per system. Not last backup. Last restore.
Backup blast radius. If a domain admin account is compromised at 2am, can that account reach and destroy the backups? Yes or no.
Data lineage for your top 3 regulatory reports. Source system, transformation, destination. If you can't draw it on one page, you can't defend it.
Patch latency on internet-facing assets. Industry data suggests only 3 to 5 percent of disclosed vulnerabilities are patched within 30 days. Where do you sit against that.
GDPR exposure on the restore path. Fines run up to 20 million euros or 4 percent of global turnover. A recovery that re-materialises data you were meant to have deleted is its own incident.

The left-behind risk

The operators who come out of the next 24 months intact aren't the ones who buy the most tooling. They're the ones who treated data-layer resilience as an engineering problem and did the unglamorous integration work. They know where the data is. They know what "good" restoration looks like. They've timed it.

The firms that get left behind are the ones that read Rubrik's UK announcement as a procurement story. It isn't. It's a signal about which side of a gap you're on. The vendors have already placed their bet. Your quarter is the answer.

Sources

This article was originally published on the Digital Colliers Blog. Digital Colliers helps DACH and UK companies implement AI — see our AI consulting services or contact us.

When Your Core Software Vendor Becomes an M&A Target, Your Data Model Matters

Digital Colliers — Sat, 18 Jul 2026 16:00:33 +0000

Written by: Agata Wojtas, Chief Commercial Officer, Digital Colliers

Elliott building a stake in CCC and pushing for a sale isn't just a Wall Street story. If you're an insurer running quotes, claims, or subrogation through a single core platform, the ownership of that platform is now your problem. A new owner will retest every discount, every custom integration, and every renewal. If your data lives inside their schema and nowhere else, you don't have a negotiation. You have a bill.

This is the left-behind risk nobody prices in until it arrives. And it arrives fast, usually 6 to 12 months after the deal closes, when the new commercial team gets its number.

What most insurer contracts actually say about your data

Read your master agreement with your core vendor. Most of the ones I've seen contain some version of three clauses that look reasonable and are not.

Data export is available "in the vendor's standard format" (which usually means a flat CSV dump, not the relational model you actually run on).
Historical claim notes, adjuster workflow states, and audit trails are described as "platform metadata" and excluded from the export.
Exit assistance is capped at 30 or 60 days, billed at time and materials, and gated on you being current on fees.

None of that gets you out. It gets you a pile of CSVs and a lawsuit. Under DORA, which has been in force since 17 January 2025, financial entities are already expected to manage ICT third-party risk with exit strategies that are actually testable. "We'll dump CSVs" is not a testable exit strategy.

The mirrored warehouse move

The operators who sleep through vendor M&A drama have done one specific thing. They keep a continuous, mirrored copy of their own data in a warehouse they control. Snowflake, BigQuery, Databricks, Postgres on their own cloud account, pick one. The vendor's platform is the system of record for operations. The warehouse is the system of record for the business.

The pattern looks like this:

Nightly or streaming replication of every table you touch, including the join tables and status enums.
A documented schema on your side, owned by your data team, not the vendor's PS org.
Analytics, pricing models, and regulatory reporting run off the warehouse, not the vendor UI.

The negotiating power this buys is not subtle. When the new owner comes in with a 40% price increase, you can credibly say you're 90 days from switching. The ones without a mirror say the same thing and everyone in the room knows it isn't true.

Export terms to require, in writing

If you're renewing in the next 18 months, or negotiating a new core, these are the clauses to fight for. Not nice-to-haves. Signature-blockers.

Continuous read access to the full relational model, not a nightly export. API or direct replica, your choice.
Schema documentation kept current, with 90 days notice on breaking changes and a contractual right to reject them.
All derived data included: adjuster notes, workflow states, decision audit logs, model scores, override reasons.
Portability of any AI or scoring outputs the vendor generates on your book. Under the SCHUFA ruling (C-634/21, December 2023), automated scoring on your customers carries your GDPR exposure, not theirs, and GDPR fines run up to €20M or 4% of global turnover.
Exit assistance measured in months, not days, with a fixed fee schedule agreed up front.
A tested exit runbook, executed annually, with evidence retained. DORA examiners are going to ask.

The AI Act clock is also ticking

Most core insurance platforms are quietly shipping more automated decisioning every quarter. Pricing suggestions, fraud flags, claim triage. Under the EU AI Act, high-risk obligations apply from 2 December 2027, with fines up to €15M or 3% of global turnover for high-risk violations. If your vendor's model is deciding who gets a policy or a payout, the regulator is going to want to see your documentation, not theirs.

You can't produce that documentation from a CSV dump six months after a hostile exit. You produce it from a warehouse you already own, populated with data you already have, governed by contracts you already signed.

The M&A story is the forcing function. The data model is the actual work.

Sources

This article was originally published on the Digital Colliers Blog. Digital Colliers helps DACH and UK companies implement AI — see our AI consulting services or contact us.

You Cannot Enforce a £150 Threshold on Data You Have Not Joined

Digital Colliers — Sat, 18 Jul 2026 10:00:35 +0000

Written by: Kacper Osiewalski, Lead Backend Engineer, Digital Colliers

The UK affordability trigger sits at £150 net deposits per rolling 30 days. That's the number your risk team is measured against, and it's the number the Gambling Commission expects you to see in something close to real time. The problem isn't the rule. The problem is that most operators can't compute the input.

The threshold is a join, not a number

Net deposits per rolling 30 days sounds like a single figure. In practice it's a windowed sum over every deposit, minus every withdrawal, per player identity, across every product they touch. If a player deposits £80 into the sportsbook wallet on day one, £40 into casino on day fourteen, and £50 into poker on day twenty-eight, you're already at £170. None of your product teams see it. Your payments team sees three separate authorisations to three separate merchant descriptors.

The RCI guidance that came into force in August 2022 and expanded in 2024 assumes you can answer questions like this on demand. The regulator is not interested in why your data model makes it hard.

Where the silos actually sit

If you've grown by acquisition, or you white-label a vertical, the shape is familiar. You end up with something like this:

Sportsbook on one platform, with its own wallet and its own player ID.
Casino on a second platform, often a third-party RGS, with a different player ID mapped by an internal service.
Poker on a third stack, frequently the oldest and least loved.
Payments as a fourth system, with PSP-level records that don't cleanly map to product wallets.
KYC and CRM as fifth and sixth, holding the golden customer record that nobody fully trusts.

Each system has its own definition of a deposit. Some count the authorisation, some count settlement, some count the wallet credit. Refunds, chargebacks, bonus conversions and inter-wallet transfers all muddy the number. You can compute net deposits inside any one product in an afternoon. Computing it across all of them, per player, on a rolling window, in minutes rather than days, is a serious data engineering problem.

Why batch ETL won't save you

The pattern I keep seeing is a nightly job that stitches product data into a warehouse, a BI dashboard for compliance, and a manual review queue the next morning. That worked when the regulator was asking annual questions. It does not work when the threshold is a rolling 30-day window and interventions are expected before harm accrues.

Around one in four UK-licensed operators fails to achieve a satisfactory AML rating on first assessment. When you read the public enforcement notices, the same phrases keep appearing: the operator did not identify the trigger in time, the operator relied on a monthly review, the operator's systems did not aggregate across brands. That is not a policy failure. That is a data pipeline failure with a policy label on it.

The cost of getting it wrong is not abstract. UK penalties for the most serious AML breaches reach up to 15% of gross gaming yield. Kindred publicly reported £14M in compliance-team cost in 2023, and that is the price of doing it reasonably well, not the price of getting it wrong.

What the joined player view actually needs

If you're planning this work for 2026, the shape of the build is roughly:

A canonical player identity service that maps every product-level ID to one person, including historic aliases from acquired brands.
A streaming event bus where every deposit, withdrawal, bonus, refund and transfer lands within seconds, tagged with product, wallet, and PSP reference.
A materialised rolling-window aggregate per player, keyed on that canonical ID, refreshed on every event rather than nightly.
A rules layer that fires interventions when the aggregate crosses £150, or the earlier internal thresholds most operators set below it.
An audit trail that lets you show the regulator, on request, exactly what you knew about a player at any given minute.

None of the individual pieces are exotic. Kafka or Kinesis, a warehouse with streaming ingestion, a feature store, a rules engine. The hard part is the identity resolution and the definitional work: agreeing, across product owners who each think their number is right, what a deposit is.

The cost of leaving it

Every month you run without a joined view, you're accepting two risks. The first is regulatory: an intervention you failed to make becomes evidence in an enforcement case. The second is commercial: your responsible gambling team spends its day running SQL by hand instead of talking to players who need the conversation. Neither risk shows up on a roadmap until it shows up in a public notice.

The £150 threshold isn't going away, and it isn't going up. The operators who'll be comfortable in 2026 are the ones treating the joined player view as core infrastructure, not a compliance side project.

Sources

This article was originally published on the Digital Colliers Blog. Digital Colliers helps DACH and UK companies implement AI — see our AI consulting services or contact us.