# Intl Test Data Generator: UK NINO, BE RRN, DE Steuer-ID (`codeclouds/internationale-testdata-generator`) Actor

Generate checksum-valid test identifiers for UK/BE/DE software QA: UK National Insurance Numbers (HMRC-reserved ZZ prefix), Belgian Rijksregisternummer, German Steuer-ID, mod-97 IBANs and Visa/Mastercard/Amex sandbox card numbers — each record labeled with an explicit guarantee level.

- **URL**: https://apify.com/codeclouds/internationale-testdata-generator.md
- **Developed by:** [Dennis](https://apify.com/codeclouds) (community)
- **Categories:**
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $0.60 / 1,000 generated-identifiers

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## International Test Data Generator: UK NINO, BE RRN, DE Steuer-ID

Generate checksum-valid test identifiers for UK, Belgian and German software QA: UK National Insurance Numbers using HMRC's officially never-issued `ZZ` prefix, Belgian Rijksregisternummer (mod-97), German Steuer-ID (ISO 7064 MOD 11,10), mod-97-valid IBANs, and the same Visa/Mastercard/American Express sandbox card numbers used across this portfolio. Every record includes an explicit **guarantee level** — this actor never claims a stronger safety guarantee than what could actually be verified per country. 100% deterministic, pure computation — no scraping, no external calls at runtime.

**⚠️ For test/development purposes only.** These identifiers must never be used as a substitute for a real national ID/IBAN/credit card in production, and never for identity fraud. See the Legal section below — read it carefully, the guarantee level differs meaningfully by country.

### When should an AI agent use this?

- "Give me 10 valid test UK National Insurance Numbers I can use in a payroll integration's unit tests."
- "Generate a Belgian Rijksregisternummer and a German Steuer-ID for testing my EU-wide KYC form's country-specific validation logic."
- "I need reproducible international test IBANs for BE, DE and GB fixtures — use seed 42."
- "Build me a full international test identity: NINO, IBAN and credit card, for a UK customer record in my e2e test suite."
- "Does my Steuer-ID checksum validator work correctly? Give me a known-good example."
- "I need 100 fake Belgian national ID numbers for a load test, but I want to know exactly how confident I can be that none of them belong to a real person."

### What this Actor does

- **UK — National Insurance Number (NINO)**: always uses the `ZZ` prefix, which HMRC's own National Insurance Manual (NIM39110) explicitly documents as "not to be used" — the strongest guarantee of the three countries.
- **Belgium — Rijksregisternummer (RRN/INSZ)**: uses a structurally impossible birth date (30 or 31 February, which never exists on the Gregorian calendar) combined with a correctly computed mod-97 check digit. **Weaker guarantee than UK** — no official Belgian reserved test range could be confirmed to exist (see Legal section).
- **Germany — Steuerliche Identifikationsnummer (Steuer-ID)**: a correctly computed ISO 7064 MOD 11,10 checksum over 10 random digits. **Weakest guarantee of the three** — no official German test range could be confirmed either; only checksum validity is guaranteed (see Legal section).
- **IBAN**: full mod-97-valid IBANs for Belgium and Germany (Belgium additionally gets a correct national BBAN check digit); a UK/GB IBAN is also available but clearly labeled — the UK does not use IBANs for domestic payments.
- **Credit card**: the same official, publicly documented Visa/Mastercard/American Express sandbox numbers used across this portfolio (not country-specific).
- Optional `seed` parameter for **fully reproducible** runs.

### Guarantee levels — read this before using the output for anything sensitive

| Country / field | `guaranteeLevel` | What it actually means |
|---|---|---|
| 🇬🇧 UK NINO | `official-reserved-range` | HMRC's own manual explicitly states the `ZZ` prefix is "not to be used" — never issued to a real person. Strongest guarantee. |
| 🇧🇪 BE Rijksregisternummer | `structurally-impossible-date` | Uses 30/31 February, a calendar date that never exists — a logically sound but **not officially government-labeled** test convention. No official Belgian reserved test range was found. Weaker than UK. |
| 🇩🇪 DE Steuer-ID | `checksum-valid-only` | The checksum is correctly computed, but **no confirmed official test range exists**. A checksum-valid Steuer-ID is not proven to be unissued. Weakest guarantee of the three national IDs. |
| BE / DE IBAN | `checksum-valid-only` | Mod-97-valid, but no officially reserved "never-issued" bank code was found. |
| UK/GB IBAN | `checksum-valid-only` | Same caveat, plus: the UK does not normally use IBANs domestically — only relevant for international/SEPA-style contexts. |
| Credit card | `official-reserved-range` | Publicly documented official sandbox numbers (Visa/Mastercard/Amex via Stripe and other certified processors). |

### Input

| Field | Type | Description |
|---|---|---|
| `countries` | array | Which countries to generate `nationalId`/`iban` records for: `UK`, `BE`, `DE`. Default: all three. Does not affect `creditCard` (not country-specific). |
| `types` | array | Which identifier types to generate: `nationalId`, `iban`, `creditCard`. Default: all three. |
| `count` | integer | How many identifiers to generate per selected type **per selected country** (`creditCard` is generated once in total, not per country). Default `10`, max `10000`. |
| `creditCardNetwork` | array | Which card networks to draw from: `visa`, `mastercard`, `amex`. Default: all three. |
| `seed` | integer | Optional. Set a fixed number to make repeated runs produce the exact same identifiers. |

### Output

One flat JSON record per generated identifier:

```json
{
  "type": "nationalId",
  "country": "UK",
  "value": "ZZ123456A",
  "isValidChecksum": true,
  "guaranteeLevel": "official-reserved-range",
  "sourceRangeNote": "UK NINO met het ZZ-prefix — HMRC National Insurance Manual NIM39110 ..."
}
```

```json
{
  "type": "nationalId",
  "country": "DE",
  "value": "48127395606",
  "isValidChecksum": true,
  "guaranteeLevel": "checksum-valid-only",
  "sourceRangeNote": "Duits Steuer-ID-vormig nummer, checksum-geldig volgens het officiële ISO 7064 MOD 11,10-kettingalgoritme ..."
}
```

| Field | Description |
|---|---|
| `type` | One of the requested identifier types: `nationalId`, `iban`, `creditCard` |
| `country` | `UK`, `BE` or `DE` — omitted for `creditCard` (not country-specific) |
| `value` | The generated identifier itself |
| `isValidChecksum` | Whether the value passes the relevant checksum/format check for that type |
| `guaranteeLevel` | See the "Guarantee levels" table above — read this before treating the value as "safe" |
| `sourceRangeNote` | Transparency field: exactly which source/reasoning this value's safety claim rests on, including any relevant disclaimer |

### Use cases

- Populate a UK payroll or benefits form's automated test suite with a safely never-issued NINO
- Test a KYC/onboarding flow's country-specific national ID validation for BE and DE, with clear disclosure of how confident each generated value is
- Generate reproducible international fixture data for CI pipelines (`seed` parameter)
- Give an AI coding agent a reliable "tool" for producing valid international test data instead of letting it invent (possibly incorrect, possibly unsafe) checksum logic itself
- Stress-test bulk-import/validation pipelines with syntactically valid IBANs across three countries

### Pricing

Pay-per-event: **$0.0006 per generated identifier** (`generated-identifier` event), plus Apify's standard actor-start fee. Generating 30 identifiers across three countries (10 national IDs each) costs roughly $0.018.

### Legal & safety

- **UK NINO**: uses exclusively the `ZZ` prefix, which HMRC's own National Insurance Manual (gov.uk/hmrc-internal-manuals/national-insurance-manual/nim39110) explicitly documents as "not to be used" for a real NINO. Highest-confidence national ID in this Actor.
- **BE Rijksregisternummer**: **no officially published Belgian reserved test range could be confirmed to exist**, unlike the UK NINO or the RvIG BSN range used in this portfolio's `nl-testdata-generator`. This Actor instead uses a structurally impossible birth date (30/31 February) — a logically sound argument (no real person can have that birth date) but not a government-labeled test convention. Treat BE output as lower-confidence than UK.
- **DE Steuer-ID**: **no officially published German reserved test range could be confirmed either.** Only the checksum algorithm is guaranteed correct. Two frequently-cited "example" numbers (from an official ELSTER/ITZBund illustration document) are explicitly excluded from this Actor's output, because that same official source states they must never be used for test or live transmissions — but the generated values themselves carry no stronger guarantee than "passes the checksum". This is the lowest-confidence identifier type in this Actor.
- **IBAN**: bank codes used (BE/DE numeric, UK `TEST` prefix) are not confirmed to be officially reserved "never-issued" codes. A valid mod-97 checksum does **not** prove the account exists — never use for a real payment. The UK/GB IBAN is provided for international/SEPA-style testing only; the UK does not use IBANs for domestic payments.
- **Credit card**: only the literal, publicly documented official sandbox numbers from Visa/Mastercard/American Express are used — never a self-constructed Luhn-valid number.
- This Actor is intended **exclusively for software testing and development purposes**. Never use generated identifiers as a substitute for a real national ID, IBAN, or credit card in a production system, in a real financial transaction, or for identity fraud.

### FAQ

**Is the Belgian or German output as safe as the UK output?**
No. Read the "Guarantee levels" table above. Only the UK NINO rests on an explicit official "never issued" statement. BE and DE are weaker, clearly labeled guarantees — see the Legal section for the full reasoning.

**Why does DE only get `checksum-valid-only` and not a reserved range like BSN/NINO?**
Because no official German test range could be found during research, and the two publicly cited "example" Steuer-IDs are explicitly marked by the official ELSTER source as never to be used for test/live purposes — so this Actor deliberately avoids treating either as a safe convention, and instead only guarantees checksum correctness.

**Can I get the same identifiers again later?**
Yes — set the `seed` input field to any fixed number.

**Does a duplicate credit card number across records mean something is broken?**
No — there are only 5 official sandbox numbers in total (across all 3 networks combined), so duplicates are expected once you request more results than that.

***

### Keywords

NINO generator, national insurance number test, UK national insurance number generator, rijksregisternummer generator, INSZ nummer generator, belgisch rijksregisternummer test, steuer-id generator, steuerliche identifikationsnummer test, german tax id generator, iban generator, mod 97 checksum, luhn algorithm, credit card test numbers, qa test data, fixture data generator, international test identifier, MCP tool test data

### Changelog

- **v0.1** (2026-08-25) — Initial release: UK NINO (HMRC ZZ prefix), BE Rijksregisternummer (structurally impossible date), DE Steuer-ID (checksum-valid-only), BE/DE IBAN (full mod-97), UK/GB IBAN (labeled, SEPA-context only), credit card (Visa/Mastercard/Amex sandbox numbers). Optional `seed` for reproducible runs. Every record carries an explicit `guaranteeLevel`.

# Actor input Schema

## `countries` (type: `array`):

Which countries to generate national ID / IBAN records for. Does not affect credit card generation (not country-specific).

## `types` (type: `array`):

Which types of test identifiers to generate. `nationalId` and `iban` are generated once per selected country; `creditCard` is generated once total (not country-specific).

## `count` (type: `integer`):

How many identifiers to generate per selected type per selected country (creditCard: total, not per country).

## `creditCardNetwork` (type: `array`):

Which card networks to draw official sandbox test numbers from. Not country-specific.

## `seed` (type: `integer`):

Set a fixed number to make repeated runs produce the exact same identifiers (useful for reproducible test fixtures). Leave empty for a different result on every run.

## Actor input object example

```json
{
  "countries": [
    "UK",
    "BE",
    "DE"
  ],
  "types": [
    "nationalId",
    "iban",
    "creditCard"
  ],
  "count": 10,
  "creditCardNetwork": [
    "visa",
    "mastercard",
    "amex"
  ]
}
```

# Actor output Schema

## `results` (type: `string`):

Results stored in the default dataset.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "countries": [
        "UK",
        "BE",
        "DE"
    ],
    "types": [
        "nationalId",
        "iban",
        "creditCard"
    ],
    "creditCardNetwork": [
        "visa",
        "mastercard",
        "amex"
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("codeclouds/internationale-testdata-generator").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "countries": [
        "UK",
        "BE",
        "DE",
    ],
    "types": [
        "nationalId",
        "iban",
        "creditCard",
    ],
    "creditCardNetwork": [
        "visa",
        "mastercard",
        "amex",
    ],
}

# Run the Actor and wait for it to finish
run = client.actor("codeclouds/internationale-testdata-generator").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "countries": [
    "UK",
    "BE",
    "DE"
  ],
  "types": [
    "nationalId",
    "iban",
    "creditCard"
  ],
  "creditCardNetwork": [
    "visa",
    "mastercard",
    "amex"
  ]
}' |
apify call codeclouds/internationale-testdata-generator --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,codeclouds/internationale-testdata-generator"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/RyYiq76fXYu4ppKYQ/builds/rTCchYzbsfv9T4gty/openapi.json