Contact Us

Deterministic test data for banking and insurance

DATAMIMIC is the test data platform for regulated banking and insurance. It generates deterministic, reproducible, CI/CD-ready test data, including valid ISO 20022 and SWIFT messages, without production data ever leaving your environment.

Connect a database or import JSON, model entities and relationships once, then run it from any pipeline via REST/OpenAPI. Referential integrity holds across tables, collections, and deeply nested payloads.

 

Start with the docs
Talk to an expert

Key Benefits

Model-based control

Define precise structures and rules to enforce strict referential integrity. Ensure consistent test data management across complex applications.

Deterministic Generation

Same engine version, same model, same seed, byte-identical output, on any machine, months later. Model-driven generation needs no production data to begin with.

JSON/XML mastery

Advanced handling of complex JSON and XML including deeply nested, API-style payloads used in microservices.

Built for regulation

De-identification techniques (tokenization, format-preserving encryption, pseudonymization, field-level masking) for teams measured against GDPR Art. 25, DORA and BCBS 239. Every run is logged and traceable.

CI/CD friendly API

Automate generation in pipelines via REST and run headless in DevOps/CI to seed test environments on every build.

Visual modeling

A clear layer to inspect quality checks & relations so data stewards can validate models in a data-quality framework.

How it works

DATAMIMIC connects directly to your databases or ingests files like JSON to auto-generate a model of your data, then lets you refine entities and relationships so generated datasets stay consistent across tables, NoSQL collections and deeply nested JSON/XML. Because it’s model-based, outputs preserve referential integrity and support trusted data solutions for test, dev and training. Through documented REST/OpenAPI endpoints you can run it headless in CI/CD to keep test environments consistently seeded without copying production data.

Use cases

Teams use DATAMIMIC to build realistic, privacy-compliant datasets for QA and staging without exposing production records, to run integration and end-to-end tests that depend on stable cross-entity links (customers ↔ orders, payments ↔ accounts), and to produce API-ready, JSON/XML payloads for microservice and banking/fintech scenarios — all inside a GDPR-compliant, synthetic-data workflow.

Ship faster with privacy-safe test data that mirrors your systems.

DATAMIMIC generates realistic, synthetic datasets from a model of your structures, so relationships stay intact across tables and even deeply nested JSON/XML. Because it’s built for regulated teams and GDPR-friendly workflows, you can test without exposing production data—and you can trigger generation headlessly via REST/OpenAPI in CI/CD to keep staging consistently seeded.

 

Deploy DATAMIMIC as SaaS or on-premise—via Docker/Podman or Helm on Kubernetes/OpenShift—and use the visual modeling UI to inspect entities, define data-quality checks, and enforce referential integrity; then automate generation through the REST API with project access tokens, or keep projects versioned by syncing a DATAMIMIC project to a specific Git branch so test-data definitions stay in lockstep with your codebase

See DATAMIMIC in action

Explore real projects where teams used model-based synthetic data to move faster and stay compliant — from a European tier-1 bank that took test-data preparation from 20 to 28 days down to about 12 hours per cycle across Oracle, MongoDB and Kafka, to a public-sector education platform that replaced 10,000 lines of custom Python with 1,200 lines of DATAMIMIC models across roughly 30 schemas, with no real student data in non-production. See how trusted data solutions from DATAMIMIC removed the need for manual masking while keeping data realistic enough for E2E and API tests.

View case studies

Automate in your pipeline

Hook DATAMIMIC into your delivery process with the documented REST/OpenAPI endpoints, run it headless to provision synthetic data on every build, and even sync projects to a Git branch so test-data definitions stay in lockstep with your codebase. This lets DevOps teams enforce repeatable, GDPR-compliant test data and ship under regulatory pressure with trusted data solutions. For trials or support, contact the team.

datamimic.io
F.A.Q

Frequently Asked Questions.

Frequently Asked Questions about working with us
How to create complex data for testing?
DATAMIMIC is model-driven. The platform reads your schema or source data and builds a model from it: entities, relationships, field types, and a proposal for which field gets which de-identification technique. You review and override that proposal before anything runs. Execution is then rule-based and deterministic. Where distributions matter, such as transaction amounts or claim frequencies, auto-regressive ML generators are used in addition, versioned and quality-graded. In practice, complex means three things: deeply nested JSON, foreign keys that have to line up across tables and collections, and message formats that have to be valid against their schema. The model covers all three in one run.
The distinction matters under GDPR. Anonymization alters data so individuals cannot be re-identified, even in combination with other information; such data is no longer personal data. Pseudonymization replaces direct identifiers with a pseudonym but leaves re-linking possible via separately held information, so pseudonymized data remains personal data (Art. 4(5), Recital 26). DATAMIMIC supports both, and the mode is a decision, not a side effect. With a seed set, output is deterministic and reproducible, and the result is pseudonymization. Drop the seed and output is non-reproducible, with the transformed fields irreversible. That alone does not make a record anonymous: quasi-identifiers such as age, postcode, timestamps or amount patterns must also be generalized or suppressed. DATAMIMIC flags those fields in its risk review and provides the converters to coarsen them.
Better in several ways, worse in one, and the difference is predictable. Better: a production copy is a perfect snapshot of the normal cases and misses exactly the edge cases testing needs, because rare combinations stay rare in an extract. From a model you produce them deliberately and in any volume, along with states that do not exist in production yet, such as a message format ahead of a migration or a volume profile for load testing. Worse: a model only knows what was modelled. Irregularities buried in your production data that nobody described will not appear in the synthetic set. That is why DATAMIMIC starts from a model of your real structures rather than a generic template, and why the model stays an artifact you maintain.
Production copies in test and development environments are the standard case of unnecessary exposure: more people with access than in production, longer retention, weaker controls. DATAMIMIC addresses the cause. Test data comes from a model, and generation needs no production records. Where real data must be involved, the de-identification runs inside your own environment. This directly addresses data minimisation under GDPR Art. 5(1)(c) and privacy by design under Art. 25. Compliance remains a property of your processing as a whole, not of any single tool. What DATAMIMIC contributes is the evidence: every run is logged with task ID, timestamps, model version and content hash, and can be reconstructed identically months later. When proof is missing, the system blocks the operation instead of falling back silently.
Yes. Native connectors for PostgreSQL, Oracle, MongoDB and Apache Kafka, plus SWIFT MT, HL7 and EDIFACT. The REST/OpenAPI endpoints are documented and integrate with Jenkins, GitLab CI or Azure DevOps. Run it as SaaS, on-premise via Docker/Podman, or with Helm on Kubernetes and OpenShift, including fully offline, with no telemetry and no call-home.
Yes. pacs.008 and pain.001 in the ISO 20022 space, MT103 and MT202 COV in SWIFT MT, plus EDIFACT and HL7. Messages are valid by construction against the relevant schema, not validated after the fact. For camt messages, validation against the registered schemas is available today; generation is not. You can download, adjust and upload your own or diverging spec versions without waiting for a release.
It works through the platform, not around it. A DATAMIMIC project bundles models, environments, and permissions, and synchronizes with a Git branch, ensuring that test data definitions remain in sync with the code. The DATAMIMIC extension brings this project context directly into the editor. Schema validation, auto-completion, and error diagnostics are provided by a language server operated by the platform on a project-specific, authenticated basis. Consequently, no schema or environment-specific data exists as a local copy outside the platform. This same interface is also available to a coding agent operating within the editor. Execution still takes place via the platform, utilizing the same permissions, authorization protocols, and logging mechanisms as a run initiated from the web interface. The editor streamlines the workflow; it does not create a separate, parallel path.

Ready to generate safe, realistic test data?

Clear next steps—read the quickstart or book a short call; we’ll map entities, relationships, and CI/CD triggers together.
Talk to an expert
Contact us