Korean e-finance rules: assess your mobile banking app on the annual cycle and before every release.
The Electronic Financial Transactions Act requires financial companies and e-finance businesses to analyse and assess their electronic financial infrastructure and report the results to the FSC. The Regulation on Supervision of Electronic Financial Activities sets the cycle, the team and the fix deadlines, and the Financial Security Institute's criteria now cover cloud and mobile apps, with 288 mobile apps from 32 companies planned for assessment in 2026. Ostorlab tests your app and the APIs behind it, behind login, on every release.
- Assesses the mobile app and the APIs it calls, on the build your customers download
- Tests login, one-time codes, step-up checks and session handling with your test accounts
- Lists the SDKs and native libraries in each release and maps them to known vulnerabilities
- Proves each finding with a replayable exploit or request and response evidence
- Who it applies to
- Banks, e-finance businesses and other institutions supervised under the Electronic Financial Transactions Act, and MyData operators under the Credit Information Act
- Key date
- Regulation in force on 15 July 2026; SaaS network separation exception from 20 April 2026; principle-based reform from 5 February 2025
- Focus
- Annual vulnerability analysis and assessment, mobile app and API security, authentication, program integrity and data protection
- Main reference
- Regulation on Supervision of Electronic Financial Activities and the Financial Security Institute's assessment criteria
The Korean texts behind your mobile channel
The Regulation sits on the Electronic Financial Transactions Act, and the Financial Security Institute's criteria translate it into checks. The dates below are for the texts cited on this page.
- 13 August 2024
Network separation roadmap
The FSC sets out phased reform of the network separation rules: generative AI, wider SaaS use, better research and development environments, and a move towards self-security with result responsibility.
- 5 February 2025
Regulation reform
The Regulation is amended to move from detailed rules to principles, reducing some 293 prescriptive items to 166, and adds the authentication and password management articles.
- 30 December 2025
FSI criteria for 2026
The Financial Security Institute revises its assessment criteria: a new cloud management area, checks for systems past patch support, servers split into operating system and middleware, and new criteria for virtual asset exchanges.
- 13 February 2026
FSI assessment programme
The Financial Security Institute plans to assess 178 financial companies, expands the criteria from 14 areas and 789 items to 15 areas and 869 items, and schedules 288 mobile apps from 32 companies.
- 20 April 2026
SaaS network separation exception
The Enforcement Rules of the Regulation are amended so that SaaS can be used on internal work networks under strict controls, with no exception when unique identifiers or personal credit information are processed.
- 29 June 2026
FSS risk response meeting
The FSS tells 491 institutions to fix basic IT controls and make vulnerability analysis and assessment effective, and announces second-half inspections that include the SaaS conditions.
- 29 July 2026
Third-party IT risk guideline
The FSS and seven industry associations issue a guideline that puts ultimate responsibility on the board and requires a three-tier control structure, key third parties and contract lifecycle management.
The Korean e-finance rules, applied to your mobile app
For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team. The laws and the Regulation are summarised from the Korean text.
- Electronic Financial Transactions Act, Article 21-3; Regulation on Supervision of Electronic Financial Activities, Articles 37-2 and 37-3 (Korean text)
Run the annual vulnerability analysis and assessment
What the text says
Under Article 21-3 of the Electronic Financial Transactions Act, financial companies and e-finance businesses must analyse and assess their electronic financial infrastructure, covering the organisation, facilities and internal control of the IT division, the electronic devices and access media, and the incident response measures that keep e-finance transactions running, and report the results to the FSC. Article 37-2 of the Regulation sets the cycle: at least once a year for institutions with total assets of KRW 2 trillion or more and 300 or more regular employees, with public homepages checked at least every six months, and at least once a year for other institutions. The work is done by a dedicated team of five or more people including the CISO, with at least 30 percent qualified staff, or entrusted to an assessment institution designated under Article 37-3. An implementation plan must remove each vulnerability or take an equivalent measure; if that is not possible, the CEO approves the exception, and the results are reported to the CEO.
What it means for your mobile app
The annual assessment is the baseline for Korean financial institutions. If the mobile app and the APIs it calls are not in its scope, your customer-facing channel is outside the assessment.
How Ostorlab helps
Ostorlab runs AI-agent pentests of the store build and the APIs behind it, behind login, plus mobile SAST and SCA, on a schedule that fits the annual cycle and each release. Each AI-agent finding comes with a working exploit you can replay.
What stays with you
The institutional assessment and its report to the FSC, the dedicated team or the contract with a designated assessment institution, and the remediation plan.
- Financial Security Institute, 2026 vulnerability analysis and assessment, 13 February 2026; 2026 criteria revision, 30 December 2025 (Korean text)
Put mobile apps in the FSI assessment scope
What the text says
The Financial Security Institute runs most of the vulnerability analysis and assessment work and revises its criteria every year. For 2026 it expanded the electronic financial infrastructure criteria from 14 areas and 789 items in 2025 to 15 areas and 869 items, added 73 criteria specific to cloud environments, strengthened checks for systems and equipment whose security patch support has ended, and created a mock-hacking team. It planned to assess 288 mobile apps from 32 companies in 2026. Its fintech security checks also include a service vulnerability check for mobile and web, which open banking institutions and MyData operators use for their periodic checks.
What it means for your mobile app
Mobile app security is a standing part of the Korean assessment system, not an extra. The criteria look at the app, its client-side protections and its authentication as well as the server side.
How Ostorlab helps
Ostorlab tests the controls those criteria describe: binary analysis with taint analysis across the app and its embedded SDKs, runtime checks of root, jailbreak, tamper and pinning protections, and authenticated testing of the APIs behind login. Findings map to the controls your assessor asks about.
What stays with you
Contracting the assessment, the relationship with the FSI or a designated institution, and the institutional reporting.
- Regulation on Supervision of Electronic Financial Activities, Article 34(1)4 (Korean text)
Verify the integrity of the transaction program
What the text says
Article 34(1)4 of the Regulation requires financial companies and e-finance businesses to provide a way to verify that the e-finance transaction program, including transaction messages, has not been forged or altered.
Source:Regulation on Supervision of Electronic Financial Activities, Article 34(1)4 (Korean text)
What it means for your mobile app
A modified app or a modified transaction message must be detectable. Tamper detection and integrity checks are the app-side part; the backend has to check the transaction side.
How Ostorlab helps
Mobile Shielding Scan tests root and jailbreak detection, anti-tampering and pinning at runtime and reports which protections held and which were bypassed; Mobile SAST looks at the integrity logic in the binary.
What stays with you
Choosing the protection technology, deciding what the app does when an integrity check fails, and the transaction checks on the backend.
- Regulation on Supervision of Electronic Financial Activities, Articles 34-2, 34-3 and 19-2, added on 5 February 2025 (Korean text)
Manage authentication methods and passwords
What the text says
The Regulation was amended on 5 February 2025 and added Article 34-2, which requires safe authentication methods that consider the type, nature and risk level of the transaction, Article 34-3, which requires user passwords to be stored encrypted and not readable, sets rules for password creation and change, requires transactions to be suspended after repeated failed password entries and identity to be verified before they resume, and requires PIN pad or equivalent input, and Article 19-2, which requires a management plan for authentication means such as passwords and biometrics covering issuance, storage, periodic change and the handling of authentication errors.
What it means for your mobile app
Lockout, password policy and biometric handling are behaviours the backend enforces. The app must not be able to skip or weaken them, and the customer flows that use them have to hold.
How Ostorlab helps
Authenticated testing covers login and logout, one-time codes, step-up flows, lockout after repeated failures, token refresh, timeouts and session invalidation, with the API calls behind each.
What stays with you
The authentication policy, the choice of factors, and support for customers whose accounts are locked.
- Regulation on Supervision of Electronic Financial Activities, Article 36 (Korean text)
Pass the self security review before a new service
What the text says
Article 36 of the Regulation requires a self security review, following standards and procedures set by the FSS, before a new e-finance service is offered over information networks. The review report is submitted to the FSS within 30 days of the service starting, and the FSS can require improvements when it considers the level of security insufficient.
Source:Regulation on Supervision of Electronic Financial Activities, Article 36 (Korean text)
What it means for your mobile app
New services and major changes need a security review before launch, and the app is where customers meet the service. Waiting until after launch leaves the review without technical evidence.
How Ostorlab helps
Pre-release pentests of the app and the APIs behind it produce the technical evidence a self security review needs; store release monitoring shows what changed after launch.
What stays with you
The review itself, the report to the FSS, and decisions on its scope.
- Regulation on Supervision of Electronic Financial Activities, Article 15; FSC network separation improvement roadmap, 13 August 2024; FSC and FSS, SaaS network separation exception, 20 April 2026 (Korean text)
Work with the network separation reform
What the text says
The Regulation requires internal work systems to be separated from external networks, with limited exceptions. The FSC's network separation improvement roadmap of 13 August 2024 set out phased reform: allow generative AI use, widen the use of cloud-based software, improve research and development environments, and move towards a self-security, result-responsibility framework. On 20 April 2026 the Enforcement Rules of the Regulation were amended to add SaaS to the exceptions. SaaS can be used on internal work networks when it has been assessed by an incident response institution such as the FSI, endpoints such as computers and mobile devices are protected, safe authentication and least privilege apply, important information flows are monitored and controlled, unnecessary sharing and unauthorised internet access are blocked, network sections are encrypted, and compliance is evaluated twice a year and reported to the information protection committee chaired by the CISO. There is no exception when unique identifiers or personal credit information are processed, and pseudonymised information still goes through the innovation financial service process.
What it means for your mobile app
The reform changes where work happens, not what customers expect. Development and tooling can move to cloud services, but the app and its APIs still need testing, and some data cannot leave the country.
How Ostorlab helps
Ostorlab scans run from your CI/CD pipeline or on-premises behind your firewall, on infrastructure you control, so the app artifact and test data stay inside your environment. Production customer data is not needed.
What stays with you
The network architecture, the SaaS assessments, and the twice-yearly evaluations and committee reporting.
- FSS third-party IT risk management guideline, 29 July 2026; Financial Security Institute software supply chain security platform, 28 July 2025 (Korean text)
Manage third-party IT risk and the software supply chain
What the text says
On 29 July 2026 the FSS and seven industry associations issued the third-party IT risk management guideline. The board holds ultimate responsibility, a three-tier control structure of a general management department, a risk management department and an internal audit department manages the risk, third parties that matter to the institution or its customers are designated separately and reviewed at least every six months, and contracts cover due diligence, roles and liability, continuity, exit and data destruction. The FSI announced a software supply chain security platform on 28 July 2025 that provides integrated vulnerability management, SBOM management and bug bounty operations, with full operation from 2026.
What it means for your mobile app
The SDKs inside your app and the backends they call are third parties. Their components need versions, known vulnerabilities and an owner, and the contract and review record have to match.
How Ostorlab helps
SCA and SBOM list the SDKs and native libraries in each release with their versions and location in the app bundle, map them to known vulnerabilities, and track closure release after release. Network analysis shows which backends the app and its SDKs talk to.
What stays with you
Due diligence, contracts, the third-party register and the board reporting.
- Personal Information Protection Act, Articles 29 and 34; PIPC standards for ensuring the safety of personal information, Notice No. 2026-9 (Korean text)
Protect personal data under PIPA
What the text says
The Personal Information Protection Act requires personal information processors to take the technical, managerial and physical measures needed to keep personal information safe (Article 29), and to notify data subjects and report to the Personal Information Protection Commission or the Korea Internet and Security Agency in qualifying cases when personal information is lost, stolen or leaked (Article 34). The PIPC's standards for ensuring safety, Notice No. 2026-9 in force from 1 July 2026, set the minimum measures: management of access authorities, access control including safe authentication for remote access and protection of mobile devices, encryption including when personal data is transmitted over internet sections, retention and monthly checks of access logs, malware prevention, disaster preparedness and controls on output and copies.
What it means for your mobile app
The phone is part of the processing environment. Passwords, tokens and personal data must be encrypted, access must be logged, and exposure in storage, logs, screenshots and caches has to be prevented.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, checks transport protections and misconfigurations that weaken them, and finds API keys and credentials in the app package.
What stays with you
The internal management plan, the privacy officer role, breach notification and reporting, and access reviews.
- Credit Information Use and Protection Act, Articles 19 and 32; supervisory regulation for the credit information business, MyData security vulnerability check; FSI standing information protection evaluation, 28 April 2026 (Korean text)
Cover credit information and MyData checks
What the text says
The Credit Information Use and Protection Act requires credit information companies and users to put technical, physical and managerial security measures in place so that the credit information computer system is protected from unauthorised access, alteration, destruction and other risks (Article 19), and sets the rules for providing and using personal credit information with the data subject's consent (Article 32). Under the supervisory regulation for the credit information business, MyData operators must have their service reviewed by the FSI when it is developed or materially changed, and must have a security vulnerability check at least once a year by the FSI, an assessment institution designated under the Regulation or a dedicated team. The FSI's standing information protection evaluation covers about 3,000 financial companies under the Act, and for 2026 it strengthened the criteria for access rights and logs, personal data encryption, monitoring of anomalous behaviour, output minimisation, vulnerability checks, intrusion detection and blocking, malware protection and consent.
What it means for your mobile app
If your app is part of a MyData or credit information service, an annual security vulnerability check is already expected, and the app and API controls come up in it.
How Ostorlab helps
Ostorlab tests the app and its APIs against those control areas and produces evidence for each finding, so the annual check can focus on the institution-wide items.
What stays with you
The MyData licence and review process, the annual check, and the standing evaluation.
- FSS, Financial IT Risk Response Meeting, 29 June 2026 (Korean text)
Fix, report and retest
What the text says
At the Financial IT Risk Response Meeting on 29 June 2026, the FSS told 491 institutions that some of them had weak basic IT controls, and set out five points for preventing electronic financial accidents: follow basic IT controls, make security vulnerability analysis and assessment more effective, strengthen power facility safety, prevent unauthorised access through wireless networks, and follow incident response and reporting procedures. It asked institutions to define the scope and criteria of vulnerability assessments clearly, set remediation plans, avoid excessive risk acceptance, and follow up on remediation. In the second half of 2026 it will inspect compliance with basic IT controls and with the SaaS network separation conditions.
Source:FSS, Financial IT Risk Response Meeting, 29 June 2026 (Korean text)
What it means for your mobile app
An assessment that ends in a report is not enough. Supervisors look at scope, deadlines, fixes and retests, and at whether the same problems come back.
How Ostorlab helps
Findings become tickets in the platform or in Jira and ServiceNow, with severity, and are retested after the fix; the ticket history is the record of remediation.
What stays with you
Scope and criteria, risk acceptance decisions, and reporting to supervisors.
Summary of public Korean texts, checked on 27 September 2026. The laws and the Regulation are summarised from the Korean text. This page is not legal advice.
Korean rules, control by control
The controls the Korean texts point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Annual vulnerability analysis and assessmentEFTA Art 21-3; Regulation Art 37-2 | AI-agent pentest of the store build and its APIs, behind login, scheduled with the annual cycle and every release. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Mobile app assessment in the FSI criteriaFSI 2026 criteria | Binary analysis of APK, AAB and IPA with taint analysis across the app and its embedded SDKs. Details | Static findings with the code and component locations, per release |
| Integrity of the transaction programRegulation Art 34(1)4 | Tests root and jailbreak detection, anti-tampering and pinning at runtime, and reports which protections held. Details | A runtime report showing each protection and its result on the build you ship |
| Authentication, lockout and session handlingRegulation Arts 34-2, 34-3, 19-2 | Logs in with one-time codes and tests MFA enforcement, step-up flows, lockout after repeated failures and session invalidation. Details | Findings on login and step-up flows, with reproduction steps, and session and token logs |
| Self security review before a new serviceRegulation Art 36 | Mobile DAST and pre-release pentests of the app and its APIs produce the technical evidence for the review. Details | Pre-release scan results per build and per service change |
| Credentials embedded in the app and APIsRegulation Art 19-2 | Finds API keys, tokens and credentials in the app package and validates whether they work. Details | Validated secrets, with the permissions and services they expose |
| SDKs, components and fix deadlinesFSS third-party guideline; FSI supply chain platform | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Component identity, version and location, with upgrade or replace recommendations and closure tracked across releases |
| Data protection on the device and in transitPIPA Art 29; PIPC standards; Credit Information Act Art 19 | Intercepts app traffic even with TLS pinning, and looks for tokens and personal data in storage, caches, logs and screenshots. Details | File system and request evidence showing what was written or sent, where and when |
| Network separation conditions and on-premises testingRegulation Art 15; Enforcement Rules, 20 April 2026 | Runs scans behind your firewall or VPN, on infrastructure you control, so artifacts and test data stay inside. Details | Scan results and logs that stay in your environment |
| Remediation, deadlines and retestsFSS meeting, 29 June 2026 | Groups findings into tickets in the platform or in Jira and ServiceNow, and retests after the fix. | Ticket history and retest result for each finding |
Ostorlab tests controls in the app and its APIs. The institutional assessment, the dedicated team, SOC monitoring, incident response and reporting, breach notification, governance, third-party contracts and board reporting stay with your teams.
Korean controls to test in your mobile app
A practical list for security and system risk teams, based on the Electronic Financial Transactions Act, the Regulation and the FSI's assessment criteria.
Annual assessment scope
Put the mobile app and the APIs it calls in the scope of the vulnerability analysis and assessment, with a frequency that covers the annual cycle and each release.
Self security review
Run a pre-release test of the app and the APIs behind it for every new service or major change, and keep the results in the review file.
Program integrity
Check that the app detects tampering and that the backend checks transaction integrity, not only the app.
Authentication and lockout
Test MFA, one-time codes, step-up flows and lockout after repeated failures with your test accounts.
Components and deadlines
Keep a versioned list of the SDKs and libraries in each release, map them to known vulnerabilities and set fix deadlines by severity.
Secrets and data on the phone
Look for API keys, tokens and personal data in the package, storage, logs and screenshots, and rotate any credential that works.
Third parties and SaaS
For each SDK backend and SaaS in the delivery chain, keep the assessment, the contract and the review record, and report the twice-yearly SaaS evaluation to the information protection committee.
Fix, report and retest
Track findings to closure, retest after the fix, and keep the ticket history for the assessment report and FSS follow-up.
A suggested list, not an FSS or FSI template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- Electronic Financial Transactions Act (전자금융거래법)Korean text, current consolidation on law.go.kr. Article 21 (safety obligations), Article 21-2 (CISO), Article 21-3 (vulnerability analysis and assessment of electronic financial infrastructure) and Article 21-5 (incident notification)
- Regulation on Supervision of Electronic Financial Activities (전자금융감독규정)FSC Notice No. 2026-29, in force 15 July 2026, Korean text. Vulnerability analysis and assessment (37-2), assessment institutions (37-3), incident reporting (37-4), transaction encryption and program integrity (34), authentication and passwords (34-2, 34-3, 19-2), self security review (36), cloud use and network separation (14-2, 15). Amended on 5 February 2025 to move from detailed rules to principles
- 「금융분야 망분리 개선 로드맵」 발표 (Financial sector network separation improvement roadmap)FSC, 13 August 2024, Korean text. Phased reform for generative AI, SaaS and research and development environments, and the direction towards a self-security, result-responsibility framework
- 4월 20일부터 금융회사는 내부 업무망에서 클라우드 기반 응용소프트웨어(SaaS)를 보다 원활하게 활용할 수 있습니다 (SaaS network separation exception)FSC and FSS, 20 April 2026, Korean text. The Enforcement Rules of the Regulation amended; the conditions attached to SaaS use on internal work networks, and the data that gets no exception
- 금융보안원, 2026년도 취약점 분석·평가 실시 (FSI, 2026 vulnerability analysis and assessment)Financial Security Institute, 13 February 2026, Korean text. 178 institutions, criteria expanded to 15 areas and 869 items, 73 cloud criteria, 288 mobile apps from 32 companies, and the new mock-hacking team
- 금융감독원, 전자금융사고 대응 역량 및 IT복원력 강화를 위한 「금융IT 리스크 대응회의」 개최 (FSS Financial IT Risk Response Meeting)FSS, 29 June 2026, Korean text. Five points for preventing electronic financial accidents, including basic IT controls and the effectiveness of vulnerability analysis and assessment
- 금융회사의 제3자 IT리스크 관리 가이드라인 마련 (Third-party IT risk management guideline)FSS with seven industry associations, 29 July 2026, Korean text. Board responsibility, the three-tier control structure, key third parties and the contract lifecycle; association model standards from November 2026
- 개인정보의 안전성 확보조치 기준 (Standards for ensuring the safety of personal information)Personal Information Protection Commission, Notice No. 2026-9, in force 1 July 2026, Korean text. Minimum technical and managerial measures under Article 29 of the Personal Information Protection Act: access authority, access control, encryption, access logs, malware prevention, disaster preparedness and output controls
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Assess your mobile banking app the way the Korean rules describe it
Start with a free scan of your app from the store, or book a demo to run logged-in tests of your app and APIs with our team.