Datenquellen verknüpfen in Berliner Start-ups und Fintechs

Das Wichtigste auf einen Blick

Für datennachschlag.de ist der Berliner Fall ein Ausschnitt aus dem größeren Thema betriebliche Daten und Analytik. Im Kern geht es um Datenintegration, Datenqualität, Data Warehousing, Reporting und Governance.

Wer Datenquellen verknüpft, schafft eine analytische Grundlage für Controlling, Risikomanagement und operative Entscheidungen. Die folgenden Abschnitte zeigen diese allgemeinen Muster am Beispiel von Start-ups und Fintechs. Leserinnen und Leser aus anderen Branchen können die beschriebenen Schritte auf ihre eigenen Systeme übertragen.

Warum Berliner Start-ups und Fintechs auf verknüpfte Datenquellen setzen

Berlin ist die Start-up-Hauptstadt Deutschlands. Besonders Fintechs und Health-Techs entwickeln hier datengetriebene Geschäftsmodelle. Sie konkurrieren mit etablierten Banken und Versicherern, die über jahrzehntelange Datenbestände verfügen.

Datenquellen verknüpfen bedeutet, Informationen aus verschiedenen Systemen zusammenzuführen. Das können öffentliche Register, offene Datenportale oder interne CRM- und Transaktionsdaten sein. Erst die Verknüpfung schafft Mehrwert: Ein Fintech erkennt beispielsweise Zahlungsausfälle, indem es Handelsregisterdaten mit Transaktionshistorien kombiniert.

Der Berliner Markt ist dicht. Über 500 Fintechs sind in der Hauptstadt aktiv. Wer hier bestehen will, braucht belastbare Datenpipelines. Die Verknüpfung von Datenquellen ist deshalb keine technische Nebensache, sondern Teil des Geschäftsmodells.

Ein weiterer Grund ist die Geschwindigkeit. Daten aus fremden Quellen verkürzen die Entwicklungszeit, weil eigene Erhebungen entfallen. Wer Registerdaten geschickt einsetzt, spart Personal und Kapital.

Öffentliche Register und offene Daten als Basis

Öffentliche Register sind für Start-ups eine kostengünstige Datenquelle. Das Handelsregister liefert Informationen zu Gesellschaften, Geschäftsführern und Beteiligungen. Das Transparenzregister gibt Auskunft über wirtschaftlich Berechtigte. Beide Register sind über das Unternehmensregister oder die Länderjustizportale zugänglich.

Für Registerabrufe fallen je nach Zugang Gebühren an. Ein einfacher Handelsregisterauszug über das gemeinsame Registerportal kostet in der Regel 4,50 EUR. Beglaubigte Ausdrucke liegen häufig bei rund 10 EUR. Kommerzielle Anbieter verlangen für programmatische API-Abrufe Abonnements oder Preise pro Abruf.

Daneben stehen offene Daten der öffentlichen Verwaltung. Berlin betreibt ein Open-Data-Portal mit Datensätzen zu Verkehr, Bevölkerung und Infrastruktur. Der Bund stellt über GovData ebenfalls zahlreiche Datensätze bereit. Diese Daten sind meist frei nutzbar, unterliegen aber Lizenzbedingungen.

Für Fintechs sind auch Daten der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) relevant. Sie veröffentlicht Unternehmensdatenbanken und Zulassungsinformationen. Wer diese Quellen mit eigenen Daten verknüpft, kann Risiken früh erkennen.

Ein Beispiel: Das Berliner Fintech FinCompare prüft die Bonität von Geschäftskunden. Es kombiniert Handelsregisterdaten mit Zahlungsverhalten aus eigenen Transaktionen. So entsteht ein Risikoprofil, das ohne externe Register nicht möglich wäre.

Wichtig ist die Aktualität. Registereinträge ändern sich, wenn Geschäftsführer wechseln oder Kapital erhöht wird. Automatisierte Abrufe halten die Daten frisch. Wer nur einmal im Jahr importiert, arbeitet mit veralteten Informationen.

Interne Datenquellen anbinden: von CRM bis Transaktionsdaten

Interne Datenquellen sind oft heterogen. Ein Start-up nutzt vielleicht ein CRM für Kundenbeziehungen, ein ERP für Buchhaltung und eine eigene Anwendung für Transaktionen. Diese Systeme sprechen unterschiedliche Sprachen. Die Kunst besteht darin, sie zu verbinden.

Zunächst müssen die Daten identifiziert werden. Welche Tabellen enthalten Kundeninformationen? Welche Felder lassen sich verknüpfen? Eine eindeutige Kunden-ID ist der Schlüssel. Fehlt sie, müssen Matching-Verfahren eingesetzt werden.

Dann folgt die technische Anbindung. Moderne Start-ups setzen auf APIs, um Systeme zu verbinden. Ältere Systeme bieten oft nur Datenbankzugriff oder Dateiexporte. Hier helfen ETL-Tools, die Daten extrahieren, umformen und laden.

Wichtig ist die Datenqualität. Nach DIN 66398 sollten Daten vollständig, konsistent und aktuell sein. Dubletten und veraltete Einträge verfälschen Analysen. Regelmäßige Bereinigungen sind Pflicht.

Schließlich müssen die Daten zentral verfügbar sein. Ein Data Warehouse oder ein Data Lake bündelt die Quellen. Von dort aus können Analyse- und Reporting-Tools darauf zugreifen. Die Online-Dienste der Verbraucherzentrale richten sich an Verbraucher, nicht an Data-Teams.

Ein Praxisbeispiel: Das Berliner Health-Tech Ada Health verbindet CRM-Daten mit Abrechnungsdaten. So erkennt es, welche Kunden welche Leistungen nutzen. Der Vertrieb erhält Hinweise auf Cross-Selling-Potenziale.

Datenquellen verknüpfen ohne DSGVO-Verstoß

Die DSGVO setzt enge Grenzen. Wer personenbezogene Daten verknüpft, braucht eine Rechtsgrundlage. Das BDSG als Rechtsgrundlage ergänzt die DSGVO für den nichtöffentlichen Bereich. Ohne Rechtsgrundlage ist die Verarbeitung unzulässig.

Die Grundsätze der Zweckbindung und Datenminimierung sind zu beachten. Eine Verarbeitung von Daten ist ausschließlich für den vorgesehenen Zweck erlaubt. Wer Registerdaten mit Kundendaten verknüpft, muss diesen Zweck dokumentieren. Eine Datenschutz-Folgenabschätzung kann erforderlich sein.

Start-ups sollten frühzeitig Datenschutzhinweise erstellen. Die Aufsichtsbehörden bieten Hinweise und Muster zur DSGVO. Diese helfen, typische Fehler zu vermeiden.

Besonders kleine und mittlere Unternehmen brauchen pragmatische Lösungen. Der Landesbeauftragte für Datenschutz in Nordrhein-Westfalen stellt spezielle Informationen zu Datenschutz im KMU bereit. Sie lassen sich auf Berliner Verhältnisse übertragen.

Ein häufiger Fehler ist die fehlende Löschfrist. Verknüpfte Daten müssen gelöscht werden, wenn der Zweck entfällt. Wer keine Fristen definiert, riskiert Bußgelder. Ein Löschkonzept gehört deshalb in jedes Datenprojekt.

Werkzeuge und Architekturen für junge Unternehmen

Die Werkzeugwahl hängt von Budget und Teamgröße ab. Open-Source-Lösungen sind für Start-ups attraktiv. Apache Airflow orchestriert Datenpipelines. dbt bereitet Daten in SQL auf. Fivetran und Airbyte verbinden Quellen per Connector.

Die Lizenzkosten unterscheiden sich stark. Apache Airflow und dbt Core sind Open Source und kosten keine Lizenzgebühren. Kommerzielle Connector-Dienste rechnen nach Datenvolumen ab; für kleine Teams sind 100 bis 500 EUR monatlich eine typische Größenordnung. Cloud-Dienste wie BigQuery oder Snowflake berechnen Speicher und Abfragen nach Verbrauch.

Für die Speicherung bieten sich Cloud-Dienste an. Amazon S3, Google BigQuery oder Snowflake sind skalierbar. Sie erfordern jedoch Datenschutzprüfungen, insbesondere bei US-Anbietern. Der Einsatz in der EU ist vorzuziehen.

Eine typische Architektur umfasst drei Schichten: Extraktion, Aufbereitung und Bereitstellung. In der Extraktionsschicht werden Register- und interne Daten gesammelt. Die Aufbereitungsschicht bereinigt und verknüpft sie. Die Bereitstellungsschicht stellt sie für Analysen bereit.

Sicherheit ist ein weiterer Baustein. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt Verschlüsselung und Zugriffskontrollen. Start-ups sollten diese Empfehlungen umsetzen, um Haftungsrisiken zu minimieren.

Auch die Wahl der Programmiersprache spielt eine Rolle. Python ist in Berliner Data-Teams weit verbreitet. Bibliotheken wie pandas oder PySpark beschleunigen die Verarbeitung. Wer SQL beherrscht, hat ebenfalls gute Karten.

Beispiel: ein Fintech verknüpft Register- und Kundendaten

Das Berliner Fintech FinCompare vermittelt Geschäftskredite. Ein möglicher Ablauf für die Verknüpfung von Register- und Kundendaten sieht so aus.

Schritt 1: Das Fintech ruft täglich das Handelsregister ab. Es speichert Firmendaten, Geschäftsführer und Kapitalangaben.

Schritt 2: Aus dem eigenen System werden Kunden- und Transaktionsdaten extrahiert. Jeder Kunde hat eine eindeutige ID.

Schritt 3: Ein Matching-Algorithmus verbindet Registereinträge mit Kundendatensätzen. Firmenname und Adresse dienen als Schlüssel.

Ein konkretes Schema kann so aussehen:

CREATE TABLE kunde (
  kunden_id TEXT PRIMARY KEY,
  firma_normalisiert TEXT,
  plz TEXT,
  adresse TEXT
);
CREATE TABLE register_abruf (
  register_id TEXT,
  firma_normalisiert TEXT,
  plz TEXT,
  geschaeftsfuehrer TEXT,
  kapital_eur NUMERIC,
  abrufdatum DATE
);

Als Scoring-Features dienen Kapitalhöhe, Zahlungsverzugstage, Transaktionsvolumen und Wechsel der Geschäftsführung.

Schritt 4: Die verknüpften Daten fließen in ein Scoring-Modell. Es bewertet die Wahrscheinlichkeit eines Zahlungsausfalls.

Schritt 5: Das Ergebnis wird im CRM angezeigt. Der Vertrieb sieht, welche Kunden ein erhöhtes Risiko tragen.

Rechtlich kommt Art. 6 Abs. 1 lit. b und lit. f DSGVO in Betracht. Die Kunden werden in der Datenschutzerklärung informiert.

Ob die Verknüpfung wirkt, zeigt sich an Kennzahlen wie Ausfallquote und Bearbeitungszeit. Diese Werte muss jedes Unternehmen selbst messen.

Häufige Fragen