Home / Blog / Article

Article · 2026-05-04

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

compliance · api · aml · kyc · 5 min read

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 14 days of the company’s entry in the KRS, and within 14 days of any change to the details already reported. Saturdays and public holidays do not count towards either deadline, so in practice both are working-day counts. Failing to report, or reporting details that do not match reality, carries a penalty of up to 1 million PLN.

If you have seen 7 days quoted, that was the deadline before the 2021 amendment. It is still repeated in a lot of secondary guidance, and at the time of writing the Ministry of Finance’s own CRBR Q&A page has not been updated either - so it is worth checking the statute rather than a summary.

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.008 per query result on the Free plan (lower on higher Apify plans, which carry a tier discount)
$0.025 actor start fee, charged once per run

For context: 100 UBO checks pulled in a single run cost about $0.83. 1,000 checks cost about $8.03. No subscription, no minimum.

Input format:

A single lookup takes nip, krs, or companyName directly. For a batch, pass queries - a list of objects, each keyed by nip, krs, name, or pesel:

{
  "queries": [
    { "nip": "6770065406" },
    { "krs": "0000057567" }
  ]
}

Leave proxyConfiguration alone. It defaults to Apify Proxy with rotating datacenter IPs because the registry enforces a per-IP request quota - turning it off will get a batch run throttled or blocked partway through.

Output for a single company. One row per query. The company’s own fields sit flat on the row - there is no nested company object - and the query you sent comes back as searchInput. Names below are placeholders; the field names are exactly what the actor returns.

{
  "requestId": "730FD9F7B65B41979D1D3BD8CCA85D58",
  "searchInput": { "nip": "6770065406" },
  "found": true,
  "name": "EXAMPLE SPÓŁKA AKCYJNA",
  "nip": "6770065406",
  "krs": "0000057567",
  "legalForm": "Spółka akcyjna",
  "postalCode": "31-864",
  "voivodeship": "MAŁOPOLSKIE",
  "city": "KRAKÓW",
  "street": "ALEJA JANA PAWŁA II",
  "houseNumber": "39A",
  "flatNumber": null,
  "foreignAddress": null,
  "foreignTrustRegister": null,
  "proceeding": null,
  "periodStart": "2026-08-13",
  "periodEnd": "2026-08-13",
  "corrected": false,
  "hasDiscrepancies": false,
  "discrepancyCount": 0,
  "beneficialOwners": [
    {
      "firstName": "JAN",
      "secondName": null,
      "lastName": "KOWALSKI",
      "pesel": "00000000000",
      "dateOfBirth": null,
      "citizenship": "POLSKA",
      "countryOfResidence": "POLSKA",
      "groupName": null,
      "trustRights": null,
      "entitlements": [
        {
          "natureOfControl": "osoba fizyczna zajmująca wyższe stanowisko kierownicze, o której mowa w art. 2 ust. 2 pkt.1 lit. a tiret 5 ustawy AML",
          "natureOfControlCode": "002",
          "controlBasisCode": 3,
          "ownershipTypeCode": null,
          "amount": null,
          "unit": null,
          "unitCode": null,
          "indirect": null,
          "privilege": null
        }
      ]
    }
  ],
  "representatives": [
    {
      "firstName": "MARCIN",
      "secondName": null,
      "lastName": "NOWAK",
      "role": "zgłaszający - członek zarządu"
    }
  ],
  "sourceUrl": "https://crbr.podatki.gov.pl/"
}

Four things that catch people out:

There is no combined full-name field. Build it from firstName + secondName + lastName; secondName is usually null.
Control is a list, not a string. entitlements holds one entry per basis of control, each with a text natureOfControl and a registry natureOfControlCode. A person can appear with several.
There is no ownership-percentage field. Where a company declared a size it arrives as amount plus unit on the entitlement, and it is null far more often than not - a beneficial owner declared on the basis of senior management has no percentage attached at all. Code that expects a percentage on every owner will break on the majority of real records.
pesel is a real national identifier. Treat every row as personal data from the moment it lands in your dataset.

Use found to separate “the register answered and holds no declaration” from a lookup that never got an answer. hasDiscrepancies and discrepancyCount surface entries the register itself has flagged as contested, and representatives names who filed the declaration - which is not the same list as the beneficial owners.

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={
        "queries": [
            {"nip": "6770065406"},
            {"nip": "1080004850"}
        ]
    }
)
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", []):
        name = " ".join(p for p in (bo["firstName"], bo["secondName"], bo["lastName"]) if p)
        basis = "; ".join(e["natureOfControl"] for e in bo.get("entitlements", []))
        print(f"{r['name']}: {name} ({basis})")

How It Compares

Factor	Manual Portal	MGBI	Apify CRBR Actor
Cost	Free	200-500 PLN/mo	$0.008/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 - official government registries across Europe, the US, UAE, Africa and LatAm, all pay-per-result with no subscription.

Turn this into working data. Browse the registries and use cases, or start free on Apify.

Originally published on Dev.to.