Wie israelische Banken die Anforderungen der Amendment 13 Compliance erfüllen – ohne ihre Kernsysteme auszutauschen

Israelische Banken stehen unter zunehmendem Druck, die Anforderungen der Amendment 13 zu erfüllen und gleichzeitig mit der Realität veralteter Infrastrukturen umzugehen. Der Austausch von Kernbankensystemen zur Einhaltung gesetzlicher Vorgaben ist nicht nur teuer, sondern auch disruptiv, zeitaufwendig und bringt erhebliche operative Risiken mit sich. Dennoch ist Compliance nicht optional, und die Aufsichtsbehörden erwarten einen robusten Datenschutz, Zugriffskontrollen und Prüfprotokolle.

Die Herausforderung besteht darin, sensible Kundendaten zu schützen und regulatorische Nachweispflichten zu erfüllen, ohne ein vollständiges Technologieaustauschprogramm auszulösen. Banken benötigen Architekturansätze, die moderne Sicherheitskontrollen über bestehende Systeme legen, Richtlinien an Kommunikationsgrenzen durchsetzen und die von Aufsichtsbehörden geforderten Audit-Trails generieren. Dieser Artikel erklärt, wie israelische Finanzinstitute die Compliance mit Amendment 13 erreichen können, indem sie gezielte Sicherheitsschichten implementieren, anstatt Kernbankplattformen auszutauschen.

Executive Summary

Die Einhaltung von Amendment 13 verlangt von israelischen Banken, umfassenden Datenschutz, Zugriffs-Governance und Audit-Fähigkeiten über alle Kundendatensysteme hinweg nachzuweisen. Die meisten Banken arbeiten auf Kernplattformen, die vor Jahrzehnten entwickelt wurden – lange bevor heutige Compliance-Standards entstanden sind. Ein Austausch dieser Systeme ist extrem teuer und mit hohen operativen Risiken verbunden.

Die Lösung liegt in der Implementierung einer Sicherheitsarchitektur, die moderne Kontrollen um die bestehende Infrastruktur legt. Durch die Absicherung sensibler Daten beim Transfer zwischen Systemen, die Durchsetzung von zero trust-Architektur-Richtlinien und die Erfassung unveränderlicher Audit-Trails an Kommunikationsgrenzen können Banken regulatorische Anforderungen erfüllen, ohne Kernbankplattformen auszutauschen. Dieser Ansatz reduziert Risiken, beschleunigt Compliance-Prozesse und erhält die operative Kontinuität bei gleichzeitiger Erfüllung regulatorischer Erwartungen.

wichtige Erkenntnisse

1. Herausforderungen durch Legacy-Systeme bei der Compliance. Israelische Banken kämpfen mit der Einhaltung von Amendment 13, da veraltete Kernbankensysteme moderne Sicherheitsfunktionen vermissen lassen, was einen vollständigen Austausch teuer und riskant macht.
2. Sicherheitslösungen an Kommunikationsgrenzen. Die Implementierung von zero trust- und inhaltsbasierten Sicherheitskontrollen an Kommunikationsgrenzen ermöglicht es Banken, Datenflüsse zu schützen, ohne die Legacy-Infrastruktur grundlegend zu verändern.
3. Unveränderliche Audit-Trails. Die Erfassung detaillierter, manipulationssicherer Audit-Protokolle an Daten-Grenzen stellt die Einhaltung regulatorischer Vorgaben sicher, indem sie Nachweise für Zugriffskontrollen und Datenschutzmaßnahmen liefern.
4. Kontinuierliche Compliance ohne Unterbrechung. Automatisierte Richtliniendurchsetzung und Integration in bestehende Sicherheitsoperationen ermöglichen eine fortlaufende Einhaltung von Amendment 13 und passen sich an neue regulatorische Anforderungen an, ohne den Betrieb zu stören.

Amendment 13-Anforderungen im Kontext von Legacy-Banking-Umgebungen

Amendment 13 legt spezifische Pflichten zum Schutz von Kundendaten, zur Kontrolle des Zugriffs auf vertrauliche Informationen und zur Führung von Audit-Logs fest, die eine kontinuierliche Compliance belegen. Die Regulierung schreibt vor: Daten müssen während der Übertragung und im ruhenden Zustand verschlüsselt werden, der Zugriff erfolgt nach dem Least-Privilege-Prinzip, und jede Interaktion mit sensiblen Informationen wird mit manipulationssicheren Protokollen dokumentiert.

Israelische Banken betreiben in der Regel Kernbankensysteme, die zwischen den 1980er und frühen 2000er Jahren eingeführt wurden. Diese Plattformen wurden nicht mit modernen Sicherheitsarchitekturen entwickelt. Häufig fehlt eine native Verschlüsselung, sie setzen auf perimeterbasierte Sicherheitsmodelle und erzeugen Protokolle, die heutigen Audit-Standards nicht genügen. Viele nutzen proprietäre Protokolle, laufen auf veralteten Betriebssystemen und sind über individuelle Schnittstellen mit zahlreichen Zusatzanwendungen verbunden.

Die regulatorische Herausforderung besteht nicht darin, dass diese Systeme Transaktionen nicht sicher verarbeiten könnten. Sie können jedoch die Compliance nicht so nachweisen, wie es Amendment 13 verlangt. Aufsichtsbehörden erwarten granulare Zugriffsprotokolle, inhaltsbasierte Richtliniendurchsetzung und kryptografische Nachweise, dass vertrauliche Daten nicht manipuliert wurden. Legacy-Systeme bieten diese Funktionen in der Regel nicht nativ.

Der Austausch einer Kernbankplattform dauert in der Regel drei bis fünf Jahre, kostet mehrere zehn Millionen Schekel und bringt erhebliche operative Risiken während der Umstellung mit sich. Banken müssen Kundenkonten migrieren, Integrationen neu konfigurieren, Mitarbeiter schulen und unvermeidbare Störungen im Kundenservice bewältigen. Angesichts dieser Herausforderungen ist ein Austausch kurzfristig keine praktikable Option. Ein praxisorientierter Ansatz konzentriert sich daher auf Datenflüsse statt auf Systeminventare.

Beginnen Sie damit, zu analysieren, wie sensible Kundendaten zwischen Systemen bewegt werden. Identifizieren Sie alle Punkte, an denen Daten die Kernbankplattform verlassen: Berichte an Aufsichtsbehörden, Dateien an Drittanbieter, Kontoauszüge per E-Mail, Kontoinformationen, auf die Filialmitarbeiter zugreifen, und API-Aufrufe aus digitalen Banking-Anwendungen. Jeder dieser Flüsse kann eine Compliance-Lücke darstellen.

Bewerten Sie, welche Kontrollen aktuell jeden Fluss schützen. Werden die Daten verschlüsselt übertragen? Wird der Zugriff so protokolliert, dass nachvollziehbar ist, wer wann und von wo auf welche Daten zugegriffen hat? Können Sie nachweisen, dass die Daten während der Übertragung nicht verändert wurden? Werden Zugriffsrichtlinien auf Basis von Rolle, Kontext und Sensitivität durchgesetzt? In den meisten Legacy-Umgebungen lautet die Antwort auf einige dieser Fragen: nein. Diese Fluss-basierte Analyse offenbart Compliance-Lücken, ohne umfassende Systemaudits zu erfordern, und weist auf die Lösung hin: Wenn Sie vertrauliche Daten nicht im Legacy-System schützen können, sichern Sie sie an den Grenzen, an denen sie zwischen Systemen bewegt werden.

Zero-Trust-Kontrollen an Kommunikationsgrenzen implementieren

Zero trust-Sicherheit geht davon aus, dass keinem Nutzer, Gerät oder System standardmäßig vertraut werden darf. Jeder Zugriffsversuch muss authentifiziert, autorisiert und kontinuierlich anhand von Identität, Kontext und Sensitivität der angeforderten Ressource validiert werden. Für Banken mit Legacy-Infrastruktur ist die Umsetzung von zero trust in allen internen Systemen nicht praktikabel. Ein realistischer Ansatz setzt zero trust-Kontrollen an den Kommunikationsgrenzen um, an denen sensible Daten bewegt werden.

Legacy-Systeme autorisieren Anfragen oft nur anhand des Netzstandorts oder eines einmaligen Authentifizierungsereignisses beim Login. Sie bewerten weder die Sensitivität der angeforderten Daten noch die aktuelle Rolle oder den Kontext des Mitarbeiters oder ob die Anfrage erwartungsgemäß ist.

Durch die Implementierung von zero trust-Kontrollen an der Kommunikationsgrenze können Banken granulare Richtlinien durchsetzen, ohne das Kernsystem zu verändern. Wenn eine Anfrage die Grenze erreicht, authentifiziert ein zero trust-Enforcement-Point den Nutzer, prüft Rolle und Berechtigungen, bewertet die Sensitivität der angeforderten Daten, erkennt kontextuelle Anomalien und verschlüsselt die Daten – AES-256 für ruhende Daten und TLS 1.3 für Daten während der Übertragung – bevor sie weitergegeben werden. Das Kernbankensystem sieht eine standardisierte, authentifizierte Anfrage. Die Bank erhält die Sicherheitskontrollen, die Amendment 13 fordert.

Dieser Ansatz an den Kommunikationsgrenzen gilt für verschiedene Szenarien: Dateiübertragungen an Drittanbieter, API-Aufrufe aus digitalen Banking-Anwendungen, E-Mail-Kommunikation mit Kundeninformationen, automatisierte Berichte an Aufsichtsbehörden und Remote-Zugriffe von Mitarbeitern außerhalb der Filiale. In jedem Fall setzen zero trust-Kontrollen die Richtlinie an dem Punkt durch, an dem Daten bewegt werden, statt Kontrollen nachträglich in Legacy-Systeme einzubauen.

Inhaltsbasierte Sicherheit bewertet den tatsächlichen Inhalt einer Kommunikation, nicht nur Metadaten. Für die Compliance mit Amendment 13 müssen Banken nachweisen, dass hochsensible Daten wie Kontonummern, Identitätsinformationen und Finanzdaten einen stärkeren Schutz erhalten als weniger sensible Informationen. Legacy-Systeme unterscheiden selten zwischen verschiedenen Sensitivitätsstufen.

Inhaltsbasierte Richtliniendurchsetzung prüft die tatsächlichen Daten während der Übertragung, identifiziert sensible Elemente mittels Mustererkennung und Datenklassifizierungsregeln und wendet je nach Inhalt geeignete Kontrollen an. Wenn ein Filialmitarbeiter ein Dokument mit Kontonummern oder nationalen Identifikationsnummern per E-Mail versendet, kann der Enforcement-Point zusätzliche Authentifizierung verlangen, Zustellmethoden einschränken, stärkere Verschlüsselung anwenden oder die Übertragung blockieren, wenn sie gegen Richtlinien verstößt.

Dieser Ansatz erfordert keine Änderungen am Kernbankensystem oder am E-Mail-Client des Mitarbeiters. Die Durchsetzung erfolgt an der Kommunikationsgrenze – für Absender und Legacy-System transparent. Inhaltsbasierte Richtlinien unterstützen zudem automatisierte Schwärzung und Maskierung, sodass Teams mit nutzbaren Daten arbeiten können, ohne regulierte Informationen offenzulegen.

Audit-Trails generieren, die regulatorischen Standards entsprechen

Amendment 13 verlangt von Banken, detaillierte, manipulationssichere Protokolle über jeden Zugriff auf sensible Kundendaten zu führen. Aufsichtsbehörden erwarten Nachweise darüber, wer auf welche Informationen zugegriffen hat, wann der Zugriff erfolgte, von wo die Anfrage kam, welche Aktionen mit den Daten durchgeführt wurden und ob der Zugriff den festgelegten Richtlinien entsprach. Diese Audit-Protokolle müssen unveränderlich sein und für die in der Regulierung festgelegten Zeiträume aufbewahrt werden.

Legacy-Bankensysteme erzeugen zwar Logs, diese genügen jedoch selten regulatorischen Anforderungen. Sie erfassen oft nur grobe Ereignisse wie erfolgreiche Logins oder abgeschlossene Batch-Jobs. Sie dokumentieren keinen Zugriff auf Inhaltsebene, keine Richtlinienentscheidungen oder den vollständigen Kontext jeder Interaktion. Viele Legacy-Logging-Systeme erlauben Administratoren das Ändern oder Löschen von Log-Einträgen – dies widerspricht dem Unveränderlichkeitsgebot.

Durch die Erfassung von Audit-Daten an Kommunikationsgrenzen können Banken umfassende, unveränderliche Protokolle generieren, ohne Legacy-Systeme zu verändern. Jedes Mal, wenn sensible Daten bewegt werden, protokolliert der Enforcement-Point den vollständigen Kontext: die authentifizierte Nutzeridentität, die angeforderte Ressource und deren Sensitivitätsklassifizierung, die Richtlinienentscheidung und deren Begründung, Quell- und Zielsysteme, Zeitpunkt und Dauer der Interaktion sowie kryptografische Nachweise, dass die Daten während der Übertragung nicht verändert wurden.

Diese Logs werden in manipulationssicheren Speichern abgelegt, auf die selbst Administratoren keinen Änderungs- oder Löschzugriff haben. Sie folgen einem einheitlichen Format über alle Kommunikationskanäle hinweg, was Korrelation und Analyse erleichtert. Wenn Aufsichtsbehörden Compliance-Nachweise verlangen, können Banken vollständige Audit-Trails vorlegen, die Richtliniendurchsetzung, Zugriffskontrollen und zero trust-Datenschutz für jeden sensiblen Datenfluss belegen.

Regulatoren verlangen nicht nur Logs, sondern Nachweise, die die Einhaltung spezifischer regulatorischer Anforderungen belegen. Die Compliance-Mapping-Funktionalität versieht jeden Audit-Eintrag automatisch mit den jeweiligen Amendment 13-Anforderungen. Wird beispielsweise ein verschlüsselter Dateitransfer protokolliert, erhält der Eintrag einen Verweis auf die Verschlüsselungsanforderungen von Amendment 13. Wird eine Richtlinienentscheidung, die unautorisierten Zugriff blockiert, protokolliert, wird der Eintrag mit den Zugriffsanforderungen verknüpft.

Während regulatorischer Audits ermöglicht dieses Mapping eine schnelle Beantwortung gezielter Compliance-Fragen. Wenn Aufsichtsbehörden Nachweise für die Verschlüsselung von Kundendaten während der Übertragung verlangen, kann das Audit-System alle relevanten Einträge nach Zeitraum, Datentyp oder Geschäftsbereich filtern und bereitstellen. Das Compliance-Mapping unterstützt zudem kontinuierliche Überprüfung, sodass Banken sicherstellen, dass sie für jede Amendment 13-Anforderung Nachweise generieren, bevor Aufsichtsbehörden Lücken aufdecken.

Compliance-Kontrollen mit bestehenden Sicherheitsoperationen und Drittparteien-Datenaustausch integrieren

Die Einhaltung von Amendment 13 muss sich in bestehende Sicherheitsoperationen, Incident-Response-Workflows und Governance-Prozesse integrieren. Banken betreiben bereits Security Information and Event Management (SIEM)-Plattformen, Security Orchestration, Automation and Response (SOAR)-Tools, IT-Service-Management-Systeme sowie Identity and Access Management (IAM)-Infrastrukturen.

Der Ansatz über Kommunikationsgrenzen unterstützt diese Integration von Natur aus. Da alle sensiblen Datenflüsse Enforcement-Points passieren, die strukturierte Audit-Protokolle generieren, können diese direkt in bestehende Sicherheitsplattformen eingespeist werden. Erkennt der Enforcement-Point ein anomales Zugriffsmuster, kann er automatisch ein Incident-Ticket erstellen, einen automatisierten Untersuchungsworkflow auslösen und das Security Operations Center über das SIEM informieren.

Diese Integration ermöglicht eine schnellere Erkennung und Reaktion. Werden beispielsweise die Zugangsdaten eines Mitarbeiters kompromittiert und ein Angreifer versucht, Kundendaten zu exfiltrieren, erkennt der Enforcement-Point das anomale Muster, blockiert den Versuch sofort, protokolliert den vollständigen Kontext, erstellt einen Incident-Record und benachrichtigt das Sicherheitsteam.

Die Integration unterstützt auch die automatisierte Richtliniendurchsetzung. Wenn das Identity and Access Management-System einem Mitarbeiter aufgrund einer Rollenänderung oder Kündigung den Zugriff entzieht, aktualisieren die Enforcement-Points automatisch ihre Richtlinien und blockieren den Zugriff dieses Nutzers auf sensible Datenflüsse.

Israelische Banken tauschen regelmäßig sensible Kundendaten mit Drittanbietern aus: Zahlungsdienstleister, Auskunfteien, Aufsichtsbehörden, Technologieanbieter und Geschäftspartner. Jeder Austausch birgt Compliance-Risiken. Erfüllen die Sicherheitskontrollen der Drittpartei nicht die Anforderungen von Amendment 13, bleibt die Bank für Verstöße oder Compliance-Fehler verantwortlich.

Traditionelle Ansätze erfordern umfangreiche Partner-Onboardings: Sicherheitsbewertungen, Vertragsverhandlungen, technische Integrationen und laufendes Monitoring. Der Ansatz über Kommunikationsgrenzen verschiebt die Compliance-Verantwortung weg von den einzelnen Partnern. Anstatt jede Drittpartei zur Umsetzung von Amendment 13-Kontrollen zu verpflichten, setzt die Bank diese Kontrollen an ihren eigenen Grenzen durch. Überträgt die Bank Kundendaten an einen Zahlungsdienstleister, verschlüsselt der Enforcement-Point die Daten, wendet Zugriffskontrollen an, protokolliert die Transaktion vollständig und überwacht auf Anomalien.

Dieser Ansatz vereinfacht das Partner-Onboarding erheblich. Die Bank definiert die Compliance-Anforderungen einmal an ihren eigenen Grenzen und wendet sie konsistent auf alle Drittparteien-Austausche an. Neue Partner können schnell eingebunden werden, da sie keine aufwendigen Sicherheitsbewertungen oder bankspezifische Kontrollen implementieren müssen.

Fortschrittliche Datenschutztechniken ermöglichen es Banken, die Kontrolle auch nach der Weitergabe von Daten zu behalten. Überträgt die Bank Kundendaten an eine Drittpartei, kann der Enforcement-Point einen dauerhaften Schutz anwenden, der mit den Daten mitreist: Verschlüsselung, die aktiv bleibt, bis ein autorisierter Nutzer auf die Daten zugreift, Zugriffskontrollen, die Bankrichtlinien auch auf Drittpartei-Systemen durchsetzen, automatische Ablaufdaten, die Daten nach einer bestimmten Zeit unlesbar machen, und Remote-Sperren, mit denen die Bank den Zugriff bei Sicherheitsbedenken sofort entziehen kann.

Kontinuierliche Compliance ohne Unterbrechung des Bankbetriebs erreichen

Die Einhaltung von Amendment 13 ist kein einmaliges Projekt, sondern eine laufende betriebliche Anforderung, die mit Systemänderungen, neuen Bedrohungen, sich entwickelnden Vorschriften und wechselnden geschäftlichen Anforderungen Schritt halten muss. Banken benötigen Architekturen, die kontinuierliche Compliance unterstützen, ohne ständige manuelle Eingriffe oder Betriebsunterbrechungen zu erfordern.

Der Ansatz über Kommunikationsgrenzen ermöglicht kontinuierliche Compliance durch automatisierte Mechanismen. Die Richtliniendurchsetzung erfolgt automatisiert und konsistent und wendet dieselben Kontrollen auf jeden sensiblen Datenfluss an – unabhängig von System oder Nutzer. Audit-Protokolle werden automatisch generiert und liefern kontinuierliche Nachweise ohne manuelles Logging oder Dokumentation. Das Compliance-Mapping prüft fortlaufend, dass alle regulatorischen Anforderungen erfüllt werden. Die Integration mit Sicherheitsoperationen ermöglicht eine schnelle Reaktion bei Vorfällen.

Mit sich ändernden Vorschriften aktualisieren Banken die Richtlinien an den Enforcement-Grenzen, statt einzelne Legacy-Systeme anzupassen. Wird Amendment 13 beispielsweise um stärkere Verschlüsselungsalgorithmen ergänzt, aktualisiert die Bank ihre Verschlüsselungs-Best Practices an den Enforcement-Points – etwa durch Upgrades der Cipher Suites wie AES-256 oder Protokollversionen wie TLS 1.3. Alle sensiblen Datenflüsse erhalten sofort den stärkeren Schutz, ohne die Kernbankplattformen zu verändern. Compliance wird zu einem gesteuerten, messbaren Prozess und nicht zu einer hektischen Vorbereitung vor Audits.

Fazit

Israelische Banken können die Compliance mit Amendment 13 erreichen, ohne Kernbankensysteme auszutauschen, indem sie Sicherheitskontrollen an den Kommunikationsgrenzen implementieren, an denen sensible Daten bewegt werden. Dieser Architekturansatz legt modernen Schutz um Legacy-Infrastrukturen, setzt zero trust- und inhaltsbasierte Richtlinien durch, generiert unveränderliche Audit-Trails und integriert sich in bestehende Sicherheitsoperationen.

Die Strategie konzentriert sich auf die für Aufsichtsbehörden relevanten Ergebnisse: Nachweis, dass sensible Daten während der Übertragung und im ruhenden Zustand verschlüsselt sind, Beleg, dass der Zugriff nach dem Least-Privilege-Prinzip erfolgt, manipulationssichere Protokolle jeder Interaktion mit Kundeninformationen und schnelle Reaktion bei Vorfällen. Durch die Absicherung von Datenflüssen, statt Legacy-Systeme nachzurüsten, verkürzen Banken die Compliance-Zeiten, senken operative Risiken und sichern die Geschäftskontinuität.

Mit Blick auf die Zukunft wird sich das Compliance-Umfeld für israelische Banken in mehreren Dimensionen verschärfen. Die Bank of Israel steuert auf die Erwartung von Echtzeit-Compliance-Nachweisen zu – kontinuierliche, maschinenlesbare Belege für die Wirksamkeit von Kontrollen – anstelle der rückblickenden Audit-Dokumentation, die bisher genügte. Gleichzeitig erhöhen DORA und Basel-Rahmenwerke für operationelle Resilienz den Druck, die Wirksamkeit von Kontrollen sowohl für Legacy- als auch für moderne Systeme gleichzeitig zu dokumentieren, was eine doppelte Nachweispflicht schafft, die boundary-basierte Architekturen besonders gut erfüllen. Das schnelle Wachstum von Open Banking und API-basierten Finanzdienstleistungen erhöht die Dringlichkeit zusätzlich: Da sich Datenflüsse über interne Legacy-Systeme hinaus auf das gesamte Ökosystem mit Fintechs, Aggregatoren und Embedded-Finance-Partnern ausweiten, müssen boundary-basierte Governance-Frameworks jeden neuen Datenvektor abdecken – und die frühe Einführung dieser Architektur wird zum strategischen Vorteil, nicht nur zur Compliance-Maßnahme.

Sensible Bankdaten in Bewegung schützen und Amendment 13-Compliance nachweisen

Die Einhaltung von Amendment 13 stellt israelische Banken vor die Herausforderung, sensible Kundendaten über Legacy-Infrastrukturen hinweg zu schützen, die nicht für moderne regulatorische Anforderungen konzipiert wurden. Der Austausch von Kernbankensystemen ist nicht praktikabel, aber Compliance ist verpflichtend. Das Private Data Network von Kiteworks bietet die architektonische Schicht, die diese Lücke schließt.

Kiteworks schützt sensible Daten in Bewegung, indem es zero trust- und inhaltsbasierte Kontrollen an Kommunikationsgrenzen durchsetzt. Wenn Kundeninformationen zwischen Systemen übertragen werden, authentifiziert Kiteworks jeden Nutzer und jedes Gerät, bewertet die Sensitivität der angeforderten Daten, setzt granulare Richtlinien je nach Rolle und Kontext durch und verschlüsselt Daten mit AES-256 im ruhenden Zustand und TLS 1.3 während der Übertragung – so bleibt der Schutz während des gesamten Datenflusses erhalten. Diese Kontrollen werden über die bestehende Infrastruktur gelegt, ohne Änderungen an den Kernbankplattformen zu erfordern.

Das Private Data Network generiert unveränderliche Audit-Trails, die direkt auf die Anforderungen von Amendment 13 abbilden. Jeder Datenzugriff, jede Richtlinienentscheidung und jedes Sicherheitsereignis wird mit vollständigem Kontext protokolliert und liefert so die kontinuierlichen Compliance-Nachweise, die Aufsichtsbehörden verlangen. Diese Audit-Protokolle integrieren sich in bestehende SIEM-Plattformen, SOAR-Tools und IT-Service-Management-Systeme, sodass Security-Teams Vorfälle mit vertrauten Workflows erkennen und bearbeiten können.

Kiteworks vereinfacht zudem den Datenaustausch mit Drittparteien, indem die Kontrolle über sensible Informationen auch nach der Weitergabe an externe Partner erhalten bleibt. Banken können dauerhaften Schutz, automatische Ablaufdaten und Remote Wipe für Kundendaten anwenden, die an Zahlungsdienstleister, Auskunfteien und Serviceanbieter übermittelt werden.

Für israelische Banken, die vor den Fristen von Amendment 13 stehen und gleichzeitig mit der Realität von Legacy-Systemen arbeiten, bietet Kiteworks einen Weg zur Compliance, der keinen vollständigen Infrastrukturaustausch erfordert. Vereinbaren Sie eine individuelle Demo, um zu sehen, wie das Private Data Network von Kiteworks Ihrem Institut helfen kann, regulatorische Anforderungen zu erfüllen und gleichzeitig die operative Kontinuität zu sichern.