How Israeli Banks Can Achieve Amendment 13 Compliance Without Replacing Core Systems

Israeli banks face mounting pressure to comply with Amendment 13 requirements whilst managing the operational reality of legacy infrastructure. Replacing core banking systems to meet regulatory mandates isn’t just expensive, it’s disruptive, time-consuming, and introduces substantial operational risk. Yet compliance isn’t optional, and regulators expect robust data protection, access controls, and audit capabilities.

The challenge centres on securing sensitive customer data and maintaining regulatory defensibility without triggering a wholesale technology replacement programme. Banks need architectural approaches that layer modern security controls over existing systems, enforce policy at communication boundaries, and generate the audit trails regulators demand. This article explains how Israeli financial institutions can achieve Amendment 13 compliance by implementing targeted security layers rather than ripping out core banking platforms.

Executive Summary

Amendment 13 compliance requires Israeli banks to demonstrate comprehensive data protection, access governance, and audit capability across all customer information systems. Most banks operate on core platforms built decades ago, long before current regulatory compliance standards emerged. Replacing these systems is prohibitively expensive and operationally risky.

The solution lies in implementing a security architecture that wraps modern controls around legacy infrastructure. By securing sensitive data as it moves between systems, enforcing zero trust architecture policies, and capturing immutable audit trails at communication boundaries, banks can achieve regulatory compliance without replacing core banking platforms. This approach reduces risk, accelerates compliance timelines, and maintains operational continuity whilst meeting regulatory expectations.

Key Takeaways

1. Legacy Challenges in Compliance. Israeli banks struggle with Amendment 13 compliance due to outdated core banking systems that lack modern security features, making full replacement costly and risky.
2. Boundary-Based Security Solutions. Implementing zero-trust and content-aware security controls at communication boundaries allows banks to secure data flows without overhauling legacy infrastructure.
3. Immutable Audit Trails. Capturing detailed, tamper-proof audit logs at data boundaries ensures regulatory compliance by providing evidence of access controls and data protection measures.
4. Continuous Compliance Without Disruption. Automated policy enforcement and integration with existing security operations enable ongoing compliance with Amendment 13, adapting to evolving regulations without operational interruptions.

Understanding Amendment 13 Requirements Within Legacy Banking Environments

Amendment 13 establishes specific obligations for protecting customer data, controlling access to sensitive information, and maintaining audit logs that demonstrate continuous compliance. The regulation mandates outcomes: data must be encrypted in transit and at rest, access must follow least-privilege principles, and every interaction with sensitive information must be logged with tamper-proof records.

Israeli banks typically run on core banking systems deployed between the 1980s and early 2000s. These platforms weren’t designed with modern security architectures in mind. They often lack native encryption, rely on perimeter-based security models, and generate logs that don’t meet current audit standards. Many use proprietary protocols, run on legacy operating systems, and integrate with dozens of ancillary applications through custom interfaces.

The regulatory challenge isn’t that these systems can’t process transactions securely. It’s that they can’t demonstrate compliance in the way Amendment 13 requires. Regulators expect granular access logs, content-aware policy enforcement, and cryptographic proof that sensitive data hasn’t been tampered with. Legacy systems rarely provide these capabilities natively.

Replacing a core banking platform typically requires three to five years, costs tens of millions of shekels, and introduces significant operational risk during cutover. Banks must migrate customer accounts, reconfigure integrations, retrain staff, and manage inevitable disruption to customer-facing services. Given these constraints, replacement isn’t a viable path to near-term compliance. The more practical approach focuses on data flows rather than system inventories.

Start by mapping how sensitive customer data moves between systems. Identify every point where data exits the core banking platform: reports sent to regulators, files transferred to third-party processors, customer statements delivered via email, account information accessed by branch staff, and API calls from digital banking applications. Each of these flows represents a potential compliance gap.

Assess what controls currently protect each flow. Does the data travel encrypted? Is access logged with sufficient detail to reconstruct who accessed what data, when, and from where? Can you prove the data wasn’t altered in transit? Are access policies enforced based on role, context, and content sensitivity? In most legacy environments, the answer to several of these questions will be no. This flow-based assessment reveals compliance gaps without requiring exhaustive system audits and points toward a solution: if you can’t secure sensitive data inside legacy systems, secure it at the boundaries where it moves between systems.

Implementing Zero-Trust Controls at Communication Boundaries

Zero trust security assumes that no user, device, or system should be trusted by default. Every access request must be authenticated, authorised, and continuously validated based on identity, context, and the sensitivity of the requested resource. For banks with legacy infrastructure, implementing zero trust across every internal system is impractical. The more achievable approach implements zero-trust controls at the communication boundaries where sensitive data moves.

Legacy systems often authorise requests based on network location or a single authentication event at login. They don’t evaluate the specific sensitivity of the requested data, the employee’s current role or context, or whether the request follows expected patterns.

By implementing zero-trust controls at the communication boundary, banks can enforce more granular policies without modifying the core system. When a request reaches the boundary, a zero-trust enforcement point authenticates the user, verifies their current role and assigned permissions, evaluates the sensitivity of the requested data, checks for contextual anomalies, and applies encryption — AES-256 for data at rest and TLS 1.3 for data in transit — before transmitting the data. The core banking system sees a standard, authenticated request. The bank gains the security controls Amendment 13 requires.

This boundary-based approach applies across multiple scenarios: file transfers to third-party processors, API calls from digital banking applications, email communications containing customer information, automated reports sent to regulators, and remote access by staff working outside branch offices. In each case, zero-trust controls enforce policy at the point where data moves, rather than attempting to retrofit controls inside legacy systems.

Content-aware security evaluates the actual content of a communication, not just metadata. For Amendment 13 compliance, banks must demonstrate that highly sensitive data such as account numbers, identity information, and financial records receives stronger protection than less sensitive information. Legacy systems rarely distinguish between different sensitivity levels.

Content-aware policy enforcement inspects the actual data in transit, identifies sensitive elements using pattern matching and data classification rules, and applies appropriate controls based on what the communication contains. If a branch employee emails a document containing account numbers or national identification numbers, the enforcement point can require additional authentication, restrict delivery methods, apply stronger encryption, or block the transmission entirely if it violates policy.

This approach doesn’t require changes to the core banking system or the employee’s email client. The enforcement happens at the communication boundary, transparently to both the sender and the legacy system. Content-aware policies also support automated redaction and masking, allowing teams to receive usable data whilst limiting exposure of regulated information.

Generating Audit Trails That Meet Regulatory Standards

Amendment 13 requires banks to maintain detailed, tamper-proof records of every access to sensitive customer data. Regulators expect to see who accessed what information, when the access occurred, from where the request originated, what actions were taken with the data, and whether the access complied with established policies. These audit records must be immutable and retained for periods specified in the regulation.

Legacy banking systems generate logs, but these logs rarely meet regulatory standards. They often capture only high-level events like successful logins or batch job completions. They don’t record content-level access, policy decisions, or the full context around each interaction. Many legacy logging systems allow administrators to modify or delete log entries, failing the immutability requirement.

By implementing audit capture at communication boundaries, banks can generate comprehensive, immutable records without modifying legacy systems. Every time sensitive data moves, the enforcement point logs the complete context: the authenticated user identity, the requested resource and its sensitivity classification, the policy decision and reasoning, the source and destination systems, the time and duration of the interaction, and cryptographic proof that the data wasn’t altered in transit.

These logs are written to tamper-proof storage where even administrators can’t modify or delete entries. They follow a consistent format across all communication channels, simplifying correlation and analysis. When regulators request evidence of compliance, banks can produce complete audit trail that demonstrate policy enforcement, access controls, and zero trust data protection across every sensitive data flow.

Regulators don’t just want logs. They want evidence that demonstrates compliance with specific regulatory requirements. Compliance mapping functionality automatically tags each audit record with the specific Amendment 13 requirements it addresses. When the system logs an encrypted file transfer, it tags the record with references to the encryption requirements in Amendment 13. When it logs a policy decision that blocks unauthorised access, it tags the record with references to access control requirements.

During regulatory audits, this mapping allows banks to respond quickly to specific compliance questions. If regulators ask for evidence that the bank encrypts customer data in transit, the audit system can immediately produce all records tagged with the relevant encryption requirements, filtered by time period, data type, or business unit. Compliance mapping also supports continuous assessment, allowing banks to verify they’re generating evidence for every Amendment 13 requirement before regulators identify gaps.

Integrating Compliance Controls With Existing Security Operations and Third-Party Data Exchanges

Amendment 13 compliance must integrate with existing security operations, incident response workflows, and governance processes. Banks already operate security information and event management (SIEM) platforms, security orchestration, automation and response (SOAR) tools, IT service management systems, and identity and access management (IAM) infrastructure.

The communication boundary approach naturally supports integration. Because all sensitive data flows pass through enforcement points that generate consistent, structured audit records, these records can feed directly into existing security operations platforms. When the enforcement point detects an anomalous access pattern, it can automatically create an incident ticket, trigger an automated investigation workflow, and alert the security operations centre through the SIEM.

This integration enables faster detection and response. If an employee’s credentials are compromised and an attacker attempts to exfiltrate customer data, the enforcement point detects the anomalous request pattern, immediately blocks the attempt, logs the complete context, creates an incident record, and notifies the security team.

Integration also supports automated policy enforcement. If the identity and access management system revokes an employee’s access due to a role change or termination, the enforcement points automatically update their policies to block that user’s access to sensitive data flows.

Israeli banks routinely exchange sensitive customer data with third-party service providers: payment processors, credit bureaus, regulatory agencies, technology vendors, and business partners. Each exchange creates compliance risk. If the third party’s security controls don’t meet Amendment 13 standards, the bank remains liable for any breach or compliance failure.

Traditional approaches require extensive partner onboarding: security assessments, contract negotiations, technical integrations, and ongoing monitoring. The communication boundary approach shifts the compliance burden away from individual partners. Rather than requiring each third party to implement Amendment 13 controls, the bank enforces those controls at its own boundary. When the bank transfers customer data to a payment processor, the enforcement point encrypts the data, applies access controls, logs the complete transaction, and monitors for anomalies.

This approach dramatically simplifies partner onboarding. The bank establishes compliance requirements once, at its own boundaries, and applies them consistently to all third-party exchanges. New partners can be onboarded quickly because they don’t need to undergo extensive security assessments or implement bank-specific controls.

Advanced data protection techniques allow banks to maintain control even after data is shared. When the bank transfers customer data to a third party, the enforcement point can apply persistent protection that travels with the data: encryption that remains active until the data is accessed by an authorised user, access controls that continue enforcing bank policies even on third-party systems, automated expiration that renders the data unreadable after a specified time period, and remote revocation that allows the bank to immediately cut off access if security concerns emerge.

Achieving Continuous Compliance Without Disrupting Banking Operations

Amendment 13 compliance isn’t a one-time project. It’s an ongoing operational requirement that must be maintained as systems change, new threats emerge, regulations evolve, and business needs shift. Banks need architectures that support continuous compliance without requiring constant manual intervention or disrupting day-to-day operations.

The communication boundary approach supports continuous compliance through automated mechanisms. Policy enforcement is automated and consistent, applying the same controls to every sensitive data flow regardless of which systems or users are involved. Audit records are generated automatically, creating continuous evidence without manual logging or documentation. Compliance mapping continuously validates that the bank is meeting every regulatory requirement. Integration with security operations enables rapid detection and response when issues occur.

As regulations evolve, banks update policies at the enforcement boundaries rather than modifying individual legacy systems. If Amendment 13 is updated to require stronger encryption algorithms, the bank updates its encryption best practices at the enforcement points — upgrading cipher suites such as AES-256 or protocol versions such as TLS 1.3 as required. All sensitive data flows immediately gain the stronger protection without touching core banking platforms. Compliance becomes a managed, measurable process rather than a periodic scramble before audits.

Conclusion

Israeli banks can achieve Amendment 13 compliance without replacing core banking systems by implementing security controls at communication boundaries where sensitive data moves. This architectural approach wraps modern protection around legacy infrastructure, enforcing zero-trust and content-aware policies, generating immutable audit trails, and integrating with existing security operations.

The strategy focuses on outcomes that matter to regulators: demonstrating that sensitive data is encrypted in transit and at rest, proving that access follows least-privilege principles, maintaining tamper-proof records of every interaction with customer information, and responding rapidly when incidents occur. By securing data flows rather than attempting to retrofit legacy systems, banks reduce compliance timelines, lower operational risk, and maintain business continuity.

Looking ahead, the compliance landscape for Israeli banks will intensify across multiple dimensions. The Bank of Israel is moving towards an expectation of real-time compliance evidence — continuous, machine-readable demonstration of control effectiveness — rather than the retrospective audit documentation that has historically satisfied regulators. Simultaneously, DORA and Basel operational resilience frameworks are increasing pressure on institutions to document control effectiveness across legacy and modern systems simultaneously, creating a dual accountability that boundary-based architectures are uniquely positioned to satisfy. The rapid growth of open banking and API-driven financial services adds further urgency: as data flows extend beyond internal legacy systems to encompass ecosystem-wide exchanges with fintechs, aggregators, and embedded finance partners, boundary-based governance frameworks must scale to govern every new data vector — making early adoption of this architecture a strategic advantage, not merely a compliance measure.

Secure Sensitive Banking Data in Motion and Demonstrate Amendment 13 Compliance

Amendment 13 compliance challenges Israeli banks to protect sensitive customer data across legacy infrastructure that wasn’t designed for modern regulatory requirements. Replacing core banking systems isn’t practical, but compliance isn’t optional. The Kiteworks Private Data Network provides the architectural layer that bridges this gap.

Kiteworks secures sensitive data in motion by enforcing zero-trust and content-aware controls at communication boundaries. When customer information moves between systems, Kiteworks authenticates every user and device, evaluates the sensitivity of the requested data, enforces granular policies based on role and context, and applies AES-256 encryption at rest and TLS 1.3 encryption in transit to protect data throughout its journey. These controls layer over existing infrastructure without requiring changes to core banking platforms.

The Private Data Network generates immutable audit trails that map directly to Amendment 13 requirements. Every data access, policy decision, and security event is logged with complete context, creating the continuous compliance evidence regulators demand. These audit records integrate with existing SIEM platforms, SOAR tools, and IT service management systems, enabling security operations teams to detect and respond to incidents using familiar workflows.

Kiteworks also simplifies third-party data exchanges by maintaining control over sensitive information even after it’s shared with external partners. Banks can apply persistent protection, automated expiration, and remote wipe to customer data sent to payment processors, credit bureaus, and service providers.

For Israeli banks facing Amendment 13 deadlines whilst managing the operational reality of legacy systems, Kiteworks offers a path to compliance that doesn’t require wholesale infrastructure replacement. Schedule a custom demo to see how the Kiteworks Private Data Network can help your institution achieve regulatory compliance whilst maintaining operational continuity.