Germany Bank Lending Survey - Bundesbank

Germany's results of the Eurosystem Bank Lending Survey - credit standards, terms and demand by segment and quarter from the Deutsche Bundesbank, as clean per-observation records. Values are emitted verbatim.

Who buys this and for what job

• Bank strategists and economists following the Bundesbank bank lending survey for German credit conditions.
• Credit, markets and policy analysts tracking Germany credit standards and loan demand quarter by quarter.
• Researchers who need the official Bundesbank series as clean records.

Buyers usually search for this as "bundesbank bank lending survey" or "germany credit standards".

Choose the series

Question: What share of German banks tightened credit standards for companies, and how did companies' loan demand change, in the latest quarters?

{"seriesIds": ["BBBU2.Q.DE.ALL.O.E.Z.B3.ST.S.FNET", "BBBU2.Q.DE.ALL.O.E.Z.B3.ZZ.D.FNET"], "newestFirst": true, "maxRecords": 10}

Run on 30 Sep 2026 the two series held 190 quarterly values; the newest 10 were returned (10 × $0.05 = $0.50 on Apify's Free plan), for example:

Quarter	Series	Net %
2026-Q3	loan demand (enterprises)	9.68
2026-Q3	credit standards (enterprises)	9.68
2026-Q2	loan demand (enterprises)	3.23
2026-Q2	credit standards (enterprises)	16.13
2026-Q1	loan demand (enterprises)	6.45
2026-Q1	credit standards (enterprises)	16.13

Search options (all optional; a record must match every option you set, and several values in one option match any of them):

• Series ids (seriesIds) — exact Bundesbank ids, e.g. BBBU2.Q.DE.ALL.O.E.Z.B3.ST.S.FNET (credit standards for enterprises, overall, net percentage) and BBBU2.Q.DE.ALL.O.E.Z.B3.ZZ.D.FNET (loan demand from enterprises).
• Words in the series title (titleWords) — the titles are German; English shortcuts work: credit standards, credit terms, loan demand, housing loans, consumer credit, SMEs, large enterprises, overall.
• Borrowers (borrowers) — enterprises or households.
• Measure (measures) — net percentage, diffusion index or mean.
• Horizon (horizons) — past three months or next three months.
• From / to quarter (fromQuarter, toQuarter) — e.g. 2024-Q1.
• Newest first (newestFirst) — latest quarter first.

Options are tested on every row of the Bundesbank file before the record limit. Note the Bundesbank dates each value by its publication quarter; the answers refer to the previous quarter (Bundesbank comment on every series). With no option set the actor returns the flow exactly as before.

What one record represents

The source is the Deutsche Bundesbank statistics REST API at api.statistiken.bundesbank.de, read as keyless SDMX-CSV from the BBBU2 flow (Germany results of the Bank Lending Survey). Each record is one survey dimension tuple x quarter - the Bundesbank series key and title, the survey dimensions (bank selection, item, count, time horizon, effect domain, market role, aggregation method), the period, the value and the unit. Every column present is emitted, so no dimension is dropped.

Sample output

Real rows from a live run of this actor (first 5 rows, selected columns).

One full record from the same run, exactly as delivered:

{
  "dataflow": "BBK:BBBU2(1.0)",
  "bbk_std_freq": "Q",
  "bbk_std_area_world": "DE",
  "bbk_bls_bank_selection": "ALL",
  "bbk_bls_item": "BC",
  "bbk_bls_count": "E",
  "bbk_bls_count_detail": "LE",
  "bbk_bls_time_horizon": "B3",
  "bbk_bls_effect_domain": "ST",
  "bbk_bls_market_role": "S",
  "bbk_bls_agg_method": "A",
  "time_period": "2008-Q2",
  "obs_value": 3,
  "time_format": "P3M",
  "bbk_decimals": "2",
  "bbk_id": "BBBU2.Q.DE.ALL.BC.E.LE.B3.ST.S.A",
  "bbk_unit": "percent",
  "bbk_unit_mult": "0",
  "bbk_title": "Kreditgewährung / Unternehmen / Große Unternehmen / Kreditrichtlinien (Kreditstandards) / Auswirkungen der Konkurrenz durch andere Banken / vierteljährlich / In den letzten drei Monaten / Mittelwert",
  "bbk_comm_gen": "Zeitangabe ist Veröffentlichungsdatum; Werte beziehen sich außer bei den Prognosewerten auf das vorangegangene Quartal",
  "web_category": "BAUK",
  "bbk_diff": null,
  "bbk_diff_y": null,
  "record_id": "BBBU2.Q.DE.ALL.BC.E.LE.B3.ST.S.A:2008-Q2",
  "source": "Deutsche Bundesbank (ESCB)",
  "source_dataset": "Deutsche Bundesbank Bank Lending Survey - Germany (BBBU2)",
  "licence": "Deutsche Bundesbank / ESCB statistics. Under the ESCB terms for the re-use of statistics, these data may be re-used free of charge for commercial and non-commercial purposes provided the source is quoted and the statistics and their metadata are not modified. Only Bundesbank/ECB-sourced statistical aggregates are emitted; any third-party-sourced rows are structurally excluded.",
  "attribution": "Source: Deutsche Bundesbank (ESCB); re-used under the ESCB terms, values unmodified",
  "caveat": "One record per Bank Lending Survey dimension tuple x quarter from the Deutsche Bundesbank BBBU2 flow (Germany results of the Eurosystem Bank Lending Survey), read as SDMX-CSV. The live flow holds 43,284 observations (Sol's Wave-5 index counted 42,513; the series has grown since - the live count is the honest one and is quoted here). Values are emitted verbatim per the ESCB 'unmodified' term. The flow carries no third-party-source column, so all rows are Bundesbank/ECB; the third-party guard still runs. Aggregate survey statistics, no personal data.",
  "observed_at": "2026-09-25T17:19:11Z"
}

Coverage, the source rule and versioning

Default changed on 30 Sep 2026: if you leave maxRecords out, a run now returns up to 10 records (it was 500). Set maxRecords yourself to get more — the maximum is unchanged.

The live flow holds 43,284 observations. Sol's Wave-5 index counted 42,513; the survey has published further quarters since, so the live count is higher - the live measure is the honest one and is what this listing quotes. Under the ESCB re-use terms the statistics and metadata are emitted unmodified: values are carried verbatim and the source is stamped on every record. The flow carries no third-party-source column, so all rows are Bundesbank/ECB; a third-party guard still runs on every row so that, were a non-Bundesbank source ever present, it would be structurally excluded.

Licence

Deutsche Bundesbank / ESCB statistics. Under the ESCB terms for the re-use of statistics, the data may be re-used free of charge for commercial and non-commercial purposes provided the source is quoted and the statistics and their metadata are not modified. Values are emitted verbatim; the source is carried on every record. Any third-party-sourced rows are structurally excluded.

Sibling Actors

Different publisher and geography, no dataset-row overlap.

Fields, scheduling and integration

Every field in the record is either a source-native identifier, a source-native attribute, or one of the six provenance fields (source, source_dataset, licence, attribution, caveat, observed_at) the fleet attaches to every record. Nothing is derived or inferred beyond the small, documented transforms noted above, and nothing is dropped silently - the handling section spells out exactly what is excluded and why. The grain is one record per the natural unit of the source, which keeps each row independently meaningful, keeps the key stable across runs so re-running is a cheap upsert rather than a re-import, and lets you aggregate up to whatever unit you need without unpicking a pre-joined table.

Because the source republishes on its own cadence, a scheduled run keeps a downstream table current: new and changed records upsert over the old ones on the stable key, and the observed_at stamp tells you when each was last seen live. Set Maximum records low to sample the shape of the data cheaply, then raise it once the cell fits your use; the Actor streams or partitions its source, so memory stays flat regardless of how many records you request, and you are billed only for what is delivered. The output is a flat table of typed records, so it drops straight into whatever you already use: load the run's dataset over the API or an export, key on the record id, and upsert. Because identifiers are preserved exactly as the source publishes them, joins across the fleet's cells - and onto your own systems - work without a mapping layer. There is no subscription and no minimum: the per-record price and the record cap together mean the spend on any run is known in advance and matched exactly to the data you receive.

Reconciling counts honestly

Where the live count differs from any previously published figure, the live measure is the honest one and is what this listing quotes; sources re-issue and re-version their data over time. The run receipt always states what was actually delivered and charged and confirms the two agree, so every run is auditable against itself regardless of what any external index expected.

Scaling, scheduling and support

A common pattern is a light scheduled run that pulls the newest slice into a staging table, then a merge on the stable key into the table your product reads, so you never re-pay for rows you already hold and your history grows cleanly over time. Because the record shape assumes no particular warehouse, language or tool, the integration work is a load and a merge, not a cleaning project: the same code path handles a 40-row sample and a full pull, and the only thing that changes between them is the record cap. If you only need a slice, the cap and any partition or filter inputs bound the run precisely, so a targeted pull costs cents rather than the price of the whole set, and a broad pull is simply a higher cap left to run. Nothing about the delivery is subscription-gated: each run stands alone, priced at exactly the records it returns, so you can dial spend up or down run by run as your needs change, and a scheduled cadence keeps a downstream table current without any standing commitment. When the source publishes a correction or a new period, the next run picks it up and upserts it over the stale row on the same key, so the table you maintain stays both complete and current with no manual reconciliation.

Provenance and compliance

Every run reads the door host's robots.txt at runtime and records the result (URL, status, byte length and, where a policy is served, its SHA-256) in the run's RUN_RECEIPT. Where the host serves no applicable policy - a 404, a 403, or a homepage redirect - the gate records that as a flag and proceeds on the licence, which grants re-use; a flag is never treated as permission in itself. The endpoint is keyless and the Actor reads only the public data door - never a mirror, and it never bypasses a block.

Data quality and freshness

Numbers arrive as real numbers, booleans as real booleans, and every other value as a string or null, so the dataset loads without a cleaning pass. Each record is keyed on a stable composite of the source's own identifiers, so it is safe to diff, deduplicate or upsert. Every run re-reads the live door, so the data is as fresh as the source publishes, and each record's observed_at stamp dates the snapshot. The receipt records how many rows were delivered and charged and confirms charge_equals_delivered.

Billing, delivery and joins

Pricing is per record: you are billed only for records the Actor actually delivers, and the charge is raised after each record is pushed (push-then-charge), so a failed or empty run costs nothing. The Maximum records cap bounds every run, so spend is known before you start - sample cheaply, then raise it. Every record is a flat, typed object keyed on a stable id, so it loads without a cleaning pass, diffs cleanly between runs, and upserts into a table you keep over time; re-running keeps that table current without re-paying for rows you already hold, and each receipt reconciles delivered against charged. Because the source's own identifiers are preserved verbatim, the dataset joins onto other sources keyed on the same identifier.

Who buys this, and how they use it

This cell is bought by teams that need the source's published set as a typed, keyed table they can hold and refresh rather than a page they scrape: market- and macro-intelligence teams sizing and tracking a market, data engineers wiring a clean upstream feed into a warehouse, and compliance and research teams building on a stable identifier. The grain and the key are chosen so the output is a building block, not a one-off export - you run it on a schedule, keep the delta, and join it to your other sources on the identifiers it preserves verbatim. The spend on any run is the per-record price times the records delivered, matched exactly to what you receive.