DEV Community: Peter

How to Scrape 620,000 Austrian Businesses from WKO Firmen A-Z (Official Chamber of Commerce Directory)

Peter — Tue, 28 Apr 2026 13:09:42 +0000

How to Scrape 620,000 Austrian Businesses from WKO Firmen A-Z (Official Chamber of Commerce Directory)

If you are building a B2B lead generation pipeline for the DACH market, you need Austrian company data. And the best source is hiding in plain sight: the WKO Firmen A-Z directory, maintained by the Austrian Chamber of Commerce itself.

620,000+ businesses. Phone numbers. Email addresses. Websites. Industry classifications. All official. And until recently, no programmatic way to access any of it.

Here is how to scrape it.

What is WKO Firmen A-Z?

The Wirtschaftskammer Osterreich (WKO) is Austria's Chamber of Commerce. Every legally operating business in Austria is registered there. Their public directory, Firmen A-Z, lets anyone search for Austrian companies and view:

Company name and legal form
Physical address and Bundesland (state)
Phone number and email
Website URL
Industry classification (WKO Fachgruppe)
Trade licenses (Gewerbeberechtigungen)

This is not some scraped third-party database. It is the official government-affiliated register. The data quality is as high as it gets.

The catch? WKO never built an API. The directory runs on an ASP.NET WebForms site that loads results dynamically via JavaScript. If you have ever tried to scrape a WebForms site with plain HTTP requests, you know the pain.

The problem: no API, and WebForms makes it worse

Most business registries at least offer a search portal. WKO does too, but:

No public API exists (confirmed - no REST, no GraphQL, nothing)
The site uses ASP.NET WebForms with JS-loaded search results
ViewState and event validation tokens make direct HTTP scraping unreliable
Pagination requires maintaining session state

You can search manually at firmen.wko.at. But if you need 1,000 Austrian companies for a sales campaign, you are looking at days of manual copy-paste.

The solution: Apify WKO Business Directory Scraper

The Austria WKO Business Directory Scraper handles all of this automatically. It uses headless browser automation (Puppeteer with StealthPlugin) to navigate the WebForms site, execute searches, paginate through results, and return structured JSON.

Here is what a basic run looks like in Node.js:

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: 'YOUR_APIFY_TOKEN' });

const run = await client.actor('regdata/wko-business-directory-scraper').call({
    searchQuery: 'softwareentwicklung',
    maxResults: 100
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
console.log(`Scraped ${items.length} Austrian businesses`);

And in Python:

from apify_client import ApifyClient

client = ApifyClient(token="YOUR_APIFY_TOKEN")

run = client.actor("regdata/wko-business-directory-scraper").call(
    run_input={
        "searchQuery": "softwareentwicklung",
        "maxResults": 100
    }
)

items = client.dataset(run["defaultDatasetId"]).list_items().items
print(f"Scraped {len(items)} Austrian businesses")

What the output looks like

Each result comes back as clean JSON:

{
    "companyName": "ExampleTech GmbH",
    "address": "Mariahilfer Strasse 123/45",
    "postalCode": "1060",
    "city": "Wien",
    "bundesland": "Wien",
    "phone": "+43 1 234 56 78",
    "email": "office@exampletech.at",
    "website": "https://www.exampletech.at",
    "industry": "Dienstleistungen in der automatischen Datenverarbeitung...",
    "tradeLicenses": ["IT-Dienstleistung"],
    "url": "https://firmen.wko.at/exampletech-gmbh/wien/..."
}

Phone, email, and website - the three things that actually matter for B2B outreach. Most business directories in Europe do not expose email addresses. WKO does. That is rare.

Real use case: SaaS company entering the Austrian market

Imagine you run a German SaaS company selling HR software. You have proven product-market fit in Germany and Switzerland. Austria is the natural next step in your DACH expansion.

You need Austrian companies with 50+ employees to target. Here is the workflow:

Search WKO by industry: "Personalberatung" (HR consulting), "Softwareentwicklung" (software development), "Unternehmensberatung" (management consulting) - target the companies that already buy HR services.
Extract with the actor: Run searches for each term, get structured contact data for every matching business.
Enrich with Firmenbuch data: Optionally cross-reference against Austria's commercial register (Firmenbuch) for company size, founding date, and legal status.
Load into your CRM: Export the JSON to HubSpot, Salesforce, or a simple CSV for cold outreach.

The whole pipeline runs in minutes instead of days. And because the data comes from the official Chamber of Commerce, it is more reliable than any purchased lead list.

How it compares to alternatives

There is one other WKO scraper on Apify: scrapyspider's firmen-wko-at-scraper. It is free but reports a ~50% success rate. The WebForms site is genuinely hard to scrape reliably.

Our actor uses:

Puppeteer with StealthPlugin for anti-detection
Proper session state management for pagination
Comprehensive fallback logic for missing fields
Validated against 620,000+ business listings

No residential proxy required. Unlike the Spain and France actors in our suite (which hit WAF-protected government portals), the WKO directory is accessible from standard datacenter IPs. Free tier users can run this with a slightly higher memory setting (512MB instead of the default 256MB).

Pricing transparency

Tier	Price per result
Free	$0.003
GOLD+ (paid Apify plan)	$0.002

Plus a one-time actor start fee of $0.025 per run.

To scrape 1,000 Austrian software companies: ~$3.03 on the free tier. Compare that to buying a DACH lead list from a data broker (typically $200-500 for 1,000 contacts of questionable freshness).

Technical requirements

Memory: 512MB recommended (WebForms + Puppeteer need headroom)
Proxy: Not required (standard datacenter IPs work fine)
Runtime: ~2-3 seconds per result page (~10 businesses per page)
Rate limiting: Built-in delays to respect WKO's servers

What you cannot scrape

WKO Firmen A-Z is a business directory, not a corporate registry. It does NOT contain:

Financial statements or revenue data
Ownership structure or shareholders
Company registration number (FN - Firmenbuchnummer)
Founding date

For those, you need Austria's Firmenbuch (commercial register) or paid services like KSV1870. Our actor gives you the top-of-funnel contact data that powers B2B prospecting. For deeper due diligence, pair it with our Austria Ediktsdatei Insolvency Scraper to screen for bankruptcy risk.

Quick start

Sign up for a free Apify account
Go to the WKO Business Directory Scraper
Click "Try for free" and enter a search query (e.g., "steuerberatung" for tax consultants)
Get your results in the dataset tab

The free tier gives you $5/month in platform credits, which is enough for ~1,600 results on the free pricing plan. Plenty to validate whether the data fits your pipeline before committing.

Bottom line

Austria has 620,000+ registered businesses with verified contact data sitting in a government-affiliated directory that has no API. The WKO scraper turns that directory into a structured data source you can query programmatically. No manual searches. No stale lead lists. Just official data, when you need it, in your pipeline.

If you are working with Austrian companies for credit risk or compliance purposes, check out our Austria Ediktsdatei Insolvency Scraper - it monitors Austria's official insolvency gazette and runs on free-tier-friendly infrastructure with no proxy required.

Automating Polish UBO Checks: How to Query CRBR Without an Official API

Peter — Tue, 28 Apr 2026 11:36:17 +0000

Automating Polish UBO Checks: How to Query CRBR Without an Official API

If you build AML/KYC pipelines for European markets, you've probably hit this wall: Poland's Central Register of Beneficial Owners (CRBR) has no public API. No REST endpoint. No SOAP service. Not even an FTP dump.

Yet Polish law requires obligated institutions - banks, fintechs, law firms, crypto exchanges - to verify beneficial owners for every business relationship. And with the EU's 6th Anti-Money Laundering Directive tightening UBO verification requirements across all member states, manual lookups don't scale.

Here's how to automate CRBR queries programmatically.

What CRBR Actually Contains

CRBR (Centralny Rejestr Beneficjentow Rzeczywistych), operated by Poland's Ministry of Finance at crbr.podatki.gov.pl, holds structured UBO data for Polish-registered entities:

Beneficial owner names (natural persons with >25% ownership or control)
Citizenship and country of residence
Nature of control (direct shareholding, indirect control, senior management)
Ownership percentage range
Company identifiers (NIP, KRS number, legal form)
Declaration compliance status

The registry covers general partnerships, limited partnerships, limited joint-stock partnerships, joint-stock companies, and limited liability companies. Civil law partnerships and sole proprietorships are exempt.

Filing is mandatory within 7 days of company registration, with penalties up to 1 million PLN (~220,000 EUR) for non-compliance.

The Manual Approach (and Why It Breaks)

The official portal lets you search by NIP (Polish tax ID) or KRS number. You type in an identifier, solve a CAPTCHA, and get one result. For a single due diligence check, that's fine.

For a fintech onboarding 50 businesses per day? That's two hours of manual lookups. For a bank running periodic reviews on 5,000 corporate accounts? That's a team of people doing nothing but CRBR searches.

And under AMLD6, obligated institutions must update UBO data actively - not just at onboarding but continuously throughout the business relationship.

Three Ways to Access CRBR Data at Scale

Option 1: MGBI Subscription (~200-500 PLN/month)

MGBI is Poland's dominant legal information provider. Their subscription gives you access to CRBR alongside other registries (KRS, KRZ, MSiG).

The downside: you're paying a flat monthly fee regardless of query volume. If you only need 20 UBO checks per month, you're overpaying. If you need 5,000, the subscription tiers get expensive fast.

Option 2: Build Your Own Scraper

CRBR's web portal uses standard HTTP with some session management (CSRF tokens, ASP.NET viewstate). Technically, you could build a scraper that:

Requests the search page, extracts the CSRF/verification token
POSTs a search with NIP/KRS
Parses the HTML result table for UBO data

The challenge: CRBR's anti-automation measures, CAPTCHA requirements, and the Ministry's willingness to change the portal structure without notice. Maintaining a scraper against a government portal that can change its HTML structure at any time is an ongoing engineering cost.

Option 3: Use the Apify CRBR Actor (Pay-Per-Result)

CRBR Beneficial Owners Scraper on Apify Store provides a maintained, API-accessible wrapper around the CRBR portal:

Pricing:

$0.03 per result on the Free plan
$0.02 per result on GOLD+
$0.025 actor start fee

For context: 100 UBO checks cost $3.00-$3.25. 1,000 checks cost $20-$30. No subscription, no minimum.

Input format:

{
  "searchQueries": [
    { "nip": "5252002340" },
    { "krs": "0000016702" }
  ],
  "proxyConfiguration": { "useApifyProxy": false }
}

Output for a single company:

{
  "query": { "nip": "5252002340" },
  "company": {
    "name": "EXAMPLE SP Z O O",
    "nip": "5252002340",
    "krs": "0000016702",
    "legalForm": "SP Z O O",
    "declarationStatus": "Zgloszono"
  },
  "beneficialOwners": [
    {
      "fullName": "JAN KOWALSKI",
      "citizenship": "Polska",
      "residenceCountry": "Polska",
      "controlNature": "Wlasciciel bezposredni",
      "ownershipPercentage": "Powyzej 50%",
      "isAlsoSeniorManagement": false
    }
  ]
}

Integration via Apify API:

import requests

APIFY_TOKEN = "your-token-here"
ACTOR_ID = "wOcPC7vYzfCkB62pG"

# Start a run
resp = requests.post(
    f"https://api.apify.com/v2/acts/{ACTOR_ID}/runs",
    params={"token": APIFY_TOKEN},
    json={
        "searchQueries": [
            {"nip": "5252002340"},
            {"nip": "5272520115"}
        ]
    }
)
run_id = resp.json()["data"]["id"]

# Poll for results
import time
while True:
    status = requests.get(
        f"https://api.apify.com/v2/acts/{ACTOR_ID}/runs/{run_id}",
        params={"token": APIFY_TOKEN}
    ).json()["data"]["status"]
    if status == "SUCCEEDED":
        break
    time.sleep(5)

# Fetch results
results = requests.get(
    f"https://api.apify.com/v2/acts/{ACTOR_ID}/runs/{run_id}/dataset/items",
    params={"token": APIFY_TOKEN}
).json()

for r in results:
    for bo in r.get("beneficialOwners", []):
        print(f"{r['company']['name']}: {bo['fullName']} ({bo['controlNature']})")

How It Compares

Factor	Manual Portal	MGBI	Apify CRBR Actor
Cost	Free	200-500 PLN/mo	$0.03/result
Scale	1 at a time	Bulk (subscription)	API-driven, any volume
Integration	None	Limited	REST API, webhooks, datasets
UBO detail	Full	Full	Full
Maintenance	None	Vendor-managed	Actor-maintained

Real Use Cases

Fintech KYC pipeline: A payment institution in Warsaw runs CRBR checks automatically during onboarding. New company applies -> system queries CRBR by NIP -> UBO data feeds into the risk scoring model. Zero manual intervention.

Periodic review automation: A bank's compliance team runs batch CRBR checks quarterly on its entire corporate portfolio. Any change in UBO structure triggers a review workflow. The alternative - assigning analysts to manually re-check every account - doesn't scale past a few hundred entities.

Cross-border due diligence: An international M&A advisory firm needs UBO data on Polish acquisition targets. Instead of relying on self-reported ownership structures, they pull CRBR data directly for verification.

What CRBR Won't Tell You

Important caveat: under AMLD5/6, institutions cannot rely solely on beneficial ownership registers. CRBR shows registered UBOs, but:

Registration gaps exist (not all entities file on time)
Complex multi-tier ownership structures may obscure true UBOs
CRBR data reflects declarations, not verified facts

CRBR automation should feed into - not replace - your broader risk-based KYC approach. Corroborate register data with client-provided information, and flag discrepancies.

Bottom Line

Poland's CRBR is an essential data source for any AML/KYC pipeline covering Polish entities. The lack of an official API is a real obstacle - but not an insurmountable one.

Whether you build your own scraper (engineering cost), subscribe to MGBI (fixed monthly cost), or use pay-per-result automation (variable cost), the key decision factor is your query volume and integration requirements.

For most teams building compliance automation: start with pay-per-result, measure your actual volume for 2-3 months, then decide if a subscription makes more financial sense.

The CRBR Beneficial Owners Scraper is part of the European Business Data Suite - 14 actors covering Polish, Spanish, Austrian, and French government registries, all pay-per-result with no subscription.

European Compliance Scraper Reliability: BORME and Societe.com Configuration Guide

Peter — Mon, 27 Apr 2026 10:08:32 +0000

Fixing BORME and Societe.com Reliability Issues: A Practical Guide for European Compliance

European Business Data Suite reliability is crucial for compliance workflows. After analyzing our run logs, we've identified specific patterns that cause failures with BORME Corporate Acts and Societe.com scrapers. This guide helps you configure these tools correctly and avoid common pitfalls.

The Reliability Challenge

Our latest metrics show these patterns that impact your compliance automation:

BORME: 68.8% success rate (11 successful, 5 aborted out of 16 runs)
Societe.com: 81.2% success rate (13 successful, 2 timeouts, 1 aborted out of 16 runs)
Common issue: Both actors fail due to configuration problems, not technical bugs

The good news? When configured correctly, both scrapers achieve 100% success rates on valid inputs.

BORME Corporate Acts Scraper: Configuration Guide

Common Failure Patterns

Input validation errors (3 out of 5 aborted runs)
Proxy connection issues (1 out of 5 aborted runs)
Timeout on large date ranges (1 out of 5 aborted runs)

Correct Configuration

Step 1: Input Validation

BORME requires specific input format. Invalid inputs cause immediate abortion:

{
  "startDate": "2024-01-01",
  "endDate": "2024-01-31",
  "companyName": "",
  "documentType": "Todos"
}

Critical rules:

Use YYYY-MM-DD format for dates
Include empty string "" for companyName when not filtering
Use "Todos" for documentType to get all corporate acts

Step 2: Proxy Requirements

Spanish government portals require residential proxies for reliable access:

# Example configuration
{
  "proxy": {
    "useApifyProxy": true,
    "apifyProxyGroups": ["RESIDENTIAL"]
  }
}

Step 3: Optimize Date Ranges

Large date ranges cause timeouts. Split queries:

# Instead of 1 year, use monthly chunks
queries = [
    {"startDate": "2024-01-01", "endDate": "2024-01-31"},
    {"startDate": "2024-02-01", "endDate": "2024-02-29"},
    # ...
]

Testing Your Configuration

Run this test query to verify your setup:

{
  "startDate": "2024-01-01",
  "endDate": "2024-01-07",
  "companyName": "",
  "documentType": "Todos"
}

This should return results within 30 seconds if configured correctly.

Societe.com Company Data Scraper: Configuration Guide

Common Failure Patterns

Timeout errors (2 out of 16 runs)
Proxy configuration issues (1 out of 16 aborted runs)

Correct Configuration

Step 1: Timeout Settings

French portals are slower than expected. Increase timeout:

{
  "timeout": 120000,  # 120 seconds instead of default 60
  "proxy": {
    "useApifyProxy": true,
    "apifyProxyGroups": ["RESIDENTIAL"]
  }
}

Step 2: Input Validation

Societe.com requires exact company name matches:

{
  "companyName": "Société Générale",
  "maxPages": 5
}

Important:

Use exact company names as registered
French company names include accents and special characters
Test with partial names if exact match fails

Step 3: Residential Proxy Requirement

French government portals actively block data center IPs. Residential proxies are mandatory:

{
  "proxy": {
    "useApifyProxy": true,
    "apifyProxyGroups": ["RESIDENTIAL"],
    "apifyProxyCountry": "FR"
  }
}

Testing Your Configuration

Test with this known French company:

{
  "companyName": "TotalEnergies",
  "maxPages": 2
}

This should return company directors and financial data within 2 minutes.

Production-Ready Patterns

1. Error Handling and Retries

Implement retry logic for transient failures:

import time
import requests

def fetch_borme_data_with_retry(query, max_retries=3):
    for attempt in range(max_retries):
        try:
            result = borme_actor.run(query)
            if result.get('success'):
                return result
            elif result.get('error') == 'timeout':
                time.sleep(10 * (attempt + 1))  # Exponential backoff
            else:
                break  # Don't retry on validation errors
        except Exception as e:
            if attempt == max_retries - 1:
                raise
            time.sleep(5 * (attempt + 1))
    return None

2. Batch Processing

Process multiple companies efficiently:

# BORME - Process monthly chunks
def process_borme_year(year, company_names=None):
    results = []
    for month in range(1, 13):
        start_date = f"{year}-{month:02d}-01"
        if month == 12:
            end_date = f"{year}-12-31"
        else:
            end_date = f"{year}-{month+1:02d}-01"

        query = {
            "startDate": start_date,
            "endDate": end_date,
            "companyName": "" if not company_names else ",".join(company_names),
            "documentType": "Todos"
        }

        result = borme_actor.run(query)
        if result.get('success'):
            results.extend(result.get('data', []))

    return results

3. Data Validation

Verify data quality before processing:

def validate_borme_data(data):
    required_fields = ['companyName', 'documentType', 'publicationDate']
    return all(field in data for field in required_fields)

def validate_societe_data(data):
    required_fields = ['companyName', 'siren', 'directors']
    return all(field in data for field in required_fields)

Troubleshooting Common Issues

BORME Issues

Error	Solution
"Invalid date format"	Use YYYY-MM-DD format
"Company not found"	Check exact company name spelling
"Proxy connection failed"	Use residential proxy
"Query timeout"	Reduce date range to < 3 months

Societe.com Issues

Error	Solution
"Request timeout"	Increase timeout to 120 seconds
"Access denied"	Use residential proxy with FR location
"Company not found"	Verify exact company name with accents
"Rate limit exceeded"	Add 30-second delay between requests

Success Metrics

When configured correctly, you should see:

BORME: 95%+ success rate on valid inputs
Societe.com: 90%+ success rate with proper proxy setup
Average response time: BORME (30-60s), Societe.com (60-120s)

Getting Help

If you continue experiencing issues:

Check your input format against the examples above
Verify proxy configuration - residential proxies are required
Reduce query scope - test with smaller date ranges first
Review run logs in Apify Console for specific error messages

Related Tools

For comprehensive European compliance workflows, combine these actors:

BORME Corporate Acts Scraper - Spanish corporate registry data
Societe.com Company Data Scraper - French company intelligence
Spain Company Directory Scraper - Spanish business directory
WKO Business Directory Scraper - Austrian company registry

Reliability isn't just about technology—it's about understanding the unique requirements of each European registry. With proper configuration, these tools become powerful assets for your compliance automation workflows.

Your UCP Profile is Detected. But AI Agents Still Can't Buy From You.

Peter — Sun, 26 Apr 2026 15:55:30 +0000

Your UCP Profile is Detected. But AI Agents Still Can't Buy From You.

We scanned 111 e-commerce stores. 35 of them have UCP profiles that pass validation. But not a single one can actually complete a purchase with AI agents.

Here's why: these "Grade C" stores all share the same 3 critical missing fields.

The Grade C Trap: Detection ≠ Readiness

Every store in the Grade C category (score: 60-79) has UCP manifest files that basic validators like UCPChecker.com report as "valid." They pass structural validation, network connectivity, and even basic schema checks.

But when AI agents actually try to interact with these stores, they fail. Every single time.

The problem isn't that these stores lack UCP profiles. The problem is that their profiles lack 3 specific fields that AI agents need to complete transactions.

The 3 Missing Fields Break AI Commerce

1. Missing `signing_keys` - The Trust Gap

What it is: Cryptographic verification that the UCP manifest hasn't been tampered with.

Why agents need it: AI agents need to verify that the UCP profile they're interacting with is authentic and hasn't been maliciously modified.

Impact: Without signing keys, AI agents cannot trust the UCP profile, making the entire interaction insecure.

Prevalence: 19.8% of stores with UCP profiles lack signing keys, but 100% of Grade C stores are missing them.

2. Missing `payment_handlers` - The Purchase Blocker

What it is: Configuration that tells AI agents how to process payments for the store.

Why agents need it: AI agents need to know which payment methods to use, how to format payment requests, and how to handle payment processing.

Impact: Without payment handlers, AI agents cannot complete purchases. They can discover the store and browse products, but they can't buy anything.

Prevalence: 22.5% of stores with UCP profiles lack payment handlers, but 100% of Grade C stores are missing them.

3. Missing `return_policy` Schema - The Trust Builder

What it is: Structured data about return policies, warranties, and refund terms.

Why agents need it: AI agents need to show customers trust signals before making purchases. Return policies are one of the most important trust signals for e-commerce.

Impact: Without return policy schema, AI agents cannot display return terms, build customer trust, or handle post-purchase service.

Prevalence: 48.6% of all stores lack return policy schema, but 100% of Grade C stores are missing them.

Why This Matters for Agentic Commerce

The Grade C pattern reveals a critical gap in current UCP implementations:

Stores pass "presence" validation but fail "interaction" validation.

This means:

AI discovery works (agents can find the store)
Product browsing works (agents can see products)
But purchasing fails (agents cannot complete transactions)

For agentic commerce to work, we need to move beyond "is UCP present?" to "can UCP actually facilitate commerce?"

How to Fix Your Grade C Profile

The good news: these are configuration issues, not platform limitations. Here's how to address each:

1. Add Signing Keys

{
  "signing_keys": [
    {
      "key_id": "your-key-id",
      "public_key": "your-public-key-here",
      "algorithm": "ES256"
    }
  ]
}

2. Configure Payment Handlers

{
  "payment_handlers": [
    {
      "payment_method": "credit_card",
      "supported_networks": ["visa", "mastercard", "amex"],
      "capabilities": ["supports_installments", "supports_3d_secure"]
    },
    {
      "payment_method": "paypal",
      "capabilities": ["supports_paypal_vault"]
    }
  ]
}

3. Add Return Policy Schema

{
  "return_policy": {
    "return_window_days": 30,
    "return_shipping_paid_by": "merchant",
    "refund_method": "original_payment_method",
    "exceptions": ["final_sale_items", "custom_products"],
    "restocking_fee_percent": 0
  }
}

The BigCommerce Platform Bug

Our scans reveal a specific pattern affecting BigCommerce stores:

Issue: dev.ucp.shopping service missing required spec field
Issue: REST transport missing required schema field
Result: All report UCP_INVALID_SERVICE errors

This appears to be a platform-level issue in BigCommerce's UCP implementation. BigCommerce merchants should verify their REST schema fields and contact BigCommerce support if these fields are missing.

Who's Affected?

All 35 Grade C stores share these exact same failures, including:

SaaS agencies: obundle.com, papathemes.com
Fashion DTC: allbirds.com, brooklinen.com, chubbiesshorts.com, fashionnova.com
Home Decor: curatedhomedecor.com, interiordelights.net, feldkampsfurniture.com
Beauty: kyliecosmetics.com

These aren't small, unknown stores. These are established brands with UCP profiles that "pass validation" but fail at AI commerce.

The Reality Check

65% of stores have zero UCP profiles.
Zero stores are fully AI-agent ready.
35 stores have "broken but detectable" UCP profiles.

The state of agentic commerce readiness is worse than most merchants realize. Having a UCP profile isn't enough. Your profile actually needs to work with AI agents.

Test Your AI Readiness

Don't trust basic validation. Test your actual AI commerce readiness:

Check your signing keys: Can your manifest be cryptographically verified?
Test payment handlers: Can AI agents process payments on your store?
Verify return policy: Do agents have access to your return terms?

The gap between "UCP detected" and "AI commerce ready" is where most merchants are stuck. Fixing these 3 fields is the bridge from discovery to actual transactions.

Data from UCPtools AI Readiness Index (111 domains scanned, April 13, 2026)

Test your store's actual AI readiness at ucptools.dev?utm_source=devto&utm_medium=article&utm_campaign=202604

EKW Land Registry Scraper: Transparent Review Response & Compliance Use Cases

Peter — Fri, 24 Apr 2026 10:13:11 +0000

EKW Land Registry Scraper: Transparent Review Response & Compliance Use Cases

The Reality of Government Data Scraping: What Our 1-Star Review Tells Us

Earlier this month, our EKW Land Registry (księgi wieczyste) scraper received its first review on the Apify Store - a 1-star rating. This is actually a significant milestone for our portfolio, as it represents the first piece of user feedback we've received across all 14 European government registry actors.

Rather than avoiding this feedback, we believe transparency is crucial for building trust in the compliance technology ecosystem. Let's break down what this review means and how we're addressing it.

Understanding the Review Context

The EKW Land Registry scraper extracts property ownership data, encumbrances, and transaction histories from Polish notary registers. This is critical information for:

Real estate due diligence
Legal case preparation
Asset verification in M&A transactions
Compliance monitoring for beneficial ownership

The 1-star review came from a user who ran the scraper successfully (100% success rate on 14 runs) but likely had different expectations about the data format or coverage.

What Our Scrapers Actually Deliver

Unlike some government portals that return structured JSON data, Polish notary registers (EKW) present several challenges:

Data Format Complexity

Mixed content types: Some entries contain structured tables, others are narrative text

Current Capabilities

Our EKW scraper delivers:

{
  "property_details": {
    "address": "ul. Przykładowa 123, 00-001 Warszawa",
    "parcel_number": "12345/67/89", 
    "current_owner": "Jan Kowalski SP. z o.o.",
    "ownership_type": "Pełne prawo własności"
  },
  "register_history": [
    {
      "date": "2023-06-15",
      "type": "Przewłaszczenie",
      "parties": ["Bank XYZ", "Jan Kowalski SP. z o.o."],
      "amount": "1,200,000 PLN"
    }
  ],
  "encumbrances": [],
  "last_updated": "2023-12-01"
}

Addressing Common Expectation Gaps

1. "Why isn't this as comprehensive as the official portal?"

The official portal (https://ekw.ms.gov.pl/) requires:

Individual document downloads
Manual data extraction
Multiple search iterations
PDF parsing for older records

Our scraper automates the first two steps but respects the same data boundaries set by the Ministry of Justice.

2. "Why do some properties have incomplete data?"

Polish land registries have different coverage levels:

Urban areas: Comprehensive digital records (post-2010)
Rural areas: Mixed digital/analog records
Historical properties: May require manual archive research

3. "How can I verify the data accuracy?"

Always cross-reference with official sources:

Use the EKW portal for final verification
Cross-check with notary protocols when available
Verify amounts and dates against court records
Confirm ownership changes in company registries (KRS)

Production Use Cases That Work

Real Estate Due Diligence Process

graph TD
    A[Identify Property] --> B[Run EKW Scraper]
    B --> C{Data Quality Check}
    C -->|Complete| D[Integrate with KRS for company ownership]
    C -->|Partial| E[Use official portal for verification]
    D --> F[Generate due diligence report]
    E --> F

Compliance Monitoring Workflow

Initial screening: Run EKW on target properties
Risk identification: Flag unusual ownership patterns
Deep verification: Cross-reference with official sources
Documentation: Save both scraper and official data for audit trails

Technical Limitations We're Working On

Current Constraints

Pagination: Limited to first 50 results per search (API limitation)
Date ranges: Cannot search beyond available digital records
Complex queries: Boolean operators not supported in current version

Planned Improvements (Q2 2026)

[ ] Extended pagination support
[ ] Advanced search filters by date/amount
[ ] Integration with KRS for company cross-referencing
[ ] Change detection and monitoring alerts

The Compliance Professional's Reality

Government registry scraping always involves trade-offs:

What you gain:

Automated data collection saves 15-20 hours per property search
Consistent formatting across multiple records
Integration capability with other systems
Historical data compilation

What you accept:

Need for source verification
Potential gaps in older records
Occasional format inconsistencies
Understanding of system limitations

Our Commitment to Users

Transparency: We clearly document what our scrapers can and cannot do
Support: Direct assistance with data interpretation and usage
Improvement: User feedback drives feature development
Ethics: Compliance with Polish data protection regulations

Alternative Approaches

When EKW data proves insufficient, consider these complementary tools:

1. KRS Financial Statements

For corporate property ownership analysis

Company financials showing property holdings
Shareholder structure verification
Asset declarations in annual reports

2. CRBR Beneficial Owners

For ultimate beneficial ownership tracing

Natural persons behind corporate entities
Complex ownership structures
Cross-border asset mapping

3. Manual Portal Access

For complex cases requiring:

Historical document retrieval
Legal interpretation assistance
Notary protocol verification

Getting Started with EKW

Basic usage workflow:

Search by property address (most reliable)
Verify parcel number accuracy
Cross-check ownership data
Document your verification process

Sample code integration:

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")
actor_call = client.actor("regdata/ekw-ksiegi-wieczyste-scraper").call(
    run_input={
        "address": "ul. Marszałkowska 100, Warszawa",
        "maxPages": 5
    }
)

for item in actor_call["items"]:
    print(f"Property: {item['property_details']['address']}")
    print(f"Owner: {item['property_details']['current_owner']}")

Final Thoughts

The 1-star review taught us several valuable lessons:

User expectations management needs improvement
Documentation should be more explicit about data limitations
Support channels for data interpretation are essential
Transparency about limitations builds more trust than over-promising

Government data scraping is inherently complex, but when used appropriately, it provides immense value for compliance workflows. We're committed to making our tools more useful, transparent, and reliable for the compliance community.

What's your experience with Polish land registry data? Have you faced similar challenges with government data scraping? Share your thoughts in the comments below.

Try the EKW Land Registry scraper: https://apify.com/regdata/ekw-ksiegi-wieczyste-scraper?utm_source=devto&utm_medium=article&utm_campaign=202604

Explore other Polish compliance tools: https://apify.com/regdata?utm_source=devto&utm_medium=article&utm_campaign=202604

Join our community of compliance professionals automating European government data access.

Microsoft Dropped ACP for UCP in 104 Days. Identity Linking Is Why.

Peter — Fri, 24 Apr 2026 09:54:57 +0000

On January 8, 2026, Microsoft launched Copilot Checkout on ACP - OpenAI's Agentic Commerce Protocol, powered by Stripe.

104 days later, on April 22, Microsoft announced general availability of UCP feeds in Merchant Center. Target was the launch partner. The same day, Ulta Beauty went live with agentic commerce, linking 46 million loyalty members through UCP.

Microsoft didn't just add a second protocol. They switched horses mid-race.

The question nobody's answering clearly: what does UCP have that ACP doesn't?

The answer is one capability: Identity Linking.

The Loyalty Problem AI Agents Create

Think about what happens when an AI agent shops on your behalf.

It finds a product. Compares prices. Adds to cart. Checks out. Every step works. But it checks out as a guest.

The agent doesn't know you're a Target Circle member. It doesn't know you have 50,000 reward points. It doesn't know you qualify for member-only pricing on the item it just found.

Every AI-mediated purchase becomes a guest checkout. Merchants lose their most valuable signal: who this customer actually is.

This isn't an edge case. Target Circle has tens of millions of members. Ulta has 46 million. Sephora, Best Buy, Gap - all UCP endorsers - have massive loyalty programs. When AI agents ignore all of that, merchants lose the customer relationship they spent years building.

The protocol that solves this wins. That's why Microsoft switched.

How Identity Linking Actually Works

Identity Linking is a stable capability in the UCP spec (not draft, not experimental). It's been there since the January 2026 launch.

The namespace is dev.ucp.common.identity_linking - note it's under common, not shopping. This trips up a lot of implementations.

Here's what the capability declaration looks like in your /.well-known/ucp profile:

{
  "name": "dev.ucp.common.identity_linking",
  "version": "2026-01-11",
  "spec": "https://ucp.dev/latest/specification/identity-linking/",
  "schema": "https://ucp.dev/schemas/common/identity_linking.json",
  "config": {
    "supported_mechanisms": [
      {
        "type": "oauth2",
        "issuer": "https://yourstore.com"
      }
    ]
  }
}

The flow uses standard OAuth 2.0 Authorization Code (RFC 6749). Nothing exotic:

Agent reads your UCP profile and sees you support Identity Linking
Agent discovers your OAuth server via RFC 8414 at /.well-known/oauth-authorization-server
Agent requests authorization on the user's behalf
User sees a one-time consent prompt (inside Copilot or Gemini)
Agent gets an access token scoped to ucp:scopes:checkout_session
Every subsequent checkout carries member pricing, points, preferences

The critical insight: one consent, persistent identity. The user approves once. After that, the agent carries their loyalty membership into every future session with that merchant. No re-auth. No per-transaction prompts.

Your OAuth server needs to publish a metadata endpoint per RFC 8414:

{
  "issuer": "https://yourstore.com",
  "authorization_endpoint": "https://yourstore.com/oauth/authorize",
  "token_endpoint": "https://yourstore.com/oauth/token",
  "scopes_supported": ["ucp:scopes:checkout_session"],
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code"],
  "token_endpoint_auth_methods_supported": ["client_secret_basic"]
}

Note: the OAuth endpoints are NOT declared in the UCP profile. They're discovered dynamically via RFC 8414. The profile only declares the issuer URL.

Target Circle in Copilot: What the Flow Looks Like

Here's what Microsoft built with Target as the launch partner:

You ask Copilot to find running shoes under $80
Copilot queries Target's UCP endpoint, finds matching products
You pick a shoe. Copilot starts checkout
Copilot sees Identity Linking in Target's profile. Prompts: "Connect your Target Circle account?"
You approve. OAuth happens behind the scenes
Checkout continues - but now with your Circle discount applied, your email pre-filled, your reward points available
Next time you shop at Target through Copilot, step 4 is skipped. Your identity persists

This is why Microsoft specifically called out Identity Linking in their Merchant Center announcement. It's not a nice-to-have feature - it's the mechanism that makes loyalty programs survive the shift to AI-mediated commerce.

Why ACP Can't Do This

ACP uses Stripe delegated tokens. A Stripe token represents a payment credential - a card, a wallet, a bank account.

A Stripe token knows your card number. It does not know you're a rewards member. It does not know your loyalty tier. It does not carry member pricing.

ACP has no OAuth identity layer. No account linking mechanism. No way for an agent to say "this shopper is customer #4821 with Gold status."

This is a structural gap, not a missing feature. ACP was designed for payment delegation. UCP was designed for the full commerce lifecycle - including identity.

When Microsoft needed loyalty programs to work in Copilot Shopping, ACP couldn't deliver. UCP could. 104 days was all it took to make the switch.

Implementation: Adding Identity Linking to Your Profile

If you have a loyalty program and want it to work with AI agents, here's what you need:

1. Add the capability to your UCP profile

Add the dev.ucp.common.identity_linking entry to your capabilities array (see the JSON example above). Common namespace - not shopping.

2. Set up your OAuth server

You need a standard OAuth 2.0 Authorization Server with a metadata endpoint at /.well-known/oauth-authorization-server. If you already support OAuth for mobile apps or partner integrations, you're most of the way there.

3. Watch for these validation failures

Our validator catches 4 Identity Linking-specific issues:

Error Code	What Went Wrong
`UCP_IDENTITY_MISSING_MECHANISMS`	No `config.supported_mechanisms` in your capability
`UCP_IDENTITY_INVALID_MECHANISM`	Mechanism entry missing required `type` field
`UCP_IDENTITY_MISSING_ISSUER`	OAuth2 mechanism without an `issuer` URL
`UCP_IDENTITY_ISSUER_NOT_HTTPS`	Issuer URL uses HTTP instead of HTTPS

The most common failure: declaring the capability but forgetting the config block entirely. A Level 1 validator (JSON structure only) won't catch this. You need Level 2 compliance validation.

What To Do Next

Check if your profile declares Identity Linking - if you have a loyalty program and it's missing, your members are invisible to AI agents
Validate your Identity Linking config at ucptools.dev - the validator checks all 4 error codes and tells you exactly what to fix
Add UCP validation to CI/CD - catch regressions before agents do (GitHub Action)
Test the OAuth flow end-to-end - a valid profile means nothing if the OAuth metadata endpoint returns a 404

Microsoft made their bet. Target and Ulta are live. The Identity Linking spec is stable and validated by multiple agent platforms. If you have a loyalty program, this is the capability that makes it travel with your customers into AI commerce.

UCPtools is an independent community tool - not affiliated with Google, Shopify, or the UCP consortium.

93% of UCP profiles are broken. Here are the 3 failures that matter most.

Peter — Sat, 18 Apr 2026 07:03:35 +0000

93% of UCP profiles are broken. Here are the 3 failures that matter most.

Published April 18, 2026 | 5 min read

We just scanned 111 e-commerce domains and found a staggering truth: 93% of UCP profiles cannot complete AI agent purchases. Not because they don't have UCP files, but because they fail at the 3 critical steps that actually matter for agentic commerce.

The Data Behind the 93%

Our AI Readiness Index scanned 111 reachable domains across fashion, home decor, beauty, SaaS, and marketplaces:

72 domains (65%): Zero UCP presence at all
35 domains (31.5%): Have UCP files but are functionally broken
4 domains (3.6%): Have structural issues
0 domains: Are actually AI-agent ready

Among the 35 stores that technically "pass" UCP validation (Grade C), 100% share the same 3 fatal failures. This is where the real problem lies.

The 3 Failures That Break AI Commerce

1. Missing `signing_keys` - 20% of all stores

{
  "ucp_version": "1.0",
  "signing_keys": []  // ← EMPTY OR MISSING
}

Why it matters: Without cryptographic signing keys, AI agents cannot verify that your UCP manifest is authentic and hasn't been tampered with. This is a security requirement for any transaction.

Impact: Agents will refuse to interact with your store, period.

2. Missing `payment_handlers` - 23% of stores with UCP

{
  "services": {
    "checkout": {
      "type": "rest",
      "uri": "https://yourstore.com/checkout",
      "payment_handlers": []  // ← EMPTY OR MISSING
    }
  }
}

Why it matters: Payment handlers tell AI agents which payment methods you accept (credit cards, PayPal, Apple Pay, etc.). Without them, agents have no idea how to complete a purchase.

Impact: AI agents can discover your store but cannot buy from you.

3. Missing `return_policy` schema - 49% of all stores

{
  "organization": {
    "name": "Your Store",
    "return_policy": {
      "type": "object",
      "properties": {}  // ← MISSING REQUIRED FIELDS
    }
  }
}

Why it matters: Return policies are trust signals for AI agents. They need to know your return terms to recommend your store to users and handle post-purchase issues.

Impact: AI agents cannot display your trustworthiness, reducing conversion likelihood.

The "Detected" ≠ "Ready" Trap

Most UCP validation tools (including our own basic checks) only answer one question: "Is there a .well-known/ucp file?"

They don't answer the questions that actually matter:

✅ Can agents cryptographically verify your manifest?
✅ Can agents process payments at your store?
✅ Can agents display your trust signals?

Stores like Allbirds, Brooklinen, and Fashion Nova all pass basic UCP detection but fail at these critical levels. They're "detected" but not "transactable."

Real-World Example: BigCommerce Bug

We found a platform-wide issue affecting BigCommerce merchants:

{
  "services": {
    "dev.ucp.shopping": {
      "type": "rest",
      "uri": "https://store.mybigcommerce.com/api/ucp",
      "spec": {}  // ← MISSING SPEC FIELD
    }
  }
}

Three BigCommerce domains shared identical UCP_INVALID_SERVICE errors due to missing spec fields. This isn't merchant error - it's a platform implementation issue.

What This Means for AI Commerce

The 93% broken rate isn't just a statistic - it's a barrier to the $15T e-commerce market becoming AI-accessible.

For brands: You have a first-mover advantage right now. Fix these 3 fields and you'll be in the top 7% of AI-ready stores.

For agencies: Your clients' UCP profiles are likely broken even if they "pass" validation. You need to check these 3 critical areas.

For platforms: The current UCP implementation guidance is insufficient. Platforms need to enforce these 3 requirements at the validation level, not just the presence level.

Fix These in 15 Minutes

These aren't complex architectural changes. They're simple field additions:

Add signing keys from your SSL certificate
List accepted payment methods in payment_handlers
Define return terms in the return_policy schema

The tools exist to validate these properly - most just don't yet.

The Market Opportunity

Right now, the gap is enormous:

0% of marketplaces have working UCP
Only 31.5% of DTC brands even have UCP files
Of those, effectively none are actually AI-transactable

This creates a massive opportunity for the first platforms, agencies, and tools that solve these 3 fundamental problems.

Data from UCPtools AI Readiness Index - 111 domains scanned April 13, 2026. Scan methodology: Serper API discovery + targeted validation. All numbers from actual scan reports.

Test your store's UCP profile: https://ucptools.dev/directory?utm_source=devto&utm_medium=article&utm_campaign=202604 ?utm_source=dev.to&utm_medium=article&utm_campaign=202604

Austrian Insolvency Monitoring Without IWG License: Ediktsdatei on Apify

Peter — Sat, 18 Apr 2026 06:52:38 +0000

Austrian Insolvency Monitoring Without IWG License: Ediktsdatei on Apify

For compliance teams and credit risk analysts monitoring Austrian insolvency proceedings, the traditional path has been fraught with obstacles. The official Ediktsdatei system requires an expensive IWG government license, creating significant barriers for smaller firms, startups, and independent researchers who need access to critical insolvency data.

The Problem: IWG License Barrier

Austrian insolvency data is officially published through the Ediktsdatei system operated by the Austrian Courts. However, accessing this data programmatically traditionally required:

IWG License Application: Complex government approval process
Costly Subscription: Annual fees that can run into thousands of euros
Technical Limitations: Direct API access often restricted or unavailable
Geographic Restrictions: Some data may be location-limited

This barrier has left many compliance professionals forced to either:

Pay for expensive third-party services
Manually monitor court publications
Go without critical insolvency monitoring entirely

The Solution: Ediktsdatei Scraper on Apify

The Ediktsdatei scraper on Apify provides programmatic access to Austrian insolvency proceedings without requiring an IWG license. This democratizes access to critical compliance data that was previously locked behind bureaucratic and financial barriers.

Key Features

# Example: Get recent insolvency filings
from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")
run_input = {
    "keywords": ["Insolvenz", "Konkurs", "Sanierung"],
    "dateFrom": "2024-01-01",
    "maxResults": 100
}

run = client.actor("regdata/austria-ediktsdatei-scraper").call(run_input=run_input)

What you get:

Structured Data: Court decisions, creditor information, asset details
Real-time Monitoring: Track new filings as they're published
Historical Data: Access to past proceedings for trend analysis
Multi-Jurisdiction: Coverage across Austrian regional courts
Cost-Effective: Pay-per-use pricing starting at $0.005 per result

Use Cases for Compliance Teams

1. Credit Risk Assessment

Monitor Austrian companies showing signs of financial distress before it appears in credit reports. Early detection of insolvency proceedings allows for proactive risk mitigation.

2. Supply Chain Risk Management

Track your suppliers' financial health to prevent disruptions to your operations. Insolvency monitoring helps identify at-risk vendors before they fail.

3. Due Diligence for M&A

Conduct thorough background checks on Austrian target companies by reviewing their insolvency history and current proceedings.

4. Competitive Intelligence

Monitor industry competitors for financial distress signals that may create market opportunities or risks.

Technical Implementation

Basic Usage

import pandas as pd

# Fetch recent insolvency data
actor_client = ApifyClient("YOUR_API_TOKEN")
results = actor_client.dataset("YOUR_DATASET_ID").list_items()

# Analyze trends by court
df = pd.DataFrame(results)
court_counts = df['court'].value_counts()
print("Insolvency filings by court:")
print(court_counts)

Advanced Monitoring

Set up automated monitoring for specific companies or industries:

# Monitor specific companies
monitoring_list = [
    "Unternehmensname GmbH", 
    "Industrie AG",
    "Handels KG"
]

# Filter results for monitored companies
filtered_results = [
    item for item in results 
    if any(company in item['debtor_name'] for company in monitoring_list)
]

Comparison with Alternatives

Solution	Cost	License Required	Real-time Data	Historical Data
Ediktsdatei Scraper	$0.005/result	None	✅	✅
IWG Direct Access	€2,000+/year	Required ✅	✅	✅
Commercial Vendors	€500+/month	Varies	✅	✅
Manual Monitoring	€0 (time cost)	None	❌	Limited

Compliance Benefits

6AMLD Compliance

The upcoming 6th Anti-Money Laundering Directive (effective July 2027) requires enhanced due diligence on beneficial owners and risk assessment. Austrian insolvency data provides critical signals for:

Enhanced Due Diligence: Identifying high-risk entities
Ongoing Monitoring: Tracking changes in corporate structure
Source of Wealth Verification: Understanding financial history

Regulatory Reporting

Insolvency data feeds into various regulatory reporting requirements including:

Suspicious transaction reporting
Enhanced customer due diligence
Risk assessment documentation

Getting Started

Create Apify Account: Free tier available
Get API Token: Generate from your Apify dashboard
Deploy the Actor: One-click deployment of Ediktsdatei scraper
Configure Your Query: Set keywords, date ranges, and filters
Automate Monitoring: Set up scheduled runs for ongoing monitoring

First Run Example

# Configure your first scraping run
run_input = {
    "keywords": ["Konkurs", "Insolvenz", "Sanierungsplan"],
    "dateFrom": "2024-01-01",
    "dateTo": "2024-12-31",
    "maxResults": 50,
    "includeDetails": True
}

# Execute the scrape
run = client.actor("regdata/austria-ediktsdatei-scraper").call(run_input=run_input)

# Monitor progress
print(f"Run status: {run['status']}")
print(f"Items collected: {run['stats']['items']}")

Cost Analysis

The pay-per-use model makes this solution highly cost-effective:

Small Scale: 100 results/month = $0.50
Medium Scale: 1,000 results/month = $5.00
Large Scale: 10,000 results/month = $50.00

Compare this to traditional IWG license fees of €2,000+ per year, and the value proposition becomes clear.

Limitations and Considerations

Public Data Only: Only covers officially published insolvency proceedings
Update Frequency: Dependent on court publication schedules
Language: Most documents are in German
Data Completeness: Some details may be redacted or incomplete

Conclusion

The Ediktsdatei scraper on Apify removes the IWG license barrier that has prevented many organizations from accessing critical Austrian insolvency data. For compliance teams, credit risk analysts, and due diligence professionals, this tool provides an affordable, scalable solution for monitoring Austrian corporate distress signals.

As regulatory requirements continue to evolve and the importance of early risk detection grows, having programmatic access to insolvency data becomes increasingly valuable. This solution bridges the gap between the need for comprehensive compliance monitoring and the practical barriers that have traditionally existed.

Ready to get started with Austrian insolvency monitoring? Deploy the Ediktsdatei scraper on Apify and begin monitoring critical compliance signals today.

Additional Resources

What are your thoughts on insolvency monitoring tools? Have you faced challenges with accessing Austrian court data? Share your experiences in the comments below!

6AMLD Compliance: Automate Beneficial Owner Checks by July 2027

Peter — Fri, 17 Apr 2026 15:25:54 +0000

6AMLD Compliance: Automate Beneficial Owner Checks by July 2027

The Sixth EU Anti-Money Laundering Directive (6AMLD) comes into full effect on July 10, 2027, and compliance teams across Europe are scrambling to prepare. With stricter beneficial ownership verification requirements and increased penalties for non-compliance, manual registry searches are no longer sustainable.

The Challenge: Cross-Border Beneficial Owner Verification

Under 6AMLD, financial institutions and designated businesses must:

Verify beneficial ownership information for all corporate entities
Monitor for changes in ownership structures
Report suspicious activity within strict deadlines
Maintain auditable trails of all verification processes

The problem? Beneficial owner data is scattered across 27+ national registries with:

Different formats (XML, JSON, PDF, web pages)
Varying access methods (paid APIs, free portals, web scraping)
Update frequencies (daily, weekly, quarterly)
Search capabilities (limited to basic name/company searches)

The Solution: Automated Beneficial Owner Intelligence

Our European Business Data Suite provides programmatic access to key beneficial owner registries across four countries:

Poland: CRBR Beneficial Owners Scraper

What it does: Extracts real beneficial owner data from Poland's Central Register of Beneficial Owners
Price: $0.03 per result
Use case: Verify Polish company ownership structures, monitor for changes
Why it matters: Poland's CRBR is mandatory under 6AMLD with real-time updates

Spain: Company Directory Scraper

What it does: Accesses Spanish company registry data including beneficial owners
Price: $0.005 per result
Use case: Cross-reference Spanish entities with ownership information
Why it matters: Spain's strict transparency laws align with 6AMLD requirements

Austria: WKO Business Directory

What it does: Provides Austrian company data including ownership structures
Price: $0.003 per result
Use case: Verify Austrian beneficial ownership for due diligence
Why it matters: Austrian transparency requirements complement 6AMLD

France: Societe.com Company Data

What it does: Extracts French company director and ownership information
Price: $0.005 per result
Use case: Monitor French corporate ownership changes
Why it matters: France's expanded beneficial ownership registries fall under 6AMLD

Automated Compliance Workflows

1. New Customer Onboarding

Customer provides company ID → Cross-check all 4 country registries → 
Flag high-risk jurisdictions → Verify beneficial owners → 
Generate compliance report

2. Ongoing Monitoring

Daily scans of registries → Detect ownership structure changes →
Trigger review workflows → Update compliance profiles →
Maintain audit trail

3. Risk Assessment

Extract ownership networks → Identify politically exposed persons →
Cross-reference sanctions lists → Calculate risk scores →
Prioritize high-risk cases

Why Automation Beats Manual Searches

Method	Speed	Accuracy	Cost	Scalability	Audit Trail
Manual searches	Hours per company	60-80%	$50-100/company	Limited	Poor
Spreadsheets	Days/weeks	70-85%	$20-50/company	Limited	Medium
Our automation	Minutes	95%+	$0.01-0.03/company	Unlimited	Excellent

Getting Started with 6AMLD Compliance

Step 1: Assess Your Exposure

Map your customer base by country
Identify high-risk jurisdictions
Calculate manual compliance costs

Step 2: Test Automation

Start with pilot customers
Compare accuracy vs manual methods
Build compliance templates

Step 3: Scale Deployment

Integrate with existing workflows
Set up automated monitoring
Establish alert thresholds

Step 4: Maintain Compliance

Regular audits of automated processes
Updates for regulatory changes
Continuous improvement

The Cost of Non-Compliance

6AMLD penalties can reach up to 5% of global annual turnover or €10 million, whichever is higher. With 27+ countries implementing the directive, the compliance burden is unprecedented.

Our suite reduces compliance costs by 80-90% while improving accuracy and auditability.

Start Your 6AMLD Journey Today

The July 2027 deadline will be here before you know it. Early adopters are already building automated compliance systems, while laggards face impossible manual workloads.

Ready to automate your beneficial owner verification?

Explore our European Business Data Suite:

Automated compliance isn't just about meeting deadlines—it's about transforming compliance from a cost center to a competitive advantage.

This article is part of our European Business Data series. Stay tuned for more insights on cross-border compliance automation.

UCP and ACP Need a Third Layer: Trust Rails

Peter — Thu, 16 Apr 2026 05:59:36 +0000

If you only watched protocol updates in agentic commerce, this week might have looked like more of the same.

But if you looked at where new announcements actually landed, the signal was different:

UCP and ACP keep defining reach (where an agent can discover and attempt checkout).
A new trust layer is becoming explicit (who carries risk when an autonomous purchase goes wrong).

That second point is the story.

In the last 7 days, the market did not just talk about agent checkout mechanics. It moved toward issuer-side controls, intent proof, and liability handling as first-class infrastructure.

For merchants, this changes the implementation question from:

"Which protocol should we support first?"

to:

"How do we ship protocol coverage and trust controls together so autonomous checkout can scale without blowing up disputes?"

The 7-Day Signal (Apr 10-Apr 16)

Here are the highest-signal changes and discussions from the current window:

Apr 14, 2026: American Express launched ACE developer tooling and registered-agent purchase protection
- Official newsroom announcement: American Express introduced Agentic Commerce Experiences (ACE) and protection mechanics for registered agent purchases.
- Practical meaning: payment-side participants are now publishing explicit models for intent validation, registration, and post-transaction accountability.
Apr 14, 2026: Commerce media coverage emphasized trust, control, and visibility for agent-initiated transactions
- Industry writeups broke out the operational pieces: agent registration, account enablement, purchase intent, tokenized credential pass-through, and optional cart context.
- Practical meaning: trust is no longer an abstract "future standards" topic. It is entering implementation checklists.
Apr 10-Apr 16, 2026: Operator conversation accelerated around protocol fragmentation and execution gaps
- Builders and commerce operators repeatedly framed the same reality: one protocol path rarely covers every agent ecosystem.
- Practical meaning: merchants need a multi-surface strategy (discovery + checkout + payment trust) instead of single-protocol optimism.

UCP and ACP Are Reach Layers, Not Full Safety Models

Let's separate what each layer does.

Layer 1: Reach and Interoperability

UCP (Google/Shopify ecosystem) helps agents discover merchant capabilities and run structured commerce flows.
ACP (OpenAI/Stripe ecosystem) enables structured agent checkout interactions in the ChatGPT-linked path.

Both are essential. Neither is sufficient on its own for production-scale autonomous buying.

Why?

Because successful autonomous commerce needs answers to risk questions that protocol alone does not fully answer:

What evidence proves user intent at authorization time?
Who is accountable if the agent buys the wrong item?
How does dispute resolution separate merchant error from agent error from user error?
What data can be safely retained for adjudication without creating privacy debt?

When volume is low, teams hand-wave these questions.
When agent volume rises, they become blocking architecture.

Why This Week Matters More Than Another Spec Diff

The common pattern in early UCP/ACP discussions was:

"Get discoverable and check-out capable first."

That guidance was directionally right, but incomplete.

This week showed the next constraint very clearly:

Agentic commerce throughput is constrained by the weaker layer:

Throughput ≈ min(protocol reach, trust-rail maturity)

If trust rails lag, throughput stalls. Not because agents cannot click "buy," but because finance, risk, and support teams will cap exposure.

In plain terms:

You can win technical demos with protocol support.
You win real GMV only when risk teams sign off on intent and liability paths.

The New Merchant Architecture (Practical Version)

You do not need to boil the ocean this quarter. You do need to avoid shipping protocol support in isolation.

Use this architecture split:

A) Discovery and Capability Layer

Maintain a valid UCP profile (/.well-known/ucp) where relevant.
Keep capability declarations synchronized with real endpoint behavior.
Validate profile and endpoint health continuously (not manually before launch days).

B) Transaction Execution Layer

Implement clean, deterministic checkout state handling.
Preserve idempotency across agent retries.
Log machine-readable failure reasons so agents can recover.

C) Trust and Liability Layer

Record explicit intent artifacts for agent-initiated actions.
Capture agent identity/registration context where available.
Define dispute routing playbooks: agent error vs merchant error vs user error.
Align payment credential handling with tokenized, scoped, revocable controls.

Most teams currently invest heavily in A and B, then improvise C.
This week's market signal suggests that C is now where winners and false starts will diverge.

A 30-Day Implementation Plan You Can Actually Execute

If your team is small, here is a realistic sequencing model.

Week 1: Baseline Reach Integrity

Validate UCP profile shape and endpoint availability.
Confirm declared capabilities match production behavior.
Patch obvious hygiene gaps (HTTPS, schema paths, key metadata).

Week 2: Checkout Determinism

Add idempotency guards on create/update/complete flows.
Normalize error codes for agent-readable recovery.
Add end-to-end replay tests for interrupted flows.

Week 3: Trust Artifacts

Define and store minimal intent evidence bundle.
Capture agent/session identifiers in transaction metadata.
Document what support can and cannot adjudicate with current logs.

Week 4: Liability Readiness Review

Run simulated dispute scenarios:
- wrong color/variant selected by agent
- stale availability race
- canceled intent arriving after delayed authorization
Confirm owner and fallback path for each failure mode.
Update customer-facing policy language for autonomous purchases.

This is not "perfect security architecture."
It is enough to move from experimental to operational.

The Cost of Ignoring the Trust Layer

If you skip this shift and treat agentic commerce as protocol-only, you will usually see one of four outcomes:

High discovery, low completion: agents can find you but fail late in checkout.
Completion spikes, dispute spikes: operations spend explodes and leadership throttles rollout.
Silent risk caps: internal teams reduce allowed agent use-cases without product visibility.
Channel fragmentation debt: each ecosystem gets separate one-off fixes, no shared risk model.

In other words, engineering may report "integration complete" while finance reports "do not scale this yet."

Where UCPtools Fits (and Where It Doesn't)

UCPtools helps with the readiness and validation side:

profile and capability validation
endpoint and schema checks
implementation diagnostics you can run before shipping

It does not replace your policy, underwriting, or issuer agreements.

But it does reduce one expensive failure class: shipping broken protocol posture and discovering it only after agents already route traffic.

If you want a quick baseline, run your domain through the validator:

https://ucptools.dev/validator?utm_source=devto&utm_medium=article&utm_campaign=ai_commerce_for_developers&utm_content=risk_layer

Then use the score as your Week 1 input for the 30-day plan above.

What to Do This Week

If you are deciding where to spend engineering time in April, here is the short answer:

Do not pick between UCP and ACP as an ideology war.
- Pick based on your near-term customer channel mix.
Do not treat protocol support as the finish line.
- Add intent and liability handling to the same roadmap.
Do not wait for perfect standards convergence.
- Build a clear internal trust model now, then adapt.

The teams that move fastest from pilot to durable volume will likely be the ones that connect these layers earliest:

Reach (UCP/ACP) + Execution (checkout reliability) + Trust (intent/liability rails).

That was not obvious to most teams a month ago.
After this week, it should be.

UCP is an open standard driven by Google and Shopify. ACP is an open standard driven by OpenAI and Stripe. UCPtools is an independent community tool and is not affiliated with Google, Shopify, OpenAI, or Stripe.

BORME Corporate Acts as Structured Data: Comparing Your Options in 2026

Peter — Wed, 15 Apr 2026 10:07:13 +0000

Every business day, Spain's Boletin Oficial del Registro Mercantil (BORME) publishes hundreds of corporate acts: company incorporations, officer appointments and dismissals, capital changes, dissolutions, mergers, and insolvency proceedings. For compliance teams monitoring Spanish counterparties or B2B sales teams prospecting new incorporations, this data is essential.

The problem: BORME publishes as PDFs. The official BOE API gives you PDF URLs but not the parsed content inside them.

This article compares three options for getting structured BORME data, with code examples.

Option 1: LibreBOR (formerly LibreBORME)

URL: librebor.me
Model: Free web interface, limited API behind Cloudflare
Status: Active — last confirmed updates February/March 2026

LibreBOR is the spiritual successor to the original LibreBORME open-source project. It provides a searchable web interface for BORME data at librebor.me, where you can look up any company and see its historical BORME acts. It's free and well-structured.

However, it comes with practical limitations:

Rate limiting and Cloudflare protection make bulk programmatic access unreliable
No official API documentation — the original LibreBORME had a documented API, but LibreBOR's API access is restricted
Dependency on a single maintainer — the original LibreBORME went offline in April 2025; while LibreBOR has been stable, there's no service-level guarantee
No Apify integration — you can't schedule runs, set up webhooks, or pipe results into your existing data pipeline on Apify

LibreBOR is excellent for ad-hoc lookups. If you need to check one company's BORME history, use it. If you need to process 500 acts daily in a production pipeline, the rate limiting becomes a blocker.

Option 2: BORME Scraper Pro (spain-data-solutions on Apify)

URL: apify.com/spain-data-solutions/borme-scraper-pro
Model: $8/month platform fee + usage charges
Status: Active — 8 total users, 2 monthly active

BORME Scraper Pro is a competing Apify actor that also parses BORME PDFs. It includes proxy rotation, province filtering, and claims 99.9% success rate. The developer renamed from startquicklabs and has been actively maintaining it.

Pricing structure: a fixed $8/month platform fee plus per-usage charges. This makes economic sense if you're running daily BORME extractions at scale. For occasional use — say, pulling one week's BORME data for a due diligence project — the monthly commitment may not justify the cost.

Option 3: BORME Corporate Acts Parser (regdata on Apify)

URL: apify.com/regdata/borme-corporate-acts-scraper
Model: Pay-per-use — $0.003 per result, no monthly fee
Status: Active — free tier friendly, HTTP-only (no Puppeteer)

Our BORME actor takes a different approach: pure HTTP requests and PDF parsing with pdfjs-dist. No browser automation, no proxy required, no monthly fee. You pay $0.003 per corporate act extracted.

How it works:

Fetches the BORME Section A index from boe.es for your specified date
Downloads the PDF files listed in the index
Parses each PDF to extract structured corporate acts
Returns JSON with act type, company name, NIF, province, and full details

Input example:

{
  "date": "2026-04-15",
  "province": "Barcelona"
}

Output example:

{
  "date": "2026-04-15",
  "province": "Barcelona",
  "bormeNumber": "89",
  "actType": "Nombramientos",
  "company": "EJEMPLO SOLUCIONES SL",
  "nif": "B12345678",
  "details": {
    "appointee": "Garcia Lopez, Maria",
    "role": "Administrador único"
  }
}

Running it via API:

curl -X POST "https://api.apify.com/v2/acts/regdata~borme-corporate-acts-scraper/runs?token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"date": "2026-04-15"}'

Running it with the Python client:

from apify_client import ApifyClient

client = ApifyClient("YOUR_TOKEN")

run = client.actor("regdata/borme-corporate-acts-scraper").call(
    run_input={"date": "2026-04-15", "province": "Madrid"}
)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(f"{item['actType']}: {item['company']} ({item['nif']})")

Cost comparison for common use cases:

Use Case	Acts/Run	BORME Scraper Pro	Our BORME Parser
Daily monitoring (1 province, 1 month)	~1,500	$8 + usage	~$4.50
One-off due diligence (1 day, all provinces)	~500	$8 + usage	~$1.50
Quarterly batch (3 months, 2 provinces)	~9,000	$8 + usage	~$27.00

For the one-off and low-frequency use cases that most compliance teams and law firms run, pay-per-use is significantly cheaper. The break-even with BORME Scraper Pro's $8 monthly fee is around 2,600 acts per month — below that, pay-per-use wins.

What BORME Data Looks Like

BORME Section A publishes the following act types daily:

Constituciones — new company incorporations (the goldmine for B2B prospecting)
Nombramientos — officer appointments (directors, administrators, secretaries)
Ceses/Dimisiones — officer dismissals and resignations
Modificaciones — company statute changes
Aumentos de capital / Reducciones de capital — capital increases and reductions
Disoluciones — company dissolutions
Fusiones / Escisiones — mergers and spin-offs
Declaraciones de unicidad — single-member company declarations
Revocaciones de poderes — revocations of powers of attorney
Situaciones concursales — insolvency proceedings

Each act type is extracted with its specific fields. For example, a "Constitución" includes company name, NIF, registered address, initial capital, and appointed officers. A "Cese" includes the departing officer's name and role.

Practical Workflow: Monitoring New Spanish Incorporations

A common use case: your B2B sales team wants daily alerts when new companies are incorporated in your target provinces.

from apify_client import ApifyClient
import json

client = ApifyClient("YOUR_TOKEN")

# Run BORME parser for today
run = client.actor("regdata/borme-corporate-acts-scraper").call(
    run_input={"date": "2026-04-15"}
)

# Filter for new incorporations only
new_companies = [
    item for item in client.dataset(run["defaultDatasetId"]).iterate_items()
    if item["actType"] == "Constituciones"
]

for company in new_companies:
    print(f"NEW: {company['company']} (NIF: {company['nif']})")
    # Push to your CRM, Slack, or email pipeline

Set this up as a scheduled run on Apify (daily at 10:00 CET, after BORME publishes), add a webhook to push results to your Slack or CRM, and you have a fully automated new-business monitoring system.

Summary

	LibreBOR	BORME Scraper Pro	Our BORME Parser
Cost	Free	$8/month + usage	$0.003/act, no monthly fee
Bulk access	Rate limited	Yes (proxy rotation)	Yes (HTTP-only)
Apify integration	No	Yes	Yes
Free tier	N/A	No ($8 minimum)	Yes
Proxy required	N/A	Yes (included)	No
Maintenance risk	Single maintainer	Developer-supported	Developer-supported
Best for	Ad-hoc lookups	Daily high-volume pipelines	Occasional/batch processing

Choose based on your volume and frequency. LibreBOR for quick manual lookups. BORME Scraper Pro if you're running thousands of acts daily and can justify the monthly commitment. Our parser for everything in between — project-based due diligence, periodic compliance checks, and batch processing without a recurring fee.

European Business Data Suite: 14 Actors, 4 Countries, One Platform

Peter — Wed, 15 Apr 2026 10:07:10 +0000

Government registries across Europe share one thing in common: they have no public API. Whether you need Polish company financials from KRS, Spanish corporate acts from BORME, Austrian insolvency data from Ediktsdatei, or French director networks from Societe.com — you're stuck with manual portal searches. One query at a time.

This article maps out 14 Apify actors that give you programmatic access to government and semi-official business data sources across 4 European countries. Every actor returns structured JSON. Every actor is pay-per-use with no subscription.

The Problem: Government Portals Without APIs

European business registries were built for citizens, not developers. Here's what that means in practice:

Poland's eKRS portal requires navigating through forms, solving captchas, and downloading individual PDF/XML files for each company's financial statements
Spain's BORME publishes 500+ corporate acts daily as PDFs — the official API gives you PDF URLs but not the parsed content
Austria's Ediktsdatei insolvency register requires an IWG license from the Ministry of Justice for API access — a bureaucratic process most companies can't justify
France's Societe.com aggregates INSEE, INPI, and BODACC data with director networks and financials, but has no API — you'd need to query 3 separate government APIs and join the data yourself
Poland's CRBR beneficial owner register has no bulk API — you verify one NIP at a time
Poland's EKW land registry uses an encrypted API endpoint and captcha, making it one of the hardest registries to automate in Europe

For a compliance officer running due diligence on 200 counterparties across multiple countries, this means days of manual work. For a developer building a KYC pipeline, it means writing fragile scrapers that break when portals change.

The Suite: 14 Actors, 4 Countries

All actors run on Apify's serverless platform. You get an API endpoint, scheduled runs, webhooks, and structured JSON output. No infrastructure to manage.

Poland (9 Actors)

Actor	Registry	Price/Result	Key Use Case
KRS Financial Statements	eKRS (ekrs.ms.gov.pl)	$0.025	Balance sheets, income statements from official filings
EKW Land Registry	EKW (ekw.ms.gov.pl)	$0.04	Property ownership, mortgages, easements across 352 courts
CRBR Beneficial Owners	CRBR (crbr.podatki.gov.pl)	$0.03	UBO verification — names, citizenship, ownership %
KRZ Debtor Registry	KRZ (krz.ms.gov.pl)	$0.025	Bankruptcy and debt screening — 9 search modes
UOKiK Abusive Clauses	UOKiK register	$0.003	Contract compliance against 7,500+ banned clauses
MSiG Court Gazette	MSiG (ems.ms.gov.pl)	$0.005	20+ years of bankruptcy, liquidation, merger announcements
KNF Financial Registry	KNF (3 registries)	$0.006	Licensed financial institution verification — 75,000+ entities
BDO Waste Registry	BDO (bdo.mos.gov.pl)	$0.005	Waste contractor verification for ESG/CSRD compliance
KRS Board Members	KRS PDF extracts	$0.035	Full board member names — the official API censors them

Technical note on KRS Board Members: The official KRS1 API returns person names as "L******" (censored). This actor downloads the public PDF extract from the government portal, which contains full names. It's the only way to get non-anonymized Polish company director data programmatically.

Spain (2 Actors)

Actor	Source	Price/Result	Key Use Case
BORME Corporate Acts	BORME via boe.es	$0.003	Daily corporate acts — incorporations, appointments, capital changes
Spain Company Directory	OpenData Registradores	$0.005	Company profiles with NIF, officers, CNAE codes

BORME parses the official PDFs published daily by Spain's Registro Mercantil. It extracts structured data from 500+ daily corporate acts: new company incorporations, officer appointments and dismissals, capital increases and reductions, dissolutions and mergers.

Spain Company Directory scrapes the official Colegio de Registradores open data portal (opendata.registradores.org), which launched in 2024 but has no public API. It returns NIF, legal form, registered officers, CNAE industry codes, address, and status. Requires residential proxy.

Austria (2 Actors)

Actor	Source	Price/Result	Key Use Case
Ediktsdatei Insolvency	edikte.justiz.gv.at	$0.005	Bankruptcies, reorganizations, debt settlements
WKO Business Directory	firmen.wko.at	$0.003	620,000+ businesses with phone, email, website

Ediktsdatei is the only Apify actor providing Austrian insolvency data without requiring the IWG government license. The official API at justizonline.gv.at requires "ID Austria" authentication and bureaucratic approval — this actor scrapes the public HTML pages instead.

WKO Firmen A-Z is the Austrian Chamber of Commerce's official business directory. No API exists. This actor extracts company name, address, phone, email, website, and industry classification from 620,000+ registered businesses. Useful for B2B lead generation, market entry research, and supplier discovery.

France (1 Actor)

Actor	Source	Price/Result	Key Use Case
Societe.com Company Data	Societe.com	$0.005	Directors, financials, shareholders in one profile

Societe.com aggregates data from INSEE (SIREN/SIRET), INPI (RNE), and BODACC into combined company profiles. While individual government APIs exist (API Sirene, INPI RNE), none provide the combined director-financial-shareholder profile. This actor gives you directors with roles, simplified financials (revenue, net result), shareholders, subsidiaries, NAF code, and legal form — all in a single API call. Requires residential proxy.

Cross-Border Due Diligence Workflow

Here's a concrete example: your compliance team needs to screen a counterparty that operates across Poland, Spain, and Austria.

Step 1: Poland KRS Financial Statements
  → Pull their latest balance sheet and income statement

Step 2: Poland CRBR Beneficial Owners  
  → Identify all beneficial owners with ownership percentages

Step 3: Poland KRZ Debtor Registry
  → Check for bankruptcy proceedings or outstanding debts

Step 4: Spain BORME Corporate Acts
  → Check for recent officer changes or capital restructuring at their Spanish subsidiary

Step 5: Austria Ediktsdatei Insolvency
  → Screen for insolvency proceedings at their Austrian branch

Step 6: Cross-reference
  → Join the data to build a complete risk profile

Running this manually across 5 different portals with different interfaces, languages, and search capabilities would take hours per counterparty. With the actors above, you can automate the entire pipeline.

Quick Start Example

Here's how to call any actor via the Apify API:

# Example: Run BORME scraper for a specific date
curl -X POST "https://api.apify.com/v2/acts/regdata~borme-corporate-acts-scraper/runs?token=YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "date": "2026-04-15",
    "province": "Madrid"
  }'

Or use the Apify Python client:

from apify_client import ApifyClient

client = ApifyClient("YOUR_API_TOKEN")

# Run KRS Financial Statements scraper
run = client.actor("regdata/poland-krs-financial-scraper").call(
    run_input={"companyIds": ["0000012345"]}
)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(f"Company: {item['companyName']}")
    print(f"Total assets: {item['financialData']['totalAssets']}")
    print(f"Revenue: {item['financialData']['revenue']}")

Pricing: Pay-Per-Use vs Subscriptions

Traditional European business data providers (MGBI, Bisnode/D&B, Axesor) operate on subscription models — typically hundreds or thousands of euros per month. That makes sense if you're running thousands of queries daily. But for most compliance teams, law firms, and due diligence analysts, usage is sporadic: batch checks before a deal, periodic counterparty reviews, one-off investigations.

Pay-per-use pricing means you pay only for what you need:

A single KRS financial statement costs $0.025
A BORME day's corporate acts cost $0.003 per act
A WKO business lookup costs $0.003

Running 100 KRS financial checks costs $2.50. Running 1,000 BORME act extractions costs $3.00. No monthly commitment, no minimums.

Apify's tiered pricing also reduces the per-result cost at higher volumes (GOLD and above), so production pipelines get cheaper as you scale.

Technical Notes

Free-tier friendly actors (no proxy needed, run on Apify free plan):

KRS Financial Statements
CRBR Beneficial Owners
KRZ Debtor Registry
UOKiK Abusive Clauses
MSiG Court Gazette
KNF Financial Registry
BORME Corporate Acts
Ediktsdatei Insolvency
WKO Business Directory (free tier needs higher memory setting)

Requires residential proxy (paid Apify plan):

EKW Land Registry (encrypted API + captcha)
Spain Company Directory (F5/Volterra WAF)
Societe.com Company Data (anti-bot protection)
BDO Waste Registry (React SPA with stealth detection)
KRS Board Members (PDF download requires proxy rotation)

Which Actors Should You Start With?

For compliance/KYC teams: CRBR Beneficial Owners + KRZ Debtor Registry + KRS Financial Statements. These three cover the core Polish due diligence workflow: who owns it, are they in debt, and are they financially stable.

For B2B sales teams: WKO Business Directory (620K Austrian contacts) + BORME Corporate Acts (daily Spanish new incorporations) + KRS Board Members (Polish company directors with full names).

For credit risk analysts: Ediktsdatei Insolvency (Austrian bankruptcies) + KRZ Debtor Registry (Polish debtors) + KRS Financial Statements (Polish financials).

For M&A and competitive intelligence: Societe.com (French director networks) + BORME Corporate Acts (Spanish corporate changes) + KRS Financial Statements (Polish financials).

Bottom Line

These 14 actors exist because European government registries systematically lack public APIs. If you need programmatic access to business data from Poland, Spain, Austria, or France, and you don't want to build and maintain fragile scrapers yourself, this suite covers the most commonly needed sources.

Every actor links to its Apify page with full documentation, input schemas, and example outputs. Try any of them with the Apify free tier — most actors work without a paid plan.

DEV Community: Peter

How to Scrape 620,000 Austrian Businesses from WKO Firmen A-Z (Official Chamber of Commerce Directory)

How to Scrape 620,000 Austrian Businesses from WKO Firmen A-Z (Official Chamber of Commerce Directory)

What is WKO Firmen A-Z?

The problem: no API, and WebForms makes it worse

The solution: Apify WKO Business Directory Scraper

What the output looks like

Real use case: SaaS company entering the Austrian market

How it compares to alternatives

Pricing transparency

Technical requirements

What you cannot scrape

Quick start

Bottom line

Automating Polish UBO Checks: How to Query CRBR Without an Official API

Automating Polish UBO Checks: How to Query CRBR Without an Official API

What CRBR Actually Contains

The Manual Approach (and Why It Breaks)

Three Ways to Access CRBR Data at Scale

Option 1: MGBI Subscription (~200-500 PLN/month)

Option 2: Build Your Own Scraper

Option 3: Use the Apify CRBR Actor (Pay-Per-Result)

How It Compares

Real Use Cases

What CRBR Won't Tell You

Bottom Line

European Compliance Scraper Reliability: BORME and Societe.com Configuration Guide

Fixing BORME and Societe.com Reliability Issues: A Practical Guide for European Compliance

The Reliability Challenge

BORME Corporate Acts Scraper: Configuration Guide

Common Failure Patterns

Correct Configuration

Step 1: Input Validation

Step 2: Proxy Requirements

Step 3: Optimize Date Ranges

Testing Your Configuration

Societe.com Company Data Scraper: Configuration Guide

Common Failure Patterns

Correct Configuration

Step 1: Timeout Settings

Step 2: Input Validation

Step 3: Residential Proxy Requirement

Testing Your Configuration

Production-Ready Patterns

1. Error Handling and Retries

2. Batch Processing

3. Data Validation

Troubleshooting Common Issues

BORME Issues

Societe.com Issues

Success Metrics

Getting Help

Related Tools

Your UCP Profile is Detected. But AI Agents Still Can't Buy From You.

Your UCP Profile is Detected. But AI Agents Still Can't Buy From You.

The Grade C Trap: Detection ≠ Readiness

The 3 Missing Fields Break AI Commerce

1. Missing signing_keys - The Trust Gap

2. Missing payment_handlers - The Purchase Blocker

3. Missing return_policy Schema - The Trust Builder

Why This Matters for Agentic Commerce

How to Fix Your Grade C Profile

1. Add Signing Keys

2. Configure Payment Handlers

3. Add Return Policy Schema

The BigCommerce Platform Bug

Who's Affected?

The Reality Check

Test Your AI Readiness

EKW Land Registry Scraper: Transparent Review Response & Compliance Use Cases

EKW Land Registry Scraper: Transparent Review Response & Compliance Use Cases

The Reality of Government Data Scraping: What Our 1-Star Review Tells Us

Understanding the Review Context

What Our Scrapers Actually Deliver

Data Format Complexity

Current Capabilities

Current Capabilities

Addressing Common Expectation Gaps

1. "Why isn't this as comprehensive as the official portal?"

2. "Why do some properties have incomplete data?"

1. Missing `signing_keys` - The Trust Gap

2. Missing `payment_handlers` - The Purchase Blocker

3. Missing `return_policy` Schema - The Trust Builder

1. Missing `signing_keys` - 20% of all stores

2. Missing `payment_handlers` - 23% of stores with UCP

3. Missing `return_policy` schema - 49% of all stores