Dutch Test Data: Generate Valid Test BSNs, IBANs and BRP Records

If you build or test software for a Dutch bank, insurer, pension administrator, or government supplier, you run into the same wall over and over: your application validates identity and payment data, so your test data has to be valid, but privacy law says it cannot be real.

A random 9-digit string is not a BSN. Your validation layer rejects it before your test even starts. Copying a production record into the test environment makes the test pass, and quietly turns your acceptance environment into a GDPR incident.

This guide covers how Dutch test data actually works: what makes a BSN, IBAN, or BRP record structurally valid, why production data does not belong in test environments, and how to generate compliant test data in seconds, by hand or automated.

Why You Cannot Use Real Personal Data in Test Environments

Under the GDPR (in the Netherlands: the AVG), personal data may only be processed for the purpose it was collected for. Customer data was collected to administer an account or a pension, not to debug your acceptance environment. The Dutch Data Protection Authority (Autoriteit Persoonsgegevens) has been explicit that production personal data in test environments needs a legal basis that teams almost never have.

On top of the legal problem there is a practical one: test environments have weaker access controls, more people with admin rights, more logging in plain text, and more copies floating around. If a data leak is going to happen anywhere, it happens in the environment nobody hardened.

The standard answer is synthetic test data: records that behave exactly like real ones in every technical check, but are guaranteed not to belong to any real person or account.

What Makes a Test BSN Valid: the Elfproef

A burgerservicenummer (BSN) is not a random 9-digit number. It has to pass the elfproef (11-check): multiply each digit by its position weight (9, 8, 7, 6, 5, 4, 3, 2, and -1 for the last digit), sum the results, and the total must be divisible by 11.

Any serious Dutch system validates this before accepting input. That means test data has to pass the same check, or your forms and APIs reject it at the front door.

The Test BSN Generator produces numbers that pass the elfproef but are not issued to real persons, so you can fill databases, test forms, and CI fixtures without touching anyone's identity. Generate one for a quick manual test or a hundred for a seed script.

Test IBANs with Correct Check Digits

IBANs have the same property: the two check digits after the country code are calculated with a mod-97 algorithm over the whole account number. Payment modules, onboarding flows, and import validators all run this check.

The Test IBAN Generator generates IBANs with correct mod-97 check digits for the Netherlands, Germany, Belgium, France, and the United Kingdom. Dutch test IBANs use realistic bank codes (ABNA, INGB, RABO, and others), so they also look right in UIs and reports. The accounts do not exist, so nothing can ever be transferred.

Want to verify the other direction? The IBAN Validator checks any IBAN's structure and checksum, which is handy when a test fails and you need to know whether the data or the code is wrong.

Full Persons: BRP Persoonslijst Test Records

Sometimes a number is not enough and you need a whole person: name, birth date, address history, partnerships, the works. Dutch government-adjacent systems structure this data as a persoonslijst following the BRP (Basisregistratie Personen) category model: category 01 for identity, 04 for nationality, 05 for partnerships, 08 for residence, and so on.

The BRP Test Data Generator produces complete persoonslijst records in that category structure, including consistent BSNs (elfproef-valid), plausible municipalities, and history categories. For pension administration chains there is also a UPA File Generator that produces Uniforme Pensioenaangifte test files with consistent totals.

Everything is generated in your browser. Nothing you generate is stored on a server.

Automating Test Data in CI and Fixtures

Clicking a generator works for exploratory testing, but pipelines want automation. The ToolForte REST API exposes the test data generators as JSON endpoints. A free API key covers 1,000 calls per month, which is plenty for seeding CI runs:

`bash curl -X POST https://toolforte.com/api/v1/tools/test-iban-generator \ -H "Authorization: Bearer tf_YOUR_KEY" \ -H "Content-Type: application/json" \ -d '{"country": "NL", "count": 25}' `

The same endpoint exists for test BSNs. Responses are plain JSON arrays you can pipe straight into fixtures, database seeds, or Postman collections. The full OpenAPI 3.1 spec is available if you prefer generated clients.

If your team works with AI assistants, the ToolForte MCP server exposes the same generators as tools for Claude, Cursor, and other MCP clients, so an agent writing your test cases can generate valid Dutch test data mid-task instead of inventing numbers that fail validation.

Rules of Thumb for Safe Test Data

A few practices that keep test environments clean:

• Generate, never copy. Synthetic data that passes validation beats anonymized production data. Anonymization fails more often than it succeeds, and under the AVG pseudonymized data is still personal data.
• Mark it clearly. Use obviously fake names alongside valid numbers where the format allows it, so a screenshot from a test environment can never be mistaken for production.
• Regenerate per run. Fresh data per CI run catches bugs that fixed fixtures hide, like ordering assumptions and uniqueness constraints.
• Keep validity where it matters. BSNs and IBANs must pass their checksums; free-text fields can and should be visibly fake.
• Watch chain partners. In pension and banking chains, files travel between organizations. Test files (UPA, payment batches) must be internally consistent or the receiving system rejects the delivery for the wrong reason.

For the complete overview of Dutch test data generators, including document numbers and UPA files, see the Dutch test data page.