Entity Resolution im eigenen Cloud-Konto der Bank: Checkliste für die Beschaffung 2026

Kurzfassung: Ja. Eine Bank kann Entity Resolution im eigenen Cloud-Konto betreiben, wenn sie die Kontrolle über Schlüssel, Audit-Protokolle, Zugriffe, Änderungen und den Exit belegen kann. Die eigene Account-Grenze ist nützlich, doch die Beschaffungsentscheidung braucht zusätzlich ein getestetes Verantwortungsmodell, Nachweise zur Resilienz und prüfbare Matching-Kontrollen.

Demo buchen · Tilores Studio kostenlos testen

Auf dieser Seite

1. Kann eine Bank Entity Resolution im eigenen Cloud-Konto betreiben?
2. Welche Nachweise gehören vor die Vorauswahl?
3. Wem gehören Zugänge, Schlüssel und Protokolle?
4. Welche Produktnachweise müssen vorliegen?
5. Welche Vertragsbelege braucht der Einkauf?
6. Wie führen Sie einen belastbaren Abnahmetest durch?
7. Wann ist die Entscheidung belastbar?
8. Wichtige Begriffe
9. Welche Fragen bleiben häufig offen?
10. Prüfen Sie die Kontrollgrenze mit Ihren eigenen Anforderungen
11. Quellen

Für ein Bankteam kann ein Deployment im eigenen Cloud-Konto so wirken, als sei die Kontrollfrage bereits beantwortet. Daten und Infrastruktur bleiben in einer vertrauten Grenze, während die Entity Resolution dieselben Kunden-, Financial-Crime- und Betriebsentscheidungen unterstützt, die diesen Einsatz so wichtig machen.

Diese Grenze ist jedoch nur der Anfang des Kontrollnachweises. Schlüsselverwaltung, Zugriffe, Protokolle, Änderungen, Resilienz und Exit-Rechte brauchen Belege, die Beschaffung, Sicherheit und Recht prüfen können. Entscheidend ist deshalb, wie Architektur, Betriebsmodell und Vertrag diese Verantwortlichkeiten zuordnen und ob die Bank das Ergebnis vor dem Produktivbetrieb testen kann.

Kann eine Bank Entity Resolution im eigenen Cloud-Konto betreiben?

Ja. Wir können im eigenen AWS-Konto der Bank laufen. Auf AWS nutzt das Deployment DynamoDB, SQS und S3 in der VPC der Bank. Die Daten bleiben dabei in der Umgebung der Bank. Die aktuelle Übersicht der Deployment-Optionen beschreibt diese Kontrollgrenze. Wie dieselbe Engine auf AWS, einer anderen Cloud oder On-Premise-Hardware läuft, beschreibt Infrastrukturunabhängige Entity Resolution: Tilores auf AWS, einer anderen Cloud oder eigener Hardware betreiben.

Diese Antwort eröffnet die Prüfung, sie beendet sie nicht. Ein eigenes Konto zeigt zunächst, wo Infrastruktur und Daten liegen. Es beweist noch nicht, wer Rollen verändern darf, welche Supportwege existieren, wie Updates freigegeben werden, ob Protokolle manipulationsgeschützt sind oder ob die Bank die Anwendung ohne unerwartete Abhängigkeit verlassen kann.

Die Beschaffungsfrage sollte deshalb lauten: Kann die Bank jede wesentliche Zusage durch einen technischen, betrieblichen oder vertraglichen Beleg bestätigen? Eine Architekturfolie ist kein Beleg. Akzeptabel sind unter anderem eine auslesbare Ressourcenkonfiguration, ein ausgeführter Zugriffstest, ein unveränderbarer Protokolleintrag, eine Vertragsklausel mit eindeutigem Geltungsbereich oder ein protokollierter Wiederanlauf.

Welche Nachweise gehören vor die Vorauswahl?

Beginnen Sie mit einer Evidence Matrix. Jede Zeile enthält eine Kontrollfrage, den verlangten Beleg, den Eigentümer des Belegs und ein eindeutiges Bestehenskriterium. Das verhindert, dass ein allgemeines Sicherheitsdokument als Antwort auf eine konkrete Architekturfrage akzeptiert wird.

Kontrollbereich	Verlangter Beleg	Bestehenskriterium	Verantwortung
Konto und Region	Ressourceninventar, Konto-ID, genehmigte Regionen	Alle produktiven Komponenten liegen innerhalb der genehmigten Grenze	Cloud Platform
Netzwerk	Datenflussdiagramm, Egress-Regeln, DNS- und Endpoint-Konfiguration	Jeder ein- und ausgehende Pfad ist begründet und getestet	Network Security
Identitäten	Rollenmatrix, Richtlinien, temporäre Supportrolle	Keine dauerhafte unkontrollierte Rolle und kein gemeinsames Administratorkonto	IAM
Schlüssel	Key Policy, Rotation, Wiederherstellungs- und Sperrtest	Freigabe, Nutzung und Änderung sind nachvollziehbar getrennt	Security
Protokolle	Organisation Trail, Aufbewahrung, Alarmierung, Beispielereignisse	Administrative und produktbezogene Ereignisse sind suchbar und geschützt	SOC
Entity Resolution	Testkorpus, Matching-Regeln, Schwellen, Fehlentscheidungen	Treffer, Nichttreffer und Grenzfälle sind reproduzierbar erklärt	Data und Compliance
Betrieb	Runbook, Updateprozess, Backup, Wiederanlauf, Vorfallablauf	Die Bank kann einen Ausfall und eine fehlerhafte Änderung beherrschen	Operations
Vertrag und Exit	Auditrechte, Unterauftragnehmer, Datenrückgabe, Löschung, Übergangsplan	Technischer Test und Vertrag beschreiben dieselbe Betriebsrealität	Einkauf und Recht

Ordnen Sie jeden Beleg einer Version und einem Datum zu. Ein Bericht über eine andere Produktvariante, einen anderen Hostingmodus oder eine frühere Architektur kann Hintergrund liefern, darf aber nicht stillschweigend als Nachweis für das angebotene Deployment gelten.

Wem gehören Zugänge, Schlüssel und Protokolle?

AWS beschreibt Sicherheit und Compliance ausdrücklich als geteilte Verantwortung. Das eigene Konto verschiebt wichtige Kontrollen zur Bank, beseitigt aber nicht ihre Pflicht, diese Kontrollen richtig zu konfigurieren. Die AWS Beschreibung des Shared Responsibility Model nennt insbesondere Zugriffsverwaltung, Verschlüsselung und Monitoring als Kundenaufgaben. Im eigenen Konto kann die Bank sogenannte customer managed keys in AWS KMS anlegen, besitzen und vollständig selbst steuern, und sie legt fest, wohin ihr eigener CloudTrail-Trail die Protokolldateien liefert. Genau diese beiden Punkte, Schlüsselhoheit und Protokollhoheit, sollte die Vorauswahl konkret verlangen, nicht nur die allgemeine Aussage einer geteilten Verantwortung.

Fordern Sie deshalb für Menschen und Maschinen getrennte Rollen an. Dokumentieren Sie, wer Deployments auslösen, Konfigurationen ändern, Daten abfragen, Exporte erstellen, Schlüssel verwenden und Protokolle lesen darf. Ein Supportzugriff sollte zeitlich begrenzt, genehmigt, protokolliert und widerrufbar sein. Der Test muss auch zeigen, was bei verweigertem Zugriff geschieht.

Verlangen Sie einen ausgeführten Nachweis für die tatsächlich angebotene Konfiguration: erlaubte und abgewiesene Schlüsseloperationen, Rollen- und Regeländerungen sowie produktive Abfragen müssen einer Identität, einer Zeit, einer Ressource und einem kontrollierten Aufbewahrungsort zugeordnet sein. Die Bank bestimmt, wer diese Protokolle kontrolliert und wie lange sie verfügbar bleiben.

Der Test sollte eine erlaubte und eine abgewiesene Schlüsseloperation, eine Rollenänderung, eine Konfigurationsänderung und eine produktive Abfrage umfassen. Für jedes Ereignis notiert die Bank Identität, Zeit, Ressource, Entscheidung und Speicherort des Nachweises. Erst dann wird aus einer vorhandenen Logging-Funktion ein belastbarer Kontrollbeleg.

Fünf getrennte Nachweisspuren, nicht eine einzelne Anbieterzusage, sollten in die Beschaffungsentscheidung einfließen.

Welche Produktnachweise müssen vorliegen?

Der operative Zugriff erfolgt vollständig über die GraphQL API. Lassen Sie die Bank deshalb die geplanten Abfragen mit ihren eigenen Rollen, Freigaben und Lastprofilen ausführen. Der Test muss zeigen, welche Daten ein berechtigter Verbraucher erhält und welche Quellen für einen nicht berechtigten Verbraucher gesperrt bleiben.

Für den Matcher müssen deterministische, fuzzy und probabilistische Verfahren getrennt geprüft werden. Bauen Sie ein kontrolliertes Testset mit eindeutigen Treffern, Schreibvarianten, fehlenden Attributen, widersprüchlichen Angaben und bewusst ähnlichen Nichttreffern. Jede akzeptierte Verknüpfung braucht eine verständliche Regel oder Bewertung. Jede abgelehnte Verknüpfung braucht ebenfalls einen nachvollziehbaren Grund.

Normalisierte Werte werden persistiert; Originalwerte bleiben erhalten. Prüfen Sie daher nicht nur die aufgelöste Entität, sondern auch Herkunft, Originalwert, normalisierte Form und die Belege für jede Verbindung. Wir stellen Datenherkunft sowie Protokolle für Abfragen, Exporte und Löschungen bereit. Die Übersicht zu Datenschutz und Sicherheit beschreibt diese Plattformkontrollen.

Wir haben ein SOC 2 Type I Audit abgeschlossen. Fordern Sie den Bericht im vorgesehenen vertraulichen Prüfprozess an und gleichen Sie Zeitraum, Systemgrenze und geprüfte Kontrollen mit dem konkreten Angebot ab. Ein Bericht ersetzt weder die Architekturprüfung der Bank noch die Abnahme ihrer eigenen Konfiguration.

Für Finanzdienstleistungen gehört außerdem ein End-to-End-Test mit Sanktionen, PEPs und adverse media in den Plan. Entity Resolution soll den richtigen Personen- oder Organisationskontext an bestehende Screening- und Fallmanagementsysteme liefern. Sie trifft nicht selbst die Risikoentscheidung. OpenSanctions unterscheidet unter anderem sanktionierte Entitäten und politisch exponierte Personen. Seine Dokumentation zur Risikoklassifikation kann beim Aufbau repräsentativer Testfälle helfen.

Welche Vertragsbelege braucht der Einkauf?

Vertrag, Architektur und Betriebsmodell müssen dieselbe Antwort geben. Wenn das Design Daten im Konto der Bank vorsieht, dürfen Supportklauseln keinen pauschalen, dauerhaften oder unprotokollierten Datenzugriff eröffnen. Wenn Updates aus der Ferne verwaltet werden, müssen Freigabe, technische Rolle, Protokollierung, Notfallstopp und Rücknahme erklärt sein.

Prüfen Sie die Anwendbarkeit getrennt: DORA Artikel 2 nennt die erfassten Arten von Finanzunternehmen. Die EBA-Auslagerungsleitlinien von 2019 betreffen Einrichtungen innerhalb des EBA-Mandats; die 2026 veröffentlichten Drittparteien-Leitlinien sollen den bisherigen Auslagerungsrahmen erst ablösen, wenn sie anwendbar werden. Ob die konkrete Bank und Leistung darunterfallen, muss die Bank mit Rechts- und Compliance-Team bestimmen. Die DSGVO gilt für die hier beschriebenen Verarbeitungsvorgänge nur, wenn ihre sachlichen und räumlichen Voraussetzungen erfüllt sind; ihr räumlicher Geltungsbereich kann auch Verantwortliche und Auftragsverarbeiter außerhalb der EU erfassen, wie die EDPB-Leitlinie erläutert. Andere Banken ordnen dieselben Kontrollfragen ihren eigenen Aufsichts- und Datenschutzregeln zu.

Für IKT-Leistungen, die kritische oder wichtige Funktionen unterstützen, verlangt DORA uneingeschränkte Zugangs-, Inspektions- und Auditrechte. Eine EIOPA-Q&A zu Artikel 30 Absatz 3 bestätigt, dass diese Anforderung bereits in der Verordnung steht. Die Bank sollte die konkrete Anwendung mit Recht, Compliance und Aufsichtsexperten beurteilen. Das ist keine Rechtsberatung.

Die Eigentümerschaft des AWS-Kontos bestimmt nicht automatisch, wer im Datenschutzrecht Verantwortlicher, Auftragsverarbeiter oder Unterauftragsverarbeiter ist. Halten Sie Zwecke, Weisungen, tatsächliche Zugriffe und Verarbeitungsschritte fest und lassen Sie die Rollen rechtlich zuordnen. Wo die DSGVO greift, verlangt Artikel 28, dass ein Auftragsverarbeiter Prüfungen durch den Verantwortlichen oder dessen beauftragten Prüfer ermöglicht und dazu beiträgt. Vertrag und Belegprozess müssen dieses Recht praktisch nutzbar machen.

Die EBA-Outsourcing-Leitlinien sehen einen angemessenen Übergangszeitraum nach Vertragsende vor. Der Vertrag sollte deshalb Datenformat, Exportumfang, Fristen, Unterstützung, Kosten, Löschbestätigung und die Behandlung von Backups festlegen. Ein Exit, der nur als Kündigungsrecht existiert, aber technisch nicht geprobt wurde, ist noch keine belastbare Kontrolle.

Fragen Sie zusätzlich nach Unterauftragnehmern, Vorfallmeldungen, Wiederanlaufzielen, Schwachstellenbehandlung und Änderungen an der Systemgrenze. Für jede Antwort sollte es eine Klausel, einen kontrollierten Prozess oder einen ausgeführten Test geben. Formulierungen wie branchenüblich oder nach bestem Bemühen ersetzen kein messbares Abnahmekriterium.

Wie führen Sie einen belastbaren Abnahmetest durch?

1. Kontrollgrenze festlegen. Erfassen Sie Konto, Region, VPC, Endpoints, Speicherorte, Quellsysteme und nachgelagerte Verbraucher. Markieren Sie jeden geplanten Datenfluss und jeden administrativen Pfad.
2. Zugriffe praktisch prüfen. Führen Sie erlaubte und abgewiesene Aktionen mit Bankrollen, Maschinenrollen und dem vereinbarten Supportverfahren aus. Speichern Sie Richtlinie, Ereignis und Ergebnis zusammen.
3. Matching und Datenherkunft testen. Nutzen Sie ein versioniertes Korpus mit Positivfällen, Nichttreffern und Grenzfällen. Rekonstruieren Sie für ausgewählte Entitäten jede Quelle, Normalisierung und Matching-Entscheidung.
4. Regulierte Abläufe einbeziehen. Welche Inputs ein solcher Test konkret braucht, beschreibt Entity Resolution Proof of Concept: 7 PoC-Inputs für Banken im Jahr 2026. Diese Inputs ergänzen die Kontrollnachweise, die Einkauf und Test parallel liefern müssen. Übergeben Sie aufgelöste Personen und Organisationen an die vorhandenen Kontrollen für Sanktionen, PEPs und adverse media. Prüfen Sie, dass Fallmanagement und menschliche Entscheidung klar außerhalb der Auflösungsschicht bleiben.
5. Betrieb stören. Simulieren Sie eine verweigerte Rolle, einen nicht verfügbaren Dienst, eine fehlerhafte Konfiguration und die Wiederherstellung aus einem definierten Stand. Messen Sie nicht nur Verfügbarkeit, sondern auch Datenintegrität und Belegkette.
6. Exit ausführen. Exportieren Sie Daten und Konfiguration in den vereinbarten Formaten, stellen Sie eine Stichprobe außerhalb der laufenden Instanz wieder her und prüfen Sie Lösch- sowie Aufbewahrungsnachweise.
7. Abnahme protokollieren. Verknüpfen Sie jede Anforderung mit Beleg, Ergebnis, Abweichung, Risikoeigentümer und Entscheidung. Offene Punkte erhalten Termin und Verantwortlichen, keine stillschweigende Freigabe.

Verwenden Sie reale Strukturen, aber minimierte oder synthetische Werte, bis Rechtsgrundlage, Zweck und Schutzmaßnahmen für Produktionsdaten freigegeben sind. Das Ziel ist keine perfekte Demo. Das Ziel ist ein reproduzierbarer Nachweis, der auch einem unabhängigen Prüfer verständlich bleibt.

Wann ist die Entscheidung belastbar?

Die Auswahl ist belastbar, wenn die Bank jede wesentliche Kontrollaussage beantworten kann: Was wurde geprüft, mit welchem Beleg, in welcher Systemgrenze, durch wen und mit welchem Ergebnis? Ein eigenes Cloud-Konto ist dann kein Marketingmerkmal, sondern eine nachgewiesene Betriebsgrenze.

Bleibt eine Antwort offen, muss der Einkauf sie als offene Bedingung, akzeptiertes Risiko oder Ausschlussgrund behandeln. So verhindert die Bank, dass Produktfähigkeit, Cloud-Konfiguration, interner Betrieb und Vertragsrecht zu einer einzigen unscharfen Zusage verschmelzen.

Das Modell im eigenen Konto ist nicht für jede Bank der richtige Ausgangspunkt. Eine Bank ohne eigenes Cloud-Platform- oder Security-Team, das diese Verantwortungsmatrix selbst tragen kann, oder mit einer Beschaffungsvorgabe für einen vollständig durch Dritte betriebenen Dienst, sollte dieses Modell nicht wählen. Der bessere Ausgangspunkt ist dort unsere Managed Cloud auf AWS: wir betreiben die Infrastruktur vollständig, sodass die Bank einen vertraglich geregelten Dienst und dessen Prüfbericht bewertet, statt ein eigenes Schlüssel- und Protokollmanagement aufzubauen und zu betreiben.

Wichtige Begriffe

• Entity Resolution: Das Erkennen und Verbinden von Datensätzen, die dieselbe reale Person oder Organisation beschreiben.
• Cloud Account: Die administrative und technische Kontogrenze, in der Cloud-Ressourcen betrieben und gesteuert werden.
• Audit Trail: Eine nachvollziehbare Folge von Ereignissen, Identitäten und Änderungen.
• adverse media: Negative Medieninformationen, die ein bestehender Prüf- oder Fallmanagementprozess als Risikosignal bewertet.

Welche Fragen bleiben häufig offen?

Reicht ein Deployment im eigenen AWS-Konto als Compliance-Nachweis?

Nein. Der Standort ist nur ein Teil des Nachweises. Die Bank muss zusätzlich belegen, wer die Schlüssel hält, wer die Protokolle besitzt, und muss Zugriffe, Betrieb, Vertrag und Exit prüfen.

Muss die Bank dem Anbieter dauerhafte Datenzugriffe geben?

Nein. Für unser Modell im eigenen AWS-Konto bleiben die Daten in der Umgebung der Bank. Die konkrete Betriebsrolle und jeder Supportpfad müssen trotzdem im Architekturtest belegt werden.

Welche Matching-Verfahren sollte die Bank testen?

Deterministische, fuzzy und probabilistische Verfahren sollten getrennt mit Positivfällen, schwierigen Varianten, Nichttreffern und Grenzfällen geprüft werden.

Muss ein Machbarkeitsnachweis personenbezogene Produktionsdaten verwenden?

Nein. Beginnen Sie mit minimierten oder synthetischen Werten, bis Rechtsgrundlage, Zweck, Freigaben und Schutzmaßnahmen für echte Produktionsdaten geklärt sind. Erst ein genehmigter, repräsentativer Datensatz prüft anschließend das tatsächliche Matching unter kontrollierten Bedingungen.

Ersetzt ein SOC 2 Type I Bericht die Prüfung der Bank?

Nein. Er ist ein vertraulich zu prüfender Nachweis für seinen geprüften Zeitraum und Systemumfang. Architektur, Vertrag, Rollen, Betriebsbelege und die eigene Konfiguration muss die Bank weiterhin selbst bewerten.

Wie gehören Sanktionen, PEPs und adverse media in den Test?

Die Entity Resolution sollte den richtigen Personen- oder Organisationskontext für bestehende Screening- und Fallmanagementsysteme liefern. Die Risikoentscheidung bleibt in diesen nachgelagerten Kontrollen.

Prüfen Sie die Kontrollgrenze mit Ihren eigenen Anforderungen

Demo buchen, um Deployment, Schlüsselhoheit und Nachweisgrenze mit Ihrem Architekturteam durchzugehen, oder Tilores Studio kostenlos testen, um Matching und Datenherkunft mit einem kontrollierten Datensatz lokal zu prüfen.

Quellen

1. Deployment-Optionen: Tilores dort betreiben, wo Ihre Daten sind, Tilores.
2. Data Privacy and Security, Tilores.
3. Infrastrukturunabhängige Entity Resolution: Tilores auf AWS, einer anderen Cloud oder eigener Hardware betreiben, Tilores.
4. Entity Resolution Proof of Concept: 7 PoC-Inputs für Banken im Jahr 2026, Tilores.
5. Shared Security Responsibility Model, Amazon Web Services.
6. AWS KMS keys (customer managed, AWS managed und AWS owned keys), Amazon Web Services.
7. CloudTrail concepts, Amazon Web Services.
8. DORA 228 - 3317: Zugangs-, Inspektions- und Auditrechte, EIOPA.
9. Leitlinien zu Auslagerungsvereinbarungen, Europäische Bankenaufsichtsbehörde (EBA).
10. Entity Risk Tagging, OpenSanctions.
11. What an Entity Resolution Graph Looks Like and How It Is Queried, Tilores.
12. DORA Article 2 scope Q&A, EIOPA.
13. Guidelines 3/2018 on the territorial scope of GDPR, EDPB.
14. Data controller or data processor, EDPB.
15. DORA, Artikel 2, EUR-Lex.
16. EBA-Leitlinien zum Drittparteienrisiko und geltende Auslagerungsleitlinien, EBA.