Speakers: Michael Sprecher (Integration Engineer Synthetic Data, LGT Bank) & Sebastian Köhler (Senior Consultant, LGT Bank) | Swiss Testing Day 2026 | Room 5, 10:45
Key Takeaways
- A model-based approach solves the dual-platform problem – A semantic model describes test customers in business terms and can be provisioned both on-premises (Avaloq) and in the cloud (microservices).
- Everything as code – The model, personas, and data orders are Python code in Git. Versioning, branching, testing, and releases work just like in any other software project.
- Synthetic data eliminates data breach risk – No cloning of production data, no DLP issues, just consistent, reproducible test data at the push of a button.
When Five Core Banking Systems and a Cloud Need Testing
LGT Private Banking Group faces a unique challenge: five independent Avaloq instances worldwide, a decoupling layer of microservices above them, and front services for client advisors on top. Development happens in the public cloud — but the core banking system Avaloq cannot move to the cloud for architectural and data protection reasons. At Swiss Testing Day 2026, Michael Sprecher and Sebastian Köhler showed how LGT solves this with synthetic test data.
The Problem: Testing Across Platform Boundaries
Production data? Not available in the cloud. Manually maintaining static test data on both sides? A bottomless pit. LGT needed a platform-independent approach.
The architecture challenge: On-premises (in-house) with Avaloq and the cloud with microservices – connected by iSynth.
The Solution: iSynth — A Model-Based Approach
The solution rests on three building blocks:
1. Personas — Customer archetype constellations: individual clients, legal entities, external asset managers, joint accounts. A handful of prototypes cover the essential test scenarios.
2. Generic model — Deliberately simplified compared to the full banking model. Only what is needed for the test case: accounts, portfolios, positions, currencies, powers of attorney.
3. Data order (“the recipe”) — A structured text file configuring the test customer. Based on the Given-When-Then approach: the recipe describes the Given block.
“A business analyst at our company once said: ‘This is my recipe.’ That nails it.”
Everything as Code
The deliberate choice against proprietary formats: the model is Python code, personas are code, recipes are structured text files — all in Git. This brings versioning, branching, test suites, and releases out of the box.
The complete data flow: The tester places an order via a recipe → iSynth applies the model and personas → synthetic data is generated → an adapter provisions it in Avaloq or the cloud microservices.
“We treat the development of synthetic test data like any other software project.”
Dual Provisioning: One Recipe, Two Platforms
The recipe is platform-independent. The magic lies in the adapters:
-
- On-premises: Adapter transforms iSynth data into Oracle-based Avaloq protocols. Customer is created, replicated through the decoupling layer into front services.
-
- Cloud: Same order, same model. Adapter transforms into microservice protocols (Kafka, Protobuf, PostgreSQL, Redis). iSynth generates its own IDs, acting as a “virtual core banking system.”
Structurally identical data on both platforms — from the same recipe.
Beyond Testing
Synthetic data proved more versatile than expected: training videos, demos for potential clients, sandboxes for PoCs, and CSV deliveries for various consumers.
Zero Data Breach Risk
Learnings: Synthetic data as a consumable – stable, consistent, reproducible. And: no data breach risk.
“With synthetic data, I fundamentally have no data breach risk. It’s eliminated by nature.”
An anecdote: Michael once emailed data to Sebastian in the heat of the moment. At 6:30 PM, compliance called. The DLP scanner worked — but the data was synthetic. No problem.
Critical Success Factors
- Simplify as much as possible — do not rebuild the core banking system
- Domain knowledge is essential — more important than Python skills
- Testers own the preconditions in the recipe
- Test data is consumable — not hoarded, but regenerated on demand
“I’d rather have someone who knows the difference between a Lombard loan and a mortgage than someone who writes Python code in no time.”
Plattformübergreifende Bereitstellung synthetischer Testdaten
Speaker: Michael Sprecher (Integration Engineer Synthetic Data, LGT Bank) & Sebastian Köhler (Senior Consultant, LGT Bank) | Swiss Testing Day 2026 | Room 5, 10:45
Key Takeaways
- Modellbasierter Ansatz löst das Dual-Platform-Problem — Ein semantisches Modell beschreibt Testkunden fachlich und kann sowohl On-Premises (Avaloq) als auch in der Cloud (Microservices) provisioniert werden.
- Everything as Code — Modell, Personas und Datenbestellungen sind Python-Code in Git. Versionierung, Branching, Testing und Releases funktionieren wie bei jedem Software-Projekt.
- Synthetische Daten eliminieren Data-Breach-Risiko — Kein Klonen produktiver Daten, keine DLP-Probleme, konsistente und reproduzierbare Testdaten auf Knopfdruck.
Wenn fünf Kernbanksysteme und eine Cloud getestet werden müssen
Die LGT Private Banking Group steht vor einer besonderen Herausforderung: Fünf eigenständige Avaloq-Instanzen weltweit, darüber ein Decoupling Layer aus Microservices, darüber die Front Services für Kundenberater. Die Entwicklung findet in der Public Cloud statt — aber das Kernbankensystem Avaloq kann aus Architektur- und Datenschutzgründen nicht in die Cloud. Michael Sprecher und Sebastian Köhler zeigten am Swiss Testing Day 2026, wie die LGT dieses Problem mit synthetischen Testdaten löst.
Das Problem: Wie testet man über Plattformgrenzen hinweg?
Produktive Daten? In der Cloud gar nicht vorhanden. Statische Testdaten manuell auf beiden Seiten pflegen? Ein Fass ohne Boden. Die LGT brauchte einen Ansatz, der plattformunabhängig funktioniert.
Die Architektur-Herausforderung: On-Premises (Haus) mit Avaloq und Cloud mit Microservices — verbunden durch iSynth.
Die Lösung: iSynth — ein modellbasierter Ansatz
Die Lösung basiert auf drei Bausteinen:
1. Personas — Archetypen von Kundenkonstellationen: individuelle Kunden, juristische Personen, externe Asset Manager, gemeinsame Konten. Eine Handvoll Prototypen deckt die wesentlichen Testszenarien ab.
2. Generisches Modell — Fachlich bewusst vereinfacht. Nicht das komplette Kernbankensystem nachbauen, sondern nur das, was für den Testfall nötig ist: Konten, Portfolios, Positionen, Währungen, Vollmachten.
3. Datenbestellung (“Das Rezept”) — Ein strukturiertes Textfile, das den Testkunden konfiguriert. Orientiert am Given-When-Then-Ansatz: Das Rezept beschreibt den Given-Block.
“Eine Business-Analystin bei uns hat gesagt: ‘Das ist mein Rezept.’ Das trifft es ziemlich gut.”
Alles ist Code
Sebastian Köhler erklärte die bewusste Entscheidung gegen proprietäre Formate: Das Modell ist Python-Code, die Personas sind Code, die Rezepte sind strukturierte Textfiles — alles in Git.
Der komplette Datenfluss: Tester bestellt über Rezept → iSynth wendet Modell und Personas an → Synthetische Daten → Adapter provisioniert in Avaloq oder Cloud-Microservices.
Die Vorteile:
- Versionierung out of the box
- Branching für Feature-Entwicklung an synthetischen Testdaten
- Testsuite validiert Daten vor dem Merge
- Releases — verschiedene Umgebungen nutzen verschiedene Stände
“Wir behandeln die Entwicklung von synthetischen Testdaten wie ein normales Software-Projekt.”
Dual-Provisioning: Ein Rezept, zwei Plattformen
Das Rezept ist plattformunabhängig. Die Magie liegt in den Adaptern:
- On-Premises: Adapter transformiert iSynth-Daten in Oracle-basierte Avaloq-Protokolle. Kunde wird angelegt, repliziert über Decoupling Layer in die Front Services. IDs kommen vom Kernbankensystem.
- Cloud: Gleiche Datenbestellung, gleiches Modell. Adapter transformiert in Microservice-Protokolle (Kafka, Protobuf, PostgreSQL, Redis). iSynth generiert selbst IDs und agiert als “virtuelles Kernbankensystem”.
Strukturell identische Daten auf beiden Plattformen — aus demselben Rezept.
Über Testing hinaus
Synthetische Daten haben sich als vielseitiger erwiesen als erwartet:
- Schulungsvideos — Produktive Daten können nicht gefilmt werden
- Demos und Pitching — E-Banking-Lösung für potenzielle Kunden vorführen
- Sandboxes — Daten für PoCs und Experimente
- CSV-Lieferungen — für verschiedenste Konsumenten
Kein Data-Breach-Risiko
Learnings: Synthetische Daten als Verbrauchsmaterial — stabil, konsistent, reproduzierbar. Und: kein Data-Breach-Risiko.
“Mit synthetischen Daten habe ich grundsätzlich kein Risiko eines Data Breach. Das ist von Natur aus eliminiert.”
Dazu eine Anekdote: Michael schickte Sebastian in der Hitze des Gefechts Daten per E-Mail. Um 18:30 rief die Compliance an. Der DLP-Scanner funktionierte — aber die Daten waren synthetisch. Kein Problem.
Kritische Erfolgsfaktoren
- Vereinfache so weit wie möglich — nicht das Kernbankensystem nachbauen
- Fachliches Wissen ist elementar — wichtiger als Python-Kenntnisse
- Tester trägt Verantwortung für korrekte Vorbedingungen
- Testdaten sind Verbrauchsmaterial — nicht horten, sondern jederzeit neu erzeugen
“Mir ist lieber, ich habe jemanden, der den Unterschied zwischen einem Lombardkredit und einer Hypothek kennt, als dass er mir Zeilen Python-Code in null Komma nichts schreibt.”
Über die Speaker
Michael Sprecher ist Integration Engineer Synthetic Data bei der LGT Bank. Sebastian Köhler ist Senior Consultant bei der LGT Bank. Gemeinsam verantworten sie den modellbasierten Ansatz iSynth für die plattformübergreifende Bereitstellung synthetischer Testdaten.
Swiss Testing Day 2026 — “Defining Quality in a Dangerous Decade” — StageOne, Zürich, 26. März 2026Berichterstattung: Xebia
