South Korean banks, insurers, card companies and fintechs have worked for over a decade under one of the strictest financial security regimes anywhere, built on the Electronic Financial Transactions Act and a physical network separation rule that is now being loosened step by step for cloud, SaaS and AI. Security teams at Korean financial firms, and at foreign SaaS, cloud and AI vendors selling into them, need to know what still applies, what has changed and what conditions come with each exemption. This guide covers the Act's core security duties, the supervisory regulation, the Financial Services Commission (FSC) network separation roadmap from August 2024, the January 2026 SaaS revision and the 2026 moves on AI security. Personal data rules are covered in the South Korea PIPA Guide and are not repeated here.
Source note: the official Korean statute text could not be accessed in full. Statutory duties on this page are based on the article headings in the Korea Legislation Research Institute (KLRI) English translation and on the Baker McKenzie Global Data and Cyber Handbook; regulatory changes are based on FSC English press releases, with one press report (The Korea Times) for the June 2026 remarks. Confirm against the official text before relying on it.
Key takeaways
- The Act sets the safety duty. Chapter III of the Electronic Financial Transactions Act (EFTA) requires financial companies and electronic financial business entities to ensure the safety of electronic financial transactions, appoint a chief information security officer (CISO) and analyse and assess vulnerabilities in their electronic financial infrastructure.
- Infringement incidents must be notified. Under Article 21-5, firms must notify infringement incidents affecting electronic financial infrastructure (KLRI article heading; Baker McKenzie describes notification to the FSC). Confirm the timing in the official text.
- Network separation is being eased, not abolished. The August 2024 roadmap opened sandbox exemptions for generative AI and wider SaaS use, conditional on security measures, and set a long-term goal of principle-based, self-accountable security.
- The SaaS exemption carries five control conditions. The FSC's January 2026 proposed revision requires Financial Security Institute (FSI) pre-screening, access device controls, monitoring of critical information, blocking of unnecessary data and unauthorised internet services, and encryption, with six-monthly compliance reviews reported to the CISO.
- AI security is the next frontier. In June 2026 the FSC chairman said the FSC was speeding up work to relax network separation for security-purpose AI (The Korea Times); no rule or date has been set.
The legal stack
| Layer | Instrument | What it does for security |
|---|---|---|
| Act | Electronic Financial Transactions Act | Chapter III safety duties: Article 21 duty to ensure safety, 21-2 appointment of CISOs, 21-3 analysing and assessing vulnerability of electronic financial infrastructure, 21-4 prohibition of electronic infringement, 21-5 notification of infringement incidents, 21-6 response to infringement incidents (headings from the KLRI translation of the 2017 version); Article 9 covers liability of financial companies |
| Supervisory regulation | Regulation on Supervision of Electronic Financial Services (supervisory regulation on electronic financial services) | Detailed technical rules, including network separation, set by the FSC |
| Sector law on cloud | Act on the Development of Cloud Computing and Protection of Its Users and its Enforcement Decree | Defines the SaaS programs that the 2026 revision proposes to exempt from network separation |
| Sandbox | Financial regulatory sandbox | Temporary exemptions, used since 2023 for SaaS and since 2024 for generative AI |
| Supervisors | FSC, Financial Supervisory Service (FSS), Financial Security Institute (FSI) | FSC makes rules; FSS and FSI inspect and consult on exemption applicants; FSI pre-screens SaaS programs under the 2026 proposal |
Article numbering may have changed in later amendments, so check the current consolidated text on the Korean law portal.
Network separation: what it is and why it is changing
The FSC describes network separation as the requirement to physically separate financial companies' networks, which has kept financial data security built on an internal network environment. In its August 2024 announcement the FSC said the rule had been in place for ten years and that it caused inefficiency and held back research and development on SaaS and generative AI.
The model has a clear security logic: systems that process financial transactions and customer data sit on networks with no direct internet path, and staff use separate environments for internet access. The cost is that cloud collaboration tools, security SaaS and AI services need special treatment, and developers struggle to work with modern tooling.
The roadmap and its milestones
| Date | Step (FSC sources) | Status as of November 2026 |
|---|---|---|
| February 2024 | Proposed revision of the supervisory regulation shifting from rule-based to principle-based regulation, cutting rules from 293 to 166, removing prescriptive items such as password construction rules, strengthening chief executive and board roles, requiring disaster response centres and recovery time targets for smaller firms, raising minimum cyber insurance | Proposed; took effect only after final FSC deliberation, so confirm the current text |
| 13 August 2024 | Network separation improvement roadmap announced | In progress |
| September 2024 | Sandbox applications opened for generative AI use with internet access, subject to safeguards | Sandbox route available |
| Stage 2 | SaaS use extended beyond certain back-office functions to cyber and information security and customer relationship management, with an exemption | Delivered through the sandbox; SaaS rule revision proposed in 2026 |
| Stage 3 | Revise the supervisory regulation to ease physical separation for R&D and allow pseudonymised data use | Confirm with the FSC |
| Long term | Principle-based system centred on autonomous security and self-accountability, stronger third-party risk management, legal grounds for strict compensation and penalties for security failures | Policy direction |
| 19 January 2026 | Preliminary notice of revision exempting cloud SaaS from network separation; comment period 20 January to 9 February 2026 | Subject to regulatory review; no effective date announced in the notice |
| 10 June 2026 | FSC chairman says the FSC is moving to ease network separation for security-purpose AI (The Korea Times) | Under review, no deadline |
The FSC said that since September 2023, 32 financial companies had been permitted to run 85 SaaS programs under the sandbox, which shows how much practical demand sat behind the January 2026 proposal.
The SaaS exemption conditions
The January 2026 proposal exempts SaaS programs defined under the cloud computing Enforcement Decree from network separation, but not for handling personal identification information or personal credit information. Firms must demonstrate a certain level of capacity to comply with network security protocols, including the following.
| Condition | Practical implementation |
|---|---|
| FSI pre-screening of the SaaS program | Engage the vendor early; prepare architecture, data flow and security documentation for review |
| Certification and authorisation controls on access devices | Managed, compliant devices only; device certificates and conditional access tied to the SaaS tenant |
| Monitoring and control of input, processing and transfer of critical information | DLP rules and SaaS audit logs feeding the security operations centre |
| Preventing unnecessary information sharing and blocking unauthorised internet services | Data classification, tenant restrictions, egress filtering to approved SaaS endpoints only |
| Encryption on networks where SaaS is used | TLS enforced end to end, with inspection only where policy allows |
| Six-monthly compliance assessment reported to the CISO | Scheduled control testing with evidence retained for supervisors |
The proposal also lets firms use SaaS for administrative and back-office functions without per-program approval under the sandbox. See the Data Classification Guide for separating data that may enter SaaS from data that may not.
Decision guidance
- Sandbox or wait for the rule? Use the sandbox where a business case is urgent and you can show safeguards now; wait for the final revision for tools that are not time-critical, to avoid running two compliance tracks.
- Which workloads first? Start with workloads that touch no personal identification or personal credit information, such as security tooling and back-office collaboration, because the 2026 exemption excludes those data types.
- Large firms versus small: large groups can build their own pre-screening packs and monitoring; smaller electronic financial business entities should focus on the disaster recovery and recovery time targets highlighted in the February 2024 proposal before expanding SaaS.
- Foreign vendors: expect FSI review, data flow questions and requests for encryption and logging evidence. Prepare a Korea-specific security pack rather than a generic questionnaire answer.
Where identity fits
Easing network separation moves the security boundary from the network to identity and devices. Each exemption condition is, in practice, an identity control.
- Device and user authentication: the access device condition means binding SaaS sign-in to managed devices and strong user authentication. See the Financial Services Identity Security Guide.
- SaaS integrations and tokens: OAuth grants and API keys between SaaS tools and internal systems can move critical information without any human session. Inventory them and restrict scopes so the monitoring condition covers machine traffic too.
- AI agents for security: if security-purpose AI gets internet access under the 2026 changes, give each agent its own identity, least-privilege permissions and logged actions. See the AI Agents in Financial Services Security Guide.
How to implement: a phased approach
- Map current separation: document which networks are separated, which exemptions you already hold and which SaaS and AI tools are in sandbox use.
- Classify data: mark personal identification and personal credit information and keep it out of exempt SaaS.
- Build the control set: managed devices, conditional access, DLP, egress allow-lists and encryption for each candidate service.
- Pilot: one low-risk SaaS workload with a small user group, with the old separated workflow kept available as the rollback path.
- Pre-screen and apply: submit the vendor and control evidence for FSI review or sandbox designation.
- Expand in rings: extend users and workloads only after the first six-monthly compliance assessment is clean.
- Report: keep the CISO informed through the six-monthly review and board reporting.
The sequence is our suggestion; follow FSC and FSI instructions where they differ.
Detection and measurement
- Unapproved internet services blocked: count of blocked connections to unapproved services from separated or SaaS-enabled segments.
- Critical data transfers: number of DLP alerts for personal identification or credit information heading to SaaS, and time to triage.
- Device compliance: percentage of SaaS sign-ins from managed, certified devices (target 100 per cent).
- Integration inventory: number of SaaS OAuth grants and API keys reviewed in the last six months.
- Incident notification time: time from detecting an infrastructure disruption by intrusion to FSC notification.
Common failure patterns
- Exemption treated as a blanket licence: a SaaS tool approved for back-office work quietly receives customer credit data.
- Unmanaged access devices: staff reach exempt SaaS from personal devices, breaking the access device condition.
- Machine traffic outside monitoring: API integrations move data without passing through DLP.
- Missed six-month review: compliance assessment slips and the CISO has no current evidence.
- Old article references: policies cite EFTA article numbers from an outdated translation.
Framework mapping
| Korean requirement | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Network separation | PR.IR-01 | SC-7 |
| CISO and governance | GV.RR-01 | PM-2 |
| Vulnerability analysis and assessment | ID.RA-01 | RA-5, CA-8 |
| Incident notification to the FSC | RS.CO-02 | IR-6 |
| SaaS access device controls | PR.AA-03 | AC-20 |
| Monitoring critical information flows | DE.CM-09 | AC-4 |
| Encryption on SaaS networks | PR.DS-02 | SC-8 |
| SaaS vendor pre-screening | GV.SC-07 | SA-9 |
The mapping is ours, for orientation.
Practitioner checklist
- Confirm the current consolidated EFTA and supervisory regulation text, including article numbers.
- Check that the CISO appointment, vulnerability assessment and incident notification process are current.
- List all sandbox designations and SaaS or AI exemptions you hold, with conditions.
- Keep personal identification and personal credit information out of exempt SaaS.
- Enforce managed, certified devices for SaaS access.
- Route SaaS and API data flows through DLP and logging.
- Allow-list egress to approved SaaS endpoints and block other internet services.
- Run and report the six-monthly compliance assessment to the CISO.
- Track FSC announcements on AI security and network separation through 2026.
Standards and references
- Financial Services Commission: Roadmap to make improvements to network separation in the financial industry
- Financial Services Commission: Network separation rule to be eased to facilitate use of cloud-based SaaS
- Financial Services Commission: Proposed revision to Supervisory Regulation on Electronic Financial Services
- Korea Legislation Research Institute: Electronic Financial Transactions Act (English translation)
- Baker McKenzie: Global Data and Cyber Handbook, South Korea security requirements and breach notification
- The Korea Times: Chief regulator says efforts underway to ease network separation rules
Related NHI Mgmt Group resources: South Korea PIPA Guide · Financial Services Cyber Regulation Map · South Korea AI Basic Act Guide · Network Segmentation Guide. This guide summarises South Korean financial sector cyber rules and is not legal advice. Confirm against the official text before relying on it.